ticket,summary,component,version,milestone,type,owner,status,created,_changetime,_description,_reporter
13645,boost::geometry::simplify broken in 1.67,geometry,Boost 1.67.0,To Be Determined,Bugs,Barend Gehrels,new,2018-07-28T18:51:42Z,2018-07-28T19:09:12Z,"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))",Eyal Soha <eyalsoha@…>
13644,std::iterator_traits<>::value_type is always non-const for any kind of boost::iterator_facade Iterator,iterator,Boost 1.67.0,To Be Determined,Bugs,jeffrey.hellrung,new,2018-07-26T14:32:38Z,2018-07-26T14:32:38Z,"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:

{{{
#!C++
#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

{{{
#!C++

    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
{{{
#!C++
typedef typename remove_const<ValueParam>::type value_type;
}}}
to
{{{
#!C++
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>>'
}}}",Florian Reiser <florian.reiser@…>
13642,Strange behaviour of filesystem::relative on Windows,filesystem,Boost 1.67.0,To Be Determined,Bugs,Beman Dawes,new,2018-07-25T12:21:31Z,2018-07-25T12:21:31Z,"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.
",martin.apel@…
13641,Boost.Build doesn't create config.log when --build-dir is specified,build,Boost 1.66.0,To Be Determined,Bugs,Vladimir Prus,new,2018-07-23T11:16:44Z,2018-07-23T11:16:44Z,"Platform: Windows

How to reproduce:
1. Extract Boost sources to some directory, say D:\boost
2. Bootstrap Boost as usual
3. 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.
",alexsharoff@…
13640,GCC trunk can only compile program_options with -fpermissive,program_options,Boost 1.65.0,To Be Determined,Bugs,Vladimir Prus,new,2018-07-23T09:51:27Z,2018-07-23T09:51:27Z,"/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,
              ^~~~~
",anonymous
13639,monotonic_buffer_resource current_buffer() possibly broken and documentation wrong,container,Boost 1.67.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-07-21T14:18:22Z,2018-07-21T15:19:17Z,"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
",Markus Dreseler
13638,wrong system to generic error conversion on windows with ERROR_SHARING_VIOLATION,system,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,new,2018-07-18T14:40:41Z,2018-07-19T00:21:07Z,"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. 


",joseph@…
13636,distance calculation can be wrong for rings with collinear segments,geometry,Boost 1.67.0,To Be Determined,Bugs,Barend Gehrels,new,2018-07-17T12:49:55Z,2018-07-17T13:25:31Z,"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.",stfn <p1433025@…>
13635,circular_buffer does not always initialize elements,circular_buffer,Boost Development Trunk,To Be Determined,Bugs,Jan Gaspar,new,2018-07-17T08:41:42Z,2018-07-17T08:45:14Z,"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}}}.
{{{#!c++
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:
{{{#!c++
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:
{{{#!c++
#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
}
}}}",Niklas Fejes <niklas.fejes@…>
13634,regex duplicating literal part of replace string,regex,Boost 1.67.0,To Be Determined,Bugs,John Maddock,new,2018-07-13T14:29:28Z,2018-07-13T14:29:28Z,"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;
}
}}}",joseph@…
13633,boost/system/error_code.hpp fails to compile on clang-3.6 in gnu++14 mode due to invalid constexpr,system,Boost Release Branch,Boost 1.68.0,Bugs,Beman Dawes,new,2018-07-12T06:08:28Z,2018-07-12T06:08:28Z,"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.",Rainer Deyke <rainerd@…>
13632,boost::function operator== is bugged on FreeBSD 11.2,function,Boost 1.67.0,To Be Determined,Bugs,Douglas Gregor,new,2018-07-11T13:45:32Z,2018-07-22T01:00:03Z,"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.",hongli@…
13631,Need for boost::property_tree:ptree::range_type,property_tree,Boost 1.67.0,To Be Determined,Feature Requests,Sebastian Redl,new,2018-07-09T09:51:56Z,2018-07-09T09:51:56Z,"{{{

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 );
    }

}}}",dmilos@…
13630,Missing assembly files on iOS,context,Boost 1.66.0,To Be Determined,Bugs,olli,new,2018-07-09T09:10:17Z,2018-07-09T09:10:17Z,"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.",delrieutheo@…
13629,boost::fusion::make_map cannot be called with boost::fusion::vector,fusion,Boost 1.67.0,To Be Determined,Bugs,Joel de Guzman,new,2018-07-07T05:48:09Z,2018-07-07T05:48:09Z,"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>        ]
",Shintaro Sakahara <shintaro-sakahara@…>
13628,"boost::intrusive::rbtree::insert_unique() may throw, contrary to what the doc says",intrusive,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-07-06T12:07:07Z,2018-07-06T12:07:07Z,"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

}}}

",anonymous
13627,"""bcp --namespace=..."" misses change in macro for ""unordered"".",bcp,Boost 1.67.0,To Be Determined,Bugs,John Maddock,new,2018-07-05T17:37:53Z,2018-07-06T10:04:50Z,"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",Lou Barbieri <louis.barbieri@…>
13626,Growing managed mapped file cause a pointer invalidation,interprocess,Boost 1.67.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-07-05T15:47:47Z,2018-07-05T15:57:43Z,,bvbfan@…
13624,"GCC 8.1.1 Error: ""Failed to determine builtin floating point type sizes""",atomic,Boost 1.67.0,To Be Determined,Bugs,timblechmann,new,2018-07-03T15:53:30Z,2018-07-04T13:31:15Z,"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",simon.michalke@…
13623,scope_exit has broken documentation,scope_exit,Boost 1.67.0,To Be Determined,Bugs,Lorenzo Caminiti,new,2018-07-03T03:15:15Z,2018-07-03T03:15:15Z,"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.",Kef Schecter <furrykef@…>
13622,BOOST_SCOPE_EXIT error : use of undeclared identifier 'boost_se_params_t_*,scope_exit,Boost 1.67.0,To Be Determined,Bugs,Lorenzo Caminiti,new,2018-06-29T05:20:40Z,2018-06-29T05:20:40Z,"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.
}}}",markus_bonk@…
13619,boost.crc fails to compile with gcc due to undefined behaviour,crc,Boost 1.67.0,To Be Determined,Bugs,Daryle Walker,new,2018-06-26T19:11:34Z,2018-06-26T19:13:01Z,"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)
}}}",Pavel Fevralev <dllmain@…>
13618,Support for string_view etc...,string_algo,Boost 1.67.0,To Be Determined,Feature Requests,Marshall Clow,new,2018-06-26T11:21:50Z,2018-06-26T14:44:46Z,"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.
",stream009@…
13616,"""likely"" is c++2a-keyword used by gcc 8.1.1 but used as identifier",date_time,Boost 1.67.0,To Be Determined,Bugs,az_sw_dude,new,2018-06-24T08:11:43Z,2018-06-24T08:11:43Z,"In new  [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0479r5.html 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

",anonymous
13614,padding related issue on VS2017 with boost::endian,endian,Boost 1.67.0,To Be Determined,Bugs,Beman Dawes,new,2018-06-21T04:51:38Z,2018-06-21T04:51:38Z,"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.

{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!c++
#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;
}
  }}}
}}}
",imak@…
13613,gcd performs modulo by zero which is undefined,integer,Boost 1.67.0,To Be Determined,Bugs,Daryle Walker,new,2018-06-20T12:45:53Z,2018-06-20T12:45:53Z,"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

>   1. divide_arg: n is used as a divisor in function gcd.
    return integer::gcd( n, m );
}
","James E. King, III"
13612,Missing support for move semantic in boost::bimap,bimap,Boost 1.67.0,To Be Determined,Feature Requests,Matias Capeletto,new,2018-06-20T06:44:56Z,2018-06-20T06:44:56Z,And due to that that useful container is slow as hell.,piotrzsl@…
13610,_env_impl is not reloaded,process,Boost 1.63.0,To Be Determined,Bugs,,new,2018-06-19T12:34:48Z,2018-06-19T12:34:48Z,"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",santa4github@…
13607,Asio bad_address_cast fix under no exceptions,asio,Boost Development Trunk,To Be Determined,Bugs,chris_kohlhoff,new,2018-06-14T18:12:21Z,2018-06-14T18:15:01Z,"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.",kvankooten
13605,Filedescriptor leak in boost::process,process,Boost 1.64.0,To Be Determined,Bugs,,new,2018-06-14T13:27:47Z,2018-06-14T13:27:47Z,"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?
",4hopp
13601,Compiling iterator_range_core.hpp with VS2017 (15.7.1) generates the Warning C5032.,range,Boost 1.67.0,To Be Determined,Bugs,Neil Groves,new,2018-06-14T07:36:33Z,2018-06-14T07:36:33Z,"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
}}}
",alexander.frank.lehmann@…
13599,condition_variable::timed_wait never returns,thread,Boost 1.65.0,To Be Determined,Support Requests,viboes,assigned,2018-06-14T03:04:33Z,2018-09-11T21:29:43Z,"boost::condition_variable::timed_wait never returns if compiled with -DBOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC.

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

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

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

{{{
#define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC

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

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

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

    return 0;
}
}}}
",steven.cook@…
13597,"VC++ 15 compiler warning C4244: 'argument': conversion from 'const coordinate_type' to 'const int', possible loss of data",geometry,Boost 1.67.0,To Be Determined,Bugs,Barend Gehrels,new,2018-06-13T13:34:58Z,2018-06-14T09:42:23Z,"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.",Volker Schöch <vschoech@…>
13594,init_from_settings does not allow repeated calls,log,Boost 1.67.0,To Be Determined,Bugs,Andrey Semashev,new,2018-06-13T09:42:49Z,2018-06-13T10:24:38Z,"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).

",PieterB@…
13593,intersects assertion failure for linestrings in spherical_equatorial coordinates,geometry,Boost 1.67.0,To Be Determined,Bugs,Barend Gehrels,new,2018-06-13T09:31:59Z,2018-06-13T09:31:59Z,"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.",swordvetal@…
13592,"command_line_parser(int, char const*[]) throws std::bad_alloc when called with zero arguments",program_options,Boost 1.67.0,To Be Determined,Bugs,Vladimir Prus,new,2018-06-12T09:58:32Z,2018-06-12T09:58:32Z,"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);
}
}}}",kai.unger@…
13590,Bug in executor::_read_error leads to bad string allocation exception,process,Boost 1.65.0,To Be Determined,Bugs,,new,2018-06-11T09:15:19Z,2018-06-11T09:15:19Z,"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.
",Elmar Daegele <elmar.daegele@…>
13589,boost_1_55_0 bootstrap mingw failed,Building Boost,Boost 1.55.0,To Be Determined,Support Requests,"James E. King, III",new,2018-06-11T01:47:06Z,2018-09-21T09:02:10Z,"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 

}}}
",Rie <princedragon9924@…>
13588,rename lock_sharable and its methods(and mutex methods) in order of concept of std::lock_shared,interprocess,Boost 1.67.0,To Be Determined,Tasks,Ion Gaztañaga,new,2018-06-07T08:54:52Z,2018-06-07T08:54:52Z,"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...",fsmoke@…
13587,ssl::stream::async_shutdown() never completes when async_read is active,asio,Boost 1.67.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-06-06T07:46:10Z,2018-06-06T07:46:10Z,"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:
1. Is it allowed to call async_shutdown on an ssl::stream when there is an async_read pending?
2. If yes, is the above behavior expected?
3. 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.",anonymous
13586,array::rangecheck() allows access one element past end of array,array,Boost 1.67.0,To Be Determined,Bugs,Marshall Clow,new,2018-06-02T08:38:20Z,2018-06-02T08:38:20Z,"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.",anonymous
13585,Undefined Behavior results in optimizer removing critical check,filesystem,Boost 1.67.0,To Be Determined,Bugs,Beman Dawes,new,2018-05-31T21:16:23Z,2018-05-31T21:16:23Z,"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.",bart.wyatt@…
13584,"boost beast flat buffer move ctor, move assign and swap all ""cancel"" a prepare()",asio,Boost 1.67.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-05-31T03:34:48Z,2018-05-31T13:07:01Z,"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

",paul.d.rose@…
13583,"quantities can be assigned from cmath sqrt result, but not initialized",units,Boost 1.67.0,To Be Determined,Bugs,Matthias Schabel,new,2018-05-30T21:33:28Z,2018-05-30T21:33:28Z,"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.
",edaskel@…
13582,what does $(>) mean?,build,Boost 1.67.0,To Be Determined,Support Requests,Vladimir Prus,new,2018-05-30T06:42:25Z,2018-05-30T06:42:25Z,"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? 
",anonymous
13581,`basic_stream_socket::read_some` on `non_blocked` socket returns `ec=would_block`,asio,Boost Development Trunk,To Be Determined,Bugs,chris_kohlhoff,new,2018-05-29T14:52:30Z,2018-05-30T09:48:25Z,"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;
}}}

",Dmytro Ovdiienko <dmitriyovdienko@…>
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)",filesystem,Boost 1.67.0,To Be Determined,Bugs,Beman Dawes,new,2018-05-29T11:50:09Z,2018-05-29T11:55:17Z,"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.",sz@…
13579,memory management in algorithm::is_any_of,string_algo,Boost 1.63.0,To Be Determined,Bugs,Marshall Clow,new,2018-05-29T10:29:02Z,2018-06-13T20:24:35Z,"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.",anonymous
13578,Why boost.context export make_x86_64_sysv_elf_gas.o,context,Boost 1.67.0,To Be Determined,Support Requests,olli,new,2018-05-29T07:54:20Z,2018-05-30T02:01:12Z,"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?",anonymous
13576,boost filesystem create_directories function fails randomly when accessing to a mapped network drive,filesystem,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2018-05-28T15:07:47Z,2018-05-28T15:07:47Z,"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.",sergio.anza@…
13575,boost asio memory leak,asio,Boost 1.67.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-05-24T14:39:13Z,2018-05-31T08:44:59Z,"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.
",boris@…
13573,container/detail/flat_tree.hpp should not #include <boost/move/make_unique.hpp>,container,Boost 1.64.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-05-23T14:38:52Z,2018-05-23T14:38:52Z,"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.",huili80@…
13571,difference results in invalid output,geometry,Boost 1.66.0,To Be Determined,Bugs,Barend Gehrels,new,2018-05-22T14:25:02Z,2018-05-22T14:25:02Z,"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.",anonymous
13570,asio_handler_invoke resume wrong thread in coroutine,asio,Boost 1.67.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-05-21T09:58:20Z,2018-05-21T09:58:20Z,"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;

}
}}}



",pengying.wu@…
13569,Broken build on newer versions of LLVM,atomic,Boost 1.63.0,To Be Determined,Patches,timblechmann,new,2018-05-18T21:45:49Z,2018-05-18T21:45:49Z,"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.)


",Emil Gilliam <egilliam@…>
13568,no referenceto boost::regex libraries error in compilation,regex,Boost 1.65.0,Boost 1.65.0,Support Requests,John Maddock,new,2018-05-18T13:58:20Z,2018-05-18T13:58:20Z,"- 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
",anonymous
13567,io_context ::run() doesn't return immediately on stopped io_context due to Windows implementation,asio,Boost 1.67.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-05-16T08:27:11Z,2018-05-16T08:27:11Z,"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
}}}

[https://www.boost.org/doc/libs/1_67_0/doc/html/boost_asio/reference/io_context/stop.html 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 [https://www.boost.org/doc/libs/1_67_0/doc/html/boost_asio/reference/io_context/stopped.html 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.",cvzakharchenko@…
13566,difference and intersection yield wrong result,geometry,Boost 1.66.0,To Be Determined,Bugs,Barend Gehrels,new,2018-05-16T06:51:43Z,2018-05-16T07:01:10Z,"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.

",Henrik Zimmer <henrik@…>
13565,Compilation issue with property_tree on VS2017 15.7,property_tree,Boost 1.67.0,Boost 1.68.0,Bugs,Sebastian Redl,new,2018-05-15T10:05:28Z,2018-05-15T11:59:32Z,"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.
",Pavel Pokutnev <pavel.pokutnev@…>
13564,Compile error of asio::async_read_until,asio,Boost 1.67.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-05-13T11:28:16Z,2018-07-02T15:31:39Z,"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.",Vincent Lextrait <vincent.lextrait@…>
13563,Error deserializing empty forward_list,serialization,Boost 1.67.0,To Be Determined,Patches,Robert Ramey,new,2018-05-11T12:03:11Z,2018-05-11T12:03:11Z,"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)
}}}",Maximiliano Pin <mxcpin@…>
13562,Missing null pointer check in compensating_work_started,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-05-08T08:01:20Z,2018-05-09T09:28:41Z,"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   }
}}}

",michael.lindig@…
13560,Cannot build --with-python --with-mpi --python-buildid=py36 python=3.6,mpi,Boost 1.66.0,To Be Determined,Bugs,Matthias Troyer,new,2018-05-03T11:43:37Z,2018-05-03T11:43:37Z,"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
",Dimitri John Ledkov <xnox@…>
13559,boost::program_options::detail::make_vector class removed?,program_options,Boost 1.67.0,To Be Determined,Bugs,Vladimir Prus,new,2018-05-02T23:30:04Z,2018-05-08T15:40:09Z,"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?

",anonymous
13558,"gcd(INT_MIN, INT_MIN) crashes",integer,Boost 1.67.0,To Be Determined,Bugs,Daryle Walker,new,2018-05-02T20:28:08Z,2018-05-02T20:28:33Z,"The following produces a SIGFPE for me:

{{{#!c++
#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",Evan Driscoll <evaned@…>
13557,Boost 1.67.0 chrono library Windows build installs NTFS junction,chrono,Boost 1.67.0,Boost 1.69,Bugs,viboes,new,2018-05-01T19:14:37Z,2018-09-11T18:57:46Z,"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?",george@…
13556,boost::geometry::within() is not finding a point within a segment,geometry,Boost 1.67.0,To Be Determined,Bugs,Barend Gehrels,new,2018-05-01T17:20:11Z,2018-05-01T17:20:11Z,"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.",Josiah Slack <josiahnmi@…>
13555,Crash when statically linked to the dynamic library when use dlopen.,serialization,Boost 1.66.0,To Be Determined,Bugs,Robert Ramey,new,2018-05-01T15:48:05Z,2018-05-01T15:48:05Z,"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 _GLOBAL__sub_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.",Kipa Mikhail <msnkipa@…>
13554,NULL deference exception in boost::asio::ip::tcp::resolver::results_type,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-05-01T09:27:44Z,2018-05-01T09:27:44Z,"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:
{{{#!c++
#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 
{{{#!c++
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)
{{{#!c++
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.",giacomopoz@…
13553,intersection gives wrong result,geometry,Boost 1.66.0,Boost 1.68.0,Bugs,Barend Gehrels,assigned,2018-04-30T14:04:02Z,2018-05-16T06:21:26Z,"The following polygons result in a wrong intersection:

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

polygon op1, op2;

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

result is equal to op1, while op1 is mostly outside op2.",marnix.berg@…
13551,m_storage may be used uninitialized in this function,optional,Boost 1.66.0,To Be Determined,Bugs,Fernando Cacciola,new,2018-04-30T09:02:58Z,2018-04-30T09:02:58Z,"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.",lukasz.czajczyk@…
13550,Boost foreach library trigger warning in Qt,foreach,Boost Development Trunk,To Be Determined,Patches,Eric Niebler,new,2018-04-30T06:46:44Z,2018-05-10T16:46:27Z,"Since I use [[https://github.com/KDE/clazy|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",Martin Delille <martin@…>
13549,"""Failed to register an intel toolset!"" despite ""iclvars.bat"" intel64 ran.",build,Boost 1.67.0,To Be Determined,Bugs,Vladimir Prus,new,2018-04-28T09:10:37Z,2018-04-28T09:10:37Z,"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.
",boost@…
13548,typo in documentation,Documentation,Boost 1.67.0,To Be Determined,Bugs,Matias Capeletto,new,2018-04-27T19:05:22Z,2018-04-27T19:05:22Z,"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**",howard.gleason@…
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"".",asio,Boost 1.67.0,To Be Determined,Patches,chris_kohlhoff,new,2018-04-27T15:03:14Z,2018-04-27T15:05:05Z,"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"".",boost@…
13546,"""boost\asio\placeholders.hpp"" is missing static modifiers for ""boost::arg<1>&error""...",asio,Boost 1.67.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-04-27T14:58:41Z,2018-04-27T14:58:41Z,"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.
",boost@…
13545,Missing SAL-Präfixes for windows-function-imports.,winapi,Boost 1.67.0,To Be Determined,Patches,Andrey Semashev,new,2018-04-27T14:53:45Z,2018-05-01T21:58:48Z,"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.",boost@…
13544,remove_vertex broken for adjacency_list,graph,Boost 1.66.0,To Be Determined,Bugs,Jeremiah Willcock,new,2018-04-27T12:59:47Z,2018-04-27T12:59:47Z,"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.

{{{#!c++
    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.

{{{#!c++
      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.

{{{#!c++
      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;
          }
        }
      }
}}}
",Rasmus Ahlberg <rasmus.ahlberg@…>
13543,documentation for allocation_command shows the wrong return type,interprocess,Boost 1.59.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-04-26T17:06:47Z,2018-04-26T17:06:47Z,"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.",matt.liberty@…
13539,Boost Polygon - MSVC 2017 - Ambiguous call to size() function,polygon,Boost 1.67.0,To Be Determined,Bugs,Lucanus Simonson,new,2018-04-25T10:54:09Z,2018-04-25T10:57:36Z,"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.",Kai Benndorf <kai.benndorf@…>
13538,Issue in addressof.hpp?,smart_ptr,Boost 1.67.0,To Be Determined,Support Requests,Peter Dimov,new,2018-04-25T01:19:18Z,2018-05-10T17:03:58Z,"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);",Josh <egomagickian@…>
13537,serializable unordered_map has incorrect template signature,serialization,Boost 1.67.0,To Be Determined,Bugs,Robert Ramey,new,2018-04-24T22:23:10Z,2018-04-24T22:23:10Z,"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.
",David Hawkes <daveh@…>
13535,xpressive miss captured groups name  while assign a match_results object to another.,xpressive,Boost 1.67.0,To Be Determined,Bugs,Eric Niebler,new,2018-04-23T10:48:24Z,2018-04-23T10:48:24Z,"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.
",hyd <ruoleng@…>
13534,icu support windows7 x64 failed,regex,Boost 1.67.0,To Be Determined,Bugs,John Maddock,new,2018-04-20T21:44:14Z,2018-04-20T22:22:02Z,"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
0. set PATH=c:/icu/bin64;c:/icu/bin;%PATH%
1. 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?",stoneGuard
13530,str##A##B ?,python USE GITHUB,Boost 1.67.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2018-04-20T06:34:58Z,2018-04-20T06:34:58Z,"#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”",anonymous
13526,Boost.Interprocess named_semaphore fail with C#,interprocess,Boost 1.66.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-04-17T12:49:45Z,2018-04-17T12:49:45Z,"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(?).",janmkubalek@…
13524,Parameter mismatch on make_controlled factory (incorrectly constructed controlled_runge_kutta),odeint,Boost Release Branch,To Be Determined,Bugs,karsten,new,2018-04-16T15:41:21Z,2018-04-16T15:50:13Z,"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.
",J.Saffer <j.saffer@…>
13522,Invalid empty result using boost::geometry::difference,geometry,Boost 1.66.0,To Be Determined,Bugs,Barend Gehrels,assigned,2018-04-16T09:43:01Z,2018-05-16T06:21:58Z,"Hello,

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

Code to reproduce this:

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

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

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

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

    for(int i = 0; i < 3; i++)
    {
      boost::geometry::difference(Left[i], Right[i], Left[i + 1]);
    }

Final result in Left[3] is empty.


",lehnert@…
13520,Cant add capture-by-move lambda to channel,context,Boost 1.66.0,To Be Determined,Bugs,olli,new,2018-04-15T14:06:50Z,2018-04-15T14:42:45Z,"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
",kreuzerkrieg@…
13519,Invalid result for boost::geometry::difference,geometry,Boost 1.66.0,To Be Determined,Bugs,Barend Gehrels,new,2018-04-13T15:21:42Z,2018-05-02T15:32:01Z,"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);

",lehnert@…
13517,Boost Small Container chokes MSVC+NVCC CUDA 9.1,container,Boost 1.66.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-04-12T06:36:18Z,2018-04-12T06:36:18Z,"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

1. One line program in kernel.cu

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

2. 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 ==========
",kandel3@…
13516,crash in boost regex,regex,Boost 1.63.0,To Be Determined,Bugs,John Maddock,new,2018-04-09T13:53:50Z,2018-04-09T16:21:06Z,"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.",Aron Pongo <aron@…>
13515,async_pipe::async_read_some returns zero read size if -O<something> is used,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-04-06T14:20:16Z,2018-08-01T19:59:31Z,"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.

{{{
#!div style=""font-size: 80%""
  {{{#!C++
  #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.

{{{
#!div style=""font-size: 80%""
  {{{#!C++
  pipe.async_read_some(asio::buffer(buffer), yield[read_ec]);
  }}}
}}}
starts returning 0. Buffer contents are modified though. Callback based approach yields same result.

{{{
#!div style=""font-size: 80%""
{{{
...
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",Tomasz Jonak <tjonak@…>
13514,can not build against boost 1.66.0 with MSVC 2015 due to range/concepts.hpp,range,Boost 1.66.0,To Be Determined,Bugs,Neil Groves,new,2018-04-06T13:32:57Z,2018-04-18T20:00:10Z,"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 ';'
}}}
",Mario Emmenlauer <mario@…>
13512,Starting from boost 1.67 boost build system for Intel compiler on Windows is broken.,build,Boost 1.67.0,Boost 1.67.0,Bugs,Vladimir Prus,new,2018-04-05T07:42:07Z,2018-04-05T09:15:11Z,"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.",Ivan Kelarev <ivan.kelarev@…>
13511,Boost transformation has possible bug,polygon,Boost 1.62.0,To Be Determined,Bugs,Lucanus Simonson,new,2018-04-04T18:25:58Z,2018-04-04T18:25:58Z,"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);

",asksoni@…
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.",geometry,Boost 1.61.0,Boost 1.61.0,Bugs,Barend Gehrels,new,2018-04-04T09:11:40Z,2018-04-04T09:11:40Z,"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)",sumanth.kaliki@…
13509,Boost.Asio broken link in documentation,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-04-03T15:32:27Z,2018-04-13T15:33:00Z,"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",anonymous
13507,Build issue for Boost 1.67.0 Beta 1 with Visual Studio 2017 15.6.4 and Intel Compiler 18.0.2,Building Boost,Boost 1.67.0,To Be Determined,Bugs,,new,2018-03-31T10:12:44Z,2018-03-31T10:12:44Z,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.,Jacek Blaszczyk <jacekb@…>
13506,Bootstrap.bat fails for Microsoft Visual Studio Community 15.6.4,Building Boost,Boost 1.66.0,Boost 1.66.0,Bugs,,new,2018-03-31T03:57:22Z,2018-03-31T05:03:18Z,".\bootstrap.bat fails with the following message:

cl : Command line error D8016 : '/O2' and '/RTC1' command-line options are incompatible",donald.h.ellison@…
13505,graph/detail/array_binary_tree.hpp:45:18: error: unknown template name 'iterator',graph,Boost 1.67.0,To Be Determined,Bugs,Jeremiah Willcock,new,2018-03-30T15:42:39Z,2018-03-31T10:24:28Z,"Discovered this when building [https://github.com/dealii/dealii 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. ",Denis Davydov <davydden@…>
13502,Intel compiler detection under Windows failed,predef USE GITHUB,Boost 1.67.0,To Be Determined,Bugs,René Rivera,new,2018-03-29T11:31:20Z,2018-04-04T13:47:08Z,"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",oley@…
13501,no matching function for call to 'hash_value' while compiling program with clang on osx,hash,Boost 1.64.0,To Be Determined,Bugs,Daniel James,new,2018-03-29T11:26:49Z,2018-03-29T15:25:56Z,"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);
                   ^~~~~~~~~~
}}}",travis.wrightsman@…
13499,"Intel Compiler 2018 Windows error: overloaded function ""boost::scope_exit::detail::deref"" is not a type name",scope_exit,Boost 1.65.0,To Be Determined,Bugs,Lorenzo Caminiti,new,2018-03-28T19:51:14Z,2018-05-10T16:37:00Z,"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?",Mario Emmenlauer <mario@…>
13498,Error compiling boost with Intel Compiler 2018 / Visual Studio 2015 on Windows,Building Boost,Boost 1.65.0,To Be Determined,Bugs,,new,2018-03-28T19:13:53Z,2018-04-18T19:54:59Z,"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.",Mario Emmenlauer <mario@…>
13497,‘next’ is not a member of ‘boost’ in spsc_queue.hpp in 1.67,lockfree,Boost 1.67.0,To Be Determined,Bugs,timblechmann,new,2018-03-28T14:36:55Z,2018-04-01T10:57:25Z,"/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.",Riot <rain.backnet@…>
13496,ASIO: Ability to do a synchronous read with timeout on a socket,asio,Boost 1.67.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2018-03-28T07:11:19Z,2018-03-28T07:11:19Z,"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. 
",tom@…
13495,wrong comments in newline.hpp,iostreams,Boost 1.66.0,To Be Determined,Bugs,Jonathan Turkanis,new,2018-03-28T01:00:11Z,2018-03-28T01:00:11Z,"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.",axch@…
13494,polygon intersection fails,geometry,Boost 1.66.0,To Be Determined,Bugs,Barend Gehrels,new,2018-03-27T13:21:11Z,2018-03-27T13:21:11Z,"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.",lehnert@…
13493,boost::regex doesn't accept a regular expression anymore,regex,Boost 1.66.0,To Be Determined,Bugs,John Maddock,new,2018-03-26T12:35:15Z,2018-03-26T12:35:15Z,"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.",sebastian.panek@…
13490,Compile error when BOOST_FIBERS_NO_ATOMICS is open,context,Boost 1.66.0,To Be Determined,Bugs,olli,new,2018-03-23T12:30:45Z,2018-03-23T12:30:45Z,"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'
}}}
",tdzl2003 <tdzl2003@…>
13489,boykov_kolmogorov_max_flow produces incorrect residual edge capacity,graph,Boost 1.67.0,To Be Determined,Bugs,Jeremiah Willcock,new,2018-03-22T16:26:50Z,2018-03-22T16:26:50Z,"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.",Nate Bird <nate@…>
13488,Detect ICU with pkg-config when possible in bootstrap.sh,Building Boost,Boost 1.66.0,To Be Determined,Patches,,new,2018-03-22T12:24:20Z,2018-03-22T12:25:13Z,"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.",anonymous
13487,Error detecting is_nothrow_move_constructible & is_nothrow_move_assignable,move,Boost Development Trunk,To Be Determined,Bugs,Ion Gaztañaga,new,2018-03-19T10:10:30Z,2018-03-19T11:40:38Z,"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:

{{{
#!c++
  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.",Andrey Glebov <andrey458641387@…>
13485,parent_path() edge case returns wrong result on Windows,filesystem,Boost 1.66.0,To Be Determined,Bugs,Beman Dawes,new,2018-03-17T04:56:11Z,2018-05-10T16:36:17Z,"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).


",Alex Weiss <alexweiss86@…>
13484,exists doesn't clear no_such_file_or_directory type of error codes,filesystem,Boost 1.66.0,To Be Determined,Bugs,Beman Dawes,new,2018-03-17T01:47:44Z,2018-03-17T01:47:44Z,"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.
",Alex Weiss <alexweiss86@…>
13482,"Referenced file in {.tar.gz,.tar.bz2}.json of official source distribution downloads is wrong",None,Boost 1.66.0,To Be Determined,Bugs,,new,2018-03-15T13:45:57Z,2018-09-21T09:06:51Z,"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.",t.klatt.oss+boost@…
13481,Strict aliasing is causing SIGSEGV on ARM Cortex-A15 when using GCC6,function,Boost 1.66.0,To Be Determined,Bugs,Douglas Gregor,new,2018-03-14T08:43:54Z,2018-04-04T07:41:16Z,"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 `union`s 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.",Piotr Podusowski <piotr.podusowski@…>
13477,Initializing boost::asio socket after constructor failed,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-03-13T07:24:42Z,2018-05-15T03:17:49Z,"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?",nguyen.tnhoang@…
13475,"boost_1_66_0, Windows 10, mingw-w4, bootstrap fails - cannot write AppData\Local\Temp file",build,Boost 1.63.0,To Be Determined,Bugs,Vladimir Prus,new,2018-03-12T17:31:19Z,2018-08-02T11:15:48Z,"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?",mhkelley2017@…
13474,Weighted Graphs for Betweennness Centrality,graph,Boost 1.63.0,To Be Determined,Bugs,Jeremiah Willcock,new,2018-03-11T20:59:50Z,2018-05-10T12:13:19Z,"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",abertzouanis@…
13473,asio::basic_repeating_timer broken by 1.66.0,asio,Boost 1.66.0,Boost 1.66.0,Bugs,chris_kohlhoff,new,2018-03-10T16:21:55Z,2018-03-18T09:17:25Z,"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;
",Mike Haben <michael.haben@…>
13471,Documentation warnings in Xcode 9.2,process,Boost 1.66.0,To Be Determined,Bugs,,new,2018-03-08T15:03:08Z,2018-03-08T15:03:08Z,"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
",pointerphile@…
13469,Getting lot of warnings for simple code which is using boost::Intersection,polygon,Boost 1.61.0,To Be Determined,Support Requests,Lucanus Simonson,new,2018-03-06T12:05:28Z,2018-03-06T12:05:28Z,"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;
}

}}}
",sumanth.kaliki@…
13468,asio receive buffer overwritten before handler called,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-03-06T10:47:26Z,2018-03-06T10:47:26Z,"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_;
}
",Gary Bayliss <gary.bayliss@…>
13467,RTTI issue with non-polymorphic types in debug mode,serialization,Boost 1.67.0,To Be Determined,Bugs,Robert Ramey,new,2018-03-05T18:09:14Z,2018-03-05T18:09:14Z,"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.
",jlodos@…
13466,Security vulnerability in Boost Interprocess,interprocess,Boost Development Trunk,To Be Determined,Bugs,Ion Gaztañaga,new,2018-03-05T10:16:39Z,2018-07-01T21:04:16Z,"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?",Corelogic RiskModel <riskmodel-all.india@…>
13464,Boost failed to compile test in graph lib due to the error C2499.,graph,Boost 1.63.0,To Be Determined,Bugs,Jeremiah Willcock,new,2018-03-05T02:55:29Z,2018-03-06T03:01:47Z,"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:**

1. git clone -c core.autocrlf=true --recursive https://github.com/boostorg/boost.git D:\Boost\src
2. Open a VS 2015 x86 command prompt and browse to D:\Boost\src
3. .\bootstrap
4. .\b2 headers variant=release --build-dir=..\out\Release --address-model=32
5. .\b2 variant=release --build-dir=..\out\Release --address-model=32
6. .\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 '<'",1518134125@…
13463,Boost UDP multicast sender not using correct port,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-03-04T01:12:13Z,2018-03-04T02:41:14Z,"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.",anonymous
13462,set_option: The requested address is not valid in its context,asio,Boost 1.66.0,,Bugs,chris_kohlhoff,new,2018-03-03T22:08:17Z,2018-03-03T22:08:17Z,"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?
",nguyen.tnhoang@…
13461,C++ Boost UDP multicast errors out with socket.set_option(),asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-03-03T04:30:29Z,2018-03-03T05:34:15Z,"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.",nguyen.tnhoang@…
13460,broken shared build.,program_options,Boost 1.66.0,To Be Determined,Bugs,Vladimir Prus,new,2018-03-01T10:07:53Z,2018-03-01T10:07:53Z,"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 -D'''FOOBAR'''_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.",pawels@…
13459,boost/regex/v4/perl_matcher_non_recursive.hpp infinite loop bug,regex,Boost 1.66.0,To Be Determined,Bugs,John Maddock,new,2018-02-28T15:09:26Z,2018-02-28T15:09:26Z,"== description ==
{{{   do
   {
      --position;
      --count;
      ++state_count;
   }while(count && !can_start(*position, rep->_map, mask_skip));
}}}[[br]]
It performs a continuous loop at this point.
[[br]]
== 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
}}}

",komad <tlagyqls7@…>
13456,Object tracking fails with pointer to variant's content,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,new,2018-02-24T14:06:05Z,2018-02-25T02:22:03Z,"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);
    }
}

}}}
",Ricardo Calheiros de Miranda Cosme <ricardo.cosme@…>
13454,universal 32/64 bits build broken on macOS (worked until 1.65.1),Building Boost,Boost 1.66.0,To Be Determined,Bugs,,new,2018-02-20T13:53:59Z,2018-02-22T20:35:57Z,"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
}}}

see also: https://trac.macports.org/ticket/55857",Frédéric Devernay <frederic.devernay@…>
13453,add serialize/ deserialize functionality,accumulator,Boost 1.67.0,To Be Determined,Feature Requests,Eric Niebler,new,2018-02-20T08:38:43Z,2018-02-20T08:38:43Z,"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).",Yuval Lifshitz <yuvalif@…>
13452,Use of std deprecated code in C++17 in MSCV 2017,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-02-20T06:42:09Z,2018-02-20T06:42:09Z,"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.",r.undheim@…
13450,boost_beast tests are failing on Windows with Intel's compiler due to incorrect boost_asio config.hpp file,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-02-16T09:25:57Z,2018-02-16T09:25:57Z,"{{{
$ 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
}}}
",Ivan Kelarev <ivan.kelarev@…>
13449,"Execution of boost_mpl_preprocess.py fails if $(boost_root) path contains the string ""linux""",mpl,Boost 1.63.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2018-02-15T08:59:29Z,2018-02-15T09:27:31Z,"**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
",Mihai Pop <mihaipop11@…>
13448,Json Property tree throwing error when a node has interger value greater than INT_MAX of  int32,property_tree,Boost 1.63.0,To Be Determined,Bugs,Sebastian Redl,new,2018-02-15T07:56:40Z,2018-05-10T12:08:18Z,"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""
",tejaveda.2008@…
13447,BOOST_PP_VARIADICS should be 1 for NVCC,preprocessor,Boost Development Trunk,To Be Determined,Feature Requests,No-Maintainer,new,2018-02-14T17:13:14Z,2018-06-26T22:20:50Z,"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 [https://github.com/boostorg/preprocessor/blob/develop/include/boost/preprocessor/config/config.hpp#L74 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?",Alexander Matthes <a.matthes@…>
13446,\R does not match \v and \n when combined with flag no_escape_in_lists,regex,Boost 1.66.0,To Be Determined,Bugs,John Maddock,new,2018-02-14T10:50:10Z,2018-02-14T10:50:10Z,"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
",youcef.l@…
13445,Manual entry for abs function of vector space algebra differs from implementation,odeint,Boost 1.66.0,To Be Determined,Bugs,karsten,new,2018-02-13T11:39:46Z,2018-02-13T11:39:46Z,"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.",jan@…
13444,boost::geometry::buffer returns only partial result (regression over 1.63.0),geometry,Boost 1.66.0,To Be Determined,Bugs,Barend Gehrels,assigned,2018-02-09T10:44:56Z,2018-02-17T17:53:03Z,"using boost::geometry::buffer with multilinestring, only 1 of expected 3 polygons are returned.

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

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

Version 1.63.0 returned all 3 polygons, but was also rather slow when compared with the workaround.",andre.meyer@…
13442,pmr::synchronized_pool_resource is affected by thread priority inversion,container,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-02-07T09:41:11Z,2018-02-09T17:17:32Z,"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`
",enniobarbaro@…
13441,Boos.Locale message formating exception if 'ß' used in translation file,locale,Boost 1.66.0,To Be Determined,Bugs,Artyom Beilis,new,2018-02-07T07:49:19Z,2018-02-07T07:49:19Z,"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

}}}

",mattias.eppler@…
13440,Paths to boost libraries contain colons on OS X 10.13 (xcode 9) with Intel's compiler,Building Boost,Boost 1.66.0,Boost 1.66.0,Bugs,,new,2018-02-06T14:43:35Z,2018-02-15T13:51:56Z,"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.",Ivan Kelarev <ivan.kelarev@…>
13439,boost:::filesystem:::copy_file : The File Exist,filesystem,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,new,2018-02-06T14:31:28Z,2018-02-07T06:18:33Z,"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 ",anonymous
13437,array.hpp and boost_array.hpp share the same header guard,serialization,Boost 1.66.0,To Be Determined,Bugs,Robert Ramey,new,2018-02-06T00:46:27Z,2018-02-06T01:03:22Z,"Both array.hpp and boost_array.hpp use BOOST_SERIALIZATION_ARRAY_HPP as header guard.
",christof.krueger@…
13433,b2 emits strange error message when building 1.66.0 on windows 10 against very new visual studio,build,Boost 1.66.0,To Be Determined,Bugs,Vladimir Prus,new,2018-01-31T22:08:49Z,2018-02-02T18:30:56Z,"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.",ivandavid14@…
13432,Remove RCS Tags from MPL component,mpl,Boost 1.63.0,To Be Determined,Tasks,Aleksey Gurtovoy,new,2018-01-31T21:03:56Z,2018-01-31T21:03:56Z,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.,Grayson Lang <graysonlang@…>
13431,ncurses.h and boost.asio problem,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-01-31T17:05:53Z,2018-05-22T04:13:35Z,"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.


",Adrian Rapiteanu <adrian.rapiteanu@…>
13430,boost::optional C++98 and C++11 compatability breaks in boost 1.66.0,optional,Boost 1.66.0,To Be Determined,Bugs,Fernando Cacciola,new,2018-01-30T16:20:38Z,2018-01-30T16:20:38Z,"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.",nialljosullivan@…
13429,Typo in Boost.Regex error message,regex,Boost 1.66.0,To Be Determined,Patches,John Maddock,new,2018-01-30T14:21:13Z,2018-02-11T20:11:09Z,"The attached patch fixes the typo ""uninitialzed"".",Peter Klotz <peter.klotz@…>
13428,"Windows: ""is_symlink"" for drive letter (without trailing directory separator) returns the wrong result",filesystem,Boost 1.66.0,To Be Determined,Bugs,Beman Dawes,new,2018-01-30T13:39:23Z,2018-01-30T13:39:23Z,"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}}}.",m.kosch@…
13427,Boost::binomial_heap - decrease bug,heap,Boost 1.63.0,To Be Determined,Bugs,timblechmann,new,2018-01-30T12:45:35Z,2018-01-30T12:45:35Z,"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",adtac
13426,path::concat should ideally take a value_type,filesystem,Boost 1.63.0,To Be Determined,Feature Requests,Beman Dawes,new,2018-01-30T00:36:48Z,2018-01-30T00:36:48Z,"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.",ethan@…
13425,bug in boost polygon resize,polygon,Boost 1.66.0,To Be Determined,Bugs,Lucanus Simonson,new,2018-01-29T04:15:12Z,2018-01-30T01:07:50Z,"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,
",leoyin@…
13424,incorect path separator in filesystem::weakly_canonical,filesystem,Boost 1.66.0,To Be Determined,Bugs,Beman Dawes,new,2018-01-28T22:34:18Z,2018-01-28T22:34:18Z,"On windows for this code:

path t = ""."";
cout << weakly_canonical(t) << endl;

I got:
C:/test\boost_test
",ajcekg@…
13421,"boost::polygon::euclidean_distance(segment, point) returns 0 if the segment is of length 0",polygon,Boost 1.65.0,To Be Determined,Bugs,Lucanus Simonson,new,2018-01-25T05:31:36Z,2018-01-25T05:31:36Z,"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.",daniel@…
13419,Dinkum STL requires std::sprintf() with <cstdio>,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-01-24T19:41:25Z,2018-01-24T19:41:25Z,"sprintf() used in global scope in recent update.

Corrected in https://github.com/boostorg/asio/pull/54


",Brian Kuhl <brian.kuhl@…>
13417,ASIO should support VxWorks,asio,Boost 1.66.0,To Be Determined,Patches,chris_kohlhoff,new,2018-01-23T18:37:49Z,2018-01-23T18:41:30Z,"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",Brian Kuhl <brian.kuhl@…>
13416,ASIO does not cross compile because it uses obsolete <os> vs. <target-os>,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-01-23T18:30:22Z,2018-01-23T18:40:37Z,"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 ",Brian Kuhl <brian.kuhl@…>
13415,"Every time I interact with trac for the first time, it claims my email is a sign of spam",trac / subversion,Boost 1.67.0,To Be Determined,Bugs,Douglas Gregor,new,2018-01-23T05:17:48Z,2018-01-23T05:17:48Z,"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.",Richard <legalize@…>
13414,"""Reported by me"" doesn't show my tickets",trac / subversion,Boost 1.67.0,To Be Determined,Bugs,Douglas Gregor,new,2018-01-23T05:13:23Z,2018-01-23T05:13:23Z,"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.",Richard <legalize@…>
13413,ticket urls in emails are wrong,trac / subversion,Boost 1.67.0,To Be Determined,Bugs,Douglas Gregor,new,2018-01-22T20:48:48Z,2018-01-22T20:48:48Z,"For instance

    Date: Mon, 22 Jan 2018 19:48:39 -0000

      To: undisclosed-recipients: ;
      cc: boost-bugs@lists.boost.org

    From: ""Boost C++ Libraries"" <noreply@lists.boost.org>
Reply-To: 

 Subject: Re: [Boost C++ Libraries] #13388: boost.test doesn't recognize VS 2
          017
      Re: <064.e6e39a12f4ecd2b7b4662c5b22774588@lists.boost.org>

      Id: <079.42a6af0375edd2d14082408474e705d9@lists.boost.org>
    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
",Richard <legalize@…>
13412,Boost ver1.64.0 doesnt have asio/asoiciated_allocator.hpp,asio,Boost 1.64.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-01-22T11:38:57Z,2018-05-10T12:03:37Z,"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",anonymous
13411,boost::container::small_vector move constructor/assignop not noexcept,container,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-01-21T13:03:22Z,2018-01-21T13:03:22Z,"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.",avi@…
13410,Build failure: function_template.hpp:159:33: error: called object type 'nullptr_t' is not a function or function pointer,function,Boost 1.66.0,To Be Determined,Bugs,Douglas Gregor,new,2018-01-21T06:14:53Z,2018-02-24T11:54:28Z,"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;
                    ^
}}}
",yuri <yuri@…>
13409,Logging For Static Methods At Runtime,log,Boost 1.54.0,To Be Determined,Bugs,Andrey Semashev,new,2018-01-19T14:34:06Z,2018-01-22T01:44:44Z,"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

",cranberriess89@…
13408,Boost Library Possible memory Leak,thread,Boost 1.63.0,To Be Determined,Support Requests,viboes,assigned,2018-01-19T14:30:46Z,2018-04-14T06:37:19Z,"Hi,

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


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



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


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


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

}}}

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

Thanks in advance,

Kind Regards


",anonymous
13406,Boost 1.65.1 : Boost filesystem error codes for  non existent files seems to be incorrect,filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2018-01-19T05:23:24Z,2018-01-19T06:33:53Z,"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?",sudhanshu.gupta05@…
13405,Tree-based containers have troubles with move-only types.,container,Boost 1.66.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-01-17T17:34:52Z,2018-01-17T17:40:11Z,"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.
}}}",Mikhail Kremniov <mkremniov@…>
13404,boost::container::container_detail::forward_as_tuple conflicts with std::forward_as_tuple,container,Boost 1.66.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-01-17T17:06:13Z,2018-01-17T17:06:13Z,"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?",Mikhail Kremniov <mkremniov@…>
13402,Log format JUNIT generates invalid XML files with incorrect encoding,test,Boost 1.66.0,To Be Determined,Bugs,Gennadiy Rozental,new,2018-01-17T07:46:06Z,2018-07-02T11:26:26Z,"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>
}}}
",gallien@…
13401,Specialization of consuming_buffers for null_buffers declares wrong interface,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-01-16T21:23:04Z,2018-01-16T21:23:04Z,"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",Juan Ramirez <jrami>
13400,"boost::archive::xml_iarchive Exception in destructor: ""input stream error-No error""",serialization,Boost 1.66.0,To Be Determined,Bugs,Robert Ramey,new,2018-01-16T14:09:06Z,2018-02-17T15:34:36Z,"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);

",Andrei Bryleuski <andrey-brilevskiy@…>
13399,pthread_create segfaults when program is restarted after some time,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-01-16T08:35:32Z,2018-01-16T09:14:23Z,"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
}}}



",ttomas.mikalauskas@…
13392,"deadline_timer  -> endless handler recursion, if it should have been cancelled.",asio,Boost 1.65.0,To Be Determined,Bugs,chris_kohlhoff,new,2018-01-11T10:25:23Z,2018-01-11T10:57:32Z,"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 ?",HeinrichBoost <heinrich_nbongo@…>
13391,Typo in documentation,interprocess,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-01-11T08:20:59Z,2018-01-11T08:34:21Z,"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.
",valeriykireev@…
13390,Bootstrapping Boost 1.66 fails on Windows 10 using wingw gcc,build,Boost 1.66.0,,Bugs,Vladimir Prus,new,2018-01-11T04:46:31Z,2018-01-23T00:33:21Z,"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",hepler@…
13389,rbtree_best_fit.hpp:grow() if condition error,interprocess,Boost 1.66.0,To Be Determined,Bugs,Ion Gaztañaga,new,2018-01-11T01:57:50Z,2018-01-11T01:57:50Z,"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;
  }

}}}

",jakciehan <hanchengxi0423@…>
13385,"Docs for for_each() should be clearer about forbidding ""any non-constant operation""",range,Boost 1.66.0,To Be Determined,Bugs,Neil Groves,new,2018-01-09T12:19:51Z,2018-01-09T12:19:51Z,"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.",Tony Lewis <tonyelewis@…>
13384,Captcha rejected all my attempts; ticket text lost,trac / subversion,,,Bugs,Douglas Gregor,new,2018-01-09T11:47:17Z,2018-01-17T12:08:57Z,"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?",Tony Lewis <tonyelewis@…>
13383,Doc for is_sorted() incorrectly states the predicate defaults to std::less_equal,algorithm,Boost Development Trunk,To Be Determined,Bugs,Marshall Clow,new,2018-01-09T11:32:09Z,2018-01-09T11:50:46Z,"
{{{#!cpp
#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"";
}
}}}",Tony Lewis <tonyelewis@…>
13382,Bug in polygon OR operation with collinear points,polygon,Boost 1.66.0,To Be Determined,Bugs,Lucanus Simonson,new,2018-01-08T15:14:40Z,2018-05-10T15:58:37Z,"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.",k.daloukas@…
13379,"covered_by not implemented for (Box, MultiPolygon)",geometry,Boost 1.66.0,To Be Determined,Bugs,Barend Gehrels,new,2018-01-04T14:27:36Z,2018-06-14T10:34:24Z,"If I remember correctly, Barend mentioned in some email conversation that this should actually be implemented.",Volker Schöch <vschoech@…>
13375,Crash with python 3.6 on Mac OS X 10.12 (Sierra),python USE GITHUB,Boost 1.66.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2018-01-03T11:41:51Z,2018-01-03T11:41:51Z,"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.",Hugues Talbot <hugues.talbot@…>
13374,Boykov Kolmogorov warning with float,graph,Boost 1.63.0,To Be Determined,Bugs,Jeremiah Willcock,new,2018-01-03T11:22:25Z,2018-01-03T11:22:25Z,"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",cyril.novel@…
13372,"Boost Preprocessing: compiler error: macro ""BOOST_PP_VARIADIC_ELEM_2"" requires 4 arguments, but only 2 given",preprocessor,Boost 1.64.0,To Be Determined,Bugs,No-Maintainer,new,2018-01-01T19:30:49Z,2018-01-27T09:10:21Z,"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 )

",Dmitrii B <d4qcdes@…>
13369,[Windows] Cannot handle symbolic links,filesystem,Boost 1.66.0,To Be Determined,Bugs,Beman Dawes,new,2017-12-30T07:26:05Z,2018-06-08T21:31:31Z,"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.",0x0c0ff33.1523@…
13368,consuming_buffers.hpp: parse error in template argument list,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-28T15:34:31Z,2018-05-08T10:08:21Z,"{{{
.../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

",anonymous
13367,lockfree need update,lockfree,Boost Release Branch,To Be Determined,Tasks,timblechmann,new,2017-12-26T06:50:35Z,2017-12-26T06:51:51Z,"The latest lockfree contains the fix:
https://github.com/boostorg/lockfree/commit/582b27bf0b56a64af16ceda0a275cea2c87381ad, need update the reference in boost.",PhoebeHui
13364,xxx please delete - it was my fault xxx,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-25T23:52:32Z,2017-12-26T21:30:57Z,"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?",anonymous
13363,locale not compatible(not compilable) with c++17 mode in VS2017,locale,Boost 1.66.0,To Be Determined,Bugs,Artyom Beilis,new,2017-12-24T14:56:21Z,2017-12-24T14:56:21Z,"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 
}}}
",aleksander.matveyev@…
13361,Host boost.org using HTTPS,Documentation,,To Be Determined,Tasks,Matias Capeletto,new,2017-12-24T13:56:12Z,2018-05-10T11:59:50Z,"For security reasons, it would be good if all Boost websites are hosted using HTTPS so that all traffic is encrypted and authenticated.",anonymous
13360,std::numeric_limits<multiprecision::float128> methods fail to compile in C++11 mode,multiprecision,Boost 1.66.0,To Be Determined,Bugs,John Maddock,new,2017-12-24T12:37:40Z,2017-12-28T21:16:49Z,"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; }
                                                       ^
}}}",b7.10110111@…
13359,"windows_intermodule_singleton.hpp line 118, for version 1.62 throws warning error for possible loss of data",interprocess,Boost 1.62.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-12-22T18:10:01Z,2018-05-10T11:59:21Z,"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);",anonymous
13358,boost::process on_exit fails when using multiple processes,process,Boost 1.65.0,To Be Determined,Bugs,,new,2017-12-22T15:30:28Z,2017-12-22T20:34:26Z,"
{{{
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.
",david.glesser@…
13357,boost::iterator_range<boost::counting_iterator<uint64_t>>::back() returns reference to temporary,range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2017-12-22T14:00:47Z,2017-12-22T14:02:04Z,"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).
",Mikołaj Milej <mmilej@…>
13354,xml_iarchive destructor calls abort(),serialization,Boost 1.66.0,To Be Determined,Bugs,Robert Ramey,new,2017-12-20T13:52:47Z,2018-02-17T15:31:08Z,"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.
}}}",anonymous
13353,Distance segment-box wrong result for spherical CS,geometry,Boost Development Trunk,To Be Determined,Bugs,Barend Gehrels,new,2017-12-20T13:07:53Z,2017-12-20T13:07:53Z,"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. ",Vissarion Fisikopoulos <fisikop@…>
13352,1.66 i686-w64-mingw32-g++-win32,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-19T15:19:04Z,2018-02-13T21:18:28Z,"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.

",Martin Kjær Jørgensen <mkj@…>
13350,build error non_blocking_io,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-19T10:11:08Z,2017-12-19T10:11:08Z,"build error, no find boost::asio::socket_base::non_blocking_io

error C2039: “non_blocking_io”: 不是“boost::asio::socket_base”的成员",iewj <iewj@…>
13349,sregex not thread-safe when copied,xpressive,Boost 1.64.0,To Be Determined,Bugs,Eric Niebler,new,2017-12-18T15:44:34Z,2017-12-18T15:44:34Z,"The following code does fail about every other execution:

{{{
#!c++

#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;
}

}}}",wave@…
13346,SFINAE-friendly range_value,range,Boost 1.62.0,To Be Determined,Feature Requests,Neil Groves,new,2017-12-17T19:53:47Z,2017-12-17T19:53:47Z,"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.",marc.glisse@…
13345,Possible misses of comma operator,array,Boost 1.65.0,To Be Determined,Bugs,Marshall Clow,new,2017-12-17T14:08:58Z,2018-05-10T19:56:17Z,"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)",dev@…
13342,Support out-of-tree builds,Building Boost,Boost 1.63.0,To Be Determined,Bugs,,new,2017-12-14T10:46:55Z,2017-12-14T10:46:55Z,"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).",tdhutt@…
13340,ptr_vector::c_array is not compiling when boost::nullable is used.,ptr_container,Boost 1.62.0,To Be Determined,Bugs,Thorsten Ottosen,new,2017-12-14T10:15:13Z,2017-12-14T10:15:13Z,"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] );
}}}



",przemek.wos@…
13339,boost::filesystem segfaults under simple use...,filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-12-14T00:58:54Z,2017-12-14T00:58:54Z,"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""",Robert H Whitcher <robert@…>
13338,checked_delete问题,utility,Boost 1.65.0,To Be Determined,Bugs,No-Maintainer,new,2017-12-13T08:50:05Z,2017-12-13T08:50:05Z,"环境：
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);  
}  
",linzhongzi@…
13337,io_service::stop() behavior on MSVC contradicts documentation,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-12T11:10:01Z,2017-12-12T11:10:39Z,"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:


{{{
#!cpp
#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 [https://wandbox.org/permlink/N02wy78yFGX1eJRl GCC] but ""1 2 3"" on [http://rextester.com/FHNW43260 MSVC]

This bug was concretized by an Stack Overflow user while he investigated #13317.
See [https://stackoverflow.com/a/47733861/4999407 his answer] for more information.",Diego Barrios Romero <eldruin@…>
13336,vs2013 build my project with so many boost header errors,mpl,Boost 1.65.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2017-12-12T09:39:16Z,2018-05-10T11:10:56Z,"错误	1809	error C2628: “boost::mpl::intunsigned”后面接“char”是非法的(是否忘记了“;”?)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	43	1	libccm_cppbase.a
错误	1810	error C2226: 语法错误 : 意外的“boost::mpl::intunsigned”类型	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	44	1	libccm_cppbase.a
错误	1811	error C2143: 语法错误 : 缺少“;”(在“{”的前面)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	44	1	libccm_cppbase.a
错误	1812	error C2447: “{”: 缺少函数标题(是否是老式的形式表?)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	44	1	libccm_cppbase.a
错误	1813	error C2039: “intunsigned”: 不是“boost::mpl”的成员	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	1814	error C2144: 语法错误:“char”的前面应有“;”	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	1816	error C2143: 语法错误 : 缺少“;”(在“<”的前面)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	1817	error C2988: 不可识别的模板声明/定义	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	1818	error C2059: 语法错误:“<”	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	1819	error C2039: “value”: 不是“`global namespace'”的成员	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	1820	error C2143: 语法错误 : 缺少“;”(在“}”的前面)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	88	1	libccm_cppbase.a
错误	1821	error C2143: 语法错误 : 缺少“;”(在“:”的前面)	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	88	1	libccm_cppbase.a
错误	1822	error C2334: “:”的前面有意外标记；跳过明显的函数体	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	88	1	libccm_cppbase.a
错误	1823	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
错误	1824	error C2059: 语法错误:“return”	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	117	1	libccm_cppbase.a
错误	1825	error C2238: 意外的标记位于“;”之前	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	117	1	libccm_cppbase.a
错误	1826	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
错误	1827	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
错误	1828	error C2270: “raw_name”: 非成员函数上不允许修饰符	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	121	1	libccm_cppbase.a
错误	1829	error C2065: “data_”: 未声明的标识符	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	123	1	libccm_cppbase.a
错误	1830	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
错误	1831	error C1903: 无法从以前的错误中恢复；正在停止编译	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	129	1	libccm_cppbase.a
错误	2732	error C2628: “boost::mpl::intunsigned”后面接“char”是非法的(是否忘记了“;”?)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	43	1	libccm_cppbase.a
错误	2733	error C2226: 语法错误 : 意外的“boost::mpl::intunsigned”类型	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	44	1	libccm_cppbase.a
错误	2734	error C2143: 语法错误 : 缺少“;”(在“{”的前面)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	44	1	libccm_cppbase.a
错误	2735	error C2447: “{”: 缺少函数标题(是否是老式的形式表?)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	44	1	libccm_cppbase.a
错误	2736	error C2039: “intunsigned”: 不是“boost::mpl”的成员	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	2737	error C2144: 语法错误:“char”的前面应有“;”	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	2739	error C2143: 语法错误 : 缺少“;”(在“<”的前面)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	2740	error C2988: 不可识别的模板声明/定义	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	2741	error C2059: 语法错误:“<”	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	2742	error C2039: “value”: 不是“`global namespace'”的成员	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	85	1	libccm_cppbase.a
错误	2743	error C2143: 语法错误 : 缺少“;”(在“}”的前面)	D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp	88	1	libccm_cppbase.a
错误	2744	error C2143: 语法错误 : 缺少“;”(在“:”的前面)	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	88	1	libccm_cppbase.a
错误	2745	error C2334: “:”的前面有意外标记；跳过明显的函数体	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	88	1	libccm_cppbase.a
错误	2746	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
错误	2747	error C2059: 语法错误:“return”	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	117	1	libccm_cppbase.a
错误	2748	error C2238: 意外的标记位于“;”之前	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	117	1	libccm_cppbase.a
错误	2749	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
错误	2750	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
错误	2751	error C2270: “raw_name”: 非成员函数上不允许修饰符	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	121	1	libccm_cppbase.a
错误	2752	error C2065: “data_”: 未声明的标识符	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	123	1	libccm_cppbase.a
错误	2753	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
错误	2754	error C1903: 无法从以前的错误中恢复；正在停止编译	D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp	129	1	libccm_cppbase.a
",anonymous
13335,"When using unix domain socket (boost::asio::local::stream_protocol), synchronous write may not respond sometimes on macOS",asio,Boost 1.65.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-11T06:48:39Z,2017-12-11T06:48:39Z,"In very intermittent situations, synchronous write does not wake up in the following situations:

1. The server application uses a unix domain socket and accepts and reads asynchronously.
2. 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).''",seungrye@…
13334,MSVC ARM64,Building Boost,Boost 1.65.0,To Be Determined,Feature Requests,,new,2017-12-08T19:16:56Z,2017-12-08T19:16:56Z,"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.",Simon Richter <Simon.Richter@…>
13333,Child processes started with boost::process have incorrect argv if executable path contains spaces,process,Boost 1.65.0,To Be Determined,Bugs,,new,2017-12-08T16:54:21Z,2018-03-04T19:24:18Z,"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.",Jonathan Jaloszynski <Jon_Jaloszynski@…>
13332,Boost 1.65.1 seems to be missing boost graph fixes from 1.64,graph,Boost 1.65.0,To Be Determined,Bugs,Jeremiah Willcock,new,2017-12-08T11:02:48Z,2018-05-10T14:17:11Z,"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?",jckooijman@…
13330,IMM架构输入法的ime中引入filesystem模块，导致xp上无法加载ime,filesystem,Boost 1.62.0,To Be Determined,Bugs,Beman Dawes,new,2017-12-07T10:35:24Z,2017-12-07T10:35:24Z,"在输入法工程中引入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",376098946@…
13329,BOOST_ASIO_ENABLE_CANCELIO must be globally defined,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-06T19:23:40Z,2017-12-06T19:23:40Z,"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():

{{{
#!C++
    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:

{{{
#!C++
#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.
",Mario Klebsch <mario@…>
13328,"transitive_reduction.hpp in the Graph component contains two lines that use ""not"" instead of ""!""",graph,Boost 1.65.0,To Be Determined,Bugs,Jeremiah Willcock,new,2017-12-06T13:48:33Z,2017-12-06T13:48:33Z,"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] ) {
",cjfred01@…
13327,Issue with boost::property_tree::ptree inside lambda with a capture using Visual Studio 2017,property_tree,Boost 1.63.0,To Be Determined,Bugs,Sebastian Redl,new,2017-12-06T10:11:34Z,2017-12-06T10:11:34Z,"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.",shubham.srivastava@…
13326,linking with program_options has unresolved symbols on MSVC,program_options,Boost 1.65.0,To Be Determined,Bugs,Vladimir Prus,new,2017-12-06T09:59:32Z,2018-07-07T11:57:52Z,"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?",Mario Emmenlauer <mario@…>
13325,"boost::numeric::odeint::dense_output_runge_kutta call a non-existign function ""resize""",odeint,Boost 1.65.0,To Be Determined,Bugs,karsten,new,2017-12-05T00:25:46Z,2017-12-05T00:25:46Z,"I failed the compile of the following code.

{{{
#!div style=""font-size: 80%""
source:
  {{{#!c++
#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;
}
  }}}
}}}
{{{
#!div style=""font-size: 80%""
output:
  {{{#!c++
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.

{{{
#!div style=""font-size: 80%""
boost/numeric/odeint/stepper/dense_output_runge_kutta.hpp
  {{{#!c++
    //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?
    }
  }}}
}}}

",Koichi
13324,not able to link the path to some files of boost library like boost::interprocess::detail has not been declared,interprocess,Boost 1.53.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-12-04T22:45:50Z,2017-12-04T22:45:50Z,"
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. ",kartikay1110@…
13323,Passing a vector of arguments to boost::process (boost::fusion),process,Boost 1.65.0,To Be Determined,Bugs,,new,2017-12-04T14:57:30Z,2018-05-10T11:09:26Z,"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);`.
",jpo38 <jean.porcherot@…>
13322,boost::process reports ERROR_INVALID_HANDLE instead of ERROR_FILE_NOT_FOUND when program cannot be found,process,Boost 1.65.0,To Be Determined,Bugs,,new,2017-12-04T11:33:58Z,2018-05-10T11:09:08Z,"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;
}

}}}",jpo38 <jean.porcherot@…>
13321,boost::process: executable extension is required to create a process.,filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-12-04T11:29:49Z,2017-12-05T07:15:06Z,"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 """").",jpo38 <jean.porcherot@…>
13320,It would be nice if boost::process could provide an API to get all running processes,process,Boost 1.65.0,To Be Determined,Feature Requests,,new,2017-12-04T11:21:21Z,2018-05-10T11:08:38Z,"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
    }

}}}",jpo38 <jean.porcherot@…>
13319,Boost.Asio.SSL write_some cause 'decryption failed or bad record mac' on large (~1MB) transmissions,asio,Boost 1.65.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-04T09:38:35Z,2017-12-04T09:38:35Z,"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:
1.	User application calls boost::asio::ssl::stream::write_some operation and gives it the buffer with initial data.
2.	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.
3.	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.
4.	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.
5.	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.
6.	In our case normally the Open SSL just want to send the portion of encrypted data.
7.	The detail::io execute the case engine::want_output:. It calls boost::asio::write(next_layer, core.engine_.get_output(core.output_buffer_), ec);
8.	This function read the encrypted data from OpenSSL buffer and transmit it using usual boost write operation.
9.	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.
10.	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.
11.	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.
12.	The reason of why write operation can send not the entire encrypted portion (16KB) is the following:
a.	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. 
b.	In this case the socket operation has the following options
i.	Block in send operation in case of blocking socked
ii.	Return “would block” error in case of nonblocking socket.
c.	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.
",Andrey Borisov <andrey.borisov@…>
13318,key_of_value now changes the type in the priority comparison for intrusive::treap_set,intrusive,Boost 1.65.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-12-04T08:03:30Z,2017-12-04T23:55:03Z,"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);
}
}}}
",Jan Martin Mikkelsen <janm@…>
13317,io_service behaviour difference between ubuntu and msvc-14,asio,Boost 1.62.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-12-01T16:54:35Z,2017-12-12T11:14:07Z,"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?",Diego Barrios Romero <eldruin@…>
13314,warning in graph/transitive_closure.hpp,graph,Boost 1.63.0,To Be Determined,Bugs,Jeremiah Willcock,new,2017-11-28T13:46:17Z,2018-05-10T11:08:17Z,"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",o.tristan@…
13313,Problem when mixing repeat with epsilon parser,spirit,Boost 1.65.0,To Be Determined,Bugs,Joel de Guzman,new,2017-11-28T02:46:24Z,2017-12-05T18:36:38Z,"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);
    }
}}}


",Sebastien Matte
13312,boost::locale::conv and secure memory buffers,locale,Boost 1.63.0,To Be Determined,Feature Requests,Artyom Beilis,new,2017-11-27T15:07:09Z,2017-11-27T15:07:09Z,"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!",Marcus Brinkmann <marcus.brinkmann@…>
13310,"boost::filesystem::exists(""."") fails on Mac OS Sierra",filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-11-23T21:42:10Z,2017-11-23T22:29:33Z,"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;
}",anonymous
13309,function_address_holder::get_module/::get implementations are not thread-safe,interprocess,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-11-22T22:33:11Z,2017-11-22T22:36:40Z,"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",Daniel Krügler <daniel.kruegler@…>
13308,Asio symbols are exported even when they should not,asio,Boost 1.64.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-11-22T09:36:26Z,2017-11-22T09:36:26Z,"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.",Jan Patera <japa@…>
13306,Bimap uses std::unary_function/std::binary_function which are removed in c++17,bimap,Boost 1.65.0,To Be Determined,Bugs,Matias Capeletto,new,2017-11-21T11:26:47Z,2017-11-21T11:26:47Z,"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.",Andy Vincent <andrew.vincent@…>
13305,memory leaks,log,Boost 1.65.0,To Be Determined,Bugs,Andrey Semashev,new,2017-11-21T08:35:05Z,2017-11-21T08:35:05Z,"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;
}
}}}

",vgtinenko@…
13298,boost_1_65_1,Building Boost,Boost 1.65.0,To Be Determined,Bugs,,new,2017-11-16T15:22:51Z,2017-12-15T07:11:33Z,"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 *'
 ",jaime.oliva@…
13297,"Coroutine-Context linker error on Cygwin, but not on Linux",context,Boost 1.65.0,Boost 1.65.0,Bugs,olli,new,2017-11-15T10:59:19Z,2017-11-15T10:59:19Z,"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!",lars@…
13296,The directory-separator indicating the root-directory incorrectly handled by lexically_normal on windows,filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-11-15T08:33:48Z,2017-11-15T08:33:48Z,"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
}}}
",peter@…
13295,Error during building boost,build,Boost 1.65.0,To Be Determined,Bugs,Vladimir Prus,new,2017-11-15T03:04:11Z,2018-05-10T11:05:00Z,"Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

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>

",anonymous
13294,Boost(1.57).Asio crashes after ssl stream is closed and stream is deleted.,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-11-13T23:17:41Z,2017-11-13T23:17:41Z,"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:

{{{#!cpp
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:
{{{#!cpp
m_stream->async_read_some(buffer, readHandler);
}}}

After that we just close the connection and remove objects:
{{{#!cpp
m_stream->shutdown(ec);                
m_stream->lowest_layer().close(ec);
}}}

Than we destroy the stream and context:
{{{#!cpp
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:

{{{#!cpp
>	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. 
",Andrey Borisov <andrey.borisov@…>
13292,Using Boost.Asio's POSIX-specific features makes programs not compile,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-11-12T15:58:57Z,2017-11-12T15:58:57Z,"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"");
}
}}}
",arsenarsentmc@…
13291,read_until won't compile with Visual Studio 2017 using regex,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-11-09T10:10:57Z,2018-05-02T10:58:16Z,"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);

}}}
",Ville-Pekka Vahteala <vahtis@…>
13289,"Generating default locale from envronment variables (LC_ALL, LANG) is in wrong order",locale,Boost 1.62.0,To Be Determined,Bugs,Artyom Beilis,new,2017-11-06T13:47:43Z,2017-11-06T14:56:36Z,"When generating locale with empty string, we infer the locale from the environment variables. The current order is

1. LC_CTYPE
2. LC_ALL
3. 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

1. LC_ALL
2. LC_CTYPE
3. LANG

The fix is trivial in the function {{{boost::locale::util::get_system_locale()}}}",Dimitrij Mijoski <dmjpp@…>
13287,Broken wchar EQUAL,test,Boost 1.65.0,To Be Determined,Bugs,Gennadiy Rozental,new,2017-11-04T22:07:01Z,2017-11-04T22:07:01Z,"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);
}

}}}",stier08@…
13286,warning C4141: 'dllexport': used more than once,serialization,Boost 1.65.0,To Be Determined,Bugs,Robert Ramey,new,2017-11-04T21:03:18Z,2018-04-30T20:39:47Z,"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;
}}}
",tsondergaard@…
13285,clang-tidy analyzer complains about uninitialized variable,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-11-03T23:19:19Z,2017-11-03T23:19:19Z,"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);
                ^
",Evgeny Televitckiy <stelek@…>
13282,Allocator compilation problems with  gcc 4.8.1,container,Boost 1.64.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-10-31T18:08:27Z,2017-10-31T18:08:27Z,"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

}}}",apmanol@…
13281,How to build with NDK,Building Boost,Boost 1.65.0,To Be Determined,Support Requests,,new,2017-10-30T19:52:23Z,2017-10-30T19:52:23Z,"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",salih.yucel@…
13278,interprocess_sharable_mutex::unlock_sharable() bug when counter is already equal to 0,interprocess,Boost 1.66.0,To Be Determined,Patches,Ion Gaztañaga,new,2017-10-27T16:10:32Z,2017-10-27T16:10:32Z,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.,arnaud.gody@…
13277,State explicitly in the docs that Boost.Containers don't allocate in the default constructor,container,Boost 1.66.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-10-27T08:14:15Z,2017-10-27T08:14:15Z,"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.",dariomt@…
13276,circular_buffer pulls in exception handling code,circular_buffer,Boost 1.65.0,To Be Determined,Bugs,Jan Gaspar,new,2017-10-26T19:08:26Z,2017-10-26T19:11:29Z,"`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.",anonymous
13275,flat_map's allocator_type constructor could potentially produce invalid output in optimization,container,Boost 1.65.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-10-25T19:49:59Z,2017-10-27T11:18:19Z,"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> >
}}}
to
{{{
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. 
",jasonliu.development@…
13274,boost.filesystem compile problem on Android,filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-10-25T08:48:40Z,2018-03-01T20:46:10Z,"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.",Berkus <berkus@…>
13273,boost.program_options compile problems on Android,program_options,Boost 1.65.0,To Be Determined,Bugs,Vladimir Prus,new,2017-10-25T08:44:11Z,2017-10-25T12:56:44Z,"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"" 
}}}",Berkus <berkus@…>
13272,boost.serialization compile problem on Android,serialization,Boost 1.65.0,To Be Determined,Bugs,Robert Ramey,new,2017-10-25T08:42:43Z,2017-10-25T12:58:00Z,"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"" 
}}}",Berkus <berkus@…>
13270,BOOST_CLASS_EXPORT(some_template<>) fails to load pointers,serialization,Boost 1.65.0,To Be Determined,Bugs,Robert Ramey,new,2017-10-23T09:13:31Z,2017-10-23T09:32:06Z,"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.",Hajo Kirchhoff <boost@…>
13269,Wrong docu for uniform_real-distribution,random,Boost 1.63.0,To Be Determined,Bugs,No-Maintainer,new,2017-10-22T19:47:20Z,2017-10-22T19:47:20Z,"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"".",Flamefire
13268,Exception thrown: write access violation.,interprocess,Boost 1.65.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-10-21T10:18:08Z,2017-10-22T00:30:49Z,"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:
1. Git clone and open ipc.sln
2. Build Develop | x64
3. 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
",wronso <wronso@…>
13267,b2 doesn't recognize ZLIB options other than ZLIB_SOURCE,Building Boost,Boost 1.65.0,To Be Determined,Bugs,Jonathan Turkanis,new,2017-10-20T13:16:09Z,2017-10-20T13:21:29Z,"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.",Shintaro Sakahara <shintaro-sakahara@…>
13265,boost atomic lib memory_order error,atomic,Boost 1.63.0,To Be Determined,Bugs,timblechmann,new,2017-10-19T11:08:26Z,2017-10-19T11:08:26Z,"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.
 ",haisql@…
13263,error in boost lockfree 1.58 documentation,lockfree,Boost 1.58.0,To Be Determined,Tasks,timblechmann,new,2017-10-17T23:39:37Z,2017-10-17T23:39:37Z,"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)",anonymous
13261,managed_shared_memory construction fail after PC-Cleaning tools were used on the machine,interprocess,Boost 1.65.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-10-13T14:33:55Z,2017-10-13T14:35:13Z,"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",m.fornaro6@…
13259,"seg fault at cleanup time, __run_exit_handlers",serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,new,2017-10-12T12:00:35Z,2017-10-12T12:00:35Z,"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.","James E. King, III"
13258,boost/archive/text_iarchive.hpp memory leaks with MFC!,serialization,Boost 1.65.0,To Be Determined,Bugs,Robert Ramey,new,2017-10-12T05:56:51Z,2017-10-12T05:56:51Z,"visual studio 2017 community edition;
boost c++, 1.65 installed through vcpkg;

reproducing steps.
1. install vcpkg; vcpkg install boost
2. create a new project with mfc shared support;
3. add #include <boost/archive/text_iarchive.hpp> to stdafx.h
4. build -> run -> exit
5. 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>
}}}
",LL L <lll@…>
13257,Log attributes passed as arguments to open_record are ignored,log,Boost 1.64.0,To Be Determined,Bugs,Andrey Semashev,new,2017-10-11T19:19:04Z,2017-10-16T12:26:31Z,"Why does boost::log::sources::basic_logger::open_record_unlocked(ArgsT const&) ignore its argument when calling boost::log::core::open_record()?

{{{
#!cpp
    /*!
     * 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.",Thomas M. Bernal <tbernal@…>
13256,regex '([|&])\1?' with backreference fails to compile if regex::nosub flag used,regex,Boost 1.58.0,To Be Determined,Bugs,John Maddock,new,2017-10-11T09:06:39Z,2017-10-11T09:08:00Z,"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",Gene Thomas <gene@…>
13253,RFC 4180 CSV separator,tokenizer,Boost 1.63.0,To Be Determined,Feature Requests,jsiek,new,2017-10-10T00:21:26Z,2017-10-10T15:38:52Z,"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:

1. Putting quotes around a field allows commas only if the initial quote is at the beginning of the field. 
2. Quotes can be embedded in a quoted field if they are repeated. For example:
{{{
field 1,""embedded """" in field 2"",field 3
}}}
3. Newlines can be embedded in a quoted field. 
4. 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. ",tom_becker@…
13252,Bootstrap.bat gcc throws compilation error (code is not c90 complilant),Building Boost,Boost 1.65.0,To Be Determined,Bugs,,new,2017-10-09T21:16:47Z,2017-11-13T18:32:08Z,"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.",carlos.federico005@…
13250,bootstrap.bat fails for toolset mingw,Building Boost,Boost 1.65.0,To Be Determined,Bugs,,new,2017-10-08T17:38:22Z,2017-10-08T17:38:22Z,"See also ticket #12997

Have successfully built several versions of boost going back about 2 years.  Each build fails until I appropriately tweak the bootstrap and config scripts.  For 1.65.1, the fix was pretty easy, requiring only a simply manual addition to 

..tools/build/src/engine/config_toolset.bat

Near the end of that script (the last toolset it checks) is mingw.  Unfortunately, jam doesn't understand toolset mingw, so the toolset needs to be set to gcc.  It doesn't work to call bootstrap.bat with gcc because then subsequent scripts assume either visual studior or msvc.   The fix is to insert the line

set ""BOOST_JAM_TOOLSET=gcc""

immediately after the line :Skip_INTEL_WIN32

then run b2 with toolset=gcc.
",Michael H Kelley <mhkelley2017@…>
13248,test_hyperexponential_distribution fails in debug builds on travis CI osx any xcode level (clang 4.2.1 for example),random,Boost 1.65.0,To Be Determined,Bugs,No-Maintainer,new,2017-10-08T11:50:07Z,2017-10-08T11:50:07Z,"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...
}}}
","James E. King, III"
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",random,Boost 1.65.0,Boost 1.66.0,Bugs,Steven Watanabe,new,2017-10-08T04:13:39Z,2017-10-10T16:10:23Z,"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...
}}}","James E. King, III"
13245,Coroutines2: Crashes Visual Studio when attached with a debugger (on Windows x86),context,Boost 1.65.0,To Be Determined,Bugs,olli,new,2017-10-04T13:50:24Z,2017-11-30T06:38:12Z,"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


",Michael Eiler <michael.eiler@…>
13243,error_category() BOOST_SYSTEM_NOEXCEPT: std_cat_( this ) {} gives warning in Visual Studio 2010,system,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-10-03T10:50:51Z,2017-10-03T10:53:08Z,"\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",anonymous
13238,Typo in Boost.Move,move,Boost Development Trunk,To Be Determined,Bugs,Ion Gaztañaga,new,2017-10-01T14:01:11Z,2017-10-03T00:49:26Z,"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
}}}
",Jerker Bäck <jerker.back@…>
13235,"Wrong ""Getting Started"" link",trac / subversion,Boost 1.63.0,To Be Determined,Bugs,Douglas Gregor,new,2017-09-29T07:56:18Z,2017-09-29T07:56:18Z,"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",anonymous
13233,address sanitize dumps error,log,Boost 1.65.0,To Be Determined,Bugs,Andrey Semashev,new,2017-09-29T03:16:34Z,2018-02-20T15:21:01Z,"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


",anonymous
13232,u32regex_replace -  None of these prototypes have callback formatter capability,regex,Boost 1.65.0,To Be Determined,Feature Requests,John Maddock,new,2017-09-28T21:08:28Z,2017-09-28T21:08:28Z,"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 );
}

}}}

",robic@…
13231,u32regex_replace()  for  std::u32string  (UTF-32) won't compile,regex,Boost 1.64.0,To Be Determined,Bugs,John Maddock,new,2017-09-27T23:24:52Z,2017-09-28T20:46:16Z,"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 ) )
	{
		// ...
	}
}}}

",robic@…
13230,_FILE_OFFSET_BITS=64 breaks compilation with Android NDK r15 and API<24,filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-09-27T18:09:30Z,2018-03-19T16:44:01Z,"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.",d.mikhirev@…
13228,argument parsing errors when unit_test_main() is called in a loop more than ones,test,Boost 1.65.0,To Be Determined,Bugs,Gennadiy Rozental,new,2017-09-21T19:54:40Z,2017-09-22T20:49:19Z,"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$
}}}",claus.klein@…
13227,exception.hpp : disable false warning C4265 given by Visual Studio,exception,Boost 1.64.0,To Be Determined,Bugs,Emil Dotchevski,new,2017-09-21T18:30:26Z,2017-09-21T18:30:26Z,"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 !


",Pascal Thomet <pthomet@…>
13225,operator != fails in classes derived from boost::rational,rational,Boost 1.64.0,To Be Determined,Bugs,Jonathan Turkanis,new,2017-09-21T14:47:48Z,2017-09-21T14:47:48Z,"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.
",Michael Hanrath <Michael.Hanrath@…>
13224,Error compiling odeint with nvcc CUDA 9 error in ublas,odeint,Boost 1.65.0,To Be Determined,Bugs,karsten,new,2017-09-21T12:44:14Z,2018-01-02T09:30:17Z,"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",jorge_221@…
13222,Documentation for header-only libraries inaccurate,Documentation,Boost 1.65.0,To Be Determined,Bugs,Matias Capeletto,new,2017-09-21T09:00:25Z,2017-09-21T09:02:27Z,"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


",Declan Moran <dec1@…>
13218,Xcode 8/9 static analyzer warning in socket_ops.ipp:2023:5: function 'strcat' is insecure. CWE-119,asio,Boost 1.65.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-09-19T21:03:31Z,2017-09-19T21:03:31Z,"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.",mark_hastings@…
13217,"remove_all(const path& p, system::error_code& ec) is not supposed to throw filesystem_error, but still can",filesystem,Boost 1.64.0,To Be Determined,Bugs,Beman Dawes,new,2017-09-19T20:17:47Z,2018-05-10T10:57:57Z,"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:
* #10380
* #12640



",Brad Spencer <bspencer@…>
13216,Failed to build Boost.Build engine,build,Boost 1.63.0,To Be Determined,Bugs,Vladimir Prus,new,2017-09-19T15:48:26Z,2018-05-10T10:57:25Z,"Failed to build Boost.Build engine.
I'm trying to build 1.64 boost in VSC2017
",anonymous
13215,Polygon union give a different result depending of the order,geometry,Boost 1.66.0,To Be Determined,Bugs,Barend Gehrels,new,2017-09-18T16:02:20Z,2017-09-25T15:57:02Z,"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:
1. We use float
2. 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.
3. Prints are made with ""%.64g"" format option of printf to avoid financial round.
4. Those polygons are counter clockwise and open, but I also test them reversed and close, it gives the same result.",flamaros.xavier@…
13214,Boost::process examples fail to compile in Visual studio 2012 Win 7,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-09-18T15:25:10Z,2018-05-10T10:57:03Z,"This ticket is related to [https://svn.boost.org/trac10/ticket/12990 #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)

",daniele.trimarchi@…
13210,Signed integer overflow in successive_shortest_path_nonnegative_weights(),graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2017-09-13T20:33:09Z,2017-09-13T20:33:09Z,"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.",grievejia@…
13209,erdos_renyi_iterator hangs when n is 1,graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2017-09-13T18:04:15Z,2017-09-13T18:04:15Z,"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. ",grievejia@…
13208,"Make boost::optional<T> trivially destructible, copyable and movable if T is",optional,,To Be Determined,Feature Requests,Fernando Cacciola,new,2017-09-13T09:59:39Z,2017-09-13T09:59:39Z,"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 [https://github.com/z33ky/trivial_optional/blob/master/optional.hpp 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.",1zeeky@…
13207,boost::spirit::istream_iterator unusable with boost::asio::ip::tcp::iostream,spirit,Boost 1.65.0,To Be Determined,Bugs,Joel de Guzman,new,2017-09-13T01:27:53Z,2017-09-17T00:23:08Z,"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?",Christoper Friedt <chrisfriedt@…>
13206,regex constructor throws regex_error for simple expression,regex,Boost 1.65.0,To Be Determined,Bugs,John Maddock,new,2017-09-12T12:01:45Z,2017-10-12T21:26:05Z,"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;
}
",Asbjørn Pedersen <ahp@…>
13205,Suurballe's algorithm for finding two edge disjoint paths in non-negatively weighted graphs would be a great addition to BGL,graph,Boost Release Branch,To Be Determined,Feature Requests,Jeremiah Willcock,new,2017-09-11T11:43:34Z,2017-09-11T11:43:34Z,"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).
",tobiaskussel@…
13204,Warning when compiling with -Wdeprecated-dynamic-exception-spec in clang,smart_ptr,Boost 1.65.0,To Be Determined,Bugs,Peter Dimov,new,2017-09-09T23:44:29Z,2017-09-09T23:44:29Z,"
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.",viboes
13203,adjacent_filtered lets the first element entry through,range,Boost Development Trunk,To Be Determined,Bugs,Neil Groves,new,2017-09-09T20:40:01Z,2017-09-09T20:40:01Z,"`adjacent_filtered` always lets the first element of the range leak through, even for a predicate that rejects that element as either argument. Eg.

{{{
#!cpp
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.
",Tony Lewis <tonyelewis@…>
13202,adjacent_filtered postcondition docs differ from behaviour,range,Boost Development Trunk,To Be Determined,Bugs,Neil Groves,new,2017-09-09T20:29:26Z,2017-09-09T20:29:26Z,"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:

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

{{{
0
1
3
5
}}}

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).",Tony Lewis <tonyelewis@…>
13201,boost::container::small_vector invalid internal capacity,container,Boost 1.65.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-09-09T02:29:48Z,2017-09-09T02:29:48Z,"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.
",DirtY.iCE.hu@…
13200,"test_new_operator, develop branch, test '(2 == T::m_new_calls)' failed",serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,new,2017-09-08T21:35:14Z,2017-09-08T21:35:14Z,"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

","James E. King, III"
13199,execvpe has not been declared,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-09-08T13:34:20Z,2017-09-08T13:34:20Z,"According to [https://linux.die.net/man/3/execvpe man] execvpe was introduced only since GLIBC v2.11.
Attaching patch for boost/process/detail/posix/executor.hpp with more accurate GLIBC check",slobodyanukma@…
13198,breadth_first_visit crashes on graphs where VertexLists is vecS,graph,Boost 1.63.0,To Be Determined,Bugs,Jeremiah Willcock,new,2017-09-07T17:04:06Z,2017-09-07T17:04:29Z,"breadth_first_search crashes if VertexLists is vecS. A minimal example is as follows:

{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!cpp
#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.",hong@…
13196,buffer produces incorrect corners from linestring with asymmetric distance strategy,geometry,Boost 1.65.0,To Be Determined,Bugs,Barend Gehrels,new,2017-09-07T11:19:22Z,2017-09-07T11:26:17Z,"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.

",jan.kleemann@…
13195,Parsing a local_date_time with a custom decimal point does not work,date_time,Boost 1.65.0,To Be Determined,Bugs,az_sw_dude,new,2017-09-05T18:43:05Z,2017-09-05T18:43:05Z,"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
",Sylvain Rosembly <sylvain.rosembly@…>
13193,multiple sockets (reuse_address) + multiple io_service = packages never received,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-09-05T14:29:28Z,2017-09-05T14:36:31Z,"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.


",rafal2@…
13191,"undefined reference error when ODR-using boost::ratio::{num,den}",ratio,Boost 1.59.0,To Be Determined,Bugs,viboes,new,2017-09-04T16:27:37Z,2017-11-03T05:30:49Z,,anonymous
13190,Boost releases do not include boost/crc.hpp changes,crc,Boost 1.65.0,To Be Determined,Bugs,Daryle Walker,new,2017-09-04T06:14:14Z,2017-09-04T06:14:14Z,"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).",dave@…
13189,copy throws exception from a function defined as noexcept,filesystem,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,new,2017-09-03T13:08:12Z,2017-11-11T15:07:31Z,"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}}}.",kukkerman@…
13188,VS2017 reports typecast error in two_bit_color_map.hpp,graph,Boost 1.65.0,To Be Determined,Patches,Jeremiah Willcock,new,2017-09-01T19:36:23Z,2017-09-01T19:36:23Z,"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));
",peter.johnson@…
13187,Getting Started guide has wrong information,Documentation,Boost 1.65.0,To Be Determined,Bugs,Matias Capeletto,new,2017-09-01T13:38:14Z,2018-05-10T10:51:38Z,"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!
",anonymous
13186,Memory leak in serialization 1.65,serialization,Boost 1.65.0,Boost 1.65.0,Bugs,Robert Ramey,new,2017-09-01T10:25:46Z,2018-06-22T01:17:59Z,"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.",anonymous
13185,serialization of null pointer fails in optimized builds,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,new,2017-08-31T23:18:18Z,2017-08-31T23:21:39Z,"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);
    }
}}}

",tyler@…
13184,child move constructor does not set _terminated member,process,Boost 1.65.0,To Be Determined,Bugs,,new,2017-08-31T15:45:35Z,2018-04-07T19:38:21Z,In 'process/include/boost/process/detail/child_decl.hpp' child move constructor does not set '_terminated' member.,helmet23
13183,boost wave fails to compile with Clang on Windows,wave,Boost 1.65.0,To Be Determined,Bugs,Hartmut Kaiser,new,2017-08-31T10:09:12Z,2017-08-31T10:11:16Z,"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",anonymous
13182,Boost.Fiber ignores lambda captures,context,Boost 1.65.0,Boost 1.65.0,Bugs,olli,new,2017-08-30T00:43:19Z,2017-08-31T10:02:15Z,"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
",Sergey Babin <axilmail@…>
13180,Loop vectorisation using boost multi_array,multi_array,Boost 1.65.0,To Be Determined,Support Requests,Ronald Garcia,new,2017-08-28T07:08:40Z,2017-08-28T07:08:40Z,"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",Nicolas Barrier <nicolas.barrier@…>
13179,geometry::covered_by and geometry::within not working for certain values,geometry,Boost 1.65.0,To Be Determined,Bugs,Barend Gehrels,new,2017-08-25T21:04:11Z,2018-06-12T20:09:08Z,"''covered_by'' and ''within'' return false even if the point is obviously located within the polygon, as the following code demonstrates:

{{{
#!c++
#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
}}}",Stanley <stanley.foerster@…>
13177,Possible loss of data warnings,geometry,Boost 1.65.0,To Be Determined,Bugs,Barend Gehrels,new,2017-08-24T21:58:45Z,2017-08-24T21:58:45Z,"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.
",anonymous
13174,boost::property_tree::read_json throws exception (see attachment),property_tree,Boost 1.64.0,To Be Determined,Bugs,Sebastian Redl,new,2017-08-22T00:38:04Z,2017-08-22T01:02:06Z,"

{{{
boost::property_tree::ptree tree;
std::stringstream ss(""{\""name\"": \""test\""}"");
boost::property_tree::read_json(ss, tree);
}}}",anonymous
13173,"""program_options"" build fail. ""boost::lambda"" is working without any problem.",program_options,Boost 1.64.0,To Be Determined,Bugs,Vladimir Prus,new,2017-08-21T19:52:22Z,2017-08-21T19:52:22Z,"
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",Yoni Shperling <yoni386@…>
13172,filesystem::directory_iterator::operator++: Function not implemented (errno not reset),filesystem,Boost 1.64.0,To Be Determined,Bugs,Beman Dawes,new,2017-08-21T18:32:24Z,2017-11-16T16:00:02Z,"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 ",Simon Warta <simon@…>
13171,Linker error when using boost::process::posix::use_vfork,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-08-21T11:41:16Z,2017-08-23T11:55:19Z,"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()}}}?",Ton van den Heuvel <tonvandenheuvel@…>
13169,Context breaks with using python jam file,context,Boost 1.65.0,To Be Determined,Bugs,olli,new,2017-08-21T01:37:13Z,2017-08-21T01:37:13Z,"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.",Gary Furnish <gfurnish@…>
13168,Boost python tutorial doesn't build.,python USE GITHUB,Boost 1.58.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2017-08-19T01:11:07Z,2017-08-19T01:44:23Z,"{{{
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"".

",aaron@…
13166,gcc static linking with LTO flag with boost filesystem fails,filesystem,Boost 1.64.0,To Be Determined,Bugs,Beman Dawes,new,2017-08-17T15:06:40Z,2018-04-18T08:46:33Z,"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
}}}
",mettbest@…
13165,inplace_ptr,smart_ptr,Boost 1.64.0,To Be Determined,Feature Requests,Peter Dimov,new,2017-08-17T10:43:35Z,2017-09-03T18:22:28Z,"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",gast128@…
13164,Unable to build Boost.Iostreams with pre-built zlib on Windows,iostreams,Boost 1.64.0,Boost 1.64.0,Bugs,Jonathan Turkanis,new,2017-08-17T10:00:42Z,2017-08-17T10:00:42Z,"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",listhex@…
13162,Sharable Lock And Upgradable Lock documentation,interprocess,Boost 1.64.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-08-14T11:10:56Z,2017-08-14T11:10:56Z,"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.",anonymous
13161,Optional vector assignment regression,optional,Boost 1.63.0,To Be Determined,Bugs,Fernando Cacciola,new,2017-08-14T06:43:17Z,2017-08-16T03:39:04Z,"{{{
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.

",popizdeh@…
13158,core dump when get parent_path in a new thread,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,new,2017-08-10T15:59:51Z,2017-08-10T16:08:31Z,"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
}}}
",jaycelq@…
13157,Failed to Install,build,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2017-08-10T03:42:39Z,2018-05-10T10:46:27Z,"Cannot install - 
in command prompt :
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0.26430.16
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

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.


",shadowflameg@…
13156,Not word boundary -  \b   vs. NOT \B are not the same,regex,Boost 1.64.0,To Be Determined,Bugs,John Maddock,new,2017-08-10T01:36:30Z,2017-08-10T01:36:30Z,"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<> '

}}}
",anonymous
13154,Error compiling pthread/thread.o on Oracle Linux with Oracle compiler and stdlib=sun-stlport,build,Boost 1.63.0,To Be Determined,Bugs,Vladimir Prus,new,2017-08-09T12:40:34Z,2017-08-10T10:41:19Z,"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

 ",maxim.kartashev@…
13153,Missing return statement in range/algorithm_ext/insert.hpp,range,Boost 1.64.0,To Be Determined,Bugs,Neil Groves,new,2017-08-09T12:24:11Z,2018-06-30T21:08:25Z,"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 )",Olivier B.
13151,Graph dominiator tree considers unvisited vertices,graph,Boost 1.64.0,To Be Determined,Bugs,Jeremiah Willcock,new,2017-08-09T10:26:12Z,2017-08-09T10:26:12Z,"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",scott.gregory.west@…
13147,Crash in boost::asio::basic_streambuf,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-08-04T06:50:09Z,2017-08-15T04:56:00Z,"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, ...);

}}}",luliu@…
13146,Precompiled lib32-msvc-12.0 binaries don't compile in VS2013 projects,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-08-02T23:06:14Z,2017-08-18T09:16:19Z,"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",komannamok@…
13145,parse_charset.hpp(304): warning C4456: declaration of 'invert' hides previous local declaration,xpressive,Boost 1.63.0,To Be Determined,Bugs,Eric Niebler,new,2017-08-02T09:03:08Z,2017-08-02T09:03:08Z,"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",Dmitry Yastrebkov <yastrebkov@…>
13144,Hinted overloads of boost::container::flat_map::insert_or_assign are uncompilable,container,Boost 1.64.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-08-01T18:37:22Z,2017-08-01T18:37:22Z,"`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.",Constantin Makshin <cmakshin@…>
13143,boost read_json throw exception when the json file has some gbk chinese charactor,property_tree,Boost 1.64.0,To Be Determined,Bugs,Sebastian Redl,new,2017-08-01T02:47:29Z,2017-08-01T02:51:09Z,"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""
",Li Da <sculida@…>
13142,circle_formation_functor call has no effect?,polygon,Boost 1.64.0,To Be Determined,Bugs,Lucanus Simonson,new,2017-07-29T20:25:40Z,2017-07-29T20:39:13Z,"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?",nkurtov@…
13141,Allow intrusive containers to work with relative pointers (ie with nodes stored in a vector),intrusive,Boost 1.64.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-07-28T05:23:14Z,2017-07-28T05:23:14Z,"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.",fdegros@…
13140,Quadratic complexity of a flat_set constructor,container,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-07-28T00:53:15Z,2017-08-08T01:36:20Z,"The documentation of [http://www.boost.org/doc/libs/1_64_0/doc/html/boost/container/flat_map.html#boost.container.flat_mapconstruct-copy-destruct 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`.
",victor.zverovich@…
13139,child::join() incorrectly throws `waitpid(2) failed: No child processes` if child exited abnormally,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-07-27T19:46:16Z,2017-07-27T19:46:16Z,"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()`.",keithb@…
13138,bootstrap.bat throws an error,build,Boost 1.64.0,Boost 1.64.0,Support Requests,Vladimir Prus,new,2017-07-27T10:59:40Z,2018-01-23T00:20:51Z,"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.",oranzohar@…
13137,"boost::optional::operator*() doesn't have ""const &&"" overload, allowing incorrect usage",optional,Boost 1.65.0,To Be Determined,Bugs,Fernando Cacciola,new,2017-07-26T06:00:30Z,2017-07-31T04:07:55Z,"{{{
#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 &&;
}}}
[http://en.cppreference.com/w/cpp/utility/optional/operator* overload], which lets the code above work correctly.",for.gcc.bugzilla@…
13136,Regression: intrusive::unordered_set::rehash now requires T to be hashable,intrusive,Boost 1.64.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-07-25T19:45:13Z,2017-07-26T01:13:16Z,"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`.",gromer@…
13135,boost::filesystem::exists silently fails to work on MSVC with newly created symlink,filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-07-25T09:09:54Z,2017-07-25T09:09:54Z,"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.",Antony Polukhin
13134,Warnings about the use of 0 as null pointer constant.,core,Boost Development Trunk,To Be Determined,Bugs,Peter Dimov,new,2017-07-24T22:55:36Z,2017-07-24T22:55:36Z,"`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, `ifdef`ing on `BOOST_NO_CXX11_NULLPTR`. Shall I create a PR?",kot.tom97@…
13133,"copy_file does not check file type, can fill disk or hang program if used on certain file types",filesystem,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,new,2017-07-24T21:12:13Z,2017-07-24T21:12:13Z,"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.",Ryan Patton <rjp2@…>
13132,process_event called upon initial on_entry does not wait for on_entry completion.,msm,Boost 1.64.0,To Be Determined,Bugs,Christophe Henry,new,2017-07-23T19:05:29Z,2017-07-23T19:05:29Z,process_event called during initial on_entry does not wait for on_entry completion.,Janusz Piwowarski <jpiw@…>
13131,move_if_not_lvalue_reference undefined under BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE,move,Boost 1.60.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-07-21T17:03:02Z,2017-07-21T22:05:21Z,"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.",ryan.johnson@…
13130,BOOST_LOCKFREE_CACHELINE_BYTES value is incorrect on s390x,lockfree,Boost 1.63.0,To Be Determined,Bugs,timblechmann,new,2017-07-21T16:40:28Z,2017-09-20T11:56:13Z,"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.",mike.munday@…
13128,boost asio does not initialize libressl library,asio,Boost 1.64.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-07-19T22:39:40Z,2018-05-15T20:06:52Z,"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)
}}}",ioan pomian <ipomian@…>
13127,out of bound memory access in integer_sort,sort,Boost 1.64.0,To Be Determined,Bugs,Paul A. Bristow,new,2017-07-17T05:26:37Z,2017-07-17T05:26:37Z,"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().
",Jie HE <jie.he.cn@…>
13125,parse_config_file silently ignores IO errors,program_options,Boost Release Branch,To Be Determined,Bugs,Vladimir Prus,new,2017-07-16T12:21:46Z,2017-07-16T12:44:09Z,"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:

{{{#!c++
#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
}}}",Johannes Spangenberg <johannes.spangenberg@…>
13123,So confused on building boost.,build,Boost 1.64.0,To Be Determined,Support Requests,Vladimir Prus,new,2017-07-16T06:32:20Z,2017-07-30T18:26:25Z,"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!]",scubaventure101@…
13122,Four statics from containers_fwd.hpp should be constexpr,container,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-07-14T13:34:24Z,2017-07-14T13:34:24Z,"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'.
",robert.mcmillan@…
13121,std_fenced_block gets used for g++ 4.6.4 and hence buggy std::atomic_thread_fence,asio,Boost 1.64.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-07-13T10:52:36Z,2017-08-09T20:47:58Z,"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.
",Richard Hazlewood <boost@…>
13120,optional o<size_t>.  x<(size_t)0 is different to x<0,optional,Boost 1.64.0,To Be Determined,Bugs,Fernando Cacciola,new,2017-07-12T08:13:11Z,2017-07-12T15:45:59Z,"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.
",harris.pc@…
13119,Boost::binomial_heap Merge memcheck error - Merging 9 into 5,heap,Boost 1.64.0,To Be Determined,Bugs,timblechmann,new,2017-07-11T19:22:34Z,2017-07-11T19:22:34Z,"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.
",jun.kudo@…
13118,"boost.locale, Windows, x64 build: linker looks for ICU libraries in wrong folder (/lib instead of /lib64)",locale,Boost 1.64.0,To Be Determined,Bugs,Artyom Beilis,new,2017-07-11T05:41:55Z,2017-07-11T05:41:55Z,"When building all of boost (64 bit) with ICU, locale fails to link to ICU libs, while other libraries, regex included, succeed.[[BR]]
Accidently creating a copy of <ICU_root>/lib64/ into <ICU_root>/lib/ resolved the issue.[[BR]]
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).
",zhivkot@…
13117,BTC CODE REALISER BIOT,Building Boost,Boost Release Branch,Boost 1.65.0,Library Submissions,,new,2017-07-11T02:19:40Z,2017-07-15T17:19:38Z,,Vadim Kozhukhovskiy
13116,BTC CODE REALISER,result_of,Boost Release Branch,Boost 1.65.0,Bugs,Daniel Walker,new,2017-07-11T01:36:42Z,2017-07-11T01:36:42Z,,Vadim Kozhukhovskiy <smens50@…>
13114,Multiple signatures for function,function,Boost 1.63.0,To Be Determined,Feature Requests,Douglas Gregor,new,2017-07-10T18:09:48Z,2017-07-10T18:09:48Z,"I am not familiar with boost, just wanted to suggest the possibility of having `function` take multiple signatures

{{{#!c++
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

{{{#!c++
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.",stinkingmadgod@…
13113,"OperationalError: could not extend file ""base/19263/19289"": No space left on deviceHINT:  Check free disk space.",trac / subversion,Boost 1.63.0,To Be Determined,Bugs,Douglas Gregor,new,2017-07-10T18:07:26Z,2017-08-15T08:27:12Z,"==== 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.

}}}",anonymous
13112,uninitialized pointer fields in asio epoll_reactor,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-07-07T14:57:46Z,2017-07-07T14:57:46Z,"
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}


}}}
",ben@…
13111,Out-of-bounds access for asio consuming buffers,asio,Boost 1.66.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-07-07T14:37:53Z,2017-07-07T14:37:53Z,"
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  }

…

}}}
",ben@…
13110,cannot wait/join process to actually terminate after calling child::terminate,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-07-07T09:04:57Z,2017-07-07T09:04:57Z,"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.",Christian Maaser <boost@…>
13107,Include guards missing in range/iterator_range_hash.hpp,range,Boost 1.63.0,To Be Determined,Bugs,Neil Groves,new,2017-07-05T16:48:47Z,2017-07-05T16:48:47Z,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>&)`,Petr Kmoch <petr.kmoch@…>
13105,Add missing top level include guards,function,Boost 1.64.0,To Be Determined,Bugs,Douglas Gregor,new,2017-07-03T20:56:21Z,2017-07-03T20:56:21Z,"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)",anonymous
13103,Documentation: Line-by-line I/O example should use asio,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-06-30T08:50:17Z,2017-06-30T08:50:17Z,"The boost::process Tutorial needs some improvements:

When following the example ""[http://www.boost.org/doc/libs/1_64_0/doc/html/boost_process/tutorial.html#boost_process.tutorial.io Synchronous I/O]"" the output may be incomplete. Actually, this is even stated in the [http://www.boost.org/doc/libs/1_64_0/doc/html/boost_process/faq.html#boost_process.faq.closep 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();

};
}}}


",joshua.hopp@…
13102,Executable not relinking if related static libraries are changed.,build,Boost 1.63.0,To Be Determined,Bugs,Vladimir Prus,new,2017-06-28T07:16:03Z,2018-01-23T00:05:10Z,"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.",Uttkarsh
13101,multiplication overflow issue,rational,Boost 1.63.0,To Be Determined,Feature Requests,Daryle Walker,new,2017-06-27T20:34:04Z,2017-07-30T18:25:27Z,"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.
",Robert Ramey
13100,How can I post move only handler?,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-06-27T08:22:41Z,2017-06-27T08:22:41Z,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.,136002018@…
13099,How about adding BOOST_CONSEXPR to functions in rational where appropriate,rational,Boost 1.63.0,To Be Determined,Feature Requests,Daryle Walker,new,2017-06-26T18:02:30Z,2017-06-27T08:53:38Z,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.,Robert Ramey
13098,geometry::touches return wrong result on two polygons,geometry,Boost 1.63.0,To Be Determined,Bugs,Barend Gehrels,new,2017-06-26T16:28:51Z,2017-10-12T11:01:20Z,"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);
}}}
",bruno.deligny@…
13096,boost::geometry::intersection results depend on polypoints inputorder,geometry,Boost 1.64.0,To Be Determined,Bugs,Barend Gehrels,new,2017-06-26T11:59:02Z,2017-06-26T12:36:32Z,"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;
}
}}}
",kle@…
13092,"Serializing pointer makes sanitizer complain about ""reference binding to misaligned address""",serialization,Boost 1.63.0,To Be Determined,Bugs,Robert Ramey,new,2017-06-23T08:48:25Z,2017-08-11T12:41:00Z,"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.
",fiesh@…
13089,Boost::binomial_heap Sanity check error,heap,Boost 1.64.0,To Be Determined,Bugs,timblechmann,new,2017-06-20T18:00:21Z,2017-06-20T18:30:04Z,"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);
}
}}}

",jun.kudo@…
13088,Boost::binomial_heap Merge memcheck error,heap,Boost 1.64.0,To Be Determined,Bugs,timblechmann,new,2017-06-20T17:46:01Z,2017-06-20T17:46:01Z,"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.
",jun.kudo@…
13087,Boost::binomial_heap Merge error,heap,Boost 1.64.0,To Be Determined,Bugs,timblechmann,new,2017-06-20T17:27:54Z,2017-06-20T17:27:54Z,"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.
",jun.kudo@…
13086,Exception Throw -> { boost::asio::ip::tcp::aceptor * acceptor->open(); },asio,Boost 1.63.0,To Be Determined,Support Requests,chris_kohlhoff,new,2017-06-20T15:01:48Z,2017-06-20T15:01:48Z,"
{{{
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;
...
}

}}}
",ya.tarakanov.ilya@…
13085,Bad command line escaping for Windows shell,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-06-20T08:53:02Z,2017-06-20T08:58:01Z,"I'm trying to launch a command with the windows shell:

{{{
#!bash
call ""%VS140COMNTOOLS%\vsvars32.bat""
}}}
so the source is: (i have to escape the double-quotes and antislash)
{{{
#!c++
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.
}}}
",Salamandar <felix@…>
13084,boost::filesystem::exists returns false on existing pathnames on OSX systems,filesystem,Boost 1.64.0,To Be Determined,Bugs,Beman Dawes,new,2017-06-19T20:50:40Z,2017-06-19T20:50:40Z,"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:[[BR]]
reply of boost::filesystem::exists: true[[BR]]
reply of stat_exists:               true[[BR]]
reply of stream_exists:             true[[BR]]

OSX:[[BR]]
reply of boost::filesystem::exists: false[[BR]]
reply of stat_exists:               true[[BR]]
reply of stream_exists:             true[[BR]]

",fabrice.ducos@…
13083,msvc c++14 permissive- unrecognizable template declaration,Building Boost,Boost 1.64.0,To Be Determined,Bugs,,new,2017-06-19T12:21:43Z,2017-12-26T01:04:00Z,"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.
",Gunnar <LifePropertyLiberty@…>
13082,Add a way to identify the executable as a boost-test,test,Boost 1.64.0,To Be Determined,Feature Requests,Gennadiy Rozental,new,2017-06-19T08:39:36Z,2017-06-30T19:46:12Z,"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();
  }



",jan.wilmans@…
13081,Xpressive crashes in release if auto keyword used.,xpressive,Boost 1.62.0,To Be Determined,Bugs,Eric Niebler,new,2017-06-18T21:29:46Z,2017-06-18T21:31:41Z,"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).
",Evgeny Yashin <johny5.coder@…>
13078,boost::geometry::intersection between a polygon and a box produces incorrect results,geometry,Boost 1.59.0,To Be Determined,Bugs,Barend Gehrels,new,2017-06-16T18:24:56Z,2017-07-30T18:22:40Z,"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?",David R <ratchkov@…>
13076,Compilation error on MSVC2015+ on base_from_member used in a class with __declspec(dllexport),utility,Boost 1.64.0,To Be Determined,Bugs,No-Maintainer,new,2017-06-15T15:54:17Z,2017-07-02T19:51:15Z,"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.",mwu <mwu-tow@…>
13075,gzip_decompressor cannot be pushed to filtering_stream if provided with input_seekable,iostreams,Boost 1.63.0,To Be Determined,Bugs,Jonathan Turkanis,new,2017-06-15T14:46:12Z,2018-01-13T17:36:00Z,"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);",hellohee
13074,boost/mpi/detail/mpi_datatype_primitive.hpp still includes boost/serialization/detail/get_data.hpp although get_data.hpp is no longer there,mpi,Boost 1.64.0,To Be Determined,Bugs,Matthias Troyer,new,2017-06-14T15:33:44Z,2017-07-13T17:57:23Z,Not sure how this passed the build & test before release? ,anonymous
13073,boost tokenizer_functions explicit char_separator() ctor does not initialize m_output_done,tokenizer,Boost 1.54.0,To Be Determined,Bugs,jsiek,new,2017-06-14T13:35:50Z,2017-06-17T18:14:20Z,"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) { }


",jim.king@…
13072,boost::geometry::intersection different results for CCW and CW,geometry,Boost 1.64.0,To Be Determined,Bugs,Barend Gehrels,assigned,2017-06-14T10:57:24Z,2017-06-14T13:13:25Z,"Hello,[[BR]]

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


{{{

#include <boost/geometry/geometry.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/geometries/point_xy.hpp>

int main(int argc, char* argv[])
{
  typedef boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<double>, true,  false >  boost_polygon_CW_Open;
  typedef boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<double>, false, false > boost_polygon_CCW_Open;

  const std::string strPoly1( ""POLYGON((986.53314901320903 603.61376367962623, 1014.6804499149767 602.74037774442763, 1018.1411735073581 623.97665453539310, 990.14493850604447 624.49725628790509))"" );
  const std::string strPoly2( ""POLYGON((986.77183669558929 603.60635741124452, 998.79457181965154 603.23330253835934, 1002.2613711877982 623.79581100129735, 990.30090761267468 624.02156931285253))"" );

  boost_polygon_CW_Open p1_cw_open, p2_cw_open;
  boost::geometry::read_wkt(strPoly1, p1_cw_open);
  boost::geometry::read_wkt(strPoly2, p2_cw_open);
  boost::geometry::correct(p1_cw_open); // reverts order of points
  boost::geometry::correct(p2_cw_open); // reverts order of points

  std::vector<boost_polygon_CW_Open> output_cw;
  boost::geometry::intersection(p1_cw_open, p2_cw_open, output_cw); // correct: output_cw.front equals poly2

  boost_polygon_CCW_Open p1_ccw_open, p2_ccw_open;
  boost::geometry::read_wkt(strPoly1, p1_ccw_open);
  boost::geometry::read_wkt(strPoly2, p2_ccw_open);
  boost::geometry::correct(p1_ccw_open); // no modification
  boost::geometry::correct(p2_ccw_open); // no modification

  std::vector<boost_polygon_CCW_Open> output_ccw;
  boost::geometry::intersection(p1_ccw_open, p2_ccw_open, output_ccw); // incorrect: output_cw is empty!!!

  return 0;
}
}}}
",kle@…
13066,boost_1_64_0 build error,Building Boost,Boost 1.64.0,To Be Determined,Bugs,,new,2017-06-14T01:43:45Z,2017-06-14T01:43:45Z,"
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	
",anonymous
13065,boost_1_64_0 build error,Building Boost,Boost 1.64.0,To Be Determined,Bugs,,new,2017-06-14T01:43:00Z,2017-06-14T01:43:00Z,"
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	
",anonymous
13063,error C2668: 'boost::next' : ambiguous call to overloaded function,utility,Boost 1.63.0,To Be Determined,Bugs,Andrey Semashev,new,2017-06-10T02:12:42Z,2017-07-31T11:07:44Z,"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 ",Roxana
13062,LNK2019 Unresolved External Symbol in VS2015 when using Boost python3 and numpy3 libraries on Windows,python USE GITHUB,Boost 1.64.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2017-06-09T10:03:35Z,2017-06-09T10:03:35Z,"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:

{{{#!c++
#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?)

See also https://stackoverflow.com/questions/44072440/lnk2019-unresolved-external-symbol-in-vs2015-when-using-boost-python3-and-numpy3 for more information",oystein@…
13059,Getting attached error when trying to use property_tree header,property_tree,Boost 1.64.0,To Be Determined,Bugs,Sebastian Redl,new,2017-06-08T09:59:03Z,2017-06-09T06:31:12Z,"/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
",yogav2009@…
13056,boost\asio\impl\read_until.hpp,asio,Boost 1.64.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-06-06T02:31:23Z,2017-06-06T02:31:23Z,"          // 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;
",xjzhang1979@…
13055,Couple doc typos,graph,Boost 1.64.0,To Be Determined,Bugs,Jeremiah Willcock,new,2017-06-04T20:24:48Z,2017-08-30T09:29:54Z,"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"".",jonroy7@…
13054,Boost Process - rdbuf() in basic_ipstream/basic_opstream -  implementation bug,process,Boost 1.64.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-06-02T21:22:01Z,2017-09-18T11:32:18Z,"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;};
                                                         ^
",radoslaw.chm@…
13053,fail to build boost.build engine,build,Boost 1.64.0,To Be Determined,Bugs,Vladimir Prus,new,2017-06-01T15:41:25Z,2017-07-30T18:21:15Z,"###
### 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 
",854976175@…
13052,iostreams visibility=hidden for non-Windows platforms,iostreams,Boost 1.64.0,To Be Determined,Bugs,Jonathan Turkanis,new,2017-06-01T12:07:49Z,2017-08-24T18:03:32Z,"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.)
",Mark M <mememory359@…>
13049,nvcc CT Error: Boost 1.64.0 & CUDA 8.0,odeint,Boost 1.64.0,To Be Determined,Bugs,karsten,new,2017-05-30T11:58:21Z,2017-06-15T12:06:03Z,"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",r.widera@…
13048,Static libraries and visibility hidden,Building Boost,Boost Development Trunk,To Be Determined,Bugs,,new,2017-05-26T18:21:46Z,2018-07-17T18:42:58Z,"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.",Mark M <mememory359@…>
13047,Program crash after calling boost::filesystem::exists,filesystem,Boost 1.65.0,Boost 1.65.0,Bugs,Beman Dawes,new,2017-05-26T11:22:12Z,2017-07-24T17:28:29Z,Everything is in the title,aminemayouf@…
13046,Program crash after calling boost::filesystem::exists,filesystem,Boost 1.65.0,Boost 1.65.0,Bugs,Beman Dawes,new,2017-05-26T11:21:58Z,2017-06-17T18:21:20Z,Everything is in the title,aminemayouf@…
13044,Failed to build Boost.Build engine.,build,Boost 1.63.0,To Be Determined,Bugs,Vladimir Prus,new,2017-05-23T10:34:51Z,2017-07-30T18:20:46Z,"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????
",vit bernatik <bernatikv@…>
13043,Serialized MPI doesn't properly handle cancellation of a request,mpi,Boost 1.62.0,To Be Determined,Bugs,Matthias Troyer,new,2017-05-22T17:12:00Z,2017-06-05T13:24:20Z,"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;
}
}}}",Mike Willaims <michael.williams@…>
13042,Build errors with stdlib=sun-stlport on Linux,build,Boost 1.63.0,To Be Determined,Bugs,Vladimir Prus,new,2017-05-22T14:59:07Z,2017-06-21T11:04:51Z,"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.
",maxim.kartashev@…
13039,geometry::difference with multi_linestring and multi_polygon needs geometry.hpp to compile with MinGW/LLVM,geometry,Boost 1.63.0,To Be Determined,Bugs,Barend Gehrels,new,2017-05-19T17:30:15Z,2017-05-22T09:33:32Z,"{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!python
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.",bruno.deligny@…
13032,qvm/mat.hpp fails to compile when assign/list_of.hpp has been included first,geometry,Boost 1.64.0,To Be Determined,Bugs,Barend Gehrels,new,2017-05-15T08:36:16Z,2017-09-01T23:11:13Z,"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);
                       ^
}}}

",Michael Krause <m.krause@…>
13031,Un-deprecated boost::optional::reset(),optional,Boost 1.66.0,To Be Determined,Feature Requests,Fernando Cacciola,new,2017-05-15T08:06:51Z,2017-05-15T08:06:51Z,"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 [http://en.cppreference.com/w/cpp/utility/optional/reset form]), can it be un-deprecated in Boost?",bmerry@…
13030,Make address class and related classes to literal type,asio,Boost Development Trunk,To Be Determined,Feature Requests,chris_kohlhoff,new,2017-05-14T13:06:04Z,2017-05-14T13:06:04Z,"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.
",soorosh_abi@…
13029,Unable to build with VS2015,build,Boost 1.64.0,To Be Determined,Bugs,Vladimir Prus,new,2017-05-13T07:58:50Z,2017-07-30T18:18:14Z,"I am unable to build in windows 10 with VS2015.

bootstrap.log follows",Alexandre Gomes <alexandre.e.gomes@…>
13028,"boost::filesystem::canonical(const path& p, system::error_code& ec) throws exception",filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2017-05-12T20:18:22Z,2017-07-14T19:12:59Z,"Per [http://www.boost.org/doc/libs/1_64_0/libs/filesystem/doc/reference.html#Error-reporting 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]",Zach Wasserman <zachwass2000@…>
13025,"Segmentation fault in difference(multipoint, multilinestring)",geometry,Boost Development Trunk,To Be Determined,Bugs,Barend Gehrels,new,2017-05-11T13:39:33Z,2017-07-02T18:06:15Z,"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;
}
}}}
",Vissarion Fisikopoulos <fisikop@…>
13023,Boost_python3 prebuild binaries are not built correctly.,python USE GITHUB,Boost 1.64.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2017-05-10T22:53:33Z,2017-07-30T18:17:29Z,"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?",sergey.shandar@…
13022,Boost_python2 prebuild binaries are not built correctly.,python USE GITHUB,Boost 1.64.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2017-05-10T22:46:16Z,2017-07-30T18:17:06Z,"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.",anonymous
13021,Odeint: Eigen upgrade to v 3.3.3 breaks compatibility,odeint,Boost 1.64.0,To Be Determined,Bugs,karsten,new,2017-05-10T18:25:08Z,2017-05-10T19:00:42Z,"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.
",speku.gmt@…
13017,boost::interprocess::map compilation problem (overloading),interprocess,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-05-08T13:32:59Z,2017-07-30T18:16:33Z,"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;
};

}}}

",gjcarneiro@…
13016,small buffer optimization for bool vector or dynamic_bitset,dynamic_bitset,Boost 1.64.0,To Be Determined,Feature Requests,jsiek,new,2017-05-08T12:26:58Z,2017-05-11T12:33:46Z,"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).

see also http://stackoverflow.com/questions/7760678/is-there-a-bitset-class-thats-sized-at-instantiation-time-but-avoids-boostdy
",gast128@…
13015,"Several ""declaration hides member"" warnings in Boost random",random,Boost 1.63.0,To Be Determined,Patches,No-Maintainer,new,2017-05-08T10:00:07Z,2017-05-08T10:00:07Z,"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)
",thimo.neubauer@…
13014,buffer returns invalid geometries when used with asymmetric distances on the same side,geometry,Boost 1.62.0,To Be Determined,Bugs,Barend Gehrels,new,2017-05-08T09:20:46Z,2017-05-08T09:20:46Z,"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?",andre.meyer@…
13013,Boost upgradeable lock - simple swap include error.,interprocess,Boost 1.62.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-05-08T01:18:08Z,2017-05-08T01:18:08Z,"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> 

",sprague.a.rick@…
13010,Is there any plan to support initializer list constructor and move assign?,ptr_container,Boost 1.63.0,To Be Determined,Feature Requests,Thorsten Ottosen,new,2017-05-05T02:19:36Z,2017-05-05T02:19:36Z,Is there any plan to support initializer list constructor and move assign?I think it make sense.,wenyong.yu <136002018@…>
13008,[windows][Visual Studio compiler] Building Boost Thread with /GL causes leak in boost::thread_specific_ptr,thread,Boost 1.64.0,To Be Determined,Bugs,Anthony Williams,new,2017-05-03T20:47:35Z,2017-08-22T20:54:29Z,"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[[br]]
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.",daniel.kruegler@…
13007,"When BOOST_BIND_NO_PLACEHOLDERS is defined, framework.ipp seems to be missing an #include",test,Boost 1.64.0,Boost 1.65.0,Bugs,Raffi Enficiaud,assigned,2017-05-03T18:12:22Z,2017-07-07T21:22:41Z,"Like the summary says, I think boost/test/impl/framework.ipp should simply have one additional #include <boost/bind/placeholders.hpp> so it works when BOOST_BIND_NO_PLACEHOLDERS is defined.

",bspencer@…
13004,Cannot build boost 1.64 with Visual Studio 2015 command prompt when Visual Studio 2017 is installed,Building Boost,Boost 1.64.0,To Be Determined,Bugs,,new,2017-05-03T13:31:17Z,2017-05-03T13:31:17Z,"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.",mgr2000@…
13000,Please use BOOST_NOEXCEPT_OR_NOTHROW,system,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,new,2017-05-01T01:27:12Z,2017-05-01T01:27:12Z,"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

}}}
",viboes
12998,Can't forward single-argument constructors to sinks,log,Boost 1.63.0,To Be Determined,Bugs,Andrey Semashev,new,2017-04-30T22:25:39Z,2017-04-30T22:25:39Z,"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.",steinar+boost@…
12997,bootstarp.bat MinGW failed to build boost engine,build,Boost 1.64.0,To Be Determined,Bugs,Vladimir Prus,new,2017-04-30T03:18:52Z,2017-07-30T18:16:07Z,,shirishr@…
12996,warning: 'long long' is a C++11,timer,Boost 1.64.0,To Be Determined,Bugs,Beman Dawes,new,2017-04-29T16:22:15Z,2017-10-22T12:58:31Z,"
{{{
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; }
}}}

                                          ^
",viboes
12995,Clang/C2 support,preprocessor,Boost 1.64.0,To Be Determined,Bugs,No-Maintainer,new,2017-04-29T15:02:52Z,2017-07-06T10:04:35Z,"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. ",kaba <kaba@…>
12994,Bugs in make_maximal_planar() function,graph,Boost 1.63.0,Boost 1.63.0,Bugs,-,new,2017-04-28T18:56:49Z,2018-01-05T03:20:26Z,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 ,hunglv.k52tncntt@…
12991,Could not find yacc to build JAM grammar.,Building Boost,Boost 1.64.0,To Be Determined,Bugs,,new,2017-04-26T16:44:18Z,2017-04-26T16:44:18Z,"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.",jim.mauroff@…
12990,Boost::process examples fail to compile in Visual studio 2010 Win 7,process,Boost 1.64.0,To Be Determined,Bugs,,new,2017-04-26T16:19:44Z,2017-07-30T18:15:27Z,It looks like it was developed assuming C++11.,anonymous
12988,boost::geometry::difference doesn't operate correctly when many holes are overlapping,geometry,Boost 1.63.0,To Be Determined,Bugs,Barend Gehrels,new,2017-04-25T16:11:38Z,2017-04-25T16:11:38Z,"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
",flamaros.xavier@…
12987,boost::filesystem::exists crashes,filesystem,Boost 1.64.0,To Be Determined,Bugs,Beman Dawes,new,2017-04-24T16:19:34Z,2018-01-15T10:25:13Z,"
{{{
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",Leinad
12985,missing include of array_wrapper.hpp in boost/mpi/python/serialize.hpp,mpi,Boost 1.64.0,To Be Determined,Bugs,Matthias Troyer,new,2017-04-24T07:06:08Z,2017-04-24T07:06:08Z,"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.

",abhijit.sovakar@…
12984,Impossible make coordinate transformation,geometry,Boost 1.64.0,To Be Determined,Bugs,Barend Gehrels,new,2017-04-23T18:09:42Z,2017-06-29T22:12:44Z,"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)'''));",kirill.ierusalimov@…
12982,Missing <serialization/array_wrapper.hpp> header in uBLAS files?,uBLAS,Boost Development Trunk,To Be Determined,Bugs,Gunter,new,2017-04-21T23:49:06Z,2017-08-15T13:40:45Z,"When building code using the boost library I received two error messages saying
{{{#!python
/usr/local/include/boost/numeric/ublas/storage.hpp:301:33: 
error: no member named 'make_array' in namespace 'boost::serialization'
}}}
and
{{{#!python
/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 
{{{#!c++
#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.",paul.wambergue@…
12981,Building Bjam VC14 WIN10,build,Boost 1.64.0,To Be Determined,Bugs,Vladimir Prus,new,2017-04-21T19:27:30Z,2017-04-21T19:57:53Z,"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.",anonymous
12978,wrong boost::serialization header included in ublas,uBLAS,Boost 1.64.0,To Be Determined,Bugs,Gunter,new,2017-04-18T13:48:41Z,2017-07-30T18:14:29Z,"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'
}}}",Mark.Moll@…
12975,Add map_options for managed_mapped_file (managed_open_or_create_impl_device_holder),interprocess,Boost Development Trunk,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-04-17T07:37:58Z,2017-04-17T07:37:58Z,"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",amirhakh@…
12974,Log and Asio without defined _WIN32_WINNT,asio,Boost 1.64.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-04-16T13:56:47Z,2017-04-16T15:19:29Z,"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[[BR]]
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[[BR]]
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.[[BR]]

Log use BOOST_USE_WINAPI_VERSION[[BR]]
but Asio use _WIN32_WINNT

in 
\boost\asio\detail\config.hpp [[BR]]
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.",sobolevsv@…
12973,Example in docs for optional<T&> copy constructor is wrong,optional,Boost 1.63.0,To Be Determined,Bugs,Fernando Cacciola,new,2017-04-14T21:52:55Z,2017-04-14T21:52:55Z,"In the [http://www.boost.org/doc/libs/1_63_0/libs/optional/doc/html/boost_optional/reference/header__boost_optional_optional_hpp_/detailed_semantics.html 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>`. ",barry.revzin@…
12972,converter.hpp uses std::unary_function which is removed in c++17,numeric,Boost 1.64.0,To Be Determined,Bugs,Fernando Cacciola,new,2017-04-14T21:38:02Z,2018-02-25T11:46:07Z,"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",anonymous
12967,boost::none_t should be a literal type like std::nullopt_t,optional,Boost 1.67.0,Boost 1.68.0,Bugs,Fernando Cacciola,new,2017-04-13T12:32:50Z,2018-06-14T16:21:42Z,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.,Matt Rice <citrusmoose@…>
12965,bug of [[:xdigit:]] matching,regex,Boost 1.63.0,To Be Determined,Bugs,John Maddock,new,2017-04-13T09:33:56Z,2017-08-01T18:47:40Z,"	boost::regex myRegex{ ""[[:xdigit:]]{ 1,2 }"" };//
	string s = ""\xca\xd5"";

	cout << boost::regex_match(s,myRegex) << endl;",freeman_feng@…
12963,boost::time_period::span() returns invalid period if one of the periods is not-a-date-time,date_time,Boost 1.62.0,To Be Determined,Bugs,az_sw_dude,new,2017-04-12T11:32:50Z,2017-04-12T11:32:50Z,"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.",willi.burkhardt@…
12962,user overridden cxxflags are not honored for the compilation of some libraries,Building Boost,Boost 1.63.0,To Be Determined,Bugs,,new,2017-04-12T08:42:03Z,2017-04-12T08:42:03Z,"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.",sascha.kratky@…
12959,Regex class negation,regex,Boost 1.61.0,To Be Determined,Bugs,John Maddock,new,2017-04-10T00:24:17Z,2017-08-03T17:06:48Z,"Pertains to boost::regex  
Tested on version 1.61 

Flags: Perl[[BR]]
Target string: abc092efg[[BR]]
Regex: `[^\W\D]+`[[BR]]

Function: regex_search[[BR]] 

Matches:  abc092efg[[BR]]

Should match:  092[[BR]]

Notes[[BR]]

Negative class resolution:  'Not-Not Word' AND 'Not-Not Digit'[[BR]]
The intersection of word AND digits is digits.[[BR]]

Every other regex engine does this correctly.[[BR]]
This includes Perl, PCRE, JS, C++11, Python, etc..[[BR]] 

In this engine, `[^\W\D]` matches what `[\w\d]` does.[[BR]]
`[^\W\D]` appears not to be an intersection as the operator in[[BR]]
a negative class is AND.[[BR]]

Fwiw - this behavior is seen with all negated shorthand elements of a[[BR]]
negative class, i.e. `[^\S\W]` matches all whitespace OR all word char's.[[BR]]

",robic@…
12952,Interval arithmetic: fmod produces wrong results,interval,Boost Development Trunk,To Be Determined,Bugs,Boris Gubenko,new,2017-04-06T10:57:39Z,2017-04-06T10:57:39Z,"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
",stripf@…
12951,Warning C4244 generated by packed_oarchive.hpp,mpi,Boost 1.63.0,To Be Determined,Bugs,Matthias Troyer,new,2017-04-05T16:02:20Z,2017-04-05T16:02:20Z,"{{{
#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
}}}",l.kiss@…
12950,boost::lockfree::spsc_queue::produce(Functor),lockfree,Boost 1.63.0,To Be Determined,Feature Requests,timblechmann,new,2017-04-05T10:11:55Z,2017-04-05T10:11:55Z,"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.",Oleksandr Guteniev <gutenev@…>
12947,Failed to use memory-mapped file to interprocess communications,iostreams,Boost 1.63.0,To Be Determined,Bugs,Jonathan Turkanis,new,2017-04-04T14:46:04Z,2018-04-12T08:31:36Z,"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"");

",Valeriy N. Sifurov <vsifurov@…>
12946,Definition of BOOST_ARCH_ARM does not check __aarch64__,predef USE GITHUB,Boost 1.63.0,To Be Determined,Bugs,René Rivera,new,2017-04-04T08:48:55Z,2017-10-04T04:00:59Z,"Hi

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",Sergey Shestakov <s_shestakov@…>
12939,use of boost::graph_bundle with subgraph,graph,Boost 1.60.0,To Be Determined,Bugs,Jeremiah Willcock,new,2017-03-29T02:30:41Z,2017-03-29T02:30:41Z,"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;
}}}

",ioannis.nousias@…
12934,asio ssl not support AxTLS,asio,Boost 1.63.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2017-03-25T15:24:28Z,2017-04-16T08:47:57Z,"OpenSSL too larger,but asio ssl not support AxTLS.
thanks.",iewj@…
12933,Improve Calculation of Cartesian Point Distances,geometry,Boost 1.63.0,To Be Determined,Patches,Barend Gehrels,new,2017-03-25T14:47:20Z,2017-03-26T09:46:29Z,"ISSUE:[[BR]]

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

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.",manfredweis@…
12932,"""Char >> (Literal | Sequence)"" unpacking",spirit,Boost 1.63.0,To Be Determined,Feature Requests,Joel de Guzman,new,2017-03-24T21:59:00Z,2017-12-14T17:14:20Z,"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;
}
}}}
",jetdog330@…
12929,linestring with zero points or a single point is not equal to itself,geometry,Boost 1.60.0,To Be Determined,Bugs,Barend Gehrels,new,2017-03-24T11:01:32Z,2017-03-24T11:01:32Z,"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.


{{{
#!div style=""font-size: 80%""
Example:
  {{{#!c++
#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';
}
  }}}
}}}

{{{
#!div style=""font-size: 80%""
Output:
{{{
empty == empty := 0
single_point_linestring == single_point_linestring := 0
single_point_linestring == single_point_linestring_2 := 0
}}}
}}}


{{{
#!div style=""font-size: 80%""
Expected:
{{{
empty == empty := 1
single_point_linestring == single_point_linestring := 1
single_point_linestring == single_point_linestring_2 := 1
}}}
}}}
",Michael Maier <m-maier@…>
12926,"UBSAN complains about ""left shift of negative value -4"" from boost::icl::interval_bounds::reverse_right()",ICL,Boost 1.62.0,To Be Determined,Bugs,Joachim Faulhaber,new,2017-03-23T15:39:36Z,2018-03-16T14:58:30Z,"{{{
/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

",tgrabiec@…
12925,boost::asio::ip::tcp::socket::async_read_some() changes socket to non-blocking,asio,Boost 1.60.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-03-23T09:54:12Z,2017-03-23T09:54:12Z,"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",yogevch@…
12921,Linker Error with numpy in boost/python,python USE GITHUB,Boost 1.63.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2017-03-22T12:49:15Z,2017-04-16T08:46:12Z,"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.

",niko.koester@…
12918,Spirit:extra template parameters in mini_c sample,spirit,Boost 1.63.0,To Be Determined,Bugs,Joel de Guzman,new,2017-03-20T12:04:41Z,2017-03-21T01:20:55Z,"as the following code shows,[[BR]]
'''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'''[[BR]]

{{{
#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) {}
                           .
                           .
                           .
      }
}
}}}

",lisi <942748117@…>
12917,string_ref not constructible from rvalue strings anymore,utility,Boost 1.64.0,To Be Determined,Bugs,Marshall Clow,new,2017-03-20T08:47:44Z,2017-03-22T14:27:17Z,"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.",Mathias Gaunard
12916,Network Issue,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-03-20T06:30:10Z,2017-04-29T01:55:12Z,"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?",rabindra@…
12913,Undefined behaviour in serialization library,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,assigned,2017-03-19T18:28:47Z,2017-05-04T16:12:02Z,"Hi Robert, 

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

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

}}}

Which looks like a genuine issue to me.
",John Maddock
12911,Allow u32regex_match to accept boost::string_view,regex,Boost 1.63.0,To Be Determined,Feature Requests,John Maddock,new,2017-03-17T19:54:22Z,2017-03-17T19:54:22Z,"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.",dani.user@…
12906,Add support for string_view,spirit,Boost 1.63.0,To Be Determined,Feature Requests,Joel de Guzman,new,2017-03-15T14:00:38Z,2017-11-10T18:58:03Z,"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.
",Andrey Semashev
12904,canonical fails for relative symbolic link on NTFS,filesystem,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,new,2017-03-14T16:24:57Z,2017-03-14T16:36:46Z,"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""}}}
or
 {{{""C:/Project/50_Workspace/out/x64.Debug/./audio/Test.dll""}}}
for the next loop...
",Matthias@…
12903,division by 0,polygon,Boost 1.55.0,To Be Determined,Support Requests,Lucanus Simonson,new,2017-03-14T03:23:08Z,2017-03-15T03:03:23Z,"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?",anonymous
12902,boost test labels,test,Boost 1.63.0,Boost 1.68.0,Support Requests,Raffi Enficiaud,assigned,2017-03-13T18:20:16Z,2018-06-21T05:13:35Z,"there is a tutorial about new boost test feature - the labels. 
but it is not clear how to run all tests in testsuite except those that are with a specific label.
could you help, please?",dimitry
12900,Can't compile Boost.Typeof with MSVC and flag /permissive-,typeof,Boost 1.63.0,To Be Determined,Bugs,Peder Holt,new,2017-03-13T13:28:22Z,2017-03-30T15:23:29Z,"Can't compile Boost.Typeof with VC++ 2015/2017 and compiler flag ""/permissive-""",arkadiy_s@…
12899,ERROR: Error LNK1104	cannot open file 'libboost_date_time-vc140-mt-gd-1_63.lib',Building Boost,Boost 1.63.0,To Be Determined,Bugs,,new,2017-03-11T17:00:43Z,2017-03-11T17:00:43Z,"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
",Kurt VanderKoi
12896,"[Utility] string_view's comparison operators are not marked ""constexpr""",utility,Boost 1.63.0,To Be Determined,Bugs,Marshall Clow,new,2017-03-11T05:15:48Z,2017-05-04T02:59:05Z,"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.",Zheng Luo
12895,VS 2012: zip_iterator dereference causes a compiler error,iterator,Boost 1.63.0,To Be Determined,Bugs,jeffrey.hellrung,new,2017-03-10T21:26:44Z,2017-03-30T12:54:25Z,"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).
",daniel.kruegler@…
12893,Add debug check for boost::container::string::c_str method,container,Boost 1.63.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-03-10T13:19:51Z,2017-03-10T13:19:51Z,"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:
1. std::string on MS Visual Studio 2015 is already does this check.
2. 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;
}


}}}
",Lev Sch <zorechfan@…>
12892,range/algorithm_ext/insert.hpp won't compile,range,Boost 1.63.0,To Be Determined,Bugs,Neil Groves,new,2017-03-10T08:37:50Z,2017-03-10T10:33:46Z,"Due to a missing return statement in function Container& insert( Container& on, const Range& from ), line 37.",ondrej.polacek@…
12891,boost::signals::scoped_connection is copyable and the documentation says it is not,signals,Boost 1.63.0,To Be Determined,Bugs,Douglas Gregor,new,2017-03-09T15:14:25Z,2017-03-09T15:14:25Z,"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.",thomas.sondergaard@…
12890,Misleading documentation for regex_replace,regex,Boost 1.63.0,To Be Determined,Bugs,John Maddock,new,2017-03-09T14:44:06Z,2017-03-10T10:34:40Z,"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).
",anonymous
12884,to_string(),exception,Boost 1.63.0,To Be Determined,Bugs,Emil Dotchevski,new,2017-03-06T20:16:23Z,2017-03-08T18:52:15Z,"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?",Olaf <olafvdspek@…>
12882,Boost.Log fails to build on Solaris 11.3 x86 using Developer Studio 12.5,optional,Boost 1.63.0,To Be Determined,Bugs,akrzemi1,new,2017-03-02T06:47:03Z,2017-03-02T08:52:14Z,"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.

",lcarreon@…
12880,Alignment information @ PP time,align,Boost 1.63.0,Boost 1.65.0,Feature Requests,Glen Fernandes,assigned,2017-03-01T14:42:25Z,2017-03-03T13:37:23Z,"Please add a macro that can be used for selective compilation based on the guaranteed alignment of the default allocator, i.e. something like:
https://bitbucket.org/eigen/eigen/src/d4e10456d28275c27f417efc119024749c979b7e/Eigen/src/Core/util/Memory.h",Domagoj Šarić
12879,boost::filesystem::rename could result in copy instead of rename (windows),filesystem,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2017-03-01T12:27:36Z,2017-04-16T08:41:21Z,"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.",anonymous
12875,ip::tcp::iostream flush() doesn't clear the buffer.  Neither does clear();,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-02-28T17:27:02Z,2017-04-16T09:31:26Z,"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.


",ericrsoldan@…
12873,boost.heap calls non-existing constructor of iterator_adaptor,heap,Boost 1.63.0,To Be Determined,Bugs,timblechmann,reopened,2017-02-26T20:23:02Z,2017-03-05T14:16:57Z,"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`",Bart van Merrienboer <bart.vanmerrienboer@…>
12872,icl calls set::insert with invalid iterator hint,ICL,Boost 1.63.0,To Be Determined,Bugs,Joachim Faulhaber,new,2017-02-26T08:18:28Z,2017-02-26T08:23:53Z,"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.",David Lacey <dave.lacey@…>
12871,boost::posix_time::operator<< results in heap corruption,date_time,Boost 1.59.0,To Be Determined,Bugs,az_sw_dude,new,2017-02-26T05:50:43Z,2017-03-01T11:24:44Z,"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
ntdll!RtlpBreakPointHeap+0x19:
77df7aa6 cc              int     3

'''STACK_TEXT:'''  
1e80ebd8 77d97167 a2f3581f 00000230 00000224 ntdll!RtlpBreakPointHeap+0x19
1e80ed30 77d50ef4 00000224 00000240 00000000 ntdll!RtlpAllocateHeap+0x46233
1e80edc4 77df628a 00d20000 50000163 00000224 ntdll!RtlAllocateHeap+0x14d
1e80ee24 77d96efb 00000224 a2f35aaf 00000230 ntdll!RtlDebugAllocateHeap+0xdf
1e80ef80 77d50ef4 00000224 00000230 00000000 ntdll!RtlpAllocateHeap+0x45fc7
1e80f014 6be24158 00d20000 40000060 00000224 ntdll!RtlAllocateHeap+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
",nmmreddy11@…
12870,bugs?: xpressive: xp::skip(xp::_s) does not work,xpressive,Boost 1.63.0,To Be Determined,Bugs,Eric Niebler,new,2017-02-26T04:05:24Z,2017-02-26T04:05:24Z,"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!
",shinichiro.hamada@…
12869,Getting the path of the current executable,filesystem,Boost Development Trunk,To Be Determined,Feature Requests,Beman Dawes,new,2017-02-25T12:08:01Z,2018-05-24T15:08:08Z,"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 [http://stackoverflow.com/a/34109000/1173521 this StackOverflow answer], which, according to the author, has been tested on various platforms.

Regards,
Sam",vervaeck.sam@…
12867,log library extensions,log,Boost 1.57.0,To Be Determined,Feature Requests,Andrey Semashev,new,2017-02-24T15:28:27Z,2017-11-17T12:34:41Z,"'''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: 
1.	we want to delete the log files after specific amount of time
2.	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.
",vgrinenko@…
12866,"boost::interprocess::rbtree_best_fit::deallocate() throws boost::interprocess::lock_exception, although basic_managed_memory_impl::deallocate() docs says it never throws",interprocess,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-02-24T14:06:17Z,2017-02-24T14:06:17Z,"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?",Alexey Rybalchenko <alexryba@…>
12863,some API detection #ifdefs not valid,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-02-22T20:46:40Z,2017-02-22T20:46:40Z,"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)",danalbert@…
12862,build boost with Visual Studio 2017 RC without sdk 10,Building Boost,Boost 1.63.0,To Be Determined,Bugs,,new,2017-02-22T15:24:51Z,2017-04-13T03:37:27Z,"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>
}}}
",zoruamonster@…
12859,std::string_view as token,tokenizer,Boost 1.63.0,To Be Determined,Feature Requests,jsiek,new,2017-02-20T17:00:10Z,2017-04-30T19:42:08Z,"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.",Johel Ernesto Guerrero Peña <johelegp@…>
12852,Resizing fills the circular buffer,circular_buffer,Boost 1.63.0,To Be Determined,Bugs,Jan Gaspar,new,2017-02-17T21:47:48Z,2017-02-18T20:54:09Z,"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;
}}}
",b.n.ryland@…
12841,Boost.Property_Tree Missing Include Bind Placeholders,property_tree,Boost 1.63.0,To Be Determined,Bugs,Sebastian Redl,new,2017-02-15T23:01:21Z,2017-02-16T08:48:54Z,"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)",a.huebl@…
12838,Invalid assignment in iostreams large_file_test.cpp,iostreams,Boost 1.63.0,To Be Determined,Bugs,Jonathan Turkanis,new,2017-02-14T21:40:03Z,2017-02-14T21:41:51Z,"/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) };",stephen.clamage@…
12837,Binary serialization: crash that may allow jump to attacker-controlled address,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,assigned,2017-02-14T18:11:12Z,2017-05-04T16:25:16Z,"Using afl-fuzz on some simple programs that use boost binary and xml
serialization, I have found a number of crashes and assertion failures.

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

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

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

I ran my tests on Debian Jessie amd64 with gcc version 4.9.2 (Debian 4.9.2-10).
The following revisions of modularized boost were used (the tip of each
master branch at the time of writing, as described by 'git describe --tags
--always):
{{{
config: boost-1.62.0-57-g1abc59c
core: boost-1.61.0-59-gd753d9a
move: boost-1.63.0
serialization: boost-1.61.0-57-g62bf8fc
}}}

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

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

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

{{{
FgAAAAAAAABzZXJpYWxpemF0aW9uOjphcmNoaXZlDwAECAQIAQAAAAAAAAAAAwAAAAAAAAABAAAA
AAEAAAD0/wEAAAAAAAAAAAEAAAACAAEAAAACAAAAAgAAAAAA
}}}

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

{{{
#include <fstream>
#include <vector>

#include <boost/shared_ptr.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/serialization/nvp.hpp>
#include <boost/serialization/shared_ptr.hpp>
#include <boost/serialization/vector.hpp>

struct boxed_int
{
    boxed_int() : i(0) {}
    boxed_int(int i) : i(i) {}
    int i;
    template<class Archive>
    void serialize(Archive &ar, unsigned version)
    {
        ar & BOOST_SERIALIZATION_NVP(i);
    }
};
typedef boost::shared_ptr<boxed_int> pi;

void go(std::istream &is) {
    std::vector<pi> vv;
    try
    {
        boost::archive::binary_iarchive ia(is);
        ia & vv;
    }
    catch(std::exception &e) {}
}

int main(int argc, char **argv) {
    if(argc > 1) {
        std::ifstream is(argv[1]);
        go(is);
    } else {
        go(std::cin);
    }

    return 0;
}
}}}

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

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

Thank you for taking the time to consider this issue.

--Jeff",jepler@…
12836,the function canonical invalidates a path if there is double dot between two symbolic links,filesystem,Boost 1.59.0,To Be Determined,Bugs,Beman Dawes,new,2017-02-14T15:33:56Z,2017-02-14T15:33:56Z,"Create unit test like this:

{{{
#!cpp

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.",Frantisek Boranek <fboranek@…>
12835,warnings while boost bcp,bcp,Boost 1.62.0,To Be Determined,Bugs,John Maddock,new,2017-02-13T14:21:21Z,2017-02-13T14:21:21Z,"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...........
...........
.....
...",rgoyal@…
12832,add a static histogram type,accumulator,Boost 1.61.0,To Be Determined,Patches,Eric Niebler,new,2017-02-12T20:51:21Z,2017-02-12T20:51:21Z,"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
",georg@…
12830,boost::filesystem::windows_name() ?,filesystem,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,new,2017-02-11T15:49:28Z,2017-11-14T12:10:19Z,boost::filesystem::windows_name() allows the '''?''' character when this is a dissalowed character.,anonymous
12829,Documentation of nonblocking limitations comparaed to MPI standard,mpi,Boost 1.61.0,To Be Determined,Bugs,Matthias Troyer,new,2017-02-10T16:24:19Z,2017-02-10T16:24:19Z,"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.""",thomas.ilsche@…
12828,"Fatal crash on multiple irecv with the same communicator, sender, tag",mpi,Boost 1.63.0,To Be Determined,Bugs,Matthias Troyer,new,2017-02-10T15:54:15Z,2017-02-10T15:54:15Z,"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.",thomas.ilsche@…
12827,test of numpy initialization,python USE GITHUB,Boost 1.63.0,To Be Determined,Feature Requests,Ralf W. Grosse-Kunstleve,new,2017-02-10T15:51:24Z,2018-07-23T11:06:47Z,"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",en@…
12826,Disabled SSL compression results in compile failure,asio,Boost 1.62.0,To Be Determined,Patches,chris_kohlhoff,new,2017-02-09T23:57:14Z,2018-07-23T11:05:33Z,"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 [https://svn.boost.org/trac/boost/ticket/10795 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
}}}",ecprodev@…
12825,Missing exports in numpy library,python USE GITHUB,Boost 1.63.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2017-02-09T15:59:16Z,2018-07-23T11:04:15Z,"Hi,

I think export macros are missing in numpy part of python library.

We have for example :[[BR]]
{{{
void initialize(bool register_scalar_converters=true);
}}}

I think we should have :[[BR]]
{{{void BOOST_NUMPY_DECL initialize(bool register_scalar_converters=true);}}}",en@…
12823,"Partial sort""'`--",sort,Boost 1.63.0,To Be Determined,Feature Requests,Paul A. Bristow,new,2017-02-08T17:26:02Z,2018-07-23T11:02:59Z,Please add partial sort versions (i.e. std::partial_sort counterparts).,Domagoj Šarić
12822,MSVC14u3: compiler warning,sort,Boost 1.63.0,To Be Determined,Bugs,Paul A. Bristow,new,2017-02-08T17:24:20Z,2018-07-23T10:58:22Z,"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
}}}
",Domagoj Šarić
12821,Crash in integer_sort when reverse sorting a struct,sort,Boost 1.63.0,To Be Determined,Bugs,Paul A. Bristow,new,2017-02-08T17:14:28Z,2018-07-23T11:00:52Z,"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...",Domagoj Šarić
12820,"Unsigned value type accepts negative argument""'`--",program_options,Boost 1.58.0,To Be Determined,Bugs,Vladimir Prus,new,2017-02-08T13:28:23Z,2018-07-23T10:59:35Z,"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`

or

`mycommand --foo-level=-1`

or

`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.",avogel@…
12816,error using with WinRT,typeof,Boost 1.63.0,To Be Determined,Support Requests,Peder Holt,new,2017-02-05T19:33:03Z,2018-01-29T02:40:32Z,"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",tomáš hering <hering.t@…>
12815,Boost asio 1.63 examples are all broken links,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-02-05T19:03:48Z,2017-02-25T18:36:36Z,"In the docs site, the boost 1.63 asio examples are all broken links.",marvin.herbold@…
12814,BOOST_TEST_EQ has wrong behavior for const char*,core,Boost 1.61.0,To Be Determined,Bugs,Peter Dimov,new,2017-02-05T17:16:26Z,2017-02-05T17:16:26Z,"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.",Hans Dembinski <hans.dembinski@…>
12810,feature parity between boost::intrusive_ptr and boost::interprocess::intrusive_ptr,intrusive,Boost Release Branch,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-02-03T13:01:34Z,2017-02-25T18:36:05Z,"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 ",mikolaj.krzewicki@…
12809,crash in boost interprocess cached adaptive pool when using allocate_one method,interprocess,Boost 1.62.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-02-03T10:44:56Z,2017-02-03T10:47:57Z,"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

",naidu.trk@…
12807,boost::python::objects::add_cast can make incorrect connections,python USE GITHUB,Boost 1.63.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2017-02-02T23:10:23Z,2017-02-02T23:12:18Z,"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.
   ",Rob Pieké <robpieke@…>
12806,flat_map.hpp function force_copy break strict-aliasing on gcc < 4.4,container,Boost 1.63.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-02-02T16:38:59Z,2017-04-09T20:38:53Z,"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?
",Vladislav <phprus@…>
12804,Can't compiler IPC atomic_cas32<> on AIX.ppc with GCC,interprocess,Boost 1.62.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-02-02T07:39:03Z,2017-08-08T07:14:31Z,"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$

}}}
",dima.ru.com@…
12802,optional<recursive_wrapper> is broken in 1.63,optional,Boost 1.63.0,To Be Determined,Bugs,Fernando Cacciola,new,2017-02-01T16:03:27Z,2017-02-01T16:03:27Z,"{{{
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
",pal666@…
12801,dynamic_bitset move constructor/assignment does not compile with state allocator,dynamic_bitset,Boost 1.62.0,To Be Determined,Bugs,jsiek,new,2017-02-01T09:05:38Z,2017-02-01T09:05:38Z,"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).",piotr.cisowski@…
12797,Invalid regex recursion behavior,regex,Boost 1.63.0,To Be Determined,Bugs,John Maddock,new,2017-01-29T14:49:10Z,2017-01-29T14:49:10Z,"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 [https://regex101.com/r/emKagD/1 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:

{{{
#!cpp
#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 [http://stackoverflow.com/a/41910370/3764814 here].
",Lucas Trzesniewski <lucas.trzesniewski@…>
12795,thread library - thread_specific_ptr documentation gives obsolete recomendation,thread,Boost 1.63.0,To Be Determined,Bugs,viboes,assigned,2017-01-27T09:37:42Z,2017-11-14T20:43:42Z,"thread_specific_ptr documentation says

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

Now as we have portable '''thread_local''' in current compilers, it should be prefered to use '''thread_local''', since thread_specific_ptr has known performance limitation.",Oleksandr Guteniev <gutenev@…>
12793,Boost.ICL document exclusive_less_than,ICL,Boost 1.61.0,To Be Determined,Support Requests,Joachim Faulhaber,new,2017-01-26T09:24:45Z,2017-01-26T09:24:45Z,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.,gast128@…
12789,"Instantiating bimap with all three ""additional"" template parameter fails to compile.",bimap,Boost 1.55.0,To Be Determined,Bugs,Matias Capeletto,new,2017-01-25T15:21:48Z,2017-01-25T15:21:48Z,"The following test program fails to compile.

{{{#!c++
#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:

{{{#!c++
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.",jonathan.haigh@…
12788,optional 1.63 no longer can be initialized from '<brace-enclosed initializer list>',optional,Boost 1.63.0,To Be Determined,Bugs,akrzemi1,reopened,2017-01-25T09:19:18Z,2017-04-07T07:50:03Z,"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>')
",piotrwn1@…
12787,how to read non-utf8 strings with boost::property_tree,property_tree,Boost 1.61.0,To Be Determined,Bugs,Sebastian Redl,new,2017-01-25T09:09:24Z,2017-01-26T13:46:44Z,"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",steinbac@…
12785,building in solaris 10: ./build.sh: syntax error at line 135: `machine=$' unexpected,Building Boost,Boost 1.63.0,Boost 1.65.0,Bugs,,new,2017-01-24T20:10:22Z,2017-01-24T20:10:22Z,"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?",anonymous
12784,"Use of ""cp -p"" on a tmpfs is broken in recent versions coreutils on solaris",Building Boost,Boost 1.63.0,Boost 1.65.0,Bugs,,new,2017-01-24T19:48:12Z,2017-01-24T19:58:48Z,"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.
",anonymous
12783,Make some existing solaris-specific flags only be used with the solaris studio toolset,Building Boost,Boost 1.63.0,Boost 1.65.0,Bugs,,new,2017-01-24T19:20:54Z,2017-01-24T19:20:54Z,"When building in solaris it automatically incorporates the following
pre-processor definitions in a number of projects:

-D_XOPEN_SOURCE=500
-D__EXTENSIONS__

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.",anonymous
12781,Boost.MPI header <boost/mpi.hpp> cannot be included in project headers,mpi,Boost 1.61.0,To Be Determined,Bugs,Matthias Troyer,new,2017-01-23T16:18:59Z,2017-04-24T16:31:17Z,"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. ",ryan.krattiger@…
12777,uniform_real_distribution fails to compile with result_type having explicit conversion constructor from float,random,Boost 1.63.0,To Be Determined,Bugs,No-Maintainer,new,2017-01-22T07:47:15Z,2017-01-22T07:47:15Z,"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.",b7.10110111@…
12773,WINDOWS- Boost thread 1.63.0 strict aliasing warnings,thread,Boost 1.63.0,To Be Determined,Bugs,viboes,assigned,2017-01-19T13:34:42Z,2017-11-14T20:54:51Z,"I'm cross-compiling boost on Linux, having 32-bit mingw64 as a target.

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


As gcc 6 has even stricter aliasing rules, I'm afraid that these may be harmful, so I came up with the attached patch - which is ugly, but works. 
",alexandre.nunes@…
12772,Interval streaming does not work for std::wstring,ICL,Boost 1.63.0,To Be Determined,Feature Requests,Joachim Faulhaber,new,2017-01-18T09:37:09Z,2017-01-18T09:37:09Z,"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;
   }
}
}}}
",gast128@…
12768,Provide intrusive unordered_set with automatic bucket management,intrusive,Boost 1.63.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-01-18T00:51:46Z,2017-07-26T00:18:44Z,"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.",fdegros@…
12766,Boost Units: Quantities in Constexpr Functions,units,Boost 1.62.0,To Be Determined,Feature Requests,Jürgen Hunold,new,2017-01-17T10:37:44Z,2017-01-20T07:30:49Z,"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

}}}
",a.huebl@…
12765,Provide heterogeneous lookup methods using the container's hasher and/or comparator functions,intrusive,Boost 1.63.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-01-16T23:50:08Z,2017-07-26T00:19:43Z,"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.",fdegros@…
12764,Improve documentation regarding disposers,intrusive,Boost 1.63.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-01-16T23:13:00Z,2017-01-16T23:13:00Z,"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 [http://en.cppreference.com/w/cpp/memory/default_delete std::default_delete]. It could be used in the example instead of rolling out our own function object calling the {{{delete}}} operator.",fdegros@…
12763,Provide a way to specify a default disposer,intrusive,Boost 1.63.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2017-01-16T07:19:18Z,2017-07-26T00:21:42Z,"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();
}}}",fdegros@…
12758,Fix warning: declaration of 'explicit' constructor without a single argument is redundant,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2017-01-13T14:28:19Z,2017-01-15T04:14:17Z,"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",martin.wild@…
12756,"Getting the error: "" undefined reference to `_Py_NoneStruct' "" using boost.python",python USE GITHUB,Boost 1.63.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2017-01-12T21:57:34Z,2017-01-15T04:01:28Z,"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. 
_",Joshua Moser <joshnm7@…>
12755,serialization/map.hpp tests for the wrong thing to figure out whether emplace_hint() exists,serialization,Boost 1.63.0,To Be Determined,Bugs,John Maddock,new,2017-01-12T20:02:11Z,2017-05-03T21:47:14Z,"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.",bangerth@…
12754,operator| overload for boost::range_details::replace_holder is not SFINAE friendly,range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2017-01-12T13:40:13Z,2017-01-16T09:33:28Z,"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.
",Tim Wynants <tim.wynants+boost@…>
12746,boost::filesystem::canonical fails for network paths on windows/inconsistent behavior,filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2017-01-11T03:07:52Z,2017-01-11T03:09:56Z,"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.
",Rob.Conde@…
12743,boost::filesystem in Windows fails to compare two identical paths with different case,filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2017-01-10T14:55:16Z,2017-03-08T20:54:50Z,"	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"".",diecalt@…
12741,Linker error in cross compiling with x86_64-w64-mingw32-g++,serialization,Boost 1.63.0,To Be Determined,Bugs,Robert Ramey,assigned,2017-01-10T11:31:22Z,2017-09-08T14:53:37Z,"Using
{{{
using gcc : i686 : i686-w64-mingw32-g++ ;
using gcc : x86_64 : x86_64-w64-mingw32-g++ ;
}}}
in tools/build/src/user-config.jam

with  x86_64-w64-mingw32-g++ (GCC) 5.3.1 20160211  and calling
{{{
./b2 toolset=gcc-x86_64 address-model=64 link=shared --stagedir=x64 target-os=windows threading=multi threadapi=win32 variant=release --with-date_time --with-filesystem --with-graph --with-math --with-program_options --with-serialization --with-system --with-thread --with-timer
}}}
gives linker errors 
{{{
gcc.link.dll bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/libboost_wserialization.dll.a
bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/basic_text_wiprimitive.o:basic_text_wiprimitive.cpp:(.rdata$.refptr._ZTVN5boost7archive12codecvt_nullIwEE[.refptr._ZTVN5boost7archive12codecvt_nullIwEE]+0x0): undefined reference to `vtable for boost::archive::codecvt_null<wchar_t>'
bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/xml_wiarchive.o:xml_wiarchive.cpp:(.rdata$.refptr._ZTVN5boost7archive6detail18utf8_codecvt_facetE[.refptr._ZTVN5boost7archive6detail18utf8_codecvt_facetE]+0x0): undefined reference to `vtable for boost::archive::detail::utf8_codecvt_facet'
}}}

The 32bit version  i686-w64-mingw32-g++  with  toolset=gcc-i686 address-model=32  works.",zimmermann@…
12738,Invalid include of no_exceptions_support.hpp in boost/move/algorithm.hpp.,move,Boost Development Trunk,To Be Determined,Bugs,Ion Gaztañaga,new,2017-01-09T15:05:41Z,2017-01-09T15:08:04Z,"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.",ashapiro@…
12737,Invalid include of no_exceptions_support.hpp in boost/move/algorithm.hpp.,move,Boost Development Trunk,To Be Determined,Bugs,Ion Gaztañaga,new,2017-01-09T15:05:36Z,2017-01-09T15:27:49Z,"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.",ashapiro@…
12736,crc table init at compile time,crc,Boost 1.61.0,To Be Determined,Feature Requests,Daryle Walker,new,2017-01-09T14:16:47Z,2017-11-08T02:48:35Z,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.,ajax16384@…
12735,asio: Fails to include unistd.h if BOOST_ASIO_HAS_BOOST_CONFIG is defined,asio,Boost Development Trunk,To Be Determined,Bugs,chris_kohlhoff,new,2017-01-09T12:17:12Z,2017-02-07T10:32:24Z,"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:
{{{
#!C++
#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:

{{{
#!C++
#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.
",Idar Tollefsen <idart@…>
12732,Karma problem converting a char vector to string,fusion,Boost 1.64.0,To Be Determined,Bugs,Joel de Guzman,new,2017-01-06T15:16:39Z,2017-05-02T14:51:33Z,"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: 

{{{#!c++
#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.",Braden McDaniel <braden@…>
12729,crash,date_time,Boost 1.61.0,To Be Determined,Bugs,az_sw_dude,new,2017-01-05T13:06:39Z,2017-01-06T01:20:39Z,"I find a crash:[[BR]]

1.Operating system: Android 0.0.0 Linux 3.10.0[[BR]]

2.CPU: arm ARMv7 ARM part(0x4100c070) features: swp,half,thumb,fastmult,vfpv2,edsp,neon,vfpv3,tls,vfpv4,idiva,idivt 4 CPUs[[BR]]

3.code:[[BR]]

void my_thread_sleep(int millisec)[[BR]]

{
try{boost::thread::sleep(boost::get_system_time() + boost::posix_time::millisec(millisec));}
	catch (boost::thread_interrupted& e){(void)e;}
	catch (...){}
}[[BR]]

thread do:[[BR]]

for(;;)
{
my_thread_sleep(5000);
}[[BR]]

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]",anonymous
12726,compilation errors for iOS API,bind,Boost 1.63.0,To Be Determined,Bugs,Peter Dimov,new,2017-01-05T05:46:17Z,2017-01-05T15:48:49Z,"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
",support@…
12725,boost::geometry::distance compile errors with 3D segment primitives,geometry,Boost 1.60.0,To Be Determined,Feature Requests,Barend Gehrels,new,2017-01-05T00:33:45Z,2017-01-16T19:28:28Z,"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]",Arturo Blas <arturoblas@…>
12723,./boost/mpi/detail/mpi_datatype_primitive.hpp:28:51: fatal error: boost/serialization/detail/get_data.hpp: No such file or directory,mpi,Boost 1.64.0,To Be Determined,Bugs,Matthias Troyer,new,2017-01-04T22:33:42Z,2017-08-07T15:38:46Z,"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",nico.schloemer@…
12722,asio visibility pragmas bloat .dynstr segment,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2017-01-04T18:05:19Z,2017-01-08T14:29:27Z,"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.",mzeren@…
12721,intrusive key_of_value requires value to be returned by reference,intrusive,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2017-01-04T10:03:06Z,2017-02-06T12:21:43Z,"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.",Mathias Gaunard
12718,LD_LIBRARY_PATH shouldn't be applied to touch command,Building Boost,Boost 1.63.0,To Be Determined,Bugs,,new,2016-12-30T13:29:53Z,2016-12-30T13:29:53Z,"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.

",Kan Li <likan_999.student@…>
12717,Incomplete documentation of boost::lockfree::queue::queue,lockfree,Boost Development Trunk,To Be Determined,Bugs,timblechmann,new,2016-12-29T18:13:56Z,2016-12-29T18:13:56Z,"{{{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",pmoran@…
12716,"Python link broken in ""build from source"" documentation",python USE GITHUB,Boost 1.63.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2016-12-28T12:15:44Z,2016-12-29T11:02:28Z,"In the ""[http://www.boost.org/doc/libs/1_63_0/more/getting_started/windows.html#or-build-binaries-from-source Build from source]"" documentation page there's a link ""[http://www.boost.org/doc/libs/1_63_0/libs/python/doc/building.html Boost.Python build documentation]"" that's broken.",jepessen
12715,nested BOOST_FOREACH: MSVC 14.0 Update 3 warning issued,foreach,Boost 1.61.0,To Be Determined,Bugs,Eric Niebler,new,2016-12-28T09:16:50Z,2016-12-28T09:16:50Z,"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;
	}
}
}}}
",timo.euler@…
12714,boost 1.6.3 doesn't appear to be installing right,Building Boost,Boost 1.63.0,To Be Determined,Bugs,,new,2016-12-27T20:56:12Z,2016-12-27T20:56:12Z,"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
",Ray Satiro <raysatiro@…>
12711,Cross-compiling with GCC on windows will hang due cygwin path resolution,build,Boost 1.61.0,To Be Determined,Bugs,Vladimir Prus,new,2016-12-23T09:19:10Z,2016-12-23T09:19:10Z,"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:
{{{#!sh
   b2 --clean-all  -d+5 variant=release
}}}

Will leads to endless loops in cygwin path resolving:
{{{#!txt
(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
{{{#!diff
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/boost_1_63_0/tools/build/src/tools/cygwin.jam     Wed Nov  9 18:10:39 2016
+++ b/boost_1_63_0/tools/build/src/tools/cygwin.jam     Fri Dec 23 15:53:29 2016
@@ -59,9 +59,9 @@
                 head = ;
             }
             tail = $(tail:R=$(head:D=)) ;

-            if $(head) = /
+            if $(head) = ""/"" || [ MATCH  ""^([a-zA-Z]:/)$"" : $(head) ]
             {
                 head = ;
             }
             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)",kirill.erofeev@…
12710,Asio with OpenSSL 1.1.0 compiles but does not work,asio,Boost 1.62.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-12-22T22:36:02Z,2017-09-17T19:45:36Z,"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.",vygis.d@…
12709,"Boost.Asio uses Boost.Coroutine v1, yet Boost.Coroutine v2 references it as a usage example",coroutine,Boost 1.62.0,To Be Determined,Bugs,olli,new,2016-12-22T17:30:57Z,2017-11-04T02:36:12Z,"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.",Antoine Poliakov <antoinep92@…>
12708,Cannot use Boost Units cmath.hpp with custom systems,units,Boost 1.62.0,To Be Determined,Bugs,Matthias Schabel,new,2016-12-22T08:11:53Z,2016-12-22T08:11:53Z,"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.",Kamil Rojewski <kamil.rojewski@…>
12707,Missing edges in Voronoi Diagram,polygon,Boost 1.56.0,To Be Determined,Bugs,Lucanus Simonson,new,2016-12-21T18:42:02Z,2016-12-21T18:42:02Z,"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.",alessandro@…
12706,missing including to restriction namespace boost placeholders conflicting with C++ std::placeholders,property_tree,Boost 1.62.0,To Be Determined,Bugs,Sebastian Redl,new,2016-12-21T08:20:57Z,2016-12-21T08:20:57Z,"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

",betachen@…
12704,scope_exit: MSVC 14.0 Update 3 warning issued,scope_exit,Boost 1.61.0,To Be Determined,Bugs,Lorenzo Caminiti,new,2016-12-20T13:15:17Z,2016-12-20T13:15:17Z,"
Hi,

BOOST_SCOPE_EXIT emits[[BR]]
'''warning C4459: declaration of 'boost_scope_exit_aux_args' hides global declaration'''[[BR]]
using compiler setting /W4 for Visual Studio 2015 Update 3 (VC 14)

Example code:
{{{#!c++
#include <boost/scope_exit.hpp>
int main()
{
    int test = 0;
    BOOST_SCOPE_EXIT(&test) { test = 5;  } BOOST_SCOPE_EXIT_END;
    return 0;
}
}}}",thomas.forell@…
12703,BOOST_MPL_ASSERT_MSG cannot be used in constexpr functions,mpl,Boost 1.62.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2016-12-20T02:51:25Z,2016-12-20T02:51:25Z,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?,socgerlia@…
12702,boost_1_62_0 issue,Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-12-19T21:54:05Z,2016-12-30T01:26:03Z,"I have the following error.



Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

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>",henriaghaei@…
12701,Numerical error cause invalid input to dijkstra algorithm in min cost max flow code,graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2016-12-19T16:50:55Z,2016-12-20T00:53:42Z,"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));",Dmitrii Marin <dmitry.marin@…>
12700,Returned type mess with find_flow_cost,graph,Boost 1.62.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-12-19T16:41:56Z,2016-12-19T16:41:56Z,"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))",Dmitrii Marin <dmitry.marin@…>
12699,posix_time\time_formatters removes trailing 0 fractional seconds,date_time,Boost 1.63.0,To Be Determined,Feature Requests,az_sw_dude,new,2016-12-16T22:53:41Z,2016-12-16T22:53:41Z,"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.

OR

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.
",Jonathan Zuber <jonathan.zuber@…>
12690,Boost Asio race condition,asio,Boost 1.62.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-12-14T14:39:48Z,2016-12-14T14:39:48Z,"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
",Ivan Kostov <ikostov@…>
12688,Boost..Accumulators test/median.cpp testing method is flawed,accumulator,Boost 1.62.0,To Be Determined,Bugs,Eric Niebler,new,2016-12-14T12:25:18Z,2016-12-14T17:43:24Z,"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.

1. 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.

2. In the case of P^2^, 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:

1. The implementations should be tested against cases where we know what they are supposed to do.

2. It looks like there is a problem in the implementation of the P^2^ algorithm.

HTH,

-- Sinan",A. Sinan Unur <sinan@…>
12685,boost::iostream library does not correctly mark exported symbols as visible on macOS as BOOST_IOSTREAMS_DECL is not defined,iostreams,Boost 1.61.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-12-13T15:31:36Z,2016-12-13T15:34:55Z,"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.
",vishalshetye@…
12684,Application crashing when collector maximum size is reached,log,Boost 1.61.0,To Be Determined,Bugs,Andrey Semashev,new,2016-12-13T10:26:10Z,2016-12-14T06:30:13Z,"
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);",ketan0712@…
12683,Using std::string for options_description,program_options,Boost 1.62.0,To Be Determined,Feature Requests,Vladimir Prus,new,2016-12-13T08:07:44Z,2016-12-13T08:07:44Z,"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.",Rado
12679,"Merging heaps causes them to ""forget"" pending lazy updates.",heap,Boost 1.55.0,To Be Determined,Bugs,timblechmann,new,2016-12-12T07:11:49Z,2016-12-14T05:03:27Z,"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();
  }
}}}
",shirpeled+boost@…
12665,boost::filesystem::path::replace_extension(const path& new_extension) produces inintuitive path on special directory,filesystem,Boost 1.62.0,To Be Determined,Feature Requests,Beman Dawes,new,2016-12-09T00:21:00Z,2016-12-09T00:27:08Z,"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",Guillaume Labourey <guillaume.labourey@…>
12663,geometry::equals fails when points differ by small value,geometry,Boost 1.61.0,To Be Determined,Support Requests,Barend Gehrels,new,2016-12-08T20:21:07Z,2016-12-28T13:30:20Z,"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
",anonymous
12659,Deadlocked with boost::interprocess::managed_mapped_file find,interprocess,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-12-08T10:16:11Z,2018-07-26T08:38:37Z,"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.",soumyadutta13@…
12658,Lack of check for matching end tag in read_xml.,property_tree,Boost 1.62.0,To Be Determined,Bugs,Sebastian Redl,new,2016-12-07T21:03:53Z,2016-12-07T21:03:53Z,"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.",jakjas
12656,`vf2_subgraph_iso` fails to find matchings in mutually connected vertices,graph,Boost Release Branch,To Be Determined,Bugs,Jeremiah Willcock,new,2016-12-07T02:11:22Z,2016-12-11T08:00:20Z,"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. ",araijn@…
12648,Missing includes in boost/icl/left_open_interval.hpp,ICL,Boost 1.62.0,Boost 1.62.0,Bugs,Joachim Faulhaber,new,2016-12-05T15:02:38Z,2016-12-05T15:06:01Z,"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,

}}}

",Vincenzo Giovanni Comito <clynamen@…>
12647,Support for arm instruction-set for arm64-v8a,build,Boost 1.62.0,To Be Determined,Support Requests,Vladimir Prus,new,2016-12-04T08:59:53Z,2016-12-29T11:36:15Z,"Please add support for boost build for instruction-set = arm64-v8a
when building boost for arm architecture.",tungchingkai@…
12646,Compilation error when using a property type other than int with property_merge_45,polygon,Boost 1.62.0,To Be Determined,Bugs,Lucanus Simonson,new,2016-12-04T05:12:28Z,2016-12-04T05:12:28Z,"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
",Charles A Cornell <cacornell@…>
12644,Windows store - vcvarsall.bat is invoked with wrong arguments,Building Boost,Boost 1.62.0,To Be Determined,Bugs,,new,2016-12-02T22:50:51Z,2016-12-13T23:34:59Z,"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).",bjorn.aili@…
12643,Compiler internal error in VS2013 Release mode,lockfree,Boost 1.62.0,Boost 1.62.0,Bugs,timblechmann,new,2016-12-02T14:32:08Z,2016-12-02T14:32:08Z,"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 ==========
}}}",grigorryev@…
12641,binary_oarchive_impl constructor calls derived class before it is constructed.,serialization,Boost 1.62.0,To Be Determined,Bugs,Robert Ramey,new,2016-12-01T23:46:57Z,2016-12-01T23:46:57Z,"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. 


",Jess Peterson <jess@…>
12640,is_empty and remove_all may throw even when called with error_code& argument.,filesystem,Boost 1.62.0,To Be Determined,Bugs,Beman Dawes,new,2016-12-01T18:48:26Z,2016-12-03T06:38:58Z,"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.

",nigel.pattinson@…
12637,The FAQ should address the difference from the C++ standard library version,filesystem,Boost 1.62.0,To Be Determined,Bugs,Beman Dawes,new,2016-11-30T22:13:49Z,2016-11-30T22:13:49Z,"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.",eyalroz@…
12634,optional_config.hpp: needs update for Oracle Developer Studio compiler,optional,Boost Development Trunk,To Be Determined,Bugs,Fernando Cacciola,new,2016-11-29T19:29:27Z,2016-11-29T19:29:27Z,"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
$



",Aparna Kumta <aparna.kumta@…>
12629,temp_directory_path does not conform to GetTempPath on Windows,filesystem,Boost 1.62.0,To Be Determined,Bugs,Beman Dawes,new,2016-11-28T18:47:49Z,2016-11-28T18:54:37Z,"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.",Michael Chadwick <josephholyheart@…>
12626,Building boost with Python and MPI failed (MSVC),mpi,Boost 1.62.0,To Be Determined,Bugs,Matthias Troyer,new,2016-11-26T16:14:56Z,2016-12-29T11:32:43Z,"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
",MailMr_S@…
12624,bug error calling boost::make_u32regex(),regex,Boost 1.63.0,To Be Determined,Bugs,John Maddock,new,2016-11-25T05:22:18Z,2017-02-09T19:08:36Z,"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

",shane.quinlivan@…
12623,MSVC Warning in boyer_moore.hpp,algorithm,Boost 1.62.0,To Be Determined,Bugs,Marshall Clow,new,2016-11-25T00:12:31Z,2016-11-25T16:13:34Z,"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
",vinnie.falco@…
12621,property_tree::read_json does not work with BOOST_BIND_NO_PLACEHOLDERS,property_tree,Boost 1.61.0,To Be Determined,Bugs,Sebastian Redl,new,2016-11-24T14:35:16Z,2016-11-24T14:40:05Z,"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.",ja2222ja@…
12619,Boost.Regex partial_match fails (see also Ticket #11776 feature request),regex,Boost 1.61.0,To Be Determined,Bugs,John Maddock,new,2016-11-23T17:15:14Z,2016-11-23T17:15:14Z,"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.",Dr. Robert van Engelen <engelen@…>
12618,"Unused ""str_icase_"" member in xpression_peeker struct",xpressive,Boost 1.63.0,To Be Determined,Bugs,Eric Niebler,new,2016-11-22T20:31:28Z,2016-11-22T20:31:28Z,"There seem to be unused ""str_icase_"" member in xpression_peeker struct in ""boost\xpressive\detail\core\peeker.hpp"" file.",anonymous
12616,Cannot build boost 1.62 for x32 ABI,Building Boost,Boost 1.62.0,To Be Determined,Bugs,,new,2016-11-21T12:03:44Z,2016-11-21T14:07:15Z,"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.",ross@…
12614,Boost graph vf2 isomorphism algo runs for ever for this test case,graph,Boost 1.53.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-11-21T08:20:56Z,2016-11-23T16:13:36Z,"Boost graph vf2 isomorphism algo runs for ever for this test case
Steps to reproduce:
1. Unzip the attached file, you should see three files
2. Add the cpp file to your build system
3. Compile and execute.
----
",Praveen Vs <praveen_v-s@…>
12613,Problem in vf2_subgraph_iso handling self-loops when using undirectedS,graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2016-11-18T11:48:51Z,2016-11-18T11:48:51Z,"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",Flavio De Lorenzi <fdlorenzi@…>
12612,Inconsistency in vf2_subgraph_iso documentation / return value,graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2016-11-18T11:24:48Z,2016-11-24T19:21:40Z,"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",Flavio De Lorenzi <fdlorenzi@…>
12608,boost::polygon crashing on get function after substruction operaion,polygon,Boost 1.58.0,To Be Determined,Bugs,Lucanus Simonson,new,2016-11-14T15:22:41Z,2016-11-14T15:22:41Z,"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",shroman@…
12607,boost telnet client,asio,Boost 1.62.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-11-14T10:10:55Z,2016-11-15T00:00:25Z,"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.",Oleg
12606,Boost.ASIO not throwing EOF exception when using coroutine reading from pipe,asio,Boost 1.62.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-11-14T04:07:22Z,2016-11-14T04:07:22Z,"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",kirit.saelensminde@…
12604,neither scoped_array nor checked_delete do check for nullptr,smart_ptr,Boost 1.62.0,To Be Determined,Bugs,Peter Dimov,new,2016-11-11T10:15:47Z,2016-11-11T14:07:20Z,"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.",steinbac@…
12603,C++11 Raw string literals with delimiters are not lexed correctly,wave,Boost 1.63.0,To Be Determined,Bugs,Hartmut Kaiser,new,2016-11-11T04:23:08Z,2016-11-11T04:23:08Z,"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.",edaskel@…
12602,C++11 raw string literals with embedded escapes are mislexed,wave,Boost 1.63.0,To Be Determined,Bugs,Hartmut Kaiser,new,2016-11-11T03:38:33Z,2016-11-11T03:38:33Z,"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.",edaskel@…
12601,system_complete doc error,filesystem,Boost 1.62.0,To Be Determined,Bugs,Beman Dawes,new,2016-11-10T23:28:34Z,2016-11-10T23:28:34Z,"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"".",anonymous
12598,Function definition not found reported by intellisense,foreach,Boost 1.62.0,To Be Determined,Bugs,Eric Niebler,new,2016-11-09T14:09:17Z,2016-11-09T14:09:17Z,"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!?


",bjorn.holmgren@…
12595,Unexpected result when using type_erased adaptor to a transformed_range when clang optimizations are enabled,range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2016-11-08T06:11:41Z,2016-11-08T06:11:41Z,"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",Alfredo Altamirano <fredy.altamirano8@…>
12594,zlib is always missed when ZLIB_SOURCE contains spaces,iostreams,Boost 1.62.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-11-07T21:03:35Z,2016-11-07T21:03:35Z,"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.",mikhail@…
12591,Error compiling boost with mingw,Building Boost,Boost 1.62.0,To Be Determined,Bugs,,new,2016-11-07T12:35:06Z,2017-10-09T21:24:12Z,"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",anonymous
12590,C++11 raw string literal support incomplete,wave,Boost 1.61.0,To Be Determined,Bugs,Hartmut Kaiser,new,2016-11-06T18:14:54Z,2016-11-07T16:17:37Z,"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
",edaskel@…
12586,String algorithm fails to compile using Visual Studio 2015 Update 3,algorithm,Boost 1.62.0,To Be Determined,Bugs,Marshall Clow,new,2016-11-05T16:37:17Z,2017-08-13T10:01:42Z,"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. ",lex21@…
12585,Functional fails to compile using Visual Studio 2015 Update 3,functional,Boost 1.62.0,To Be Determined,Bugs,No-Maintainer,new,2016-11-05T16:21:46Z,2016-11-05T16:21:46Z,"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.",lex21@…
12582,"Error catching specific ""regex_error""",regex,Boost 1.61.0,To Be Determined,Bugs,John Maddock,new,2016-11-04T14:58:54Z,2017-02-09T18:50:17Z,"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
    }
}}}",Pierre Vaillancourt <pierre.vaillancourt@…>
12576,Segmentation fault when use bcp for asio lin in Mac Clang6.0,asio,Boost 1.61.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2016-11-02T09:58:10Z,2017-07-17T18:59:12Z,"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
",julien.dauba@…
12575,fix compilation of software using libressl and boost asio,asio,Boost 1.62.0,To Be Determined,Patches,chris_kohlhoff,new,2016-11-02T09:20:33Z,2017-02-02T22:06:38Z,"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
",Reinhard Biegel <r.biegel@…>
12573,b2 ignores <archiver> <ranlib> and other flags selecting toolchain,Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-11-01T14:51:20Z,2017-03-15T21:40:23Z,"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.





",hbadger@…
12570,"b2 ignores Iconv and disabled boost-locale lib, even though has_iconv.cpp passed",locale,Boost 1.62.0,To Be Determined,Bugs,Artyom Beilis,new,2016-10-31T13:59:58Z,2016-12-07T17:18:45Z,"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.











",hbadger@…
12567,boost::filesystem::path::generic crashes on Windows while attempting to build a network share path,filesystem,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-10-28T16:02:50Z,2016-10-28T16:02:50Z,"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.",alexandra.ghecenco@…
12561,program_options fails with clang++/libc++,program_options,Boost 1.62.0,To Be Determined,Bugs,Vladimir Prus,new,2016-10-27T18:47:12Z,2016-11-07T16:26:37Z,"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",Jörg Plate <patterner@…>
12558,reverse_graph is missing degree(),graph,Boost 1.62.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-10-27T03:18:44Z,2016-10-27T03:25:31Z,"Commit 50bfd8d added the missing check for degree in BidirectionalGraphConcept, but reverse_graph doesn't implement degree and thus fails the concept check.",matthew.barr@…
12557,new_iterator_tests.hpp has a missing #include,iterator,Boost 1.60.0,To Be Determined,Bugs,jeffrey.hellrung,new,2016-10-26T22:55:30Z,2016-10-26T22:55:30Z,"`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).",gromer@…
12555,Graph headers are not self-contained,graph,Boost 1.60.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-10-26T21:45:17Z,2016-10-26T22:08:28Z,"Many BGL header files are not self-contained, meaning that they will not compile if `#include`d 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 `#include`s. 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`.",gromer@…
12554,boost/core/typeinfo.hpp creates unwanted strings in release binary,tokenizer,Boost 1.62.0,Website 1.X,Bugs,jsiek,new,2016-10-26T21:11:09Z,2017-11-18T09:49:18Z,"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:
1. binary program file size become larger
2. code symbols are present in production version of a program

Five minutes proposed solution from me is replace function ""name"" by
{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!c++
  static char const * name()
    {
#ifdef NDEBUG
        return """";
#else
        return BOOST_CURRENT_FUNCTION;
#endif
    }
  }}}
}}}
    

Sorry for English...

Thank you for attention.",Lev Sch <Zorechfan@…>
12550,output operator for multiprecision cpp_dec_float does not recognise locale settings for decimal point,multiprecision,Boost 1.62.0,To Be Determined,Bugs,John Maddock,new,2016-10-25T14:21:06Z,2016-10-25T14:21:06Z,"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.",Rüdiger Brünner <rbruenner@…>
12548,Build system fails to find Python 3.5 on macOS,Building Boost,Boost 1.62.0,To Be Determined,Bugs,,new,2016-10-24T20:11:59Z,2016-10-24T20:11:59Z,"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.
",Bob Pepin <bobpepin@…>
12546,Using lambda in transformed or filtered adaptors result in non assignable iterator,range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2016-10-24T15:04:54Z,2017-06-08T14:37:49Z,"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.",Jean-Philippe DUFRAIGNE <j.dufraigne@…>
12545,stream_socket_service forcibly takes responsibility for closing the native_handle,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-10-24T09:06:19Z,2016-10-24T09:06:19Z,"When using the `basic_stream_socket` [https://github.com/boostorg/asio/blob/36eef63a9cf8ae609716d76ccb3906ff9769d53a/include/boost/asio/basic_stream_socket.hpp#L130 constructor with a native_handle_type], it seems that the service will call `close()` on it [https://github.com/boostorg/asio/blob/36eef63a9cf8ae609716d76ccb3906ff9769d53a/include/boost/asio/detail/impl/reactive_socket_service_base.ipp#L91 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.",Adrien CLERC <adrien.clerc@…>
12541,Permit test cases that are templated *and* data-driven,test,Boost 1.61.0,To Be Determined,Feature Requests,Gennadiy Rozental,new,2016-10-21T17:44:45Z,2016-10-21T17:44:45Z,"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.",Tony Lewis <TonyELewis@…>
12539,error category thread safety (system + asio) c++98,system,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-10-19T22:17:17Z,2016-10-19T22:17:17Z,"
    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?",richard@…
12536,Implement small_flat_set and small_flat_map in terms of small_vector.,container,Boost 1.61.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2016-10-19T17:19:54Z,2016-10-19T17:19:54Z,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.,samkellett@…
12535,boost::program_options cannot handle std::uint8_t arguments,program_options,Boost 1.61.0,To Be Determined,Bugs,Vladimir Prus,new,2016-10-19T07:23:01Z,2017-07-08T11:59:41Z,"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.
",gilgamash
12533,Difficulty building boost 1.62.0 using current mingw distribution,Building Boost,Boost 1.62.0,To Be Determined,Bugs,,new,2016-10-17T23:54:34Z,2016-10-17T23:54:34Z,"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.

1. bootstrap.bat never reached the section looking for MinGW gcc compiler.  I moved that earlier in the script (just before checking for msvc compilers).
2. 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.
3. toolset=mingw is not supported by jam - had to set it to gcc instead
4. 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.",drmhkelley@…
12529,Sending two int values,asio,Boost 1.61.0,Boost 1.61.0,Support Requests,chris_kohlhoff,new,2016-10-14T11:48:31Z,2016-10-14T11:48:31Z,"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 ?",anonymous
12528,"boost::asio::ssl_stream ""short read error"" when a connection is closed",asio,Boost 1.62.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-10-14T07:30:06Z,2016-10-14T07:30:06Z,"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",Nakao_Kazuhiro@…
12527,cpp_bin_float: Anal fixation. Part 3. Double rounding when result of convert_to<double>() is a subnormal,multiprecision,Boost 1.62.0,To Be Determined,Bugs,John Maddock,reopened,2016-10-13T23:46:51Z,2016-11-29T22:43:55Z,"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.

",Michael Shatz
12526,"test_graphs.cpp :Error: The operation ""boost::undirected_graph*** is illegal",graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2016-10-13T21:34:23Z,2016-10-13T21:34:23Z,"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
> 
}}}
",Aparna.kumta@…
12523,configuration issue in foreach.hpp for Oracle Developer Studio compiler,foreach,Boost Development Trunk,To Be Determined,Bugs,Eric Niebler,new,2016-10-13T17:26:52Z,2016-10-13T17:26:52Z,"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)
$
",Aparna.kumta@…
12522,boost/math/tools/minima.hpp pass functor by ref,math,Boost 1.61.0,To Be Determined,Feature Requests,John Maddock,new,2016-10-12T23:15:53Z,2016-10-12T23:15:53Z,"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);",ch816772@…
12521,runtime error placement_new.cpp  with Oracle Developer Studio compiler,uBLAS,Boost Development Trunk,To Be Determined,Bugs,Gunter,new,2016-10-11T21:03:21Z,2016-10-11T21:03:21Z,"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",Aparna Kumta <aparna.kumta@…>
12520,Boost.Fiber requirements are executed when cross-compiling,Building Boost,Boost 1.62.0,To Be Determined,Bugs,,new,2016-10-11T14:30:50Z,2016-10-11T14:30:50Z,"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.",carlosmf.pt@…
12518,boost::filesystem::unique_path throws std::exception and not  filesystem_error,filesystem,Boost 1.58.0,To Be Determined,Bugs,Beman Dawes,new,2016-10-11T12:09:54Z,2016-12-06T11:41:56Z,"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",gerald.lodron@…
12516,Missing boost::serialization::array_wrapper in built serialization binary,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,reopened,2016-10-11T10:58:53Z,2017-06-01T05:31:50Z,"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.[[BR]]
The bug is not present into Boost 1.59.0. I've not tried Boost 1.62.0.[[BR]]
[[BR]]
Some more details:[[BR]]
[[BR]]
'''OS:''' CentOS6[[BR]]
'''Compiler:'''[[BR]]
Intel 16, over gcc 4.9.2 (tried building with both -std=c++11 or -std=c++14).[[BR]]
Tried also with Intel 13, over gcc 4.8.5 (-std=c++11) and the issue is the same.",michele.de.stefano@…
12515,"bjam ""python=X.X"" option not recognized anymore",Building Boost,Boost 1.62.0,To Be Determined,Bugs,,new,2016-10-11T09:11:55Z,2017-02-20T13:55:08Z,"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.
",boost@…
12513,"Boost optional  (1.60/1.61/1.62) generates ""may be used uninitialized"" warnings with gcc 6",optional,Boost 1.60.0,To Be Determined,Bugs,Fernando Cacciola,new,2016-10-10T21:57:44Z,2017-02-14T22:44:39Z,"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",romain.geissler@…
12504,Use types from <cinttypes> in boost::uint_t and boost::int_t,integer,Boost 1.61.0,To Be Determined,Feature Requests,Daryle Walker,new,2016-10-07T20:44:01Z,2016-10-07T20:44:01Z,"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 [https://github.com/boostorg/integer/blob/develop/include/boost/integer.hpp#L67 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 [https://travis-ci.org/johnmcfarlane/fixed_point/builds/165888344 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",john@…
12502,boost/asio/error.hpp: fix warnings about unused static variables,asio,Boost 1.59.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-10-06T13:21:11Z,2017-01-12T16:45:17Z,"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",bachmann@…
12496,clang 3.9 fails to generate precompiled headers,build,Boost 1.62.0,To Be Determined,Bugs,Vladimir Prus,new,2016-10-02T08:15:41Z,2017-01-13T17:12:57Z,"Bootstrapping
{{{
./bootstrap.sh --with-toolset=clang --with-icu=/usr
  --prefix=~/lib/boost_clang --with-python=python3
}}}

b2
{{{
./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""
}}}

",Jörg Plate <patterner@…>
12493,Compile error in boost::intrusive with Sun compiler 12.4,intrusive,Boost 1.58.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-09-30T16:21:28Z,2016-09-30T16:21:28Z,"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.


",kilian.kilger@…
12492,No libbost_fiber files after building boost 1_62,Building Boost,Boost 1.62.0,To Be Determined,Support Requests,,new,2016-09-29T11:21:53Z,2016-09-29T12:24:50Z,"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",filwoz@…
12489,"file_lock and fstream read causes ""permission denied""",interprocess,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-09-28T09:34:18Z,2016-09-28T09:34:18Z,"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;
}
",anonymous
12485,accessing message_queue created by 64bit process from a 32bit process results in blocked process.,interprocess,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-09-26T19:32:02Z,2016-09-26T19:32:02Z,"Environment:
  * Development and target: Windows 7 Pro, 64-bit;
  * MSVS 2013; 
  * boost is used as header-only

Sequence of events:
 1. process A (64-bit) creates message queue ""msgq1""
 2. process B (32-bit) opens ""msgq1"" (successfully)
 3. 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.",alex parkov <alex.parkov@…>
12483,signals2 bind to member function by value fail to signal when using trackable,signals,Boost 1.61.0,To Be Determined,Support Requests,Douglas Gregor,new,2016-09-26T13:03:57Z,2016-09-26T13:03:57Z,"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.
{{{
#!div style=""font-size: 80%""
Test program:
  {{{#!c++
#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:
{{{
#!div style=""font-size: 80%""
Bind by reference:
  {{{#!c++
sig.connect(boost::bind(&SignalTest::printInfo, &test2, _1, _2));
  }}}
}}}
The following is printed:
{{{
#!div style=""font-size: 80%""
test2 bind by reference print
  {{{#!text
Signal: Test 2
  }}}
}}}

And if I also bind signalTest object ""test1"" by reference the following is printed:
{{{
#!div style=""font-size: 80%""
test1 and test2 bind by reference print
  {{{#!text
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.

",kim.lykke.johansen@…
12482,No longer builds without warnings on MAC OS X 10.11.6 after upgrade to Xcode with Clang 8.0,asio,Boost 1.61.0,Boost 1.61.0,Tasks,chris_kohlhoff,new,2016-09-26T03:02:56Z,2016-11-18T10:39:33Z,"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.
}}}",anonymous
12477,[math] error: while reading precompiled header: No such file or directory,build,Boost 1.61.0,To Be Determined,Bugs,Vladimir Prus,new,2016-09-23T07:18:37Z,2016-09-24T15:53:10Z,"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.


",jackie.huang@…
12476,Using named_condition_any with a readers-writer lock,interprocess,Boost 1.58.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-09-21T14:01:32Z,2016-09-21T14:01:32Z,"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;
}
}}}

",Chris Evans <chris.evans@…>
12475,boost::fast_pool_allocator causes a deadlock on Windows 7,pool,Boost 1.61.0,To Be Determined,Bugs,Chris Newbold,new,2016-09-21T13:31:32Z,2016-09-21T13:31:32Z,"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

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

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

{{{#!cpp
#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.",dictoon@…
12474,Using two different resolver instances on the same io_service causes a race condition,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-09-21T09:47:04Z,2016-09-21T10:09:14Z,"Dear developer (or developers) of Boost Asio,[[BR]]
[[BR]]
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.[[BR]]
[[BR]]
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.[[BR]]
[[BR]]
Quick instructions for running the tests:[[BR]]
[[BR]]
`test_engine_client_dbg_x -s -p <port>`[[BR]]
[[BR]]
runs the server.[[BR]]
[[BR]]
`test_engine_client_dbg_x -c -p <port>`[[BR]]
[[BR]]
Runs the client.[[BR]]
[[BR]]
`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.[[BR]]
[[BR]]
`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.[[BR]]
[[BR]]
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()`.[[BR]]
[[BR]]
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.[[BR]]
[[BR]]
In summary, stress test is the only way to hope to experience this bug (but sometimes it also comes out at the first run).",michele.de.stefano@…
12472,accumulator statistics.hpp may cause build to fail due to no viable overloaded operator[],accumulator,Boost 1.61.0,To Be Determined,Bugs,Eric Niebler,new,2016-09-20T20:28:28Z,2016-09-30T16:09:37Z,"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`.

",Alex Wang <aw1621107@…>
12471,gzip compressor decompressor broken,iostreams,Boost 1.61.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-09-20T14:40:52Z,2018-01-13T17:30:42Z,"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...
",anonymous
12470,gzip compressor decompressor broken,iostreams,Boost 1.61.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-09-20T14:40:47Z,2016-09-20T14:40:47Z,"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...
",anonymous
12469,BOOST_MPL_PRINT_HPP generates error: negative integral constant converted to unsigned type,mpl,Boost 1.61.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2016-09-20T14:17:27Z,2016-11-01T22:02:49Z,"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.
",anonymous
12467,[regression] clang 3.9 and trunk fail to compile small_vector (ICE),container,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-09-16T08:58:32Z,2018-11-14T13:31:56Z,"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.",anonymous
12466,"property_tree::string_path<StringT, TranslatorT>'s operator / won't accept StringT as an argument",property_tree,Boost 1.61.0,To Be Determined,Bugs,Sebastian Redl,new,2016-09-16T07:09:18Z,2016-09-16T07:09:18Z,"A very simple example of the problem can be seen with this code:
{{{#!C++
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.",LRFLEW <LRFLEW.Coll@…>
12465,"Suggest promoting -j to ""Important Options"" in help output",build,Boost 1.61.0,To Be Determined,Feature Requests,Vladimir Prus,new,2016-09-15T14:37:30Z,2016-09-15T14:37:30Z,"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.",Phil Endecott
12464,Mention dependencies on zlib etc. and how to reconfigure,Getting Started Guide,Boost 1.61.0,To Be Determined,Feature Requests,Dave Abrahams,new,2016-09-15T14:31:45Z,2016-09-15T14:31:45Z,"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.",Phil Endecott
12463,Mention -j option for b2,Getting Started Guide,Boost 1.61.0,To Be Determined,Feature Requests,Dave Abrahams,new,2016-09-15T14:26:05Z,2016-09-15T14:26:05Z,"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.

",Phil Endecott
12462,Wish INSTALL file had more content,Getting Started Guide,Boost 1.61.0,To Be Determined,Feature Requests,Dave Abrahams,new,2016-09-15T14:22:17Z,2016-09-15T14:22:17Z,"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.

---------------------------
Copyright Beman Dawes, 2008

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.",Phil Endecott
12461,Consider using parallel bzip2 for .tar.bz2 downloads,Building Boost,Boost 1.61.0,To Be Determined,Feature Requests,,new,2016-09-15T14:00:46Z,2016-09-15T14:00:46Z,"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!)",Phil Endecott
12458,Boost should use /utf8 compiler option for Visual C++ builds,Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-09-15T09:07:20Z,2016-09-15T09:07:20Z,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.,thomas.sondergaard@…
12456,mapped_file issues with huge file support,iostreams,Boost 1.61.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-09-14T16:27:34Z,2016-09-14T16:27:34Z,"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:

1. 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.


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

3. 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.",Igor Minin <igorm6387@…>
12455,Missing include boost/config.hpp and boost/assert.hpp in download package 1.61.0,xpressive,Boost 1.61.0,To Be Determined,Bugs,Eric Niebler,new,2016-09-14T15:10:58Z,2016-09-14T15:15:12Z,"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.",alexander.hetzl@…
12454,multi_array: operator= does not resize array,multi_array,Boost 1.61.0,To Be Determined,Feature Requests,Ronald Garcia,new,2016-09-14T11:04:57Z,2016-09-14T11:04:57Z,"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;
}",martin.koerner@…
12452,XML log can contain unescaped characters from test output,test,Boost 1.61.0,To Be Determined,Bugs,Gennadiy Rozental,new,2016-09-13T11:40:36Z,2016-09-13T12:51:04Z,"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.",Igor Akhmetov <igor.akhmetov@…>
12450,oost/serialization/singleton.hpp:131: undefined reference to `boost::serialization::singleton_module::is_locked()',serialization,Boost 1.61.0,Boost 1.63.0,Bugs,Robert Ramey,new,2016-09-12T11:50:27Z,2017-09-08T17:27:10Z,"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",NASa Qian <cj.nasa@…>
12448,Boost fails to build when path contains % (percent sign),Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-09-12T09:13:46Z,2016-09-12T12:04:16Z,"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
}}}",yury.zaytsev@…
12446,flat unordered/hash map,container,Boost 1.61.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2016-09-10T06:08:59Z,2016-09-10T06:08:59Z,If/when feasible ;),Domagoj Šarić
12445,static_vector is not noexcept,container,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-09-10T05:56:19Z,2016-09-10T05:56:19Z,"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).",Domagoj Šarić
12444,build failure of boost::date_time::string_parse_tree on HP-UX 11i v3,date_time,Boost 1.38.0,To Be Determined,Bugs,az_sw_dude,new,2016-09-09T05:05:58Z,2016-09-09T05:05:58Z,"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""
}}}",kostrzewa@…
12442,container_traits is closed for extension,graph,Boost 1.61.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-09-08T22:38:37Z,2016-09-08T22:38:37Z,"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.",erdem.cilingir@…
12440,incorrect configuration in boost/graph/properties.hpp for Oracle Developer Studio,graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2016-09-06T21:35:22Z,2016-09-06T21:35:22Z," 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.

",Aparna Kumta <aparna.kumta@…>
12439,"Problems with 180 and -180 meridian, using bg::cs::geographic<bg::degree>",geometry,Boost 1.61.0,To Be Determined,Bugs,Barend Gehrels,new,2016-09-06T19:13:54Z,2017-01-03T17:06:15Z,"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",ostroukhov@…
12437,asio::async_read with a tcp socket gives erroneous results under Windows,asio,Boost 1.62.0,Boost 1.61.0,Bugs,chris_kohlhoff,new,2016-09-05T05:09:12Z,2016-09-05T15:15:52Z,"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).
",anonymous
12436,"BOOST_FUSION_DEFINE_STRUCT fails if a member type starts with ""::""",fusion,Boost 1.59.0,To Be Determined,Bugs,Joel de Guzman,new,2016-09-05T03:45:07Z,2016-10-06T16:01:47Z,"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.
}}}
",jaredgrubb
12433,Make use of make_shared whenever possible in future.hpp,thread,Boost 1.62.0,To Be Determined,Tasks,viboes,assigned,2016-09-03T18:06:36Z,2016-09-03T18:06:47Z,Even if boost::make_shared is not aware of Boost.Move there are a lot of places in future.hpp where make shared could be used and improve the performances.,viboes
12431,BOOST_PP_TUPLE_PUSH_FRONT fails to expand with BOOST_PP_EXPAND,preprocessor,Boost 1.56.0,To Be Determined,Bugs,No-Maintainer,new,2016-09-01T23:48:43Z,2016-09-20T21:36:26Z,"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.",mjtruog@…
12430,Adapt boost for cygwin - patches provided,None,Boost 1.61.0,To Be Determined,Bugs,,new,2016-09-01T22:34:03Z,2018-09-21T09:09:50Z,"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?",frederic.bron@…
12428,string_view. absence of documentation,utility,Boost 1.61.0,To Be Determined,Bugs,Marshall Clow,new,2016-09-01T08:50:31Z,2017-02-12T02:33:59Z,"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.",voropaev_sg@…
12426,boost/preprocessor/seq/for_each_i.hpp fails on gcc 5.4.0 and appleclang 7.3.0,preprocessor,Boost 1.58.0,To Be Determined,Bugs,No-Maintainer,new,2016-08-31T22:47:20Z,2016-09-20T21:38:07Z,"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.",mjtruog@…
12423,fusion::make_map breaks when passing references,fusion,Boost 1.61.0,To Be Determined,Bugs,Joel de Guzman,new,2016-08-30T15:51:30Z,2016-08-30T17:28:45Z,"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)...);
    }

}}}

",oleg00@…
12421,"Even with BOOST_ALL_NO_LIB defined, VS14 linker looks for mt-s variant",Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-08-29T22:50:00Z,2016-09-06T18:59:23Z,"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.",emonette123@…
12420,Boost filesystem should use POSIX API on cygwin,filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2016-08-29T10:53:43Z,2016-08-29T11:09:41Z,"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",frederic.bron@…
12419,use POSIX poll.h instead of glibc-specific sys/poll.h,asio,Boost 1.61.0,To Be Determined,Patches,chris_kohlhoff,new,2016-08-29T08:41:54Z,2016-08-29T08:41:54Z,"    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.
",git@…
12418,boost.smart_ptr: mips assembly doesn't compile in mips16e mode,smart_ptr,Boost 1.61.0,To Be Determined,Patches,Peter Dimov,new,2016-08-29T08:32:15Z,2016-09-02T17:18:20Z,"    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.
",git@…
12416,Windows: shared_mutex::state_data exceptions thrown in synthetic tests,thread,Boost 1.61.0,To Be Determined,Feature Requests,viboes,assigned,2016-08-28T23:21:13Z,2017-02-19T10:53:41Z,"Hi,
My name is Tomer Gal.

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

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

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

Could this be fixed?

Regards,
Tomer Gal, CTO at OpTeamizer

",Tomer Gal <Tomer.Gal@…>
12409,Building boost using different calling conventions,Building Boost,Boost 1.61.0,To Be Determined,Support Requests,,new,2016-08-23T22:51:54Z,2016-08-23T22:51:54Z,"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.",fabrice.lecuyer@…
12406,socket_select_interrupter throws exception when 127.0.0.1 was mapped to another IP address.,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-08-22T15:38:02Z,2016-08-22T15:38:02Z,"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.",zephyryu <zplutor@…>
12403,wave: #include with an empty file causes a crash under Windows,wave,Boost 1.61.0,To Be Determined,Bugs,Hartmut Kaiser,new,2016-08-20T22:31:14Z,2016-08-20T22:49:24Z,"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:
{{{
#!c++
#include ""Empty.h""

int foo()
{
    return 0;
}
}}}

Note that Empty.h must be //completely// empty, including no terminating newline.",anonymous
12399,minmax_element in Boost.Range,range,Boost 1.61.0,To Be Determined,Feature Requests,Neil Groves,new,2016-08-18T02:12:25Z,2016-08-18T02:12:25Z,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.,Brian Pantaleon <bpantaleonh@…>
12397,static_assert in arg.hpp failing when using boost::placeholder with std::bind,bind,Boost 1.61.0,To Be Determined,Bugs,Peter Dimov,new,2016-08-17T10:42:49Z,2016-08-19T22:35:54Z,"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",anonymous
12395,Asio Serial_port does not work after unplug and plug the cable back (reconnection),asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-08-16T13:13:30Z,2016-08-16T13:13:30Z,"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.

",paulorbhell@…
12394,boost::lockfree::queue with gcc-4.6 + optimization,lockfree,Boost 1.58.0,To Be Determined,Bugs,timblechmann,new,2016-08-15T15:21:25Z,2016-08-15T15:23:45Z,"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;
}
}}}
",ygabay@…
12393,Some geometry headers fail to compile indepedently,geometry,Boost 1.61.0,To Be Determined,Bugs,Barend Gehrels,new,2016-08-15T08:10:55Z,2016-08-19T21:18:02Z,"Following on from ticket:12289, I've identified some other Geometry headers that don't compile independently (under Clang) in violation of the [http://www.boost.org/development/header.html 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.",Tony Lewis <tonyelewis@…>
12392,boost::iostreams::mapped_file fails during creating file with zero length,iostreams,Boost 1.60.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-08-15T07:09:07Z,2016-08-15T07:09:07Z,"example
[[BR]]

{{{
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);
}}}",surtaevm@…
12385,program_options ignores long_allow_next,program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-08-09T16:00:31Z,2016-08-09T16:00:31Z,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,Shai Shasag <shai@…>
12384,"GetCurrentProcessId : is filling to get  definition on ""WinCE platform"" for Release mode",winapi,Boost 1.59.0,To Be Determined,Bugs,Andrey Semashev,new,2016-08-09T08:25:20Z,2018-08-02T11:24:45Z,"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"".
",manoharreddy620@…
12383,boost::asio fails to read more than 65536 bytes from file asyncronously,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-08-09T07:10:21Z,2016-08-10T10:46:28Z,"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 `65537`th 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` [[br]]
    > `offset 0: <?xml version=""1.0"" encoding=""UTF-8""?>`  [[br]]
    > `offset 65536: <?xml version=""1.0"" encoding=""UTF-8""?>` [[br]]

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.  [[br]]
Operating systems are: Windows 7 and Windows Server 2008R2.",AStepanjuk@…
12382,nvcc 7.5 unable to compile boost/numeric/odeint example,numeric,Boost 1.60.0,To Be Determined,Bugs,Douglas Gregor,new,2016-08-08T16:06:42Z,2016-08-08T16:06:42Z,"I'm trying to compile the boost example [https://github.com/headmyshoulder/odeint-v2/blob/master/examples/thrust/lorenz_parameters.cu ""lorenz_parameters.cu""] referenced by the [http://www.boost.org/doc/libs/1_60_0/libs/numeric/odeint/doc/html/boost_numeric_odeint/tutorial/using_cuda__or_openmp__tbb_______via_thrust.html 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",Olaf Pichler <boost.olaf@…>
12381,Bootstrap.bat error,Building Boost,Boost 1.61.0,,Support Requests,,new,2016-08-04T12:33:11Z,2016-08-04T12:33:11Z,"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.""


",kylej.ukr@…
12380,property_tree::ordered_end() missing,property_tree,Boost 1.61.0,To Be Determined,Feature Requests,Sebastian Redl,new,2016-08-04T07:25:05Z,2016-08-04T07:25:05Z,"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.",harris.pc@…
12379,Yet another problems with boolean operations with shared edges,geometry,Boost Development Trunk,To Be Determined,Bugs,Barend Gehrels,new,2016-08-03T14:43:05Z,2016-08-03T14:46:05Z,"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.

+-------------+
|             |
|             |
|       +     |
|       |     |
+---+---+-----+
    |
    +",anton.kovalev.239@…
12377,boost::filesystem::exist() returns false when file exist in system,filesystem,Boost 1.61.0,Boost 1.61.0,Bugs,Beman Dawes,new,2016-08-03T12:25:18Z,2016-08-03T12:25:18Z,"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",girishjoshi189@…
12376,boost::filesystem::exist() returns false when file exist in system,filesystem,Boost 1.61.0,Boost 1.61.0,Bugs,Beman Dawes,new,2016-08-03T12:24:58Z,2016-08-16T01:22:33Z,"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",girishjoshi189@…
12375,Patch fixing use of boost::icl w/ MSVC CL.exe /P,ICL,Boost 1.61.0,To Be Determined,Patches,Joachim Faulhaber,new,2016-08-03T10:51:40Z,2016-08-03T10:53:46Z,"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`
}
}}}

On MSVC (Visual Studio 2013)
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

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
}}}",anonymous
12374,doku bug boost::adaptors::sliced,range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2016-08-03T09:09:49Z,2016-09-24T14:42:22Z," 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.
",brix@…
12373,Basic sign conversion,filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2016-08-03T07:10:11Z,2016-08-03T07:10:11Z,"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);

}}}
",Brett Hale <brettyhale@…>
12372,property_tree::get_optional without the template parameter,property_tree,Boost 1.61.0,To Be Determined,Feature Requests,Sebastian Redl,new,2016-08-03T01:25:11Z,2016-08-03T01:25:11Z,"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
",harris.pc@…
12370,Make winapi_mutex_wrapper official,interprocess,Boost 1.61.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2016-08-02T15:56:43Z,2016-08-02T15:56:43Z,"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?",gast128@…
12368,Improve property_tree documentation for path_of,property_tree,Boost 1.61.0,To Be Determined,Feature Requests,Sebastian Redl,new,2016-08-02T08:44:13Z,2017-01-10T07:01:44Z,"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();
            }
         };
      };
}}}",harris.pc@…
12365,fail to build under mingw,Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-07-30T08:45:21Z,2017-02-10T09:25:00Z,"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",anonymous
12361,in string_parse_tree one constructor does not initialize m_value,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2016-07-29T13:05:25Z,2016-07-29T13:05:25Z,"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.","James E. King, III <jim.king@…>"
12360,dead code detected by coverity in mersenne_twister,random,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2016-07-29T12:42:17Z,2017-05-04T04:00:00Z,"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    }
}}}
","James E. King, III <jim.king@…>"
12359,eventfd_select_interrupter calls fcntl without checking the return code,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-07-29T12:27:03Z,2016-07-29T12:27:03Z,"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?","James E. King, III <jim.king@…>"
12358,epoll_reactor calls fcntl without checking return code,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-07-29T12:12:09Z,2016-07-29T12:22:20Z,"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?",jim.king@…
12357,Seg Fault running bcp in 1.61.0 when trying to build in custom namespace,bcp,Boost 1.61.0,To Be Determined,Bugs,John Maddock,new,2016-07-28T17:56:44Z,2017-02-13T14:27:02Z,"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.",Matthew Russell <mrussell@…>
12356,Failed build for msvc 11.0 with global setup script in combination with rewrite option,Building Boost,Boost 1.58.0,To Be Determined,Bugs,,new,2016-07-28T15:04:56Z,2016-07-28T15:04:56Z,"'''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]) ;
}}}
",Christian.Steinle@…
12355,False self intersection,geometry,Boost 1.61.0,To Be Determined,Bugs,Barend Gehrels,new,2016-07-27T15:00:08Z,2016-07-27T15:00:08Z,"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.",jan.kleemann@…
12354,boost::asio::connect crash when connect_condition sets iterator to end,asio,Boost 1.60.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-07-27T10:11:54Z,2016-07-27T10:11:54Z,"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)


}}}
",snua12@…
12352,factory object fails to be assigned to function object when deducing constructor argument (C++11 only),functional,Boost 1.61.0,To Be Determined,Bugs,No-Maintainer,new,2016-07-26T14:08:36Z,2016-07-26T14:14:01Z,"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.",Matthew Hoops <matthewthoops@…>
12351,boost::make_shared doesn't use constructor forwarding through move emulation,smart_ptr,Boost 1.59.0,To Be Determined,Patches,Peter Dimov,new,2016-07-26T09:03:12Z,2016-07-26T09:03:12Z,"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 [http://www.boost.org/doc/libs/1_59_0/doc/html/move/construct_forwarding.html how to perform (limited) constructor forwarding]. It's example is perfectly applicable to boost::make_shared.

The change in [https://github.com/boostorg/smart_ptr/pull/24 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.",me@…
12347,linestring and polygon intersection wrong answer,geometry,Boost 1.60.0,To Be Determined,Bugs,Barend Gehrels,new,2016-07-23T19:07:02Z,2016-07-23T19:07:02Z,"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) :(",Anton Kovalev <anton.kovalev.239@…>
12346,Boost downloaded docs for asio don't work,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-07-22T17:12:23Z,2016-10-02T17:07:57Z,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.,anonymous
12344,boost::fusion::extension::struct_member_name doesn't work with a const sequence,fusion,Boost 1.61.0,To Be Determined,Bugs,Joel de Guzman,new,2016-07-22T12:33:18Z,2016-10-13T15:29:41Z,"Here is the code to reproduce the bug:

{{{#!cpp
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();
}
}}}

[http://melpon.org/wandbox/permlink/0LiQIP59uLbWXFR6 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`.
",Benoit Blanchon <benoit@…>
12341,Enhancement for multi_array resize,multi_array,Boost 1.61.0,To Be Determined,Feature Requests,Ronald Garcia,new,2016-07-21T18:48:30Z,2016-07-21T18:48:30Z,"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.",eugvor@…
12338,compiler warnings in unused variables and typedef,interval,Boost 1.61.0,To Be Determined,Bugs,Boris Gubenko,new,2016-07-21T12:46:15Z,2016-07-21T12:46:15Z,"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();
}}}",anonymous
12335,Integer overflow in use counter of shared pointers.,smart_ptr,Boost 1.61.0,To Be Determined,Bugs,Peter Dimov,new,2016-07-20T09:27:16Z,2016-07-20T09:27:16Z,"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)",Christian Wressnegger <c.wressnegger@…>
12332,Couple of bugs found in version 1.60.0,program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-07-18T13:58:07Z,2016-07-18T16:59:33Z,"Hi Boost,

Please note the following bug report

'''BUG-1'''[[BR]]
File: 1.60.0\boost\program_options\detail\cmdline.hpp[[BR]]
Line: 139[[BR]]
Expression: 'args'[[BR]]
The bug:[[BR]]
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'''[[BR]]
File:  1.60.0\libs\program_options\src\variables_map.cpp[[BR]]
Line:  71[[BR]]
Expression: '
{{{
string original_token =
}}}
 ...'[[BR]]
The bug:[[BR]]
Variable 'original_token' is already defined in this scope at line 43.
This new declaration of same variable hides previous declaraion.

Thanks, Paz
",Paz_Offer@…
12331,BOOST_FUSION_ADAPT_STRUCT doesn't work with empty struct on Visual Studio,fusion,Boost 1.61.0,To Be Determined,Bugs,Joel de Guzman,reopened,2016-07-18T12:06:18Z,2016-07-29T08:00:15Z,"The following code works fine on GCC and Clang:

{{{#!c++
#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
}}}",Benoit Blanchon <benoit@…>
12326,boost::iostreams -- CRC error while decompressing certain gzip files,iostreams,Boost 1.61.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-07-13T14:08:38Z,2016-07-13T14:08:38Z,"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
",joel.nordell@…
12325,Boost syslog as TCP,log,Boost 1.61.0,To Be Determined,Feature Requests,Andrey Semashev,new,2016-07-13T13:05:22Z,2016-07-13T13:05:22Z,The boost syslog backend only supports UDP. TCP would be appreciated. Log4j does support this e.g.,Hendrik Schall
12320,add an example to demonstrate how to leverage sockets concurrently in multithreading scenarios,asio,Boost 1.61.0,Boost 1.62.0,Patches,chris_kohlhoff,new,2016-07-09T09:06:56Z,2016-07-09T09:06:56Z,"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.

",luxiaoshuang@…
12318,Problem using Boost 1.61.0 with VTK Marching Cubes,Building Boost,Boost 1.61.0,To Be Determined,Tasks,,new,2016-07-08T12:42:13Z,2016-07-08T12:42:13Z,"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:

{{{#!c++
#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:
{{{#!c++
#  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:
{{{#!c++
#  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.",psmit057@…
12316,"ASIO: ""Undefined error: 0"" on the Mac OS 10.10 and 10.11",asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-07-07T14:30:49Z,2017-03-12T05:33:06Z,"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!",David Dovodov <ddovod@…>
12315,boost::interprocess_exception - library_error exception when creating shared_memory_object,interprocess,Boost 1.58.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-07-07T08:59:17Z,2017-02-20T12:14:09Z,[http://stackoverflow.com/questions/38045857/boostinterprocess-exception-library-error-exception-when-creating-shared-mem Problem description and workaround],Oleg
12314,boost::geometry::within for a point in a geographic coordinate system fails,geometry,Boost 1.61.0,To Be Determined,Bugs,Barend Gehrels,new,2016-07-07T07:47:37Z,2017-01-03T13:51:34Z," 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;
}

}}}

",oleary.simon@…
12313,sockaddr_storage_type doesn't have a member named ss_len,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-07-07T05:17:21Z,2017-04-25T11:00:28Z,"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
",Takatoshi Kondo <redboltz@…>
12312,UTF8 system error reporting for Win32,system,Boost 1.61.0,To Be Determined,Feature Requests,Beman Dawes,new,2016-07-05T06:07:42Z,2016-08-19T21:19:06Z,"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.
",anonymous
12310,"xlc++: lexical_cast.hpp ""invalid processing token""",range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2016-07-01T15:02:24Z,2017-03-01T15:53:14Z,"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?",jlost@…
12306,"boost::filesystem::remove_all(const path& p, system::error_code& ec) throws while it shouldn't",filesystem,Boost 1.59.0,To Be Determined,Bugs,Beman Dawes,new,2016-06-30T10:41:58Z,2016-09-04T09:18:16Z,"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!",christophe.calmejane@…
12305,"Requirements for traits::interior_{const,mutable}_type",geometry,Boost 1.61.0,To Be Determined,Bugs,Barend Gehrels,new,2016-06-30T01:33:04Z,2016-11-02T14:07:41Z,"The [http://www.boost.org/doc/libs/1_61_0/libs/geometry/doc/html/geometry/reference/concepts/concept_polygon.html 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 [https://github.com/boostorg/geometry/blob/boost-1.61.0/include/boost/geometry/algorithms/detail/overlay/convert_ring.hpp#L90 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?",john.firebaugh@…
12304,Incorrect documentation for boost::geometry::traits::ring_type,geometry,Boost 1.61.0,To Be Determined,Bugs,Barend Gehrels,new,2016-06-30T01:15:50Z,2016-08-26T13:41:17Z,"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`.",john.firebaugh@…
12302,Warning while installing boost libraries,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-06-27T12:02:26Z,2016-08-19T21:20:29Z,"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?",shopping_vineeshvs@…
12301,problem building 1.61.0,filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2016-06-26T12:42:51Z,2016-08-29T10:50:12Z,"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

",drmhkelley@…
12298,epool_wait hang,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-06-23T10:22:34Z,2017-02-22T06:58:01Z,"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 ??",baibin <406455861@…>
12297,epoll_wait hang,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-06-23T10:15:07Z,2016-06-23T10:15:07Z,"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 ??



",baibin <406455861@…>
12295,Boost Asio Serial Port does not work with Exar (Baudrate zero),asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-06-22T18:47:15Z,2018-02-09T09:46:50Z,"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",Andreas Schmitz <andreas.schmitz13@…>
12294,boost::geometry::union_ empty result,geometry,Boost 1.61.0,To Be Determined,Bugs,Barend Gehrels,new,2016-06-22T18:10:53Z,2016-06-22T18:23:45Z,"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.",phelippeneveu@…
12292,[TypeErasure] Construction of any from static_binding fails if compiling with rvalue-ref support,type_erasure,Boost Development Trunk,To Be Determined,Bugs,Steven Watanabe,new,2016-06-22T11:05:31Z,2017-03-22T21:47:47Z,"Although the documentation of **Boost.Type``Erasure** 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
",Deniz Bahadir <D.Bahadir@…>
12284,Library requirements errors.,wave,Boost Development Trunk,To Be Determined,Bugs,Hartmut Kaiser,new,2016-06-17T18:47:02Z,2016-06-17T18:47:02Z,"====== 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 ======
",René Rivera
12283,Library requirements errors.,dynamic_bitset,Boost Development Trunk,To Be Determined,Bugs,jsiek,new,2016-06-17T18:35:12Z,2016-06-17T18:35:12Z,"====== 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 ======
",René Rivera
12281,Library requirements errors.,concept_check,Boost Development Trunk,To Be Determined,Bugs,jsiek,new,2016-06-17T18:30:30Z,2016-06-17T18:30:30Z,"====== 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 ======
",René Rivera
12279,Library requirements errors.,tokenizer,Boost Development Trunk,To Be Determined,Bugs,jsiek,new,2016-06-17T18:28:02Z,2017-04-25T20:20:30Z,"====== 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 ======
",René Rivera
12278,Library requirements errors.,smart_ptr,Boost Development Trunk,To Be Determined,Bugs,Peter Dimov,new,2016-06-17T18:26:15Z,2016-06-17T18:26:56Z,"====== 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 ======
",René Rivera
12277,Library requirements errors.,rational,Boost Development Trunk,To Be Determined,Bugs,Jonathan Turkanis,new,2016-06-17T18:07:44Z,2016-06-17T18:07:44Z,"====== 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 ======
",René Rivera
12272,vertex_iterator dereference has odd return value,graph,Boost 1.61.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-06-15T16:22:37Z,2016-06-15T16:22:37Z,"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.

{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!cpp
#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;
}
  }}}
}}}",ich.freak@…
12271,segfaults in options_description with -fipa-pta,program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-06-15T08:23:18Z,2016-06-28T00:55:07Z,"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.",Seth <sshannin@…>
12269,wrong error code,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-06-14T08:30:47Z,2016-06-14T08:30:47Z,"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).",anonymous
12268,Boost Polygon: Overflow issue with euclidean_distance() when using large (32-bit) coordinates.,polygon,Boost 1.61.0,To Be Determined,Bugs,Lucanus Simonson,new,2016-06-14T07:46:32Z,2016-06-15T20:49:28Z,"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.

",Pallav Gupta <drpallavgupta@…>
12267,How to build boost with Boost.Build using Clang 3.7 with Microsoft CodeGen instead of the original Visual C++ compiler?,Building Boost,Boost 1.61.0,To Be Determined,Support Requests,,new,2016-06-12T00:14:28Z,2016-06-12T00:14:28Z,"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",JUAN DENT <juandent@…>
12266,Visual Studio 2015 Express for Desktop and 64-bit builds,Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-06-11T21:15:15Z,2016-06-11T21:37:27Z,"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).




",carles.cufi@…
12264,queue<Apple*> can pop to Orange* even when Apples don't relate to Oranges,lockfree,Boost 1.61.0,To Be Determined,Bugs,timblechmann,new,2016-06-10T20:04:29Z,2016-06-10T20:04:29Z,"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
",Jacob Burckhardt <JBurckhardt@…>
12263,"ublas matrix iterators do not include ""->"" member access (dereferencing) operator, although the operator is referenced in the documentation",uBLAS,Boost 1.61.0,To Be Determined,Bugs,Gunter,new,2016-06-10T14:09:03Z,2016-06-10T14:09:32Z,"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.",douglas.schuyler@…
12261,LT_HalfPrevLoT and GT_HalfSuccHiT are not symmetrical,numeric,Boost 1.61.0,To Be Determined,Bugs,Fernando Cacciola,new,2016-06-10T12:38:46Z,2016-08-12T19:49:12Z,"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
}}}

",Christophe Brassart <christophe.brassart@…>
12259,"improved version of boost::property_tree::ini_parser, which handles comments in INI-files",property_tree,Boost Release Branch,To Be Determined,Patches,Sebastian Redl,new,2016-06-09T09:20:30Z,2016-06-09T09:20:30Z,"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)",jan.krieger@…
12255,Centroid for polygon failed to compile for rational coordinate,geometry,Boost 1.61.0,To Be Determined,Bugs,Barend Gehrels,new,2016-06-07T13:41:47Z,2016-06-09T10:48:59Z,"If I use rational coordinate, centroid function for polygon failed to compile.
",andyplekhanov@…
12254,NULL reference to error_code passing to noexcept functions caused std::terminate,filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2016-06-07T08:27:29Z,2016-06-07T10:39:07Z,"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.
",aerisnju@…
12252,"numeric_cast<int64_t>(pow(2.0, 63.0)) doesn't throw",numeric,Boost 1.58.0,To Be Determined,Bugs,Douglas Gregor,new,2016-06-06T19:11:33Z,2016-06-06T19:11:33Z,"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]",wellnhofer@…
12251,Add constexpr support to random number generators,random,Boost 1.61.0,Boost 1.62.0,Feature Requests,No-Maintainer,new,2016-06-03T17:06:37Z,2016-06-03T17:31:13Z,"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)",Guillem Blanco <gblanco92@…>
12249,Wrong operator|() overload being found on multiple platforms & causing compilation failure,range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2016-06-02T15:47:39Z,2016-06-02T18:21:00Z,"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.",rob.desbois@…
12243,Boost.Serialization compilation error in Visual Studio with Zc:wchar_t-,serialization,Boost 1.61.0,To Be Determined,Bugs,Robert Ramey,new,2016-06-01T15:30:09Z,2017-06-13T17:10:38Z,"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'.

",anonymous
12240,Documentation for data-driven testing should explictly mention std::tuple,test,Boost 1.61.0,To Be Determined,Feature Requests,Raffi Enficiaud,assigned,2016-05-31T14:09:03Z,2016-09-29T14:14:53Z,"`BOOST_DATA_TEST_CASE()` handles ranges of `std::tuple`s differently to ranges of other types, in that it expects to be able to expand the parts of the tuples out to multiple variables. Whether or not this is intended or just a side-effect of the implementation, I think it's a sensible behaviour. Indeed, it's quite useful to be able to supply `BOOST_DATA_TEST_CASE()` with pre-zipped data rather than always having to use `^`.

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

Many thanks for your work on this library.",Tony Lewis <tonyelewis@…>
12239,Filesystem compiler error when using Clang 3.7 in Microsoft Windows,filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2016-05-31T01:15:53Z,2016-06-05T17:38:29Z,"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",JUAN DENT <juandent@…>
12238,Boost fails to compile using OpenSSL 1.1.0,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-05-30T23:32:58Z,2016-09-28T23:31:24Z,"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).",noloader@…
12232,boost::interprocess::intermodule_singleton initialization failed in Windows 2012 Server,interprocess,Boost 1.59.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-05-28T00:57:40Z,2016-09-28T11:01:39Z,"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!

",rafael.bronzeri@…
12231,How to build boost with CMake?,Building Boost,Boost Development Trunk,Boost 1.61.0,Support Requests,,new,2016-05-27T17:31:05Z,2016-05-27T23:00:27Z,"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 ",juandent@…
12229,intrusive::unordered_set<T>::rehash() broken,intrusive,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-05-27T11:13:19Z,2016-11-10T09:04:45Z,"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.",Christian Kaiser <boost@…>
12219,Compilation error using input_seekable with gzip_decompressor(),iostreams,Boost 1.58.0,To Be Determined,Support Requests,Jonathan Turkanis,new,2016-05-22T01:19:15Z,2016-06-05T17:41:36Z,"
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>          ]",efrain.astudillo58@…
12218,Compilation error using input_seekable with gzip_decompressor(),iostreams,Boost 1.58.0,To Be Determined,Support Requests,Jonathan Turkanis,new,2016-05-22T01:18:41Z,2016-08-19T21:21:40Z,"
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>          ]
}}}",anonymous
12217,boost.iostreams on Android can't find ZLIB,iostreams,Boost 1.61.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-05-20T10:09:21Z,2016-05-20T10:10:36Z,"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.

* Linux log: https://s3.amazonaws.com/archive.travis-ci.org/jobs/131643137/log.txt
* OSX log: https://s3.amazonaws.com/archive.travis-ci.org/jobs/131643139/log.txt",ruslan_baratov@…
12211,boost::multiprecision cpp_int renders string inconsistently w.r.t. locale,multiprecision,Boost 1.59.0,To Be Determined,Bugs,John Maddock,new,2016-05-17T08:08:49Z,2016-10-23T17:15:19Z,"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.",Tassilo Glander <tassilo.glander@…>
12208,Lexer does not work with boost::spirit::istream_iterator,wave,Boost 1.61.0,To Be Determined,Bugs,Hartmut Kaiser,new,2016-05-16T06:14:06Z,2017-11-24T23:29:03Z,"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.",edaskel@…
12207,allocate_shared using fast_pool_allocator results in member vector iterator memory corruption on MSVC,pool,Boost 1.61.0,To Be Determined,Bugs,Chris Newbold,new,2016-05-15T20:26:37Z,2016-05-15T20:26:37Z,"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"").",esas
12206,"gcc 6.1 reports ""misleading-indentation"" warning",algorithm,Boost 1.61.0,To Be Determined,Bugs,Marshall Clow,new,2016-05-15T17:27:11Z,2016-05-16T14:48:20Z,"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;
     ^~~~~~",yuri.borisoff@…
12205,FTBFS boost.serialization 1.61: undefined reference to boost::archive::codecvt_null<wchar_t>,serialization,Boost 1.61.0,To Be Determined,Bugs,Robert Ramey,new,2016-05-14T13:15:39Z,2017-11-26T18:42:05Z,"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.



",xantares
12197,is_valid returns self-intersection error for multipolygons with many decimal,geometry,Boost 1.59.0,To Be Determined,Bugs,Barend Gehrels,new,2016-05-12T21:10:49Z,2016-05-16T17:57:49Z,"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;
}}}",jean.sebastien.carrier@…
12188,Valgrind reports invalid delete after using boost::asio::ip::tcp::resolver.resolve,asio,Boost 1.60.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-05-10T13:34:06Z,2016-05-10T13:34:06Z,"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)
}}}",Mateusz Wójcik <mateusz.wojcik@…>
12187,Boost-bugs Archive link does not work,website,Boost 1.61.0,Website 1.X,Bugs,René Rivera,new,2016-05-10T11:23:55Z,2016-05-10T11:23:55Z,"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",nayana4u@…
12186,Inclusion order for labeled_graph,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-05-10T08:04:59Z,2016-08-10T11:49:27Z,"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*[])
{
}
}}}
",scott_paulin@…
12185,bootstrap for boost_60_0 does not work for Visual Studio 2013,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2016-05-09T19:19:51Z,2016-05-10T10:38:04Z,"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.",peter.raeth@…
12182,boost::asio async_send corrupts memory on Visual Studio 2015 x64 build,asio,Boost 1.60.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-05-08T14:19:43Z,2016-05-08T14:19:43Z,"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:

{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!cpp
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

{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!cpp
  // 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:

{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!cpp
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++
}}}
",a-pavlov <dkfsoft@…>
12180,Date time parsing with a particular format string dereferences an end iterator,date_time,Boost Development Trunk,To Be Determined,Bugs,az_sw_dude,new,2016-05-06T10:18:05Z,2016-05-09T13:24:50Z,"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;
}}}",sascha.zelzer@…
12174,Tokenizer delivers additional null byte - string token,tokenizer,Boost 1.59.0,To Be Determined,Bugs,jsiek,new,2016-05-03T10:28:12Z,2016-05-13T06:55:58Z,"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.",Peter Caspers <pcaspers1973@…>
12173,error: Unable to load Jamfile.,config,Boost 1.61.0,To Be Determined,Bugs,John Maddock,new,2016-05-03T09:17:41Z,2017-01-05T09:40:00Z,"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?",Nico Schlömer <nico.schloemer@…>
12172,Warning in ublas/matrix_expression.hpp from GCC 6.1.0 -Wmisleading-indentation,uBLAS,Boost Development Trunk,To Be Determined,Bugs,Gunter,new,2016-05-02T16:59:38Z,2017-08-01T18:34:53Z,"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.",lopresti@…
12169,error when copying blocks into a dynamic_bitset with size() not an integral number of bits_per_block,dynamic_bitset,Boost 1.61.0,To Be Determined,Bugs,jsiek,new,2016-04-29T14:25:57Z,2016-04-29T14:25:57Z,"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
",Diab Jerius <djerius@…>
12168,Issue with shared_ptr on boost python,smart_ptr,Boost 1.58.0,To Be Determined,Bugs,Peter Dimov,new,2016-04-28T15:19:19Z,2016-04-28T15:46:09Z,"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",praveenkumar076@…
12165,Build filesystem for Windows Runtime,filesystem,Boost 1.61.0,To Be Determined,Patches,Beman Dawes,new,2016-04-27T22:37:47Z,2016-04-27T22:37:47Z,"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.",Yury Kirpichev <ykirpichev@…>
12164,Build filesystem for Windows Runtime,filesystem,Boost 1.61.0,To Be Determined,Patches,Beman Dawes,new,2016-04-27T22:37:36Z,2016-04-27T22:37:36Z,"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.",Yury Kirpichev <ykirpichev@…>
12163,`void boost::algorithm::replace_all()`'s documentation describes the return value,algorithm,Boost 1.60.0,To Be Determined,Bugs,Marshall Clow,new,2016-04-27T18:14:38Z,2016-04-28T15:49:33Z,"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`",milleniumbug <wojas1222@…>
12162,buffer interface violates strict-aliasing rule,endian,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-04-27T12:08:13Z,2016-04-27T12:08:13Z,"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

",Vinnie Falco <vinnie.falco@…>
12161,Broken link in HTML documentation,endian,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-04-27T11:16:13Z,2016-04-27T11:16:13Z,"This link produces a 404
http://www.boost.org/doc/libs/1_60_0/libs/endian/include/boost/endian/conversion.hpp
",Vinnie Falco <vinnie.falco@…>
12159,"file_descriptor(int,flags) constructor fails",iostreams,Boost 1.58.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-04-26T22:44:26Z,2016-04-26T22:49:42Z,"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.

",Dylan Doxey <dylan.doxey@…>
12158,boost::size() and friends should use an ADL barrier like boost::begin,range,Boost 1.60.0,To Be Determined,Feature Requests,Neil Groves,assigned,2016-04-26T21:35:42Z,2016-04-26T21:55:11Z,"boost::begin() and boost::end() are nicely declared in an ADL barrier namespace to avoid conflicts with code like this:

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

[http://isocpp.org/files/papers/n4280.pdf N4280] has been accepted into C++17, which adds std::size, std::empty, and std::data.  But if users attempt to use those in the same way:

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

They may get an error.  For example, if c is a std::vector<boost::shared_ptr<int>> or something, boost::size() will be found by ADL, and since it's no more specific than std::size, the call will be ambiguous.",Tavian Barnes <tavianator@…>
12156,AddressSanitizer reports stack-buffer-overflow for error_with_option_name::substitute_placeholders,program_options,Boost 1.61.0,To Be Determined,Bugs,Vladimir Prus,new,2016-04-26T13:37:10Z,2016-04-26T13:37:10Z,"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)
}}}
",Dan Berger <danielberger@…>
12154,"[program_options] disable ""long_allow_adjacent"" and ""short_allow_adjacent"",it doesn't work",program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-04-26T08:14:06Z,2016-04-26T08:40:48Z,"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)",714702751@…
12153,"[program_options] disable ""long_allow_adjacent"" and ""short_allow_adjacent"",it doesn't work",program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-04-26T08:13:38Z,2016-04-26T08:13:38Z,"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)",714702751@…
12151,Example UDP async server stops on error...,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-04-23T15:19:11Z,2016-10-02T17:03:51Z,"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",Micah Quinn <micah.quinn@…>
12150,"posix_recursive_mutex constructor never called, fails to init mutex",interprocess,Boost 1.60.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-04-22T18:26:39Z,2016-04-22T18:26:39Z,"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.
",adrian.cheater@…
12149,"boost::property_tree::write_json(stream, root, /*pretty=*/false)  gives extra std::endl at the end",property_tree,Boost 1.57.0,To Be Determined,Bugs,Sebastian Redl,new,2016-04-22T16:24:51Z,2016-04-22T22:56:19Z,"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)",anonymous
12148,VS2015 warning: macro redefinition,endian,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-04-22T16:08:06Z,2016-04-22T16:08:06Z,"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'",wbu@…
12145,boost::geometry::remove_spikes doesn't remove spike,geometry,Boost 1.60.0,To Be Determined,Bugs,Barend Gehrels,new,2016-04-21T22:07:44Z,2016-04-21T22:07:44Z,"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
}

}}}",xiongzubiao@…
12144,Clang 3.9 trunk DONT_USE_HAS_NEW_OPERATOR warning,serialization,Boost 1.61.0,To Be Determined,Bugs,Robert Ramey,reopened,2016-04-21T19:02:13Z,2017-04-18T14:06:25Z,"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
}}}",drivehappy@…
12143,Preferred separator not exported in dll under Windows,filesystem,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-04-21T14:08:31Z,2016-09-04T09:39:36Z,"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
}}}

",andrei_damian2620000@…
12141,XML serialization broken,serialization,Boost 1.61.0,To Be Determined,Bugs,Robert Ramey,reopened,2016-04-20T18:27:14Z,2017-11-08T16:40:52Z,"The Boost 1.61.0 beta1 version of serialization has a breaking regression that changes the XML closing tag to `&lt;/boost_serialization&gt;` rather than `</boost_serialization>`.

Example code:

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

}}}",Tony Lewis <tonyelewis@…>
12139,Voronoi diagram contains NaN coordinates,polygon,Boost 1.60.0,To Be Determined,Bugs,Lucanus Simonson,new,2016-04-19T13:21:23Z,2016-04-19T15:03:18Z,"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++
",Piotr Wieczorek <pwiecz@…>
12137,boost::interprocess::intermodule_singleton initialization failed,interprocess,Boost 1.60.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-04-18T23:01:55Z,2017-06-01T17:09:11Z,"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.",Valentin Shtronda <valiko.ua@…>
12135,Boost.Concepts shoudn't create typedefs based on line number,concept_check,Boost 1.60.0,To Be Determined,Bugs,jsiek,new,2016-04-17T23:00:53Z,2016-04-17T23:00:53Z,"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:

{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!C++
// a.h
#include <boost/concept_check.hpp>

BOOST_CONCEPT_ASSERT((boost::Integer<int>)); // note line number
  }}}
}}}


{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!C++
// b.h
#include <boost/concept_check.hpp>

BOOST_CONCEPT_ASSERT((boost::UnsignedInteger<unsigned int>)); // note line number
  }}}
}}}


{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!C++
// main.cpp
#include ""a.h""
#incldue ""b.h""

int main(){}
  }}}
}}}

",russellgreene8@…
12134,Boost.Concepts shoudn't create typedefs based on line number,concept_check,Boost 1.60.0,To Be Determined,Bugs,jsiek,new,2016-04-17T23:00:38Z,2016-04-17T23:00:38Z,"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:

{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!C++
// a.h
#include <boost/concept_check.hpp>

BOOST_CONCEPT_ASSERT((boost::Integer<int>)); // note line number
  }}}
}}}


{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!C++
// b.h
#include <boost/concept_check.hpp>

BOOST_CONCEPT_ASSERT((boost::UnsignedInteger<unsigned int>)); // note line number
  }}}
}}}


{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!C++
// main.cpp
#include ""a.h""
#incldue ""b.h""

int main(){}
  }}}
}}}

",russellgreene8@…
12133,cpp_dec_float should compare to precision,multiprecision,Boost 1.60.0,To Be Determined,Bugs,John Maddock,new,2016-04-17T08:50:37Z,2016-06-05T18:21:51Z,"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)",scottopoly@…
12132,ubuntu 64 bit icu detaction fails,regex,Boost 1.60.0,To Be Determined,Bugs,John Maddock,new,2016-04-16T15:30:04Z,2018-01-23T21:33:16Z,"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
",konstantin.kivi@…
12131,Boost Asio async HTTP Client example source code incorrect,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-04-16T08:03:45Z,2016-10-02T17:03:25Z,"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"";
    }
  }
}}}",Micah Quinn <micah.quinn@…>
12129,C++11 / C++14 compability in boost/iostreams,iostreams,Boost Development Trunk,To Be Determined,Bugs,Jonathan Turkanis,new,2016-04-15T12:34:52Z,2016-06-03T08:24:43Z,"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",Christian Meesters <meesters@…>
12128,Stage .pdb Files for Debug and Release - VS2015,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2016-04-14T21:45:28Z,2016-08-17T13:39:16Z,"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,",Will Bickford <wbickford@…>
12127,Invoking a library's build//stage ignores --stagedir,build,Boost 1.61.0,To Be Determined,Bugs,Vladimir Prus,new,2016-04-14T17:52:06Z,2016-04-14T17:52:06Z,"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`.",Peter Dimov
12125,Another problems performing boolean operations on polygons with shared edges,geometry,Boost 1.61.0,Boost 1.63.0,Bugs,Barend Gehrels,assigned,2016-04-13T22:43:43Z,2016-10-28T16:17:05Z,"Trying to solve problems with union_ operation on mpolygons with shared edges (https://svn.boost.org/trac/boost/ticket/12118) with help of boost 1.61.0 beta.
But instead of getting problems with zero areas, I'm getting really wrong result.

For example

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

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

Union result (same as currentPath, appended Polygon was totally ignored)[[BR]]
MULTIPOLYGON(((-5.96064376831054687500 -17.19871711730957031250,7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,19.66869926452636718750 -14.42036247253417968750,-5.96064376831054687500 -17.19871711730957031250)),((-14.87041568756103515625 -6.99879980087280273438,-16.12161636352539062500 -18.30021858215332031250,-5.96064376831054687500 -17.19871711730957031250,-14.87041568756103515625 -6.99879980087280273438)))",ev.mipt@…
12122,Socket get_option throwing length_error exceptions,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-04-12T16:12:48Z,2016-06-01T21:03:22Z,"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:

1. 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.

2. 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.",Chris White <chriswhitemsu@…>
12119,Symlinks not supported when compiled on MSYS2 MinGW64 Windows 7,filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2016-04-10T20:56:54Z,2016-04-17T08:45:54Z,"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:"". ",Mario Emmenlauer <mario@…>
12116,"filesystem::path::iterator does not work correctly with ""\\?\UNC\{servername}"" paths",filesystem,Boost 1.61.0,To Be Determined,Bugs,Beman Dawes,new,2016-04-06T20:34:24Z,2016-04-06T20:34:24Z,"{{{
#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
}}}",jim@…
12115,Boost.Asio compile error on Visual Studio 2015 Update 2,asio,Boost 1.60.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-04-06T07:53:12Z,2016-05-16T03:57:54Z,"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(""

{{{
#!cpp
#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)
}}}",Sergey Svistunov <zenden2k@…>
12113,./boost/mpi/communicator.hpp:1260:3: error: 'array' is not a member of 'boost::serialization',mpi,Boost Release Branch,To Be Determined,Bugs,Matthias Troyer,new,2016-04-05T08:51:25Z,2016-04-05T09:16:49Z,Boost.MPI no longer compiles because boost::serialization::array has been renamed to boost::serialization::array_view,lukeocamden@…
12111,use std placeholders in boost::bind in c++11,bind,Boost 1.60.0,To Be Determined,Bugs,Peter Dimov,new,2016-04-03T20:30:11Z,2016-04-03T20:30:11Z,"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
",anonymous
12109,C4100 warning (unreferenced formal parameter) in json_parser,property_tree,Boost 1.60.0,To Be Determined,Bugs,Sebastian Redl,new,2016-04-01T11:43:16Z,2016-04-01T11:52:43Z,"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'.",gigaplex@…
12108,boost::filesystem::canonical() enters infinite loop when current path is a directory symlink on windows,filesystem,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-04-01T08:02:02Z,2016-07-12T08:48:16Z,"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



",Tony Abbott <tony.abbott@…>
12104,windows - Visual Studio 2015 Update 2 RC gives out warning C4191 in thread_primitive.hpp,thread,Boost 1.60.0,To Be Determined,Bugs,viboes,assigned,2016-03-30T22:21:21Z,2017-09-16T16:48:44Z,"
{{{
thread/win32/thread_primitives.hpp(312): warning C4191: 'type cast': unsafe conversion from 'boost::detail::win32::farproc_t' to 'boost::detail::win32::detail::gettickcount64_t'
}}}

Calling this function through the result pointer may cause your program to fail",Shane Mathews (oneZero Financial Systems) <smathews@…>
12100,including <boost/accumulators/statistics/rolling_mean.hpp> brings static c++ initializers into my code,accumulator,Boost 1.61.0,To Be Determined,Bugs,Eric Niebler,new,2016-03-26T22:17:50Z,2016-03-26T22:17:50Z,"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.",Richard Powell <rmpowell77@…>
12099,Ziggurat implementation of boost::random::exponential_distribution,random,Boost Development Trunk,To Be Determined,Patches,No-Maintainer,new,2016-03-25T20:19:58Z,2016-03-25T20:47:53Z,"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?",Jason Rhinelander <jason@…>
12096,Typo at the regex description's page?,regex,Boost 1.61.0,To Be Determined,Bugs,John Maddock,new,2016-03-25T06:13:17Z,2017-04-09T12:23:51Z,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?..,beaux_monde@…
12091,"help2man compatibility: add one more space between ""arg"" and description",program_options,Boost 1.61.0,To Be Determined,Bugs,Vladimir Prus,new,2016-03-23T12:24:52Z,2016-10-11T21:16:32Z,"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.",Timo Weingärtner <timo@…>
12087,transform_iterator is not assignable in VS2015,iterator,Boost 1.60.0,To Be Determined,Bugs,jeffrey.hellrung,new,2016-03-22T13:55:07Z,2016-03-22T16:59:17Z,"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",bswerts@…
12086,Fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-sgd-1_34_1.lib',Building Boost,Boost 1.34.1,To Be Determined,Support Requests,,new,2016-03-22T12:31:49Z,2016-03-23T11:23:28Z,"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
",greatsaurav@…
12083,Rounding mode not restored when using save_state rounding struct on x64,numeric,Boost 1.60.0,To Be Determined,Bugs,Douglas Gregor,new,2016-03-21T17:24:42Z,2016-03-21T17:24:42Z,"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);
}
",Aaron Balog <abalog@…>
12081,the minmax creates dangling references too easily,minmax,Boost 1.60.0,To Be Determined,Bugs,Marshall Clow,new,2016-03-20T20:23:47Z,2018-02-21T22:20:01Z,"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 [[BR]]
http://www.boost.org/doc/libs/1_60_0/libs/algorithm/minmax/example/minmax_ex.cpp

[[BR]]

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

I think we should change the return type from tuple<T const&, T const&> to tuple<T,T>.

See also: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/HLiJJBRNYSw",anonymous
12080,Boost:asio::address incompatible 32 and 64 bit,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-03-20T14:08:39Z,2016-03-20T14:08:39Z,"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.",max_shifrin@…
12079,Infinite loop in boost:: filesystem::directory_iterator,filesystem,Boost Release Branch,To Be Determined,Bugs,Beman Dawes,new,2016-03-19T21:09:05Z,2016-03-19T21:12:32Z,"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:
{{{#!c++
  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.",alexb.x42@…
12078,Warnings in boost/core/swap.hpp when using nvcc,core,Boost Development Trunk,To Be Determined,Bugs,Peter Dimov,new,2016-03-19T16:00:54Z,2016-08-19T21:22:03Z,"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.",Karl Ljungkvist <k.ljungkvist@…>
12077,gcc: error: CreateProcess: No such file or directory,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2016-03-19T15:02:22Z,2016-03-19T15:43:15Z,"
{{{
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
}}}
 

",james@…
12073,Why read callback not call,asio,Boost 1.48.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-03-17T01:45:12Z,2017-06-14T08:21:49Z,"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?",zhjie007@…
12071,Using iterator_facade with range-v3 fails to compile,iterator,Boost 1.61.0,To Be Determined,Bugs,jeffrey.hellrung,new,2016-03-16T15:36:58Z,2016-04-20T15:21:25Z,"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}}}.",Krzysztof Czaiński <1czajnik@…>
12069,hexfloat not respected for float128,multiprecision,Boost 1.60.0,To Be Determined,Bugs,John Maddock,new,2016-03-16T06:08:54Z,2016-03-16T06:08:54Z,"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.",Ruslan <b7.10110111@…>
12068,boost::filtered_range is not default constructible,range,Boost 1.59.0,To Be Determined,Feature Requests,Neil Groves,new,2016-03-14T15:50:49Z,2016-03-14T17:11:19Z,"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)),

",Aleksej Lebedev <root@…>
12067,polygon/voronoi missing edges,polygon,Boost 1.57.0,To Be Determined,Bugs,Lucanus Simonson,new,2016-03-14T14:28:52Z,2016-03-15T10:33:31Z,"For the following input to the voronoi builder (or the voronoi visualizer from the examples dir, from which the attached image was generated)

{{{
6
-10 -20
10 -20
5 0
10 20
-10 20
-5 0
}}}

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.
",n4tivex@…
12065,Boost program options throws an exception,program_options,Boost 1.59.0,To Be Determined,Bugs,Vladimir Prus,new,2016-03-12T20:21:58Z,2016-03-12T20:21:58Z," 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",Thomas Milotti <thomas.milotti@…>
12063,boost include directives use double quotes incorrectly,range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2016-03-12T18:06:51Z,2016-03-12T18:06:51Z,"

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.
",John Maddock
12062,boost include directives use double quotes incorrectly,property_tree,Boost 1.61.0,To Be Determined,Bugs,Sebastian Redl,new,2016-03-12T18:06:18Z,2016-03-12T18:06:18Z,"

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.
",John Maddock
12061,boost include directives use double quotes incorrectly,numeric,Boost 1.61.0,To Be Determined,Bugs,Douglas Gregor,new,2016-03-12T18:05:03Z,2016-03-12T18:05:03Z,"

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.
",John Maddock
12060,boost include directives use double quotes incorrectly,lambda,Boost 1.61.0,To Be Determined,Bugs,No-Maintainer,new,2016-03-12T18:03:45Z,2016-03-12T18:03:45Z,"

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.
",John Maddock
12058,boost include directives use double quotes incorrectly,core,Boost 1.61.0,To Be Determined,Bugs,Peter Dimov,new,2016-03-12T18:01:10Z,2016-03-12T18:01:10Z,"

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.
",John Maddock
12056,boost include directives use double quotes incorrectly,multi_array,Boost 1.61.0,To Be Determined,Bugs,Ronald Garcia,new,2016-03-12T17:58:54Z,2016-03-12T17:58:54Z,"

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.
",John Maddock
12055,boost include directives use double quotes incorrectly,dynamic_bitset,Boost 1.61.0,To Be Determined,Bugs,jsiek,new,2016-03-12T17:58:19Z,2016-03-12T17:58:19Z,"

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.
",John Maddock
12054,boost include directives use double quotes incorrectly,date_time,Boost 1.61.0,To Be Determined,Bugs,az_sw_dude,new,2016-03-12T17:57:30Z,2016-03-12T17:57:30Z,"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.
",John Maddock
12051,"offset_ptr<void , boost::int32_t, boost::uint64_t> is saved incorrectly on win32",interprocess,Boost 1.61.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-03-11T15:44:42Z,2016-03-11T15:44:42Z,"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",anonymous
12048,Deprecated libstdc++ header used in adjacency_list.hpp,graph,Boost 1.59.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-03-09T13:40:31Z,2016-08-09T08:37:14Z,"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",friedrich.grabner@…
12046,Error of fatal error: quadmath.h:  - Rhel7,Building Boost,Boost 1.60.0,To Be Determined,Support Requests,,new,2016-03-08T05:32:50Z,2016-03-17T21:30:59Z,"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 ?",abdul.p78@…
12045,Bug in condition_algorithm_8a<ConditionMembers>::wait when using timed wait,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-03-07T11:13:46Z,2016-03-19T15:47:00Z,"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.


",yochait@…
12041,fusion::traits for proxy types,fusion,Boost 1.61.0,To Be Determined,Feature Requests,Joel de Guzman,new,2016-03-04T16:25:52Z,2016-03-05T11:42:49Z,"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.",jensweller@…
12040,The result of compilation relies upon the inclusion order of grep_serialize.hpp and gregorian.hpp,date_time,Boost 1.58.0,To Be Determined,Bugs,az_sw_dude,new,2016-03-03T18:04:24Z,2016-03-03T18:04:24Z,"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.",laurent.stacul@…
12038,Max-flow algorithms not working with named parameters.,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-03-02T14:56:52Z,2016-05-03T08:44:57Z,"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`
{{{#!cpp
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
{{{#!cpp
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:
{{{#!cpp
#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;
}
}}}",Maël Valais <mael.valais@…>
12037,boost::program_options tests cannot be built for both release and debug variants at the same time,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2016-03-01T18:06:24Z,2016-03-09T07:05:39Z,"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) ",Diego Barrios Romero <eldruin@…>
12035,Please add constexpr and noexcept qualifiers,range,Boost 1.61.0,To Be Determined,Feature Requests,Neil Groves,new,2016-03-01T13:00:43Z,2016-03-01T13:00:43Z,where applicable (similarly to what string_ref offers)...,Domagoj Šarić
12034,missing qualifier for sprintf in numeric/odeint/integrate/max_step_checker.hpp,odeint,Boost Development Trunk,To Be Determined,Bugs,karsten,new,2016-03-01T03:45:50Z,2016-03-01T03:51:46Z,"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::
",Aparna Kumta <aparna.kumta@…>
12033,Boostdep misses some dependent components,Building Boost,Boost 1.61.0,To Be Determined,Feature Requests,Peter Dimov,assigned,2016-02-29T21:33:12Z,2016-03-03T17:46:12Z,"In creating a modular boost build for a client I found that boostdep was missing a few smaller libraries when tracing the dependencies.  The library msm depends on fusion, which depends on utility, but boostdep does not list ""utility"" as among the depdencies of msm.

For a test case, try building libs/msm/doc/HTML/examples/SimpleTutorial.cpp using a version of Boost with only the submodules listed as dependencies of msm.  It should complain about not finding boost/utility/result_of.hpp",edaskel@…
12032,boost::system::error_code bug?,asio,Boost 1.60.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-02-29T20:55:16Z,2016-02-29T21:06:19Z,"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.",Falven2000@…
12030,boost iostreams documentation misstates filtering_streambuf typedef,iostreams,Boost 1.60.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-02-28T15:39:35Z,2016-02-28T16:00:13Z,"This report concerns iostreams documentation.

The documentation for class template filtering_streambuf misstates the name of four typedefs:

From the [http://www.boost.org/doc/libs/1_60_0/libs/iostreams/doc/classes/filtering_streambuf.html 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 [http://www.boost.org/doc/libs/1_60_0/libs/iostreams/doc/ ""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 [http://www.boost.org/doc/libs/1_60_0/libs/iostreams/doc/classes/filtering_stream.html 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;
}}}

",Nicholas Musolino <n.musolino@…>
12026,using this coupon,iterator,Boost 1.35.0,Boost 1.61.0,Feature Requests,jeffrey.hellrung,new,2016-02-27T10:43:53Z,2017-10-08T06:06:41Z,"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 [http://mydomain98223848.com/ go to this website] anyone.",christiezimmermann@…
12022,CRT optimised powm(),multiprecision,Boost 1.61.0,To Be Determined,Feature Requests,John Maddock,new,2016-02-26T10:29:02Z,2016-02-26T15:21:34Z,"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",Domagoj Šarić
12019,Conversion from unique_ptr to shared_ptr is too broad,smart_ptr,Boost 1.60.0,To Be Determined,Bugs,Peter Dimov,new,2016-02-25T21:24:34Z,2016-02-25T21:27:20Z,"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",Tavian Barnes <tavianator@…>
12018,rounded_arith_opp doesn't work in Release configuration under msvc 14,interval,Boost 1.60.0,To Be Determined,Bugs,Boris Gubenko,new,2016-02-25T14:37:18Z,2016-02-25T14:37:18Z,"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.
",peter.azmanov@…
12017,Segfault with Boost program_options 1.60 debug libraries on OSX,program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-02-24T17:24:26Z,2016-03-18T02:25:33Z,"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).
",anonymous
12015,OperationalError: database is locked,trac / subversion,Boost 1.61.0,To Be Determined,Bugs,Douglas Gregor,new,2016-02-23T10:44:37Z,2016-02-23T10:44:37Z,"==== 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
}}}",Andrey Semashev
12012,bost.MPI installation fail on Windows' 10,mpi,Boost 1.60.0,To Be Determined,Tasks,Matthias Troyer,new,2016-02-21T15:58:53Z,2016-02-21T15:58:53Z,"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 ",anastp@…
12011,Boost.Regex always links against dynamic DLLs of ICU with MSVC,regex,Boost 1.61.0,To Be Determined,Bugs,John Maddock,new,2016-02-21T11:44:44Z,2016-06-11T17:50:04Z,"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 [http://www.npcglib.org/~stathis/blog/2016/02/21/windows-task-building-boost-against-static-icu-with-msvc/ 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 [http://www.npcglib.org/~stathis/downloads/boost_1.60.0.patch 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.



",stathis@…
12009,Fix for Visual C++ C4267 'conditional expression is constant' warning,ptr_container,Boost Development Trunk,To Be Determined,Patches,Thorsten Ottosen,new,2016-02-19T21:43:23Z,2016-02-19T21:43:23Z,"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?",eyas.sharaiha@…
12008,Support Intel SSE instructions for CRC-32C,crc,Boost 1.61.0,To Be Determined,Feature Requests,Daryle Walker,new,2016-02-19T20:19:08Z,2017-04-07T18:53:16Z,"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",arkadiy_s@…
12007,Support Intel SSE instructions for CRC-32C,crc,Boost 1.61.0,To Be Determined,Feature Requests,Daryle Walker,new,2016-02-19T20:19:03Z,2017-04-07T18:53:53Z,"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",arkadiy_s@…
12006,Compile error on Windows of boost/functional/hash/extensions.hpp,hash,Boost 1.58.0,To Be Determined,Bugs,Daniel James,new,2016-02-19T14:54:18Z,2016-03-12T18:16:54Z,"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.",kilian.kilger@…
12005,Install boost_context on CentOS 6,build,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-02-19T14:25:56Z,2016-02-19T14:25:56Z,"
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!!",nguyenduong2010@…
12004,Boost 1.60 fails to build with VC14,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2016-02-19T10:13:32Z,2016-02-19T10:13:32Z,"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.",anonymous
11997,website multiple headers sent,trac / subversion,Boost 1.61.0,To Be Determined,Support Requests,Douglas Gregor,new,2016-02-17T14:35:23Z,2017-08-15T08:26:53Z,"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

",damian.vicino@…
11991,Application crashes when yield/resume an coroutine after handing an exception,asio,Boost 1.61.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-02-16T19:03:21Z,2016-02-17T08:34:30Z,"
{{{
#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",misko.pawel@…
11990,interprocess_condition on OSX with processes in different address spaces,interprocess,Boost 1.60.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-02-16T17:51:56Z,2016-02-16T17:51:56Z,"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",johughes@…
11989,gcc 5.3 optimizer mangles non_blocking_recvfrom,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-02-16T12:48:22Z,2016-08-19T08:00:27Z,"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:

1. 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)

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

3. 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




",tmark@…
11986,TTI: has_static_member_function doesn't like function local classes with GCC,tti,Boost 1.59.0,To Be Determined,Bugs,Edward Diener,new,2016-02-15T17:54:38Z,2016-02-19T21:25:22Z,"Hi

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."");
}
}}}
",lukester_null@…
11985,range: compiler-error sub_range copy-constructor workaround for MSVC,range,Boost 1.61.0,To Be Determined,Bugs,Neil Groves,new,2016-02-15T09:32:02Z,2016-02-15T09:32:48Z,"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
",Tobias Loew
11982,distance between point and linestring on spherical_equatorial ignores radius when using haversine.,geometry,Boost 1.60.0,To Be Determined,Bugs,Barend Gehrels,new,2016-02-12T12:05:13Z,2016-02-12T22:12:25Z,"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.",anonymous
11981,boost::archive::xml_woarchive with locale dosen't work,serialization,Boost 1.65.0,To Be Determined,Bugs,Robert Ramey,reopened,2016-02-12T03:57:43Z,2017-09-29T10:38:08Z,"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.",anonymous
11980,Windows Phone Build Error,locale,Boost Release Branch,To Be Determined,Bugs,Artyom Beilis,new,2016-02-11T19:47:10Z,2016-02-12T09:32:10Z,"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 __imp__GetLocaleInfoA@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 __imp__GetLocaleInfoA@16
3>libboost_locale-vc140-mt-gd-1_60.lib(lcid.obj) : error LNK2001: unresolved external symbol __imp__GetLocaleInfoA@16
3>libboost_locale-vc140-mt-gd-1_60.lib(codepage.obj) : error LNK2019: unresolved external symbol __imp__IsDBCSLeadByteEx@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 __imp__EnumSystemLocalesA@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 __imp__FoldStringW@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 __imp__LCMapStringW@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 __imp__LCMapStringW@24
3>libboost_locale-vc140-mt-gd-1_60.lib(collate.obj) : error LNK2019: unresolved external symbol __imp__CompareStringW@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 __imp__GetDateFormatW@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 __imp__GetTimeFormatW@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 __imp__GetLocaleInfoW@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 __imp__GetCurrencyFormatW@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 __imp__LocalFree@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)

",yigit.ozcelik@…
11979,Wiki page has broken link to building Python,Documentation,Boost 1.61.0,To Be Determined,Bugs,Matias Capeletto,new,2016-02-11T10:13:28Z,2018-04-13T15:42:51Z,"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.

",gamesbook@…
11978,Bootstrap generates errors,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2016-02-11T09:44:51Z,2016-02-17T07:47:19Z,"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"".
",bram.de.beer@…
11976,compile error when BOOST_UBLAS_SCALED_NORM is defined,uBLAS,Boost 1.60.0,To Be Determined,Bugs,Gunter,new,2016-02-11T02:30:18Z,2016-02-11T02:30:18Z,"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.

{{{#!div style=""font-size: 90%""
Wrong:
{{{#!c++
size_type size(e().size());
for (size_type i = 0; i < size; ++i) {
}}}
}}}

{{{#!div style=""font-size: 90%""
Correct:
{{{#!c++
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.",lebre <junonon0077@…>
11975,Null pointer dereference in boost::filesystem::copy,filesystem,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-02-10T15:58:41Z,2016-02-10T15:58:41Z,"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.",Michael Rasmussen <Michael.Rasmussen@…>
11973,Can't work with date_time library,date_time,Boost 1.60.0,To Be Determined,Support Requests,az_sw_dude,new,2016-02-10T11:42:13Z,2016-02-10T12:14:54Z,"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 fr 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': fr 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.
",markus.zaczek@…
11971,polygon_set_data<int32_t> has problems near INT_MAX,polygon,Boost 1.61.0,To Be Determined,Bugs,Lucanus Simonson,new,2016-02-09T22:09:56Z,2016-02-09T22:09:56Z,"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?",lopresti@…
11970,Use perfect forwarding for object_pool,pool,Boost 1.61.0,To Be Determined,Feature Requests,Chris Newbold,new,2016-02-09T19:29:22Z,2016-02-09T19:29:22Z,"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.",djpeaco@…
11969,Add new library category,Documentation,Boost 1.61.0,To Be Determined,Feature Requests,Matias Capeletto,new,2016-02-09T16:48:42Z,2016-02-09T16:48:42Z,"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.",steve.hickman@…
11968,Undefined behavior in `boost::lockfree::queue`: nodes are always misaligned,lockfree,Boost Development Trunk,To Be Determined,Bugs,timblechmann,new,2016-02-09T13:22:02Z,2016-10-11T13:56:18Z,"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.

1. 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`.

2. 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.[[br]][[br]]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.

3. 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.",yury.zaytsev@…
11964,asio async_resolve cannot be cancelled,asio,Boost 1.59.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-02-08T09:53:07Z,2016-02-08T09:53:07Z,"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.",sven_nilsson@…
11963,"Boost function ""boost::property_tree::ini_parser::read_ini"" causing ""EXC_BAD_ACCESS (code=EXC_I386_GPFLT)""",property_tree,Boost 1.60.0,To Be Determined,Bugs,Sebastian Redl,new,2016-02-08T08:51:10Z,2016-02-08T08:51:10Z,"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
",giovacchini.andrea@…
11960,"boost::transitive_closure dies on small graph with only 100,000 vertices",graph,Boost 1.58.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-02-06T03:03:04Z,2016-02-13T21:17:56Z,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.,jpritikin@…
11958,boost::gregorian is not thread safe,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2016-02-05T14:48:21Z,2016-03-15T17:58:38Z,"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.",Mathieu Marquis Bolduc <mbolduc@…>
11955,boost/graph/adjacency_matrix.hpp triggers deprecated code,graph,Boost 1.60.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-02-04T15:25:17Z,2016-08-09T10:38:46Z,"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.",fiesh@…
11954,NOTE: Use of this header (bool_trait_def.hpp) is deprecated,iostreams,Boost 1.60.0,To Be Determined,Bugs,Jonathan Turkanis,new,2016-02-04T13:47:51Z,2017-03-23T10:54:52Z,"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.",fiesh@…
11949,request for information,filesystem,Boost 1.61.0,To Be Determined,Support Requests,Beman Dawes,new,2016-02-02T05:29:14Z,2016-02-02T07:04:37Z,"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@iinet.net.au
",dp25@…
11948,undefined reference to boost::gregorian::greg_month::get_month_map_ptr(),date_time,Boost 1.60.0,To Be Determined,Bugs,az_sw_dude,new,2016-01-30T15:48:25Z,2016-01-30T15:48:25Z,"[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']",565434471@…
11947,filesystem: getting file_type from a directory_entry without causing a system call on linux,filesystem,Boost 1.61.0,To Be Determined,Patches,Beman Dawes,new,2016-01-29T10:44:31Z,2016-01-29T10:44:31Z,"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?",Taru Karttunen <taruti@…>
11944,lexically_relative() documentation incorrect,filesystem,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-01-28T07:20:19Z,2016-01-28T07:20:19Z,"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;
",harris.pc@…
11943,std::vector does not have a member data() in c++03 mode,program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-01-27T20:20:24Z,2016-01-27T20:20:24Z,"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)",angela.xie@…
11939,Issues with boost::interprocess::shared_ptr's move constructor and move assignment operator.,interprocess,Boost 1.60.0,To Be Determined,Bugs,Ion Gaztañaga,new,2016-01-26T07:38:51Z,2016-01-26T07:38:51Z,"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.
}}}",aivazyan@…
11937,the bootstrap,Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-01-24T08:47:40Z,2016-01-24T08:47:40Z,"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
",terry lyons <tlyons@…>
11935,boost::program_options::error_with_option_name.what() throws std::out_of_range when an empty option is used in the command input,program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-01-22T16:11:20Z,2016-01-29T01:47:44Z,"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[[BR]]
Mark.",mark.incley@…
11934,Various warnings in 1.60 MPL when compiling with nvcc,mpl,Boost 1.60.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2016-01-22T09:06:42Z,2018-02-13T16:38:39Z,"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_* );
}}}
",Alex Grund <a.grund@…>
11933,warnings in 1.60 when compiling with nvcc,smart_ptr,Boost 1.60.0,To Be Determined,Bugs,Peter Dimov,new,2016-01-22T09:01:55Z,2016-05-30T12:34:38Z,"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/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
}}}
",Alex Grund <a.grund@…>
11932,Binary MPL transform on empty fusion sequences does not work,fusion,Boost 1.60.0,Boost 1.69,Bugs,Kohei Takahashi,new,2016-01-22T00:24:07Z,2018-07-16T04:21:37Z,"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",zeratul976@…
11929,haversine method is inaccurate,geometry,Boost 1.58.0,To Be Determined,Bugs,Barend Gehrels,new,2016-01-21T19:03:03Z,2016-01-21T19:03:36Z,"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.

{{{#!c++
#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
  [https://en.wikipedia.org/wiki/Great-circle_navigation#cite_note-2 great-circle navigation]
  (this is the formula used by Vincenty in the spherical limit
  -- but it surely doesn't originate with him).
",Charles Karney <charles@…>
11927,"optional_test_swap.cpp: In C++11 mode, std::swap should have a noexcept specification",optional,Boost Development Trunk,To Be Determined,Bugs,Fernando Cacciola,new,2016-01-20T18:59:53Z,2016-02-15T09:04:09Z,"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. 


",Aparna Kumta <aparna.kumta@…>
11926,b2 returns an error code of 1 on Windows when using the --show-libraries option,Building Boost,Boost 1.58.0,To Be Determined,Bugs,,new,2016-01-20T18:21:33Z,2016-01-20T18:21:33Z,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.,wkurlancheek@…
11921,Bootstrap fails to run on windows 8.1 vc12 due to environment variable,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2016-01-18T15:39:00Z,2016-01-21T22:43:46Z,"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.",junaid1@…
11920,MSVC warning C4505 when po::bool_switch(&flag) is being used,program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-01-18T14:49:59Z,2016-07-27T04:12:01Z,"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


}}}
",anton.lauridsen@…
11919,ERROR_BROKEN_PIPE != boost::system::errc::broken_pipe,system,Boost 1.59.0,To Be Determined,Support Requests,Beman Dawes,new,2016-01-18T13:22:02Z,2016-01-18T13:22:02Z,"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
",anonymous
11916,Problem with iterating foreach on in_edges of reverse_graph,graph,Boost 1.61.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-01-16T16:04:31Z,2016-01-21T22:43:25Z,Hello. got a problem with iterating all edges in in_edges by given vertex on reverse_graph.,pawel.kunio@…
11914,abort is called while boost::filesystem::copy tries to throw and exception,filesystem,Boost 1.65.0,To Be Determined,Bugs,Beman Dawes,new,2016-01-15T08:14:49Z,2018-04-25T08:25:35Z,"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
",jpo38 <jean.porcherot@…>
11913,free functions should support StreamBuffer concept,asio,Boost 1.61.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2016-01-14T21:18:42Z,2016-01-14T21:18:42Z,"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

",vinnie.falco@…
11910,recursive_directory_iterator doesn't set end iterator properly when exception is thrown in increment(),filesystem,Boost 1.60.0,To Be Determined,Bugs,Beman Dawes,new,2016-01-13T16:49:16Z,2016-01-13T16:50:01Z,"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.  

",David Raphael <draphael@…>
11909,Bjam loses trailing dash sign in Cxxflags command line parameter,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2016-01-13T00:55:48Z,2016-01-13T21:47:06Z,"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",Yuriy Martsynovskyy <captainsilver@…>
11908,mpi_process_group.cpp uses undefined class 'std::list',graph,Boost 1.61.0,To Be Determined,Bugs,Jeremiah Willcock,new,2016-01-13T00:17:43Z,2016-01-17T19:56:15Z,"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.

 ",terry lyons <tlyons@…>
11905,"Exception ""character conversion failed"" when omitting argument",program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-01-12T14:11:09Z,2016-12-27T08:43:49Z,"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
",Thibaut Lepage <dourak@…>
11902,bind placeholder _1 is not defined,bind,Boost 1.60.0,To Be Determined,Bugs,Peter Dimov,new,2016-01-11T12:08:47Z,2016-01-23T19:14:45Z,"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.
",zimmermann@…
11898,Input stream operator of a filesystem::path can't handle spaces,filesystem,Boost 1.58.0,To Be Determined,Bugs,Beman Dawes,new,2016-01-09T20:40:57Z,2016-01-09T20:40:57Z,"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.",anonymous
11895,Strand service scheduling is hurting ASIO scalability,asio,Boost 1.60.0,To Be Determined,Bugs,chris_kohlhoff,new,2016-01-08T04:38:26Z,2016-01-09T18:47:12Z,"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.",Chris White <chriswhitemsu@…>
11891,boost::program_options::validation_error throws std::out_of_range when original_token argument is empty,program_options,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2016-01-06T22:53:55Z,2016-01-06T22:53:55Z,"The code below presents some bugs. 
{{{#!cpp
#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!",ce.andrade@…
11886,Deprecated header template_arity_spec.hpp included in several places,function_types,Boost 1.61.0,To Be Determined,Bugs,t_schwinger,new,2016-01-05T05:47:17Z,2016-12-16T01:10:16Z,"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>
",anonymous
11883,Incorporate 64 bit in DLL name,Building Boost,Boost 1.61.0,To Be Determined,Feature Requests,,new,2016-01-04T12:56:24Z,2018-02-06T15:18:58Z,"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",gast128 <gast128@…>
11882,Mistake in iterator facade documentation,iterator,Boost 1.60.0,To Be Determined,Tasks,jeffrey.hellrung,new,2016-01-03T20:56:30Z,2016-01-03T20:56:30Z,"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",sylvaincoulombel@…
11881,b2 returns code 256 exit code instead zero,Building Boost,Boost 1.61.0,To Be Determined,Bugs,,new,2016-01-01T19:58:10Z,2016-03-01T04:34:02Z,"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?
",pavel.odintsov@…
11880,BGL adjacency_matrix_traits compiling failure,graph,Boost 1.60.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-12-31T03:46:37Z,2017-01-12T12:39:00Z,"'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);",jackymiao@…
11879,Incorrect use of reset cause unexpected impact on previous code segment,smart_ptr,Boost 1.57.0,To Be Determined,Bugs,Peter Dimov,new,2015-12-30T08:40:42Z,2016-01-05T10:32:21Z,"#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';
}",anonymous
11876,Boost.Graph conflicts with Qt's foreach macro,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-12-28T14:56:52Z,2016-01-03T16:46:19Z,"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. ",richel@…
11874,Compilation error with GCC4.6 in C++11 mode,exception,Boost 1.64.0,To Be Determined,Bugs,Emil Dotchevski,reopened,2015-12-27T19:14:54Z,2017-08-23T16:05:57Z,"`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.",Antony Polukhin
11873,boost::filesystem does not work on windows when multiple processes access the same junction (directory),filesystem,Boost 1.64.0,To Be Determined,Bugs,Beman Dawes,new,2015-12-26T05:24:32Z,2018-06-08T17:11:06Z,"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
",stsoe <stsoe@…>
11871,json_parser missing return statement in standard callback,property_tree,Boost 1.61.0,To Be Determined,Bugs,Sebastian Redl,new,2015-12-23T19:50:49Z,2016-03-07T06:30:45Z,new_tree in standard callbacks of json_parser misses return statement and therefore fails to compile depending on warning level.,ingo.loehken@…
11868,cannot build Boost using PGI compilers,Building Boost,Boost 1.60.0,To Be Determined,Bugs,,new,2015-12-23T15:03:51Z,2015-12-23T15:03:51Z,"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 
> -D__need_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 ",anonymous
11863,Compilation failure when trying to use Boost Test,mpl,Boost 1.60.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-12-23T01:21:59Z,2016-03-21T15:45:55Z,"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:[[BR]]

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.",gordon@…
11862,"timer.hpp, commented line 14 (// #include <boost/chrono/chrono.hpp>) causes link error in (at least) MSVC",timer,Boost 1.60.0,Boost 1.60.0,Bugs,Beman Dawes,new,2015-12-22T18:44:03Z,2016-05-27T05:35:45Z,"boost\timer\timer.hpp 
line 14
//#include <boost/chrono/chrono.hpp>
causes unresolved externals
uncommenting that line solves the issue
",dmitry.kolomiets@…
11861,windows - Using boost thread crash winrt store app on start on Windows 10 Phone devices,thread,Boost 1.60.0,To Be Determined,Bugs,viboes,new,2015-12-22T15:54:18Z,2016-03-08T07:23:47Z,"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.",Mathieu <mvillegas@…>
11860,Using iostreams causes lots of messages about deprecated header template_arity_spec.hpp,iostreams,Boost 1.60.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-12-22T14:27:34Z,2016-09-27T18:02:23Z,"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.
",martin.apel@…
11851,epoll_reactor::deregister_descriptor() release descriptor_data,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-12-17T08:04:44Z,2015-12-23T13:29:04Z,"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().",ljl <404140036@…>
11850,templated overload of boost::lockfree::spsc_queue::pop is a potential footgun,lockfree,,To Be Determined,Feature Requests,timblechmann,new,2015-12-17T03:11:24Z,2015-12-17T03:13:32Z,"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.",tjakubowski@…
11849,-DBOOST_TYPEOF_EMULATION is not needed for scope_exit/run-vaseq test with Oracle studio 12.5,scope_exit,Boost 1.59.0,To Be Determined,Bugs,Lorenzo Caminiti,new,2015-12-17T00:10:00Z,2016-01-05T18:16:02Z,"-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 : : : ;
}
",angela.xie@…
11848,Win32 backend bug when do wide char convert to multi byte in boost::locale,locale,Boost 1.59.0,To Be Determined,Bugs,Artyom Beilis,assigned,2015-12-16T05:26:31Z,2015-12-16T11:47:20Z,"The function wide_to_multibyte_non_zero in locale/src/encoding/wconv_codepage.ipp has bug. This function assume that when the codepage is CP_UTF7 or CP_UTF8, the substitute_ptr and subst_char_ptr will be 0. But, in x64 Windows 10, I use codepage 54936 get 87 error code after the first WideCharToMultiByte called. This will make n is zero, and the second WideCharToMultiByte call will make the program crash.

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

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

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

BOOL bVal = FALSE;

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

You'll get 0 with GetLastError 87 (ERROR_INVALID_PARAMETER).",fyrestone@…
11847,reference typedef no longer available in parent class of iterator_facade,iterator,Boost 1.57.0,To Be Determined,Bugs,jeffrey.hellrung,new,2015-12-15T17:52:04Z,2015-12-15T17:52:04Z,"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;
}",alexhighviz@…
11846,to_iso[_extended]_string documentation,date_time,Boost 1.56.0,To Be Determined,Bugs,az_sw_dude,new,2015-12-15T16:29:18Z,2015-12-15T16:29:18Z,"Hi,

documentation (I use [http://www.boost.org/doc/libs/1_56_0/doc/html/date_time/posix_time.html#ptime_to_string 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?",anonymous
11843,shared_ptr hash support doesn't work for shared_ptr<T[]> or shared_ptr<T[N]>,smart_ptr,Boost 1.59.0,To Be Determined,Bugs,Peter Dimov,new,2015-12-13T03:07:33Z,2015-12-15T17:15:30Z,"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.",rs2740@…
11839,"JSON parser does not work with ""boost::any"" as value type",property_tree,Boost 1.59.0,To Be Determined,Bugs,Sebastian Redl,new,2015-12-10T22:46:12Z,2015-12-10T22:46:12Z,"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).",milacher@…
11838,contribution: Yen k-shortest paths,graph,Boost 1.57.0,To Be Determined,Library Submissions,Jeremiah Willcock,new,2015-12-10T21:06:02Z,2018-07-18T20:58:48Z,I wanna contribute the implementation of the Yen k-shortest paths algorithm.  Please find attached the implementation and the unit test.,Irek Szcześniak <irek@…>
11837,Failed to build Boost.Build engine,build,Boost 1.59.0,To Be Determined,Bugs,Vladimir Prus,new,2015-12-10T01:40:05Z,2016-02-13T22:26:26Z,"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
}}}",alexey.trenikhin+boost@…
11836,"cannot build filesystem, utility/enable_if has been moved to core",filesystem,Boost Development Trunk,To Be Determined,Bugs,Beman Dawes,new,2015-12-09T14:35:42Z,2015-12-22T17:05:35Z,"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!",pas@…
11834,Undefined symbols for architecture x86_64:,system,Boost 1.59.0,To Be Determined,Bugs,Beman Dawes,new,2015-12-08T15:35:43Z,2015-12-22T17:06:57Z,"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)",banslug2001@…
11828,net/if.h and linux/if.h incompatible for latest boost and centos 6.6,asio,Boost 1.59.0,Boost 1.59.0,Bugs,chris_kohlhoff,new,2015-12-04T06:07:54Z,2015-12-04T06:07:54Z,"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.",saima8788@…
11824,[spirit][qi] skip_flag::dont_postskip not working as expected,spirit,Boost 1.59.0,To Be Determined,Bugs,Joel de Guzman,new,2015-11-28T08:56:53Z,2015-11-28T08:56:53Z,"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.",Daniel Starke <daniel.f.starke@…>
11823,Exception safety problems in the epoll based implementation of async_accept,asio,Boost 1.59.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-11-26T10:08:59Z,2016-05-09T22:31:42Z,"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.
",Sorin Fetche <sorin.fetche@…>
11816,can not move asio socket on vs2010,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-11-23T09:25:37Z,2015-12-06T09:14:12Z,"
io_service svc;
tcp::socket sk(svc);
auto sk2 = std::move(sk);

compile failed on vs2010,and I tried on vs2012 it works.",luguanyu <luguanyu1234@…>
11814,Add Boost.Convert to the Trac,trac / subversion,Boost 1.57.0,To Be Determined,Feature Requests,Douglas Gregor,new,2015-11-21T20:34:41Z,2016-01-03T16:51:51Z,,viboes
11813,Microseconds get cut off in ISO string representation if all zero (posix_time::to_iso_string),date_time,Boost 1.55.0,To Be Determined,Bugs,az_sw_dude,new,2015-11-21T14:33:16Z,2015-11-21T20:30:32Z,"
{{{
#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[[BR]]
''Timestamp: 20151121T141523.000000''[[BR]]
but actually is[[BR]]
''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.",Marcel Glacki <boost-trac@…>
11810,privilege __sun over sun for strict ISO compilers,build,Boost 1.59.0,To Be Determined,Patches,Vladimir Prus,new,2015-11-21T06:18:19Z,2015-11-22T13:00:30Z,"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
}}}

",Richard PALO <richard@…>
11809,Add SSL Renegotiate  handshake support to boost::asio::ssl,asio,Boost 1.59.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2015-11-20T11:13:43Z,2017-08-22T08:59:53Z,"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:

{{{
#!c++

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

}}}",georgid@…
11808,ip::address::from_string() is not crossplatform,asio,Boost 1.59.0,Boost 1.59.0,Bugs,chris_kohlhoff,new,2015-11-20T09:00:38Z,2015-11-20T09:02:10Z,"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.",reinterpret.alexey@…
11807,"sun.jam needs updating when creating shared libraries compiled with -std=[c++03,c++11] mode.",build,Boost 1.60.0,To Be Determined,Bugs,Vladimir Prus,new,2015-11-19T18:56:33Z,2015-11-19T19:03:24Z,"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",Aparna Kumta <aparna.kumta@…>
11805,building boost.python 1.56+ with msvc,python USE GITHUB,Boost 1.56.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2015-11-19T10:08:35Z,2015-11-21T20:32:55Z,"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.",remi.ducceschi@…
11804,Contribution: edge-disjoint k-shortest paths,graph,Boost 1.57.0,To Be Determined,Library Submissions,Jeremiah Willcock,new,2015-11-18T22:04:36Z,2016-03-14T21:29:25Z,"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!
  ",Irek Szcześniak <irek@…>
11799,boost::interprocess::offset_ptr not compatible with C++11 std::pointer_traits,container,Boost 1.59.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-11-17T14:39:29Z,2015-11-17T14:39:29Z,"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.",Chris Clearwater <chris@…>
11798,Implementation of boost::shared_mutex on POSIX is suboptimal,thread,Boost 1.59.0,To Be Determined,Tasks,viboes,assigned,2015-11-16T12:52:52Z,2017-12-13T02:08:35Z,"The current (as of boost 1.59) implementation of boost::shared_mutex for 'pthread' is pretty suboptimal as it's using a heavyweight mutex to guard the internal mutex state. This is more evident when shared locks are used to guard state whose access concurrency is high, due to contention on the mutex state lock (in these cases, the shared mutex is effectively exclusive). In comparison, the 'win32' implementation uses lightweight spinlocks underneath.

There are a couple options to fix this for 'pthread', e.g. using a spinlock or leveraging pthreads_rwlock. I'm happy to provide with an initial patch for this.",alex@…
11797,The __idiv__ operator was replaced with __itruediv__ and __ifloordiv__ in Python 3,python USE GITHUB,Boost 1.59.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2015-11-16T10:28:50Z,2015-11-16T10:29:25Z,"`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/",lahwaacz <j.l.k@…>
11794,SSL context and/or stream valgrind reports conflicting access in libcrypto.so,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-11-13T10:03:42Z,2015-11-21T20:38:23Z,"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
}}}",Aleksey Barsuk <barsuk.alexey@…>
11793,Build for Intel Xeon Phi fails,build,Boost 1.59.0,To Be Determined,Bugs,Vladimir Prus,new,2015-11-12T23:47:36Z,2015-11-21T20:35:28Z,"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)
",evgeny.fiksman@…
11787,fusion for_each turns array reference const on msvc,fusion,Boost Development Trunk,To Be Determined,Bugs,Joel de Guzman,new,2015-11-08T08:17:14Z,2016-03-09T11:12:16Z,"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.",imer@…
11785,specializing boost::range_const_iterator has no effect on boost::has_range_iterator,range,Boost 1.59.0,To Be Determined,Bugs,Neil Groves,new,2015-11-05T11:29:51Z,2015-11-05T11:29:51Z,"see the following code:

{{{#!c++
#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.",Tobias Reh <treh@…>
11782,OpenSSL SSLv3 methods removed,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-11-02T21:13:08Z,2015-11-02T21:16:19Z,"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.",kurt@…
11781,b2 install not copying filesystem.hpp or program_options.hpp,Building Boost,Boost 1.59.0,To Be Determined,Bugs,,new,2015-11-02T00:04:11Z,2016-02-13T21:28:15Z,"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 [http://www.boost.org/doc/libs/1_59_0/more/getting_started/unix-variants.html#easy-build-and-install 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?",gtmalmgren@…
11779,Boost.Lockfree: Implicit conversion loses integer precision warnings,lockfree,Boost 1.59.0,To Be Determined,Bugs,timblechmann,new,2015-11-01T14:38:40Z,2017-04-11T12:46:43Z,"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) {}
}}}                            ^
",wise.monkey@…
11777,Doing async reads appears to do spurrious calls to recvmsg that return EAGAIN,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-10-30T23:45:23Z,2015-10-30T23:45:23Z,"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.",Dave Gotwisner <dgotwisn@…>
11776,Effective way to find all regex matches in large file,regex,Boost 1.59.0,To Be Determined,Feature Requests,John Maddock,reopened,2015-10-30T09:20:12Z,2016-11-23T16:13:11Z,"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 [http://www.boost.org/doc/libs/1_59_0/libs/regex/doc/html/boost_regex/partial_matches.html 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!",der-storch-85@…
11775,Documentation points wrong folder,Getting Started Guide,Boost 1.57.0,To Be Determined,Bugs,Dave Abrahams,new,2015-10-29T21:20:27Z,2015-10-29T21:20:27Z,"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
}}}
",villasv@…
11774,"Extract try_executing_one, reschedule_until to a more specific reentrant executor interface.",thread,Boost 1.60.0,To Be Determined,Feature Requests,viboes,assigned,2015-10-29T13:12:35Z,2015-10-29T13:12:58Z,,viboes
11773,Extract close/closed to a more specific shutdonw-executor interface.,thread,Boost 1.60.0,To Be Determined,Feature Requests,viboes,assigned,2015-10-29T13:11:31Z,2015-10-29T13:13:45Z,,viboes
11771,Type error in has_member_finish_edge with CLR,graph,Boost 1.59.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-10-29T10:14:21Z,2015-10-29T10:14:21Z,"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",Taus Møller <taus.moeller@…>
11767,More -Wunused-local-typedef warnings when building Boost 1.55.0 with Apple LLVM version 7.0.0 (clang-700.1.76),asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-10-28T09:04:33Z,2015-10-28T09:04:33Z,"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.",christopher.dawes@…
11761,boost/graph/kamada_kawai_spring_layout.hpp: many indexes out of range ?,graph,Boost 1.59.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-10-27T16:09:09Z,2015-12-14T19:38:12Z,"[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]);
",anonymous
11760,libs/xpressive/perf/regex_comparison.hpp:84: bad if test ?,xpressive,Boost 1.59.0,To Be Determined,Bugs,Eric Niebler,new,2015-10-27T16:04:53Z,2015-10-29T10:37:37Z,"[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 ?",anonymous
11757,ptr_list no longer compiles in msvc2013,ptr_container,Boost 1.59.0,To Be Determined,Bugs,Thorsten Ottosen,new,2015-10-27T12:31:00Z,2015-10-27T12:31:00Z,"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


}}}
",anonymous
11755,b2 ignores MAKEFLAGS and '-j' option isn't documented in b2 --help,Building Boost,Boost 1.59.0,To Be Determined,Feature Requests,,new,2015-10-26T14:50:27Z,2016-02-13T21:36:26Z,"''./b2'' ignores ''MAKEFLAGS'' and ''-j'' option isn't documented in ''./b2 --help''.

experienced with boost-1.59.0-126-g919988b",krichter@…
11754,Fix building when OpenSSL is built with no-ssl3 option,asio,Boost Development Trunk,To Be Determined,Bugs,chris_kohlhoff,new,2015-10-25T09:35:31Z,2015-10-25T09:35:31Z,"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.",Bernard Spil <brnrd@…>
11753,cannot execute bootstrap - Failed to build Boost.build engine,Building Boost,Boost 1.59.0,To Be Determined,Bugs,,new,2015-10-24T07:28:00Z,2015-10-29T10:36:30Z,"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.",aamirlodhi66@…
11752,basic_null_device::read returns 0 but -1 is expected,iostreams,Boost 1.59.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-10-24T01:41:50Z,2016-12-09T01:34:03Z,"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; }
    ...
}}}",Nikolay Shelukhin <nikola-sh@…>
11749,mpi::broadcast problem,mpi,Boost 1.57.0,,Bugs,Matthias Troyer,new,2015-10-23T09:47:29Z,2015-10-23T09:47:29Z,"Hi

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",Warin <xavier.warin@…>
11748,boost::asio::buffer() overload for string_ref and const char pointer (c-string),asio,Boost 1.57.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2015-10-22T20:22:13Z,2015-11-06T12:38:39Z,"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.",oliora@…
11747,boost::asio::buffer() overload for string_ref and const char pointer (c-string),asio,Boost 1.57.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2015-10-22T20:21:57Z,2015-10-22T20:25:58Z,"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.",oliora@…
11746,boost::asio::buffer() overload for string_ref and const char pointer (c-string),asio,Boost 1.57.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2015-10-22T20:21:32Z,2015-10-22T20:26:59Z,"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.",oliora@…
11745,memory-mapped file documentation heavily implies that we cannot use a Filesystem path,iostreams,Boost 1.59.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-10-22T16:23:17Z,2015-10-22T16:23:17Z,"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.",Austin Hicks <camlorn38@…>
11743,json parser cannot be compiled with -DNDEBUG,property_tree,Boost 1.59.0,To Be Determined,Bugs,Sebastian Redl,new,2015-10-21T13:11:55Z,2017-08-10T14:46:17Z,"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.
",Marco Clemencic <marco.clemencic@…>
11735,A* Out of Range Error on 2D grid if width or height is 1,graph,Boost 1.59.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-10-17T20:38:40Z,2018-02-22T14:31:45Z,"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.",willi+boost@…
11732,Use CreateEventW instead of CreateEvent,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-10-15T10:23:02Z,2015-10-15T10:23:02Z,"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.",Kim Gräsman <kim.grasman@…>
11731,iostreams classes do not support C++11 move semantics,iostreams,Boost Development Trunk,To Be Determined,Bugs,Jonathan Turkanis,new,2015-10-15T08:38:48Z,2017-01-26T06:12:26Z,"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;
};
",Josh Chia <joshchia@…>
11730,Extend interprocess::message_queue to be lazy initializable,interprocess,Boost 1.59.0,To Be Determined,Patches,Ion Gaztañaga,new,2015-10-15T07:56:30Z,2015-10-15T07:56:30Z,"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
",Lingxi Li <lilingxi.cs@…>
11729,Boost interprocess fails to initialize on long-running Windows machines,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-10-15T07:56:10Z,2015-11-17T08:03:20Z,"This bug report is similar to [https://svn.boost.org/trac/boost/ticket/9767 #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.",martin.apel@…
11728,interprocess::message_queue deadlocked when process exists unexpectedly on Windows,interprocess,Boost 1.59.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-10-15T07:37:45Z,2017-07-11T22:34:02Z,"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()`.
",Lingxi Li <lilingxi.cs@…>
11724,managed_shared_memory constructor crash,interprocess,Boost 1.59.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-10-13T20:22:58Z,2015-10-13T20:22:58Z,"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
}}}
",john.saxton@…
11723,Memory leak (and assertion failed) in r_c_shortest_paths.hpp,graph,Boost 1.58.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-10-13T15:19:06Z,2018-07-29T16:56:30Z,"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.",a.santini@…
11721,boost::asio::serial_port bug in win10,asio,Boost 1.59.0,Boost 1.59.0,Bugs,chris_kohlhoff,new,2015-10-13T07:57:35Z,2015-10-13T07:57:35Z,"在最近写一些串口操作的程序时使用了 boost::asio::serial_port 来操作串口
但当尝试打开串口的时候出现了错误。下面是我的测试代码：
{{{#!cpp
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 函数的实现如下：
{{{#!cpp
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行左右添加
{{{#!cpp
if (dcb.BaudRate == 0) dcb.BaudRate = 115200;
}}}

修改后的 win_iocp_serial_port_service::open 函数完整代码如下：
{{{#!cpp
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",admin@…
11718,No debug output when karma.hpp is included before qi.hpp,spirit,Boost 1.55.0,To Be Determined,Bugs,Joel de Guzman,new,2015-10-11T06:28:15Z,2016-06-17T10:18:24Z,"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.",anonymous
11717,Associate an Executor used to launch the continuation to a promise/packaged_task constructor.,thread,Boost 1.58.0,To Be Determined,Feature Requests,viboes,assigned,2015-10-10T14:55:30Z,2015-10-11T18:16:01Z,"Currently 
we have `async` function that constructs futures associated to an `Executor`. 

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

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

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

* Add `packaged_task<R(Args...)>::packaged_task(Executor&)` Executor aware constructor.
",viboes
11715,build error with openmpi in vs2010,mpi,Boost 1.58.0,To Be Determined,Bugs,Matthias Troyer,new,2015-10-07T18:14:01Z,2015-10-07T18:14:01Z,"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.",anonymous
11714,"[subgraph.hpp] add_vertex(u_global, g) on a subgraph does not recursively add to parent subgraphs",graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2015-10-07T13:48:46Z,2016-08-12T07:52:51Z,"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!",s.hammer@…
11708,shared_ptr for void,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-10-05T19:30:20Z,2015-10-05T19:30:20Z,"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;
}}}
",mati_egon@…
11707,Locale facets have hidden visibility,date_time,Boost 1.59.0,To Be Determined,Bugs,az_sw_dude,new,2015-10-04T15:54:07Z,2015-10-04T19:21:42Z,"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`.",Andrey Semashev
11706,The Bessel function can not support to use complex parameter,math,Boost 1.57.0,To Be Determined,Bugs,John Maddock,new,2015-10-04T03:48:29Z,2015-10-15T18:34:33Z,"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. 

",jufangliang@…
11705,Phoenix function defining operator() with non-const reference parameter fails to compile with C++ 11.,phoenix,Boost 1.59.0,To Be Determined,Bugs,Thomas Heller,new,2015-10-03T05:07:56Z,2015-10-03T05:07:56Z,"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.

    
",David Williams <bateyware@…>
11704,Can't pass a generic lambda as an argument to a parser,spirit,Boost 1.59.0,To Be Determined,Bugs,Joel de Guzman,new,2015-10-02T13:26:04Z,2015-10-02T13:26:04Z,"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)",Matheus Izvekov <mizvekov@…>
11702,boost::bind universal reference handling regression,bind,Boost 1.59.0,To Be Determined,Bugs,Peter Dimov,new,2015-10-01T11:16:54Z,2015-10-03T23:25:43Z,"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
}}}",maxim.yegorushkin@…
11695,Crash if boost managed_shared_memory is used on Windows,interprocess,Boost 1.60.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-09-30T06:35:15Z,2015-09-30T06:35:15Z,"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);
    }
}
}}}",rohbansa@…
11694,Boost.icl tests incompatibility with Solaris,ICL,Boost Development Trunk,To Be Determined,Bugs,Joachim Faulhaber,new,2015-09-29T17:02:37Z,2016-01-12T22:04:41Z,"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





",Aparna Kumta <aparna.kumta@…>
11692,boost::insert doesn't return a value on the 2 argument overload causing undefined behaviour,range,Boost 1.63.0,To Be Determined,Bugs,Neil Groves,new,2015-09-29T12:24:02Z,2017-09-27T15:05:14Z,"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.  ",Harry George <harry.m.george@…>
11685,bootstrap.log: fatal error C1083: Cannot open include file: 'tlhelp32.h': No such file or directory,Building Boost,Boost 1.59.0,To Be Determined,Bugs,,new,2015-09-26T02:31:11Z,2015-09-26T04:24:19Z,"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 
",aritz@…
11682,fusion::pair not compatible with std::is_default_constructible,fusion,Boost 1.59.0,To Be Determined,Bugs,Joel de Guzman,new,2015-09-24T14:59:03Z,2015-09-24T14:59:03Z,"
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.",crmoore@…
11681,Boost 1.59 program_options parsing error,program_options,Boost 1.59.0,To Be Determined,Bugs,Vladimir Prus,new,2015-09-24T13:12:05Z,2015-09-30T10:41:47Z,"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?",mskalick@…
11680,boost::polygon::connectivity_extraction<int>::extract crashes when no polygons were inserted,polygon,Boost 1.58.0,To Be Determined,Bugs,Lucanus Simonson,new,2015-09-24T08:56:52Z,2015-09-24T08:59:07Z,"steps to reproduce:

{{{#!C++
#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 

{{{#!C++
    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 ?",mhilferink@…
11679,boost::polygon::connectivity_extraction<int>::extract crashes when no polygons were inserted,polygon,Boost 1.58.0,To Be Determined,Bugs,Lucanus Simonson,new,2015-09-24T08:56:50Z,2015-09-24T08:56:50Z,"steps to reproduce:

{{{#!C++
#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 

{{{#!C++
    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 ?",mhilferink@…
11677,too long file name,geometry,Boost 1.57.0,To Be Determined,Bugs,awulkiew,new,2015-09-22T03:32:33Z,2015-10-02T08:48:34Z,"C:\Users\me\Downloads\boost_1_59_0.7z\boost_1_59_0\libs\geometry\doc\html\geometry\reference\spatial_indexes\boost__geometry__index__rtree\rtree_parameters_type_const____indexable_getter_const____value_equal_const____allocator_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 
",anonymous
11675,sym_difference yields bad result for int polygons,geometry,Boost 1.59.0,To Be Determined,Bugs,Barend Gehrels,new,2015-09-21T14:31:07Z,2018-07-19T13:32:06Z,"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.",vschoech@…
11670,Boost intrusive constructors should be constexpr,intrusive,Boost 1.60.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-09-18T23:15:49Z,2015-09-18T23:15:49Z,"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",ben.maurer@…
11668,"cpu_timer methods documented as noexcept, while in code they are not",timer,Boost 1.59.0,To Be Determined,Bugs,Beman Dawes,new,2015-09-18T15:17:38Z,2015-09-18T15:17:38Z,"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",George Butnaru <geo.butnaru@…>
11667,Error compiling VS2013 update 5,Building Boost,Boost 1.59.0,To Be Determined,Bugs,,new,2015-09-18T12:46:00Z,2015-09-18T12:46:00Z,"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)'",anonymous
11666,"graph library documentation issues (""Using adjacency_list"")",graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-09-18T12:19:48Z,2015-09-23T23:09:28Z,"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;
> };
> }}}

1. Where is ''num'' defined? (Is it necessary at all?)
2. (If necessary) where exactly does it need to be unique? (Within a certain namespace? Over all edge properties? Over all vertex+edge properties?
3. What about the range (number of bits?), reserved numbers/ranges and consecutiveness?

> Access the propety acessor type for this graph

(Typo in ""property"")",Hans Meine <hans_meine@…>
11663,No way to query file extension without allocating memory,filesystem,Boost 1.57.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2015-09-17T06:44:37Z,2016-09-09T18:14:22Z,"the function .extension() returns an fs::path, containing a fresh string that contains the extension.  On certain library implementations that don't implement the SSO -- or, I guess, for files with very long extensions -- there will be a memory allocation each time the function is called.

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

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

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

I propose adding the function bool path::has_extension(string const&) which can compare the extension in a memory-friendly way.",matthew.chaplain@…
11662,Parse Json,property_tree,Boost 1.58.0,To Be Determined,Bugs,Sebastian Redl,new,2015-09-17T04:31:49Z,2015-09-23T23:09:51Z,"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);

	}
}

}}}


",KigKrazy@…
11660,"interprocess::winapi::get_last_bootup_time(std::string &stamp) fails, resulting in bad IPC name",interprocess,Boost 1.59.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-09-16T14:57:08Z,2016-01-12T02:40:29Z,"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.",bmccart@…
11659,push_relabel_max_flow,graph,Boost 1.59.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-09-16T06:05:12Z,2016-08-09T07:50:17Z,"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;
}


}}}
",anonymous
11658,push_relabel_max_flow,graph,Boost 1.59.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-09-16T06:05:07Z,2016-08-09T07:49:05Z,"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;
}


}}}
",anonymous
11657,Add VxWorks support for program options,program_options,Boost 1.59.0,To Be Determined,Patches,Vladimir Prus,new,2015-09-16T05:13:47Z,2015-09-18T17:00:07Z,"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)   ",Brian Kuhl <brian.kuhl@…>
11656,Updated VxWorks support for iostreams,iostreams,Boost 1.59.0,To Be Determined,Patches,Jonathan Turkanis,new,2015-09-16T05:03:43Z,2015-09-16T05:27:26Z,"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",Brian Kuhl <brian.kuhl@…>
11654,Updated VxWorks support for asio,asio,Boost 1.59.0,To Be Determined,Patches,chris_kohlhoff,new,2015-09-16T04:42:15Z,2015-09-16T04:42:15Z,"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 ",Brian Kuhl <brian.kuhl@…>
11651,boost::to_upper and boost::to_lower damages non ascii-charasters in std::u32string,string_algo,Boost 1.59.0,To Be Determined,Bugs,Marshall Clow,new,2015-09-14T18:41:19Z,2015-09-15T03:22:05Z,"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",anonymous
11650,boost range size() fails concept on subarray of a const multi_array,multi_array,Boost 1.59.0,To Be Determined,Bugs,Ronald Garcia,new,2015-09-14T10:06:01Z,2015-09-14T15:21:53Z,"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",John Reid <johnbaronreid@…>
11646,Boost ASIO server-side async_handshake handler not called if Diffie-Hellman key is too small,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-09-11T22:18:07Z,2015-09-11T22:18:07Z,"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.

",c.m.brandenburg@…
11643,warning clang without c++11,mpl,Boost 1.59.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-09-11T11:35:45Z,2015-09-11T11:35:45Z,"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));
",anonymous
11640,scope_exit: -Wshadow warning issued,scope_exit,Boost 1.58.0,To Be Determined,Bugs,Lorenzo Caminiti,new,2015-09-10T13:33:35Z,2018-06-19T11:38:58Z,"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:
{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!c++
#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;
       ^

",lukasz.czajczyk@…
11639,document std's vs boost's chrono::steady_clock system-wideness discrepancy,chrono,Boost 1.59.0,To Be Determined,Support Requests,viboes,assigned,2015-09-10T08:20:34Z,2015-10-25T23:49:58Z,"boost doc states that its steady_clock is system-wide, in doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.cpp0x.system_clocks_hpp.steady_clock
{{{
steady_clock class provides access to the system-wide steady clock.
The current time can be obtained by calling steady_clock::now().
There is no fixed relationship between values returned by
steady_clock::now() and wall-clock time. 
}}}

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

It would be good to highlight this discrepancy in the doc, especially since the doc ""Included on the C++11 Recommendation"" section let's you think that boost's chrono and std's chrono are interchangeable.",Sébastien Barthélémy <barthelemy@…>
11633,chrono IO V1 may throw bad_cast,chrono,Boost 1.58.0,To Be Determined,Support Requests,viboes,assigned,2015-09-09T14:59:45Z,2017-08-28T05:19:54Z,"I had occurences of chrono io throwing bad_cast exceptions, which lead to backtraces like this one:


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

I think the attached minimal example reproduces the issue.

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


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

maybe we could avoid calling os.getloc() again at line 210 to avoid the race?",Sébastien Barthélémy <barthelemy@…>
11629,Appears clash when the boost::log and boost::asio::io_service are running in the same time.,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-09-09T03:12:44Z,2015-09-09T03:12:44Z,"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.",liangzhonghong <1054116023@…>
11626,graph: segfault with custom container example,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-09-07T17:10:05Z,2015-09-07T17:25:33Z,"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.",blobfish@…
11622,std::auto_ptr is deprecated,smart_ptr,Boost 1.59.0,To Be Determined,Bugs,Peter Dimov,new,2015-09-07T09:10:26Z,2018-05-30T00:38:12Z,"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
",anonymous
11621,"Regexp doesn't match ""\\""",spirit,Boost Development Trunk,To Be Determined,Bugs,Joel de Guzman,new,2015-09-06T10:37:26Z,2015-09-06T10:37:26Z,"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/.",dezelin@…
11620,BOOST_NO_AUTO_PTR support for ptr_container,ptr_container,Boost 1.59.0,To Be Determined,Feature Requests,Thorsten Ottosen,new,2015-09-06T09:48:23Z,2015-09-06T09:48:23Z,it would be nice if ptr_container could make use of BOOST_NO_AUTO_PTR.,timblechmann
11619,Chrono V2 IO - format tags 'unsupported'?,chrono,Boost 1.59.0,To Be Determined,Support Requests,viboes,assigned,2015-09-04T20:24:43Z,2015-09-11T17:02:24Z,"http://www.boost.org/doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.io.ios_state_hpp.sag.set_time_fmt 

table 6.3 on the page linked above describes format tags to be used with IO. Several are listed as unsupported. There is no explanation of what 'unsupported' means. Does it mean a format string with one of those tags will cause an exception? Will the format tag be ignored? Will the entire format string fail to work? Will interation over the string stop before or after the 'unsupported' tag? More explanation would be helpful here.",steve.hickman@…
11613,ptime deserialization runtime issue when using ClCompile->Optimization set to MaxSpeed.,date_time,Boost 1.59.0,To Be Determined,Bugs,az_sw_dude,new,2015-09-02T14:30:51Z,2015-09-02T14:30:51Z,"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.",dirtypiece@…
11609,circular_buffer erroneously invalidates reverse_iterator at pop_back in debug mode,circular_buffer,Boost 1.57.0,To Be Determined,Bugs,Jan Gaspar,new,2015-09-01T15:50:34Z,2015-09-02T17:54:42Z,"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.""
}
}}}

",christian.stimming@…
11601,Boost 1.59 doesn't build with Visual C++ 2015,build,Boost 1.59.0,To Be Determined,Bugs,Vladimir Prus,new,2015-08-31T07:33:07Z,2015-09-03T17:56:06Z,"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? ",anonymous
11597,undefined reference to boost::system::generic_category(),system,Boost 1.59.0,To Be Determined,Bugs,Beman Dawes,new,2015-08-29T05:57:02Z,2015-08-29T05:57:02Z,"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
",davido
11595,boost container forward declares names from the std namespace illegally,container,Boost 1.58.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-08-27T18:49:05Z,2015-08-27T18:49:05Z,"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).",Mathias Gaunard
11594,"mpl/test/string.cpp fails, test needs to take into account endianness.",mpl,Boost Development Trunk,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-08-27T17:29:00Z,2015-08-27T17:40:26Z,"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_::failed************boost::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_::failed************boost::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_::failed************boost::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_::failed************boost::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_::failed************boost::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_::failed************boost::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.
%",Aparna Kumta <aparna.kumta@…>
11588,Build error using --build-type=complete,build,Boost 1.59.0,To Be Determined,Bugs,Vladimir Prus,new,2015-08-27T12:05:16Z,2015-08-27T12:24:01Z,".../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.
",anonymous
11587,Compute index from offset and vice versa,multi_array,Boost 1.59.0,To Be Determined,Feature Requests,Ronald Garcia,new,2015-08-27T09:38:48Z,2015-08-27T09:38:48Z,"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.",alex.shtf@…
11586,Webcheck result is outdated: Remove or update,website,Boost 1.59.0,To Be Determined,Bugs,René Rivera,new,2015-08-27T01:55:25Z,2015-08-27T01:57:58Z,"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
",Ben Wiederhake <Ben.Wiederhake@…>
11585,Johnson All Pairs - wrong edge mapping,algorithm,Boost 1.58.0,To Be Determined,Bugs,Marshall Clow,new,2015-08-26T22:37:36Z,2015-08-26T22:37:36Z,"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.",Harold Ishebabi <harold.ishebabi@…>
11584,Johnson All Pairs - wrong edge mapping,algorithm,Boost 1.58.0,To Be Determined,Bugs,Marshall Clow,new,2015-08-26T22:37:36Z,2015-08-26T22:37:36Z,"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.",Harold Ishebabi <harold.ishebabi@…>
11583,Johnson All Pairs - wrong edge mapping,algorithm,Boost 1.58.0,To Be Determined,Bugs,Marshall Clow,new,2015-08-26T22:37:32Z,2015-08-26T22:37:32Z,"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.",Harold Ishebabi <harold.ishebabi@…>
11581,Interprocess documentation error,interprocess,Boost 1.59.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-08-26T13:55:05Z,2015-08-26T13:55:05Z,"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.",anonymous
11580,invalid buffer result,geometry,Boost 1.59.0,To Be Determined,Bugs,Barend Gehrels,assigned,2015-08-25T10:00:19Z,2016-03-26T15:33:14Z,"The following code example produces invalid results. Reducing the distance e.g. from 2.37 to 1 produces correct results.
I have tested this code with boost 1.57 and boost 1.59 with the same results.

{{{

#include <boost/geometry.hpp>
#include <boost/geometry/geometries/geometries.hpp>

namespace bg = boost::geometry;

int main()
{
	typedef bg::model::point<double, 2, bg::cs::cartesian> point;
	typedef bg::model::polygon<point> polygon;

	polygon poly;
	bg::read_wkt(""POLYGON((14.02 474.96,14.02 494.96,14.022 494.96,14.022 486.24,14.02 474.96))"", poly);

        bg::strategy::buffer::distance_symmetric<double> distance_strategy(2.37);
	bg::strategy::buffer::side_straight side_strategy;
	bg::strategy::buffer::join_miter join_strategy;
	bg::strategy::buffer::end_flat end_strategy;
	bg::strategy::buffer::point_circle point_strategy;

	bg::model::multi_polygon<Polygon> grown;
	bg::buffer(poly, grown, distance_strategy, side_strategy, join_strategy,
			   end_strategy, point_strategy);

	std::cout << bg::wkt(grown) << std::endl;
	return 0;
}

}}}

The returned shape is:

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

",Marios Visvardis <visvardis.marios@…>
11577,Parallel graph documentation refers to non-existent type,graph,Boost 1.59.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-08-24T18:33:18Z,2015-08-24T18:33:18Z,"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.",Jeff Trull <edaskel@…>
11576,boost::geometry::intersection wrong results,geometry,Boost 1.61.0,Boost 1.61.0,Bugs,Barend Gehrels,reopened,2015-08-24T17:01:43Z,2016-06-02T21:00:20Z,"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;
}
}}}
",alex-x@…
11575,"Boost::Polygon insert(item, true) of polygon_set_data wrong",polygon,Boost 1.56.0,To Be Determined,Bugs,Lucanus Simonson,new,2015-08-24T16:50:21Z,2015-08-24T16:50:21Z,"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
",cybfly1@…
11573,Mac OSX 10.5.8 install of Boost v1.59,Building Boost,Boost 1.59.0,To Be Determined,Bugs,,new,2015-08-24T08:24:33Z,2015-10-05T10:35:54Z,Using Macports to install Boost fails on OSX 10.5.8 (Leopard).  Version 1.58 installs fine.  Server log file attached...,schalk@…
11568,Memory mapping with Boost version 1.57,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-08-21T11:54:41Z,2015-08-22T20:02:43Z,"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",raviappaji11@…
11567,"Boost crashes when boost::filesystem::path::imbue(std::locale(""""));",filesystem,Boost 1.57.0,Boost 1.58.0,Bugs,Beman Dawes,new,2015-08-21T10:47:25Z,2015-09-30T15:13:44Z,"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
  }
}}}",anonymous
11564,ZLIB library test failing on Solaris,Building Boost,Boost 1.59.0,To Be Determined,Bugs,,new,2015-08-20T13:47:23Z,2015-08-20T13:47:23Z,"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.

",lcarreon@…
11563,boost::range behavior changed from 1.55 to 1.56,range,Boost 1.59.0,To Be Determined,Bugs,Neil Groves,new,2015-08-20T12:15:43Z,2015-08-21T12:48:54Z,"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.

",fiesh@…
11561,"Build fails with threading=single,multi",build,Boost 1.59.0,To Be Determined,Bugs,Vladimir Prus,new,2015-08-20T07:30:22Z,2018-02-25T20:21:57Z,"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 [https://trac.macports.org/ticket/48614 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.",ryandesign@…
11553,Problem with std::complex,python USE GITHUB,Boost 1.59.0,To Be Determined,Bugs,Stefan Seefeld,new,2015-08-18T11:00:02Z,2015-08-18T17:19:42Z,"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.
",lcarreon@…
11552,Warning from chrono that could helpfully be suppressed,ratio,Boost 1.59.0,Boost 1.60.0,Feature Requests,viboes,assigned,2015-08-18T10:58:32Z,2017-08-22T20:51:01Z," Boost.Chrono is emitting warnings with GCC (5.1.0) that cannot be suppressed even using the following cxxflags in the user jamfile


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


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

For example:



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

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


and more...

It would be nice if the user would not see these (spurious?) warnings.",Paul A. Bristow
11551,Missing type member,proto,Boost 1.59.0,To Be Determined,Bugs,Eric Niebler,new,2015-08-18T10:56:48Z,2015-08-18T10:56:48Z,"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.
",lcarreon@…
11550,Solaris - boost::call_once issues,thread,Boost 1.59.0,To Be Determined,Bugs,viboes,assigned,2015-08-18T10:46:34Z,2015-09-23T22:23:06Z,"I compiled Boost 1.59.0 with Solaris Studio 12.4 in C++11 mode and I
 get the following error messages:


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


I'm not 100% sure whether these are compiler issues or Boost compiler
configuration issues thus I decided to raise this ticket.
",lcarreon@…
11548,Crosscompiling 1.59 with i686-w64-mingw32-g++ fails,serialization,Boost 1.59.0,To Be Determined,Bugs,Robert Ramey,new,2015-08-18T09:07:18Z,2016-11-18T10:27:42Z,"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.


",Alexander Zimmermann <zimmermann@…>
11542,Using geometry buffer with integer coordinate type,geometry,Boost 1.59.0,To Be Determined,Bugs,Barend Gehrels,new,2015-08-17T16:21:01Z,2015-08-17T16:21:01Z,"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());
",jim.whittaker@…
11539,VS2015 warning: macro redefinition,asio,Boost 1.59.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-08-15T11:13:21Z,2015-09-23T06:48:10Z,"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'",anonymous
11537,named_recursive_mutex deadlock problem,interprocess,Boost 1.49.0,To Be Determined,Support Requests,Ion Gaztañaga,new,2015-08-13T07:27:49Z,2015-08-13T07:27:49Z,"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 ()",zzweng_2001@…
11535,standard integrate_times function causes tiny time steps,odeint,Boost 1.58.0,To Be Determined,Bugs,karsten,new,2015-08-12T02:50:48Z,2018-04-16T15:48:15Z,"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;
}

}}}",gaiwa84@…
11534,timer/inspect execution failure w/ g++-4.9.2 on Solaris 11.2,timer,Boost 1.58.0,Boost 1.59.0,Bugs,Beman Dawes,new,2015-08-11T18:51:32Z,2015-08-11T18:51:32Z,"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

",angela.xie@…
11529,regression: boost::archive::archive_exception exception during serialization non latin1 strings to xml,serialization,Boost 1.58.0,To Be Determined,Bugs,Robert Ramey,reopened,2015-08-07T10:44:05Z,2016-03-09T10:52:47Z,"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.",nikolay@…
11528,MSVS 2015 + boost::range: STL and Boost iterators,range,Boost Development Trunk,To Be Determined,Bugs,Neil Groves,new,2015-08-06T14:16:16Z,2017-02-28T15:03:14Z,"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.",Dennis Schneider <dsr@…>
11527,socket  connection error,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-08-06T13:52:14Z,2015-08-06T13:52:14Z,"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 .
",danial1360@…
11523,Interprocess communication between x86 and x64 issue,interprocess,Boost 1.58.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-08-04T13:50:50Z,2015-08-04T13:50:50Z,"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`). 

{{{#!c++
#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.",lutztonineubert@…
11521,Cannot create basic_vectorstream<std::vector<char>> in Boost 1.55+,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-08-01T23:59:07Z,2015-08-20T23:06:48Z,"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",anonymous
11520,"pointer_iserializer requires operator delete(void*, size_t) for classes that have a specific operator new",serialization,Boost 1.56.0,To Be Determined,Bugs,Robert Ramey,reopened,2015-07-31T20:59:28Z,2016-03-06T08:04:42Z,"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.",Fabian Kislat <fabian.kislat@…>
11515,dynamic_bitset move constructor should be conditionally noexcept,dynamic_bitset,Boost 1.58.0,To Be Determined,Bugs,jsiek,new,2015-07-27T19:09:58Z,2015-07-27T19:09:58Z,"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.",anonymous
11513,roadmap update,website,,Website 1.X,Tasks,René Rivera,new,2015-07-27T07:29:43Z,2015-07-27T07:29:43Z,"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!

",anonymous
11511,concept_checks: -Wshadow warning isued,multi_array,Boost 1.59.0,To Be Determined,Bugs,Ronald Garcia,new,2015-07-26T13:06:11Z,2015-07-26T13:06:11Z,-Wshadow warnings are issued.,davido
11509,gzip: -Wunused warning issued,iostreams,Boost 1.59.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-07-26T12:51:58Z,2015-07-26T12:51:58Z,-Wunused warning is issued.,davido
11508,buffer: -Wshadow warning issued,iostreams,Boost 1.59.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-07-26T12:49:59Z,2015-07-26T12:49:59Z,"-Wshadow warnings are issued for the following files:

* buffer.hpp
* gzip.hpp
* zlib.cpp",davido
11507,parser: -Wshadow warning issued,property_tree,Boost 1.59.0,To Be Determined,Bugs,Sebastian Redl,new,2015-07-26T12:46:41Z,2015-07-26T12:46:41Z,-Wshadow warnings are issued.,davido
11506,rational: -Wshadow warning issued,rational,Boost 1.59.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-07-26T12:44:26Z,2015-07-26T12:44:26Z,-Wshadow warning is issued for what parameter.,davido
11505,operators: -Wundef warning issued for __NVCC__ construct,mpl,Boost 1.59.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-07-26T12:36:58Z,2015-07-26T12:36:58Z,"-Wundef warning is issued for __NVCC__ construct.

Removing this line fixed it for me:

""BOOST_WORKAROUND(__NVCC__, BOOST_TESTED_AT(1)) \""
",davido
11504,operators: -Wundef warning issued for __NVCC__ construct,mpl,Boost 1.59.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-07-26T12:33:39Z,2015-07-26T12:33:39Z,-Wundef warning is issued for __NVCC__ construct.,davido
11502,narrow_encoding: -Wtype-limits warning is reported,property_tree,Boost 1.59.0,To Be Determined,Bugs,Sebastian Redl,assigned,2015-07-26T12:28:26Z,2016-02-10T12:51:31Z,"-Wtype-limit is reported on this assert:

    char to_internal_trivial(char c) const {
        assert(c <= 0x7f); <=== Type limit
        return c;
    }
",davido
11501,standard_callbacks: -Wreturn-type warning when building in release mode,property_tree,Boost 1.59.0,To Be Determined,Bugs,Sebastian Redl,new,2015-07-26T12:12:13Z,2015-10-21T13:32:24Z,assert macro is replaced to void in release build mode. This leads to -Wreturn-type warning.,davido
11499,windows - exception lock_error while intensive locking/unlocking of shared_mutex on many threads,thread,Boost 1.59.0,To Be Determined,Bugs,viboes,assigned,2015-07-25T23:07:06Z,2016-08-15T17:59:25Z,"
{{{
#include ""stdafx.h""
#include <boost/thread/shared_mutex.hpp>
#include <thread>
#include <mutex>
#include <shared_mutex>
#include <atomic>
#include <vector>

using MutexT = boost::shared_mutex;
using ReaderLockT = std::lock_guard<MutexT>;
using WriterLockT = std::shared_lock<MutexT>;

MutexT gMutex;
std::atomic<bool> running = true;

long reads = 0;

void read()
{
   while (running)
   {
      ReaderLockT lock(gMutex);
      std::this_thread::yield();
      ++reads;
   }
}

int main()
{
   using namespace std;

   vector<thread> threads;
   for (int i = 0; i < 256; ++i)
   {
      threads.emplace_back(thread(read));
   }

   string str;

   getline(std::cin, str);
   running = false;

   for (auto& thread : threads)
   {
      thread.join();
   }

   return 0;
}


}}}
",andrew maclean <agm@…>
11497,std::front and std::back,utility,Boost 1.57.0,To Be Determined,Feature Requests,No-Maintainer,new,2015-07-24T12:13:12Z,2015-07-24T12:13:12Z,"I needed to get the first and last element in an array. Recently the STL got the free form std::begin and std::end which is good, but wouldn't it be an idea to have std::front (or boost::front) and std::back (boost::back) as well?

See also http://stackoverflow.com/questions/14880172/missing-stdfront-and-stdback",gast128@…
11490,"boost::lockfree::spsc_queue::pop(T*, size_type) did not compile when used with interprocess allocator",lockfree,Boost 1.58.0,To Be Determined,Bugs,timblechmann,new,2015-07-21T13:20:41Z,2016-01-06T12:37:49Z,"The method runtime_sized_ringbuffer::pop(T*, size_type) when used with interprocess allocator produces the following error when compiled with g++ 4.9.1 under linux:

/usr/local/include/boost/lockfree/spsc_queue.hpp: In instantiation of ‘boost::lockfree::detail::runtime_sized_ringbuffer<T, Alloc>::size_type boost::lockfree::detail::runtime_sized_ringbuffer<T, Alloc>::pop(T*, boost::lockfree::detail::runtime_sized_ringbuffer<T, Alloc>::size_type) [with T = int; Alloc = boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> >; boost::lockfree::detail::runtime_sized_ringbuffer<T, Alloc>::size_type = long unsigned int]’:
/usr/local/include/boost/lockfree/spsc_queue.hpp:556:27:   required from ‘boost::lockfree::detail::runtime_sized_ringbuffer<T, Alloc>::~runtime_sized_ringbuffer() [with T = int; Alloc = boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> >]’
/usr/local/include/boost/lockfree/spsc_queue.hpp:679:7:   required from ‘void boost::interprocess::ipcdetail::placement_destroy<T>::destroy_n(void*, std::size_t, std::size_t&) [with T = boost::lockfree::spsc_queue<int, boost::lockfree::allocator<boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > > >; std::size_t = long unsigned int]’
spsc_queue_interprocess_test.cpp:33:1:   required from here
/usr/local/include/boost/lockfree/spsc_queue.hpp:609:72: error: no matching function for call to ‘boost::lockfree::detail::runtime_sized_ringbuffer<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > >::pop(int*&, boost::lockfree::detail::runtime_sized_ringbuffer<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > >::size_type&, boost::lockfree::detail::runtime_sized_ringbuffer<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > >::pointer&, boost::lockfree::detail::runtime_sized_ringbuffer<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > >::size_type&)’
         return ringbuffer_base<T>::pop(ret, size, array_, max_elements_);
                                                                        ^
/usr/local/include/boost/lockfree/spsc_queue.hpp:609:72: note: candidate is:
/usr/local/include/boost/lockfree/spsc_queue.hpp:263:12: note: boost::lockfree::detail::ringbuffer_base<T>::size_t boost::lockfree::detail::ringbuffer_base<T>::pop(T*, boost::lockfree::detail::ringbuffer_base<T>::size_t, T*, boost::lockfree::detail::ringbuffer_base<T>::size_t) [with T = int; boost::lockfree::detail::ringbuffer_base<T>::size_t = long unsigned int]
     size_t pop (T * output_buffer, size_t output_count, T * internal_buffer, size_t max_size)
            ^
/usr/local/include/boost/lockfree/spsc_queue.hpp:263:12: note:   no known conversion for argument 3 from ‘boost::lockfree::detail::runtime_sized_ringbuffer<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>, boost::interprocess::iset_index> > >::pointer {aka boost::interprocess::offset_ptr<int, long int, long unsigned int, 0ul>}’ to ‘int*’

I have attached a small test to reproduce the problem and a patch, but other method seems to suffer from the same problem.
",Philippe Leuba <pleuba@…>
11489,"async_connect reports ""success"" on localhost even if the connection is refused",asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-07-21T11:05:22Z,2015-07-21T11:05:22Z,"Async_connect does not report ""failure"" when the server is not open. This problem is replicated only on localhost using TCP communication (on UDP works fine).

There are 2 tickets opened on the same issue (#8995 and #8795) both closed, but the problem still replicates in upper versions.",cristina.radulescu22@…
11487,Boost doesn't build with Visual C++ 2015,Building Boost,Boost 1.58.0,To Be Determined,Bugs,,new,2015-07-21T06:57:14Z,2016-04-06T23:14:30Z,"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?",Russell Wallace <russell.wallace@…>
11486,Unable to Locate bjam.exe on web and unable to build Boost Jam using bootstrap.bat,Building Boost,Boost 1.58.0,To Be Determined,Bugs,,new,2015-07-21T02:21:49Z,2015-12-14T12:24:33Z,"Hi, I'm wanting to use Boost.Python to connect C++ with Python.
I've installed boost.
---------- SIDE NOTE --------------------------
 - during the process I was not sure what MSVC version I have

The VS 2013 express that I use is located in:
Microsoft Visual Studio 12.0

But running the cl.exe (the compiler) within that directory gives
Visual C++ version 18!!

So I assume I go by the first number.  So I downloaded boost windows installer 
version MSVC-12.0-32bit (32-bit because something nearly always goes wrong 
in the future like one library is 64-bit while another is 32-bit, so I simply
chose 32-bit even though I'm on a Windows 8 64-bit machine).
-------------------------------------------------------------

Anyway, boost log attached, I tried running boostrap.bat in the boost 
install directory to try and build boost jam and it failed but maybe you can help there.

Or just help me find pre-built binaries because they're not located on
SourceForge where all the links say they are located. -- Please Download and See!

Thanks.
Regards,
-EM",Daniel Donnelly <enjoysmath@…>
11481,zip_iterator issue with _GLIBCXX_DEBUG and std::vector::insert,iterator,Boost 1.57.0,To Be Determined,Bugs,jeffrey.hellrung,new,2015-07-16T11:59:20Z,2015-07-16T11:59:20Z,"If one uses the `zip_iterator` class template with `std::vector::insert(It1, It2, It2)`, with `_GLIBCXX_DEBUG` defined, g++ return a compilation error:
{{{
/usr/include/c++/4.9.2/debug/functions.h:220:69: error: invalid initialization of non-const reference of type ‘boost::tuples::cons<int&, boost::tuples::cons<int&, boost::tuples::null_type> >&’ from an rvalue of type ‘boost::iterator_facade<boost::zip_iterator<boost::tuples::tuple<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<int*, std::__cxx1998::vector<int, std::allocator<int> > >, std::__debug::vector<int> >, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<int*, std::__cxx1998::vector<int, std::allocator<int> > >, std::__debug::vector<int> > > >, boost::tuples::cons<int&, boost::tuples::cons<int&, boost::tuples::null_type> >, boost::random_access_traversal_tag, boost::tuples::cons<int&, boost::tuples::cons<int&, boost::tuples::null_type> >, long int>::reference {aka boost::tuples::cons<int&, boost::tuples::cons<int&, boost::tuples::null_type> >}’
       return __foreign_iterator_aux4(__it, std::__addressof(*__other));
                                                                     ^

}}}

The attached test case `test.cpp` shows the error, with g++-4.9.
",laurent.rineau__cgal_boost@…
11480,Interprocess get_last_bootup_time use of Event Log on Windows is completely unreliable,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-07-15T21:33:40Z,2017-04-27T15:48:55Z,"We have been running into an issue where creating an interprocess message_queue would start to fail after some time on a production system (Windows 2012 Server) - throwing an interprocess_exception with error code 1 (native code=0).

After setting up remote debugging on the production system, we tracked it down to the get_last_bootup_time() function returning false because it couldn't find the 'Event Log Started (6005)' event in the log. (win32_api.hpp)

The Event Logs don't last forever.  Windows prunes old events when the logs grow.  If I understand the use of the Event Log to determine a boot time correctly, then this is a nasty hack and must be changed.  It is not reliable.

Perhaps a solution would be to maintain a 'current' boot time file.  You could attempt to find the boot time using the Event log (or other technique) and write it to the 'current' file.  If you couldn't obtain the boot time, just use the existing 'current' file.  If no current file exists, write one with an arbitrary time (eg. 00000).  At least this way, it will never fail, and usually will roll over to a new folder after a reboot.
",Craig White <cwhite102@…>
11473,basic_ptree documentation is missing,property_tree,Boost 1.58.0,To Be Determined,Bugs,Sebastian Redl,new,2015-07-14T12:04:49Z,2015-07-14T12:04:49Z,"basic_ptree class documentation is missing. It was available (thou hard to find) in 1.57, but in 1.58 there is no link to it from reference page. None of the 'basic_ptree' occurrences on this page:

http://www.boost.org/doc/libs/1_58_0/doc/html/property_tree/reference.html

is a hyperlink.",Maciej Gajewski <maciej.gajewski0@…>
11470,Invalid results using convex_hull with unsigned integer points coordinates,geometry,Boost 1.58.0,To Be Determined,Bugs,Barend Gehrels,new,2015-07-10T11:15:12Z,2015-11-18T11:06:12Z,"Hi, I think convex_hull algorithm does not support unsigned integer points coordinates.

The following code works well with signed integer but return a wrong result for unsigned version :


{{{

#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <deque>
 

int main()
{
    typedef boost::geometry::model::d2::point_xy<unsigned int> PointInt;
    typedef boost::geometry::model::polygon<PointInt> polygon_type;

    polygon_type poly1, convPoly1;
    polygon_type poly2, convPoly2;
    boost::geometry::read_wkt(""POLYGON((245 143, 243 113, 236 101, 228 100, 222 106, 217 121, 217 144, 220 155, 227 165, 233 166, 237 163, 245 143))"", poly1);
    boost::geometry::convex_hull(poly1, convPoly1);

    return 0;
}

}}}

Attached file is a representation of input polygon (orange) and output result (blue) curve.
",Eric Noirfalise <eric.noirfalise@…>
11469,libs/iostreams/test/detail/file_handle.hpp should include unistd.h,iostreams,Boost 1.56.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-07-09T19:43:49Z,2015-07-09T19:43:49Z,"the file libs/iostreams/test/detail/file_handle.hpp uses the
::close function.  According to Posix, this is declared in unistd.h.

However, the file does not include unistd.h

It should.

Yea...a nit.",Ed Vogel <edward.vogel@…>
11456,"deadline timer works using gcc 4.4, breaks with gcc 4.7, after switching from boost 52 to 58",asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-07-08T15:19:43Z,2015-07-08T15:19:43Z,"Our project recently switched from boost 52 to boost 58
Our boost libs (.so) are built using gcc 4.4 on linux 32 bit

When building our test application using gcc 4.4 we see no problems.
When building with gcc 4.7 our test application, which consists of 2 deadline timers, starts, but ioservice::run never returns.
When enabling -DBOOST_ASIO_ENABLE_HANDLER_TRACKING the application segfaults on boost/asio/detail/op_queue.hpp:42 (o1->next_ = 02;)

Using boost 52, built with gcc 4.4, our test application, built with gcc 4.7, runs without problems.

",P.S.vanderHeide@…
11448,posix::stream_descriptor with ::dup(STDIN_FILENO) as in sample posix chat client kills shell on Solaris 11.2,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-07-02T22:48:59Z,2015-07-02T23:24:18Z,"If you build boost_1_58_0/libs/asio/example/cpp03/chat/posix_chat_client.cpp on Solaris 11.2 and run it, it immediately terminates. Unfortunately it terminates also the running shell which startet posix_chat_client.

It is not important whether you compile with gcc or Sun CC. The behavior is always the same.

It you redirect the input from a file (posix_chat_client < some-file) or pipe data to it, everything works. The shell persists.

If you disable /dev/poll for Boost::Asio (macro via command line at compilation -DBOOST_ASIO_DISABLE_DEV_POLL) the program runs and accepts inputs. As soon as you terminate the chat client the shell terminates, too.

The problem seems to be the initialization of boost::asio::posix::stream_descriptor input_ in class posix_chat_client:
input_(io_service, ::dup(STDIN_FILENO))",Oliver Mueller <info@…>
11442,boost/smart_ptr/detail/yield_k.hpp should not unconditionally call ::nanosleep,smart_ptr,Boost 1.56.0,To Be Determined,Bugs,Peter Dimov,new,2015-07-02T01:12:41Z,2015-07-02T01:12:41Z,"The file boost/smart_ptr/detail/yield_k.hpp will call ::nanosleep when
it's compiled in multi-threaded mode.

As nanosleep is not required for Boost (there is a BOOST_HAS_NANOSLEEP
function), this code should really be guarded by conditionals and an
#error directive executed if the platform does not support nanosleep.

Yea...a real nit...but my boss wants one posted...

Ed",Ed Vogel <edward.vogel@…>
11441,Documentation sample error,accumulator,Boost 1.58.0,To Be Determined,Bugs,Eric Niebler,new,2015-07-01T12:46:04Z,2016-01-14T00:12:26Z,"User'd guide. 

 Accumulators sample program:

#include <iostream>
#include <boost/accumulators/accumulators.hpp>
#include <boost/accumulators/statistics/stats.hpp>
#include <boost/accumulators/statistics/mean.hpp>
#include <boost/accumulators/statistics/moment.hpp>
using namespace boost::accumulators;

int main()
{
    // Define an accumulator set for calculating the mean and the
    // 2nd moment ...
    accumulator_set<double, stats<tag::mean, tag::moment<2> > > acc;

    // push in some data ...
    acc(1.2);
    acc(2.3);
    acc(3.4);
    acc(4.5);

    // Display the results ...
    std::cout << ""Mean:   "" << mean(acc) << std::endl;
    std::cout << ""Moment: "" << accumulators::moment<2>(acc) << std::endl;

    return 0;
}

In a line ""std::cout << ""Moment: "" << accumulators::moment<2>(acc) << std::endl;""
name of namespace ""accumulators"" should be removed because namespace ""accumulators"" is already used.",ampoznyak@…
11440,bootstrap.sh suggests --toolset option,Building Boost,Boost 1.58.0,To Be Determined,Bugs,,new,2015-06-30T22:04:55Z,2015-06-30T22:04:55Z,"On FreeBSD ./bootstrap.sh --show-libraries says ""### No toolset specified. Please use --toolset option.""

--toolset does not work, and ./bootstrap.sh says that the name of the option is --with-toolset, not --toolset",penorman@…
11439,Duplicate name of actual target: <pstage/lib>libboost_system.a,Building Boost,Boost 1.53.0,To Be Determined,Support Requests,,new,2015-06-30T19:15:39Z,2015-09-17T20:34:35Z,"Hello,

I am trying to compile boost1.53, I can't use a version newer than 1.55 as this is for the Cufflinks RNA tools.  I already had this version installed and working previously, but an HDD made me have to reinstall everything. The commands I have used (multiple times) before are:

./bootstrap.sh

which gives:

Building Boost.Build engine with toolset gcc... tools/build/v2/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/boost-build2/doc/html/index.html

Then I run:

./bjam link=static runtime-link=static stage install I get the following

Which is now giving me:

Performing configuration checks

    - 32-bit                   : no
    - 64-bit                   : yes
    - x86                      : 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
    - iconv (libc)             : yes
    - icu                      : yes
    - gcc visibility           : yes
    - long double support      : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add ""using mpi ;"" to user-config.jam.
note: to suppress this message, pass ""--without-mpi"" to bjam.
note: otherwise, you can safely ignore this message.
/genome/Apps/boost_1_53_0/tools/build/v2/build/virtual-target.jam:1079: in virtual-target.register-actual-name from module virtual-target
error: Duplicate name of actual target: <pstage/lib>libboost_system.a
error: previous virtual target { common%common.copy-libboost_system.a.STATIC_LIB { gcc%gcc.archive-libboost_system.a.STATIC_LIB { gcc%gcc.compile.c++-error_code.o.OBJ { error_code.cpp.CPP } } } }
error: created from ./stage-proper
error: another virtual target { common%common.copy-libboost_system.a.STATIC_LIB { gcc%gcc.archive-libboost_system.a.STATIC_LIB { gcc%gcc.compile.c++-error_code.o.OBJ { error_code.cpp.CPP } } } }
error: created from ./stage-proper
error: added properties: <runtime-link>shared <warnings>on
error: removed properties: <runtime-link>static <warnings>all
/genome/Apps/boost_1_53_0/tools/build/v2/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@3722
/genome/Apps/boost_1_53_0/tools/build/v2/build/virtual-target.jam:135: in object(file-target)@3722.actualize from module object(file-target)@3722
/genome/Apps/boost_1_53_0/tools/build/v2/build-system.jam:749: in load from module build-system
/genome/Apps/boost_1_53_0/tools/build/v2/kernel/modules.jam:283: in import from module modules
/genome/Apps/boost_1_53_0/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module
/genome/Apps/boost_1_53_0/boost-build.jam:17: in module scope from module

Whereas before it compiled without issue.  I need the runtime-links to be static, when I try to make the cufflinks files I get a bunch of errors from hpp files in /usr/local/boost/* folders otherwise.",munholl@…
11438,Certificate for Boost wiki has expired,website,Boost Release Branch,To Be Determined,Bugs,René Rivera,new,2015-06-30T17:10:09Z,2015-06-30T17:10:09Z,"The security certificate for
https://svn.boost.org/trac/boost/wiki/ModularBoost 
expired in March. This results in security warnings when I go to the Boost wiki.",marcm@…
11437,rolling_mean returns incorrect result when using unsigned int,accumulator,Boost 1.58.0,To Be Determined,Bugs,Eric Niebler,new,2015-06-30T10:55:58Z,2018-02-07T10:16:33Z,"Using rolling_mean with a sample type of ""unsigned int"" leads to incorrect results. The following example outputs 1.43166e+009 instead of the expected 1.

{{{
#include <iostream>
#include <boost/accumulators/accumulators.hpp>
#include <boost/accumulators/statistics/stats.hpp>
#include <boost/accumulators/statistics/count.hpp>
#include <boost/accumulators/statistics/rolling_mean.hpp>

using namespace boost::accumulators;

int main(int argc, char** argv)
{
    accumulator_set<unsigned int, stats<tag::rolling_mean, tag::count>>  acc(tag::rolling_window::window_size = 3);

    acc(3);
    acc(2);
    acc(1);
    acc(0);

    std::cout << rolling_mean(acc) << std::endl;
}
}}}


The same problem happens if the sample type is ""int"" but you pass unsigned ints to the accumulator. For example, if you replace the above code with the following code, the result is the same:

{{{
    accumulator_set<int, stats<tag::rolling_mean, tag::count>>  acc(tag::rolling_window::window_size = 3);

    acc(3U);
    acc(2U);
    acc(1U);
    acc(0U);
}}}


I found this problem using Visual Studio 2010, after upgrading from Boost 1.44.0 to 1.58.0. With Boost 1.44.0, the above examples return 1.",Gareth White <gwhite@…>
11434,Broken link from Lambda docs,lambda,Boost 1.58.0,To Be Determined,Bugs,No-Maintainer,new,2015-06-30T00:56:06Z,2016-12-23T07:37:37Z,"The last link from Bibliography (Yiannis Smaragdakis) is broken. 

http://www.boost.org/doc/libs/1_58_0/doc/html/lambda.html

It should point at http://yanniss.github.io/fc++/ and not http://www.cc.gatech.edu/~yannis/fc++/",ToApolytoXaos
11430,accumulators/p_square_cumul_dist runtime failure,accumulator,Boost 1.58.0,To Be Determined,Bugs,Eric Niebler,new,2015-06-29T23:31:24Z,2015-06-30T00:22:34Z,"accumulators/p_square_cumul_dist runtime failure with g++-4.8.2 on solaris 11.2.

test result:
...
        echo ====== BEGIN OUTPUT ======
        cat ""../../../bin.v2/libs/accumulators/test/p_square_cumul_dist.test/gcc-4.8.2/release/link-static/p_square_cumul_dist.output""
        echo ====== END OUTPUT ======
    fi
    exit $status

====== BEGIN OUTPUT ======
Running 1 test case...
p_square_cumul_dist.cpp(66): error in ""test_stat"": difference{3.166%} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.010316599565214746} and histogram[i].second{0.01} exceeds 3%
p_square_cumul_dist.cpp(66): error in ""test_stat"": difference{3.66597%} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.020733193566368657} and histogram[i].second{0.02} exceeds 3%
p_square_cumul_dist.cpp(66): error in ""test_stat"": difference{3.31687%} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.030995060470952907} and histogram[i].second{0.029999999999999999} exceeds 3%
p_square_cumul_dist.cpp(66): error in ""test_stat"": difference{3.04411%} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.041217642957001199} and histogram[i].second{0.040000000000000001} exceeds 3%

*** 4 failures detected in test suite ""Master Test Suite""

EXIT STATUS: 201
====== END OUTPUT ======

Test failed with studio 12.4 as well with same error message
",anonymous
11421,[geometry] rstar segmentation fault boost version 1.58.0,geometry,Boost 1.58.0,To Be Determined,Bugs,awulkiew,assigned,2015-06-25T20:23:15Z,2016-06-27T12:47:13Z,"== Notes: ==

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

== system information: ==

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

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

MemTotal:       198094372 kB


== test program used to reproduce segmentation fault: ==


{{{
// File: test.cpp

#include <iostream>
#include <boost/geometry.hpp>
#include <boost/geometry/index/rtree.hpp>

// NOTE: 1250, 800 makes 10^6 geo fences
const int NUM_BOXES_LAT = 1250;
const int NUM_BOXES_LON = 800;
const float MAX_LAT_DEG = 61.2167f; // Anchorage AK
const float MIN_LAT_DEG = 25.7877f; // Miami FL
const float MAX_LON_DEG = -68.7703f; // Bangor ME
const float MIN_LON_DEG = -149.9000f; // Anchorage AK
const float DELTA_LAT_DEG = (MAX_LAT_DEG - MIN_LAT_DEG)/static_cast<float>(NUM_BOXES_LAT);
const float DELTA_LON_DEG = (MAX_LON_DEG - MIN_LON_DEG)/static_cast<float>(NUM_BOXES_LON);
using COORD_TYPE = boost::geometry::cs::cartesian;
using Point = boost::geometry::model::point<float, 2, COORD_TYPE>;
using Box = boost::geometry::model::box<Point>;
using BoxIDPair = std::pair<Box, unsigned>;

int main()
{
  // Create a grid of boxes evenly distributed across North America.
  // Test Note: swap out rtree algorithms to isolate seg fault problem
//  boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::rstar<16, 4> > locationGeometryTable; // seg fault @ 10^4 boxes
  boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::rstar<16> > locationGeometryTable; // seg fault @ 10^4 boxes
//  boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::quadratic<16> > locationGeometryTable; // pass @ 10^4 boxes; pass @ 10^6

  for(unsigned idxLat=0; idxLat<NUM_BOXES_LAT; ++idxLat)
  {
    float lat = idxLat*DELTA_LAT_DEG + MIN_LAT_DEG;
    for(unsigned idxLon=0; idxLon<NUM_BOXES_LON; ++idxLon)
    {
      float lon = idxLon*DELTA_LON_DEG + MIN_LON_DEG;
      unsigned boxID = idxLat*idxLon;
      // Directly map to cartesian: lon is X; lat is Y
      Point pt0(lon, lat);
      Point pt1(lon+0.001f, lat+0.001f);
      Box box(pt0, pt1);
      locationGeometryTable.insert(std::make_pair(box, boxID));
    }
  }

  return 0;
}
}}}



== build: ==

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


== run: ==

$ ./test[[BR]]
Segmentation fault


== debug: ==


{{{
$ gdb ./test
GNU gdb (Gentoo 7.5 p1) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type ""show copying""
and ""show warranty"" for details.
This GDB was configured as ""x86_64-pc-linux-gnu"".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from test...done.
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run
Starting program: test 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need ""set solib-search-path"" or ""set sysroot""?

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7651127 in __memmove_ssse3_back () from /lib64/libc.so.6
(gdb) backtrace
#0  0x00007ffff7651127 in __memmove_ssse3_back () from /lib64/libc.so.6
#1  0x00000000004165fa in boost::geometry::index::detail::varray_detail::copy_dispatch<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (first=0x7fffffffc188, last=0x7fffffffc1b8, 
    dst=0x406a6a <boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor<boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::---Type <return> to continue, or q <return> to quit---
index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+62>)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray_detail.hpp:201
#2  0x0000000000413ee6 in boost::geometry::index::detail::varray_detail::copy<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (
    first=0x7fffffffc188, last=0x7fffffffc1b8, 
    dst=0x406a6a <boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost---Type <return> to continue, or q <return> to quit---
::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor<boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+62>)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray_detail.hpp:224
#3  0x0000000000411a03 in boost::geometry::index::detail::varray<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_interna---Type <return> to continue, or q <return> to quit---
l_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, 17ul>::assign_dispatch<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (
    this=0x406a62 <boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor<boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allo---Type <return> to continue, or q <return> to quit---
cator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+54>, first=0x7fffffffc188, last=0x7fffffffc1b8)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray.hpp:1774
#4  0x00000000004100b4 in boost::geometry::index::detail::varray<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, 17ul>::assign<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (
    this=0x406a62 <boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boos---Type <return> to continue, or q <return> to quit---
t::detail::variant::void_>::apply_visitor<boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+54>, first=0x7fffffffc188, last=0x7fffffffc1b8)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray.hpp:950
#5  0x000000000040e698 in boost::geometry::index::detail::rtree::redistribute_elements<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::rstar_tag>::apply<boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag> > (n=..., 
    second_node=..., box1=..., box2=..., parameters=..., translator=..., allocators=...)
---Type <return> to continue, or q <return> to quit---
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/rtree/rstar/redistribute_elements.hpp:442
#6  0x0000000000000003 in ?? ()
#7  0x00007fffffffca00 in ?? ()
#8  0x000000000040b798 in boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >::operator() (
    this=<error reading variable: Cannot access memory at address 0x18>, n=<error reading variable: Cannot access memory at address 0x10>)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/rtree/rstar/insert.hpp:279
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
}}}
",Celair <mathom.house@…>
11420,program_options crash on run() on specific machine only in release mode,program_options,Boost 1.58.0,To Be Determined,Bugs,Vladimir Prus,new,2015-06-25T12:34:53Z,2015-06-25T13:05:09Z,"It's a very strange error that occured. I have deployed the program on a machine where no Visual Studio is available.

Upon start it crashes instantly so I have created a dump with the task manager and analysed it in Visual Studio 2013.

{{{
>	test.exe!boost::program_options::basic_command_line_parser<char>::run() Line 107	C++
}}}

which resolves to
{{{
template<class charT>    
    basic_parsed_options<charT>
    basic_command_line_parser<charT>::run()
    {
        // save the canonical prefixes which were used by this cmdline parser
        //    eventually inside the parsed results
        //    This will be handy to format recognisable options
        //    for diagnostic messages if everything blows up much later on
        parsed_options result(m_desc, detail::cmdline::get_canonical_option_prefix());
        result.options = detail::cmdline::run();

        // Presense of parsed_options -> wparsed_options conversion
        // does the trick.
        return basic_parsed_options<charT>(result);
    }
}}}

in my program the crash occurs in the following line

{{{
po::store(po::command_line_parser(argc, argv).options(description).allow_unregistered().run(), vm);
}}}

The very strange thing is that argc is 0 and argv is 0x0000000000000000

It only happens in release mode and i cannot catch any exception",Stephan Bertl <stephan@…>
11415,crash in processEvent_,polygon,Boost 1.56.0,To Be Determined,Bugs,Andrii Sydorchuk,assigned,2015-06-23T10:39:41Z,2017-08-31T09:58:54Z,"In polygon/details/polygon_arbitrary_formation.hpp, at the end of function processEvent_ (line 1768), I had a case where iter is dereferenced illegally. 

Changing line 1741 from:

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

to

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

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



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

        iterator iter = lookUp_(currentY);

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

          elementIters.push_back(iter);

          ...

          ++iter;

        }

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

In the seen case, scanData_ contained 3 elements, and elementIters had 2.",mhilferink@…
11414,minor problem in libs/pool/example/sys_allocator.hpp,pool,Boost 1.57.0,To Be Determined,Bugs,Chris Newbold,new,2015-06-23T00:16:41Z,2015-07-05T22:46:41Z,"In sys_allocator.hpp the struct new_delete_allocator has a minor issue.

The code is:

  static pointer allocate(const size_type n, const void* = 0)
  { return (pointer) new char[n * sizeof(T)]; }
  static void deallocate(const pointer p, const size_type)
  { delete [] p; }

Note that the deallocate member function calls array delete, but the 
allocate function does not call array new.  According to the standard
this is invalid.

The HP NonStop runtime will generate an assert failure on the call
to the delete.

",Ed Vogel <edward.vogel@…>
11413,Untrusted secure connection to *ttps://svn.boost.org,trac / subversion,Boost Development Trunk,To Be Determined,Bugs,Douglas Gregor,new,2015-06-22T17:59:44Z,2015-06-22T17:59:44Z,I get a untrusted connection warning from Firefox 38.0.5 when trying to connect to *ttps://svn.boost.org,anonymous
11411,Deprecated std::... in get_pointer.hpp,function,Boost 1.57.0,To Be Determined,Bugs,Douglas Gregor,new,2015-06-21T17:13:51Z,2015-08-12T08:02:16Z,"With g++-mp-5 (MacPorts gcc5 5.1.0_1) 5.1.0:

In file included from .../include/boost/bind/mem_fn.hpp:25:0,
                 from .../include/boost/mem_fn.hpp:22,
                 from .../include/boost/function/detail/prologue.hpp:18,
                 from .../include/boost/function/function_template.hpp:13,
                 from .../include/boost/function/detail/maybe_include.hpp:18,
                 from .../include/boost/function/function1.hpp:11,
...

.../include/boost/get_pointer.hpp:27:40: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
 template<class T> T * get_pointer(std::auto_ptr<T> const& p)",anonymous
11407,Boost.Container does not provide hash_value,container,Boost 1.58.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2015-06-19T11:20:55Z,2015-06-19T11:20:55Z,"Boost.Hash provides overloads of hash_value for standard containers, but not for their Boost.Container equivalents.  Conversely, Boost.Container also does not provide hash_value overloads for use with Boost.Hash.  This prevents boost::container::vector from being used as a drop-in replacement for std::vector, since boost::unordered_map<std::vector<int>, int> is valid but boost::unordered_map<boost::container::vector<int>, int> is not.",Rainer Deyke <rainerd@…>
11406,Bug in edge connectivity - directed graphs,graph,Boost 1.58.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-06-18T16:20:50Z,2015-06-23T12:39:36Z,"The Boost edge connectivity algorithm gives a wrong result on a directed path with 3 vertices and 2 edges:
0 --> 1 --> 2.
In particular, the output is 1, while it should be 0 (because the graph is not strongly connected).

This issue is not due to a different definition of directed edge connectivity, because the output becomes (correctly) 0 if I add an edge 1 --> 0, obtaining:
0 <-> 1 --> 2.

A minimal example of this issue is attached.",Michele Borassi <michele.borassi@…>
11404,boost/numeric/ublas/experimental/sparse_view.hpp fails to compile if -DNDEBUG is used,uBLAS,Boost 1.56.0,To Be Determined,Bugs,Gunter,new,2015-06-17T15:27:03Z,2015-06-17T15:27:03Z,"If -DNDEBUG is specified on the command line the header file
boost/numeric/ublas/experimental/sparse_view.hpp will not compile.

This can also be seen by trying to build/run the test
sparse_view_test.tes with ""B2 release""

Here's a quick cut/paste: 

$ cat t.cpp
#include <boost/numeric/ublas/experimental/sparse_view.hpp>



vogeled@nimloth ~
$ g++ -Iboost/boost_1_56_0 -c -DNDEBUG t.cpp
In file included from t.cpp:1:
boost/boost_1_56_0/boost/numeric/ublas/experimental/sparse_view.hpp:29: error: e
xpected template-name before '<' token
boost/boost_1_56_0/boost/numeric/ublas/experimental/sparse_view.hpp:29: error: e
xpected `{' before '<' token
boost/boost_1_56_0/boost/numeric/ublas/experimental/sparse_view.hpp:29: error: e
xpected unqualified-id before '<' token
boost/boost_1_56_0/boost/numeric/ublas/experimental/sparse_view.hpp:29: error: e
xpected `;' before '<' token
",Ed Vogel <edward.vogel@…>
11403,exception_ptr.hpp causes crash when .NET tries to unload a DLL that uses boost,exception,Boost 1.56.0,To Be Determined,Bugs,Emil Dotchevski,new,2015-06-15T08:19:24Z,2015-12-08T09:54:52Z,"Hello,
I posted this on the gmane board and Emil Dotchevski said I should open a ticket for this.

We are working with Visual Studio 2013 and have a plain c++ lib that uses boost. To test it, we wrote a (non clr) console program and a WPF GUI for further use.
This WPF GUI contains a clr dll as a wrapper between the .NET world and the plain c++ libs.
At startup, both console and WPF call some function pointers in _initterm in crt0dat.c, especially these two:
[[BR]]
dynamic initializer for 'boost::exception_detail::exception_ptr_static_exception_object<boost::exception_detail::bad_alloc_>::e''(void)
[[BR]]
dynamic initializer for 'boost::exception_detail::exception_ptr_static_exception_object<boost::exception_detail::bad_exception_>::e''(void)

The console terminates cleanly. But the GUI causes an exception in crtdll.c, _CRT_INIT, line 414:

/* call the function, which can eventually change __onexitbegin and __onexitend */
[[BR]]
(*function_to_call)();

The debugger says the value of *function_to_call is
[[BR]]
*function_to_call _t2m@???__Fep@?1???$get_static_exception_object@Ubad_exception_@exception_detail@boost@@@exception_detail@boost@@YA?AVexception_ptr@1@XZ@YAXXZ@?A0xd1be0c67@@YAXXZ

and causes an unhandled exception at 0x74c7c42d (KernelBase.dll), The String binding is invalid.

However, if I change (remove the static keyword) line 130 in exception_ptr.hpp from
[[BR]]
static exception_ptr ep(shared_ptr<exception_detail::clone_base const>(new exception_detail::clone_impl<Exception>(c)));

to

exception_ptr ep(shared_ptr<exception_detail::clone_base const>(new exception_detail::clone_impl<Exception>(c)));

the GUI exits cleanly.

Best regards,[[BR]]
Markus Pieper",onkelhotte@…
11399,Boost geometry models don't support stateful allocator.,geometry,Boost 1.57.0,To Be Determined,Feature Requests,Barend Gehrels,new,2015-06-12T20:08:47Z,2015-07-15T15:19:09Z,"The following model class declarations don't contain constructors that take a copy of the allocator types:
linestring
multi_linestring
polygon
multi_polygon

This makes it impossible to use stateful allocators with geometry models.",bmccart@…
11397,Can't compile RawConverter from mpq_rational to double,geometry,Boost 1.58.0,To Be Determined,Bugs,Barend Gehrels,new,2015-06-12T12:32:31Z,2015-06-12T16:13:17Z,"According to documentation I have to create low_level_convert function but compiler
(gcc version 4.6.2 (SUSE Linux)) failed to compile it:

error: invalid static_cast from type

I attached test file.",andyplekhanov@…
11396,"On remove_if documentation page, prototypes are remove, not remove_if",range,Boost 1.57.0,To Be Determined,Bugs,Neil Groves,new,2015-06-12T11:49:58Z,2015-06-12T11:49:58Z,"On the documentation page for algorithms/remove_if, the prototypes at the top of the page call it remove, not remove_if.",Jim Bell <jim@…>
11393,"boost::program_options accepting switch-options that match the beginning of defined option, but is not full option typed out.",program_options,Boost 1.58.0,To Be Determined,Bugs,Vladimir Prus,new,2015-06-11T08:48:30Z,2015-06-11T08:48:30Z,"With:

    namespace po = boost::program_options;
    po::options_description desc (""options"");
    desc.add_options ()
      ( ""help,h"", ""print this help message"")
      ( ""config,c"", po::value<ustring>(), ""config file, default: $XDG_CONFIG_HOME/astroid/config"")
      ( ""new-config,n"", ""make new default config, then exit"")
      ( ""mailto,m"", po::value<ustring>(), ""compose mail with mailto url or address"")
      ( ""no-auto-poll"", ""do not poll automatically"");

    po::variables_map vm;

    bool show_help = false;

    try {
      po::store ( po::parse_command_line (argc, argv, desc), vm );
    } catch (po::unknown_option &ex) {
      cout << ""unknown option"" << endl;
      cout << ex.what() << endl;
      show_help = true;

    }

running:

./program --asdf 

fails, but running:

./program --hel

is parsed as --help.",eg@…
11390,Wrong type in dynamic_bitset::reference constructor,dynamic_bitset,Boost 1.58.0,To Be Determined,Bugs,jsiek,new,2015-06-10T16:42:24Z,2017-11-02T20:49:34Z,"When compiling with visual studio 2013, the following warning is issued (and since we treat these as errors, fails the compilation):

boost/dynamic_bitset/dynamic_bitset.hpp(298): warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', possible loss of data

The culprit is the reference constructor:

reference(block_type & b, block_type pos)

which should be:

reference(block_type & b, block_width_type pos)

used in the non-const accessor:

reference operator[](size_type pos) {
        return reference(m_bits[block_index(pos)], bit_index(pos));
    }

bit_index() is defined as returning block_width_type, not block_type (which may be narrower).

The const accessor works as expected and is a possible workaround when read-only access is required from a non-const bitset.",stefan.atev@…
11389,Bug: Unit precision is restricted to double when using conversion constants,units,Boost 1.58.0,To Be Determined,Bugs,Matthias Schabel,new,2015-06-10T15:40:49Z,2015-06-10T15:47:21Z,"From BOOST_UNITS_DEFINE_BASE_UNIT_WITH_CONVERSIONS in boost/units/conversions.hpp:

{{{
BOOST_UNITS_DEFINE_CONVERSION_FACTOR(namespace_::name_ ## _base_unit, unit, double, factor); \
}}}

Note the type of the conversion factor value is forced unconditionally to be double.

It would be nice if the precision of this constant could be either made more flexible, or made as precise as possible with rounding to a lower-precision constant when lower-precision types are used.  For example, using long double would allow higher-precision constants and conversions, but this isn't possible at present since even if a quantity<T, long double> is used, the conversions are still being restricted to double precision.


Kind regards,
Roger",Roger Leigh <rleigh@…>
11382,Files with missing or questionable licenses,python USE GITHUB,Boost 1.57.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2015-06-09T03:52:57Z,2015-07-06T08:42:26Z,"Initial report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788126

Several files do not seem to be covered by any
license described in the copyright file.
Most serious:
interprocess/sync/xsi/advanced_xsi_semaphore.hpp : No license mentioned at all
python/detail/python22_fixed.h : Explicitly ""All rights reserved""

Probably fine but questionable and IMHO should be documented at least
as they will fail in automated checks:
algorithm/cxx14/mismatch.hpp : Refers to non-existing LICENSE10.txt, probably typo
And some non-standard license headers in:
rational.hpp
math/common_factor_rt.hpp
test/utils/runtime/cla/detail/argument_value_usage.hpp
shared_container_iterator.hpp
program_options/detail/utf8_codecvt_facet.hpp",smr@…
11375,Support Request -- boost 1.58 bootstrap.sh failed on SunOS 5.10,build,Boost 1.58.0,To Be Determined,Bugs,Vladimir Prus,new,2015-06-05T08:33:47Z,2016-09-02T18:20:25Z,"I cannot even generate b2 while compiling boost 1.58 since bootstrap.sh failed at very early stage. But it is ok while compiling boost 1.57

error message:
-n Building Boost.Build engine with toolset gcc...

Failed to build Boost.Build build engine
Consult 'bootstrap.log' for more details

bootstrap.log:
./build.sh: syntax error at line 147: `BOOST_JAM_CC=$' unexpected

",chenbo369@…
11374,find_flow_cost() not working with bundled or user-defined properties,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-06-04T09:12:23Z,2016-05-03T08:45:23Z,"I tripped over that bug when trying to use `find_flow_cost()`. Using the source below, it won't compile. The error log is here : http://pastebin.com/Gd3JdbuK

I think this is a problem in `boost/graph/find_flow_cost.hpp:18`. For example, line 19:
{{{
typedef typename property_traits<typename property_map<Graph, edge_weight_t>::const_type>::value_type Cost;
}}}
should rather be
{{{
typedef typename property_traits<Weight>::value_type Cost;
}}}
The same problem occurs line on 17 and 19.

The minimum working example:
{{{
//=======================================================================
// Copyright 2001 Jeremy G. Siek, Andrew Lumsdaine, Lie-Quan Lee,
//
// Distributed under the Boost Software License, Version 1.0. (See
// accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt)
//=======================================================================
#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);

	long flow, flow_cost;
	// XXX The ""non-named parameter version"" (works fine)
	flow = edmonds_karp_max_flow(g, s, t,capacity,residual_capacity,rev,col,pred);
	// XXX The ""named parameter version"" (producing errors)
//	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));


	find_flow_cost(g,capacity,residual_capacity,cost);
	//flow_cost = find_flow_cost(g,capacity,residual_capacity,cost);


	std::cout << ""c  The total flow:"" << std::endl;
	std::cout << ""s "" << flow << std::endl << std::endl;

	std::cout << ""c flow values:"" << std::endl;
	graph_traits < Graph >::vertex_iterator u_iter, u_end;
	graph_traits < Graph >::out_edge_iterator ei, e_end;
	for (boost::tie(u_iter, u_end) = vertices(g); u_iter != u_end; ++u_iter)
		for (boost::tie(ei, e_end) = out_edges(*u_iter, g); ei != e_end; ++ei)
			if (capacity[*ei] > 0)
				std::cout << ""a "" << *u_iter << "" "" << target(*ei, g) << "" ""
				<< (capacity[*ei] - residual_capacity[*ei]) << std::endl;

	return EXIT_SUCCESS;
}
}}}

",Maël Valais <mael.valais@…>
11373,"Ticket 10762 (boost 1..57) is nearly a year old, but error ist still in boost (now 1.58)",numeric,Boost 1.58.0,To Be Determined,Bugs,Douglas Gregor,new,2015-06-02T20:43:48Z,2015-09-03T20:06:19Z,"include/boost/numeric/ublas/matrix.hpp
line 1387, wrong parameter type (matrix m)
should be (fixed_matrix m)

solution see ticket 10762

showstopper, because certain matrix operations do not even compile!

please do not deliver untested software",anonymous
11371,"Logging: Advanced event log backend, Blank replaceable parameters",log,Boost 1.57.0,To Be Determined,Bugs,Andrey Semashev,new,2015-06-02T20:41:09Z,2015-06-02T21:05:21Z,"Overview: I'm trying to use Boost Logging for sending events to the Windows event log. In the event log the replaceable parameters are showing up as empty strings, E.g., for a message of ""Operation finished successfully in %1 seconds."" the event log will simply show ""Operation finished successfully in seconds."" and the value for %1 is lost (instead of replaced into the string).

Code: I reproduced this problem on the example provided in the boost distribution itself (libs\log\example\event_log), after commenting out the custom event mapping section, to work around the issue described in ticket 9292, https://svn.boost.org/trac/boost/ticket/9292

=======Event mapping section to be commented out======
    sinks::event_log::custom_event_type_mapping< severity_level > type_mapping(""Severity"");
    type_mapping[normal] = sinks::event_log::make_event_type(MY_SEVERITY_INFO);
    type_mapping[warning] = sinks::event_log::make_event_type(MY_SEVERITY_WARNING);
    type_mapping[error] = sinks::event_log::make_event_type(MY_SEVERITY_ERROR);
    backend->set_event_type_mapper(type_mapping);
=======End of event mapping section to be commented out======


Environment: Windows Server 2008R2 (6.1.7601) with compilers from the Windows SDK 7.0

cl.exe version 15.00.30729.01 (VC9), target processor x64. 
Message compiler mc.exe version 1.12.7600.
",Eusebio Rufian-Zilbermann <eusebio@…>
11369,Boost.Python: return_internal_reference<> bug,python USE GITHUB,Boost 1.58.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2015-06-02T06:13:07Z,2015-06-03T08:41:48Z,"I am having an issue with Boost.Python with a very simple use case.

I am returning a reference to an object, and it seems that my python object looses its C++ object's reference at a stage for some reason.

Please see my example below reproducing this issue.

C++ Code:

{{{
#include <vector>
#include <string>

#include <cmath>
#include <boost/python.hpp>
#include <boost/python/suite/indexing/vector_indexing_suite.hpp>

class Car {
public:
    Car(std::string name) : m_name(name) {}

    bool operator==(const Car &other) const {
        return m_name == other.m_name;
    }

    std::string GetName() { return m_name; }
private:
    std::string m_name;
};

class Factory {
public:
    Factory(std::string name) : m_name(name) {}

    bool operator==(const Factory &other) const {
        return m_name == other.m_name
            && m_car_list == other.m_car_list;
    }

    Car& create_car(std::string name)
    {
        m_car_list.emplace_back(Car(name));
        return m_car_list.back();
    }

    std::string GetName() { return m_name; }
    std::vector<Car>& GetCarList() { return m_car_list;}
private:
    std::string m_name;
    std::vector<Car> m_car_list;
};

class Manufacturer {
public:
    Manufacturer(std::string name) : m_name(name) {}

    bool operator==(const Manufacturer &other) const {
        return m_name == other.m_name
            && m_factory_list == other.m_factory_list;
    }

    Factory& create_factory(std::string name)
    {
        m_factory_list.emplace_back(Factory(name));
        return m_factory_list.back();
    }

    std::string GetName() { return m_name; }
    std::vector<Factory>& GetFactoryList() { return m_factory_list;}
private:
    std::string m_name;
    std::vector<Factory> m_factory_list;
};

BOOST_PYTHON_MODULE(carManufacturer)
{
    using namespace boost::python;
    class_<Manufacturer>(""Manufacturer"", init<std::string>())
        .add_property(""factory_list"", make_function(&Manufacturer::GetFactoryList, return_internal_reference<>()))
        .add_property(""name"", &Manufacturer::GetName)
        .def(""create_factory"", &Manufacturer::create_factory, return_internal_reference<>());
    class_<Factory>(""Factory"", init<std::string>())
        .add_property(""car_list"", make_function(&Factory::GetCarList, return_internal_reference<>()))
        .add_property(""name"", &Factory::GetName)
        .def(""create_car"", &Factory::create_car, return_internal_reference<>());
    class_<Car>(""Car"", init<std::string>())
        .add_property(""name"", &Car::GetName);

    class_<std::vector<Factory> >(""FactoryList"")
        .def(vector_indexing_suite<std::vector<Factory> >());
    class_<std::vector<Car> >(""Car"")
        .def(vector_indexing_suite<std::vector<Car> >());
}
}}}

Python Code:

{{{
from carManufacturer import *

vw = Manufacturer(""VW"")
vw_bra_factory = vw.create_factory(""Brazil Factory"")
beetle = vw_bra_factory.create_car(""Beetle69"")

if vw_bra_factory is vw.factory_list[0]:
    print(""equal."")
else:
    print(""NOT EQUAL"")
print(""## I expected them to be the same reference..?"")


print(""vw_bra_factory Car List size : "" + str(len(vw_bra_factory.car_list)))
print(""Actual Car List size         : "" + str(len(vw.factory_list[0].car_list)))
print(""## This still works. Maybe the python objects differ, but refer to the same C++ object. I can live with that."")

vw_sa_factory = vw.create_factory(""South Africa Factory"")
print(""vw_bra_factory Car List size : "" + str(len(vw_bra_factory.car_list)))
print(""Actual Car List size         : "" + str(len(vw.factory_list[0].car_list)))
print(""## .. what? why? brazil py object has no cars now? I don't get it. I can't have any of that."")

print(""## What will happen if I create another car in the brazil factory?"")
combi = vw_bra_factory.create_car(""Hippie van"")
print(""vw_bra_factory Car List size : "" + str(len(vw_bra_factory.car_list)))
print(""Actual Car List size         : "" + str(len(vw.factory_list[0].car_list)))

print(""## And another."")
citi_golf = vw_bra_factory.create_car(""Citi golf"")
print(""vw_bra_factory Car List size : "" + str(len(vw_bra_factory.car_list)))
print(""Actual Car List size         : "" + str(len(vw.factory_list[0].car_list)))
print(""## 'vw_bra_factory' must have lost its C++ reference it had to 'vw.factory_list[0]' when I created a new factory. Why?"")
}}}

Output:

{{{
NOT EQUAL
## I expected them to be the same reference..?
vw_bra_factory Car List size : 1
Actual Car List size         : 1
## This still works. Maybe the python objects differ, but refer to the same C++ object. I can live with that.
vw_bra_factory Car List size : 0
Actual Car List size         : 1
## .. what? why? brazil py object has no cars now? I don't get it. I can't have any of that.
## What will happen if I create another car in the brazil factory?
vw_bra_factory Car List size : 1
Actual Car List size         : 1
## And another.
vw_bra_factory Car List size : 2
Actual Car List size         : 1
## 'vw_bra_factory' must have lost its C++ reference it had to 'vw.factory_list[0]' when I created a new factory. Why?
}}}

This is just an example made to reproduce my real work's problem in a presentable way.

Is there any workaround to this? I could not find any in bug reports, the mailing list or anywhere else.

Regards,
Christoff",Christoff Heinrich Kok <christoff.kok@…>
11355,Sloan ordering does not work on disconnected graphs,graph,Boost 1.58.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-05-27T16:57:08Z,2015-05-27T16:57:08Z,"The Sloan ordering algorithm in graph/sloan_ordering.hpp does not work for disconnected graphs.

This can be easily confirmed by running an example of a graph with two disconnected vertices.

The attached file simply creates a graph with two vertices without any edges.
Running the attached file yields:
{{{
i: 0
i: 0
}}}

The result should be:
{{{
i: 0
i: 1
}}}

Or the result should be:
{{{
i: 1
i: 0
}}}

The problem also holds for larger disconnected graphs.",Jeroen Meijer <jjgmeijer@…>
11348,Problem constructing boost::iterator_range objects from arrays,range,Boost 1.58.0,To Be Determined,Bugs,Neil Groves,new,2015-05-26T20:02:12Z,2016-03-01T12:55:58Z,"I'm migrating to boost 1.58.0 from an older version and have found that I'm no longer able to construct a boost::iterator_range directly from an array.  The following code snippet demonstrates the problem:

{{{
#!cpp
#include <boost/range/iterator_range.hpp>
int main()
{
    int arr[] = { 1, 2 };
    boost::iterator_range<int *> x = arr;
}
}}}

Using gcc 4.9.2 on Linux with Boost 1.58.0, the following error is produced:

{{{
foo.cpp: In function 'int main()':
foo.cpp:5:38: error: conversion from 'int [2]' to non-scalar type 'boost::iterator_range<int*>' requested
     boost::iterator_range<int *> x = arr;
                                      ^
}}}

The code compiles fine with older versions of Boost (e.g. 1.53.0).  It appears that the problem was introduced with this change: https://github.com/boostorg/range/commit/7d13f63d5d1324abf519b67f59e1814b2cbe5d55 although I have not manually verified this.

From my brief reading of the change introduced here, it seems to deem a type that is convertible to the base iterator type to not be a compatible range.  In the example above, int[2] is convertible to int *, hence the constructor is excluded from consideration.

It appears I can work around the problem by calling boost::make_iterator_range, but I would have to change quite a lot of code to use this workaround.  Hence I wanted to verify that the previous behaviour was expected, and find out if a fix is possible.

I'm happy to help work on a patch, for example perhaps the is_compatible_range check can be tightened to explicitly check for the array case.

Thanks,

Graham
",graham@…
11345,Compilation with fails when BOOST_THREAD_VERSION=4 defined,log,Boost Release Branch,To Be Determined,Bugs,Andrey Semashev,new,2015-05-26T13:11:52Z,2015-07-21T16:33:23Z,"Compilation fails when BOOST_THREAD_VERSION=4 is defined.
timed_wait is not a member of boost::condition_variable",anonymous
11341,dimacs_basic_reader reads corrupted data,graph,Boost 1.58.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-05-25T23:18:06Z,2015-05-25T23:25:25Z,"As analyzed for http://stackoverflow.com/questions/30415388/how-to-read-dimacs-vertex-coloring-graphs-in-c/30446685#30446685

The parsing of edge lines is fundamentally broken.

A simple file as

{{{
p edge 2 1
e 1 2
}}}

will fail to read correct data (without raising an error). Instead, indeterminate values are read for the edge, and the results are undefined (at the very least depend on the graph model).

Related, I don't think the expression {{{(char*) buf.c_str()}}} is legal. I'd suggest at least replacing that by `&buf[0]`.

Further I'd really suggest replacing the parser. For the subset that the question was about, I've suggested two implementations in the linked answer on SO:

{{{
#include <string>
#include <istream>
#include <sstream>

template <typename Graph>
bool read_coloring_problem(std::istream& dimacs, Graph& g) {
    size_t vertices = 0, edges = 0;

    std::string line;
    while (getline(dimacs, line))
    {
        std::istringstream iss(line);
        char ch;
        if (iss >> ch)
        {
            size_t from, to;
            std::string format;

            switch(ch) {
                case 'c': break;
                case 'p': 
                    if (vertices||edges) return false;
                    if (iss >> format >> vertices >> edges) {
                        if (""edge"" != format) return false;
                    }
                    break;
                case 'e': 
                    if (edges-- && (iss >> from >> to) && (add_edge(from-1, to-1, g).second))
                        break;
                default: 
                    return false;
            }
        }
    }

    return !(edges || !dimacs.eof());
}
}}}

Or with Boost Spirit:


{{{
#include <boost/spirit/include/qi.hpp>
#include <boost/spirit/include/phoenix.hpp>
#include <boost/spirit/include/qi_match.hpp>

template <typename Graph>
bool read_coloring_problem(std::istream& dimacs, Graph& g) {
    auto add_edge_ = [&g](size_t from, size_t to) { add_edge(from, to, g); };
    size_t vertices = 0, edges = 0;

    using namespace boost::spirit::qi;
    namespace px = boost::phoenix;
    uint_parser<size_t> num_;

    auto eoil      = eol | eoi;
    auto comment   = boost::proto::deep_copy(lexeme[""c "" >> *(char_ - eol) >> eoil] | eol);
    auto vertices_ = px::ref(vertices);
    auto edges_    = px::ref(edges);

    dimacs >> std::noskipws >> phrase_match(
            *comment >>
            (""p"" >> lit(""edge"") >> num_ [vertices_ = _1] >> num_ [edges_ = _1] >> eoil) >>
            repeat(edges_) [ 
            *comment >> (""e"" >> num_ >> num_ >> eoil) [ px::bind(add_edge_, _1-1, _2-1) ]
            ] 
            >> *comment >> eoi
            , blank);

    return dimacs;
}
}}}

I realize there are missing features (`weight`)",anonymous
11337,implicit_cast in python/include/boost/python/opaque_pointer_converter.hpp should be boost:: qualified,python USE GITHUB,Boost Development Trunk,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2015-05-23T22:44:41Z,2015-05-23T22:47:48Z,"The following test case fails to compile:


{{{
template <typename T>
inline T implicit_cast (void *) {
  // In reality there is an actual ::implicit_cast implementation in a header file
  return 0;  
}

#include <boost/python.hpp>

int main() {
  return 0;
}

}}}

The error is:


{{{
In file included from ./python/include/boost/python.hpp:49:0,
                 from /tmp/implicit_cast.cc:6:
./python/include/boost/python/opaque_pointer_converter.hpp: In static member function ‘static void* boost::python::opaque<Pointee>::extract(PyObject*)’:
./python/include/boost/python/opaque_pointer_converter.hpp:66:68: error: call of overloaded ‘implicit_cast(PyObject*&)’ is ambiguous
             ? static_cast<python_instance*>(implicit_cast<void*>(op))->x
                                                                    ^
./python/include/boost/python/opaque_pointer_converter.hpp:66:68: note: candidates are:
In file included from ./python/include/boost/python/converter/builtin_converters.hpp:11:0,
                 from ./python/include/boost/python/converter/arg_to_python.hpp:17,
                 from ./python/include/boost/python/call.hpp:15,
                 from ./python/include/boost/python/object_core.hpp:14,
                 from ./python/include/boost/python/args.hpp:25,
                 from ./python/include/boost/python.hpp:11,
                 from /tmp/implicit_cast.cc:6:
./conversion/include/boost/implicit_cast.hpp:25:10: note: T boost::implicit_cast(typename boost::detail::icast_identity<T>::type) [with T = void*; typename boost::detail::icast_identity<T>::type = void*]
 inline T implicit_cast (typename boost::detail::icast_identity<T>::type x) {
          ^
/tmp/implicit_cast.cc:2:10: note: T implicit_cast(void*) [with T = void*]
 inline T implicit_cast (void *) {
          ^

}}}

Proposed fix:


{{{
diff --git a/include/boost/python/opaque_pointer_converter.hpp b/include/boost/python/opaque_pointer_converter.hpp
index 10eb423..70ab1fe 100644
--- a/include/boost/python/opaque_pointer_converter.hpp
+++ b/include/boost/python/opaque_pointer_converter.hpp
@@ -63,7 +63,7 @@ private:
     static void* extract(PyObject* op)
     {
         return PyObject_TypeCheck(op, &type_object)
-            ? static_cast<python_instance*>(implicit_cast<void*>(op))->x
+            ? static_cast<python_instance*>(boost::implicit_cast<void*>(op))->x
             : 0
             ;
     }
}}}
",Paul Pluzhnikov <ppluzhnikov@…>
11336,units: base_unit_info name and symbol unavailable for absolute units,units,Boost 1.55.0,To Be Determined,Bugs,Matthias Schabel,new,2015-05-22T20:53:51Z,2015-05-26T21:37:59Z,"absolute<> works for making temperatures absolute.  However, it does not define a specialisation of the base_unit_info, so name_string and symbol_string are unavailable and some methods fails as a result.

Please consider making absolute<> provide a base_unit_info specialisation which delegates to the wrapped unit type's base_unit_info, but adds an ""absolute "" prefix to both and can replace the ostream operator which works partially for the symbol case, but not the unit name which is completely absent.  This will make absolute<> behave the same as a normal unwrapped unit.",Roger Leigh <rleigh@…>
11335,units: [patch] Improve precision of mmHg conversion to Pascal,units,Boost 1.55.0,To Be Determined,Patches,Matthias Schabel,new,2015-05-22T20:10:49Z,2015-05-22T20:10:49Z,"See attached patch.

The conversion factor used by the existing code only used three decimal places.  However, the standardised conversion factor is 9 decimal places, and is also used in GNU units.  Changing to use the full 133.322387415 significantly improves accuracy.

I can't put a link in the report since it makes the ticket get rejected as spam, but see the first paragraph of the ""Millimeter of mercury"" wikepedia page, and GNU units for reference.

Defect is in the latest boost back to at least 1.55.

Please consider applying the attached patch.


Thanks,
Roger",Roger Leigh <rleigh@…>
11334,Add ability to get const filter reference from a const symmetric_filter,iostreams,Boost 1.58.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2015-05-22T19:31:39Z,2015-05-22T19:31:39Z,"If you have a const symmetric_filter, you cannot call the filter() function to get a const reference to the underlying implementation.  This would be a nice thing to have.",nathan@…
11326,Suggested patch for boost 1.58.0 and Python 3 < 3.4 breaks build for 3.4,python USE GITHUB,Boost 1.58.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2015-05-20T16:00:48Z,2015-05-20T16:00:48Z,"Both the suggested patch:
http://www.boost.org/patches/1_58_0/0001-Fix-exec_file-for-Python-3-3.4.patch

and the fix in git:
https://github.com/boostorg/python/commit/3e405b6fd5db5615bbef241763de070118222ca7

break the build for Python 3.4.

The reason is that the check for Python >= 3.4 is wrong.

It is:
{{{
#if PY_VERSION_HEX >= 0x03400000
}}}
but it should be:
{{{
#if PY_VERSION_HEX >= 0x03040000
}}}

",Mika Fischer <mika.fischer@…>
11321,Compiling for MSVC (Windows) and Clang,Building Boost,Boost 1.58.0,To Be Determined,Support Requests,,new,2015-05-19T13:52:49Z,2015-07-05T22:47:49Z,"Can you please help me with compiling for msvc (2013) using clang (3.6) on Windows 7.0

I am using the following command, but unsuccessful (perhaps it's the '$'):

b2
toolset=clang
link=static
runtime-link=static
--build-type=complete
--abbreviate-paths
architecture=x86
address-model=32
cxxflags=""-std=c++11 -nostdinc++ -isystem $/c:/PROGRA~2/MICROS~3.0/VC/include -stdlib=libc++""
linkflags=""-stdlib=c++ -L$/c:/PROGRA~2/MICROS~3.0/VC/lib""
--prefix=$/c:/clang
-j8
define=BOOST_SYSTEM_NO_DEPRECATED
stage
release
install",anonymous
11316,Getting Started on Windows Documentation - Does bootstrap.bat Need the Toolchain as an Argument?,Getting Started Guide,Boost Development Trunk,To Be Determined,Tasks,Dave Abrahams,new,2015-05-17T21:18:26Z,2015-05-17T21:18:26Z,"Hello,

I am trying to build boost on Windows using mingw32 (as setup by Qt5). I was following the instructions as per 
http://www.boost.org/doc/libs/1_58_0/more/getting_started/windows.html#id37 .
I extracted the sources, went into /tools/build and ran 

  {{{
  bootstrap.bat
  Bootstrapping the build engine
  'cl' is not recognized as an internal or external command,
  operable program or batch file.

  Failed to bootstrap the build engine
  Please consult bootstrap.log for furter diagnostics.
}}}
Further research online suggested I should have used 
{{{
bootstrap.bat mingw
}}}

after which the bootstrap completes successfully. If this is the case, please could the documentation be changed to state this?

Thanks
",stellarpower@…
11315,Compilation warnings created by boost::polygon::operators,polygon,Boost 1.58.0,To Be Determined,Bugs,Andrii Sydorchuk,assigned,2015-05-17T18:36:41Z,2015-07-01T17:33:16Z,"When I compile bp_warn.cc (attached) with Clang and enable ""-Wall -Werror"", the compilation fails with ""template argument uses unnamed type"". See attached ""warnings.txt"" for complete output.

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

I am not sure this is really a bug in boost::polygon, and I am not sure how to fix it if it is, but I thought I would report it anyway.",lopresti@…
11304,bind added overload generate ambiguity,bind,Boost 1.58.0,To Be Determined,Bugs,Peter Dimov,new,2015-05-14T17:03:23Z,2015-05-14T17:10:20Z,"When providing an explicit return type when the function result_type may or may not be deduced. If the result type is the same than the one requested by the generated function, the two template specialization become valid and then create ambiguity.

----

template<class Rt2, class R, class T,
    class B1,
    class A1, class A2>
    _bi::bind_t<Rt2, _mfi::BOOST_BIND_MF_NAME(mf1)<R, T, B1>, typename _bi::list_av_2<A1, A2>::type>
    BOOST_BIND(R (BOOST_BIND_MF_CC T::*f) (B1), A1 a1, A2 a2)
	
template<class R, class T,
    class B1,
    class A1, class A2>
    _bi::bind_t<R, _mfi::BOOST_BIND_MF_NAME(mf1)<R, T, B1>, typename _bi::list_av_2<A1, A2>::type>
    BOOST_BIND(R (BOOST_BIND_MF_CC T::*f) (B1), A1 a1, A2 a2)


----

// Here is my use case that fail on my end

class any_function
{
public:

template <typename T0, typename T1, int i>
typename boost::enable_if<
	boost::is_member_function_pointer<T0>,
	CAnyFunction&>::type
set(T0 t0, T1 t1, boost::arg<i> i1)
{
	typedef function_traits<T0> traits;
	typedef typename traits::result_type result_type;
	Functor = 
		boost::function<result_type (traits::arg1_type)> (boost::bind<result_type>(t0, t1, i1));
	return *this;
};

private:
	boost::any Functor;
}


----

",gerald.langlois@…
11300,I think the invariant in ResourceExtensionFunction for r_c_shortest_paths is not correct,graph,Boost 1.58.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-05-13T19:17:24Z,2016-01-14T00:04:12Z,"The documentation for 1.58.0 (http://www.boost.org/doc/libs/1_58_0/libs/graph/doc/r_c_shortest_paths.html) correctly states that: 

> The implementation is a label-setting algorithm. This means that there must be one or more resources whose cumulated consumption(s) after extension is/are always at least as high as before. This is similar to the Dijkstra algorithm for the SPP without resource constraints where the distance measure must be non-negative. It is sufficient if there is one resource with a non-negative resource consumption along all arcs (for example, non-negative arc lengths or non-negative arc traversal times). 


But, later on, it says: 

> If ref models the ResourceExtensionFunction concept, and if the type Resource_Container models the ResourceContainer concept, after the call 
>
> ref( const Graph& g, 
>      Resource_Container& new_cont, 
>      const Resource_Container& old_cont, 
>      graph_traits<Graph>::edge_descriptor ) 
>
> the expression old_cont <= new_cont evaluates to true. 
>
> This is because, as stated above, the implementation is a label-setting algorithm. Therefore, the Less-Than operator for ResourceContainer must compare one or more resource(s) whose resource consumption(s) along any arc is/are non-decreasing in order for the algorithm to work properly. 

Now, saying that ""old_cont <= new_cont"" is much stricter than it should be. The correct requirement (first quote) is that there is **at least one** resource whose consumption monotonically doesn't decrease. What ""old_cont <= new_cont"" requires, is that **all** resources' consumptions are monotonically non-decreasing. These two things are equivalent iff the label only has one resource. 

Also, can someone confirm my first impression (after looking at r_c_shorterst_paths.hpp) that this invariant is mentioned in the documentation, but never checked nor ''assert''-ed in the code?",a.santini@…
11297,adaptors: Documentation for sliced reports the wrong precondition,range,Boost 1.58.0,To Be Determined,Bugs,Neil Groves,new,2015-05-13T10:32:50Z,2015-05-13T10:32:50Z,"Currently, the precondition for the sliced adaptor is

Precondition: 0 <= n && n <= m && m < distance(rng).

It should instead be

Precondition: 0 <= n && n <= m && m <= distance(rng).

Notice the <= instead of <.

The page in question is [http://www.boost.org/doc/libs/1_58_0/libs/range/doc/html/range/reference/adaptors/reference/sliced.html].

Nitpicky: Maybe a better upper bound would be m <= size(rng) since boost::size returns a range_size<rng>::type which is the type of n and m (the parameters given to adaptors::sliced). Contrast this to boost::distance which returns a range_difference<rng>::type.",Frederik Aalund <frederikaalund@…>
11295,Matrix Memory problem after using lu_factorize,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2015-05-13T08:17:31Z,2017-06-16T11:49:54Z,"Discovered that after using lu_factorize the values of the matrix have changed!


{{{
#include <iostream>

#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/matrix_proxy.hpp>
#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/io.hpp>
#include <boost/numeric/ublas/lu.hpp>

using namespace std;
using namespace boost::numeric;

int main()
{
  ublas::matrix<double> X(3,3); X.clear();
  X(0,0) = 0.995182407377577; X(0,1) =-0.006473367705848; X(0,2) =-0.002032391957706;
  X(1,0) =-0.006473367705848; X(1,1) = 0.995182407377577; X(1,2) =-0.002032391957706;
  X(2,0) =-0.002032391957706; X(2,1) =-0.002032391957706; X(2,2) = 0.936175146339137;
  cout<<setprecision(16)<<X<<endl;
  cout<<ublas::lu_factorize(X)<<endl;
  cout<<setprecision(16)<<X<<endl;
  cout<<ublas::lu_factorize(X)<<endl;
  cout<<setprecision(16)<<X<<endl;
}
}}}

Output:


{{{
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006473367705848,0.995182407377577,-0.002032391957706),(-0.002032391957706,-0.002032391957706,0.936175146339137))
0
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006504704723334175,0.9951403000320849,-0.002045612067272957),(-0.002042230592742885,-0.002055601674665375,0.9361667907625133))
0
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006536193440632496,0.9950979888485471,-0.002058896174255709),(-0.002052116855767581,-0.002079077442455779,0.9361583394521271))

}}}

Is this fixed in newer versions?

Thanks

Michael Cortis

RA, Durham University",michael.cortis@…
11294,Matrix Memory problem after using lu_factorize,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2015-05-13T08:17:17Z,2015-05-13T08:17:17Z,"Discovered that after using lu_factorize the values of the matrix have changed!


{{{
#include <iostream>

#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/matrix_proxy.hpp>
#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/io.hpp>
#include <boost/numeric/ublas/lu.hpp>

using namespace std;
using namespace boost::numeric;

int main()
{
  ublas::matrix<double> X(3,3); X.clear();
  X(0,0) = 0.995182407377577; X(0,1) =-0.006473367705848; X(0,2) =-0.002032391957706;
  X(1,0) =-0.006473367705848; X(1,1) = 0.995182407377577; X(1,2) =-0.002032391957706;
  X(2,0) =-0.002032391957706; X(2,1) =-0.002032391957706; X(2,2) = 0.936175146339137;
  cout<<setprecision(16)<<X<<endl;
  cout<<ublas::lu_factorize(X)<<endl;
  cout<<setprecision(16)<<X<<endl;
  cout<<ublas::lu_factorize(X)<<endl;
  cout<<setprecision(16)<<X<<endl;
}
}}}

Output:


{{{
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006473367705848,0.995182407377577,-0.002032391957706),(-0.002032391957706,-0.002032391957706,0.936175146339137))
0
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006504704723334175,0.9951403000320849,-0.002045612067272957),(-0.002042230592742885,-0.002055601674665375,0.9361667907625133))
0
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006536193440632496,0.9950979888485471,-0.002058896174255709),(-0.002052116855767581,-0.002079077442455779,0.9361583394521271))

}}}

Is this fixed in newer versions?

Thanks

Michael Cortis

RA, Durham University",michael.cortis@…
11293,Matrix Memory problem after using lu_factorize,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2015-05-13T08:16:49Z,2015-05-13T08:16:49Z,"Discovered that after using lu_factorize the values of the matrix have changed!


{{{
#include <iostream>

#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/matrix_proxy.hpp>
#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/io.hpp>
#include <boost/numeric/ublas/lu.hpp>

using namespace std;
using namespace boost::numeric;

int main()
{
  ublas::matrix<double> X(3,3); X.clear();
  X(0,0) = 0.995182407377577; X(0,1) =-0.006473367705848; X(0,2) =-0.002032391957706;
  X(1,0) =-0.006473367705848; X(1,1) = 0.995182407377577; X(1,2) =-0.002032391957706;
  X(2,0) =-0.002032391957706; X(2,1) =-0.002032391957706; X(2,2) = 0.936175146339137;
  cout<<setprecision(16)<<X<<endl;
  cout<<ublas::lu_factorize(X)<<endl;
  cout<<setprecision(16)<<X<<endl;
  cout<<ublas::lu_factorize(X)<<endl;
  cout<<setprecision(16)<<X<<endl;
}
}}}

Output:


{{{
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006473367705848,0.995182407377577,-0.002032391957706),(-0.002032391957706,-0.002032391957706,0.936175146339137))
0
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006504704723334175,0.9951403000320849,-0.002045612067272957),(-0.002042230592742885,-0.002055601674665375,0.9361667907625133))
0
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006536193440632496,0.9950979888485471,-0.002058896174255709),(-0.002052116855767581,-0.002079077442455779,0.9361583394521271))

}}}

Is this fixed in newer versions?

Thanks

Michael Cortis

RA, Durham University",michael.cortis@…
11292,Matrix Memory problem after using lu_factorize,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2015-05-13T08:16:37Z,2015-05-13T08:16:37Z,"Discovered that after using lu_factorize the values of the matrix have changed!


{{{
#include <iostream>

#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/matrix_proxy.hpp>
#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/io.hpp>
#include <boost/numeric/ublas/lu.hpp>

using namespace std;
using namespace boost::numeric;

int main()
{
  ublas::matrix<double> X(3,3); X.clear();
  X(0,0) = 0.995182407377577; X(0,1) =-0.006473367705848; X(0,2) =-0.002032391957706;
  X(1,0) =-0.006473367705848; X(1,1) = 0.995182407377577; X(1,2) =-0.002032391957706;
  X(2,0) =-0.002032391957706; X(2,1) =-0.002032391957706; X(2,2) = 0.936175146339137;
  cout<<setprecision(16)<<X<<endl;
  cout<<ublas::lu_factorize(X)<<endl;
  cout<<setprecision(16)<<X<<endl;
  cout<<ublas::lu_factorize(X)<<endl;
  cout<<setprecision(16)<<X<<endl;
}
}}}

Output:


{{{
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006473367705848,0.995182407377577,-0.002032391957706),(-0.002032391957706,-0.002032391957706,0.936175146339137))
0
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006504704723334175,0.9951403000320849,-0.002045612067272957),(-0.002042230592742885,-0.002055601674665375,0.9361667907625133))
0
[3,3]((0.995182407377577,-0.006473367705848,-0.002032391957706),(-0.006536193440632496,0.9950979888485471,-0.002058896174255709),(-0.002052116855767581,-0.002079077442455779,0.9361583394521271))

}}}

Is this fixed in newer versions?

Thanks

Michael Cortis

RA, Durham University",michael.cortis@…
11289,"Filter test crashes if other ""compose"" function is defined",iostreams,Boost 1.58.0,To Be Determined,Patches,Jonathan Turkanis,new,2015-05-12T20:02:58Z,2015-05-12T20:02:58Z,"Because it's not qualifying the calls to the compose function, if you happen to have another function defined named ""compose"", the test will not compile.",anonymous
11287,adaptors: strided does not support input iterators,range,Boost 1.58.0,To Be Determined,Bugs,Neil Groves,new,2015-05-12T08:08:18Z,2015-05-12T08:08:18Z,"Hi,

Despite what the documentation says, the stride adaptor does not support input iterators.  This is a pity, since for instance its applicability to iterators to coroutines: see #11274.

Oliver Kowalke tracked down the issue, and built a small scale example that shows the problem: see http://lists.boost.org/boost-users/2015/05/84277.php.  The example is repeated below:

{{{
#include <iostream> 
#include <iterator> 
#include <vector> 
#include <boost/range.hpp> 
#include <boost/range/adaptor/strided.hpp> 
namespace foo { 
template< typename T > 
class X { 
private: 
    typedef std::vector< T > vec_t; 
    vec_t vec_; 
public: 
    X( vec_t const& vec) : 
        vec_( vec) { 
    } 
    class iterator : public std::iterator< std::input_iterator_tag, T > 
    { 
    private: 
        X * x_; 
        typename vec_t::iterator i_; 
    public: 
        typedef typename iterator::pointer pointer_t; 
        typedef typename iterator::reference reference_t; 
        iterator() : 
            x_( 0), i_() 
        {} 
        explicit iterator( X * x) : 
            x_( x), i_( x_->vec_.begin() ) 
        {} 
        iterator( iterator const& other) : 
            x_( other.x_), i_( other.i_) 
        {} 
        iterator & operator=( iterator const& other) { 
            if ( this == & other) return * this; 
            x_ = other.x_; 
            i_ = other.i_; 
            return * this; 
        } 
        bool operator==( iterator const& other) const 
        { return other.x_ == x_ && other.i_ == i_; } 
        bool operator!=( iterator const& other) const 
        { return other.x_ != x_ || other.i_ != i_; } 
        iterator & operator++() { 
            ++i_; 
            return * this; 
        } 
        iterator operator++( int) { 
            i_++; 
            return * this; 
        } 
        reference_t operator*() const 
        { return * i_; } 
        pointer_t operator->() const 
        { return & ( * i_); } 
    }; 
    class const_iterator : public std::iterator< std::input_iterator_tag, 
const T > 
    { 
    private: 
        X * x_; 
        typename vec_t::const_iterator i_; 
    public: 
        typedef typename iterator::pointer pointer_t; 
        typedef typename iterator::reference reference_t; 
        const_iterator() : 
            x_( 0), i_() 
        {} 
        explicit const_iterator( X * x) : 
            x_( x), i_( x_->vec_.begin() ) 
        {} 
        const_iterator( const_iterator const& other) : 
            x_( other.x_), i_( other.i_) 
        {} 
        const_iterator & operator=( const_iterator const& other) { 
            if ( this == & other) return * this; 
            x_ = other.x_; 
            i_ = other.i_; 
            return * this; 
        } 
        bool operator==( const_iterator const& other) const 
        { return other.x_ == x_ && other.i_ == i_; } 
        bool operator!=( const_iterator const& other) const 
        { return other.x_ != x_ || other.i_ != i_; } 
        const_iterator & operator++() { 
            ++i_; 
            return * this; 
        } 
        const_iterator operator++( int) { 
            i_++; 
            return * this; 
        } 
        reference_t operator*() const 
        { return * i_; } 
        pointer_t operator->() const 
        { return & ( * i_); } 
    }; 
    friend class iterator; 
    friend class const_iterator; 
}; 
template< typename T > 
typename X< T >::iterator 
range_begin( X< T > & c) 
{ return typename X< T >::iterator( & c); } 
template< typename T > 
typename X< T >::const_iterator 
range_begin( X< T > const& c) 
{ return typename X< T >::const_iterator( & c); } 
template< typename T > 
typename X< T >::iterator 
range_end( X< T > &) 
{ return typename X< T >::iterator(); } 
template< typename T > 
typename X< T >::const_iterator 
range_end( X< T > const&) 
{ return typename X< T >::const_iterator(); } 
template< typename T > 
typename X< T >::iterator 
begin( X< T > & c) 
{ return boost::begin( c); } 
template< typename T > 
typename X< T >::const_iterator 
begin( X< T > const& c) 
{ return boost::begin( c); } 
template< typename T > 
typename X< T >::iterator 
end( X< T > & c) 
{ return boost::end( c); } 
template< typename T > 
typename X< T >::const_iterator 
end( X< T > const& c) 
{ return boost::end( c); } 
} 
namespace boost { 
template< typename T > 
struct range_mutable_iterator< foo::X< T > > 
{ typedef typename foo::X< T >::iterator type; }; 
template< typename T > 
struct range_const_iterator< foo::X< T > > 
{ typedef typename foo::X< T >::const_iterator type; }; 
} 
int main() 
{ 
    std::vector< int > vec = { 1,2,3,4,5,6,7,8,9,10 }; 
    auto x = foo::X< int >( vec); 
    for (auto i : x | boost::adaptors::strided( 2) ) 
        std::cout << i << "" ""; 
    std::cout << '\n'; 
} 
}}}",Akim Demaille <akim.demaille@…>
11284,VS2013: compiler warnings C4242,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-05-11T19:55:54Z,2015-05-11T19:55:54Z,"Some C4242 [level 4] warnings in asio when compiling with VS 2013 x64.

* boost.library\v1.57.0\include\boost\asio\detail\impl\win_iocp_socket_service_base.ipp(567) : warning C4242: '=' : conversion from 'int' to 'ADDRESS_FAMILY', possible loss of data
* boost.library\v1.57.0\include\boost\asio\impl\serial_port_base.ipp(511) : warning C4242: '=' : conversion from 'const unsigned int' to 'BYTE', possible loss of data",iron9light@…
11280,VS 2010 with LLVM,smart_ptr,Boost 1.58.0,To Be Determined,Bugs,Peter Dimov,new,2015-05-11T09:29:06Z,2015-05-17T11:30:31Z,"I can't compile anything that includes BOOST when I use as a compiler clang on MSVC 2010/2013. The error is a compiler error and not a linker error.
I already built BOOST for CLANG on windows, but I didn't get to the linking stage.

Here is the error log:

1>------ Build started: Project: llvmTest, Configuration: Debug LLVM Win32 ------
1>  In file included from Source.cpp:1:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread.hpp:13:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread.hpp:12:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread_only.hpp:15:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/win32/thread_data.hpp:10:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread_time.hpp:9:
1>  In file included from c:\Boost\include\boost-1_58\boost/date_time/time_clock.hpp:17:
1>  In file included from c:\Boost\include\boost-1_58\boost/shared_ptr.hpp:17:
1>  In file included from c:\Boost\include\boost-1_58\boost/smart_ptr/shared_ptr.hpp:28:
1>  In file included from c:\Boost\include\boost-1_58\boost/smart_ptr/detail/shared_count.hpp:29:
1>  In file included from c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base.hpp:45:
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(27,8): error : unknown type name '_Atomic'
1>  typedef _Atomic( boost::int_least32_t ) atomic_int_least32_t;
1>          ^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(27,24): error : cannot define or redeclare 'int_least32_t' here because namespace 'detail' does not enclose namespace 'boost'
1>  typedef _Atomic( boost::int_least32_t ) atomic_int_least32_t;
1>                   ~~~~~~~^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(27,24): error : typedef declarator cannot be qualified
1>  typedef _Atomic( boost::int_least32_t ) atomic_int_least32_t;
1>                   ~~~~~~~^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(27,39): error : expected ';' after top level declarator
1>  typedef _Atomic( boost::int_least32_t ) atomic_int_least32_t;
1>                                         ^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(29,30): error : unknown type name 'atomic_int_least32_t'
1>  inline void atomic_increment( atomic_int_least32_t * pw )
1>                                ^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(34,46): error : unknown type name 'atomic_int_least32_t'
1>  inline boost::int_least32_t atomic_decrement( atomic_int_least32_t * pw )
1>                                                ^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(39,58): error : unknown type name 'atomic_int_least32_t'
1>  inline boost::int_least32_t atomic_conditional_increment( atomic_int_least32_t * pw )
1>                                                            ^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(68,4): error : unknown type name 'atomic_int_least32_t'
1>      atomic_int_least32_t use_count_;    // #shared
1>      ^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(69,4): error : unknown type name 'atomic_int_least32_t'
1>      atomic_int_least32_t weak_count_;   // #weak + (#shared != 0)
1>      ^
1>c:\Boost\include\boost-1_58\boost/smart_ptr/detail/sp_counted_base_clang.hpp(132,46): error : unknown type name 'atomic_int_least32_t'
1>          return __c11_atomic_load( const_cast< atomic_int_least32_t* >( &use_count_ ), __ATOMIC_ACQUIRE );
1>                                                ^
1>  In file included from Source.cpp:1:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread.hpp:13:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread.hpp:12:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread_only.hpp:15:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/win32/thread_data.hpp:11:
1>c:\Boost\include\boost-1_58\boost/thread/win32/thread_primitives.hpp(183,53): error : redeclaration of 'Sleep' cannot add 'dllimport' attribute
1>                  __declspec(dllimport) void __stdcall Sleep(unsigned long);
1>                                                       ^
1>  c:\Boost\include\boost-1_58\boost/smart_ptr/detail/yield_k.hpp(63,28) :  note: previous declaration is here
1>    extern ""C"" void __stdcall Sleep( unsigned long ms );
1>                              ^
1>  In file included from Source.cpp:1:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread.hpp:13:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread.hpp:12:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread_only.hpp:15:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/win32/thread_data.hpp:11:
1>c:\Boost\include\boost-1_58\boost/thread/win32/thread_primitives.hpp(418,20): error : no member named 'Sleep' in namespace 'boost::detail::win32'; did you mean simply 'Sleep'?
1>                      ::boost::detail::win32::Sleep(0);
1>                      ^~~~~~~~~~~~~~~~~~~~~~~~
1>  c:\Boost\include\boost-1_58\boost/smart_ptr/detail/yield_k.hpp(63,28) :  note: 'Sleep' declared here
1>    extern ""C"" void __stdcall Sleep( unsigned long ms );
1>                              ^
1>  In file included from Source.cpp:1:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread.hpp:13:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread.hpp:12:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/thread_only.hpp:15:
1>  In file included from c:\Boost\include\boost-1_58\boost/thread/win32/thread_data.hpp:11:
1>c:\Boost\include\boost-1_58\boost/thread/win32/thread_primitives.hpp(426,44): error : no type named 'Sleep' in namespace 'boost::detail::win32'
1>                      ::boost::detail::win32::Sleep(milliseconds);
1>                      ~~~~~~~~~~~~~~~~~~~~~~~~^
1>  13 errors generated.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
",aaron.adato@…
11276,Ability to hold already type erased object into a type erased reference.,type_erasure,Boost 1.55.0,To Be Determined,Bugs,Steven Watanabe,new,2015-05-08T11:34:55Z,2015-05-09T00:29:28Z,"I would like to ask for an enhancement to this fantastic library, that is making me so happy in the absence of non-library solutions in c++ :)

This problem came up in my code:

{{{

class my_concept :  public any<requirements> {
   using base = any<requirements>;
public:
   using base::base;
};

class my_concept_ref : public any<requirements, _self &> {
   using base = any<requirements, _self&>;
public:
   template <class... Args>
   my_concept_ref(Args &&... args) : base(std::forward<Args>(args)...) {}
};

//client code
vector<my_concept> vec;
//
vec.push_back(my_concrete_model{});

my_concept_ref get_a_type_erased_type_in_a_ref(vector<my_concept> & vec) {
    return vec[0];
}

//Throws bad_cast:
auto & want_my_model = any_cast<my_concrete_model&>(get_a_type_erased_type_in_a_ref());

//I must do this:
auto & will_give_me_my_model = any_cast<my_concrete_model&>(any_cast<my_concept &>(
  get_a_type_erased_type_in_a_ref());

}}}


The problem here is that when the constructor for my_concept_ref takes an already type erased
type from the vector (my_concept), it wraps that concrete type, which is a model of my_concept, but it was already type_erased, and not the internal concrete model (my_concrete_model).

What could be implemented is automatic unwrapping of a type erased type so that I can
do this:

{{{

//Throws bad_cast:
auto & want_my_model = any_cast<my_concrete_model&>(get_a_type_erased_type_in_a_ref());

}}}

I think this should work. There is no easy workaround but to cast twice. I think
the runtime concept constructor should check wether the class being taking in the
constructor is actually already a type erased one based on detecting any<requirements>. 
I do not want to use in my code both
my_concept & and my_concept_ref depending on wether I wrapped my concrete class or not
in a type erased wrapper. This would give the library more uniformity and makes
sense conceptually, because my_concept & can only be used in case I wrapped my
type in a my_concept &, which is not always the case.

Great work, by the way! I am trying to make heavy use of the library and so far it is serving me very well.
",germandiago
11270,bost::shared_ptr && boost::optional fail to compile in single if statement,smart_ptr,Boost 1.58.0,To Be Determined,Bugs,Peter Dimov,new,2015-05-05T20:32:53Z,2015-05-28T23:15:50Z,"
{{{
/*
using sun 12.4 with std=c++11 does not compile shared_ptr and optional in single if statement , example : if ( ptr && opt_value )
giving following message :   Error: The operation ""boost::shared_ptr<int> && boost::optional<int>"" is illegal

boost version : 1.58

compilation command :
/appl/toolbox/solarisstudio12.4/bin/CC -std=c++11  -I/home/vvenedik/C++/boost_1_58_0 -c main_5.cpp -o main_5.o
*/

#include <boost/optional.hpp>
#include <boost/shared_ptr.hpp>
#include <iostream>


int main() {

boost::shared_ptr<int> ptr(new int) ;

boost::optional<int> opt_int;

opt_int = 5;


if ( ptr && opt_int ) {
    std::cout << ""compiled and ran OK"" << std::endl;
}

}
}}}
",Vladimir Venediktov
11264,Add variadic lock_guard of Lockables,thread,Boost 1.57.0,To Be Determined,Feature Requests,viboes,assigned,2015-05-03T12:56:45Z,2015-05-14T15:59:40Z,"lock_guard works with BasicLockable.

In order the variadic version to avoid deadlock, it can work only with Lockable, as the use of lock forces it.",viboes
11260,stored_edge_property's copy constructor is implicitly deleted for some compilers,graph,Boost 1.56.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-04-30T18:33:53Z,2015-04-30T18:33:53Z,"Stored_edge_property has two possible definitions, depending upon the compiler used. With MSVC or gcc less than 4.6, it is given both a copy constructor and a move constructor. With other compilers, it is given a default move constructor, and its copy constructor is implicitly deleted.

This causes compiler errors in some unexpected places. I've attached an example which gives a compiler error when compiled with gcc 4.7.2 using c++11. I've observed the same issue on clang, although I haven't been able to create a simple reproduction for it there.",dave.lowell@…
11259,boost::movelib::unique_ptr is not convertible to boost::shared_ptr,smart_ptr,Boost 1.58.0,To Be Determined,Feature Requests,Peter Dimov,new,2015-04-30T18:18:42Z,2015-05-03T22:24:17Z,"I'm working on porting some code to a platform without a C++11 standard library, and wanted to use the Boost versions of shared_ptr and unique_ptr.  Unfortunately code like this doesn't work:

{{{
namespace mystd {
    using boost::shared_ptr;
    using boost::make_shared;

    using boost::movelib::unique_ptr;
    using boost::movelib::make_unique;
}

mystd::unique_ptr<int> load_thing() {
    return mystd::make_unique<int>(1);
}

mystd::shared_ptr<int> get_thing() {
    return load_thing();
}
}}}

because there is no conversion from movelib::unique_ptr to shared_ptr.

I'm happy to submit a patch that adds it but I'm not sure whether it's okay to add a Boost.Move dependency to Boost.SmartPtr.  And if I do that, should I also add move emulation to boost::shared_ptr?  C++03 users might like the performance benefit of moving them instead of copying them.",Tavian Barnes <tavianator@…>
11258,Clean up after building,build,Boost 1.58.0,To Be Determined,Feature Requests,Vladimir Prus,new,2015-04-30T17:27:04Z,2015-05-05T14:01:26Z,"After building boost with build-type=complete, 2+ gbyte of object files, pch files and program databases is left behind. It'd be nice if there's an option to clean up intermediate files.",Olaf van der Spek <olafvdspek@…>
11252,make make_ready_future more efficient,thread,Boost 1.58.0,To Be Determined,Tasks,viboes,assigned,2015-04-29T23:37:32Z,2015-05-03T20:55:53Z,this function should be more efficient using a specific shared_state constructor.,viboes
11248,Some algorithms with requirement for SinglePassRange accept range only by const reference,range,Boost 1.57.0,To Be Determined,Bugs,Neil Groves,new,2015-04-29T09:57:50Z,2015-04-29T09:57:50Z,"I came up with it when tried to use generator made by boost.coroutine with boost range algorithms.
The following code doesn't compile with MSVC 2012

{{{
#include <boost/range/distance.hpp>
#include <boost/coroutine/all.hpp>

using namespace boost::range;
using namespace boost::coroutines;

asymmetric_coroutine<int>::pull_type make_dummy_range()
{
    return asymmetric_coroutine<int>::pull_type([](asymmetric_coroutine<int>::push_type& yield)
    {
        yield(1);
    });
}


int _tmain(int argc, _TCHAR* argv[])
{
    boost::distance(make_dummy_range()); // error
    return 0;
}

}}}

with error


{{{
D:\Work\3rdparty\boost_1_58_0\boost/concept_check.hpp(181): error C2079: 'boost::CopyConstructible<TT>::b' uses undefined struct 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              TT=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          and
1>          [
1>              R=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(124) : see reference to class template instantiation 'boost::CopyConstructible<TT>' being compiled
1>          with
1>          [
1>              TT=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(147) : see reference to class template instantiation 'boost::range_detail::IncrementableIteratorConcept<Iterator>' being compiled
1>          with
1>          [
1>              Iterator=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/concept/detail/msvc.hpp(29) : see reference to class template instantiation 'boost::range_detail::SinglePassIteratorConcept<Iterator>' being compiled
1>          with
1>          [
1>              Iterator=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/concept/detail/msvc.hpp(28) : while compiling class template member function 'void boost::concepts::check<Model>::failed(Model *)'
1>          with
1>          [
1>              Model=boost::range_detail::SinglePassIteratorConcept<boost::coroutines::pull_coroutine<int>::const_iterator>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/concept/detail/msvc.hpp(66) : see reference to class template instantiation 'boost::concepts::check<Model>' being compiled
1>          with
1>          [
1>              Model=boost::range_detail::SinglePassIteratorConcept<boost::coroutines::pull_coroutine<int>::const_iterator>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(279) : see reference to class template instantiation 'boost::concepts::require<Model>' being compiled
1>          with
1>          [
1>              Model=boost::range_detail::SinglePassIteratorConcept<boost::coroutines::pull_coroutine<int>::const_iterator>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/concept/detail/has_constraints.hpp(42) : see reference to class template instantiation 'boost::SinglePassRangeConcept<T>' being compiled
1>          with
1>          [
1>              T=boost::coroutines::pull_coroutine<int>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/concept/detail/msvc.hpp(58) : see reference to class template instantiation 'boost::concepts::not_satisfied<Model>' being compiled
1>          with
1>          [
1>              Model=boost::SinglePassRangeConcept<boost::coroutines::pull_coroutine<int>>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/range/algorithm/for_each.hpp(72) : see reference to class template instantiation 'boost::concepts::require<Model>' being compiled
1>          with
1>          [
1>              Model=boost::SinglePassRangeConcept<boost::coroutines::pull_coroutine<int>>
1>          ]
1>          coroutine_bug.cpp(29) : see reference to function template instantiation 'UnaryFunction boost::range::for_each<boost::coroutines::pull_coroutine<R>,wmain::<lambda_d9c6ee6ee85186807f477d3ab241bdd7>>(SinglePassRange &,UnaryFunction)' being compiled
1>          with
1>          [
1>              UnaryFunction=wmain::<lambda_d9c6ee6ee85186807f477d3ab241bdd7>,
1>              R=int,
1>              SinglePassRange=boost::coroutines::pull_coroutine<int>
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(364): error C2027: use of undefined type 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/coroutine/asymmetric_coroutine.hpp(812) : see declaration of 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/iterator/iterator_categories.hpp(119) : see reference to class template instantiation 'std::iterator_traits<_Iter>' being compiled
1>          with
1>          [
1>              _Iter=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(126) : see reference to class template instantiation 'boost::iterators::iterator_traversal<Iterator>' being compiled
1>          with
1>          [
1>              Iterator=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(364): error C2146: syntax error : missing ';' before identifier 'iterator_category'
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(364): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(365): error C2027: use of undefined type 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/coroutine/asymmetric_coroutine.hpp(812) : see declaration of 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(365): error C2146: syntax error : missing ';' before identifier 'value_type'
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(365): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(366): error C2027: use of undefined type 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/coroutine/asymmetric_coroutine.hpp(812) : see declaration of 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(366): error C2146: syntax error : missing ';' before identifier 'difference_type'
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(366): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(368): error C2027: use of undefined type 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/coroutine/asymmetric_coroutine.hpp(812) : see declaration of 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(368): error C2146: syntax error : missing ';' before identifier 'pointer'
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(368): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(369): error C2027: use of undefined type 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/coroutine/asymmetric_coroutine.hpp(812) : see declaration of 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              R=int
1>          ]
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(369): error C2146: syntax error : missing ';' before identifier 'reference'
1>D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xutility(369): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\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=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\Work\3rdparty\boost_1_58_0\boost/mpl/eval_if.hpp(41): error C2516: 'boost::mpl::if_<T1,T2,T3>::type' : is not a legal base class
1>          with
1>          [
1>              T1=boost::is_convertible<int,std::output_iterator_tag>,
1>              T2=boost::mpl::identity<boost::iterators::incrementable_traversal_tag>,
1>              T3=void
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/mpl/if.hpp(70) : see declaration of 'boost::mpl::if_<T1,T2,T3>::type'
1>          with
1>          [
1>              T1=boost::is_convertible<int,std::output_iterator_tag>,
1>              T2=boost::mpl::identity<boost::iterators::incrementable_traversal_tag>,
1>              T3=void
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled
1>          with
1>          [
1>              C=boost::is_convertible<int,std::output_iterator_tag>,
1>              F1=boost::mpl::identity<boost::iterators::incrementable_traversal_tag>,
1>              F2=void
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled
1>          with
1>          [
1>              C=boost::is_convertible<int,std::input_iterator_tag>,
1>              F1=boost::mpl::identity<boost::iterators::single_pass_traversal_tag>,
1>              F2=boost::mpl::eval_if<boost::is_convertible<int,std::output_iterator_tag>,boost::mpl::identity<boost::iterators::incrementable_traversal_tag>,void>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled
1>          with
1>          [
1>              C=boost::is_convertible<int,std::forward_iterator_tag>,
1>              F1=boost::mpl::identity<boost::iterators::forward_traversal_tag>,
1>              F2=boost::mpl::eval_if<boost::is_convertible<int,std::input_iterator_tag>,boost::mpl::identity<boost::iterators::single_pass_traversal_tag>,boost::mpl::eval_if<boost::is_convertible<int,std::output_iterator_tag>,boost::mpl::identity<boost::iterators::incrementable_traversal_tag>,void>>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled
1>          with
1>          [
1>              C=boost::is_convertible<int,std::bidirectional_iterator_tag>,
1>              F1=boost::mpl::identity<boost::iterators::bidirectional_traversal_tag>,
1>              F2=boost::mpl::eval_if<boost::is_convertible<int,std::forward_iterator_tag>,boost::mpl::identity<boost::iterators::forward_traversal_tag>,boost::mpl::eval_if<boost::is_convertible<int,std::input_iterator_tag>,boost::mpl::identity<boost::iterators::single_pass_traversal_tag>,boost::mpl::eval_if<boost::is_convertible<int,std::output_iterator_tag>,boost::mpl::identity<boost::iterators::incrementable_traversal_tag>,void>>>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/iterator/iterator_categories.hpp(99) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled
1>          with
1>          [
1>              C=boost::is_convertible<int,std::random_access_iterator_tag>,
1>              F1=boost::mpl::identity<boost::iterators::random_access_traversal_tag>,
1>              F2=boost::mpl::eval_if<boost::is_convertible<int,std::bidirectional_iterator_tag>,boost::mpl::identity<boost::iterators::bidirectional_traversal_tag>,boost::mpl::eval_if<boost::is_convertible<int,std::forward_iterator_tag>,boost::mpl::identity<boost::iterators::forward_traversal_tag>,boost::mpl::eval_if<boost::is_convertible<int,std::input_iterator_tag>,boost::mpl::identity<boost::iterators::single_pass_traversal_tag>,boost::mpl::eval_if<boost::is_convertible<int,std::output_iterator_tag>,boost::mpl::identity<boost::iterators::incrementable_traversal_tag>,void>>>>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::iterators::detail::old_category_to_traversal<Cat>' being compiled
1>          with
1>          [
1>              Cat=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/iterator/iterator_categories.hpp(113) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled
1>          with
1>          [
1>              C=boost::is_convertible<int,boost::iterators::incrementable_traversal_tag>,
1>              F1=boost::mpl::identity<int>,
1>              F2=boost::iterators::detail::old_category_to_traversal<int>
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/iterator/iterator_categories.hpp(121) : see reference to class template instantiation 'boost::iterators::iterator_category_to_traversal<Cat>' being compiled
1>          with
1>          [
1>              Cat=int
1>          ]
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(126): error C2039: 'type' : is not a member of 'boost::iterators::iterator_traversal<Iterator>'
1>          with
1>          [
1>              Iterator=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(126): error C2146: syntax error : missing ';' before identifier 'traversal_category'
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(126): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(128): error C2065: 'traversal_category' : undeclared identifier
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(128): error C2923: 'boost::Convertible' : 'traversal_category' is not a valid template type argument for parameter 'X'
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(128): error C2893: Failed to specialize function template 'boost::concepts::require<Model> boost::concepts::require_(void (__cdecl *)(Model))'
1>          With the following template arguments:
1>          'boost::Convertible'
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(128): error C2056: illegal expression
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(140): error C2079: 'boost::range_detail::IncrementableIteratorConcept<Iterator>::i' uses undefined struct 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              Iterator=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          and
1>          [
1>              R=int
1>          ]
1>D:\Work\3rdparty\boost_1_58_0\boost/concept_check.hpp(239): error C2079: 'boost::EqualityComparable<TT>::a' uses undefined struct 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              TT=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          and
1>          [
1>              R=int
1>          ]
1>          D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(148) : see reference to class template instantiation 'boost::EqualityComparable<TT>' being compiled
1>          with
1>          [
1>              TT=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>D:\Work\3rdparty\boost_1_58_0\boost/concept_check.hpp(239): error C2079: 'boost::EqualityComparable<TT>::b' uses undefined struct 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              TT=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          and
1>          [
1>              R=int
1>          ]
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(150): error C2146: syntax error : missing ',' before identifier 'traversal_category'
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(150): error C2065: 'traversal_category' : undeclared identifier
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(150): error C2893: Failed to specialize function template 'boost::concepts::require<Model> boost::concepts::require_(void (__cdecl *)(Model))'
1>          With the following template arguments:
1>          'boost::Convertible'
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(150): error C2056: illegal expression
1>D:\Work\3rdparty\boost_1_58_0\boost/range/concepts.hpp(174): error C2079: 'boost::range_detail::SinglePassIteratorConcept<Iterator>::i' uses undefined struct 'boost::coroutines::pull_coroutine<R>::const_iterator'
1>          with
1>          [
1>              Iterator=boost::coroutines::pull_coroutine<int>::const_iterator
1>          ]
1>          and
1>          [
1>              R=int
1>          ]
1>
1>Build FAILED.
1>

}}}

Generator models SinglePassRange and modify itself will iterating, but distance accept range only by const reference

{{{
    template< class T >
    inline BOOST_DEDUCED_TYPENAME range_difference<T>::type 
    distance( const T& r )
    {
        return std::distance( boost::begin( r ), boost::end( r ) );
    }
}}}

I checked other algorithms and found that some of them have non const reference overload (for example count)

{{{
template<class SinglePassRange, class Value>
typename range_difference<SinglePassRange>::type
count(SinglePassRange& rng, const Value& val);

template<class SinglePassRange, class Value>
typename range_difference<const SinglePassRange>::type
count(const SinglePassRange& rng, const Value& val);
}}}

I tried count instead of distance and I was suprised that it doesn't compile too. 

{{{
asymmetric_coroutine<int>::pull_type make_dummy_range()
{
    return asymmetric_coroutine<int>::pull_type([](asymmetric_coroutine<int>::push_type& yield)
    {
        yield(1);
    });
}

int _tmain(int argc, _TCHAR* argv[])
{
    asymmetric_coroutine<int>::pull_type r = make_dummy_range();
    boost::count(r, 1); //still complains on const_iterator
    return 0;
}
}}}

I don't understand why MSVC12 compiler still prefer const ref overload
{{{
template<class SinglePassRange, class Value>
typename range_difference<const SinglePassRange>::type
count(const SinglePassRange& rng, const Value& val);
}}}

but it is",Taras Kozlov <kozlov.taras@…>
11247,"More useful rtree API (public apply_visitor, ...)",geometry,Boost 1.58.0,To Be Determined,Feature Requests,Barend Gehrels,new,2015-04-29T09:47:29Z,2015-05-14T10:11:27Z,"I would like to use geometry::index::rtree to create rtree in memory and then export whole structure to custom database. For that I need access to all nodes not only leaf values.

Proposed changes:[[BR]]
* make rtree::apply_visitor public
* make rtree::depth public (optional but makes sense imho)
* make second rtree typedef section (box_type, allocators, internal_node, leaf, node_pointer etc.) public 

Using that I can conveniently create my own visitor and traverse all nodes in a tree",Tomas P <pecholt@…>
11244,A version of vector optimized for the empty case,container,Boost 1.58.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2015-04-25T19:55:43Z,2015-04-25T19:55:43Z,"Hello,

it would be useful if boost could provide a version of vector optimized for the case where the vector is empty. In particular, sizeof(vector)==sizeof(void*) with no allocation in the empty case. The size and capacity can be stored in the allocated region when that region exists. This technique can be seen in mozilla's nsTArray, libstdc++'s std::string (before the new ABI in gcc-5) and several other places. Like mozilla, I would like to use this in a tree-like structure, and a large proportion of the nodes are leaves with an empty vector, where 2 pointers make a noticable difference. To be precise, I would actually want a flat_set with a map-like interface (the key can be deduced from the value), but a vector would be a good start.",marc.glisse@…
11242,Accuray issue with geometry::difference() in version Boost 1.57 (and 1.58),geometry,Boost 1.57.0,To Be Determined,Bugs,Barend Gehrels,new,2015-04-25T12:11:52Z,2015-04-25T12:11:52Z,"I'm having an accuracy issue with geometry::difference() in Boost v1.57 (and v1.58) that I didn't see with v1.55. The test program is listed below. I compiled using g++ 4.4.7 on Ubuntu 12.04.

Result using Boost v1.55:

{{{
         249.232           761.09
         249.232           760.98
          265.89           760.98
          265.89          729.219
          94.021          729.219
          94.021           761.09
         249.232           761.09
}}}

Result using Boost v1.57 (and v1.58):

{{{
249.232003466816           761.09
         249.232           760.98
          265.89 760.979984987659
          265.89          729.219
          94.021          729.219
          94.021           761.09
249.232003466816           761.09
}}}

Apparently, it is related to the rescaling policy introduced in v1.56. I can mitigate the issue by defining the BOOST_GEOMETRY_NO_ROBUSTNESS.

Best regards,

Mikkel B. Stegmann 

----

{{{
#include <boost/foreach.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry.hpp>

#include <cstdio>
#include <assert.h>

int main() {

  // 2D point with double precision
  typedef boost::geometry::model::d2::point_xy<double> BoostPoint;

  // 2D polygon, ring type: clockwise, closed (""the first point must be spatially equal to the last point"")
  typedef boost::geometry::model::polygon<BoostPoint> BoostPolygon;

  BoostPolygon rectangleA;
  rectangleA.outer().push_back(BoostPoint( 94.021, 729.219)); // clock-wise points
  rectangleA.outer().push_back(BoostPoint( 94.021, 761.090));
  rectangleA.outer().push_back(BoostPoint(265.890, 761.090));
  rectangleA.outer().push_back(BoostPoint(265.890, 729.219));
  rectangleA.outer().push_back(BoostPoint( 94.021, 729.219)); // close

  BoostPolygon rectangleB;
  rectangleB.outer().push_back(BoostPoint(249.232, 760.980)); // clock-wise points
  rectangleB.outer().push_back(BoostPoint(249.232, 780.980));
  rectangleB.outer().push_back(BoostPoint(319.232, 780.980));
  rectangleB.outer().push_back(BoostPoint(319.232, 760.980));
  rectangleB.outer().push_back(BoostPoint(249.232, 760.980)); // close

  std::list<BoostPolygon> differencePolygons;
  boost::geometry::difference(rectangleA, rectangleB, differencePolygons);
  assert(differencePolygons.size()==1);

  BOOST_FOREACH(const BoostPoint &point, differencePolygons.front().outer()) {
    printf(""%16.15g %16.15g\n"", point.x(), point.y());
  }

  return 0;
}
}}}",mikkel.stegmann@…
11240,tons of warnings about unused local typedefs with clang++,range,Boost 1.58.0,To Be Determined,Bugs,,reopened,2015-04-24T20:35:09Z,2015-05-04T11:25:38Z,"When compiling anything using `BOOST_RANGE_CONCEPT_ASSERT()` clang++ emits tons of warnings about used local typedefs if compiled with `-Wall`.

This is a regression compared to 1.57.0.

Trivial example program:

{{{
#include <vector>
#include <boost/range/algorithm.hpp>

int
main(int, char**) {
  std::vector<int> v;
  boost::range::sort(v);
}
}}}

Compiled with:

{{{
clang++ -Wall -I$HOME/opt/boost/boost_1_58_0/include/ \
  -L$HOME/opt/boost/boost_1_58_0/lib/ -o cpp1 cpp1.cpp
}}}

Output (excerpt):

{{{
In file included from cpp1.cpp:46:
In file included from /home/mosu/opt/boost/boost_1_58_0/include/boost/range/algorithm.hpp:29:
In file included from /home/mosu/opt/boost/boost_1_58_0/include/boost/range/concepts.hpp:19:
/home/mosu/opt/boost/boost_1_58_0/include/boost/concept_check.hpp:51:7: warning: unused typedef 'boost_concept_check51' [-Wunused-local-typedef]
      BOOST_CONCEPT_ASSERT((Model));
…
…
313 warnings generated.
}}}

These are 313 warnings for that trivial example program above.

g++ 4.9.2 does not emit such warnings, with neither version.

clang++ 3.6.0 emits those warnings with Boost 1.58.0 but not with 1.57.0 or earlier.",Moritz Bunkus <moritz@…>
11238,Clang doesn't support -finline-function,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2015-04-24T16:04:03Z,2015-04-24T16:04:03Z,"Previous versions of clang just ignored it silently, but now it actually emits a warning in 3.5.  See http://stackoverflow.com/questions/26108606/no-support-to-finline-functions-in-clang-3-5 for details.

Suggest removing ""-finline-functions' from clang-darwin.compile OPTIONS on line 86 of tools/build/src/tools/clang-darwin.jam",nathan@…
11237,Cannot include iostreams/filter/test.hpp in two compilation units,iostreams,Boost 1.57.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-04-24T15:55:04Z,2015-04-24T15:55:04Z,"The function ""boost::iostreams::rand(int)"" is multiply defined if you include test.hpp in two separate compilation units.  This function should probably just be marked as inlined.",nathan@…
11235,Variance error when used with std::complex,accumulator,Boost 1.58.0,To Be Determined,Bugs,Eric Niebler,new,2015-04-24T11:20:58Z,2015-04-24T11:20:58Z,"The result of variance in complex numbers sequence must be real, but it is complex.

It is solved changing the line (in ""variance.hpp""):
        this->variance =
                    numeric::fdiv(this->variance * (cnt - 1), cnt)
                  + numeric::fdiv(tmp * tmp, cnt - 1);

with this one:
        this->variance =
                    numeric::fdiv(this->variance * (cnt - 1), cnt)
                  + numeric::fdiv(std::pow(std::abs(tmp),2), cnt - 1);


P.D: sorry, I don't know how to fix it in ""lazy_variance""",Martín Sanz Sabater <martin.sanz@…>
11227,Support for unidirectional shutdown in ssl::stream,asio,Boost 1.58.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2015-04-23T14:37:54Z,2016-02-16T14:57:39Z,"In version 1.57 there is no possibility of sending ""close notify"" shutdown alert to the peer without waiting for peer's response.

The motivation of such feature is that some applications won't send their ""close notify"" response. In particular, Internet Explorer 11 apparently does not send it's ""close notify"" response to the server which called boost::asio::ssl::stream::async_shutdown when server's SSL certificate is considered untrusted. As a consequence callback for async_shutdown is never called, and the web server can not shutdown connection gracefully.

Citing OpenSSL documentation:
""''According to the TLS standard, it is acceptable for an application to only send its shutdown alert and then close the underlying connection without waiting for the peer's response''""...

Taking this into account it would be really helpful for me to have an option in the async_shutdown method which would specify type of SSL shutdown (unidirectional or bidirectional).",Oleg Andriyanov (o.andriyanov@…
11225,"failed to compile with msvc8, variadics used wrong",fusion,Boost 1.58.0,To Be Determined,Bugs,Joel de Guzman,new,2015-04-22T12:32:56Z,2015-04-22T13:32:10Z,"Hi,

in fusion there are now switches to generate code either for compilers that support variadics macros or don't. For that the macro BOOST_PP_VARIADICS macro used, but there is a corner case: vs2005 has an incomplete implementation of variadic macros, that will fail with empty sequences, i.e. see BOOST_PP_IS_EMPTY that handles this is in a special way.

Therefore variadics should not be used for generation here.

All code in boost/fusion that uses only BOOST_PP_VARIADICS needs to be extended with && (!defined(_MSC_VER) || defined(_MSC_VER) && _MSC_VER > 1400) to avoid compiler failures.

Original error message comes from boost/phoenix, where compiler complains that there are not enough actual arguments for BOOST_PP_IS_EMPTY and other macros.

Greetz, ILo.",ingo.loehken@…
11224,Pre-processing / Pre-generating MPL-containers stopped working,mpl,Boost 1.56.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-04-22T09:44:30Z,2015-04-22T12:11:13Z,"
== Background ==

Boost.MPL allows to pre-process / pre-generate headers for MPL-containers (`vector`, `list`, `set`, `map`). In particular, headers for containers in ''variadic'' and ''numbered'' form can be pre-generated. For that, Boost.MPL comes with some python-scripts, located in subdirectory ""libs/mpl/preprocessed/"" of the Boost-source directory. (As a side-note: Documentation for these python-scripts is missing.)

By default, Boost comes with pre-generated headers for MPL-containers that are able to hold up to 50 elements. Using the mentioned python-files it is possible to generate MPL-containers that can hold even more elements.


== Problem ==

Since release of Boost 1.56.0 the pre-generation of headers for MPL-containers does not work anymore.


== Explanation ==

One of the python-scripts used for pre-generation (""`pp.py`"") requires certain information to be found in the header-comments of input-headers. In particular, it required the field `$Id$` in the header-comment to contain the filename (followed by some additional non-whitespace characters), which it no longer does in release 1.56.0 and newer Boost releases.

`$Id$` is a Subversion substitution-keyword. (See: `[http]://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.props.special.keywords`)

I assume, Boost switched from Subversion to Git before releasing Boost 1.56.0. That would explain why the keyword-substition did no longer work.


== Solution ==

To make the python-scripts work again, the best solution would be to also make the keyword-substitution work together with Git. However, as this is neither simple nor recommended (see: `[https]://git.wiki.kernel.org/index.php/Git_FAQ#Does_Git_have_keyword_expansion.3F`) one should probably add the missing information into the header-comments directly before pre-generation.

The attached python-script ""`fix_boost_mpl_preprocess.py`"" is able to do that.
The attached python-script ""`boost_mpl_preprocess.py`"" can then be used as a comfortable helper-script for pre-generating.


== Additional Information ==

Explanation for both scripts on Stackoverflow:[[BR]]
`[http]://stackoverflow.com/a/29627158/3115457`

Discussion regarding this problem on the boost-users mailing-list:[[BR]]
`[http]://thread.gmane.org/gmane.comp.lib.boost.user/83794`
",Deniz Bahadir <deniz.bahadir@…>
11213,Can't debug program using Boost on MacOSX 10.10 using GCC 4.9 and GDB 7,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2015-04-21T08:50:33Z,2015-04-21T08:50:33Z,"Hi,

My problem is when debugging from Eclipse a program that uses Boost (even pure header) then the GDB debugger is unable to locate frame base for the function being trace into.

This happens only when using Boost header.

Please note that except this, the program works like a charm in debug and release mode. The problem is only for debugging and inspecting source code referring to Boost.

Please not also that the problem only affects OSX (Yosemite), mean that no issue for Linux.

The issue is that I can't see the value of the local variables. Below is the message I have in the ""(x)= Variables"" window of Eclipse :

Failed to execute MI command:
-data-evaluate-expression result
Error message from debugger back end:
Could not find the frame base for ""main()"".

The code is as simple as :

#include <boost/regex.hpp>
#include <iostream>
int main() {
   int result = 1;
   boost::regex reExpression(""[a-z]+"");

   std::cout << ""!!!Hello World !!!"" << std::endl;
   result ++;

  cout << "" Result = "" << result << ""\n"";
  return result;
}

The program is compiled using the command :

g++ -v -o -g bin/Essai-MACOS-Debug  src/Essai.cpp -I/opt/local/include /opt/local/lib/libboost_regex-mt.a

If you remove the reference to Boost.Regex then everything is ok. I can inspect the value of the local variable result.

More interesting: I built a library with a single function relying on Boost, and call that function from main(). It happens that can inspect the code in main() and have the value of main's local variable but when I came inside the library's function, the one now referring to boost then again I can't see the local variables of that function.

So it seems that as soon as a source file is referring to Boost, GDB get confused.

I have installed GCC 4.9, GDB 7.7 and Boost 1.57 using MacPort on OSX Yosemit.

I've compile Boost from source with MacPort in order to use GCC instead of GCC using the command :

sudo port install -ns boost config.compiler=macport-gcc-4.9

I also tried with a version of Boost I compiled myself and I did have the same issue.

Does anyone knows about this problem ?

I've compiled and installed the last GDB version from sources (7.9) and have the same issue described here than with the 7.7.1 provided by MacPorts.
",anonymous
11212,"""type qualifiers ignored on function return type"" in ptr_container's map_iterator's operator->",ptr_container,Boost 1.49.0,To Be Determined,Patches,Thorsten Ottosen,new,2015-04-20T21:34:07Z,2015-04-20T21:34:07Z,"Sorry to bore you with such trivia, when I know this is easy for anyone who hits it to fix themselves, but it'd be nice if we didn't have to reapply this patch when we upgrade Boost.  While I'm raising this on the obsolete version I actually used in the test case below, the fingered code is still present in svn:

martind@swiftboat:~/playpen$ cat map_iterator.cpp 
#include <boost/ptr_container/ptr_map.hpp>
martind@swiftboat:~/playpen$ gcc -c -Wignored-qualifiers -Wsystem-headers map_iterator.cpp 
In file included from /usr/include/boost/ptr_container/ptr_map_adapter.hpp:19:0,
                 from /usr/include/boost/ptr_container/ptr_map.hpp:20,
                 from map_iterator.cpp:1:
/usr/include/boost/ptr_container/detail/map_iterator.hpp:52:48: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
martind@swiftboat:~/playpen$ 

I'll attach a patch against trunk.",martin.dorey@…
11210,BOOST_CURRENT_FUNCTION internal compiler error,utility,Boost 1.57.0,To Be Determined,Bugs,No-Maintainer,new,2015-04-20T18:55:59Z,2015-04-20T18:55:59Z,"Hi,

if using a template function with an parameter that needs to be specified explicitly and is either a pseudo scoped enum or scoped enum with a specific storage type, compilation on vs2013 will fail with and internal compiler error. This can easily be fixed using FUNCTION (XXX) for that compiler-version.

(XXX) 2 leading and trailing underscores missing at FUNCTION

Greetz, ILo.

How to reproduce:

struct Val
{
  enum Enum : unsigned char
  {
     x,
  };
};

typedef ScopeEnum::Vals

template <Vals eVal> void Foo()
{
  BOOST_ASSERT(eVal == Val::x);
}

How to solve: (add to line 31 in front of all ifdef, current_function.hpp)

#if defined(_MSC_VER) && (_MSC_VER > 1700) // > vs2012 (only tested for vs2013)

# define BOOST_CURRENT_FUNCTION FUNCTION (XXX)

",ingo.loehken@…
11208,Swapping allocators does not use ADL,circular_buffer,Boost 1.58.0,Boost 1.59.0,Bugs,Jan Gaspar,new,2015-04-20T15:04:04Z,2015-05-28T10:25:02Z,"boost::circular buffer has issues when using it with Boost.Interprocess, due to attempting to use std::swap on the allocators. Specifically:

{{{#!cpp
void swap_allocator(circular_buffer<T, Alloc>& cb, const false_type&) {
    std::swap(m_alloc, cb.m_alloc);
}
}}}

does not allow ADL to find the correct swap implementation. This can be worked around by specializing std::swap, but this is not ideal, and leads to some compile issues on OSX with Clang.

The correct implementation would look like

{{{#!cpp
void swap_allocator(circular_buffer<T, Alloc>& cb, const false_type&) {
    using std::swap;
    swap(m_alloc, cb.m_alloc);
}
}}}",Alex Merry <alexander.merry@…>
11207,boost::numeric::ublas::shallow_array_adaptor broken when compiling with -DNDEBUG,numeric,Boost 1.58.0,To Be Determined,Bugs,Douglas Gregor,new,2015-04-20T14:01:19Z,2015-05-14T06:49:49Z,"The attached code does not compile with clang++ 3.6, 3.7svn, Xcode's clang++, or g++ 4.9. I get these errors:
{{{
> /usr/bin/clang++ -DNDEBUG -o broken_shallow_array_adaptor broken_shallow_array_adaptor.cpp -I /opt/local/include
In file included from broken_shallow_array_adaptor.cpp:2:
In file included from /opt/local/include/boost/numeric/ublas/matrix.hpp:18:
In file included from /opt/local/include/boost/numeric/ublas/vector.hpp:21:
/opt/local/include/boost/numeric/ublas/storage.hpp:781:9: error: expected member name or ';'
      after declaration specifiers
        template <size_t N>
        ^
/opt/local/include/boost/numeric/ublas/storage.hpp:901:9: error: unknown type name
      'const_iterator'
        const_iterator begin () const {
        ^
/opt/local/include/boost/numeric/ublas/storage.hpp:905:9: error: unknown type name
      'const_iterator'
        const_iterator cbegin () const {
        ^
/opt/local/include/boost/numeric/ublas/storage.hpp:909:9: error: unknown type name
      'const_iterator'
        const_iterator end () const {
        ^
/opt/local/include/boost/numeric/ublas/storage.hpp:913:9: error: unknown type name
      'const_iterator'
        const_iterator cend () const {
        ^
/opt/local/include/boost/numeric/ublas/storage.hpp:929:39: error: use of undeclared identifier
      'const_iterator'
        typedef std::reverse_iterator<const_iterator> const_reverse_iterator;
                                      ^
In file included from broken_shallow_array_adaptor.cpp:2:
In file included from /opt/local/include/boost/numeric/ublas/matrix.hpp:18:
/opt/local/include/boost/numeric/ublas/vector.hpp:477:27: error: no type named 'const_iterator'
      in 'boost::numeric::ublas::shallow_array_adaptor<const double>'
             typedef typename A::const_iterator const_subiterator_type;
                     ~~~~~~~~~~~~^~~~~~~~~~~~~~
broken_shallow_array_adaptor.cpp:11:58: note: in instantiation of template class
      'boost::numeric::ublas::vector<double, boost::numeric::ublas::shallow_array_adaptor<const
      double> >' requested here
    vector<double, shallow_array_adaptor<const double> > tmp2(10, tmp1);
                                                         ^
7 errors generated.
}}}",Mark.Moll@…
11206,address_v4::to_ulong() returns 8 bytes on real 64bit systems,asio,Boost 1.57.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2015-04-20T13:40:45Z,2015-04-20T13:40:45Z,"which generates narrowing warning when assigned to 32bit variable

please consider adding std::uint32_t address_v4::to_uint32() or something like that",pal666@…
11204,undefined behavior sanitizer complains about runtime_error thrown in serialization/singleton.hpp before main(),serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,reopened,2015-04-18T20:18:04Z,2018-01-20T08:49:48Z,"How to reproduce:

{{{
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>
#include <boost/serialization/vector.hpp>

#include <vector>
#include <fstream>

using namespace std;

struct Data {
  vector<int> v;
};

namespace boost {
  namespace serialization {

    template<class Archive>
      void serialize(Archive & a, Data &d, const unsigned int version)
      {
        a & d.v;
      }

  }
}

int main(int argc, char **argv)
{
  if (argc > 10) {
    ifstream f(""/dev/null"");
    boost::archive::text_iarchive a(f);
    Data d;
    a >> d;
  } else {
    ofstream f(""/dev/null"");
    boost::archive::text_oarchive a(f);
    Data d;
    a << d;
  }
  return 0;
}
}}}

Compile via:

{{{
$ g++ -g -std=c++11 -I/home/juser/src/boost/modular-boost \
   -L/home/juser/src/boost/modular-boost/stage/lib \
   -Wl,-R/home/juser/src/boost/modular-boost/stage/lib \
   -fsanitize=undefined  test_serialize.cc \
   -o test_serialize -lboost_serialization
}}}

(GCC's undefined behavior sanitizer is enabled with {{{-fsanitize=undefined}}})

Run:

{{{
$ ./test_serialize
}}}

Expected output:

{{{
}}}

(nothing)

Actual output:

{{{
/home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:132:21:
    runtime error: reference binding to null pointer of type
    'const struct extended_type_info_typeid'
/home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:132:21:
    runtime error: reference binding to null pointer of type
    'const struct iserializer'
/home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:132:21: runtime error: reference binding to null pointer of type 'const struct oserializer'
/home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:132:21: runtime error: reference binding to null pointer of type 'const struct extended_type_info_typeid'
/home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:132:21: runtime error: reference binding to null pointer of type 'const struct oserializer'
/home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:132:21: runtime error: reference binding to null pointer of type 'const struct iserializer'
}}}

First backtrace when breaking in singleton.hpp:132:

{{{
(gdb) bt
#0  boost::serialization::singleton<boost::serialization::extended_type_info_typeid<Data> >::get_instance ()
    at /home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:132
#1  0x0000000000407ebd in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<Data> >::get_const_instance ()
    at /home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:141
#2  0x0000000000407924 in boost::archive::detail::iserializer<boost::archive::text_iarchive, Data>::iserializer (
    this=0x640a60 <boost::serialization::singleton<boost::archive::detail::iserializer<boost::archive::text_iarchive, Data> >::get_instance()::t>)
    at /home/juser/src/boost/modular-boost/boost/archive/detail/iserializer.hpp:128
#3  0x0000000000407373 in boost::serialization::detail::singleton_wrapper<boost::archive::detail::iserializer<boost::archive::text_iarchive, Data> >::singleton_wrapper (
    this=0x640a60 <boost::serialization::singleton<boost::archive::detail::iserializer<boost::archive::text_iarchive, Data> >::get_instance()::t>)
    at /home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:106
#4  0x000000000040740b in boost::serialization::singleton<boost::archive::detail::iserializer<boost::archive::text_iarchive, Data> >::get_instance ()
    at /home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:128
#5  0x0000000000404a13 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
    at /home/juser/src/boost/modular-boost/boost/serialization/singleton.hpp:149
#6  0x0000000000404c6e in _GLOBAL__sub_I_main () at test_serialize.cc:43
#7  0x000000000041abbd in __libc_csu_init ()
#8  0x00007ffff62e5f6f in __libc_start_main (main=0x4047c6 <main(int, char**)>, argc=1, argv=0x7fffffffdfb8, init=0x41ab70 <__libc_csu_init>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffdfa8) at libc-start.c:245
#9  0x00000000004046f9 in _start ()
}}}
",Georg Sauthoff <mail@…>
11202,boost.sort header conflicts with boost.range header,range,Boost 1.58.0,To Be Determined,Bugs,Neil Groves,new,2015-04-18T13:26:28Z,2016-02-23T14:47:50Z,"This two-line program fails to compile.

{{{#!cpp
#include <boost/range/algorithm.hpp>
#include <boost/sort/spreadsort/spreadsort.hpp>
}}}

The headers conflict on ""boost::sort"".
The first header declares a '''function''' boost::sort.
The second header declares a '''namespace''' boost::sort.",john2.718281828459045235360287@…
11200,Error when compiling log_setup by compiler Intel C++ 14.0,phoenix,Boost 1.58.0,To Be Determined,Bugs,Thomas Heller,new,2015-04-18T08:49:56Z,2015-07-21T15:39:57Z,"In case of compilation of log_setup library there is the following error:

{{{
intel-linux.compile.c++ /home/phprus/devel/build/deps/boost/boost/bin.v2/libs/log/build/intl-lnx-14.0/rls/bst.l-off/log-api-unx/pch-off/thrd-mlt/default_formatter_factory.o

    ""/opt/intel/composer_xe_2013_sp1.0.080/bin/intel64/icpc"" -c -xc++ -w1 -inline-level=2 -O3 -ip -pthread -fPIC -m64      -fPIC -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc  -no-intel-extensions  -fvisibility=hidden -fvisibility-inlines-hidden   -ipo   -std=gnu++98  -wd177,780,2196,1782,193,304,981,1418,411,734,279 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_DYN_LINK=1 -DBOOST_LOG_SETUP_BUILDING_THE_LIB=1 -DBOOST_LOG_SETUP_DLL -DBOOST_LOG_USE_AVX2 -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_USE_SSSE3 -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -D_GNU_SOURCE=1 -D_XOPEN_SOURCE=600 -I"".""   -c -o ""/home/phprus/devel/build/deps/boost/boost/bin.v2/libs/log/build/intl-lnx-14.0/rls/bst.l-off/log-api-unx/pch-off/thrd-mlt/default_formatter_factory.o"" ""libs/log/src/default_formatter_factory.cpp""

./boost/proto/detail/preprocessed/make_expr_.hpp(73): error: class ""boost::proto::transform<PrimitiveTransform, X>::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<2>>, 0L>, boost::log::v2_mt_posix::expressions::stream_type>, 2L>)> [with
          PrimitiveTransform=boost::proto::switch_<boost::phoenix::phoenix_generator, boost::proto::tag_of<boost::proto::_> ()>, X=void]"" has no member ""type""
          typedef typename proto_generator::template result<proto_generator(expr_type)>::type result_type;
                                                                                         ^
          detected during:
            instantiation of class ""boost::proto::detail::make_expr_<Tag, Domain, A0, A1, void, void, void, void, void, void, void, void, void> [with Tag=boost::proto::tagns_::tag::assign, Domain=boost::phoenix::phoenix_domain, A0=boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<2>>, 0L>, A1=boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<boost::phoenix::argument<2>>, 0L>>]"" at line 184 of ""./boost/proto/make_expr.hpp""
            instantiation of class ""boost::proto::result_of::make_expr<Tag, Domain, A0, A1, A2, A3, A4, A5, A6, A7, A8, A9, Domain::proto_is_domain_> [with Tag=boost::proto::tagns_::tag::assign, Domain=boost::phoenix::phoenix_domain, A0=boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<2>>, 0L>, A1=boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,
                      boost::proto::argsns_::term<boost::phoenix::argument<2>>, 0L>>, A2=void, A3=void, A4=void, A5=void, A6=void, A7=void, A8=void, A9=void]"" at line 241 of ""./boost/proto/detail/preprocessed/basic_expr.hpp""
            instantiation of class ""boost::proto::exprns_::basic_expr<Tag, boost::proto::argsns_::list2<Arg0, Arg1>, 2L> [with Tag=boost::proto::tagns_::tag::assign, Arg0=boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<2>>, 0L>, Arg1=boost::log::v2_mt_posix::expressions::stream_type]"" at line 830 of ""./boost/proto/matches.hpp""
            instantiation of class ""boost::proto::switch_<Cases, boost::proto::tag_of<boost::proto::_> ()>::impl<Expr, State, Data> [with Cases=boost::phoenix::phoenix_generator, Expr=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<2>>, 0L>, boost::log::v2_mt_posix::expressions::stream_type>, 2L>,
                      State=boost::proto::envns_::empty_state={int}, Data=boost::proto::envns_::empty_env]"" at line 238 of ""./boost/proto/transform/impl.hpp""
            instantiation of class ""boost::proto::detail::apply_transform<PrimitiveTransform (Expr)> [with PrimitiveTransform=boost::phoenix::phoenix_generator, Expr=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<2>>, 0L>, boost::log::v2_mt_posix::expressions::stream_type>, 2L>]"" at line 255 of
                      ""./boost/proto/transform/impl.hpp""
            [ 7 instantiation contexts not shown ]
            instantiation of class ""boost::proto::detail::make_expr_<Tag, Domain, A0, A1, void, void, void, void, void, void, void, void, void> [with Tag=boost::proto::tagns_::tag::shift_left, Domain=boost::phoenix::phoenix_domain, A0=const boost::log::v2_mt_posix::expressions::stream_type &, A1=boost::log::v2_mt_posix::expressions::attribute_actor<boost::mpl::vector30<bool, char, wchar_t, signed char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long, long long,
                      unsigned long long, float, double, long double, std::string, boost::log::v2_mt_posix::string_literal, std::wstring, boost::log::v2_mt_posix::wstring_literal, boost::posix_time::ptime, boost::local_time::local_date_time, boost::posix_time::time_duration, boost::gregorian::date_duration, boost::posix_time::time_period, boost::local_time::local_time_period, boost::gregorian::date_period, boost::log::v2_mt_posix::attributes::named_scope_list,
                      boost::log::v2_mt_posix::aux::thread::id, boost::log::v2_mt_posix::aux::process::id>, boost::log::v2_mt_posix::fallback_to_none, void, boost::phoenix::actor> &]"" at line 184 of ""./boost/proto/make_expr.hpp""
            instantiation of class ""boost::proto::result_of::make_expr<Tag, Domain, A0, A1, A2, A3, A4, A5, A6, A7, A8, A9, Domain::proto_is_domain_> [with Tag=boost::proto::tagns_::tag::shift_left, Domain=boost::phoenix::phoenix_domain, A0=const boost::log::v2_mt_posix::expressions::stream_type &, A1=boost::log::v2_mt_posix::expressions::attribute_actor<boost::mpl::vector30<bool, char, wchar_t, signed char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long, long
                      long, unsigned long long, float, double, long double, std::string, boost::log::v2_mt_posix::string_literal, std::wstring, boost::log::v2_mt_posix::wstring_literal, boost::posix_time::ptime, boost::local_time::local_date_time, boost::posix_time::time_duration, boost::gregorian::date_duration, boost::posix_time::time_period, boost::local_time::local_time_period, boost::gregorian::date_period, boost::log::v2_mt_posix::attributes::named_scope_list,
                      boost::log::v2_mt_posix::aux::thread::id, boost::log::v2_mt_posix::aux::process::id>, boost::log::v2_mt_posix::fallback_to_none, void, boost::phoenix::actor> &, A2=void, A3=void, A4=void, A5=void, A6=void, A7=void, A8=void, A9=void]"" at line 40 of ""./boost/core/enable_if.hpp""
            instantiation of class ""boost::lazy_enable_if_c<B, T> [with B=true, T=boost::proto::result_of::make_expr<boost::proto::tagns_::tag::shift_left, boost::phoenix::phoenix_domain, const boost::log::v2_mt_posix::expressions::stream_type &, boost::log::v2_mt_posix::expressions::attribute_actor<boost::mpl::vector30<bool, char, wchar_t, signed char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long, long long, unsigned long long, float, double, long double,
                      std::string, boost::log::v2_mt_posix::string_literal, std::wstring, boost::log::v2_mt_posix::wstring_literal, boost::posix_time::ptime, boost::local_time::local_date_time, boost::posix_time::time_duration, boost::gregorian::date_duration, boost::posix_time::time_period, boost::local_time::local_time_period, boost::gregorian::date_period, boost::log::v2_mt_posix::attributes::named_scope_list, boost::log::v2_mt_posix::aux::thread::id,
                      boost::log::v2_mt_posix::aux::process::id>, boost::log::v2_mt_posix::fallback_to_none, void, boost::phoenix::actor> &, void, void, void, void, void, void, void, void, void>]"" at line 70 of ""./boost/proto/operators.hpp""
            instantiation of class ""boost::proto::detail::enable_binary<Domain, Grammar, Trait, Tag, Left, Right> [with Domain=boost::phoenix::phoenix_domain, Grammar=boost::phoenix::meta_grammar, Trait=boost::mpl::or_<boost::proto::is_extension<const boost::log::v2_mt_posix::expressions::stream_type>, boost::proto::is_extension<boost::log::v2_mt_posix::expressions::attribute_actor<boost::mpl::vector30<bool, char, wchar_t, signed char, unsigned char, short, unsigned short, int, unsigned int,
                      long, unsigned long, long long, unsigned long long, float, double, long double, std::string, boost::log::v2_mt_posix::string_literal, std::wstring, boost::log::v2_mt_posix::wstring_literal, boost::posix_time::ptime, boost::local_time::local_date_time, boost::posix_time::time_duration, boost::gregorian::date_duration, boost::posix_time::time_period, boost::local_time::local_time_period, boost::gregorian::date_period, boost::log::v2_mt_posix::attributes::named_scope_list,
                      boost::log::v2_mt_posix::aux::thread::id, boost::log::v2_mt_posix::aux::process::id>, boost::log::v2_mt_posix::fallback_to_none, void, boost::phoenix::actor>>, boost::mpl::bool_<false>, boost::mpl::bool_<false>, boost::mpl::bool_<false>>, Tag=boost::proto::tagns_::tag::shift_left, Left=const boost::log::v2_mt_posix::expressions::stream_type &, Right=boost::log::v2_mt_posix::expressions::attribute_actor<boost::mpl::vector30<bool, char, wchar_t, signed char, unsigned char,
                      short, unsigned short, int, unsigned int, long, unsigned long, long long, unsigned long long, float, double, long double, std::string, boost::log::v2_mt_posix::string_literal, std::wstring, boost::log::v2_mt_posix::wstring_literal, boost::posix_time::ptime, boost::local_time::local_date_time, boost::posix_time::time_duration, boost::gregorian::date_duration, boost::posix_time::time_period, boost::local_time::local_time_period, boost::gregorian::date_period,
                      boost::log::v2_mt_posix::attributes::named_scope_list, boost::log::v2_mt_posix::aux::thread::id, boost::log::v2_mt_posix::aux::process::id>, boost::log::v2_mt_posix::fallback_to_none, void, boost::phoenix::actor> &]"" at line 89 of ""./boost/proto/operators.hpp""
            instantiation of class ""boost::proto::detail::enable_binary<boost::proto::domainns_::deduce_domain, boost::proto::detail::not_a_grammar, Trait, Tag, Left &, Right &> [with Trait=boost::mpl::or_<boost::proto::is_extension<const boost::log::v2_mt_posix::expressions::stream_type>, boost::proto::is_extension<boost::log::v2_mt_posix::expressions::attribute_actor<boost::mpl::vector30<bool, char, wchar_t, signed char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned
                      long, long long, unsigned long long, float, double, long double, std::string, boost::log::v2_mt_posix::string_literal, std::wstring, boost::log::v2_mt_posix::wstring_literal, boost::posix_time::ptime, boost::local_time::local_date_time, boost::posix_time::time_duration, boost::gregorian::date_duration, boost::posix_time::time_period, boost::local_time::local_time_period, boost::gregorian::date_period, boost::log::v2_mt_posix::attributes::named_scope_list,
                      boost::log::v2_mt_posix::aux::thread::id, boost::log::v2_mt_posix::aux::process::id>, boost::log::v2_mt_posix::fallback_to_none, void, boost::phoenix::actor>>, boost::mpl::bool_<false>, boost::mpl::bool_<false>, boost::mpl::bool_<false>>, Tag=boost::proto::tagns_::tag::shift_left, Left=const boost::log::v2_mt_posix::expressions::stream_type, Right=boost::log::v2_mt_posix::expressions::attribute_actor<boost::mpl::vector30<bool, char, wchar_t, signed char, unsigned char,
                      short, unsigned short, int, unsigned int, long, unsigned long, long long, unsigned long long, float, double, long double, std::string, boost::log::v2_mt_posix::string_literal, std::wstring, boost::log::v2_mt_posix::wstring_literal, boost::posix_time::ptime, boost::local_time::local_date_time, boost::posix_time::time_duration, boost::gregorian::date_duration, boost::posix_time::time_period, boost::local_time::local_time_period, boost::gregorian::date_period,
                      boost::log::v2_mt_posix::attributes::named_scope_list, boost::log::v2_mt_posix::aux::thread::id, boost::log::v2_mt_posix::aux::process::id>, boost::log::v2_mt_posix::fallback_to_none, void, boost::phoenix::actor>]"" at line 82 of ""libs/log/src/default_formatter_factory.cpp""

compilation aborted for libs/log/src/default_formatter_factory.cpp (code 2)
...skipped <p/home/phprus/devel/build/deps/boost/boost/bin.v2/libs/log/build/intl-lnx-14.0/rls/bst.l-off/log-api-unx/pch-off/thrd-mlt>libboost_log_setup-il140-mt-1_58.so.1.58.0 for lack of <p/home/phprus/devel/build/deps/boost/boost/bin.v2/libs/log/build/intl-lnx-14.0/rls/bst.l-off/log-api-unx/pch-off/thrd-mlt>default_formatter_factory.o...
...skipped <p/home/phprus/devel/build/deps/i/lib64>libboost_log_setup-il140-mt-1_58.so.1.58.0 for lack of <p/home/phprus/devel/build/deps/boost/boost/bin.v2/libs/log/build/intl-lnx-14.0/rls/bst.l-off/log-api-unx/pch-off/thrd-mlt>libboost_log_setup-il140-mt-1_58.so.1.58.0...
}}}",phprus@…
11195,named_mufex creation error,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-04-17T10:13:51Z,2015-04-17T10:13:51Z,"When creating a named_mutex object under windows, if the event registry does not contain a record with id 6005 an inteprocess_exception is thrown by get_bootup_time function.
The attached sample works if event id 6005 exists but fails otherwise",trivelli.lorenzo@…
11194,named_mutex creation error,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-04-17T10:11:50Z,2015-04-17T13:49:20Z,"When creating a named_mutex object under windows, if the event registry does not contain a record with id 6005 an inteprocess_exception is thrown by get_bootup_time function.
The attached sample works if event id 6005 exists but fails otherwise",trivelli.lorenzo@…
11188,can not use repeat(int)[] with std::ref and phoenix::ref,spirit,Boost 1.58.0,To Be Determined,Bugs,Joel de Guzman,new,2015-04-14T08:37:31Z,2016-06-14T18:43:37Z,"Debian libboost-dev 1.55[[BR]]
When trying to compile a rule containing:

{{{
qi::repeat(std::ref(_n))[some_action]
}}}

the compiler complains:
/usr/include/boost/spirit/home/qi/directive/repeat.hpp:88:40: error: use of deleted function ‘std::reference_wrapper<_Tp>::reference_wrapper(_Tp&&) [with _Tp = int]’[[BR]]
T start() const { return '''type(0);''' }

In this situation qi:repeat (repeat.hpp:88:40) tries to create an iterator from[[BR]]
std::reference_wrapper<>(rhs_value) which is not possible as a reference is needed!

As a temporary workaround I used the following help type:

{{{
template<typename T>
class ref_rhs: public std::reference_wrapper<T> {
    private:
        T   _rhval;
    public:
        using std::reference_wrapper<T>::reference_wrapper; // inherit constructors

        ref_rhs(T&& rhs):
            std::reference_wrapper<T>(_rhval),
            _rhval(rhs)
        {}
};
}}}



and the call: qi::repeat(ref_rhs<T>(_n))[] works as expected.

May be qi:repeat should iterate internally with integers rather than with iterators as the documentation says that in the call qi::repeat(_n) _n must be convertible to int anyway.
",vveesskkoo@…
11187,size function causing hard errors in unrelated code,range,Boost Development Trunk,To Be Determined,Bugs,Neil Groves,new,2015-04-13T22:52:12Z,2015-04-14T08:01:20Z,"Consider the following innocuous-seeming program:

{{{
#include <boost/range.hpp>

namespace boost { struct some_type {}; }
template<typename T = boost::some_type>
struct S {};
void size(S<>) {}

int main()
{
    S<> s;
    size(s);
}
}}}


For me, with clang -std=gnu++14, I get this:

{{{
[100%] Building CXX object example/CMakeFiles/calendar.dir/calendar.cpp.o
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/begin.hpp:24:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/iterator.hpp:24:
/cygdrive/c/boost/org/modular-boost/boost/mpl/eval_if.hpp:60:26: error: no type named 'type' in 'boost::range_mutable_iterator<S<boost::some_type>, void>'
    typedef typename f_::type type;
            ~~~~~~~~~~~~~^~~~
/cygdrive/c/boost/org/modular-boost/boost/range/iterator.hpp:65:31: note: in instantiation of template class 'boost::mpl::eval_if_c<false, boost::range_const_iterator<S<boost::some_type>, void>, boost::range_mutable_iterator<S<boost::some_type>, void> >' requested here
        typedef typename mpl::eval_if_c<
                              ^
/cygdrive/c/boost/org/modular-boost/boost/range/difference_type.hpp:28:40: note: in instantiation of template class 'boost::range_iterator<S<boost::some_type>, void>' requested here
                BOOST_DEDUCED_TYPENAME range_iterator<
                                       ^
/cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:57:40: note: in instantiation of template class 'boost::range_difference<S<boost::some_type> >' requested here
                BOOST_DEDUCED_TYPENAME range_difference<C>::type
                                       ^
/cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:87:11: note: in instantiation of template class 'boost::detail::range_size<S<boost::some_type>, void>' requested here
        : detail::range_size<T>
          ^
/cygdrive/c/boost/org/modular-boost/boost/range/size.hpp:54:21: note: in instantiation of template class 'boost::range_size<const S<boost::some_type> >' requested here
    inline typename range_size<const SinglePassRange>::type
                    ^
/cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:44:5: note: while substituting deduced template arguments into function template 'size' [with SinglePassRange = S<boost::some_type>]
    size(s);
    ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/begin.hpp:24:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/iterator.hpp:24:
/cygdrive/c/boost/org/modular-boost/boost/mpl/eval_if.hpp:60:26: error: no type named 'type' in 'boost::range_const_iterator<S<boost::some_type>, void>'
    typedef typename f_::type type;
            ~~~~~~~~~~~~~^~~~
/cygdrive/c/boost/org/modular-boost/boost/range/iterator.hpp:65:31: note: in instantiation of template class 'boost::mpl::eval_if_c<true, boost::range_const_iterator<S<boost::some_type>, void>, boost::range_mutable_iterator<const S<boost::some_type>, void> >' requested here
        typedef typename mpl::eval_if_c<
                              ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:270:40: note: in instantiation of template class 'boost::range_iterator<const S<boost::some_type>, void>' requested here
        typedef BOOST_DEDUCED_TYPENAME range_iterator<
                                       ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:32:63: note: in instantiation of template class 'boost::SinglePassRangeConcept<S<boost::some_type> >' requested here
  inline yes has_constraints_(Model*, wrap_constraints<Model,&Model::constraints>* = 0);
                                                              ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:44:25: note: while substituting deduced template arguments into function template 'has_constraints_' [with Model = boost::SinglePassRangeConcept<S<boost::some_type> >]
      , value = sizeof( detail::has_constraints_((Model*)0) ) == sizeof(detail::yes) );
                        ^
/cygdrive/c/boost/org/modular-boost/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/if.hpp:63:68: note: in instantiation of template class 'boost::concepts::not_satisfied<boost::SinglePassRangeConcept<S<boost::some_type> > >' requested here
          BOOST_MPL_AUX_STATIC_CAST(bool, BOOST_MPL_AUX_VALUE_WKND(T1)::value)
                                                                   ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/value_wknd.hpp:57:40: note: expanded from macro 'BOOST_MPL_AUX_VALUE_WKND'
#   define BOOST_MPL_AUX_VALUE_WKND(C) C
                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/static_cast.hpp:24:62: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                                             ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:51:10: note: in instantiation of template class 'boost::mpl::if_<boost::concepts::not_satisfied<boost::SinglePassRangeConcept<S<boost::some_type> > >, boost::concepts::constraint<boost::SinglePassRangeConcept<S<boost::some_type> > >, boost::concepts::requirement<boost::concepts::failed ************boost::SinglePassRangeConcept<S<boost::some_type> >::************> >' requested here
  : mpl::if_<
         ^
/cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:90:9: note: in instantiation of template class 'boost::concepts::requirement_<void (*)(boost::SinglePassRangeConcept<S<boost::some_type> >)>' requested here
        BOOST_RANGE_CONCEPT_ASSERT((boost::SinglePassRangeConcept<T>));
        ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:102:45: note: expanded from macro 'BOOST_RANGE_CONCEPT_ASSERT'
    #define BOOST_RANGE_CONCEPT_ASSERT( x ) BOOST_CONCEPT_ASSERT( x )
                                            ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:25: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                        ^
/cygdrive/c/boost/org/modular-boost/boost/range/size.hpp:54:21: note: in instantiation of template class 'boost::range_size<const S<boost::some_type> >' requested here
    inline typename range_size<const SinglePassRange>::type
                    ^
/cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:44:5: note: while substituting deduced template arguments into function template 'size' [with SinglePassRange = S<boost::some_type>]
    size(s);
    ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:20:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/size.hpp:21:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:20:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:20:
In file included from /cygdrive/c/boost/org/modular-boost/boost/iterator/iterator_concepts.hpp:10:
/cygdrive/c/boost/org/modular-boost/boost/iterator/iterator_categories.hpp:119:60: error: no type named 'iterator_category' in 'std::iterator_traits<int>'
        typename boost::detail::iterator_traits<Iterator>::iterator_category
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:126:44: note: in instantiation of template class 'boost::iterators::iterator_traversal<int>' requested here
            typedef BOOST_DEDUCED_TYPENAME iterator_traversal<Iterator>::type traversal_category;
                                           ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:146:15: note: in instantiation of template class 'boost::range_detail::IncrementableIteratorConcept<int>' requested here
            : IncrementableIteratorConcept<Iterator>
              ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:32:63: note: in instantiation of template class 'boost::range_detail::SinglePassIteratorConcept<int>' requested here
  inline yes has_constraints_(Model*, wrap_constraints<Model,&Model::constraints>* = 0);
                                                              ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:44:25: note: while substituting deduced template arguments into function template 'has_constraints_' [with Model = boost::range_detail::SinglePassIteratorConcept<int>]
      , value = sizeof( detail::has_constraints_((Model*)0) ) == sizeof(detail::yes) );
                        ^
/cygdrive/c/boost/org/modular-boost/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/if.hpp:63:68: note: in instantiation of template class 'boost::concepts::not_satisfied<boost::range_detail::SinglePassIteratorConcept<int> >' requested here
          BOOST_MPL_AUX_STATIC_CAST(bool, BOOST_MPL_AUX_VALUE_WKND(T1)::value)
                                                                   ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/value_wknd.hpp:57:40: note: expanded from macro 'BOOST_MPL_AUX_VALUE_WKND'
#   define BOOST_MPL_AUX_VALUE_WKND(C) C
                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/static_cast.hpp:24:62: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                                             ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:51:10: note: in instantiation of template class 'boost::mpl::if_<boost::concepts::not_satisfied<boost::range_detail::SinglePassIteratorConcept<int> >, boost::concepts::constraint<boost::range_detail::SinglePassIteratorConcept<int> >, boost::concepts::requirement<boost::concepts::failed ************boost::range_detail::SinglePassIteratorConcept<int>::************> >' requested here
  : mpl::if_<
         ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:276:9: note: in instantiation of template class 'boost::concepts::requirement_<void (*)(boost::range_detail::SinglePassIteratorConcept<int>)>' requested here
        BOOST_RANGE_CONCEPT_ASSERT((
        ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:102:45: note: expanded from macro 'BOOST_RANGE_CONCEPT_ASSERT'
    #define BOOST_RANGE_CONCEPT_ASSERT( x ) BOOST_CONCEPT_ASSERT( x )
                                            ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:25: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                        ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:32:63: note: in instantiation of template class 'boost::SinglePassRangeConcept<S<boost::some_type> >' requested here
  inline yes has_constraints_(Model*, wrap_constraints<Model,&Model::constraints>* = 0);
                                                              ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:44:25: note: while substituting deduced template arguments into function template 'has_constraints_' [with Model = boost::SinglePassRangeConcept<S<boost::some_type> >]
      , value = sizeof( detail::has_constraints_((Model*)0) ) == sizeof(detail::yes) );
                        ^
/cygdrive/c/boost/org/modular-boost/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/if.hpp:63:68: note: in instantiation of template class 'boost::concepts::not_satisfied<boost::SinglePassRangeConcept<S<boost::some_type> > >' requested here
          BOOST_MPL_AUX_STATIC_CAST(bool, BOOST_MPL_AUX_VALUE_WKND(T1)::value)
                                                                   ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/value_wknd.hpp:57:40: note: expanded from macro 'BOOST_MPL_AUX_VALUE_WKND'
#   define BOOST_MPL_AUX_VALUE_WKND(C) C
                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/static_cast.hpp:24:62: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                                             ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:51:10: note: in instantiation of template class 'boost::mpl::if_<boost::concepts::not_satisfied<boost::SinglePassRangeConcept<S<boost::some_type> > >, boost::concepts::constraint<boost::SinglePassRangeConcept<S<boost::some_type> > >, boost::concepts::requirement<boost::concepts::failed ************boost::SinglePassRangeConcept<S<boost::some_type> >::************> >' requested here
  : mpl::if_<
         ^
/cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:90:9: note: in instantiation of template class 'boost::concepts::requirement_<void (*)(boost::SinglePassRangeConcept<S<boost::some_type> >)>' requested here
        BOOST_RANGE_CONCEPT_ASSERT((boost::SinglePassRangeConcept<T>));
        ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:102:45: note: expanded from macro 'BOOST_RANGE_CONCEPT_ASSERT'
    #define BOOST_RANGE_CONCEPT_ASSERT( x ) BOOST_CONCEPT_ASSERT( x )
                                            ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:25: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                        ^
/cygdrive/c/boost/org/modular-boost/boost/range/size.hpp:54:21: note: in instantiation of template class 'boost::range_size<const S<boost::some_type> >' requested here
    inline typename range_size<const SinglePassRange>::type
                    ^
/cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:44:5: note: while substituting deduced template arguments into function template 'size' [with SinglePassRange = S<boost::some_type>]
    size(s);
    ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:20:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/size.hpp:21:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:20:
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:152:71: error: no type named 'traversal_category' in 'boost::range_detail::SinglePassIteratorConcept<int>'
                    BOOST_DEDUCED_TYPENAME SinglePassIteratorConcept::traversal_category,
                                                                      ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:102:67: note: expanded from macro 'BOOST_RANGE_CONCEPT_ASSERT'
    #define BOOST_RANGE_CONCEPT_ASSERT( x ) BOOST_CONCEPT_ASSERT( x )
                                                                  ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:36: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
                                   ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:38: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                                     ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:32:63: note: in instantiation of template class 'boost::range_detail::SinglePassIteratorConcept<int>' requested here
  inline yes has_constraints_(Model*, wrap_constraints<Model,&Model::constraints>* = 0);
                                                              ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:44:25: note: while substituting deduced template arguments into function template 'has_constraints_' [with Model = boost::range_detail::SinglePassIteratorConcept<int>]
      , value = sizeof( detail::has_constraints_((Model*)0) ) == sizeof(detail::yes) );
                        ^
/cygdrive/c/boost/org/modular-boost/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/if.hpp:63:68: note: in instantiation of template class 'boost::concepts::not_satisfied<boost::range_detail::SinglePassIteratorConcept<int> >' requested here
          BOOST_MPL_AUX_STATIC_CAST(bool, BOOST_MPL_AUX_VALUE_WKND(T1)::value)
                                                                   ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/value_wknd.hpp:57:40: note: expanded from macro 'BOOST_MPL_AUX_VALUE_WKND'
#   define BOOST_MPL_AUX_VALUE_WKND(C) C
                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/static_cast.hpp:24:62: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                                             ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:51:10: note: in instantiation of template class 'boost::mpl::if_<boost::concepts::not_satisfied<boost::range_detail::SinglePassIteratorConcept<int> >, boost::concepts::constraint<boost::range_detail::SinglePassIteratorConcept<int> >, boost::concepts::requirement<boost::concepts::failed ************boost::range_detail::SinglePassIteratorConcept<int>::************> >' requested here
  : mpl::if_<
         ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:276:9: note: in instantiation of template class 'boost::concepts::requirement_<void (*)(boost::range_detail::SinglePassIteratorConcept<int>)>' requested here
        BOOST_RANGE_CONCEPT_ASSERT((
        ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:102:45: note: expanded from macro 'BOOST_RANGE_CONCEPT_ASSERT'
    #define BOOST_RANGE_CONCEPT_ASSERT( x ) BOOST_CONCEPT_ASSERT( x )
                                            ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:25: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                        ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:32:63: note: in instantiation of template class 'boost::SinglePassRangeConcept<S<boost::some_type> >' requested here
  inline yes has_constraints_(Model*, wrap_constraints<Model,&Model::constraints>* = 0);
                                                              ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/has_constraints.hpp:44:25: note: while substituting deduced template arguments into function template 'has_constraints_' [with Model = boost::SinglePassRangeConcept<S<boost::some_type> >]
      , value = sizeof( detail::has_constraints_((Model*)0) ) == sizeof(detail::yes) );
                        ^
/cygdrive/c/boost/org/modular-boost/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/if.hpp:63:68: note: in instantiation of template class 'boost::concepts::not_satisfied<boost::SinglePassRangeConcept<S<boost::some_type> > >' requested here
          BOOST_MPL_AUX_STATIC_CAST(bool, BOOST_MPL_AUX_VALUE_WKND(T1)::value)
                                                                   ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/value_wknd.hpp:57:40: note: expanded from macro 'BOOST_MPL_AUX_VALUE_WKND'
#   define BOOST_MPL_AUX_VALUE_WKND(C) C
                                       ^
/cygdrive/c/boost/org/modular-boost/boost/mpl/aux_/static_cast.hpp:24:62: note: expanded from macro 'BOOST_MPL_AUX_STATIC_CAST'
#   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast<T>(expr)
                                                             ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:51:10: note: in instantiation of template class 'boost::mpl::if_<boost::concepts::not_satisfied<boost::SinglePassRangeConcept<S<boost::some_type> > >, boost::concepts::constraint<boost::SinglePassRangeConcept<S<boost::some_type> > >, boost::concepts::requirement<boost::concepts::failed ************boost::SinglePassRangeConcept<S<boost::some_type> >::************> >' requested here
  : mpl::if_<
         ^
/cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:90:9: note: in instantiation of template class 'boost::concepts::requirement_<void (*)(boost::SinglePassRangeConcept<S<boost::some_type> >)>' requested here
        BOOST_RANGE_CONCEPT_ASSERT((boost::SinglePassRangeConcept<T>));
        ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:102:45: note: expanded from macro 'BOOST_RANGE_CONCEPT_ASSERT'
    #define BOOST_RANGE_CONCEPT_ASSERT( x ) BOOST_CONCEPT_ASSERT( x )
                                            ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:25: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                        ^
/cygdrive/c/boost/org/modular-boost/boost/range/size.hpp:54:21: note: in instantiation of template class 'boost::range_size<const S<boost::some_type> >' requested here
    inline typename range_size<const SinglePassRange>::type
                    ^
/cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:44:5: note: while substituting deduced template arguments into function template 'size' [with SinglePassRange = S<boost::some_type>]
    size(s);
    ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:20:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/size.hpp:21:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:20:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:19:
/cygdrive/c/boost/org/modular-boost/boost/concept_check.hpp:210:9: error: no viable conversion from 'int' to 'boost::iterators::incrementable_traversal_tag'
      Y y = x;
        ^   ~
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:16:43: note: in instantiation of member function 'boost::Convertible<int, boost::iterators::incrementable_traversal_tag>::~Convertible' requested here
    ~usage_requirements() { ((Model*)0)->~Model(); }
                                          ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:38:42: note: in instantiation of member function 'boost::concepts::usage_requirements<boost::Convertible<int, boost::iterators::incrementable_traversal_tag> >::~usage_requirements' requested here
    static void failed() { ((Model*)0)->~Model(); }
                                         ^
/cygdrive/c/boost/org/modular-boost/boost/concept_check.hpp:209:5: note: in instantiation of member function 'boost::concepts::requirement<boost::concepts::failed ************boost::concepts::usage_requirements<boost::Convertible<int, boost::iterators::incrementable_traversal_tag> >::************>::failed' requested here
    BOOST_CONCEPT_USAGE(Convertible) {
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:29:7: note: expanded from macro 'BOOST_CONCEPT_USAGE'
      BOOST_CONCEPT_ASSERT((boost::concepts::usage_requirements<model>)); \
      ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:51: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                                                  ^
/cygdrive/c/boost/org/modular-boost/boost/iterator/iterator_categories.hpp:33:8: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const boost::iterators::incrementable_traversal_tag &' for 1st argument
struct incrementable_traversal_tag
       ^
/cygdrive/c/boost/org/modular-boost/boost/iterator/iterator_categories.hpp:33:8: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to 'boost::iterators::incrementable_traversal_tag &&' for 1st argument
struct incrementable_traversal_tag
       ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:20:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/size.hpp:21:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/size_type.hpp:20:
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:167:82: error: no type named 'reference' in 'std::iterator_traits<int>'
                BOOST_DEDUCED_TYPENAME boost::detail::iterator_traits<Iterator>::reference r1(*i);
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:16:43: note: in instantiation of member function 'boost::range_detail::SinglePassIteratorConcept<int>::~SinglePassIteratorConcept' requested here
    ~usage_requirements() { ((Model*)0)->~Model(); }
                                          ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:38:42: note: in instantiation of member function 'boost::concepts::usage_requirements<boost::range_detail::SinglePassIteratorConcept<int> >::~usage_requirements' requested here
    static void failed() { ((Model*)0)->~Model(); }
                                         ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:156:13: note: in instantiation of member function 'boost::concepts::requirement<boost::concepts::failed ************boost::concepts::usage_requirements<boost::range_detail::SinglePassIteratorConcept<int> >::************>::failed' requested here
            BOOST_CONCEPT_USAGE(SinglePassIteratorConcept)
            ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:29:7: note: expanded from macro 'BOOST_CONCEPT_USAGE'
      BOOST_CONCEPT_ASSERT((boost::concepts::usage_requirements<model>)); \
      ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:51: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                                                  ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:18:
/cygdrive/c/boost/org/modular-boost/boost/range/begin.hpp:47:18: error: no member named 'begin' in 'S<boost::some_type>'
        return c.begin();
               ~ ^
/cygdrive/c/boost/org/modular-boost/boost/range/begin.hpp:102:12: note: in instantiation of function template specialization 'boost::range_detail::range_begin<S<boost::some_type> >' requested here
    return range_begin( r );
           ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:287:34: note: in instantiation of function template specialization 'boost::range_adl_barrier::begin<S<boost::some_type> >' requested here
            iterator i1 = boost::begin(*m_range);
                                 ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:16:43: note: in instantiation of member function 'boost::SinglePassRangeConcept<S<boost::some_type> >::~SinglePassRangeConcept' requested here
    ~usage_requirements() { ((Model*)0)->~Model(); }
                                          ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:38:42: note: in instantiation of member function 'boost::concepts::usage_requirements<boost::SinglePassRangeConcept<S<boost::some_type> > >::~usage_requirements' requested here
    static void failed() { ((Model*)0)->~Model(); }
                                         ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:282:9: note: in instantiation of member function 'boost::concepts::requirement<boost::concepts::failed ************boost::concepts::usage_requirements<boost::SinglePassRangeConcept<S<boost::some_type> > >::************>::failed' requested here
        BOOST_CONCEPT_USAGE(SinglePassRangeConcept)
        ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:29:7: note: expanded from macro 'BOOST_CONCEPT_USAGE'
      BOOST_CONCEPT_ASSERT((boost::concepts::usage_requirements<model>)); \
      ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:51: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                                                  ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:19:
/cygdrive/c/boost/org/modular-boost/boost/range/end.hpp:48:22: error: no member named 'end' in 'S<boost::some_type>'
            return c.end();
                   ~ ^
/cygdrive/c/boost/org/modular-boost/boost/range/end.hpp:96:12: note: in instantiation of function template specialization 'boost::range_detail::range_end<S<boost::some_type> >' requested here
    return range_end( r );
           ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:288:34: note: in instantiation of function template specialization 'boost::range_adl_barrier::end<S<boost::some_type> >' requested here
            iterator i2 = boost::end(*m_range);
                                 ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:16:43: note: in instantiation of member function 'boost::SinglePassRangeConcept<S<boost::some_type> >::~SinglePassRangeConcept' requested here
    ~usage_requirements() { ((Model*)0)->~Model(); }
                                          ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:38:42: note: in instantiation of member function 'boost::concepts::usage_requirements<boost::SinglePassRangeConcept<S<boost::some_type> > >::~usage_requirements' requested here
    static void failed() { ((Model*)0)->~Model(); }
                                         ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:282:9: note: in instantiation of member function 'boost::concepts::requirement<boost::concepts::failed ************boost::concepts::usage_requirements<boost::SinglePassRangeConcept<S<boost::some_type> > >::************>::failed' requested here
        BOOST_CONCEPT_USAGE(SinglePassRangeConcept)
        ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:29:7: note: expanded from macro 'BOOST_CONCEPT_USAGE'
      BOOST_CONCEPT_ASSERT((boost::concepts::usage_requirements<model>)); \
      ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:51: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                                                  ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:18:
/cygdrive/c/boost/org/modular-boost/boost/range/begin.hpp:47:18: error: no member named 'begin' in 'S<boost::some_type>'
        return c.begin();
               ~ ^
/cygdrive/c/boost/org/modular-boost/boost/range/begin.hpp:111:12: note: in instantiation of function template specialization 'boost::range_detail::range_begin<const S<boost::some_type> >' requested here
    return range_begin( r );
           ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:299:41: note: in instantiation of function template specialization 'boost::range_adl_barrier::begin<S<boost::some_type> >' requested here
            const_iterator ci1 = boost::begin(const_range);
                                        ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:293:13: note: in instantiation of member function 'boost::SinglePassRangeConcept<S<boost::some_type> >::const_constraints' requested here
            const_constraints(*m_range);
            ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:16:43: note: in instantiation of member function 'boost::SinglePassRangeConcept<S<boost::some_type> >::~SinglePassRangeConcept' requested here
    ~usage_requirements() { ((Model*)0)->~Model(); }
                                          ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:38:42: note: in instantiation of member function 'boost::concepts::usage_requirements<boost::SinglePassRangeConcept<S<boost::some_type> > >::~usage_requirements' requested here
    static void failed() { ((Model*)0)->~Model(); }
                                         ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:282:9: note: in instantiation of member function 'boost::concepts::requirement<boost::concepts::failed ************boost::concepts::usage_requirements<boost::SinglePassRangeConcept<S<boost::some_type> > >::************>::failed' requested here
        BOOST_CONCEPT_USAGE(SinglePassRangeConcept)
        ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:29:7: note: expanded from macro 'BOOST_CONCEPT_USAGE'
      BOOST_CONCEPT_ASSERT((boost::concepts::usage_requirements<model>)); \
      ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:51: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                                                  ^
In file included from /cygdrive/c/Users/eric/Code/range-v3/example/calendar.cpp:34:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range.hpp:18:
In file included from /cygdrive/c/boost/org/modular-boost/boost/range/functions.hpp:19:
/cygdrive/c/boost/org/modular-boost/boost/range/end.hpp:48:22: error: no member named 'end' in 'S<boost::some_type>'
            return c.end();
                   ~ ^
/cygdrive/c/boost/org/modular-boost/boost/range/end.hpp:105:12: note: in instantiation of function template specialization 'boost::range_detail::range_end<const S<boost::some_type> >' requested here
    return range_end( r );
           ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:300:41: note: in instantiation of function template specialization 'boost::range_adl_barrier::end<S<boost::some_type> >' requested here
            const_iterator ci2 = boost::end(const_range);
                                        ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:293:13: note: in instantiation of member function 'boost::SinglePassRangeConcept<S<boost::some_type> >::const_constraints' requested here
            const_constraints(*m_range);
            ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:16:43: note: in instantiation of member function 'boost::SinglePassRangeConcept<S<boost::some_type> >::~SinglePassRangeConcept' requested here
    ~usage_requirements() { ((Model*)0)->~Model(); }
                                          ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:38:42: note: in instantiation of member function 'boost::concepts::usage_requirements<boost::SinglePassRangeConcept<S<boost::some_type> > >::~usage_requirements' requested here
    static void failed() { ((Model*)0)->~Model(); }
                                         ^
/cygdrive/c/boost/org/modular-boost/boost/range/concepts.hpp:282:9: note: in instantiation of member function 'boost::concepts::requirement<boost::concepts::failed ************boost::concepts::usage_requirements<boost::SinglePassRangeConcept<S<boost::some_type> > >::************>::failed' requested here
        BOOST_CONCEPT_USAGE(SinglePassRangeConcept)
        ^
/cygdrive/c/boost/org/modular-boost/boost/concept/usage.hpp:29:7: note: expanded from macro 'BOOST_CONCEPT_USAGE'
      BOOST_CONCEPT_ASSERT((boost::concepts::usage_requirements<model>)); \
      ^
/cygdrive/c/boost/org/modular-boost/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/cygdrive/c/boost/org/modular-boost/boost/concept/detail/general.hpp:78:51: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                                                  ^
10 errors generated.
example/CMakeFiles/calendar.dir/build.make:54: recipe for target 'example/CMakeFiles/calendar.dir/calendar.cpp.o' failed
make[3]: *** [example/CMakeFiles/calendar.dir/calendar.cpp.o] Error 1
CMakeFiles/Makefile2:5748: recipe for target 'example/CMakeFiles/calendar.dir/all' failed
make[2]: *** [example/CMakeFiles/calendar.dir/all] Error 2
CMakeFiles/Makefile2:5760: recipe for target 'example/CMakeFiles/calendar.dir/rule' failed
make[1]: *** [example/CMakeFiles/calendar.dir/rule] Error 2
Makefile:2083: recipe for target 'calendar' failed
make: *** [calendar] Error 2
}}}",Eric Niebler
11186,the certificate for svn.boost.org has expired,website,Boost 1.57.0,To Be Determined,Bugs,René Rivera,new,2015-04-13T21:24:34Z,2015-08-14T01:15:24Z,The certificate svn.boost.org uses (appears to be a wildcard for *.boost.org) expired on 03/21/2015. Please update it.,dkeeler@…
11184,boost::asio::async_read_until() not usable on (at least) VC++ 2013,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-04-12T00:05:35Z,2015-04-28T14:59:57Z,"parameter 2 of boost::asio::async_read_until is a boost::asio::basic_streambuf<Allocator>& - examples even show that you can declare a boost::asio::streambuf lvalue and pass it in.

However, doing so and attempting to compile results in the following error:

\boost\boost\asio\detail\buffer_sequence_adapter.hpp(111): error C2664: 'boost::asio::const_buffer::const_buffer(const boost::asio::const_buffer &)' : cannot convert argument 1 from 'const char' to 'const boost::asio::mutable_buffer &'
1>          Reason: cannot convert from 'const char' to 'const boost::asio::mutable_buffer'
1>          No constructor could take the source type, or constructor overload resolution was ambiguous
1>          \boost\asio\detail\buffer_sequence_adapter.hpp(104) : while compiling class template member function 'boost::asio::detail::buffer_sequence_adapter<boost::asio::const_buffer,ConstBufferSequence>::buffer_sequence_adapter(const Buffers &)'",anonymous
11183,boost::asio::async_read_until() not usable on (at least) VC++ 2013,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-04-12T00:03:24Z,2015-04-12T00:45:08Z,"parameter 2 of boost::asio::async_read_until is a boost::asio::basic_streambuf<Allocator>& - examples even show that you can declare a boost::asio::streambuf lvalue and pass it in.

However, doing so and attempting to compile results in the following error:

\boost\boost\asio\detail\buffer_sequence_adapter.hpp(111): error C2664: 'boost::asio::const_buffer::const_buffer(const boost::asio::const_buffer &)' : cannot convert argument 1 from 'const char' to 'const boost::asio::mutable_buffer &'
1>          Reason: cannot convert from 'const char' to 'const boost::asio::mutable_buffer'
1>          No constructor could take the source type, or constructor overload resolution was ambiguous
1>          \boost\asio\detail\buffer_sequence_adapter.hpp(104) : while compiling class template member function 'boost::asio::detail::buffer_sequence_adapter<boost::asio::const_buffer,ConstBufferSequence>::buffer_sequence_adapter(const Buffers &)'",olipro@…
11182,Iostreams can't find symbol only on OSX,iostreams,Boost 1.57.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-04-11T16:34:04Z,2018-02-12T03:49:08Z,"'''System''': Darwin Kernel Version 14.3.0

'''Compiler''': GCC 4.9

'''Boost version''': Tried with 1.55, 1.57, 1.58-beta, boost-trunk of today

'''Minimal example''':

{{{
#include <boost/iostreams/device/file_descriptor.hpp>
#include <boost/iostreams/stream.hpp>

int main () {
  boost::iostreams::stream<boost::iostreams::file_descriptor> fdstream;
  return 0;
}
}}}

'''Outcome''':

{{{
$ /usr/local/bin/g++-4.9 -I /opt/boost/include/ -L /opt/boost/lib/ -lboost_iostreams -o foo foo.cpp
Undefined symbols for architecture x86_64:
  ""boost::iostreams::file_descriptor::seek(long, std::_Ios_Seekdir)"", referenced from:
      std::fpos<__mbstate_t> boost::iostreams::detail::seek_device_impl<boost::iostreams::any_tag>::seek<boost::iostreams::file_descriptor>(boost::iostreams::file_descriptor&, long, std::_Ios_Seekdir, std::_Ios_Openmode) in ccr82hhn.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
}}}",a.santini@…
11181,"Header conflict ""using-declaration causes a multiple declaration of 'boost::iterators::use_default'""",xpressive,Boost.Build-M3,Website 1.X,Library Submissions,Steven Watanabe,reopened,2015-04-10T11:00:17Z,2016-11-03T21:56:28Z,"I got ""using-declaration causes a multiple declaration of 'boost::iterators::use_default'"" error in my msvc. To reproduce bug you must create test.cpp with following text:

{{{
//test.cpp
#include <boost/type_erasure/iterator.hpp>
#include <boost/assign.hpp>
}}}

PS
BUG appears only in boost 1.57.0, in older versions (for example 1.55.0) code compiles without errors.
",fsmoke@…
11180,has_set_intersection,algorithm,Boost 1.57.0,To Be Determined,Feature Requests,Marshall Clow,new,2015-04-10T10:36:15Z,2017-05-12T08:05:01Z,"We sometimes have the requirement that we are only interested if two ranges have overlap. While in general for ranges this is somewhat difficult, for sorted ranges it seems easy:

template<class In1, class In2, class BinaryPredicate> 
bool has_set_intersection(In1 itFirst1, In1 itLast1, In2 itFirst2, In2 itLast2, BinaryPredicate comp)
{
    bool bOverlap = false;

    while (itFirst1 != itLast1 && itFirst2 != itLast2)
    {
        if (comp(*itFirst1, *itFirst2))
        {
            ++itFirst1;
        }
        else if (comp(*itFirst2, *itFirst1))
        {
            ++itFirst2;
        }
        else
        {
            bOverlap = true;
            break;
        }
    }

    return bOverlap;
}

Ofc this can be achieved with the normal set_intersection as well but that loops until the end of one of the ranges and requires an extra output iterator functor.

Maybe an idea?",gast128@…
11179,create_directories() does not allow control of permissions,filesystem,Boost 1.57.0,To Be Determined,Feature Requests,Beman Dawes,new,2015-04-10T00:42:02Z,2015-12-02T08:29:51Z,"Currently, there is no way to tell create_directory() or create_directories() what permissions to set for a new directory. This is particularly annoying when calling these functions from a library, where it's simply impossible to fiddle with umask.

It would be really nice to have an overload that allows permissions to be set.",Michi Henning <michi.henning@…>
11178,cpp_dec_float calculation bug,multiprecision,Boost 1.57.0,To Be Determined,Bugs,John Maddock,new,2015-04-09T17:01:00Z,2015-04-09T17:24:41Z,"#include <iostream>

#include <boost/multiprecision/cpp_dec_float.hpp>

using namespace boost::multiprecision;
using namespace std;

int main(int argc, char *argv[]) {
    cpp_dec_float_100 p(""4.5"");
    cpp_dec_float_100 a(""7.2"");

    cpp_dec_float_100 r = p / a;//(""0.625"");
    cout << r.str() << endl;

    if (r == cpp_dec_float_100(""0.625"")) cout << ""HOHO"" << endl;
    cout << r.str(2, ios_base::fixed) << endl;

    r *= 100;
    cout << r.str(2, ios_base::fixed) << endl;
    r = round(r);
    cout << r.str(2, ios_base::fixed) << endl;
    r /= 100;

    cout << r.str(2, ios_base::fixed) << endl;

    return 0;
}",nxjiang1@…
11172,Posix semaphores wait/timed_wait under linux and EINTR return code,interprocess,Boost 1.58.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-04-07T12:06:17Z,2015-04-08T12:38:35Z,"Semaphore's wait/timed_wait methods throws exception if EINTR is returned by sem_wait/sem_timedwait. This code could be returned if wait is interrupted by signal handler (in agree with POSIX.1-2001).

It looks like EINTR handling should be kept inside that functions.",poroh1981@…
11169,boost::optional triggers -Wmaybe-uninitialized errors in g++,optional,Boost 1.57.0,To Be Determined,Bugs,Fernando Cacciola,new,2015-04-06T16:24:34Z,2016-09-19T07:38:03Z,"Example taken from StackOverflow question 21755206*

{{{
#include <boost/optional.hpp>

::boost::optional<int> getitem();

int go(int nr)
{
  boost::optional<int> a = getitem();
  boost::optional<int> b;

  if (nr > 0)
    b = nr;

  if (a != b)
    return 1;

  return 0;
}
}}}


{{{
g++ -c -O2 -Wall /tmp/test.cpp
/tmp/test.cpp: In function ‘int go(int)’
/tmp/test.cpp:13:3: warning: ‘*((void*)& b +4)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   if (a != b)
   ^
}}}


This has been reported as gcc bug 47679*.

Two workarounds that seem to work in my testing are value-initializing dummy_ in the aligned_storage default constructor or adding an empty asm statement that lists dummy_ as an output. Would it be possible to include a fix in mainline boost?

* Sorry, but trac flags this as spam if I include direct links.",Mathias Stearn <redbeard0531@…>
11167,auto_cpu_timer reports questionable CPU utilization,timer,Boost 1.57.0,To Be Determined,Bugs,Beman Dawes,new,2015-04-04T18:12:31Z,2015-04-04T18:12:31Z,"Userspace time exceeds wall time showing >100% CPU utilization on OSX :
0.011577s wall, 0.020000s user + 0.000000s system = 0.020000s CPU (172.8%)

I have not seen any fractional values for userspace time, it looks like it can only increase in 0.01s intervals causing the incorrect print out above.

-------------------------------
#include <iostream>
#include <vector>
#include <boost/timer/timer.hpp>

int main(int argc, const char * argv[]) {
    std::vector<float> hv( 1000*1000 );
    {
        boost::timer::auto_cpu_timer t;
        std::generate(hv.begin(), hv.end(), rand);
    }
    return 0;
}",grubertm@…
11164,"Graph adjacency_list, add_vertex compile error on clang 3.6",graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-04-02T21:19:51Z,2016-02-03T00:24:39Z,"I have an issue similar to #10382. When compiling the following program

{{{
#include <boost/graph/adjacency_list.hpp>

struct Payload {
        Payload() = default;
        Payload(const Payload&) {};
        Payload& operator=(const Payload&) { return *this; };
};

struct PayloadD : public Payload {
};

class Props {
  public:
    PayloadD payload;
};

int main(int argc, char** argv)
{
  using boost::adjacency_list;
  using boost::vecS;
  using boost::directedS;
  typedef adjacency_list<vecS, vecS, directedS, Props> Graph;

  Graph graph;
  boost::add_vertex(graph);

  return 0;
}
}}}

Using clang 3.6 I get the error message:

{{{
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../include/c++/4.9.2/bits/stl_construct.h:75:38: error: call to implicitly-deleted copy constructor of 'boost::detail::stored_edge_property<unsigned long, boost::no_property>'
    { ::new(static_cast<void*>(__p)) _T1(std::forward<_Args>(__args)...); }

...

/usr/include/boost/graph/detail/adjacency_list.hpp:317:7: note: copy constructor is implicitly deleted because 'stored_edge_property<unsigned long, boost::no_property>' has a user-declared move constructor
      stored_edge_property(self&& x) = default;
}}}

The same program compiles fine with gcc 4.8.2, 4.9.2, and clang 3.5.

The attached patch changes stored_edge_property such that it always creates a custom copy constructor and copy assignment operator. With this changes clang 3.6 can build the program.",dstoeckel@…
11156,"Missing boost library ""libboost_zlib-vc120-mt-gd-1_57.lib""",iostreams,Boost 1.57.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-03-31T00:38:31Z,2015-03-31T01:04:15Z,"Hello!

Libraries are built under VC++ 12.0[[BR]]
Proven methods of build:
1. bjam toolset=msvc variant=debug,release link=static runtime-link=static
2. bjam toolset=msvc link=static threading=multi release stage
   bjam toolset=msvc link=static threading=multi debug stage
3. like this: http://stackoverflow.com/questions/7282645/how-to-build-boost-iostreams-with-gzip-and-bzip2-support-on-windows

The project had been prescribed library paths.
No one method helped get the library ""libboost_zlib-vc120-mt-gd-1_57.lib"" and in the folder ""boost/stage/lib"" this file does not exist.

Documentation: http://www.boost.org/doc/libs/1_40_0/libs/iostreams/doc/classes/gzip.html

The program, which would like to compile:
{{{
#define _SCL_SECURE_NO_WARNINGS
#include <string>
#include <iostream>
#include <fstream>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/filter/zlib.hpp>
#include <boost/iostreams/filter/gzip.hpp>
#include <boost/iostreams/device/file.hpp>
#include <boost/iostreams/copy.hpp>

int main(void) {
	boost::iostreams::filtering_ostreambuf out;
	out.push(boost::iostreams::gzip_compressor());
	out.push(boost::iostreams::file_sink(""data.txt"", std::ios::binary));
	boost::iostreams::copy(boost::iostreams::file_source(""data.gz"", std::ios::binary), out);
	return 0;
}
}}}",Vit.link420@…
11154,Constructing boost::interprocess::interprocess_semaphore throws in MacOS 10.9.5,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-03-30T17:11:38Z,2018-05-21T19:14:02Z,"Using boost::interprocess::interprocess_semaphore from Boost 1.56 and running MacOS 10.9.5, it simply throws an exception saying the function is not implemented:

    libc++abi.dylib: terminating with uncaught exception of type boost::interprocess::interprocess_exception: Function not implemented

This is a regression from Boost 1.49 and MacOS 10.9.5, where this works fine.

Looking at the two, it appears that 1.49 is using the generic spin emulation for interprocess_semaphore, whereas 1.56 is implementing interprocess_semaphore using POSIX unnamed semaphores, which aren't implemented in MacOS 10.9.5.",Jonathan Jones <jonathan.jones@…>
11146,iostreams seekpos/seekoff must not throw exceptions,iostreams,Boost 1.57.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-03-26T16:23:37Z,2015-03-26T16:23:37Z,"Currently, `direct_streambuf<T, Tr>::seek_impl` throws `bad_seek()` exception on invalid input.

The current standard draft N4296 says in section 27.8.2.4 about `seekoff`:

''If the positioning operation fails, or if the constructed object cannot represent the resultant stream position, the return value is pos_type(off_type(-1)).''

At least the MSVC STL implementation does not expect pubseekoff/seekoff to throw, thus does not catch the exception and the bad_seek() exception may leak to the caller even though ios_base::exceptions() is 0.
",stheophil@…
11144,Kamada Kawai graph layout algorithm crashes with MSVC 2013 with -O2,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-03-25T12:34:32Z,2015-03-25T12:34:32Z,"The attached file demonstrates a crash which only occurs when compiled with optimizations enabled. When compiling in debug the incorrect code path shown in the stack trace is not chosen.

A full compile output to show the exact compile options used is also included.",alex@…
11138,filesystem::path::canonical() failed with junction points on Windows,filesystem,Boost 1.57.0,To Be Determined,Bugs,Beman Dawes,new,2015-03-24T14:48:38Z,2017-07-19T18:28:41Z,"Hi, 

In my recent use of filesystem in Boost 1.57, the call of path::canonical() on Windows 7 returns an invalid path if part of the path in question is a junction point.  

This failure can be reproduced with the following code: 
{{{#!C++
  // ""C:\Gehua"" is a junction point of ""D:\Gehua""
  fs::path work(""d:/Gehua/work"");
  fs::path work_canonical(fs::canonical(work));
  std::wstring s = fs::canonical(work_canonical).native();
  // True path passes
  assert(s == L""d:/Gehua\\work"");

  // try the junction path 
  fs::path work_junction(""c:/Gehua/work"");
  // this passes
  assert(fs::exists(work_junction));

  s = fs::canonical(work_junction).native();
  // this one fails!
  // s has value ""c:/Gehua\\Gehua\\work""
  assert(s == L""d:/Gehua\\work"");
}}}

The call returned a value of ""c:/Gehua\\Gehua\\work"", which was wrong. ",yanggehua@…
11137,Bug in graph/dijkstra_shortest_paths_no_color_map.hpp,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-03-24T12:48:51Z,2015-03-24T13:11:14Z,"Hi,

I'm a new user to Boost Graph Library and I'm just start to figure out how to use it. So I apologize if I'm wrong.

While testing dijkstra algorithm, I found a possible bug in 
graph/dijkstra_shortest_paths_no_color_map.hpp.

In function dijkstra_shortest_paths_no_color_map_no_init, the code does not initialize distance_map[start_vertex] to 0 before push it into vertex_queue, as the document says here http://www.boost.org/doc/libs/1_57_0/libs/graph/doc/dijkstra_shortest_paths_no_color_map.html

So this will always return at the start vertex if the distance_map is initialized to infinity:

{{{
if (!distance_compare(min_vertex_distance, distance_infinity)) {
// This is the minimum vertex, so all other vertices are unreachable
return;
}
}}}



Hui Xiao",hokix@…
11134,MSM: adjust type fusion::nil to fusion::nil_,msm,Boost 1.57.0,To Be Determined,Bugs,Christophe Henry,new,2015-03-22T19:35:23Z,2015-03-22T19:35:23Z,"In order to help with some ObjectiveC++ issues, the boost fusion code renamed the type 'nil' to 'nil_'. There is still an alias to 'nil' in order to preserve ABI, but the 'nil_' is the true name of the type.

I would like to adjust accumulators to use the actual 'nil_' type instead, in order to make this code more ObjectiveC++ friendly (where 'nil' is a keyword, sadly).
",jared.grubb+boost@…
11133,Graph: using 'nil' as a local variable,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-03-21T23:22:01Z,2015-03-21T23:25:51Z,"The word ""nil"" is a keyword in Objective-C++ (this is C++ with the ObjC features too).

I'd like to rename some of the local variables in these headers that cause issues when code is compiled in ObjC++.",jared.grubb+boost@…
11131,[bb10/qnx failures] Build error,smart_ptr,Boost Development Trunk,Boost 1.58.0,Bugs,Peter Dimov,new,2015-03-20T00:27:40Z,2015-03-20T00:27:40Z,"Build error on QNX/BB10 crosscompiling:

                 from ./boost/smart_ptr/make_shared_array.hpp:12,
                 from ./boost/smart_ptr/make_shared.hpp:18,
                 from ./boost/archive/detail/helper_collection.hpp:28,
                 from ./boost/archive/detail/basic_iarchive.hpp:28,
                 from libs/serialization/src/basic_iarchive.cpp:42:
./boost/smart_ptr/detail/array_allocator.hpp:216:21: error: 'ptrdiff_t' does not name a type
             typedef ptrdiff_t difference_type;
                     ^
cc: /opt/bbndk/host_10_3_1_12/linux/x86/usr/lib/gcc/arm-unknown-nto-qnx8.0.0eabi/4.8.3/cc1plus error 1

Fix see git commit 94824c807f76dc4f3d41109a75808ed288f858f9",Jörg Böhme <joerg@…>
11130,[bb10/qnx failures] Build error,property_tree,Boost Development Trunk,Boost 1.58.0,Bugs,Sebastian Redl,new,2015-03-20T00:19:48Z,2015-03-20T00:19:48Z,"Missing std:: namespace in include/boost/property_tree/detail/info_parser_read.hpp

Fix see git commit 616631208c11c47826f07037d8827052800ce98c",Jörg Böhme <joerg@…>
11129,[bb10/qnx failures] Build error,msm,Boost Development Trunk,Boost 1.58.0,Bugs,Christophe Henry,new,2015-03-20T00:09:19Z,2015-03-20T00:09:19Z,"Missing include for std::find in boost/msm/back/metafunctions.hpp

Fix see git commit ef4de1dc4177dc1057692bc447fd0b9e6625771e",Jörg Böhme <joerg@…>
11126,View as text on the wiki is broken,trac / subversion,Boost 1.57.0,To Be Determined,Bugs,Douglas Gregor,new,2015-03-19T11:32:21Z,2015-03-19T11:32:21Z,"To repeat:

1. Go to https://svn.boost.org/trac/boost/wiki/SoCSubmissionTemplate.

2. At the bottom of the page where it says ""Download in other formats"" choose ""Plain text"".

3. Witness the explosion:

The response from the server contained duplicate headers. This problem is generally the result of a misconfigured website or proxy. Only the website or proxy administrator can fix this issue.
Error code: ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION

Niall",Niall Douglas
11124,Headers are not rebuilt completely,Building Boost,Boost Release Branch,To Be Determined,Bugs,,new,2015-03-18T18:10:54Z,2015-03-18T18:32:34Z,"Once you clone repo and run build such as this: ./b2 -a

One would assume that all libraries are built and ALL header files are copied or linked into proper place but it is not the case. Only files which built .libs are depend upon installed into include (boost) directory. If library is not used in the build process it is left out. Just look for ""Signals2"" for example.
",esadovoi@…
11123,Accumulators: adjust type fusion::nil to fusion::nil_,accumulator,Boost 1.57.0,To Be Determined,Feature Requests,Eric Niebler,new,2015-03-18T17:58:27Z,2015-03-21T23:06:01Z,"In order to help with some ObjectiveC++ issues, the boost fusion code renamed the type 'nil' to 'nil_'. There is still an alias to 'nil' in order to preserve ABI, but the 'nil_' is the true name of the type.

I would like to adjust accumulators to use the actual 'nil_' type instead, in order to make this code more ObjectiveC++ friendly (where 'nil' is a keyword, sadly).",jaredgrubb+boost@…
11122,Bulk/Range set/unset operations,dynamic_bitset,Boost Development Trunk,To Be Determined,Feature Requests,jsiek,new,2015-03-18T15:20:47Z,2015-03-18T15:25:44Z,"I need to set/unset a subrange of the elements within a dynamic bitset. The current best way (that I know of) of doing this, is assigning a value to each element individually. 

This is far from optimal, since an optimal solution would iterate over the blocks, setting the value once for each block. It is also non-trivial to work around this, since one needs to consider that the sub-range might being and end in the middle of some block. 

I propose to add the following two overloads to the set and unset member functions, to allow for this use case:

std::size_t set(std::size_t from, std::size_t to, bool value);
std::size_t unset(std::size_t from, std::size_t to, bool value);
// (maybe range-based and iterator-based versions should be added as well)

I'm willing to implement, test, and document this. But want to discuss before:

What do you think? Is there a better solution to this problem that is both safe and efficient?",gonzalobg88@…
11120,Problem compile with python 3 support.,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2015-03-18T09:07:06Z,2018-02-22T01:15:11Z,"

{{{
./bootstrap.sh --with-python=/usr/bin/python3 --with-python-root=/usr
./b2 
...
gcc.compile.c++ bin.v2/libs/python/build/gcc-4.9.2/release/threading-multi/object/function_doc_signature.o
In file included from ./boost/python/detail/prefix.hpp:13:0,
                 from ./boost/python/converter/registrations.hpp:8,
                 from libs/python/src/object/function_doc_signature.cpp:9:
./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory
 # include <pyconfig.h>
                       ^
compilation terminated.

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC  -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG  -I""."" -I""/usr/include/python3.4"" -c -o ""bin.v2/libs/python/build/gcc-4.9.2/release/threading-multi/object/function_doc_signature.o"" ""libs/python/src/object/function_doc_signature.cpp""

...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-4.9.2/release/threading-multi/object/function_doc_signature.o...
...skipped <pbin.v2/libs/python/build/gcc-4.9.2/release/threading-multi>libboost_python.so.1.57.0 for lack of <pbin.v2/libs/python/build/gcc-4.9.2/release/threading-multi>numeric.o...
...skipped <pstage/lib>libboost_python.so.1.57.0 for lack of <pbin.v2/libs/python/build/gcc-4.9.2/release/threading-multi>libboost_python.so.1.57.0...
...skipped <pstage/lib>libboost_python.so for lack of <pstage/lib>libboost_python.so.1.57.0...
...skipped <pbin.v2/libs/python/build/gcc-4.9.2/release/threading-multi>libboost_python3.so.1.57.0 for lack of <pbin.v2/libs/python/build/gcc-4.9.2/release/threading-multi>numeric.o...
...skipped <pstage/lib>libboost_python3.so.1.57.0 for lack of <pbin.v2/libs/python/build/gcc-4.9.2/release/threading-multi>libboost_python3.so.1.57.0...
...skipped <pstage/lib>libboost_python3.so for lack of <pstage/lib>libboost_python3.so.1.57.0...
...
...failed updating 56 targets...
...skipped 12 targets...
...updated 1062 targets...

}}}
[[BR]]
System:  PCLinuxOS 32bit Mate[[BR]]

gcc:   4.92[[BR]]

pkgconfig:   0.28[[BR]]

python2:   2.7.6[[BR]]

python3:   3.4.2[[BR]]


I want add log from compile, but I don't know how.

How I can find pyconfig.h ?",tele
11118,test libs/range/test/adaptor_test/indexed.cpp is bad,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,new,2015-03-13T18:08:20Z,2015-03-13T18:08:20Z,"This test contains two invocations of the BOOST_STATIC_ASSERT macro
that need additional parens around the parameters.  For
implementations that don't support variadic macros, the
BOOST_STATIC_ASSERT macro is defined to take one parameter.

As written the test passes two.",Ed Vogel <edward.vogel@…>
11117,asio: massive regression test failures,asio,Boost Development Trunk,To Be Determined,Bugs,chris_kohlhoff,new,2015-03-13T17:53:11Z,2015-03-13T17:53:11Z,"I am running the regression tests on the develop branch with Oracle Solaris
Studio12.4 on Solaris 11.2 OS.

Tests for asio fail as follows:
../boost/system/config.hpp"", line 34: Error: #error Must not define both
BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK.

I looked at  the developer issues on
http://www.boost.org/development/tests/develop/developer/issues.html

and see that asio tests fail similarly.

See discussion on
http://lists.boost.org/Archives/boost/2015/03/220407.php

For possible solution:
Removing the following line 
<library>/boost/system//boost_system 

from libs/asio/test/Jamfile.v2

seems to resolve the issue.


",Aparna Kumta <aparna.kumta@…>
11116,asio: massive regression test failures,asio,Boost Development Trunk,To Be Determined,Bugs,chris_kohlhoff,new,2015-03-13T17:51:10Z,2015-03-13T17:51:10Z,"I am running the regression tests on the develop branch with Oracle Solaris
Studio12.4 on Solaris 11.2 OS.

Tests for asio fail as follows:
../boost/system/config.hpp"", line 34: Error: #error Must not define both
BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK.

I looked at  the developer issues on
http://www.boost.org/development/tests/develop/developer/issues.html

and see that asio tests fail similarly.

See discussion on
http://lists.boost.org/Archives/boost/2015/03/220407.php

For possible solution:
Removing the following line 
<library>/boost/system//boost_system 

from libs/asio/test/Jamfile.v2

seems to resolve the issue.


",Aparna Kumta <aparna.kumta@…>
11114,Function for checking if file or directory is child of given ancestor directory.,filesystem,Boost Development Trunk,Boost 1.58.0,Feature Requests,Beman Dawes,new,2015-03-13T11:02:53Z,2015-03-13T11:02:53Z,To implement a function which returns true if a given file or directory is a child of a given ancestor directory.,perez.didac@…
11111,Enable deterministic builds (Linux),Building Boost,Boost 1.57.0,To Be Determined,Feature Requests,,new,2015-03-12T09:30:18Z,2015-03-12T09:38:40Z,"Building static libraries under Linux is not reproducible as the resulting libs have different md5sums every time.

The problem seems to be in gcc.jam which calls ar/ranlib without the 'deterministic' options.

A trivial patch is attached.

It would be nice if the boost build system could support reproducible builds. This is a first step.",Jens Richter <jens.richter@…>
11108,boost asio from_string rejects valid ipv6 address,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-03-11T22:31:56Z,2015-03-11T22:31:56Z,"
from RFC 4291 2.2.2, '::2:3:4:5:6:7:8' is a valid ipv6 address[[BR]]
following code incorrectly sets ec.m_val to 10022

{{{
std::string thost(""::2:3:4:5:6:7:8"");
boost::system::error_code ec;
addr = boost::asio::ip::address::from_string(thost, ec);
}}}

",mark andrews <mandrews58@…>
11101,urlencode() and urldecode(),string_algo,Boost 1.57.0,To Be Determined,Feature Requests,Marshall Clow,new,2015-03-11T12:11:05Z,2016-07-11T21:40:46Z,"These functions are quite handy when dealing with web stuff. Could they be added to Boost?

See also PHP's urlencode and urldecode.",olafvdspek@…
11093,Limitations of unique_ptr in C++03 mode,move,Boost 1.57.0,To Be Determined,Tasks,Ion Gaztañaga,new,2015-03-10T07:30:14Z,2015-03-10T07:30:14Z,"This is a follow-up of a thread on boost-dev mailing list which touches the topic of boost::movelib::unique_ptr emulation in C++03.

One of such limitations is related to copy initialization expressions:

{{{#!cpp
unique_ptr<Derived> x = make_unique<Derived>();
unique_ptr<Base> y = move(x);
}}}

which won't compile, while:

{{{#!cpp
unique_ptr<Derived> x = make_unique<Derived>();
unique_ptr<Base> y(move(x));
}}}

will compile without any problems.

There are probably some other limitations. It would be best if they were documented.",Adam Romanek <romanek.adam@…>
11092,Boost write_graphml writes non-conformant GraphML for boolean attributes,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-03-10T01:05:59Z,2016-12-12T17:24:54Z,"Boolean attributes are serialized as 0 and 1. They should be written as ""false"" and ""true"" instead.

The GraphML spec does not specify what values are acceptable, but according to the GraphML primer, ""The type of the GraphML-Attribute can be either boolean, int, long, float, double, or string. These types are defined like the corresponding types in the Java(TM)-Programming language."".

In source code, Java would allow only ""true"" and ""false"" for boolean values. If we add any representation that Java's Boolean.parseString() recognizes, the case wouldn't matter, but ""1"" still wouldn't parse as true.

Other libraries like NetworkX fail to parse GraphML with boolean attributes written by Boost. See also https :// github.com / networkx / networkx / pull / 1063.",freedesktop@…
11091,notify_all_at_thread_exit - ThreadSanitizer: data race,thread,Boost 1.57.0,To Be Determined,Bugs,viboes,assigned,2015-03-09T23:43:03Z,2015-03-09T23:43:18Z,"
{{{

Test output: BenPope x86_64 Ubuntu - thread - notify_all_at_thread_exit_p / clang-linux-3.6~tsan~c14_libc++
Rev 9b68e2eec037cbcb6f96d7d54079e7e1a6a274ab / Mon, 09 Mar 2015 11:14:53 +0000
Compile [2015-03-09 15:31:08 UTC]: succeed


""clang++-3.6"" -c -x c++ -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -std=c++1y -stdlib=libc++ -fsanitize=thread -O0 -fno-inline -Wall -pthread -fPIC -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I"".."" -o ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o"" ""../libs/thread/test/sync/conditions/notify_all_at_thread_exit_pass.cpp""

            

Link [2015-03-09 15:31:08 UTC]: succeed


""clang++-3.6""  -Wl,-R -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-R -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-R -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-rpath-link -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-rpath-link -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-rpath-link -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -o ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/notify_all_at_thread_exit_p"" -Wl,--start-group ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/winrt_init.o"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_thread.so.1.58.0"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_chrono.so.1.58.0"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_system.so.1.58.0""  -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -fsanitize=thread -lc++ -lc++abi -pthread 

RmTemps /home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/notify_all_at_thread_exit_p

    rm -f ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/winrt_init.o""

            

Run [2015-03-09 15:31:08 UTC]: fail


==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c48 by thread T1:
    #0 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x00000002567a)

  Previous write of size 8 at 0x7fd7f9795c48 by main thread:
    #0 <null> <null> (0x000000000001)

  Location is stack of thread T1.

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::(anonymous namespace)::thread_proxy(void*)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Read of size 8 at 0x7d4c0000de58 by thread T1:
    #0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x0000000318e5)
    #1 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7d4c0000de58 by main thread (mutexes: write M24):
    #0 boost::shared_ptr<boost::detail::thread_data_base>::swap(boost::shared_ptr<boost::detail::thread_data_base>&) <null> (libboost_thread.so.1.58.0+0x000000031796)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::operator=(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x00000003142d)
    #2 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x000000025579)
    #3 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #4 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #5 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Location is heap block of size 424 at 0x7d4c0000de40 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::thread_data<void (*)()>* boost::detail::heap_new<boost::detail::thread_data<void (*)()>, void (*)()>(void (*&&)()) <null> (notify_all_at_thread_exit_p+0x0000004c6acb)
    #2 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a87)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c38 by thread T1:
    #0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x0000000318f9)
    #1 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7fd7f9795c38 by main thread:
    #0 <null> <null> (0x000000000001)

  Location is stack of thread T1.

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Read of size 8 at 0x7d4c0000de60 by thread T1:
    #0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c7696)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #2 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7d4c0000de60 by main thread (mutexes: write M24):
    #0 boost::detail::shared_count::swap(boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c71cb)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::swap(boost::shared_ptr<boost::detail::thread_data_base>&) <null> (libboost_thread.so.1.58.0+0x0000000317d6)
    #2 boost::shared_ptr<boost::detail::thread_data_base>::operator=(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x00000003142d)
    #3 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x000000025579)
    #4 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Location is heap block of size 424 at 0x7d4c0000de40 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::thread_data<void (*)()>* boost::detail::heap_new<boost::detail::thread_data<void (*)()>, void (*)()>(void (*&&)()) <null> (notify_all_at_thread_exit_p+0x0000004c6acb)
    #2 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a87)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c40 by thread T1:
    #0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c76aa)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #2 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7fd7f9795c40 by main thread:
    #0 <null> <null> (0x000000000001)

  Location is stack of thread T1.

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Atomic write of size 4 at 0x7d080000ef88 by thread T1:
    #0 __tsan_atomic32_fetch_add /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cc:613:3 (notify_all_at_thread_exit_p+0x0000004a5256)
    #1 boost::detail::atomic_increment(int _Atomic*) <null> (notify_all_at_thread_exit_p+0x0000004c77cc)
    #2 boost::detail::sp_counted_base::add_ref_copy() <null> (notify_all_at_thread_exit_p+0x0000004c7749)
    #3 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c76e6)
    #4 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #5 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7d080000ef88 by main thread (mutexes: write M24):
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::shared_count::shared_count<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6f67)
    #2 void boost::detail::sp_pointer_construct<boost::detail::thread_data_base, boost::detail::thread_data<void (*)()> >(boost::shared_ptr<boost::detail::thread_data_base>*, boost::detail::thread_data<void (*)()>*, boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c6dd0)
    #3 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6c7b)
    #4 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a93)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Location is heap block of size 24 at 0x7d080000ef80 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::shared_count::shared_count<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6f67)
    #2 void boost::detail::sp_pointer_construct<boost::detail::thread_data_base, boost::detail::thread_data<void (*)()> >(boost::shared_ptr<boost::detail::thread_data_base>*, boost::detail::thread_data<void (*)()>*, boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c6dd0)
    #3 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6c7b)
    #4 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a93)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::atomic_increment(int _Atomic*)
==================
No errors detected.
ThreadSanitizer: reported 6 warnings

EXIT STATUS: 66
            


}}}
",viboes
11084,"segfault in process_queued_events, boost statechart",statechart,Boost 1.57.0,To Be Determined,Bugs,Andreas Huber,new,2015-03-06T21:17:54Z,2015-03-06T21:17:54Z,"Im using boost 1.57.0. I had a segfault in the process_event method. The event (build with react) is processed ok, the segfault is procduced when is processes events inqueued.

Im searching in the code, but no exist events in the eventQueue_ queue. 
What condition would be exist for this thing?

Many thanks


#7  <signal handler called>
#8  intrusive_ptr (this=0x8d88efc, evt=...) at /usr/include/boost/smart_ptr/intrusive_ptr.hpp:90
#9  process_queued_events (this=0x8d88efc, evt=...) at /usr/include/boost/statechart/state_machine.hpp:907
#10 boost::statechart::state_machine<ConnectorStateMachine, ConnIdle, std::allocator<void>, boost::statechart::null_exception_translator>::process_event (this=0x8d88efc, evt=...)
    at /usr/include/boost/statechart/state_machine.hpp:280",rodrigo.tobar@…
11083,"tools/build/src/tools/sun.jam needs additional  -W0,-abiopt=mangle6 for C++ compilations",build,Boost 1.57.0,To Be Determined,Bugs,Vladimir Prus,new,2015-03-06T20:12:20Z,2015-03-06T22:16:28Z,"1. Description of the failure
 
Several  tests inside libs/icl/test directory fail with Oracle Studio 12.4 C++ compiler on Solaris producing error message similar to what  one of those tests: libs/icl/test/fastest_interval_set_infix.cpp produces:


    ""CC"" -library=stlport4 -xO4 -mt -erroff=%none -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DDATE_TIME_INLINE -DNDEBUG -D__typeof__=__typeof__ -I""../../.."" -c -o ""../../../bin.v2/libs/icl/test/fastest_interval_set_infix.test/sun/release/link-static/stdlib-sun-stlport/threading-multi/fastest_interval_set_infix_/fastest_interval_set_infix.o"" ""fastest_interval_set_infix_/fastest_interval_set_infix.cpp""

""../../../boost/icl/concept/interval_set.hpp"", line 187: Error: boost::icl::add_intersection<boost::icl::interval_set<boost::rational<int>, less, boost::icl::continuous_interval<boost::rational<int>, less>, allocator>>(boost::icl::interval_set<boost::rational<int>, less, boost::icl::continuous_interval<boost::rational<int>, less>, allocator>&, const boost::icl::interval_set<boost::rational<int>, less, boost::icl::continuous_interval<boost::rational<int>, less>, allocator>&, const boost::icl::continuous_interval<boost::rational<int>, less>&) and boost::icl::add_intersection<boost::icl::interval_set<boost::rational<int>, less, boost::icl::continuous_interval<boost::rational<int>, less>, allocator>>(boost::icl::interval_set<boost::rational<int>, less, boost::icl::continuous_interval<boost::rational<int>, less>, allocator>&, const boost::icl::interval_set<boost::rational<int>, less, boost::icl::continuous_interval<boost::rational<int>, less>, allocator>&, const boost::rational<int>&) have same extern name ""__1cFboostDiclQadd_intersection4n0BMinterval_set4n0AIrational4Ci__nDstdEless3CTA__n0BTcontinuous_interval4n0C_n0E___n0DJallocator3C3_____6Fr3rk3r5_3_"".


2. Cause of the failure.
 
This is a name-mangling compiler bug that compiler developers can't fix without breaking compatibility.
The bug exists on Solaris/Sparc, and on Solaris x86 with -m32.
The bug does not exist on Linux, or on Solaris x86 with -m64, because the bug was discovered before those platforms were supported.
The workaround is to compile with -W0,-abiopt=mangle6, which is the default for the systems were the code works. When you use this option, you must recompile all C++ code and use the option everywhere.

3. Possible Solution.
 
To replace one line inside tools/build/src/tools/sun.jam inside  actions compile.c++ subroutine
by adding  -W0,-abiopt=mangle6 option into compilation instruction. Specifically, replace:

    ""$(CONFIG_COMMAND)"" $(OPTIONS) -D$(DEFINES) -I""$(INCLUDES)"" -c -o ""$(<)"" ""$(>)""

with 

    ""$(CONFIG_COMMAND)"" $(OPTIONS) -D$(DEFINES) -I""$(INCLUDES)""  -W0,-abiopt=mangle6 -c -o ""$(<)"" ""$(>)""
",Sergey.Sprogis@…
11080,MSVC level 4 compiler warnings in function_output_iterator,iterator,Boost 1.56.0,To Be Determined,Bugs,jeffrey.hellrung,new,2015-03-06T14:10:44Z,2015-03-06T14:42:08Z,"When compiling a project using signals2 (boost v. 1.56) with warning level 4 (/W4) in Visual Studio 2013, warnings are generated on the file function_output_iterator.hpp.

The warning is C4512: assignment operator could not be generated.

Supplying patch which solves the issue by declaring those classes noncopyable.",Erik Levin <p.erik.d.levin@…>
11073,boost::mpi an order of magnitude slower than pure MPI for sending vector of doubles,mpi,Boost 1.57.0,To Be Determined,Bugs,Matthias Troyer,new,2015-03-05T16:11:56Z,2015-03-05T16:11:56Z,As detailed in my email to boost users (h ttp://lists.boost.org/boost-users/2015/02/83807.php) it seems to take an order of magnitude longer to send a vector of doubles using boost::mpi than it takes using C bindings of MPI. I couldn't find anything in the documentation about optimizing transfers of standard types so I'd assume they are already optimized but that doesn't seem to be the case. Am I missing something or is there a serious performance issue in boost::mpi when sending (largeish) vectors of standard types?,ilja.j.honkonen@…
11072,[iostreams] mapped_file::size() returns the wrong size on 32-bit windows platforms for files larger than 4gb,iostreams,Boost 1.57.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-03-05T12:12:46Z,2015-03-05T12:12:46Z,"The signature is size_t mapped_file::size() which is uint32_t for 32-bit builds. This means files larger than 4gb will return an incorrect value.

Looking at the windows implementation source for mapped_file https://github.com/boostorg/iostreams/blob/master/src/mapped_file.cpp around line 220. The size is queried and stored as a local boost::intmax_t but when assigning to size_ it is static_cast to the smaller type.

I think the fix is to change the size member to be always 64-bit but I'm not familiar enough with the rest of the library to know if this would have any knock on effects. I suspect this is also an issue on linux as well but I am unable to easily test that at the moment,",James Whitworth <fun4jimmy@…>
11070,async_connect never calls back on mac with -fvisibility=hidden,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-03-04T14:50:25Z,2015-03-18T16:21:07Z,"See the attached file for a minimal code to reproduce. I have tested this on mac os yosemite with ""Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)"".

To test:

{{{
mkdir build
cd build
cmake ..
make
./main
}}}


Result:
The program never returns

Expected:
The program finishes (possibly with a ""connection refused"" error)

What I do is to create a socket in the main binary (without using it) and do an async_connect in a library with hidden symbols.

This code works if I comment the -fvisibility=hidden line in the CMakeLists.txt or if I comment the socket creation in main().

This seems to be related to boost::asio::detail::service_registry::keys_match which compares service types. It relies on typeinfo to do that (unless BOOST_ASIO_NO_TYPEID is set).

For that to work, typeid_wrapper is forced to default visibility (see #pragma at boost/asio/detail/service_registry.hpp:32), but in recent mac os versions it seems that it is not enough anymore. It seems that a symbol Foo<T> is exported if and only if Foo AND T are set to default visibility. So, in this case, we have two typeinfos for the same type typeid_wrapper<stream_socket_service<ip::tcp>> and they are not merged at dynamic linking because the symbols are hidden.

One possible fix is to set default visibility to stream_socket_service and ip::tcp. This makes my example work, but it should be needed also for other services and protocols as well. I have made a patch for for this, but I don't know if this is the right way to fix it.",blastrock
11069,io_service hangs for 5 minutes,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-03-04T10:56:37Z,2015-03-06T14:43:31Z,"Everything said below is applicable to Linux, 64-bit, CentOS 6.6, compiled by g++ 4.4.

I have an io_service object which is runned by several threads. According to the logic at the program finish all sockets which belong to this io_service are closed and these threads begin to exit one by one.

Just before threads exits, it posts on the io_service a callback which joins this thread from another thread and cleans up some associated data.

Everything runs perfect until only one thread is left. Occasionally this thread is not running any posted event for exactly 5 minutes. It is just waiting for something. After 5 minutes it wakes up, joins all the the threads which were posted, and successfully exits. It doesn't happen all the time, but approx. every 50 program executions I get this situations.

According to asio sources, epoll reactor has some timeout which equals to exactly 5 minutes. It seems that there is a bug somewhere.

P.S.: Meanwhile the main program thread waits for condition_variable which is set by the last thread running io_service, which signals that all the threads exited.",dmitrmax@…
11068,Link error with icpc when using Boost* 1.51+ MPL library and g++*,mpl,Boost 1.57.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-03-03T23:16:19Z,2015-03-03T23:16:19Z,"Our customer reported this issue with boost 1.51, the latest boost 1.57 still has this issue. please fix. 

the issue detail and work around is also posted online if you google the title.  

%cat t.h
#include <boost/mpl/vector.hpp>
template<typename T> struct my;
void foo(my<boost::mpl::vector<> >* = 0);

%cat u.cpp
#include ""t.h""
int main() { foo();}

%cat t.cpp
#include ""t.h""
void foo(my<boost::mpl::vector<> >*) {}

%icpc  -c  -I$BOOST_INC   u.cpp
%g++  -c   -I$BOOST_INC  t.cpp
%icpc u.o t.o
u.o: In function `main':
u.cpp:(.text+0x2b): undefined reference to `foo(my<boost::mpl::vector<boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, b:mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::nost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na, boost::mpl::na> >*)'

Work around: 
1.Go to ""./boost/mpl/aux/config"" directory
2.Comment out the following line in the file adl.hpp 
         BOOST_WORKAROUND(BOOST_INTEL_CXX_VERSION, BOOST_TESTED_AT(810))
",Jennifer Jiang <jennifer.l.jiang@…>
11067,boost::gregorian::date_iterator missing postfix operators ++ and --,date_time,Boost 1.57.0,To Be Determined,Feature Requests,"James E. King, III",assigned,2015-03-03T16:29:10Z,2017-12-28T13:35:12Z,"/* Consider the following (somewhat canonical) code snippet */
{
   std::vector<boost::gregorian::date> dates(count);
   auto dt_i = dates.begin();
   boost::gregorian::month_iterator m_i(some_start_date, 1);

   while (dt_i != dts.end())
      *dt_i++ = *m_i++; /* this will call prefix ++ operator on m_i
                         leading to subtle bug */
}",dkochin@…
11066,smart_ptr/detail/sp_convertible.hpp should include <cstddef>,smart_ptr,Boost 1.57.0,To Be Determined,Bugs,Peter Dimov,new,2015-03-01T19:04:11Z,2015-03-01T19:04:11Z,"smart_ptr/detail/sp_convertible.hpp uses std::size_t type but does not include cstddef standard header.

This can lead to errors if <cstddef> is not included by config headers (happens if stdlib configuration part of config headers is disabled).


{{{
] cat smart1.cc
#include <boost/smart_ptr/intrusive_ptr.hpp>
] gcc smart1.cc -DBOOST_NO_CONFIG  -I .
In file included from ./boost/smart_ptr/intrusive_ptr.hpp:20:0,
                 from smart1.cc:1:
./boost/smart_ptr/detail/sp_convertible.hpp:61:25: error: 'std::size_t' has not been declared
]
}}}
I got this behavior on Solaris (with Solaris Studio compiler first), but I bet it does not matter.

There is a simple fix:

{{{
] git diff .
diff --git a/include/boost/smart_ptr/detail/sp_convertible.hpp b/include/boost/smart_ptr/detail/sp_convertible.hpp
index 31b2627..4bba9ed 100644
--- a/include/boost/smart_ptr/detail/sp_convertible.hpp
+++ b/include/boost/smart_ptr/detail/sp_convertible.hpp
@@ -16,6 +16,7 @@
 //  http://www.boost.org/LICENSE_1_0.txt

 #include <boost/config.hpp>
+#include <cstddef>

 #if !defined( BOOST_SP_NO_SP_CONVERTIBLE ) && defined( BOOST_NO_SFINAE )
 # define BOOST_SP_NO_SP_CONVERTIBLE
]
}}}",Fedor Sergeev <Fedor.Sergeev@…>
11065,BZIP2_BINARY option broken in Windows,iostreams,Boost 1.57.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-03-01T02:07:20Z,2015-03-01T02:07:20Z,"Documentation ( http://www.boost.org/doc/libs/1_57_0/libs/iostreams/doc/installation.html ) suggests that users should be able to link to a precompiled bzip2 library.  On Windows, that is not the case.  In your Jamfile.v2, the following function breaks that option:


{{{
# Given a name of library, either 'zlib', or 'bzip2', creates the necessary
# main target and returns it. If compression is disabled, returns nothing.
# The 'sources' argument is the list of sources names for the library,
# which will be used if building the library.
rule create-library ( library-name : windows-name unix-name : sources + : requirements * )
{
    local LIB = $(library-name:U) ;
    if ! $(library-name) in zlib bzip2
    {
        EXIT ""Wrong library name passed to 'create-library' in libs/iostream/build/Jamfile.v2"" ;
    }

    if [ os.name ] = NT && ! $($(LIB)_SOURCE) && ! $($(LIB)_INCLUDE)
    {
        if $(debug)
        {
            ECHO ""notice: iostreams: not using $(library-name) compression "" ;
        }        
        NO_$(LIB) = 1 ;
	
	# This is necessary to that test Jamfiles don't run compression
	# tests when not needed. Dirty, but I don't have time to
	# write full-blow project module for zlib and bzip2.
	modules.poke : NO_$(LIB) : 1 ;
    }

    <snip />

}}}

That conditional needs to also consider whether $($(LIB)_BINARY) is set.  As a side note if that conditional is fixed, the correct value for Windows would be ""bz2"" instead of libbz2.  The aforementioned documentation makes it sound like Windows desires the prefix, but that is not the case for bzip2.  It is, however, for zlib, which inexplicably doesn't use this rule.",joshuadavidson@…
11060,any_range cannot be used at all,range,Boost 1.57.0,To Be Determined,Bugs,Neil Groves,new,2015-02-27T17:57:16Z,2015-02-28T15:50:55Z,"#include <boost/range/any_range.hpp>

fails under all major compilers (msvc2013, gcc492, clang35). f.e. clang first error message:

...\boost_1_57_0\boost/range/detail/any_iterator.hpp:131:15: 
error: no template named 'postfix_increment_proxy'; 
did you mean 'iterators::detail::postfix_increment_proxy'?
",BulatZiganshin <Bulat.Ziganshin@…>
11059,Ability to compile boost with customize namespace,Building Boost,Boost 1.57.0,To Be Determined,Feature Requests,,new,2015-02-25T20:06:02Z,2015-03-26T07:31:28Z,"Rather than using namespace ""boost"" upon building the libs, I would like to use ""boost_MAJOR_MINOR_PATCH"". I see that bcp will namespace certain libs, but I want all of them from the onset. Is there a way to set this in bjam or in the bootstrap.sh?

Thanks.",r4rita@…
11058,(parsing) Some thrown exceptions's messages are missing important info about the offending options,program_options,Boost 1.57.0,To Be Determined,Bugs,Vladimir Prus,new,2015-02-25T10:45:32Z,2015-04-04T21:02:24Z,"The ""unknown_option"" exception has a message that looks like
""unrecognized option"".

This can be easily improved by modifying the line
cmdline.cpp:427

to:
boost::throw_exception(unknown_option(opt.string_key));

//////////////////
Similar issue with "" multiple occurences"" exception.
The exception message does not specify which of the options occured multiple times.
This can be fixed by adding the constructor parameter in ""multiple_occurences"" exception class, and passing it to the parent class.
",Denis N <dzinyss@…>
11057,fs::copy fails with FILE_ATTRIBUTE_REPARSE_POINT attribute,filesystem,Boost 1.57.0,To Be Determined,Bugs,Beman Dawes,new,2015-02-25T10:01:56Z,2015-07-27T05:57:38Z,"Platform : Windows 7 64bits

When using fs::copy on a regular file with Windows APL attributes (Archive, sparse file, reparse point), fs::copy returns error code BOOST_ERROR_NOT_SUPPORTED.

When passing though the fs::copy, the ""from"" file is not detected as a regular file walking to the ""else"" case. 

With a little investigation, file status reports our file as a reparse file because of the REPARSE_POINT attribute. 

Is this behaviour the expected one ? knowing that a direct call to fs::copy_file works.




",loic.velut@…
11052,Make all executors copyable pointing to a shared context,thread,Boost 1.57.0,To Be Determined,Feature Requests,viboes,assigned,2015-02-20T14:08:23Z,2015-09-29T20:18:58Z,"Ensuring that the lifetime of an executor is longer than the continuations could be hard for the user.

In particular, the tests add a sleep for to ensure it. This is not robust enough. ",viboes
11051,filesystem::temp_directory_path() fails on OSX,filesystem,Boost 1.57.0,To Be Determined,Bugs,Beman Dawes,new,2015-02-20T12:17:08Z,2015-02-20T12:17:08Z,"On OSX the call to filesystem::temp_directory_path() throws an exception with error ENOTDIR.

This happens because on OSX the environment variable TMPDIR has a trailing /. There are quite a few references to this on the web.

On my system OSX 10.10.2 the TMPDIR is set to:
/var/folders/r8/y110f55j7ws94zpl8wfdpfpx13r441/T/

Workaround: Use
  system::error_code ec;
  filesystem::path p = filesystem::temp_directory_path(ec);
and ignore the error code. (which is ENOTDIR)

Suggested fix: Remove trailing / after getting environment variable in ""boost_1_57_0\libs\filesystem\src\operations.cpp"" at around line 1770.",Gerik Rhoden <Gerik.Rhoden@…>
11041,Add no_unit to duration_style.,chrono,Boost 1.57.0,To Be Determined,Feature Requests,viboes,assigned,2015-02-17T19:08:27Z,2016-03-05T09:32:21Z,"When using Chrono I/O V2, currently there's no easy way to specify that only the numeric value of a duration without the unit should be output to a stream (equivalent of duration unit pattern ""%v""). It would be useful to add a new enumerator, say 'no_unit', to duration_style enumeration, and a corresponding stream manipulator (e.g. 'no_unit_format').",rkawulak
11039,filesystem_error exception uses wrong encoding for what(),filesystem,Boost 1.55.0,To Be Determined,Feature Requests,Beman Dawes,new,2015-02-16T16:20:19Z,2015-02-16T16:20:19Z,"If one tries to access locked file on Windows with RU_ru locale, he'll get an exception with ""отказано в доступе"" (access denied) returned by its what() method. It's written in 1251 encoding, and it's very inconvenient to work with. I think, that there should be at least wwhat() method to get wstring of exception in Unicode.",polkovnikov.ph@…
11037,last_write_time doesn't work on Windows on files with custom access rights,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2015-02-16T16:07:02Z,2015-02-16T16:14:47Z,"last_write_time uses CreateFile internally with some minimal rights. Anyway, it doesn't have rights to read the last write time of ""System Volume Information"", even though such data are available i.e. for Windows Explorer. The right way to get descriptor for such file or folder is FindFirstFile.

Here's an example based on the answer from StackOverflow by Hans Passant:

std::size_t last_write_time(boost::filesystem::path const & path) {
	WIN32_FIND_DATAW info;
	auto hdl = FindFirstFileW(path.wstring().c_str(), &info);
	if (hdl == INVALID_HANDLE_VALUE) return std::time_t(-1);
	std::time_t retval = to_time_t(info.ftLastWriteTime);
	FindClose(hdl); // better use BOOST_SCOPE_EXIT two lines higher
	return retval;
}",anonymous
11034,boost::iostreams::copy: conversion from 'std::streamsize' to 'int',iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-02-16T15:24:26Z,2015-02-16T15:24:26Z,"When using <boost/iostreams/copy.hpp> in VS 2013 Update 2, I've got

boost\iostreams\copy.hpp(128): warning C4244: 'argument' : conversion from 'std::streamsize' to 'int', possible loss of data

I'm passing `ifstream` through `copy` to Poco SHA1, and the files are more than 2 GB long. It is not easy to tell if hashes for the files are correct, but from source code it seems that they are not.

The strange row ""size_(buffer_size) // Cast for SunPro 5.3."" looks like it was made deliberately to fix some other bug.

Trying to hotfix this bug I run into a problem, that the type should be std::streamsize and std::size_t simultaneosly. size_t is required by std::allocator::allocate. I've found similar problem here:

https://svn.boost.org/trac/boost/ticket/7873

Unfortunately I don't understand the code well enough to workaround that allocator parameter issue.",polkovnikov.ph@…
11033,boost::iostreams::copy: conversion from 'std::streamsize' to 'int',iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-02-16T15:22:22Z,2015-02-16T15:22:22Z,"When using <boost/iostreams/copy.hpp> in VS 2013 Update 2, I've got

boost\iostreams\copy.hpp(128): warning C4244: 'argument' : conversion from 'std::streamsize' to 'int', possible loss of data

I'm passing `ifstream` through `copy` to Poco SHA1, and the files are more than 2 GB long. It is not easy to tell if hashes for the files are correct, but from source code it seems that they are not.

The strange row ""size_(buffer_size) // Cast for SunPro 5.3."" looks like it was made deliberately to fix some other bug.

Trying to hotfix this bug I run into a problem, that the type should be std::streamsize and std::size_t simultaneosly. size_t is required by std::allocator::allocate. I've found similar problem here:

https://svn.boost.org/trac/boost/ticket/7873

Unfortunately I don't understand the code well enough to workaround that allocator parameter issue.",polkovnikov.ph@…
11032,boost::offset_ptr needs explicit ctor,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2015-02-16T14:38:13Z,2015-11-17T14:29:08Z,"Both the libc++ std library implementation and the MSVC library implementation require that their pointer types can be upcast. 

The list and tree data structures have a class hierarchy of node types and often seem to pass pointers to the base types (or to offset_ptr<void>) that are then upcast to the most derived types. offset_ptr has no explicit constructor that allows upcasts, only implicit ctors for downcasts. 

We have patched our version of offset_ptr with this constructor:

{{{
//!Explicit constructor from other offset_ptr. Never throws.
template<class T2>
explicit offset_ptr(const offset_ptr<T2, DifferenceType, OffsetType, OffsetAlignment> &ptr
   , typename ipcdetail::enable_if_c<
   !ipcdetail::is_convertible<T2*, PointedType*>::value 
    >::type * = 0)
    : internal(ipcdetail::offset_ptr_to_offset<OffsetType>(static_cast<PointedType*>(ptr.get()), this))
 {}

}}}
 
",stheophil@…
11030,"Building boost with MSVC, MASM and SAFESEH",Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2015-02-16T07:23:36Z,2015-02-16T07:23:36Z,"Hi,

in 

http://boost.2283326.n4.nabble.com/context-msvc-SAFESEH-td4652245.html

there was a discussion about the ""safeseh"" option for MASM (assembler-compuiler for MSVC).

I had troubles linking the MASM output with other SAFESEH libraries.
In version 1.56 I could solve the problem by adding /safeseh in boost_1_56_0\libs\context\build\Jamfile.v2 as supposed:

actions masm
{
     ml /safeseh /c /Fo""$(<)"" ""$(>)""
}


and -safeseh in boost_1_56_0\tools\build\src\tools\msvc.jam, line 952:

        local default-assembler-i386  = ""ml -coff -safeseh"" ;


It would be great if someone could add a build-option to specify safeseh for the assembler-compiler.

Tobias",Tobias Loew
11026,Add exceptions to file sinks when writing fails,log,Boost Development Trunk,To Be Determined,Feature Requests,Andrey Semashev,new,2015-02-14T16:03:09Z,2015-02-14T16:03:09Z,"Currently, if writing to a stream fails, the error goes unnoticed by the application. This primarily concerns text_file_backend and text_multifile_backend. There should be an exception thrown in such cases, preferably containing the cause of failure, which is not currently provided by the underlying stream. Also, some failures tend to happen repeatedly over prolonged time (e.g. when there is no free space left on the filesystem), and the library should not spam the application with exceptions in such cases.
",Andrey Semashev
11021,Natural sort,string_algo,Boost 1.57.0,To Be Determined,Feature Requests,Marshall Clow,new,2015-02-13T17:03:12Z,2016-07-11T21:31:21Z,"Alphabetically sorting gives unwanted results for humans. For example the following strings get sorted this way:
Arena 1
Arena 10
Arena 2

What humans like is:
Arena 1
Arena 2
Arena 10

This is not trivial since the numbers can appear anywhere. Would this be a nice extension for Boost as well? Microsoft has solved this in StrCmpLogicalW. See also 'sorting-for-humans-natural-sort-order' (can't include a link; I get a trac-think-it-is-a-spam error).
",gast128@…
11019,Error while building 1.57 with MinGW4.7.1,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2015-02-13T14:49:12Z,2015-02-13T14:56:41Z,"

I'm trying to build Boost 1.57 with GCC 4.7.1 bundled with CodeBlocks on Win7 64b.

I did this :

mkdir c:\boost\build
cd c:\boost\tools\build\v2
bootstrap.bat gcc
b2 install --prefix=C:\boost\build
set PATH=%PATH%;C:\boost\build\bin
cd c:\boost
b2 --build-dir=C:\boost\build toolset=gcc --build-type=complete

And I get this :

error: Name clash for '<pstage\lib>libboost_exception-mgw47-mt-1_57.a'

error: Tried to build the target twice, with property sets having
error: these incompabile properties:

error:     -  none
error:     -  <linkflags>-shared-libgcc <linkflags>-shared-libstdc++

error: Please make sure to have consistent requirements for these
error: properties everywhere in your project, especially for install
error: targets.

Did I miss anything ?

I haven't found anything on google / boost bug database.",anonymous
11017,typo in Boost.Hash documentation,hash,Boost 1.57.0,To Be Determined,Bugs,Daniel James,new,2015-02-12T19:54:55Z,2015-02-13T18:35:49Z,"In http://www.boost.org/doc/libs/1_57_0/doc/html/hash/tutorial.html

{{{
    std::transform(x.begin(), x.end(), std::insert_iterator(hashes),
        boost::hash<typename Container::value_type>());
}}} 

std::insert_iterator(hashes) is not a valid syntax.
Use std::back_inserter(hashes) instead.
",anonymous
11015,Bug with boost/graph/detail/edge.hpp,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2015-02-11T17:17:41Z,2015-11-04T13:58:02Z,"Hi,

I found a bug and it has not been solved yet (i searched on the latest source on the git repo), ok here it is:

The bug is that the use of the header ""boost/graph/detail/edge.hpp"" alone in a program cause an error at the compilation:

This error say that the ""hash struct"" is not a template class. After some searching i noticed that this ""hash struct"" is a template specialization, and the problem is that the ""hash struct"" generic template is not included in this file, i fixed it by adding the ""boost/functional/hash/hash.hpp"" header.

I don't know if this fix could be enough, but it works for my use.",mzartek@…
11013,"file_descriptor_sink won't create a file in ""app"" mode",iostreams,Boost 1.57.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-02-10T17:55:44Z,2015-02-10T17:55:44Z,"When file_descriptor_sink(filename, ios::app) is used on Linux, it refuses to create the file if the file doesn't already exist.

This is inconsistent with std::ofstream's behavior with ios::app, and it's inconsistent with file_descriptor_sink's behavior on Windows (where it does create the file if it doesn't exist).

See pull request 9 on the boostorg/iostreams GitHub repository.",Josh Kelley <joshkel@…>
11010,Why does boost setup suck,Building Boost,Boost 1.57.0,To Be Determined,Feature Requests,,new,2015-02-10T01:46:21Z,2015-02-10T01:46:21Z,"You guys need better write ups and need to show how to install and use on major IDE like Xcode, Visual Studios, Code Blocks, etc. this has the worst user experience ever..",anonymous
11003,Pointless use of using namespace std,asio,Boost 1.57.0,To Be Determined,Patches,chris_kohlhoff,new,2015-02-09T15:59:40Z,2015-02-09T15:59:40Z,"There's a few lines in boost/asio/detail/impl/signal_set_service.ipp that use ""using namespace std"" inside a block for a single call to std::memset rather than just using ""std::memset."" These blocks of code are also clearly copied from each other but that might not be an issue.

Here's a patch switching those lines around:
{{{
--- boost/asio/detail/impl/signal_set_service.ipp  Mon Feb  9 10:42:58 2015
+++ boost/asio/detail/impl/signal_set_service.ipp  Mon Feb  9 10:44:35 2015
@@ -271,9 +271,8 @@
     if (state->registration_count_[signal_number] == 0)
     {
 # if defined(BOOST_ASIO_HAS_SIGACTION)
-      using namespace std; // For memset.
       struct sigaction sa;
-      memset(&sa, 0, sizeof(sa));
+      std::memset(&sa, 0, sizeof(sa));
       sa.sa_handler = boost_asio_signal_handler;
       sigfillset(&sa.sa_mask);
       if (::sigaction(signal_number, &sa, 0) == -1)
@@ -342,9 +341,8 @@
     if (state->registration_count_[signal_number] == 1)
     {
 # if defined(BOOST_ASIO_HAS_SIGACTION)
-      using namespace std; // For memset.
       struct sigaction sa;
-      memset(&sa, 0, sizeof(sa));
+      std::memset(&sa, 0, sizeof(sa));
       sa.sa_handler = SIG_DFL;
       if (::sigaction(signal_number, &sa, 0) == -1)
 # else // defined(BOOST_ASIO_HAS_SIGACTION)
@@ -396,9 +394,8 @@
     if (state->registration_count_[reg->signal_number_] == 1)
     {
 # if defined(BOOST_ASIO_HAS_SIGACTION)
-      using namespace std; // For memset.
       struct sigaction sa;
-      memset(&sa, 0, sizeof(sa));
+      std::memset(&sa, 0, sizeof(sa));
       sa.sa_handler = SIG_DFL;
       if (::sigaction(reg->signal_number_, &sa, 0) == -1)
 # else // defined(BOOST_ASIO_HAS_SIGACTION)
}}}",fsmv@…
11002,winsock_init.ipp(36) : error C2665: 'InterlockedIncrement',asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-02-09T08:35:59Z,2015-02-09T08:35:59Z,"current compilation of code that deps on boost::asio fails with vs2013 for x64, because the used types cannot be resolved in an unambiguous manner.

<build-dir>\vc120-mt-gd-6_5-x64\include\boost/asio/detail/impl/winsock_init.ipp(36) : error C2665: 'InterlockedIncrement' : none of the 3 over
loads could convert all the argument types
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8844): could be 'unsigned __int64 InterlockedIncrement(volatile unsigned __int64 *)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8833): or       'unsigned long InterlockedIncrement(volatile unsigned long *)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8824): or       'unsigned int InterlockedIncrement(volatile unsigned int *)'
        while trying to match the argument list '(long *)'
<build-dir>\vc120-mt-gd-6_5-x64\include\boost/asio/detail/impl/winsock_init.ipp(40) : error C2665: 'InterlockedExchange' : none of the 3 overl
oads could convert all the argument types
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8910): could be 'unsigned __int64 InterlockedExchange(volatile unsigned __int64 *,unsigned
__int64)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8898): or       'unsigned long InterlockedExchange(volatile unsigned long *,unsigned long)'

        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8888): or       'unsigned int InterlockedExchange(volatile unsigned int *,unsigned int)'
        while trying to match the argument list '(long *, long)'
<build-dir>\vc120-mt-gd-6_5-x64\include\boost/asio/detail/impl/winsock_init.ipp(46) : error C2665: 'InterlockedIncrement' : none of the 3 over
loads could convert all the argument types
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8844): could be 'unsigned __int64 InterlockedIncrement(volatile unsigned __int64 *)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8833): or       'unsigned long InterlockedIncrement(volatile unsigned long *)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8824): or       'unsigned int InterlockedIncrement(volatile unsigned int *)'
        while trying to match the argument list '(long *)'
<build-dir>\vc120-mt-gd-6_5-x64\include\boost/asio/detail/impl/winsock_init.ipp(48) : error C2665: 'InterlockedExchange' : none of the 3 overl
oads could convert all the argument types
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8910): could be 'unsigned __int64 InterlockedExchange(volatile unsigned __int64 *,unsigned
__int64)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8898): or       'unsigned long InterlockedExchange(volatile unsigned long *,unsigned long)'

        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8888): or       'unsigned int InterlockedExchange(volatile unsigned int *,unsigned int)'
        while trying to match the argument list '(long *, int)'
<build-dir>\vc120-mt-gd-6_5-x64\include\boost/asio/detail/impl/winsock_init.ipp(54) : error C2665: 'InterlockedDecrement' : none of the 3 over
loads could convert all the argument types
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8875): could be 'unsigned __int64 InterlockedDecrement(volatile unsigned __int64 *)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8864): or       'unsigned long InterlockedDecrement(volatile unsigned long *)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8855): or       'unsigned int InterlockedDecrement(volatile unsigned int *)'
        while trying to match the argument list '(long *)'
<build-dir>\vc120-mt-gd-6_5-x64\include\boost/asio/detail/impl/winsock_init.ipp(62) : error C2665: 'InterlockedDecrement' : none of the 3 over
loads could convert all the argument types
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8875): could be 'unsigned __int64 InterlockedDecrement(volatile unsigned __int64 *)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8864): or       'unsigned long InterlockedDecrement(volatile unsigned long *)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8855): or       'unsigned int InterlockedDecrement(volatile unsigned int *)'
        while trying to match the argument list '(long *)'
<build-dir>\vc120-mt-gd-6_5-x64\include\boost/asio/detail/impl/winsock_init.ipp(67) : error C2665: 'InterlockedExchangeAdd' : none of the 3 ov
erloads could convert all the argument types
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8964): could be 'unsigned __int64 InterlockedExchangeAdd(volatile unsigned __int64 *,unsign
ed __int64)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8942): or       'unsigned long InterlockedExchangeAdd(volatile unsigned long *,unsigned lon
g)'
        C:\Program Files (x86)\Windows Kits\8.1\include\um\winbase.h(8922): or       'unsigned int InterlockedExchangeAdd(volatile unsigned int *,unsigned int)'

        while trying to match the argument list '(long *, int)'",ingo.loehken@…
11001,insert_range lacks support for extensible associative sequences,mpl,Boost 1.57.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-02-09T00:10:47Z,2015-02-09T00:10:47Z,"According to reference, the insert_range should work for any Extensible sequence or Extensible Associative sequence, but the following fails to compile.

{{{
#include <boost/mpl/pair.hpp>
#include <boost/mpl/map.hpp>
#include <boost/mpl/insert_range.hpp>
#include <boost/mpl/end.hpp>
#include <boost/mpl/equal.hpp>

typedef boost::mpl::map<boost::mpl::pair<int, int>, boost::mpl::pair<void, void> > myMap;
typedef boost::mpl::insert_range<boost::mpl::map<>, boost::mpl::end<boost::mpl::map<> >::type, myMap>::type copyOfMyMap;
BOOST_MPL_ASSERT((boost::mpl::equal<myMap, copyOfMyMap>));

int main()
{
    return 0;
}
}}}

I tracked the issue down to the definition of insert_range_impl, whose default implementation assumes a front_inserter is defined for the given sequence, but neither Extensible nor every Extensible Associative sequences are required to also be a Front Extensible sequence:


{{{
reverse_copy<
    joint_view< 
        iterator_range<typename begin<Sequence>::type,Pos>
    , joint_view< 
            Range
        , iterator_range<Pos,typename end<Sequence>::type>
        >
    >
, front_inserter< typename clear<Sequence>::type >
>
}}}


I found the fix to be implementing insert_range_impl by means of insert, which is defined for every Extensible sequence, using fold to iterate:

{{{
fold<
    joint_view< 
        iterator_range<typename begin<Sequence>::type,Pos>
    , joint_view< 
            Range
        , iterator_range<Pos,typename end<Sequence>::type>
        >
    >
, typename clear<Sequence>::type
, insert<_1, end<_1>, _2>
>
}}}

I'll file a pull request for this fix, any comments are welcome.",brunocodutra@…
10999,Issue while compiling mol with icc.,mpl,Boost 1.57.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2015-02-06T23:00:02Z,2015-02-06T23:00:02Z,"The error described at:

https://software.intel.com/en-us/forums/topic/516083

is still there in boost 1.57.0

we worked around the issue with:

https://github.com/cms-sw/cmsdist/blob/IB/CMSSW_7_4_X/stable/boost-1.57.0-icc.patch

can this be merged upstream?",giulio.eulisse@…
10998,Error: Boost_MPI send(): explicit specialization must precede its first use,mpi,Boost 1.63.0,To Be Determined,Support Requests,Matthias Troyer,new,2015-02-06T12:26:47Z,2017-02-21T14:57:24Z,"Dear Boost-Support,

when compiling a file with NVCC 6.5.14
containing calls to isend() etc. of boost:mpi, the following error occ 

nvcc -std=c++11 -arch=sm_20 -c file.cu
boost/1.55.0-gnu4.8/include/boost/mpi/communicator.hpp(1612): error: explicit specialization of function ""boost::mpi::communicator::send(int, int, const T &) const [with T=boost::mpi::packed_oarchive]"" must precede its first use (
(1127): here)

boost/1.55.0-gnu4.8/include/boost/mpi/communicator.hpp(1635): error: explicit specialization of function ""boost::mpi::communicator::recv(int, int, T &) const [with T=boost::mpi::packed_iarchive]"" must precede its first use (
(1191): here)

boost/1.55.0-gnu4.8/include/boost/mpi/communicator.hpp(1670): error: explicit specialization of function ""boost::mpi::communicator::isend(int, int, const T &) const [with T=boost::mpi::packed_oarchive]"" must precede its first use (
(1276): here)

Could you please help me regarding the error above?

Best regards,
Peter
",anonymous
10989,strided breaks on impure traversal tags,range,Boost 1.57.0,Boost 1.58.0,Bugs,Neil Groves,assigned,2015-02-02T17:31:03Z,2015-02-02T20:19:32Z,"From http://stackoverflow.com/questions/28280553/boostadaptorsstrided-cannot-be-used-after-boostadaptorstransformed

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

Problem is that make_begin_strided_iterator et al coerce the returned iterator traversal category/tag to a pure traversal tag, which doesn't necessarily agree with the Category passed to iterator_range for the base type. Fix is to use iterators::pure_iterator_traversal.",anonymous
10988,Range filtered adapter incorrectly requires a ForwardRange,range,Boost 1.58.0,To Be Determined,Bugs,Neil Groves,assigned,2015-02-01T18:26:23Z,2015-02-01T19:06:54Z,"The filtered Range adapter incorrectly requires a ForwardRange. A SinglePassRange should be sufficient, since it is for the Boost.Iterator filter_iterator.",Neil Groves
10986,Missing std:: qualifier for rand in test_triangular.cpp,uBLAS,Boost Development Trunk,To Be Determined,Bugs,Gunter,new,2015-01-30T21:44:59Z,2015-01-30T21:44:59Z,"Compiling libs/numeric/ublas/test/test_triangular.cpp on Solaris 11.2 with Oracle Solaris Studio12.4 compiler with -library=stlport4, we see

""../libs/numeric/ublas/test/test_triangular.cpp"", line 49: Error: The function ""rand"" must have a prototype.

""../libs/numeric/ublas/test/test_triangular.cpp"", line 51: Error: The function ""rand"" must have a prototype.

""../libs/numeric/ublas/test/test_triangular.cpp"", line 48: Error: The function ""rand"" must have a prototype.

3 Error(s) detected.

The rand() function needs to be qualified with std::.

diff ./test_triangular.cpp ./test_triangular.cpp_orig

3,5d2
< #include <cstdlib>

<
<
51,52c48,49
<     b(i) = std::rand() % 10;
<     double main = -10 + std::rand() % 20 ;
---
>     b(i) = rand() % 10;
>     double main = -10 + rand() % 20 ;
54c51
<     double side = -10 + std::rand() % 20 ;
---
>     double side = -10 + rand() % 20 ;",Aparna Kumta <aparna.kumta@…>
10983,box-box distance doesn't seem to work with spherical coordinate systems,geometry,Boost 1.57.0,Boost 1.59.0,Bugs,mkaravel,assigned,2015-01-29T23:29:45Z,2015-05-11T05:25:04Z,"The ""geometry distance matrix"" indicates that all geometry-to-geometry distances have been implemented in 1.57.  But the box-to-box distance doesn't seem to work with spherical geometries, at least with gcc 4.4.7.

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

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

See example below for problem.


----


{{{
#include <boost/geometry/geometry.hpp>

typedef boost::geometry::model::point<double,2,boost::geometry::cs::cartesian> cartesian_point;
typedef boost::geometry::model::point<double,2,boost::geometry::cs::spherical_equatorial<boost::geometry::degree> > spherical_point;

int main()
{

  // Works...
  boost::geometry::model::box<cartesian_point> c_box1, c_box2;
  boost::geometry::distance(c_box1,c_box2);

  // Doesn't work!
  boost::geometry::model::box<spherical_point> s_box1, s_box2;
  boost::geometry::distance(s_box1,s_box2);

  return 0;
}
}}}
",mdrinto@…
10982,addressof.hpp: should BOOST_ASIO_HAS_STD_ADDRESSOF be replaced with  BOOST_NO_CXX11_ADDRESSOF ?,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-01-29T13:40:50Z,2015-02-13T18:27:53Z,"Hi,

I'm on the border-line with compilers supporting (or not) various C++0x versions, and found this to be an issue: boost config already contains a macro:

BOOST_NO_CXX11_ADDRESSOF

However, in BoostAsio - this looks like a duplication that really ignores the config, and in order to compile asio BOOST_ASIO_HAS_STD_ADDRESSOF needs also be defined.

Shouldn't it be replaced by BOOST_NO_CXX11_ADDRESSOF defined in config instead?


",lukasz.forynski@…
10981,boost::function breaks with assignment or construction from nullptr,function,Boost 1.57.0,To Be Determined,Bugs,Douglas Gregor,new,2015-01-29T12:57:48Z,2015-01-29T12:57:48Z,"Repro:

{{{
#include <boost/function.hpp>

int main() {
    boost::function<int()> foo;
    foo = nullptr;
}
}}}

This appears to hit the operator= overload taking a functor. An overload for std::nullptr_t should probably be added.

There appears to be a similar issue with the constructor as well:

{{{
#include <boost/function.hpp>

int main() {
    boost::function<int()> foo = nullptr;
}
}}}",anonymous
10977,Add functions for obtaining full MPI transfer info of variable,mpi,Boost 1.57.0,To Be Determined,Feature Requests,Matthias Troyer,new,2015-01-28T18:40:00Z,2015-01-28T18:40:00Z,"I have a couple of MPI projects which duplicate functionality, so that neither depends on the other, for which boost::mpi would seem like a good place.

In order to transfer something using MPI 3 pieces of info are required: 1) the starting address of data, 2) number of items (contiguous in memory) to send and 3) the (MPI) type of each item. As far as I can tell functions in boost::mpi only return the type but not the count nor the address of variables. I'd like to see this functionality in boost or add it myself if that's ok. For basic types the function would be e.g.:

std::tuple<
  void*,
  int,
  MPI_Datatype
> get_mpi_transfer_info(const char& variable) {
  return std::make_tuple(
    (void*) &variable,
    1,
    MPI_CHAR
  );
}


For std types in contiguous containers only the count would differ (omitting error checking):

std::tuple<
  void*,
  int,
  MPI_Datatype
> get_mpi_transfer_info(const std::vector<char>& variable) {
  return std::make_tuple(
    (void*) variable.data(),
    variable.size(),
    MPI_CHAR
  );
}

For non-standard types the function would try to use the types' get_mpi_transfer_info() member function. Here's one of my current implementations for this functionality (add missing h to beginning of link): ttps://github.com/nasailja/gensimcell/blob/master/source/get_var_mpi_datatype.hpp It can probably be shortened with better use of overloads, templates, etc. but should give a good idea of what I'm after.",ilja.j.honkonen@…
10974,"dynamic_bitset.hpp should not use ""using namespace std""",dynamic_bitset,Boost 1.57.0,To Be Determined,Patches,jsiek,new,2015-01-27T15:23:28Z,2015-01-27T15:23:28Z,"Inside a few methods in the file dynamic_bitset.hpp, the statement ""using namespace std"" is used. This can cause havoc on some systems. The attached patch (made against 1.57.0) fixes this. 

I was unable to thoroughly test this for BOOST_OLD_IOSTREAMS, because I don't have such an ancient environment at my disposal.",loose@…
10973,Bootstrap doesn't configure project-config.jam correctly on Windows 8,Building Boost,Boost 1.58.0,Boost 1.58.0,Bugs,,new,2015-01-27T12:27:34Z,2015-01-27T12:27:34Z,"""Bootstrap gcc"" or ""Bootstrap mingw"" doesn't configure the project-config.jam file correctly on Windows.

It will always set ""using msvc."" This is corrected when I set ""using gcc"" in project-config.jam.

I use TGM-GCC version 4.9.2 on 64-bit Windows 8. I compiled the 32-bit versions of the Boost library. I successfully compiled the libraries after doing the above.",anonymous
10970,uses of make_reverse_iterator conflict with C++14's.,iterator,Boost 1.57.0,To Be Determined,Bugs,jeffrey.hellrung,new,2015-01-25T15:59:41Z,2016-05-07T19:04:55Z,"C++14 introduces make_reverse_iterator, which conflicts with Boost's when compiling with libc++.

At the very least, this affects targets using the multi_index library (ordered_index.hpp, random_access_index.hpp, and sequenced_index.hpp).

A quick workaround would be to simply replace occurrences of make_reverse_iterator with boost::make_reverse_iterator, following the trend in the accumulators (statistics/tail.hpp) and graph (core_numbers.hpp) libraries.

",Larisse Voufo <lvoufo@…>
10967,Timed wait points inconsistently convert relative to absolute waits,thread,Boost 1.57.0,To Be Determined,Tasks,Niall Douglas,new,2015-01-24T19:54:24Z,2017-11-14T20:55:59Z,"Possibly related: #6787

Stepping through the Boost.Thread win32 implementation, interruptible_wait() and non_interruptible_wait() are capable of accepting both relative and absolute timeouts. However condition_variable and thread join are always implemented as absolute timeouts, while thread sleep is always implemented as relative timeouts. I also see that timed mutex always converts absolute to relative too on win32.

These all should be fixed to correctly use either relative or absolute timeouts as requested by the user, firstly at the upper layers where necessary. Then all waits on Windows always need to go via interruptible_wait() or non_interruptible_wait() as appropriate as these implement the proper calls on Windows for absolute deadline timers when absolute timeouts are requested.",Niall Douglas
10966,packaged_task::reset should not reuse the shared state to conform to C++11,thread,Boost 1.57.0,To Be Determined,Feature Requests,viboes,assigned,2015-01-24T09:51:16Z,2015-01-26T07:33:49Z,"The standard says


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

Boost.Thread reuse the shared state.

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

",viboes
10962,libs/pool/test/test_bug_5526.cpp fails to compile due to missing header,pool,Boost Development Trunk,To Be Determined,Bugs,Marshall Clow,new,2015-01-23T18:57:19Z,2015-02-25T19:34:58Z,"
Test libs/pool/test/test_bug_5526.cpp fails to compile with oracle Solaris Studio12.4 on Solaris11.2. The error message is \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Error: auto_ptr is not a member of std. \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Error: A declaration does not specify a tag or an identifier. \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Error: Use "";"" to terminate declarations. \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Error: A declaration was expected instead of ""<"". \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Warning: declarator required in declaration. \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Error: Use "";"" to terminate declarations. \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Error: A declaration was expected instead of "">"". \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Error: aptr is not defined. \\
""../libs/pool/test/test_bug_5526.cpp"", line 29: Error: A declaration does not specify a tag or an identifier. \\
""../libs/pool/test/test_bug_5526.cpp"", line 33: Error: aptr is not defined. \\
9 Error(s) and 1 Warning(s) detected. \\

Adding \\
#include <memory>  \\
to the test seems to resolve the issue. \\

The diff's are \\
diff ../libs/pool/test/test_bug_5526.cpp ../libs/pool/test/test_bug_5526.cpp_orig \\
10d9 \\
< #include <memory>

",Aparna Kumta <aparna.kumta@…>
10956,null point exception using asio based on linux,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-01-23T06:58:49Z,2016-08-11T03:57:59Z,"I have writen a linux server application based on centos boost asio.I have created thread pool accelerating asyn asio,but it is cored down like following.
#0  start_op (this=0x1196e18, impl=..., op_type=1, op=0x7fd2b01a8c30, is_continuation=<value optimized out>, is_non_blocking=true, noop=false)
    at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/detail/impl/epoll_reactor.ipp:219
#1  boost::asio::detail::reactive_socket_service_base::start_op (this=0x1196e18, impl=..., op_type=1, op=0x7fd2b01a8c30, is_continuation=<value optimized out>, is_non_blocking=true, noop=false)
    at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/detail/impl/reactive_socket_service_base.ipp:214
#2  0x00007fd2b94dc667 in async_send<boost::asio::detail::consuming_buffers<boost::asio::const_buffer, asio_net::shared_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> >, asio_net::shared_const_buffer, boost::asio::detail::transfer_all_t, boost::_bi::bind_t<void, boost::_mfi::mf2<void, asio_net::AsioSocket, boost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<asio_net::AsioSocket*>, boost::arg<1>, boost::arg<2> > > > > (this=<value optimized out>, ec=<value optimized out>, bytes_transferred=<value optimized out>, start=<value optimized out>)
    at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/detail/reactive_socket_service_base.hpp:216
#3  async_send<boost::asio::detail::consuming_buffers<boost::asio::const_buffer, asio_net::shared_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> >, asio_net::shared_const_buffer, boost::asio::detail::transfer_all_t, boost::_bi::bind_t<void, boost::_mfi::mf2<void, asio_net::AsioSocket, boost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<asio_net::AsioSocket*>, boost::arg<1>, boost::arg<2> > > > > (this=<value optimized out>, ec=<value optimized out>, bytes_transferred=<value optimized out>, start=<value optimized out>)
    at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/stream_socket_service.hpp:330
#4  async_write_some<boost::asio::detail::consuming_buffers<boost::asio::const_buffer, asio_net::shared_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> >, asio_net::shared_const_buffer, boost::asio::detail::transfer_all_t, boost::_bi::bind_t<void, boost::_mfi::mf2<void, asio_net::AsioSocket, boost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<asio_net::AsioSocket*>, boost::arg<1>, boost::arg<2> > > > > (this=<value optimized out>, ec=<value optimized out>, bytes_transferred=<value optimized out>, start=<value optimized out>)
    at /usr/share/server_depends/cmake/depends/net/../../../depends/net/../boost_1_56_0/boost/asio/basic_stream_socket.hpp:732

I guess that the socket writing thread starts a reactor io when the other thread closes it concurrency.Is that a bug?Does the socket closing function should add some lock to avoid it.",xuzhiteng <419855192@…>
10954,boost::spirit::iterator_policies::split_std_deque memory leak on reference count,spirit,Boost 1.57.0,To Be Determined,Bugs,Joel de Guzman,new,2015-01-22T20:21:18Z,2017-12-10T15:21:55Z,"The split_std_deque implementation does not free unsued memory if only one reference to it remains. This is even true when invoking clear_queue().
See attaches example for more details.",daniel.f.starke@…
10952,program_options in wchar_t,program_options,Boost 1.57.0,To Be Determined,Feature Requests,Vladimir Prus,new,2015-01-22T09:26:33Z,2017-09-11T13:09:43Z,"In Visual Studio 2013, ansi MFC builds are deprecated. More products will have to convert to wchar_t. I am aware that wchar_t is not the best Unicode representation, but it is quite dominant on Windows platforms. Some program_options parts however are bound to hard code ansi strings. For example the options_description uses std::string and char*:

{{{#!python
po::options_description desc(""Allowed options"");

std::wcout << desc; //error (actual use is a std::wofstream)
}}}

Can't this just made complete template based on char type?",gast128@…
10946,Add dt to system arguments,odeint,Boost 1.57.0,To Be Determined,Feature Requests,karsten,assigned,2015-01-20T17:25:03Z,2015-01-29T21:29:57Z,"A popular algorithm for calculating the change in velocity of a charged particle in a magnetic field (1) requires the length of the time step while integrating (dx/dt := f(x,t,dt)) and cannot be used with odeint as far as I could tell so I suggest modifying the definition of system from sys( x , dxdt , t ) to sys( x , dxdt , t , dt ). Some enable_if magic should allow all existing code using the current API to work.

(1) Equations 25 and 26 in (h)ttp://www.dtic.mil/dtic/tr/fulltext/u2/a023511.pdf",ilja.j.honkonen@…
10942,Boost.Thread fails to build on Cygwin,build,Boost 1.57.0,To Be Determined,Bugs,Steven Watanabe,new,2015-01-18T19:11:18Z,2015-04-04T22:53:40Z,"By default on Cygwin, the Boost.Thread headers choose the POSIX API. This decision is made in `boost/thread/detail/platform.hpp`:

{{{
#if defined(BOOST_THREAD_POSIX)
#  define BOOST_THREAD_PLATFORM_PTHREAD
#else
#  if defined(BOOST_THREAD_WIN32)
#       define BOOST_THREAD_PLATFORM_WIN32
#  elif defined(BOOST_HAS_PTHREADS)
#       define BOOST_THREAD_PLATFORM_PTHREAD
#  else
#       error ""Sorry, no boost threads are available for this platform.""
#  endif
#endif
}}}

In the Cygwin case, neither `BOOST_THREAD_POSIX` nor `BOOST_THREAD_WIN32` appear to be defined, but `BOOST_THREAD_CYGWIN`, so the logic above chooses `BOOST_THREAD_PLATFORM_PTHREAD`.

This is actually correct, in my opinion; Cygwin is a POSIX platform.

However, the Jamfile by default chooses Win32 on Cygwin:

{{{
local rule default_threadapi ( )
{
    local api = pthread ;
    if [ os.name ] = ""NT"" { api = win32 ; }
    return $(api) ;
}
}}}

which later results in a bunch of errors when `win32/thread.cpp` is compiled against `pthread/thread_data.hpp` et al.

So, either the default in `platform.hpp` should be changed to Win32 under Cygwin, or (better) the default `threadapi` in the Jamfile should be changed to `pthread` under Cygwin.

Manually specifying `threadapi=pthread` is not a particularly good option, because Boost.Thread is a dependency of some tests, and when

{{{
b2 toolset=gcc,gcc-cxx11,clang,clang-cxx11,msvc-8.0,msvc-10.0,msvc-11.0,msvc-12.0
}}}

(for example) is invoked to test a library, `threadapi=pthread` is not possible.",Peter Dimov
10940,boost:asio/boost::thread does not work on windows 8 store/phone environment,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2015-01-18T15:39:46Z,2015-01-18T16:04:46Z,"I have try painfully to build a test app that just use serial class from boos::asio but on windows 8 store\phone, it does not work

c:\boost\boost\asio\detail\impl\win_thread.ipp(81): error C2039: '_beginthreadex' : is not a member of '`global namespace''
c:\boost\boost\asio\detail\impl\win_thread.ipp(81): error C3861: '_beginthreadex': identifier not found

With store\phone app, MS remove some function search as beginthreadex etc... it will be best that boost::asio use boost::thread or std::thread, but even that boost::thread does not work on windows 8 store app anyway related to the same thing

",sylvain.rochette@…
10937,tuple_manipulator has char in constructor,tuple,Boost 1.57.0,To Be Determined,Bugs,Joel de Guzman,new,2015-01-17T19:06:24Z,2015-01-17T19:06:24Z,"The constructor of tuple_manipulator has hard coded type char. Shouldn't this be CharType?

{{{#!cpp
template<class CharType>    
class tuple_manipulator 
{
  const detail::format_info::manipulator_type mt;
  CharType f_c;
public:
  explicit tuple_manipulator(detail::format_info::manipulator_type m, 
                             const char c = 0)

}}}

->

{{{#!cpp
  explicit tuple_manipulator(detail::format_info::manipulator_type m, 
                             const CharType c = 0)

}}}
",gast128@…
10936,How to build boost_1_32_0 for Visual studio 2012,Building Boost,Boost 1.34.0,To Be Determined,Support Requests,,new,2015-01-16T14:55:21Z,2015-01-16T16:36:35Z,"I have successfully build boost_1_57_0. Now I need to build boost_1_32_0, but same steps cannot be applied to older version of the boost, because folder does not contain bootstrap or bjam, or b2. I tried to run build.bat from boost_1_32_0\tools\build\jam_src\ directory, it was unsuccessfully. I got message ""\Microsoft was unexpected at this time"". Is there other way of how to build boost_1_32_0 versions of boost library?

Thank you",yurinaolga87@…
10935,Header-only option for Boost.Timer,timer,Boost 1.57.0,To Be Determined,Feature Requests,Beman Dawes,new,2015-01-15T22:21:21Z,2015-01-15T22:21:21Z,"As discussed on the Mailing List:



> So as far as I understand, Boost.Test has moved from Boost.Timer v1 (2001)
> to Boost.Timer v2 (2011). Boost.Timer v2 depends on Boost.Chrono, which
> optionally can be compiled header-only, and on Boost.System. But Boost.Timer
> itself has no option to be compiled header-only (AFAIU). So basically the
> regression is in Boost.Timer, which now requires linking. But because that
> is already introduced in 2011, it cannot be called a sudden regression.
> However, the influence on Boost.Test is quite large.
>
> We use Boost.Test (the header-only option)  since 2007 and wish to keep it
> header-only. I know what to do to make it compile (link with Boost.Timer)
> but that is an unwished option for several reasons, so: a regression.

I looked a Boost.Timer, and it seems reasonable to add a header-only option.

If you open a ticket, I'll give it a try. But it will be a week or
two, so a ticket is best.

",Barend Gehrels
10933,"Boost.Python incomplete type in ""contains""",python USE GITHUB,Boost 1.57.0,To Be Determined,Bugs,Stefan Seefeld,new,2015-01-14T15:20:21Z,2015-03-31T02:21:30Z,"Hi,

I am compiling Boost.Python with '''nvcc/6.5''', '''gcc/4.6.2''', '''python/2.7.8''' and '''cmake/3.0.1''' right now.

As a side note, I modified the standard ''FindPythonLibs.cmake'' a bit to match the ''cuda_add_library calls''.

During compile, I get the error

{{{
boost/python/object_core.hpp(499): error: function ""boost::python::api::object_operators<U>::attr(const char *) const"" returns incomplete type ""boost::python::api::const_object_attribute""
}}}

from ''include/boost/python/object_core.hpp''
{{{
template <typename U>
template <class T>
object api::object_operators<U>::contains(T const& key) const
{
    return this->attr(""__contains__"")(object(key));
}
}}}

Replacing the return statement with
{{{
    return (*this)[object(key)];
}}}
seems to compile and my modules work, but I am not sure if the functionality is still ok since I have no idea what this function actually does (nor how to test/trigger it).

It would be great if we can fix that compile error and someone could give me a review.",a.huebl@…
10925,fialed to build math library with studo 12.4 c++ on Solaris 11.2,math,Boost 1.56.0,To Be Determined,Bugs,John Maddock,new,2015-01-09T23:53:45Z,2015-04-02T17:10:33Z,"Problem:fails to build math library with studio 12.4 on Solaris 11.2
 with ""../../../boost/math/cstdfloat/cstdfloat_types.hpp"", line 393: Error: The type ""boost::STATIC_ASSERTION_FAILURE<0>"" is incomplete.
1 Error(s) detected.
",angela.xie@…
10923,exec-dynamic fails with Python 3,python USE GITHUB,Boost 1.57.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2015-01-09T20:37:45Z,2016-12-01T12:13:19Z,"The reason being that the test case calls PyImport_AppendInittab after Py_Initialize.  One solution is to call Py_Finalize before PyImport_AppendInittab, and the re-call Py_Initialize.  I implement this in a somewhat structured fashion in the attached patch.",Petr Machata <pmachata@…>
10922,Fails to link python-extension project when msvc target is used,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2015-01-09T12:28:23Z,2018-01-23T01:14:01Z,"For `python-extension` boost.build project, using target msvc, on link stage the command line is generated incorrectly and the build fails.

Generated command line:
{{{
link
 /NOLOGO /INCREMENTAL:NO /DLL /NOENTRY /DEBUG /MACHINE:X86 /MANIFEST
 /subsystem:console 
 /out:""bin\msvc-12.0\debug\threading-multi\mytest.pyd"" 
 /IMPLIB:""bin\msvc-12.0\debug\threading-multi\mytest.pdb""
 /LIBPATH:""C:\Program Files (x86)\Python34\libs""
 @""bin\msvc-12.0\debug\threading-multi\mytest.pyd.rsp""
}}}

Error displayed: `LINK : fatal error LNK1207: incompatible PDB format in 'D:\Temp\test\bin\msvc-12.0\debug\threading-multi\mytest.pdb'; delete and rebuild`

Note the `IMPLIB` part referencing the `.pdb` file instead of the `.lib` file.

Steps to reproduce:
 - unpack the attachment
 - copy the boost lib to `boost` directory
 - copy boost.build to `boost-build` directory
 - run `boost-build\bin\b2`
 - or `boost-build\bin\b2 target=msvc-12`

Tested with msvc 10 and 12. Standard shared library/dll project compiles fine.",Pavel Machyniak <machyniak@…>
10921,Seeding boost::random::mt19937 from a pair of iterators throws an exception,random,Boost 1.57.0,To Be Determined,Bugs,No-Maintainer,new,2015-01-09T11:28:30Z,2015-02-26T07:24:31Z,"The problem is that when seeding `boost::random::mt19937` from a pair of iterators `std::invalid_argument(""Not enough elements in call to seed"")` exception is thrown.

An isolated test case looks like this:
{{{
#include <boost/array.hpp>
#include <boost/random.hpp>

//typedef boost::random::rand48 generator_t;
typedef boost::random::mt19937 generator_t;

int main() {
  typedef boost::array<int, 3> seed_range_t;
  seed_range_t seed = {1, 2, 3};

  boost::random::seed_seq seed2(seed.begin(), seed.end());
  generator_t generator1(seed2); // works fine

  seed_range_t::iterator begin = seed.begin();
  generator_t generator2(begin, seed.end()); // throws std::invalid_argument(""Not enough elements in call to seed"")
}
}}}

The documentation of the relevant constructor ![1] does not help too much.

Please note that using the same input sequence through `boost::random::seed_seq` works fine. Moreover, the same input sequence passed directly to the constructor of `boost::random::rand48` generator also produces no exceptions.

I'm not sure if `mersenne_twister_engine` needs larger input or the implementation is broken. Please advice.

![1] http://www.boost.org/doc/libs/1_57_0/doc/html/boost/random/mersenne_twister_engine.html#idp93974544-bb",Adam Romanek <romanek.adam@…>
10920,Boost error from XlC11. 01 using BOOST 1.53 in union,geometry,Boost 1.53.0,To Be Determined,Bugs,Barend Gehrels,new,2015-01-09T06:26:05Z,2015-03-23T17:58:02Z,"Hi All,


We are trying to compile  sample boost code to demonstrate union on Aix64:
Testcase:
http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/reference/algorithms/union_.html


Following are the details of compiler
Xlc Version:Version: 11.01.0000.0011
OS version:6100-06-05-1115
Boost version:1.53


It throws errors:
""/usr/vacpp/include/vector.t"", line 163.36: 1540-0716 (S) The template argument ""std::vector<boost_1_53_0::geometry::model::ring<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector<boost_1_53_0::geometry::model::ring<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector<boost_1_53_0::geometry::model::ring<boost_1_53_0::geometry::mod..."" does not match the template parameter ""template class Container"".
""test.cpp"", line 12.5: 1540-0700 (I) The previous message was produced while processing ""_Ucopy"".
""test.cpp"", line 12.5: 1540-0700 (I) The previous message was produced while processing ""class std::vector<boost_1_53_0::geometry::model::ring<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector<boost_1_53_0::geometry::model::ring<boost_1_53_0::geometry::model::d2::point_xy<double,snps_boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector,std::allocator>,std::allocator<boost_1_53_0::geometry::model::ring<boost_1_53_0::geometry::model:..."".
""/usr/vacpp/include/vector.t"", line 163.36: 1540-1174 (S) The member ""template pointer _Ucopy(_It, _It, pointer)"" is not declared as a template in its containing class definition.
""test.cpp"", line 12.5: 1540-0700 (I) The previous message was produced while processing ""_Ucopy"".
""test.cpp"", line 12.5: 1540-0700 (I) The previous message was produced while processing ""class std::vector<boost_1_53_0::geometry::model::ring<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector,std::allocator>,std::allocator<boost_1_53_0::geometry::model::ring<boost_1_53_0::geometry::model::d2::point_xy<double,snps_boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector,std::allocator> > >"".
""/boost/boost/geometry/geometries/polygon.hpp"", line 69.7: 1540-0700 (I) The previous message was produced while processing ""class boost_1_53_0::geometry::model::polygon<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector,std::vector,std::allocator,std::allocator>"".
""test.cpp"", line 12.5: 1540-0700 (I) The previous message was produced while processing ""main()"".
""/usr/vacpp/include/vector.t"", line 163.36: 1540-0716 (S) The template argument ""std::vector<boost_1_53_0::geometry::model::polygon<snps_boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector<boost_1_53_0::geometry::model::polygon<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector<boost_1_53_0::geometry::model::polygon<boost_1_53_0::geom..."" does not match the template parameter ""template class PointList"".
""/usr/vacpp/include/vector.t"", line 163.36: 1540-0700 (I) The previous message was produced while processing ""_Ucopy"".
""/usr/vacpp/include/vector.t"", line 163.36: 1540-0700 (I) The previous message was produced while processing ""class std::vector<boost_1_53_0::geometry::model::polygon<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector<boost_1_53_0::geometry::model::polygon<snps_boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector,std::vector,std::allocator,std::allocator>,std::allocator<boost_1_53_0::geometry::model::polygon..."".
""/remote/ports/aix/xlcpp11_1_aix53/usr/vacpp/include/vector.t"", line 163.36: 1540-1174 (S) The member ""template pointer _Ucopy(_It, _It, pointer)"" is not declared as a template in its containing class definition.
""test.cpp"", line 25.26: 1540-0700 (I) The previous message was produced while processing ""_Ucopy"".
""test.cpp"", line 25.26: 1540-0700 (I) The previous message was produced while processing ""class std::vector<boost_1_53_0::geometry::model::polygon<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector,std::vector,std::allocator,std::allocator>,std::allocator<boost_1_53_0::geometry::model::polygon<boost_1_53_0::geometry::model::d2::point_xy<double,boost_1_53_0::geometry::cs::cartesian>,1,1,std::vector,std::vector,std::allocator,std::allocator> > >"".
""test.cpp"", line 12.5: 1540-0700 (I) The previous message was produced while processing ""main()"".


Is this a known bug ?
Please help us in case a patch is available.
",devika.rs@…
10918,Boost pool does not compile with MSVC /Za,pool,Boost 1.57.0,To Be Determined,Bugs,Chris Newbold,new,2015-01-08T02:45:50Z,2015-02-13T18:29:42Z,"The following code does not compile with Visual Studio C++ 2013 update 4, compiler flag /Za

{{{
    #include <boost/pool/pool.hpp>
    int main()
    {
        boost::pool<> d_BoostPool( 16 );
        d_BoostPool.ordered_malloc( 28 );
        return 0;
    }
}}}
The guilty behavior is similar to the one shown here: http://stackoverflow.com/q/27830761/2549876

",anonymous
10916,Change wait_for_all to work on models of Future.,thread,Boost 1.57.0,To Be Determined,Feature Requests,viboes,assigned,2015-01-07T02:48:57Z,2015-01-07T02:49:06Z,,viboes
10915,Change wait_for_any to work on models of Future.,thread,Boost 1.57.0,To Be Determined,Feature Requests,viboes,assigned,2015-01-07T02:47:53Z,2015-01-07T02:48:00Z,Using notify_when_any implement a generic wait_for_any on models of Future. ,viboes
10914,Add a future::notify_when_ready function,thread,Boost 1.57.0,To Be Determined,Feature Requests,viboes,assigned,2015-01-07T02:46:17Z,2015-01-07T02:46:29Z,This function should help to implement a generic wait_for_any on models of Future. ,viboes
10913,Missing std:: qualifier for pow call in units/test/test_output.cpp,units,Boost Development Trunk,To Be Determined,Bugs,Matthias Schabel,new,2015-01-06T19:05:56Z,2015-01-06T19:05:56Z,"Compiling test_output.cpp with Oracle Solaris Studio 12.4 compiler on Solaris 11.2 with -library=stlport4, we see

""../libs/units/test/test_output.cpp"", line 262: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 262: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 356: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 356: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 404: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 404: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 413: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 413: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 414: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 414: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 415: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 415: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 416: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 416: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 417: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 417: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 418: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 418: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 419: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 419: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 437: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 437: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 438: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 438: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 439: Error: The function ""pow"" must have a prototype.

The call to pow is unqualified and the following change resolves the issue.
% diff ./test_output.cpp ./test_output.cpp_orig
262c262
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 10) * byte_base_unit::unit_type(), ""1024 b"");
---
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 10) * byte_base_unit::unit_type(), ""1024 b"");
356c356
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 10) * byte_base_unit::unit_type(), ""1.024 kilobyte"");
---
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 10) * byte_base_unit::unit_type(), ""1.024 kilobyte"");
404c404
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 10) * byte_base_unit::unit_type(), ""1.024 kb"");
---
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 10) * byte_base_unit::unit_type(), ""1.024 kb"");
413,419c413,419
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 20) * byte_base_unit::unit_type(), ""1 Mib"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 30) * byte_base_unit::unit_type(), ""1 Gib"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 40) * byte_base_unit::unit_type(), ""1 Tib"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 50) * byte_base_unit::unit_type(), ""1 Pib"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 60) * byte_base_unit::unit_type(), ""1 Eib"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 70) * byte_base_unit::unit_type(), ""1 Zib"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 80) * byte_base_unit::unit_type(), ""1 Yib"");
---
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 20) * byte_base_unit::unit_type(), ""1 Mib"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 30) * byte_base_unit::unit_type(), ""1 Gib"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 40) * byte_base_unit::unit_type(), ""1 Tib"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 50) * byte_base_unit::unit_type(), ""1 Pib"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 60) * byte_base_unit::unit_type(), ""1 Eib"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 70) * byte_base_unit::unit_type(), ""1 Zib"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 80) * byte_base_unit::unit_type(), ""1 Yib"");
437,442c437,442
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 32) *byte_base_unit::unit_type(), ""4 gibibyte"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 41) *byte_base_unit::unit_type(), ""2 tebibyte""); // http://en.wikipedia.org/wiki/Tebibyte
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 50) *byte_base_unit::unit_type(), ""1 pebibyte"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 60) *byte_base_unit::unit_type(), ""1 exbibyte"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 70) *byte_base_unit::unit_type(), ""1 zebibyte"");
<     BOOST_UNITS_TEST_OUTPUT(std::pow(2., 80) *byte_base_unit::unit_type(), ""1 yobibyte"");
---
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 32) *byte_base_unit::unit_type(), ""4 gibibyte"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 41) *byte_base_unit::unit_type(), ""2 tebibyte""); // http://en.wikipedia.org/wiki/Tebibyte
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 50) *byte_base_unit::unit_type(), ""1 pebibyte"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 60) *byte_base_unit::unit_type(), ""1 exbibyte"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 70) *byte_base_unit::unit_type(), ""1 zebibyte"");
>     BOOST_UNITS_TEST_OUTPUT(pow(2., 80) *byte_base_unit::unit_type(), ""1 yobibyte"");
",Aparna Kumta <aparna.kumta@…>
10911,boost/iostreams/filter/zlib.hpp gives C4275 warning with visual studio,iostreams,Boost 1.57.0,To Be Determined,Bugs,Jonathan Turkanis,new,2015-01-02T14:50:08Z,2015-06-30T07:40:27Z,"please change the line

{{{
# pragma warning(disable:4251 4231 4660)         // Dependencies not exported.
}}}

to 

{{{
# pragma warning(disable:4251 4231 4660 4275)         // Dependencies not exported.
}}}

This will fix...

{{{
1>c:\development\boost_1_56_0\boost\iostreams\filter\zlib.hpp(138): warning C4275: non dll-interface class 'std::ios_base::failure' used as base for dll-interface class 'boost::iostreams::zlib_error'
1>          c:\program files (x86)\microsoft visual studio 12.0\vc\include\xiosbase(221) : see declaration of 'std::ios_base::failure'
1>          c:\development\boost_1_56_0\boost\iostreams\filter\zlib.hpp(138) : see declaration of 'boost::iostreams::zlib_error'
}}}",Joseph Southwell <joseph@…>
10910,arm64 value for <instruction-set> feature support,build,Boost 1.57.0,To Be Determined,Patches,Vladimir Prus,new,2014-12-30T11:21:49Z,2014-12-30T11:21:49Z,"I want to build boost for arm64 instruction set. But getting error:

    error: ""arm64"" is not a known value of feature <instruction-set>

This error occurs because builtin.jam file contains just following **valid** values for instruction-set feature:

    armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5t armv5te armv6 armv6j armv6j iwmmxt ep9312 armv7 armv7s

I also checked several versions of boost - all of them don't contain arm64 value at builtin.jam file. Meanwhile arm64 is a valid argument to **-arch** option for compiler (e.g. clang)

So my question is: why don't add there ""arm64"" value to the list of valid values for instruction-set feature? ",dmigous@…
10909,Problems with building boost system library using mingw,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2014-12-30T09:11:12Z,2014-12-30T09:11:12Z,"I'm trying to build 'system' library from Boost under Windows using command:

> bjam --toolset=gcc  target-os=qnx
> --build-dir=c:\boost_1_57_0  --build-type=complete --with-system stage

and keep getting error:

> C:\boost_1_57_0>bjam --toolset=gcc  target-os=qnx
> --build-dir=c:\boost_1_57_0  --build-type=complete --with-system stage ...found 1 target... ...updating 1 target... config-cache.write
> c:\boost_1_57_0\boost\bin.v2\project-cache.jam ...updated 1 target...
> 
> Component configuration:
> 
>     - atomic                   : not building
>     - chrono                   : not building
>     - container                : not building
>     - context                  : not building
>     - coroutine                : not building
>     - date_time                : not building
>     - exception                : not building
>     - filesystem               : not building
>     - graph                    : not building
>     - graph_parallel           : not building
>     - iostreams                : not building
>     - locale                   : not building
>     - log                      : not building
>     - math                     : not building
>     - mpi                      : not building
>     - program_options          : not building
>     - python                   : not building
>     - random                   : not building
>     - regex                    : not building
>     - serialization            : not building
>     - signals                  : not building
>     - system                   : building
>     - test                     : not building
>     - thread                   : not building
>     - timer                    : not building
>     - wave                     : not building
> 
> ...found 205 targets... ...updating 4 targets... gcc.link.dll
> c:\boost_1_57_0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\debug\target-os-qnx\threading-multi\libboost_system-mgw48-mt-d-1_57.so.1.57.0
> c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
> cannot find -lrt collect2.exe: error: ld returned 1 exit status
> 
>     ""g++""    -o ""c:\boost_1_57_0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\debug\target-os-qnx\threading-multi\libboost_system-mgw48-mt-d-1_57.so.1.57.0""
> -shared -Wl,--start-group ""c:\boost_1_57
> _0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\debug\target-os-qnx\threading-multi\error_code.o""
> -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread
> 
> ...failed gcc.link.dll
> c:\boost_1_57_0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\debug\target-os-qnx\threading-multi\libboost_system-mgw48-mt-d-1_57.so.1.57.0...
> ...skipped <pstage\lib>libboost_system-mgw48-mt-d-1_57.so.1.57.0 for
> lack of
> <pc:\boost_1_57_0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\debug\target-os-qnx\threading-multi>libboost_system-mgw48-
> mt-d-1_57.so.1.57.0... gcc.link.dll
> c:\boost_1_57_0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\release\target-os-qnx\threading-multi\libboost_system-mgw48-mt-1_57.so.1.57.0
> c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe:
> cannot find -lrt collect2.exe: error: ld returned 1 exit status
> 
>     ""g++""    -o ""c:\boost_1_57_0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\release\target-os-qnx\threading-multi\libboost_system-mgw48-mt-1_57.so.1.57.0""
> -shared -Wl,--start-group ""c:\boost_1_57
> _0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\release\target-os-qnx\threading-multi\error_code.o""
> -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -pthread
> 
> ...failed gcc.link.dll
> c:\boost_1_57_0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\release\target-os-qnx\threading-multi\libboost_system-mgw48-mt-1_57.so.1.57.0...
> ...skipped <pstage\lib>libboost_system-mgw48-mt-1_57.so.1.57.0 for
> lack of
> <pc:\boost_1_57_0\boost\bin.v2\libs\system\build\gcc-mingw-4.8.1\release\target-os-qnx\threading-multi>libboost_system-mgw48-
> mt-1_57.so.1.57.0... ...failed updating 2 targets... ...skipped 2
> targets...


The rt lib seems to be missing, where can I obtain such lib to successfully compile 'system' lib?

Changing bootstrap argument between gcc / mingw doesn't help.
Before using bootstrap I set path to mingw using:

> set PATH=c:\mingw\bin;%PATH%

and change bootstrap.bat in line 38 to: 
> set toolset=gcc

Any idea how to successfully compile system library under windows for QNX?","piotrek.orzechowski@…, com"
10907,Fix for mingw,interprocess,Boost 1.57.0,To Be Determined,Patches,Ion Gaztañaga,new,2014-12-29T22:40:14Z,2014-12-29T22:45:42Z,"Fix some problems for mingw, see github boostorg/interprocess pull request.


",Pavel Vatagin <pavelvat@…>
10906,"async_connect can't be stopped on boost 1.57, win 7 64bit",asio,Boost 1.57.0,Boost 1.58.0,Bugs,chris_kohlhoff,new,2014-12-29T16:05:27Z,2017-06-05T11:53:50Z,"I currently use Windows 7 64bit, MSVC2010 and Boost.Asio 1.57. I would like to connect to a TCP server with a timeout. If the timeout expires, I should close the connection as soon as possible as the IP address (chosen by a user) is probably wrong.

With my computer, closing the socket takes about 15 seconds to complete, which makes my program not responsive for a while.
On Linux the same code seems to be fine.
I attach a code that reproduce the problem.",anonymous
10903,planar_face_traversal function,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-12-27T04:53:22Z,2014-12-29T09:17:18Z,"Visual Studio 'Release' Configuration.
In function
  void planar_face_traversal(const Graph& g, 
                             PlanarEmbedding embedding, 
                             Visitor& visitor, EdgeIndexMap em
                             )

In the for loop
    for(boost::tie(fi,fi_end) = edges(g); fi != fi_end; ++fi)
as soon as it executes the line
    edge_t e(*fi);
the variable 'g' becomes null at runtime.
This is true for VS 2010, 2012, 2013.  For Debug configuration, it does not occur, but as soon as the code is put 'release' the problem is consistent.
It looks like a Visual Studio bug, but I am not sure how to claim a bug report to Microsoft.",dumnas@…
10900,read_symlink fails to correctly read NTFS junctions,filesystem,Boost 1.57.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-12-26T16:16:26Z,2017-09-22T08:59:32Z,"''Tested on Windows 7 64-bit.''

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

Among other things this also breaks the `canonical` operation.

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

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

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

In version 1.57.0 the offending code can be found in ''libs/filesystem/src/operations.cpp'' around line 1514.",Benjamin Kummer-Hardt <benjamin@…>
10899,symbol visibility: cannot catch an exception thrown by boost::throw_exception on mac OS,exception,Boost 1.55.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-12-26T12:56:32Z,2015-02-02T15:03:38Z,"
== The problem ==

The problem showed up with an exception from boost::property_tree, but I believe it is more general.

I have a library (named liba in the attached example) which
* is built with hidden symbols visibility
* uses boost::property_tree in a `deserialize()` function
* catch `boost::property_tree::ptree_bad_path` exception if any (so this is not an ""exception crossing dll boundary issue"")

This usually works (test_a works on all platforms) except when

* we're on mac os
* the `deserialize()` function is called from another library which also uses boost::property_tree

In such a case, liba fails to catch the `boost::property_tree::ptree_bad_path` exception (test_b fails on mac os, but passes on linux).

So, my problem is that on mac os, liba behaves differently depending on whether it's caller uses boost::property_tree or not.

== A tentative explanation ==

I think the problem comes from symbol visibility inconsistency:

* because of boost::throw_exception, the exception which is thrown is not a `boost::property_tree::ptree_bad_path` but a subclass `boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>`

* in `include/boost/exception/exception.hpp`, `error_info_injector` visibility is forced to be public (this change comes from #4594)
  {{{
#if defined(__GNUC__)
# if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4)
#  pragma GCC visibility push (default)
# endif
#endif
        template <class T>
        struct
        error_info_injector:
            public T,
            public exception
            {
            explicit
            error_info_injector( T const & x ):
                T(x)
                {
                }

            ~error_info_injector() throw()
                {
                }
            };
   }}}

* However, `boost::property_tree::ptree_bad_path` is still hidden:
  * there is no visibility #pragma in `include/boost/property_tree/exceptions.hpp` forcing it to be public
  * I build the library with hidden symbols by default
  * I want to catch the exception within the library, so I do not need to make the symbol public.


What seems to happen on mac (see the typeid adresses) when running test_b:

* symbol `boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>` is global, and ''the version from libb is used''.

* symbol `boost::property_tree::ptree_bad_path` is private, each lib uses its own version

* within liba, `boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>` is thrown, but liba fails to upcast it to its own version of `boost::property_tree::ptree_bad_path`, so it catches it as std::exception instead (and throw it again)

* then within libb, the exception is caught again, but this time casting it to libb's version `boost::property_tree::ptree_bad_path` works.

When calling the `serialize()` function from test_a (which does not use boost::property_tree), there is no symbol confusion and the exception is caught within liba, as expected.

If this is right, the root cause is that one class is hidden and the other not. If we make both exception classes public or private, then it works as expected.

I'm not sure why test_b passes on linux, it may have something to do with weak symbols: nm shows the public symbols as weak on linux, but not on mac.

== Building and running on mac ==

{{{
$ make clean
rm -f src/a.o src/liba.so src/test_a.o src/test_a src/b.o src/libb.so src/test_b.o src/test_b src/*.swp *.swp src/.a* src/.b*

$ make all
c++ -c -g -Iinclude -o src/test_a.o src/test_a.cc
c++ -c -g -fPIC -Da_EXPORTS -Iinclude -I/Users/hcuche/.local/share/qi/toolchains/mac64/boost/include -o src/a.o src/a.cc
c++ -shared -Wl -o src/liba.so src/a.o
clang: warning: unknown warning option '-Wl'
c++  -Lsrc -o src/test_a src/test_a.o -la
c++ -c -g -Iinclude -o src/test_b.o src/test_b.cc
c++ -c -g -fPIC -fvisibility=hidden -Db_EXPORTS -Iinclude -I/Users/hcuche/.local/share/qi/toolchains/mac64/boost/include -o src/b.o src/b.cc
c++ -shared -Wl -o src/libb.so src/b.o src/liba.so
clang: warning: unknown warning option '-Wl'
c++ -Lsrc -o src/test_b src/test_b.o -lb -la

$ DYLD_LIBRARY_PATH=./src ./src/test_a
A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x1085f2ed0
A::deserialize typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x1085f2f00
A::deserialize caught ptree_bad_path with typeid 0x1085f32d0
test_a: OK got ""A::deserialize caught ptree_bad_path""

$ DYLD_LIBRARY_PATH=./src ./src/test_b                                                                        B::load typeid(boost::property_tree::ptree_bad_path): 0x10515f3d0
B::load typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x10515f400
A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x105197ed0
A::deserialize typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x10515f400
A::deserialize caught std::exception with typeid 0x1051982d0
A::load caught ptree_bad_path with typeid 0x1051982d0
test_b: KO got ""B::load caught ptree_bad_path""

$ c++ --version                                                                                                                                                                                                                                                                                          
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
}}}

== Building and running on linux with gcc ==

{{{
$ make clean
rm -f src/*.o src/*.so src/test_a src/test_b src/.a* src/.b* ._* src/._* include/._*

$ make all
g++ -c -g -Iinclude -o src/test_a.o src/test_a.cc
g++ -c -g -fPIC -Da_EXPORTS -Iinclude -I/home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include -o src/a.o src/a.cc
g++ -shared -Wl -o src/liba.so src/a.o
g++  -Lsrc -o src/test_a src/test_a.o -la
g++ -c -g -Iinclude -o src/test_b.o src/test_b.cc
g++ -c -g -fPIC -fvisibility=hidden -Db_EXPORTS -Iinclude -I/home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include -o src/b.o src/b.cc
g++ -shared -Wl -o src/libb.so src/b.o src/liba.so
g++ -Lsrc -o src/test_b src/test_b.o -lb -la

$ LD_LIBRARY_PATH=./src ./src/test_a
A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x7f1912652c60
A::deserialize typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x7f1912652c20
A::deserialize caught ptree_bad_path with typeid 0x7f1912652b80
test_a: OK got ""A::deserialize caught ptree_bad_path""

$ LD_LIBRARY_PATH=./src ./src/test_b
B::load typeid(boost::property_tree::ptree_bad_path): 0x7fefc97dfce0
B::load typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x7fefc97dfca0
A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x7fefc95cdc60
A::deserialize typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x7fefc97dfca0
A::deserialize caught ptree_bad_path with typeid 0x7fefc95cdb80
test_b: OK got ""A::deserialize caught ptree_bad_path""

$ g++ --version
g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 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.
}}}

== Building and running on linux with clang ==

{{{
$ make clean
rm -f src/*.o src/*.so src/test_a src/test_b src/.a* src/.b* ._* src/._* include/._*

$ CXX=clang++ make all
clang++ -c -g -Iinclude -o src/test_a.o src/test_a.cc
clang++ -c -g -fPIC -Da_EXPORTS -Iinclude -I/home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include -o src/a.o src/a.cc
clang++ -shared -Wl -o src/liba.so src/a.o
clang++  -Lsrc -o src/test_a src/test_a.o -la
clang++ -c -g -Iinclude -o src/test_b.o src/test_b.cc
clang++ -c -g -fPIC -fvisibility=hidden -Db_EXPORTS -Iinclude -I/home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include -o src/b.o src/b.cc
clang++ -shared -Wl -o src/libb.so src/b.o src/liba.so
clang++ -Lsrc -o src/test_b src/test_b.o -lb -la

$ LD_LIBRARY_PATH=./src ./src/test_a
A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x7f8bfa09e800
A::deserialize typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x7f8bfa09e830
A::deserialize caught ptree_bad_path with typeid 0x7f8bfa09ec00
test_a: OK got ""A::deserialize caught ptree_bad_path""

$ LD_LIBRARY_PATH=./src ./src/test_b
B::load typeid(boost::property_tree::ptree_bad_path): 0x7f1d50790920
B::load typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x7f1d50790950
A::deserialize typeid(boost::property_tree::ptree_bad_path): 0x7f1d5057d800
A::deserialize typeid(boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_path>): 0x7f1d5057d830
A::deserialize caught ptree_bad_path with typeid 0x7f1d5057dc00
test_b: OK got ""A::deserialize caught ptree_bad_path""

$ clang++ --version
Ubuntu clang version 3.3-5ubuntu4~precise1 (branches/release_33) (based on LLVM 3.3)
Target: x86_64-pc-linux-gnu
Thread model: posix
}}}",Sébastien Barthélémy <barthelemy@…>
10898,Variadic constructor for ssl::stream so it can wrap streams whose constructors take n arguments,asio,Boost 1.57.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-12-24T16:56:32Z,2014-12-24T16:56:32Z,"I have specific use case ( passing through a proxy ) where I need to wrap an ssl stream in an ssl stream. This becomes possible if I change the constructor for ssl stream as follows. 

{{{
#!cpp
template <typename ...Arg>
  stream(context& ctx, Arg&& ...arg)
    : next_layer_(std::forward<Arg>(arg)...),
      core_(ctx.native_handle(), next_layer_.lowest_layer().get_io_service())
  {
    backwards_compatible_impl_.ssl = core_.engine_.native_handle();
  }
}}}}",Joseph Southwell <joseph@…>
10897,Pool allocator does not perfect forward its arguments,pool,Boost 1.58.0,To Be Determined,Feature Requests,Chris Newbold,new,2014-12-24T15:17:51Z,2016-06-13T14:17:05Z,"The pool_allocator library has not been updated to C++11 yet.
One of the greatest missing feature is the lack of perfect forwarding of the parameters of ""conctruct"" in pool_allocator and fast_pool_allocator.
This prevent the move constructor of the allocated object to be called.
Right now the construct implementation is as follow:

{{{
static void construct(const pointer ptr, const value_type & t)
{ new (ptr) T(t); }
}}}

while it should be:
{{{
template<typename ...Args>
static void construct(const pointer ptr, Args&& ...args)
{ new (ptr) T(std::forward<Args> (args)...); }
}}}
",bertello.matteo@…
10896,astar_maze.cpp: Debug assertion under Windows MSVC-12,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-12-24T12:34:03Z,2015-12-16T14:35:48Z,"Dear maintainers,
the example astar_maze.cpp compiled under Windows 7 x64 as 32 Bit executable, throws a debug assertion. See the callstack (attachment). I called this example without any arguments from the debugger so it used the default grid size of 20x20. 

The assertion get triggered at

       bucket_pointer get_bucket(std::size_t bucket_index) const
        {
--->        BOOST_ASSERT(buckets_);
            return buckets_ + static_cast<std::ptrdiff_t>(bucket_index);
        }

buckets_ is nullptr.

Environment:
Windows 7 x 64
Visual Studio 2013 Update 4 Express for Desktop

Attachments:
- callstack
- minidump
- solution folder (compressed)

",georg@…
10895,graph - copy_component is broken,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-12-23T21:13:48Z,2015-04-23T21:40:19Z,"I noticed two issues with copy_component in graph/copy.hpp.

1. The non-named parameter version gives compiler error due to failing look up:

{{{
    return detail::copy_component_impl
      (g_in, src, g_out,
       make_vertex_copier(g_in, g_out), 
       make_edge_copier(g_in, g_out), 
       make_iterator_property_map(orig2copy.begin(), 
                                  get(vertex_index, g_in), orig2copy[0]),
       bgl_named_params<char,char>('x') // dummy param object
       );
}}}


error: 'make_vertex_copier' was not declared in this scope.

Prefixing them with '''detail::''' solves this issue. This change makes it similar to copy_graph which also refers to the detail namespace for these functions.

Fixed version:

{{{
    return detail::copy_component_impl
      (g_in, src, g_out,
       detail::make_vertex_copier(g_in, g_out), 
       detail::make_edge_copier(g_in, g_out), 
       make_iterator_property_map(orig2copy.begin(), 
                                  get(vertex_index, g_in), orig2copy[0]),
       bgl_named_params<char,char>('x') // dummy param object
       );
}}}


2. In graph_copy_visitor struct's '''copy_one_vertex''' member function, the template arguments include '''class Graph''' but it is not used (neither in the function arguments nor inside the func. body). 


{{{
      template <class Vertex, class Graph>
      typename graph_traits<NewGraph>::vertex_descriptor copy_one_vertex(Vertex u) const { ... }

}}}

So the compiler complains about the failing deduction.

error: template argument deduction/substitution failed: note:   couldn't deduce template parameter 'Graph'

Fix: Removing the template argument class Graph fixes the issue.


{{{
      template <class Vertex>
      typename graph_traits<NewGraph>::vertex_descriptor copy_one_vertex(Vertex u) const { ... }

}}}

Note: Tried with GCC 4.7.2 and 4.8.3 ",erdem@…
10894,"Add an adaptor to iterate a range in pairs of (current element, next element)",range,Boost Development Trunk,To Be Determined,Feature Requests,Neil Groves,new,2014-12-23T12:07:00Z,2016-01-21T08:51:26Z,"An often needed functionality is iterating a range and accessing the current and next element of the range.

Currently this can be done as follows:
{{{#!C++
assert(someVec.size > 1);
for(auto const & pair, boost::make_iterator_range(
    boost::make_zip_iterator(
        boost::make_tuple(
            someVec.cbegin(), std::next(someVec.cbegin()))),
    boost::make_zip_iterator(
        boost::make_tuple(
            std::prev(someVec.cend()), someVec.cend())))
        )
{
    auto current = boost::get<0>(pair);
    auto next    = boost::get<1>(pair);
}
}}}

An adaptor would strongly increase readability:
{{{#!C++
assert(someVec.size > 1);
using boost::adaptors::operator|;
for(auto const & pair, someVec | boost::adaptors::paired())
{
    pair.current();
    pair.next();
}
}}}

Of course the difference between current and next could be made customizable as well.","Matthäus Brandl (brandl.matthaeus@…, com)"
10892,Boost Asio,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-12-22T19:52:05Z,2014-12-22T19:52:05Z,"I have posted on stackoverflow to see if I am implementing the TCP Server incorrectly, but this has worked for me for years. 

http://stackoverflow.com/questions/27609306/boost-asio-error

I think I wrote it originally with Boost 1.38, and upgraded boost versions about every 6 months. Around Boost 1.47 I ran into this problem, but I just used BOOST_ASIO_ENABLE_OLD_SSL to continue running with the old SSL logic to make it work. I am now trying to fix it because I think the older SSL logic may be contributing to another bug in the code.

It could be that the older SSL logic didn't check everything it was supposed to, and this is the correct functionality. But if that is the case, I'm not sure what I am doing wrong.",Matthew Mueller <Matthew.a.mueller@…>
10891,Uneeded usage of namespace causes problems for the compiler,units,Boost 1.57.0,To Be Determined,Bugs,Matthias Schabel,new,2014-12-22T19:34:55Z,2015-02-13T18:30:09Z,"Problem due to unnecessary

{{{
using namespace detail;
}}}

on several occasions in boost/units/cmath.hpp

Compare Boost ticket 8651 (https://svn.boost.org/trac/boost/ticket/8651) for the equivalent workaround in variant and Gcc bug 57524 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524) for original bug.",anonymous
10885,Serialization relies upon exceptions,date_time,Boost 1.56.0,To Be Determined,Bugs,az_sw_dude,new,2014-12-19T08:33:36Z,2014-12-19T08:33:36Z,Loading and saving ::boost::gregorian::date in greg_serialize.hpp relies upon an exception to detect if the serialized string corresponds to a special value. This has a negative effect on the runtime in debug mode.,anonymous
10884,Support for Clang using std::chrono in boost::asio,asio,Boost 1.57.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-12-18T18:12:08Z,2014-12-18T18:12:08Z,"boost automatically detects that gcc can use std::chrono, but clang requires defining BOOST_ASIO_HAS_STD_CHRONO.  It would be nice if clang were detected as well",robotoman@…
10883,Using allow-long-disguise misspelled options become positionals,program_options,Boost 1.57.0,To Be Determined,Bugs,Vladimir Prus,new,2014-12-18T13:13:51Z,2014-12-23T10:25:45Z,"Using allow-long-disguise in the parsing style, misspelled options are downgraded to positionals. The resulting error message: ""too many positional options"" is confusing and doesn't help at all the user to detect the error.",pellegrini.dario@…
10881,address-model=64 combined with --with-libraries results in x86 built,Getting Started Guide,Boost 1.57.0,To Be Determined,Bugs,Dave Abrahams,new,2014-12-18T10:55:57Z,2014-12-18T10:55:57Z,"Maybe my approach is wrong but this

./bootstrap.sh address-model=64

results in building all libraries for x64 architecture and this


./bootstrap.sh address-model=64 --with-libraries=atomic,chrono,date_time,filesystem

Results in atomic,chrono,date_time,filesystem being built for x86. Why?



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

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

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

Nevertheless, this temporaray way works out:

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



",a.carot@…
10876,windows_intermodule_singleton breaks when mixing debug/release dll/exe,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-12-16T11:14:43Z,2014-12-16T11:14:43Z,"Ticket #9262 describes a problem related to windows_intermodule_singleton being created in one runtime and then accessed in another (debug/release runtimes). I believe there is at least one more ""problematic"" object besides the std::map that from boost 1.56 is replaced with boost::container::map.  

The struct windows_bootstamp contains a std::string and since objects of this type is created in shared memory the problem with mixed runtimes is still there.",anders.widen@…
10874,Tips To Understanding The Important Details Of Van Insurance,accumulator,Boost 1.46.0,Website 1.X,Patches,Eric Niebler,new,2014-12-14T21:44:21Z,2014-12-14T21:44:21Z,"[[iframe http://www.veoh.com/static/swf/veoh/SPL.swf?videoAutoPlay=0&permalinkId=v197427717WbmxKED height=""498"" width=""510""]]You may be a new car owner, or someone thinking about buying a car, or just in the market for better deals on your auto insurance. Regardless of the situation, it's critical to know how to the best deal - and the best coverage - when shopping for auto insurance.

Learning about car insurance can help you to find the best policy and rate for you. You want to make sure that you are covered and you should understand that coverage so that you know what you are paying for. Property damage liability covers you in the event that your vehicle hits someones property. It is a required coverage in all but 3 states.

One, less well-known way to get further discounts on auto insurance, especially if you have a teen driver around who is only going back  young driver van insurance and forth to school, is to request whether your insurance offers a discount for low mileage. If you can accurately estimate the actual mileage your teen drives and report it accurately, you will pay less.

When trying to get a lower rate on your auto  cheap van insurance for young drivers insurance, don't be afraid to shop around. Auto insurance companies use different formulas to calculate who is a higher risk driver and therefore who has higher premiums. Even a slightly different set of questions could mean big savings for you.

When considering what options you want to include with your auto insurance, be sure to see if towing insurance is something that you really need. Oftentimes towing is already included in certain types of accidents. If you belong to certain auto assistance agencies, they may already provide this coverage to you. Most often, it is not financially beneficial to include this extra.

Before signing up for an insurance, you should carefully go over the policy. Pay a professional to explain it to you, if you need to. You must know what you will be covered for, in order to assess if you will be getting your money's worth. If the policy seems written in such a way that does not make it accessible, your insurance company might be trying to hide something.

Check out your state's minimum insurance guidelines, and follow them. Some states only require you to have liability coverage, but others require personal injury as well. Make sure you know your state's practices so that you do not fail to meet them, and end up with a ticket for not having enough coverage.

If you have other drivers on your insurance policy, remove them to get a better deal. Most insurance companies have a ""guest"" clause, meaning that you can occasionally allow someone to drive your car and be covered, as long as they have your permission. If your roommate only drives your car twice a month, there's no reason they should be on there!

When you have any kind of questions regarding exactly where in addition to tips  commercial van insurance quote on how to make use of [http://vaninsurance.company/ multi car and van insurance], it is possible to call us with the web site. When purchasing car insurance, consider opting for the highest deductible option you can get to keep your premiums low. To make sure you have the money to pay the deductible if you should need it, bank the difference from the expensive premium you would pay for a lower deductible. A safe driver will come out way ahead over time.

Never drive your car without liability insurance. This insurance type can save you a lot of money as the insurance company pays the damages you caused to someone. Without this insurance type, you would be liable for all the costs. Choose the coverage that is right for you and your unique situation.

Avoid auto insurance extremes. You can definitely be hurt by a lack of adequate insurance. Even more costly is being over-insured. Many people pay for coverage they can not ever possibly need. The result can be a huge drain on your budget. Evaluate your car insurance coverage and rates annually.

Shopping for auto insurance often feels overwhelming to many people, but it need not be a stressful experience. By taking the time to educate yourself on auto insurance and the many options available to you, you will be able to make the choice that is right for you and your needs.",dianagillan@…
10872,MSVC static analyser warning in Boost.System,system,Boost 1.57.0,To Be Determined,Bugs,Beman Dawes,new,2014-12-14T01:04:19Z,2014-12-15T16:55:18Z,"boost\system\detail\error_code.ipp(422) : warning C6102: Using 'lpMsgBuf' from failed function call at line '418'.: Lines: 410, 411, 422",Niall Douglas
10871,Warnings in Boost.System when built on 64 bit system on MSVC,system,Boost 1.57.0,To Be Determined,Bugs,Beman Dawes,new,2014-12-14T01:00:56Z,2014-12-15T16:57:17Z,"
.\boost/system/detail/error_code.ipp(384) : warning C4267: 'argument' : conversion from 'size_t' to 'DWORD', possible loss of data
.\boost/system/detail/error_code.ipp(401) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
",Niall Douglas
10868,Intersecting integer polygons produces incorrect or self-intersecting result,geometry,Boost 1.57.0,To Be Determined,Bugs,Barend Gehrels,new,2014-12-11T21:48:25Z,2015-05-27T21:27:18Z,"I've noticed several instances of Boost.Geometry returning incorrect or self-intersecting polygons when working in integers (32 and 64 bit).

EXAMPLE:
Polygon A has vertices
(42817136,-3774506), (43029074,-3929862), (31446819,18947953), (30772384,19615678), (30101303,19612322), (30114725,16928001), (33520458,6878575), (35332375,2413654), (35725796,2024148), (42817136,-3774506)

Polygon B has vertices
(-33386239,-33721784), (33721785,-33386239), (33386240,33721785), (-33721784,33386240)

Intersecting Polygon A and Polygon B returns:

A correct but self-intersecting polygon using Boost 1.55

An incorrect polygon using Boost 1.57 and int64_t coordinates

An incorrect and self-intersecting polygon using Boost 1.57 and int32_t coordinates.

For both Boost 1.57 tests, I enabled BOOST_GEOMETRY_NO_ROBUSTNESS to avoid floating point rescaling.",starinshak1@…
10867,Undocumented precondition for extended_p_square accumulator,accumulator,Boost 1.57.0,To Be Determined,Bugs,Eric Niebler,new,2014-12-11T13:50:13Z,2014-12-11T13:50:13Z,"probs has to be sorted ascendingly for correct results. This is not mentioned in the documentation.

typedef accumulator_set<double, stats<tag::extended_p_square> > accumulator_t;
accumulator_t acc(tag::extended_p_square::probabilities = probs);
",Jens.Decker@…
10865,boost::iterators::transform_iterator<LambdaType> is not default constructible on Clang,range,Boost 1.57.0,Boost 1.58.0,Bugs,Neil Groves,assigned,2014-12-11T09:49:25Z,2015-02-02T01:12:09Z,"The attached code compiles with GCC 4.9.2 and MSVC 2013, but fails with Clang 3.5.0.
I've first reported it against clang, but they explained that it's actually incorrect in Boost,
see clang bug #21787 (the bugtracker rejects links here).
",Balázs Kádár <Balzs.Kdr.ext@…>
10864,Boost 1.57 + Xcode 6: function/lamba incompatibility,lambda,Boost 1.57.0,To Be Determined,Bugs,No-Maintainer,new,2014-12-10T18:24:56Z,2014-12-10T19:03:24Z,"Boost 1.57 and clang 6 (from Xcode 6) reject this program:

{{{
#include <iostream>
#include <boost/lambda/lambda.hpp>
#include <boost/function.hpp>

typedef boost::function<void(std::ostream&)> Streamer;

void out(const Streamer& func)
{
    func(std::cout);
}

int main(int argc, char *argv[])
{
    out(boost::lambda::_1 << ""hi there\n"");
    return 0;
}
}}}

Errors start with:

{{{
boost/lambda/detail/lambda_traits.hpp:256:58: error: cannot form a reference to 'void'
      typename detail::IF<boost::is_function<T>::value, T&, const T>::RET
                                                         ^
}}}

This works with Boost 1.55 with clang 6.

This works with Boost 1.57 with older compilers.",nat@…
10860,Switch to 1.57 causes crash in xpressive lib in Win64 release configuration,xpressive,Boost 1.57.0,To Be Determined,Bugs,Eric Niebler,new,2014-12-09T09:08:08Z,2014-12-09T09:08:08Z,"Check for attached code, I simplified original code as much as possible so don't bother with logic. 

Crash happens in xpressive/detail/static/compile.hpp loc 38, but only in Windows 64-bit release configuration ( any other: Linux (g++ 4.8.2,) or debug or 32-bit work just fine ). I use Visual Studio 2013 Update 4 for Win build.

Addition INFO: If you build w/o NDEBUG symbol defined or if you turned off optimization it works fine.

P.S. This code works fine with boost 1.51 and Visual Studio 2010. 
",Ivan Sakic <ivansakic@…>
10859,Minor typo in Boost.Interprocess,interprocess,Boost Development Trunk,To Be Determined,Patches,Ion Gaztañaga,new,2014-12-09T03:10:16Z,2014-12-09T03:10:16Z,Patch attached.,oss.2012.team+2014E@…
10850,"gcc-x86-implementation of ""atomic_exchange_and_add"" triggers intel's ""unitialized variable"" runtime check",smart_ptr,Boost Development Trunk,To Be Determined,Patches,Peter Dimov,new,2014-12-04T18:21:44Z,2014-12-04T18:23:51Z,"The current implementation of atomic_exchange_and_add for gcc x86 is (http://svn.boost.org/svn/boost/trunk/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp) as following:

inline int atomic_exchange_and_add( int * pw, int dv )
{
    // int r = *pw;
    // *pw += dv;
    // return r;

    int r;

    __asm__ __volatile__
    (
        ""lock\n\t""
        ""xadd %1, %0"":
        ""=m""( *pw ), ""=r""( r ): // outputs (%0, %1)
        ""m""( *pw ), ""1""( dv ): // inputs (%2, %3 == %1)
        ""memory"", ""cc"" // clobbers
    );

    return r;
}

This unfortunately triggers the ""unitialized variable"" runtime check of the Intel c++ compiler. Since r is actually superfluous, a simple patch can fix the problem:

inline int atomic_exchange_and_add( int * pw, int dv )
{
    // int r = *pw;
    // *pw += dv;
    // return r;
 
    __asm__ __volatile__
    (
        ""lock\n\t""
        ""xadd %1, %0"":
        ""+m""( *pw ), ""+r""( dv ): // input/output (%0, %1)
                :
        ""memory"", ""cc"" // clobbers
    );
 
    return dv;
}
 
My  colleague, who wrote the patch, checked that the generated assembler code is almost identical to the original one. ""Almost"" in the sense, that the removal of r changes some offsets.",fabian.hachenberg@…
10849,Dereferencing null pointer in Point<>::dimension_checker::apply(),geometry,Boost 1.57.0,To Be Determined,Bugs,Barend Gehrels,new,2014-12-04T18:21:04Z,2014-12-15T23:08:50Z,"The following lines:
            P* p = 0;
            geometry::set<Dimension>(*p, geometry::get<Dimension>(*p));

indicate that the first parameter of the set<>() call will be a null pointer if it is evaluated before the call to get<>().

If this is intentional *and* you can guarantee that the get<>() call will always be made before the first parameter is evaluated, then it should be documented with comments inline. Or, better yet, split the code into 2 lines to insure *p isn't an attempt to dereference a null pointer and to insure that static code checkers don't think it is.",Steve Hickman <steve.hickman@…>
10848,try_acquire_file_lock/ try_acquire_file_lock_sharable uses = instead of == in comparison,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-12-04T18:13:38Z,2014-12-04T18:13:38Z,"The last line for both try_acquire_file_lock and try_acquire_file_lock_sharable is:

   return (acquired = true);

It is unclear if the use of assignment ('=') instead of comparison ('==') here is intentional. My static analysis checker picked it up as a bug. If this is intentional, it should be documented with comments inline. Or, better yet, split into 2 lines of code so static analysis doesn't flag it.",Steve Hickman <steve.hickman@…>
10846,Bug in python::detail::cv_tag<>,python USE GITHUB,Boost 1.57.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2014-12-04T12:56:37Z,2014-12-04T13:05:40Z,"I believe I spotted a bug in boost/python/detail/cv_category.hpp. In cv_tag the constant is_volatile is initialized with is_const_.

[https://github.com/boostorg/python/blob/master/include/boost/python/detail/cv_category.hpp#L15]

",David Siegel <david@…>
10842,Boost.Parameter: Class Template parameter can't be abstract,parameter,Boost 1.56.0,To Be Determined,Bugs,Daniel Wallin,new,2014-12-03T08:52:38Z,2014-12-03T08:53:09Z,"VS 2013 fails to compile when abstract class is passed as class template parameter with error ""cannot instantiate abstract class"".
Sample:

#include <boost/parameter.hpp>

class Intf
{
public:
  virtual void func() = 0;
};

BOOST_PARAMETER_TEMPLATE_KEYWORD(param)

template<class Arg>
class P
{
public:
  typedef typename boost::parameter::parameters<
    boost::parameter::optional<tag::param>
  >::bind<Arg>::type args;
  typedef typename boost::parameter::value_type<args, tag::param, void>::type param_type;
};

int main()
{
  P<param<Intf> > p;
	return 0;
}",o0o0@…
10841,runtime error boost::numeric:;odeint::,odeint,Boost 1.56.0,To Be Determined,Bugs,karsten,new,2014-12-03T04:32:55Z,2015-01-29T21:43:18Z,"Dear all, 

I encountered a run-time error while using odeint. In a class method this command is executed:

{{{
size_t size =boost::numeric::odeint::integrate(model, x, 0.0, 1.0, 0.1);
}}}

when x is a VECTOR defined as:

{{{
typedef std::vector<double> state_type;
}}}

No compile, link errors occur; however, in run-time following window pops up after some iteration of the integrator.
It says: 
'''vector iterator not incrementable.''' as shown in figure attached.


By changing vector definition to array definition the problem will be resolved. So the following works when 3 is number of states:


{{{
typedef boost::array< double , 3 > state_type;
}}}

This problem happens by use of the odeint-v2 commit messaged ""fixes #142, fixes boost include issue in bjam"" and boost 1.56.0 on Windows 8 64 bits, Visual Studio 2012, platform v110 (equivalent c++11).",taghia.javad@…
10834,ptr_array cannot be used with boost::nullable<T> as type parameter,ptr_container,Boost 1.57.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-12-02T09:45:51Z,2014-12-02T09:54:07Z,"The copy constructor of ptr_array uses operator[] to access the elements of the ptr_array to copy.[[BR]]
Problem one: It is not save to call ptr_array[i] if element i is null.[[BR]]
Problem two: Operator[] returns a reference to remove_nullable<T>::type.
The address of this object is then casted to const T*, which fails with
compilation error C2664 if T=nullable<X>, because X* cannot be casted to nullable<X>*.

Reproduction: compile attached test.cpp[[BR]]
Possible fix: see attached patch[[BR]]
[[BR]]
Regards,
Florian",florian.schmid1978@…
10831,ublas OneElement returns 0.0,uBLAS,Boost 1.57.0,To Be Determined,Bugs,Gunter,new,2014-12-01T14:03:24Z,2015-01-14T13:23:57Z,"In ublas::detail::concepts.hpp the function 
<template class T>
OneElement(T)
{
   return T(0.0);
}
returns 0 for all types. In older versions the function returned 1.f 1. for floats and doubles etc.

This breaks some client code. In my case the Mkl bindings (Math Kernel Library of Intel) for ublas.",r.r.ottenhoff@…
10830,Clang static analyzer warns about <boost/graph/named_function_params.hpp>,graph,Boost 1.57.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-12-01T13:52:53Z,2018-03-14T13:38:31Z,"When running the clang static analyzer (v3.4.1) on some code of mine that uses boost graph, it reports this warning about boost/graph/named_function_params.hpp:

/usr/local/include/boost/graph/named_function_params.hpp:240:5: warning: Address of stack memory associated with temporary object of type 'boost::param_not_found' returned to caller
    return lookup_named_param_def<Tag, Args, param_not_found>::get(p, param_not_found());
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.

I believe that's a genuine error.",anonymous
10829,"cardinality() of an interval_set is std::size_t independent of interval type, causing overflow",ICL,Boost 1.49.0,To Be Determined,Bugs,Joachim Faulhaber,new,2014-12-01T09:32:41Z,2014-12-01T10:47:41Z,"For an interval_set boost::icl::interval_set<int64_t>, the cardinality function boost::icl::cardinality() returns std::size_t, which is 32-bit on 32-bit machines. This makes the result wrong, due to overflow, whenever the cardinality of the interval_set does not fit into 32-bit.

The following code works on 64-bit but not on 32-bit:

{{{
#include <boost/icl/interval_set.hpp>

int main()
{
    boost::icl::interval_set<int64_t> is;
    is.add(boost::icl::interval<int64_t>::closed(1, 4294967297LL));
    assert(boost::icl::cardinality(is) == 4294967297LL);
}
}}}",konstantin.miller@…
10828,Boost asio ssl: password callback not called if private key passed with context::use_private_key,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-30T22:32:52Z,2014-11-30T22:38:53Z,"I'm writing a test unit that uses the boost asio ssl.

I'm using Boost 1.54 on Ubuntu 14.04 64 bit.

I plan to make the test self-sufficient and not rely on files to specify the private key, so I want to hard encode the key and its password in the test itself (they are just test key and password).

The code is below. For now it does nothing but I'm just trying to make the password callback work when the private key is specified:
------------------- CODE -------------------------
std::string password_callback(
  std::size_t max_length,
  boost::asio::ssl::context::password_purpose purpose)
{
    return ""test"";
}

TEST(StreamReader, sslStream)
{

    std::string certificate = ""-----BEGIN CERTIFICATE-----\n\
MIIFJjCCAw4CCQDQjrFrRcdRkjANBgkqhkiG9w0BAQsFADBVMQswCQYDVQQGEwJT\n\
BLABLABLABLA"";

    std::string key = ""-----BEGIN RSA PRIVATE KEY-----\n\
Proc-Type: 4,ENCRYPTED\n\
DEK-Info: DES-EDE3-CBC,06622C22CAB27AC2\n\
\n\
JMudxXy4ZxB733xh7QO4elsVCTzJZuWl9Go4ZMuWx0DZb2fYHqXynKZSf7UactSw\n\
vhKJnLPZaa5U+xOr9cdpSd3SwtQyNu6yaVQH3af2ILRwUsw9mQmI8yqIIF1Y6AgV\n\
BLABLABLABLA"";

    boost::asio::io_service io_service;
    boost::asio::ssl::context ctx(boost::asio::ssl::context::tlsv12);
    ctx.set_password_callback(password_callback);
    ctx.use_certificate(boost::asio::const_buffer(certificate.c_str(), certificate.size()), boost::asio::ssl::context::pem);
    ctx.use_private_key(boost::asio::const_buffer(key.c_str(), key.size()), boost::asio::ssl::context::pem);
    ctx.set_verify_mode(boost::asio::ssl::verify_peer);
}
---------------------ENDCODE-------------------------

When use_private_key is executed then the password callback is not called and I have to enter the password manually in the console. If I replace use_private_key with use_private_key_file then the callback is called.

I would expect password_callback to be called also when use_private_key is used.

Checking the internals of use_private_key I find this:
boost::system::error_code context::use_private_key(
    const const_buffer& private_key, context::file_format format,
    boost::system::error_code& ec)
{
  ::ERR_clear_error();

  bio_cleanup bio = { make_buffer_bio(private_key) };
  if (bio.p)
  {
    evp_pkey_cleanup evp_private_key = { 0 };
    switch (format)
    {
    case context_base::asn1:
      evp_private_key.p = ::d2i_PrivateKey_bio(bio.p, 0);
      break;
    case context_base::pem:
      evp_private_key.p = ::PEM_read_bio_PrivateKey(bio.p, 0, 0, 0);
      break;
    default:
      {
        ec = boost::asio::error::invalid_argument;
        return ec;
      }
    }

    if (evp_private_key.p)
    {
      if (::SSL_CTX_use_PrivateKey(handle_, evp_private_key.p) == 1)
      {
        ec = boost::system::error_code();
        return ec;
      }
    }
  }

  ec = boost::system::error_code(
      static_cast<int>(::ERR_get_error()),
      boost::asio::error::get_ssl_category());
  return ec;
}

PEM_read_bio_PrivateKey accepts a callback parameter or a passphrase, but they are left null.
",Paolo Brandoli <paolo.brandoli@…>
10819,Error in the documentation,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-11-26T11:49:50Z,2015-02-13T18:36:17Z,"Hello,

I found an little error in your documentation.
In the chapter on message queues :
http://www.boost.org/doc/libs/1_36_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.message_queue

Under the ""Using a message queue"" title, in the third code example, you have :

{{{
      message_queue mq
         (open_only        //only create
         ,""message_queue""  //name
         );
}}}

And the commentary line ""//only create"" is wrong : the code actually opens the queue in ""open only"".

Best regards
Gilles",gilles.lourdelet@…
10818,"A C4267 ""possible loss of data"" warning when compiling on VS2013 x64 with /W4",dynamic_bitset,Boost 1.56.0,To Be Determined,Bugs,jsiek,new,2014-11-26T06:14:30Z,2014-11-26T06:14:30Z,"Example:
  boost::dynamic_bitset<> flags;
...
  bool b = flags[56];
Warning when calling the reference class constructor from the [] operator.

Compiler -- VS2013, Platform -- x64, Debug mode, Warning level -- /W4.

Fix:  I found if you changed the pos parameter of the reference class constructor to size_type, the warning went away.

From:
  reference(block_type & b, block_type pos)
To:
  reference(block_type & b, size_type pos)
Location Line 88 of dynamic_bitset.hpp


Actual error message:

4>C:\Boost\1_56_0-VS_2013-x64\include\boost-1_56\boost/dynamic_bitset/dynamic_bitset.hpp(296): warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long', possible loss of data
4>          C:\Boost\1_56_0-VS_2013-x64\include\boost-1_56\boost/dynamic_bitset/dynamic_bitset.hpp(295) : while compiling class template member function 'boost::dynamic_bitset<unsigned long,std::allocator<Block>>::reference boost::dynamic_bitset<Block,std::allocator<Block>>::operator [](boost::dynamic_bitset<Block,std::allocator<Block>>::size_type)'


reference(block_type & b, size_type pos)",kaa123@…
10817,missing argument global-setup,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2014-11-25T22:30:30Z,2014-12-11T10:28:53Z,"I was attempting to build boost on Win 8.1  with just the MS VC++ Compiler for Python (microsoft.com/en-us/download/details.aspx?id=44266) so no Visual Studio installed. 

I encountered the error below when running `b2`. Modifying project-config.jam to have the line `using msvc : : : <setup> ;` allow the build to continue to completion. 

{{{
c:\boost_1_57_0>b2 --debug-configuration
notice: found boost-build.jam at C:/boost_1_57_0/boost-build.jam
notice: loading Boost.Build from C:/boost_1_57_0/tools/build/src
notice: Searching 'C:\Windows' 'C:\Users\IEUser' 'C:\Users\IEUser' 'C:\boost_1_57_0\tools/build/src' 'C:\boost_1_57_0' '
C:/boost_1_57_0/tools/build/src/kernel' 'C:/boost_1_57_0/tools/build/src/util' 'C:/boost_1_57_0/tools/build/src/build' '
C:/boost_1_57_0/tools/build/src/tools' 'C:/boost_1_57_0/tools/build/src/contrib' 'C:/boost_1_57_0/tools/build/src/.' for
 site-config configuration file 'site-config.jam'.
notice: Configuration file 'site-config.jam' not found in 'C:\Windows' 'C:\Users\IEUser' 'C:\Users\IEUser' 'C:\boost_1_5
7_0\tools/build/src' 'C:\boost_1_57_0' 'C:/boost_1_57_0/tools/build/src/kernel' 'C:/boost_1_57_0/tools/build/src/util' '
C:/boost_1_57_0/tools/build/src/build' 'C:/boost_1_57_0/tools/build/src/tools' 'C:/boost_1_57_0/tools/build/src/contrib'
 'C:/boost_1_57_0/tools/build/src/.'.
notice: Searching 'C:\Users\IEUser' 'C:\Users\IEUser' 'C:\boost_1_57_0\tools/build/src' 'C:\boost_1_57_0' 'C:/boost_1_57
_0/tools/build/src/kernel' 'C:/boost_1_57_0/tools/build/src/util' 'C:/boost_1_57_0/tools/build/src/build' 'C:/boost_1_57
_0/tools/build/src/tools' 'C:/boost_1_57_0/tools/build/src/contrib' 'C:/boost_1_57_0/tools/build/src/.' for user-config
configuration file 'user-config.jam'.
notice: Configuration file 'user-config.jam' not found in 'C:\Users\IEUser' 'C:\Users\IEUser' 'C:\boost_1_57_0\tools/bui
ld/src' 'C:\boost_1_57_0' 'C:/boost_1_57_0/tools/build/src/kernel' 'C:/boost_1_57_0/tools/build/src/util' 'C:/boost_1_57
_0/tools/build/src/build' 'C:/boost_1_57_0/tools/build/src/tools' 'C:/boost_1_57_0/tools/build/src/contrib' 'C:/boost_1_
57_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 'cl.exe' for msvc, condition <toolset>msvc
C:/boost_1_57_0/tools/build/src/tools\msvc.jam:1075: in configure-really
*** argument error
* rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup : default-global-setup-options :
 default-setup )
* called with: ( default : C:\Users\IEUser\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\bin : C:
\Users\IEUser\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC :  : i386 :  : x86 : vcvars32.bat )
* missing argument global-setup
C:/boost_1_57_0/tools/build/src/tools\msvc.jam:809:see definition of rule 'generate-setup-cmd' being called
C:/boost_1_57_0/tools/build/src/tools\msvc.jam:201: in configure
C:/boost_1_57_0/tools/build/src/tools\msvc.jam:153: in msvc.init
C:/boost_1_57_0/tools/build/src/build\toolset.jam:43: in toolset.using
C:/boost_1_57_0/tools/build/src/build\project.jam:1007: in using
project-config.jam:3: in modules.load
C:/boost_1_57_0/tools/build/src\build-system.jam:249: in load-config
C:/boost_1_57_0/tools/build/src\build-system.jam:412: in load-configuration-files
C:/boost_1_57_0/tools/build/src\build-system.jam:524: in load
C:\boost_1_57_0\tools\build\src/kernel\modules.jam:289: in import
C:\boost_1_57_0\tools\build\src/kernel/bootstrap.jam:139: in boost-build
C:\boost_1_57_0\boost-build.jam:17: in module scope
}}}",calumlind@…
10815,Boost 1.55 property_tree INFO parser does not round-trip for \t (tab),property_tree,Boost 1.55.0,To Be Determined,Bugs,Sebastian Redl,new,2014-11-24T21:12:25Z,2015-02-13T18:31:10Z,"Following GTest fails, as embedded tab (\t) has been expanded to a 'real tab' by write_info (note that \n, \0, \r are all escaped properly

{{{
	TEST(AdHocTest, AHT0051Boost__property_tree__info_parser_tab)
	{
		std::stringstream ss;
		std::string inputRaw, input, output, exp, act;
		boost::property_tree::ptree ptree;

		inputRaw = ""key2 \""value with special characters in it {}; #\\n\\t\\\""\\r\""\n"";

		ss.str(inputRaw);
		ASSERT_NO_THROW(boost::property_tree::info_parser::read_info(ss, ptree)) << ""parse inputRaw"";
		EXPECT_EQ(std::string(""value with special characters in it {}; #\n\t\""\r""), ptree.get<std::string>(""key2""));

		ss = std::stringstream();
		ASSERT_NO_THROW(boost::property_tree::info_parser::write_info(ss, ptree)) << ""extract input"";
		input = ss.str();

		exp = ""key2 \""value with special characters in it {}; #\\n\\t\\\""\\r\""\n"";
		act = input;
		EXPECT_EQ(exp.size(), act.size());
		EXPECT_EQ(exp, act);
		for (size_t ix = 0, diffs = 0; (ix < exp.size()) && (ix < act.size()) && (diffs < 5); ++ix)
		{
			if (exp[ix] != act[ix]) { ++diffs; } 
			EXPECT_EQ(exp[ix], act[ix]) << ""ix="" << ix;
		}
	}
}}}
",brewmanz <brewmanz@…>
10814,Boost asio socket keeps established connection forever even after endpoint is closed.,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-24T20:40:33Z,2014-11-24T20:40:33Z,"Context:

Server side:

  Accept socket
  loop blocking read from accepted socket

Client side:

  Connect
  loop blocking write to connected socket

Sporadically the client endpoint is ended but the server is not notified of that event. After that, the client can connect again to the server (even tho gdb says the thread is on recv) but the server never returns from the blocking read due to, probably, the new endpoint sending data doesn't match the last one:

Server side:
{{{
Local Address         Foreign Address
192.168.1.1:1234      192.168.1.2:50000
}}}


Client side after connection was dropped:

{{{
Local Address         Foreign Address
192.168.1.2:50001     192.168.1.2:1234
}}}

As I said, the issue is sporadic but I can reproduce the same blocking behaviour as follows:

1. Run the server and client normally. Client sends data and server reads it.
2. Enable a traffic filter with a firewall blocking/dropping packages at the client.
3. After step 2, I can kill the client process and the server will never realize that the client is no longer there, so it will block at recv forever.

Regards,
Iván",Iván <versuchen@…>
10813,Boost headers files incorrect permissions,parameter,Boost 1.57.0,To Be Determined,Bugs,Marshall Clow,new,2014-11-23T09:04:29Z,2015-02-13T18:31:57Z,"I recently updated Boost 1.57, I noticed that a few header files ""parameter.hpp"" and some of those in the ""parameter"" directory has permission 755 instead of normal 644. Why make these normal header files executable?",zhouyan@…
10810,Property tree XML parser eats whitespace of text elements,property_tree,Boost 1.41.0,To Be Determined,Bugs,Sebastian Redl,new,2014-11-21T20:15:08Z,2014-11-21T20:15:08Z,"The trim_whitespace flag converts this XML:

  {{{#!xml
  <yes>

    <sadly>Whitespace matters </sadly>
  </yes>
  }}}

into this:

  {{{#!xml
  <yes>
    <sadly>Whitespace matters</sadly>
  </yes>
  }}}

While the deletion of whitespace in elements that contain other elements is fine, I would consider it a bug to delete whitespace in elements that contain only text. It wouldn't do this to attributes, so it shouldn't do it to text elements.

I believe that the cause is that the boost version of rapidxml combines the two flags `parse_trim_whitespace` and `parse_normalize_whitespace` into one, `trim_whitespace`.",ahaferburg@…
10809,Seeking breaks iostreams::restriction<std::istream> internal state,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-11-21T01:47:49Z,2014-11-21T01:47:49Z,"As in the attached test case, calling seekg() on a restricted istream appears to break the internal state such that more characters can be extracted than expected.

I've done some digging around, and I think this is because the restriction device does a seek relative to std::ios_base::cur, which returns -1 from the underlying implementation:  Calling std::streambuf::pubseekoff() with way = ios_base::cur and which = (ios_base::in | ios_base::out) fails according to the C++ standard section 27.8.2.4.

When fixing this, it's worth noting that calling pubseekoff() will also fail with libstdc++ if it's passed (ios_base::in | ios_base::out) when the stream buffer has only an output buffer or input buffer, but not both.

Tested with g++-4.6.3 and g++-4.8.? on 64 bit linux Ubuntu.  Behaviour is consistent with clang++-libc++, but inconsistent with MSVC.",chris42f@…
10807,Single-letter short-cuts in Interprocess index are mostly broken,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-11-20T10:31:51Z,2015-02-13T18:36:30Z,"Very similar to ticket #7899. In <http://www.boost.org/doc/libs/1_57_0/doc/html/interprocess/indexes_reference.html>, many of the single-letter links point at some other boost module's documentation ({{{circular_buffer}}}, {{{container}}}).
",Stefan Ring <stefanrin@…>
10805,Bugs: problem in push_relabel_max_flow algorithm when using std::numeric_limits<double>::max() as capacity in some edges,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-11-19T15:29:51Z,2015-02-13T18:32:27Z," I am having trouble using the push_relabel_max_flow algorithm when I put std::numeric_limits<double>::max() as capacity attribute in some edges.
is there a maximum value that I can use as capacities. which ?.

I adjunct an example that reproduces the error:

 /home/madoery/boost_1_55_0/boost/graph/push_relabel_max_flow.hpp:750: typename boost::property_traits<CapacityEdgeMap>::value_type boost::push_relabel_max_flow(Graph&, typename boost::graph_traits<Graph>::vertex_descriptor, typename boost::graph_traits<Graph>::vertex_descriptor, CapacityEdgeMap, ResidualCapacityEdgeMap, ReverseEdgeMap, VertexIndexMap) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, vertexInfo, edgeInfo>, CapacityEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, long unsigned int, edgeInfo, double edgeInfo::*>, ResidualCapacityEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, long unsigned int, edgeInfo, double edgeInfo::*>, ReverseEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>&, long unsigned int, edgeInfo, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int> edgeInfo::*>, VertexIndexMap = boost::vec_adj_list_vertex_id_map<vertexInfo, long unsigned int>, typename boost::property_traits<CapacityEdgeMap>::value_type = double, typename boost::graph_traits<Graph>::vertex_descriptor = long unsigned int]: Assertion `algo.is_flow()' failed.

On the other side, 
http://lists.boost.org/Archives/boost/2011/01/174683.php
treats the problem of using double precision as capacity attributes on the edges.
Jeremiah Willcock advices to just replace the == and != operations in is_flow (and not < and >) and asks if the code works correctly in that case. I made the replacement but I had to use precision (epsilon) too 
high (in the order of 0.2, 0.3) to make the BOOST_ASSERT(algo.is_flow()) to pass.

Maybe these are two different problems or not. I am not sure, but they seems to be regarding the same assert that is failing

 ",Pablo Madoery <madoerypablo@…>
10802,Use make_shared<impl_type>,iostreams,Boost 1.57.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2014-11-19T12:13:19Z,2014-11-19T12:13:19Z,"file_descriptor::file_descriptor() uses new impl_type, you might want to use make_shared<impl_type> instead.",anonymous
10801,Used uninitialized error in boyer_myrvold_impl.hpp,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-11-19T00:47:37Z,2016-08-09T09:06:33Z,"I met an error when using boyer_myrvold_planar_test() function in Boost_1_55_0 to generate the kuratowski subgraph. Error message is listed as follows: 

./boost/graph/planar_detail/boyer_myrvold_impl.hpp:1545:11 error: 'z' may be used uninitialized in this function. 

I added a ""Wno-maybe-uninitialized"" flag to Makefile to remove this error temporarily, but it's not a good method. I'm looking for a better way to fix this. ",wanglurg@…
10800,boost::iostreams seems to be unmaintained,iostreams,Boost 1.57.0,To Be Determined,Support Requests,Jonathan Turkanis,new,2014-11-18T09:14:09Z,2014-11-18T09:42:36Z,"Hi guys,

I see 9 opened pull requests and 0 closed in git repository of boost::iostreams. It seems that there is no active project collaborator who can merge the requests.

Can you please look at this?

Thanks.",ivan.grynko
10799,Several problems building the example/tutorial project,python USE GITHUB,Boost 1.57.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2014-11-17T22:21:29Z,2015-04-14T20:54:37Z,"-- There are a number of problems reported here, so you may want to break this down into pieces for separate tracking.  However, I would consider this item to be fixed only when I can build the example/tutorial and it works.
 
I had a hard time building the example/tutorial project.  Some of this is, I believe, due to bugs in the distribution, and some is probably my lack of understanding.
 
Some of this I posted to the Boost interest group before I could join this (Python C++) SIG, hoping it would get forwarded on here, so there may be a duplication.
 
1. Calling bjam in the example/tutorial project failed to even start up the build system.  This was because the example/bootstrap.jam pointed to the wrong path for the build system root.  Instead of ../../../tools/build/v2, it should be ../../../tools/build/src/kernel.  When I changed this, bjam now got past the build system startup.
 
2. Building the project not only compiles hello.cpp, but it also builds a private copy of the Boost/Python library.  So I needed to supply the properties needed to correctly build this library (i.e., link=shared, address-mode=64).  Of course, I needed to supply those same properties anyway as part of creating the extension.
 
There's probably a way to change something so that the extension uses the library built in the Boost.Python's own project, or if I have obtained the libraries without having to build them, it would use these.  I don't know if you intended to have the tutorial example make its own copies, but it seems a waste of resources to do so.
 
3. The link for debug mode failed, saying that the .pdb file was in the wrong format (LNK1207).  This is a bug, due to an option in the link command '/IMPORTLIB:...hello_ext.pdb'.  So the linker is creating the .pdb file as an import library, then complaining that it's not a valid pdb file.  I changed '.pdb' to '.lib'.  I could also have removed this option entirely, since hello_ext.pyd doesn't have anything to export anyway.
 
4. Before figuring out that the link was the problem, I changed the /Z7 argument to /Zi in the compile command for hello.cpp.  I don't know if this was necessary, or if it was necessary to leave it in place.  For now, I just wanted to get it to build.  Without /Z7, the debug symbols go into example/tutorial/vc120.pdb.  I don't know if the linker found these or not.  When I try stepping into the extension, I'll know for sure.  Microsoft prefers that .pdb files be used for debug symbols rather than embedding them in the .obj files, so this might be the only real reason to make the change.
 
5. The link for both release mode failed with two undefined symbols, __imp_DecodePointer and __imp_EncodePointer, which are in kernel32.lib.  I tried adding kernel32.lib to the link's inputs.  But then it warned that there could be static constructors/destructors not getting called.  After much research on this topic, I found that the source of the problem was the /NOENTRY argument in the link command, which has the consequence that the automatic CRT initialization of the DLL doesn't occur.  So I remove the /NOENTRY and got not warnings, and I didn't need to add kernerl32.lib either.
 
6. A minor point.  The MACHINE:X64 is redundant.  The linker knows it's X64 because of the architecture of the input files and libraries.  Nothing wrong with it being there, but it's just clutter in the code.
 
7. Now bjam was successful in building whatever it wanted to build.  It said that hello.test passed.  Sounds great, I thought.  But I then went into Python and tried 'import hello_ext' and that failed.  So I have an issue with the test program passing, while the extension didn't actually work.
 
8. The problem was that bjam didn't put the hello_ext.pyd file in my Python's lib/site-packages folder.  It built the .pyd and .pdb files in the example/tutorial/bin/... staging area, and copied (ONLY) the .pyd file to example/tutorial.  So not only did the .pyd file get put in the wrong place, but the .pdb was left out.  If I am going to debug my extension (such as with Visual Studio's Python Tools), the .pdb file also needs to be in the lib/site-packages folder.  Without the .pdb file, the PTVS debugger will not set breakpoints or step into the extension code.
 
9. I spent another few hours figuring out why the import statement in Python didn't work.  Python could not load the hello_ext.pyd because it has references to BOOST_PYTHON_....DLL.  If I run Python from the example/tutorial directory itself, it works because this DLL had been build there.  That explains why the hello.test passed (as bjam ran it from that same directory).  So to fix this problem, I copied the DLL (and its accompanying PDB) from the place where it was built into a directory in my PATH.  It would also work to have these files placed in the Python lib/site-packages folder, since the main DLL's folder is one of the places that Windows looks for imported DLLs.

To summarize, the fixes I made in order to build the example and use it in Python were:
    * Change the build system path in examples/bootstrap.jam.
    * Change the /IMPORTLIB:....pdb to ....lib in the link command.  I could have removed it altogether.
    * Remove /NOENTRY from the link command.
    * Manually copy the example/tutorial/bin/.../hello_ext.(pyd,pdb) files to Python's lib/site-packages.
    * Manually copy the Boost.Python DLL and PDB files to a location in my %PATH% (or to lib/site-packages)
 
These last two steps are not necessary if I run Python from the example/tutorial directory itself, as Python will find the PYD there and it will find the Boost.Python DLL there as well.  So if the other problems are fixed, then the tutorial would be telling the truth that the extension can be imported and works correctly PROVIDED that you don't change directories after doing the build.

Maybe there's something later in the tutorial about modifying the jamfile to specify where you want the files installed so that Python can import them no matter what directory Python was called from.  If this is the case, that's OK with me, as long as the tutorial says '''clearly''' where you first build the example that at this point, Python '''must be run from the example/tutorial directory'''.

This cost me about a whole day's time, and I'm pretty resourceful.  And I actually want to build my own extensions in VS instead of bjam, linking to the Boost.Python DLL.  I started of by trying this, and my extension crashed.  So that's why I went about building the example with bjam, to at least see what a successful deployment looked like.  I now understand that my original attempt crashed because linking to the Boost.Python DLL is not enough to be sure that the target PYD will load.

If I had understood that in the first place, I would have taken care to put the Boost.Python DLL on my PATH, and not tried building the example in the manner specified in the tutorial.  But then I would not have discovered those build bugs, and they would have gone unreported.

 
I suppose that a lot of people would have given up building the tutorial example and then given up on Boost.Python altogether.

One more comment.  You should make sure, as part of the QA process for releasing Boost that you be sure that all the examples can be built and work properly, particularly on Windows with all the MSVC toolsets.  Item (1) would apply to all platforms, so I would guess that the example/tutorial was not tested at all.

Michael Rolle",m@…
10797,boost::join multiply defined (from algorithm/string/join.hpp and range/join.hpp),algorithm,Boost 1.46.1,To Be Determined,Bugs,Marshall Clow,new,2014-11-17T10:02:26Z,2014-11-17T10:02:26Z,"algorithm/string/join.hpp pulls boost::algorithm::join into the boost namespace with a 

using algorithm::join

statement.
This crates a conflict with range/join.hpp which defines boost::join directly. If I want to use both in one compilation unit, I have to wrap one of them in a separate class --> ugly.

Suggested fix: I do not think that ""using algorithm::join"" is needed in the file algorithm/string/join.hpp.",Andreas Baak <andreas.baak@…>
10796,JSON writer incorrectly escapes UTF8 strings,property_tree,Boost 1.56.0,To Be Determined,Bugs,Sebastian Redl,new,2014-11-16T20:10:25Z,2014-11-16T20:10:25Z,"Consider a string s = ""Šnipiškių"".

JSON writer stores ""\u00C5\u00A0nipi\u00C5\u00A1ki\u00C5\u00B3"", which is actually ""Šnipiškių"".

Expected behaviour:

1. UTF-8 strings properly escaped by boost::property_tree::write_json
2. boost::property_tree::read_json then reads EXACTLY the same UTF8 string.

I.e., if the original ptree contained ""Šnipiškių"", the same string ""Šnipiškių"" must be read back by read_json.",vygis.d@…
10795,Include asio/ssl/context.hpp reports two leaks on Windows,asio,Boost 1.57.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-16T02:48:37Z,2016-05-06T21:33:06Z,"Simply including the header file <boost/asio/ssl/context.hpp> causes the Microsoft Visual Studio debug runtime (MSVCRTD library) to report two 32 byte leaks on exit. It is not clear if these are from asio or from OpenSSL. This sample program compiled for 64-bit Windows using Visual Studio 2013 demonstrates the problem:

{{{
#include <boost/asio/ssl/context.hpp>
#include <crtdbg.h>
int main()
{
    int flags = _CrtSetDbgFlag (_CRTDBG_REPORT_FLAG);
    flags |= _CRTDBG_LEAK_CHECK_DF;
    _CrtSetDbgFlag (flags);
}
}}}

This report is shown on exit, when main returns:

{{{
Detected memory leaks!
Dumping objects ->
{716} normal block at 0x00000000003953F0, 32 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
{715} normal block at 0x00000000003952D0, 32 bytes long.
 Data: <         S9     > 00 00 00 00 CD CD CD CD F0 53 39 00 00 00 00 00 
Object dump complete.
}}}

",Vinnie Falco <vinnie.falco@…>
10793,Compilation errors in Visual Studio 2013 with /Za (disabled extensions),scope_exit,Boost 1.65.0,To Be Determined,Bugs,Lorenzo Caminiti,reopened,2014-11-14T20:48:44Z,2017-11-01T01:03:58Z,"Use of Scope Exit generates compilation errors in Visual Studio 2013 (version 18.00.31101 for x86) if `/Za` option (disabled language extensions) is used.

I haven't checked other VS versions. I haven't checked previous Boost versions. And `/Za` is not set by default (language extensions are enabled by default).

With `BOOST_SCOPE_EXIT_ALL` we get following errors:
{{{
C:\Users\Adam Badura\Dropbox\Projekty\scope_exit>cl /EHsc /Za /I""C:\Programming\boost_1_57_0"" BOOST_SCOPE_EXIT_ALL.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

BOOST_SCOPE_EXIT_ALL.cpp
C:\Programming\boost_1_57_0\boost/scope_exit.hpp(419) : error C2143: syntax error : missing ';' before '<'
        C:\Programming\boost_1_57_0\boost/scope_exit.hpp(427) : see reference to class template instantiation 'boost::scope_exit::aux::msvc_typeof_this::msvc_extract_type<ID,T>' being compiled
C:\Programming\boost_1_57_0\boost/scope_exit.hpp(419) : error C2913: explicit specialization; 'boost::scope_exit::aux::msvc_typeof_this::msvc_extract_type<ID,boost::scope_exit::aux::msvc_typeof_this::msvc_extract_type_default_param>::id2type_impl' is not a specialization of a class template
C:\Programming\boost_1_57_0\boost/scope_exit.hpp(419) : error C2059: syntax error : '<'
C:\Programming\boost_1_57_0\boost/scope_exit.hpp(419) : error C2334: unexpected token(s) preceding '{'; skipping apparent function body
}}}

With `BOOST_SCOPE_EXIT` we get following errors:
{{{
C:\Users\Adam Badura\Dropbox\Projekty\scope_exit>cl /EHsc /Za /I""C:\Programming\boost_1_57_0"" BOOST_SCOPE_EXIT.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.31101 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

BOOST_SCOPE_EXIT.cpp
C:\Programming\boost_1_57_0\boost/scope_exit.hpp(419) : error C2143: syntax error : missing ';' before '<'
        C:\Programming\boost_1_57_0\boost/scope_exit.hpp(427) : see reference to class template instantiation 'boost::scope_exit::aux::msvc_typeof_this::msvc_extract_type<ID,T>' being compiled
C:\Programming\boost_1_57_0\boost/scope_exit.hpp(419) : error C2913: explicit specialization; 'boost::scope_exit::aux::msvc_typeof_this::msvc_extract_type<ID,boost::scope_exit::aux::msvc_typeof_this::msvc_extract_type_default_param>::id2type_impl' is not a specialization of a class template
C:\Programming\boost_1_57_0\boost/scope_exit.hpp(419) : error C2059: syntax error : '<'
C:\Programming\boost_1_57_0\boost/scope_exit.hpp(419) : error C2334: unexpected token(s) preceding '{'; skipping apparent function body BOOST_SCOPE_EXIT.cpp(9) : warning C4003: not enough actual parameters for macro 'BOOST_PP_EXPAND_I'
}}}

Note that in case of `BOOST_SCOPE_EXIT` we also get warning C4003. And it shows in clean build (without `/Za`) as well.",adam.f.badura@…
10791,wiki is horribly stale,trac / subversion,Boost 1.57.0,To Be Determined,Bugs,Douglas Gregor,new,2014-11-14T04:51:44Z,2014-11-14T04:51:44Z,"https://svn.boost.org/trac/boost/wiki

talks as if the transition to github hasn't been made, still talks about subversion, etc.",Richard <legalize@…>
10789,unexpected behaviour with boost range join on rvalue,range,Boost 1.57.0,To Be Determined,Bugs,Neil Groves,new,2014-11-13T07:05:05Z,2014-11-13T07:11:20Z,"I'm trying to append one element to a range, and iterate over the resulting compound range. When the rhs of the `join` is an lvalue, everything seems ok. However, when the rhs of the `join` is an rvalue, I'm seeing something unexpected.

Specifically, when such a joined range is accessed directly by a `for(auto e : range)` loop, or when it is saved in a variable using `auto`, then iterated over, the singleton in the second container is not produced correctly. If however the joined range is passed by reference (other than non-const lvalue, obviously), then iterated over, the result is correct.",Matei David <matei@…>
10787,MPI wrapper autodetection fails for SGI,mpi,Boost 1.57.0,To Be Determined,Bugs,Matthias Troyer,new,2014-11-12T16:05:51Z,2014-11-14T14:59:58Z,"Detection for mpi wrapper compiler fails when using SGI's mpi, the only command printing compile info is -show which fails because boost assumes -show is for mpich which also has -compile_info and -link_info but sgi's doesn't:

mpicxx -show
g++ -I/nasa/sgi/mpt/2.11r13/include -L/nasa/sgi/mpt/2.11r13/lib -lmpi++ -lmpi

mpirun -v       
MPT: libxmpi.so 'SGI MPT 2.11  10/16/14 05:50:05'",ilja.j.honkonen@…
10785,Lambda assignment fails to compile in 1.57.0,lambda,Boost 1.57.0,To Be Determined,Bugs,No-Maintainer,new,2014-11-12T09:50:58Z,2015-04-20T12:11:28Z,"The following code used to work. From Boost 1.57.0 it does not compile with Clang 3.4, 3.5, 3.6 and Apple Clang.

{{{
#!c++
#include <iostream>
#include <boost/function.hpp>
#include <boost/lambda/lambda.hpp>
#include <boost/lambda/bind.hpp>


int add(int a, int b) {
    return a+b;
}


int main() {
    
    boost::function<int (int, int)> fuse = boost::lambda::bind(&add, boost::lambda::_1, -boost::lambda::_2);
    
    int a = fuse(3,6);
    std::cout << a << std::endl;
}
}}}

The compiler error reads:
{{{
In file included from boost_lambda.cpp:3:
In file included from /Users/dolfim/src/boost_1_57_0/boost/lambda/lambda.hpp:14:
In file included from /Users/dolfim/src/boost_1_57_0/boost/lambda/core.hpp:46:
/Users/dolfim/src/boost_1_57_0/boost/lambda/detail/lambda_traits.hpp:256:58: error: cannot form a reference to 'void'
      typename detail::IF<boost::is_function<T>::value, T&, const T>::RET
                                                         ^
/Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:148:98: note: in instantiation of template class
      'boost::lambda::const_copy_argument<const void>' requested here
BOOST_LAMBDA_BE2(BOOST_LAMBDA_COMMA_OPERATOR_NAME, other_action<comma_action>, const A, const B, const_copy_argument)
                                                                                                 ^
/Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:63:20: note: expanded from macro 'BOOST_LAMBDA_BE2'
    tuple<typename CONVERSION <CONSTA>::type, lambda_functor<Arg> >        \
                   ^
/Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:148:18: note: while substituting deduced template arguments into
      function template 'operator,' [with A = void, Arg = boost::lambda::lambda_functor_base<boost::lambda::action<3,
      boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> >]
BOOST_LAMBDA_BE2(BOOST_LAMBDA_COMMA_OPERATOR_NAME, other_action<comma_action>, const A, const B, const_copy_argument)
                 ^
/Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:145:42: note: expanded from macro
      'BOOST_LAMBDA_COMMA_OPERATOR_NAME'
#define BOOST_LAMBDA_COMMA_OPERATOR_NAME operator,
                                         ^
/Users/dolfim/src/boost_1_57_0/boost/lambda/detail/operators.hpp:65:78: note: expanded from macro 'BOOST_LAMBDA_BE2'
>                                                                            \
                                                                             ^
/Users/dolfim/src/boost_1_57_0/boost/type_traits/is_copy_constructible.hpp:104:24: note: in instantiation of template class
      'boost::detail::is_copy_constructible_impl2<false,
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3, boost::lambda::function_action<3,
      boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here
        boost::detail::is_copy_constructible_impl2<
                       ^
/Users/dolfim/src/boost_1_57_0/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
/Users/dolfim/src/boost_1_57_0/boost/type_traits/is_copy_constructible.hpp:113:71: note: in instantiation of template class
      'boost::detail::is_copy_constructible_impl<boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3,
      boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here
BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_copy_constructible,T,::boost::detail::is_copy_constructible_impl<T>::value)
                                                                      ^
/Users/dolfim/src/boost_1_57_0/boost/type_traits/detail/bool_trait_def.hpp:61:30: note: expanded from macro
      'BOOST_TT_AUX_BOOL_TRAIT_DEF1'
    BOOST_TT_AUX_BOOL_C_BASE(C) \
                             ^
/Users/dolfim/src/boost_1_57_0/boost/type_traits/detail/bool_trait_def.hpp:55:81: note: expanded from macro
      'BOOST_TT_AUX_BOOL_C_BASE'
#   define BOOST_TT_AUX_BOOL_C_BASE(C) : public ::boost::integral_constant<bool,C>
                                                                                ^
/Users/dolfim/src/boost_1_57_0/boost/type_traits/has_trivial_copy.hpp:36:76: note: in instantiation of template class
      'boost::is_copy_constructible<boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3,
      boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here
   BOOST_STATIC_CONSTANT(bool, value = BOOST_HAS_TRIVIAL_COPY(T) && boost::is_copy_constructible<T>::value);
                                                                           ^
/Users/dolfim/src/boost_1_57_0/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
/Users/dolfim/src/boost_1_57_0/boost/type_traits/has_trivial_copy.hpp:62:78: note: in instantiation of template class
      'boost::detail::has_trivial_copy_impl<boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3,
      boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here
BOOST_TT_AUX_BOOL_TRAIT_DEF1(has_trivial_copy_constructor,T,::boost::detail::has_trivial_copy_impl<T>::value)
                                                                             ^
/Users/dolfim/src/boost_1_57_0/boost/type_traits/detail/bool_trait_def.hpp:61:30: note: expanded from macro
      'BOOST_TT_AUX_BOOL_TRAIT_DEF1'
    BOOST_TT_AUX_BOOL_C_BASE(C) \
                             ^
/Users/dolfim/src/boost_1_57_0/boost/type_traits/detail/bool_trait_def.hpp:55:81: note: expanded from macro
      'BOOST_TT_AUX_BOOL_C_BASE'
#   define BOOST_TT_AUX_BOOL_C_BASE(C) : public ::boost::integral_constant<bool,C>
                                                                                ^
/Users/dolfim/src/boost_1_57_0/boost/function/function_template.hpp:939:20: note: in instantiation of template class
      'boost::has_trivial_copy_constructor<boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3,
      boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here
        if (boost::has_trivial_copy_constructor<Functor>::value &&
                   ^
/Users/dolfim/src/boost_1_57_0/boost/function/function_template.hpp:722:13: note: in instantiation of function template
      specialization 'boost::function2<int, int,
      int>::assign_to<boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3,
      boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here
      this->assign_to(f);
            ^
/Users/dolfim/src/boost_1_57_0/boost/function/function_template.hpp:1071:5: note: in instantiation of function template
      specialization 'boost::function2<int, int,
      int>::function2<boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3,
      boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here
    base_type(f)
    ^
boost_lambda.cpp:14:44: note: in instantiation of function template specialization 'boost::function<int (int,
      int)>::function<boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<3,
      boost::lambda::function_action<3, boost::lambda::detail::unspecified> >, boost::tuples::tuple<int (*const)(int, int), const
      boost::lambda::lambda_functor<boost::lambda::placeholder<FIRST> >, const
      boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::unary_arithmetic_action<boost::lambda::minus_action>,
      boost::tuples::tuple<boost::lambda::lambda_functor<boost::lambda::placeholder<SECOND> >, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
      boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > > >' requested here
    boost::function<int (int, int)> fuse = boost::lambda::bind(&add, boost::lambda::_1, -boost::lambda::_2);
                                           ^
1 error generated.
}}}
",dolfim@…
10784,Error compiling syslog_backend with icc-11.1.064,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-11T21:52:54Z,2014-11-12T13:07:34Z,"I am trying to compile boost 1.56.0 with icc-11.1.064 on ubuntu 12.04.
That specific compiler is needed for compatibility with existing code.

It's failing with this error:

./boost/asio/detail/keyword_tss_ptr.hpp(62): error: template argument list must match the parameter list
  BOOST_ASIO_THREAD_KEYWORD T* keyword_tss_ptr<T>::value_;
                               ^

compilation aborted for libs/log/src/syslog_backend.cpp (code 2)

    ""icpc"" -c -xc++ -w1 -inline-level=2 -O3 -ip -pthread -fPIC -fPIC -wd177,780,2196,1782,193,304,981,1418,411,734,279 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_DATE_TIME_DYN_LINK=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_HAS_ICU=1 -DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_DLL -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_USE_SSSE3 -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DDATE_TIME_INLINE -DNDEBUG -D_GNU_SOURCE=1 -D_XOPEN_SOURCE=600 -I""."" -I""/usr/include""   -c -o ""bin.v2/libs/log/build/intel-linux/release/build-no/log-api-unix/threading-multi/syslog_backend.o"" ""libs/log/src/syslog_backend.cpp""

...failed intel-linux.compile.c++ bin.v2/libs/log/build/intel-linux/release/build-no/log-api-unix/threading-multi/syslog_backend.o...
intel-linux.compile.c++ bin.v2/libs/log/build/intel-linux/release/build-no/log-api-unix/threading-multi/threadsafe_queue.o
intel-linux.compile.c++ bin.v2/libs/log/build/intel-linux/release/build-no/log-api-unix/threading-multi/trivial.o
 

If I compile with 'define=BOOST_LOG_WITHOUT_SYSLOG' then it builds successfully but I'd like to have the syslog backend support available. Any help would be much appreciated.
",bhall@…
10782,bootstrap.bat fails with recursion exceeding stack limits on win32,Building Boost,Boost 1.57.0,To Be Determined,Bugs,,new,2014-11-11T16:06:06Z,2015-09-22T10:20:29Z,"{{{
D:\upload\boost_1_57_0>bootstrap.bat
Building Boost.Build engine
******  B A T C H   R E C U R S I O N  exceeds STACK limits ******
Recursion Count=1240, Stack Usage=90 percent
******       B A T C H   PROCESSING IS   A B O R T E D      ******

D:\upload\boost_1_57_0\tools\build\src\engine>
}}}
Platform is 32bit Windows XP.  This is not the same bug as https://svn.boost.org/trac/boost/ticket/10330",slowriot <riot@…>
10781,Minor typo in regex_actions.hpp,xpressive,Boost Development Trunk,To Be Determined,Patches,Eric Niebler,new,2014-11-11T03:11:59Z,2014-11-11T03:11:59Z,Patch attached.,oss.2012.team+2014C@…
10779,error compiling boostlib_locale on HPUX.,locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,new,2014-11-10T10:09:06Z,2015-02-13T18:32:56Z,"Hi All,

I am trying to compile boost libraries 1.55.0 on HPUX platform with compiler version [aCC.A.06.25].. 

while compiling it's giving me following error.

------------------------------
""/usr/local/remote/packages/compiler_remote/ansicA.06.25_aCC.A.06.25/opt/aCC/include_std/rw/rwlocale"", line 722: error #2322: object of abstract class type ""boost::locale::calendar_facet"" is not allowed:
            function ""boost::locale::calendar_facet::create_calendar"" is a pure virtual function
      _Facet *__facet = new _Facet ();
                            ^
          detected during:
            instantiation of ""_Facet *__rw::__rw_create_named_facet(_Facet *, const char *, size_t) [with _Facet=boost::locale::calendar_facet]"" at line 79 of ""/usr/local/remote/packages/compiler_remote/ansicA.06.25_aCC.A.06.25/opt/aCC/include_std/rw/vendor""
            instantiation of ""_Facet *__rw::__rw_create_native_facet(_Facet *) [with _Facet=boost::locale::calendar_facet]"" at line 537 of ""/usr/local/remote/packages/compiler_remote/ansicA.06.25_aCC.A.06.25/opt/aCC/include_std/rw/locimpl""
            instantiation of ""__rw::__rw_facet_base *__rw::__rw_facet_maker<_Facet>::_C_maker_func(int, const char *, size_t) [with _Facet=boost::locale::calendar_facet]"" at line 57 of ""/usr/local/remote/packages/compiler_remote/ansicA.06.25_aCC.A.06.25/opt/aCC/include_std/rw/usefacet""
            instantiation of ""const _Facet &std::use_facet<_Facet>(const std::locale &) [with _Facet=boost::locale::calendar_facet]"" at line 26 of ""libs/locale/src/shared/date_time.cpp""

------------------------------------

Can anyone please help me with this.

I am using hpux 11.31 ia64 machine.
boost version : 1.55.0
aCC compiler version :  06.25",saurabh.csebhu@…
10776,Make BOOST_MOVE_CONVERSION_AWARE_CATCH public,move,Boost 1.57.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-11-09T18:22:36Z,2014-11-09T18:22:36Z,"I'm wrapping a boost::container::vector and I see that I need to use the macro BOOST_MOVE_CONVERSION_AWARE_CATCH.

Could it be made public?",viboes
10775,Add a boost::priority_queue class conforming to C++11,heap,Boost 1.57.0,To Be Determined,Feature Requests,timblechmann,new,2014-11-09T16:22:13Z,2014-11-10T08:29:46Z,"Boost.Heap provides already a boost::heaps::priority_queue class. However it doesn't conforms to C++11.

I suggest to add on in another namespace that conforms to C++11. ",viboes
10774,Add a queue/priority container,container,Boost 1.57.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-11-09T15:43:26Z,2015-12-25T14:58:08Z,"Boost is missing queue/priority_queue conforming to C++11 using Boost.Move.

See also #10773.",viboes
10773,pop_heap/push_heap,algorithm,Boost 1.57.0,To Be Determined,Feature Requests,Marshall Clow,new,2014-11-09T15:41:16Z,2014-11-09T15:41:16Z,It would be great to have these algorithms Boost.Move aware.,viboes
10772,boost::geometry::within() does not recognize empty boxes,geometry,Boost 1.57.0,To Be Determined,Bugs,awulkiew,assigned,2014-11-08T19:04:31Z,2015-09-07T12:54:36Z,"If boost::geometry::within() is used to check whether an empty box (i.e. a point) is within another box, false is always returned. This is not the correct behavior because:
1. OGC defines: a.Within(b) ⇔ (a∩b=a) ∧ (I(a)∩E(b)=∅) which holds true. The intersection of an empty box ''a'' and a surrounding box ''b'' yields ''a''. Since ''a'' has no interior, I(a)=∅, thus the second condition is also true.
2. Empty boxes should be treated as points. When using a point model instead of an empty box, the check returns the correct result as expected.

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

{{{
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/box.hpp>
#include <boost/geometry/algorithms/convert.hpp>
#include <boost/geometry/algorithms/within.hpp>
#include <boost/geometry/algorithms/covered_by.hpp>
#include <boost/geometry/algorithms/intersects.hpp>
#include <boost/geometry/algorithms/disjoint.hpp>
#include <boost/geometry/algorithms/distance.hpp> // needed for within() -- is this intended?
#include <iostream>

namespace bg = boost::geometry;
typedef bg::model::d2::point_xy<float> Point;
typedef bg::model::box<Point> Box;

int main()
{
    Point point(3, 4);
    Box pointAsBox;
    bg::convert(point, pointAsBox);

    Box surrounding;
    surrounding.min_corner() = Point(2, 2);
    surrounding.max_corner() = Point(5, 5);

    std::cout << ""            Point Box"" << std::endl;
    std::cout << ""within:        "" << bg::within(point,      surrounding)
                         << ""    "" << bg::within(pointAsBox, surrounding)     << ""\n""; // 1 0 <-
    std::cout << ""within (self): "" << bg::within(point,      point)           
                         << ""    "" << bg::within(pointAsBox, pointAsBox)      << ""\n""; // 1 0 <-
    std::cout << ""covered_by:    "" << bg::covered_by(point,      surrounding) 
                         << ""    "" << bg::covered_by(pointAsBox, surrounding) << ""\n""; // 1 1
    std::cout << ""intersects:    "" << bg::intersects(point,      surrounding) 
                         << ""    "" << bg::intersects(pointAsBox, surrounding) << ""\n""; // 1 1
    std::cout << ""disjoint:      "" << bg::disjoint(point,      surrounding)   
                         << ""    "" << bg::disjoint(pointAsBox, surrounding)   << ""\n""; // 0 0
    std::cout << std::endl;
}
}}}

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

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


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

The documentation about box model and concept doesn't state whether max_corner's coordinates must be component-wise greater or equal than min_corner's. If so, it seems like valid boxes are a precondition to within() and this line could be removed.",bromeon@…
10769,"iterator_adaptor does not properly inherit ""pointer"" typedef from the base iterator",iterator,Boost 1.57.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-11-07T20:03:37Z,2014-11-07T20:22:09Z,"I'm trying to define a `Derived_Iterator` class using a `Base_Iterator` class and the glue class `iterator_adaptor< Derived_Class, Base_Class, ...>` (as base of `Derived_Iterator`). In my use case, neither pointers nor references are plain:
{{{
Base_Iterator::pointer != Base_Iterator::value_type*
Base_Iterator::reference != Base_Iterator::value_type&
}}}

I found 2 possibly related problems, which I think are bugs:

1. The typedef `iterator_adaptor<>::pointer` is incorrect. Specifically, it produces a plain pointer, when I expect it to produce `Base_Iterator::pointer`.

2. There is something wrong with `iterator_adaptor<>::operator->()`. I would expect `Derived_Iterator` to behave exactly like `Base_Iterator`. So, if I don't explicitly define `Derived_Iterator::operator->()`, I would expect the version inherited from `iterator_adaptor<>` to do something similar to:
{{{
Base_Iterator operator->() const { return this->base(); }
}}}
But this doesn't happen. If I put in this definition explicitly in `Derived_Iterator`, then the code works.",Matei David <matei@…>
10764,current_exception_diagnostic_information returns an empty string if what returns an empty string.,exception,Boost 1.55.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-11-06T17:13:14Z,2014-11-06T17:13:14Z,"This happens when throwing standard exceptions such as std::runtime_error when an empty string passed to the constructor.

This is a problem with Boost 1.55 and some earlier versions but the code in 1.57 looks the same to me.",jonathan.lilliemarck@…
10762,fixed_matrix &operator = (matrix m) wrong parameter,numeric,Boost 1.57.0,To Be Determined,Bugs,Douglas Gregor,new,2014-11-06T12:39:28Z,2015-05-08T20:20:32Z,"Software was not tested! Error in
C:\Boost\include\boost-1_57\boost\numeric\ublas\matrix.hpp
line 1387
fixed_matrix &operator = (matrix m) {..
is wrong. Correct is:
fixed_matrix &operator = (fixed_matrix m) {",anonymous
10756,AddressSanitizer container overflow in deadline_timer,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-05T23:46:44Z,2015-06-16T14:58:39Z,"I am scheduling 3 ASIO deadline timers back-to-back, wrapping them in a single strand. There is a single thread that services io_service->run(). I see the following ""container-overflow"" violation:

{{{
=================================================================
==16399==ERROR: AddressSanitizer: container-overflow on address 0x60c000017550 at pc 0x0001088e1b3a bp 0x00010ea96510 sp 0x00010ea95cd0
READ of size 8 at 0x60c000017550 thread T2
    #0 0x1088e1b39 in __asan_memcpy (/opt/local/libexec/llvm-3.6/lib/clang/3.6.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x24b39)
    #1 0x1084a286a in boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config>::time_count() const (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10056186a)
    #2 0x1084a264e in boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config> >::is_less(boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config> const&, boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config> const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10056164e)
    #3 0x10808ccec in boost::date_time::base_time<boost::posix_time::ptime, boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config> > >::operator<(boost::posix_time::ptime const&) const (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10014bcec)
    #4 0x10823e079 in boost::asio::time_traits<boost::posix_time::ptime>::less_than(boost::posix_time::ptime const&, boost::posix_time::ptime const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002fd079)
    #5 0x108297b9a in boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::down_heap(unsigned long) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100356b9a)
    #6 0x108296b02 in boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::remove_timer(boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::per_timer_data&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100355b02)
    #7 0x1083bc9ef in boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::get_ready_timers(boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10047b9ef)
    #8 0x1083ba430 in boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::get_ready_timers(boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100479430)
    #9 0x10960c74c in boost::asio::detail::timer_queue_set::get_ready_timers(boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x4374c)
    #10 0x10960c0cd in boost::asio::detail::kqueue_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x430cd)
    #11 0x10960b846 in boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x42846)
    #12 0x10960b3aa in boost::asio::detail::task_io_service::run(boost::system::error_code&) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x423aa)
    #13 0x1095e2940 in boost::asio::io_service::run() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x19940)
    #14 0x1095d01f7 in eximius::Platform::ProcessorRun(unsigned int) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x71f7)
    #15 0x1095e81fe in void boost::_bi::list1<boost::_bi::value<unsigned int> >::operator()<void (*)(unsigned int), boost::_bi::list0>(boost::_bi::type<void>, void (*&)(unsigned int), boost::_bi::list0&, int) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x1f1fe)
    #16 0x1095e817b in boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > >::operator()() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x1f17b)
    #17 0x1095f5d7b in boost::detail::thread_data<boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > > >::run() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x2cd7b)
    #18 0x10a477d04 in boost::(anonymous namespace)::thread_proxy(void*) (/opt/local/lib/libboost_thread-mt.dylib+0x2d04)
    #19 0x7fff93dbc2fb in _pthread_body (/usr/lib/system/libsystem_pthread.dylib+0x32fb)
    #20 0x7fff93dbc278 in _pthread_start (/usr/lib/system/libsystem_pthread.dylib+0x3278)
    #21 0x7fff93dba4b0 in thread_start (/usr/lib/system/libsystem_pthread.dylib+0x14b0)

0x60c000017550 is located 80 bytes inside of 128-byte region [0x60c000017500,0x60c000017580)
allocated by thread T0 here:
    #0 0x1088ea2ab in wrap__Znwm (/opt/local/libexec/llvm-3.6/lib/clang/3.6.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x2d2ab)
    #1 0x108248c8a in std::__1::__split_buffer<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry, std::__1::allocator<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100307c8a)
    #2 0x108241d93 in std::__1::__split_buffer<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry, std::__1::allocator<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry>&>::__split_buffer(unsigned long, unsigned long, std::__1::allocator<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100300d93)
    #3 0x108241498 in void std::__1::vector<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry, std::__1::allocator<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry> >::__push_back_slow_path<boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry const>(boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::heap_entry const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100300498)
    #4 0x10823c621 in boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::enqueue_timer(boost::posix_time::ptime const&, boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::per_timer_data&, boost::asio::detail::wait_op*) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002fb621)
    #5 0x10823b51a in boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::enqueue_timer(boost::posix_time::ptime const&, boost::asio::detail::timer_queue<boost::asio::detail::forwarding_posix_time_traits>::per_timer_data&, boost::asio::detail::wait_op*) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002fa51a)
    #6 0x108238e17 in void boost::asio::detail::kqueue_reactor::schedule_timer<boost::asio::time_traits<boost::posix_time::ptime> >(boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >&, boost::asio::time_traits<boost::posix_time::ptime>::time_type const&, boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime> >::per_timer_data&, boost::asio::detail::wait_op*) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002f7e17)
    #7 0x1082375bc in void boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime> >::async_wait<boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf1<void, eximius::EximiusTimerHandler<boost::function<void ()> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<eximius::EximiusTimerHandler<boost::function<void ()> >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> >(boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime> >::implementation_type&, boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf1<void, eximius::EximiusTimerHandler<boost::function<void ()> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<eximius::EximiusTimerHandler<boost::function<void ()> >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running>&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002f65bc)
    #8 0x108236536 in boost::asio::async_result<boost::asio::handler_type<boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf1<void, eximius::EximiusTimerHandler<boost::function<void ()> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<eximius::EximiusTimerHandler<boost::function<void ()> >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running>, void (boost::system::error_code)>::type>::type boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> >::async_wait<boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf1<void, eximius::EximiusTimerHandler<boost::function<void ()> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<eximius::EximiusTimerHandler<boost::function<void ()> >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> >(boost::asio::detail::deadline_timer_service<boost::asio::time_traits<boost::posix_time::ptime> >::implementation_type&, boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf1<void, eximius::EximiusTimerHandler<boost::function<void ()> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<eximius::EximiusTimerHandler<boost::function<void ()> >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002f5536)
    #9 0x108205259 in boost::asio::async_result<boost::asio::handler_type<boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf1<void, eximius::EximiusTimerHandler<boost::function<void ()> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<eximius::EximiusTimerHandler<boost::function<void ()> >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running>, void (boost::system::error_code)>::type>::type boost::asio::basic_deadline_timer<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime>, boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> > >::async_wait<boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf1<void, eximius::EximiusTimerHandler<boost::function<void ()> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<eximius::EximiusTimerHandler<boost::function<void ()> >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> >(boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf1<void, eximius::EximiusTimerHandler<boost::function<void ()> >, boost::system::error_code const&>, boost::_bi::list2<boost::_bi::value<eximius::EximiusTimerHandler<boost::function<void ()> >*>, boost::arg<1> (*)()> >, boost::asio::detail::is_continuation_if_running> const&) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002c4259)
    #10 0x1081f95d6 in eximius::EximiusTimerHandler<boost::function<void ()> >::StartTimer() (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1002b85d6)
    #11 0x108081a7c in int eximius::Platform::ScheduleTimer<boost::function<void ()> >(boost::posix_time::time_duration const&, boost::function<void ()> const&, bool, char const*, unsigned int, unsigned int) (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100140a7c)
    #12 0x107fe3143 in eximius::ProcessControl::StartTimers() (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x1000a2143)
    #13 0x107f75593 in eximius::ProcessControl::StartApplication() (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100034593)
    #14 0x1096bc66e in eximius::EximiusApplication::StartEximiusApplication() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0xf366e)
    #15 0x108585856 in main (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x100644856)
    #16 0x7fff9077f5c8 in start (/usr/lib/system/libdyld.dylib+0x35c8)
    #17 0x0 (<unknown module>)

Thread T2 created by T0 here:
    #0 0x1088e106f in wrap_pthread_create (/opt/local/libexec/llvm-3.6/lib/clang/3.6.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x2406f)
    #1 0x10a477c1b in boost::thread::start_thread_noexcept() (/opt/local/lib/libboost_thread-mt.dylib+0x2c1b)
    #2 0x1095f4d04 in boost::thread::start_thread() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x2bd04)
    #3 0x1095f4c65 in boost::thread::thread<boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > > >(boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > >, boost::disable_if_c<boost::thread_detail::is_convertible<boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > >&, boost::detail::thread_move_t<boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > > > >::value, boost::thread::dummy*>::type) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x2bc65)
    #4 0x1095e307a in boost::thread::thread<boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > > >(boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > >, boost::disable_if_c<boost::thread_detail::is_convertible<boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > >&, boost::detail::thread_move_t<boost::_bi::bind_t<void, void (*)(unsigned int), boost::_bi::list1<boost::_bi::value<unsigned int> > > > >::value, boost::thread::dummy*>::type) (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x1a07a)
    #5 0x1095da31f in eximius::Platform::Initialize() (/Users/hgill/Work/dpi/sp4/build_debug/install/lib/libgencore-platform.dylib+0x1131f)
    #6 0x1085803a8 in main (/Users/hgill/Work/dpi/sp4/build_debug/install/./bin/process-manager+0x10063f3a8)
    #7 0x7fff9077f5c8 in start (/usr/lib/system/libdyld.dylib+0x35c8)
    #8 0x0 (<unknown module>)

SUMMARY: AddressSanitizer: container-overflow ??:0 __asan_memcpy
Shadow bytes around the buggy address:
  0x1c1800002e50: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x1c1800002e60: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
  0x1c1800002e70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c1800002e80: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x1c1800002e90: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
=>0x1c1800002ea0: 00 00 00 00 00 00 00 00 00 00[fc]fc fc fc fc fc
  0x1c1800002eb0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x1c1800002ec0: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
  0x1c1800002ed0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c1800002ee0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x1c1800002ef0: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  ASan internal:           fe
==16399==ABORTING
}}}

Somehow, the problem goes away when I schedule < 3 timers. ",harjotgill@…
10753,interprocess::winapi::c_heap_deleter::realloc_mem leaks memory,interprocess,Boost 1.57.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-11-05T15:44:31Z,2014-11-05T15:44:31Z,"Hi,

We believe that there is a memory leak in 
boost::interprocess::winapi::c_heap_deleter::realloc_mem

boost/interprocess/detail/win32_api.hpp:1790-1797
{{{
void realloc_mem(std::size_t num_bytes)
   {
      void *buf = ::realloc(m_buf, num_bytes);
      if(!buf){
         free(m_buf);
         m_buf = 0;
      }
   }
}}}

should probably be

{{{
void realloc_mem(std::size_t num_bytes)
   {
      void *buf = ::realloc(m_buf, num_bytes);
      if(!buf){
         free(m_buf);
         m_buf = 0;
      }
      else {
         m_buf = buf;
      }
   }
}}}

",Tomasz Wilk <tomasz.wilk@…>
10750,"bad interaction between ublas, float128 and std::complex",uBLAS,Boost 1.57.0,To Be Determined,Bugs,Gunter,new,2014-11-04T23:15:58Z,2014-11-04T23:22:06Z,"The following code fails to compile:

{{{
#include <boost/multiprecision/float128.hpp>
#include <boost/numeric/ublas/lu.hpp>

using boost::multiprecision::float128;

int main () {
	boost::numeric::ublas::matrix <std::complex<float128>> A(1,1);
	lu_factorize(A);
}
}}}

(on OSX 10.10 using g++-4.9 -fext-numeric-literals -lquadmath), I am getting a huge complaint about missing `operator<` at `numeric/ublas/detail/matrix_assign.hpp:33:35`. Things work perfectly with a matrix of float128, or a matrix of std::complex<double>. And other operations work with std::complex<float128>.

Is std::complex<float128> supposed to work?",vbeffara@…
10748,Add SHA sums to the boost/ files,None,Boost 1.57.0,To Be Determined,Feature Requests,Marshall Clow,new,2014-11-04T20:34:20Z,2014-11-04T20:38:07Z,Please add SHA sums to the files on `boost/` like you do for `boost-binaries/` on sourceforge (trac won't let me paste links),Ivan Alejandro <ivanalejandro0@…>
10744,wrong error code when doing async_connect and the connection is refused,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-11-04T08:56:02Z,2014-11-09T13:41:54Z,"When executing the following example the error_code provided is not correctly recognized as connection_refused. 

This is because the error_code supplied is provided by '''GetLastError''' and the error_code expected is provided by '''WSAGetLastError'''.

{{{
#!div style=""font-size: 80%""
  {{{#!cpp
#include <iostream>
#include ""boost/asio.hpp""

using namespace boost::asio;

int main(int argc, const char* argv[]) {
   io_service io_service;
   ip::tcp::socket::endpoint_type endpoint(ip::address_v4::from_string(""127.0.0.1""), 9999);
   ip::tcp::socket tcp_socket(io_service);

   tcp_socket.async_connect(endpoint, [](const boost::system::error_code& ec) {
      if (ec.value() != boost::asio::error::connection_refused) {
	std::cout << ""Expected error code "" << boost::asio::error::connection_refused
		  << "" but got "" << ec.value() << std::endl;
	} else {
 	   std::cout << ""got error code "" << ec.value() << std::endl;
	}
   });

   io_service.run();
   return 0;
}
  }}}
}}}

It seems that that this behavior change to earlier boost version has something to-do with this commit: [[github.com/boostorg/asio/commit/0484963a55bf109353922e1d5fdc2a218995d9e7]]

On linux system this example works fine",Martin Bonetti <martin.bonetti@…>
10743,Support Boost build on Windows using Clang,Building Boost,Boost 1.54.0,To Be Determined,Feature Requests,,new,2014-11-04T06:36:33Z,2015-02-13T19:36:38Z,"It will be lovely if it will be possible to build boost library using Clang (clang-cl) on Windows using standard win dev tools (no MingW, VS only).",kreuzerkrieg@…
10733,[wave] Hooks not called for expanding specific predefined macros,wave,Boost Development Trunk,To Be Determined,Bugs,Hartmut Kaiser,new,2014-11-01T15:52:15Z,2014-11-01T15:52:15Z,"Non of the preprocessor hook is called during the expansion of the following predefined macros: {{{__LINE__}}}, {{{__FILE__}}}, {{{__INCLUDE_LEVEL__}}}.

This is because the expansion of these macros are handled with a specific code path which skips the hooks.

Expected behavior:
* expanding_object_like_macro hook is called before the expansion
* expansion happens based on the return value from the hook
* expanded_macro hook is called after the expansion",Tamas Berghammer <berghammer.tamas@…>
10731,make_permissions is case-inconsistent and requires unnecessary conversions,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,new,2014-10-31T23:02:48Z,2017-04-30T17:21:15Z,"There exist two notable issues with the internal function make_permissions in operations.cpp (Windows only):

a) The usage of the macro BOOST_FILESYSTEM_STRICMP implies case-insensitive comparison, but for compilers different from _MSC_VER it actually calls the case-sensitive function std::strcmp.

b) The code uses up to four code-conversions (wchar_t->char) to invoke the comparison function, all of the following form:

{{{
BOOST_FILESYSTEM_STRICMP(p.extension().string().c_str(), "".exe"")
}}}

It seems that there exist a simple and consistent way to solve these problems: Replace the macro BOOST_FILESYSTEM_STRICMP by boost::algorithm::iequals and do not perform code conversion. Essentially the make_permissions code could be changed to the following form - assuming an additional inclusion of

{{{
#include ""boost/algorithm/string/predicate.hpp""
}}}

and removal of the BOOST_FILESYSTEM_STRICMP macro definition (which is no-where else used):

{{{
  perms make_permissions(const path& p, DWORD attr)
  {
    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;
    if (boost::algorithm::iequals(p.extension().c_str(), L"".exe"")
      || boost::algorithm::iequals(p.extension().c_str(), L"".com"")
      || boost::algorithm::iequals(p.extension().c_str(), L"".bat"")
      || boost::algorithm::iequals(p.extension().c_str(), L"".cmd""))
      prms |= fs::owner_exe | fs::group_exe | fs::others_exe;
    return prms;
  }
}}}

Given that boost::algorithm::iequals allows to provide a std::locale object as additional argument, one could improve that solution even more by providing the same locale as that from path_locale() within path.cpp. Unfortunately there is no access within operations.cpp to that function (which is within an unnamed namespace), so realizing this second improvement would require a larger surgery.
",daniel.kruegler@…
10728,Error in example of boost::accumulators,accumulator,Boost 1.56.0,To Be Determined,Bugs,Eric Niebler,new,2014-10-31T16:24:55Z,2015-02-13T18:36:39Z,"The first example (Hello, World!) in

http://www.boost.org/doc/libs/1_56_0/doc/html/accumulators/user_s_guide.html

does not compile because of an error on line 22:
{{{
std::cout << ""Moment: "" << accumulators::moment<2>(acc) << std::endl;
}}}
should be:
{{{
std::cout << ""Moment: "" << moment<2>(acc) << std::endl;
}}}",anonymous
10722,msm gives compilation errors when using state machine constructors with arguments,msm,Boost 1.57.0,,Bugs,Christophe Henry,reopened,2014-10-30T19:51:16Z,2014-11-05T08:07:20Z,"This code compiles fine with boost 1.55.0 but fails on 1.56.0.
Checked on  MSVC2012 and gcc.
{{{
#include <boost/msm/back/state_machine.hpp>         // back-end
#include <boost/msm/back/tools.hpp>
#include <boost/msm/front/state_machine_def.hpp>    // front-end
#include <boost/msm/front/functor_row.hpp>
#include <boost/msm/front/euml/operator.hpp>

namespace msm = boost::msm;
namespace mpl = boost::mpl;
using namespace msm::front;

struct Substate : public msm::front::state<> { };

struct State_ : public msm::front::state_machine_def<State_>
{
    State_(int) {}
    State_() {}

        struct transition_table : mpl::vector<
        //   Start        Event         Next         Action      Guard
        //  +------------+-------------+------------+-----------+------------+
        Row < Substate   , none        , none       , none      , none       >
    > {};

    typedef Substate initial_state;
};
typedef msm::back::state_machine<State_> State;


// machine itself
struct TestFSM_ : public msm::front::state_machine_def<TestFSM_>
{
    TestFSM_(int) {}
    TestFSM_() {}

    struct transition_table : mpl::vector<
        //   Start        Event          Next         Action      Guard
        //  +------------+--------------+------------+-----------+-----------+
        Row < State      , none         , none       , none      , none      >
    > {};

    typedef State initial_state;
};
typedef msm::back::state_machine<TestFSM_> TestFSM;

void start()
{
    TestFSM(msm::back::states_ << State(10), 10);
}
}}}

Error output from MSVC2012 looks like this:
{{{
1>  test.cpp
1>c:\test\boost\boost\core\enable_if.hpp(36): error C2039: 'value' : is not a member of 'boost::is_convertible<From,To>'
1>          with
1>          [
1>              From=boost::fusion::vector1<boost::msm::back::state_machine<State_>>,
1>              To=boost::msm::back::state_machine<State_>
1>          ]
1>          c:\test\boost\boost\type_traits\is_convertible.hpp(486) : see reference to class template instantiation 'boost::enable_if<Cond,T>' being compiled
1>          with
1>          [
1>              Cond=boost::is_convertible<boost::fusion::vector1<boost::msm::back::state_machine<State_>>,boost::msm::back::state_machine<State_>>,
1>              T=void
1>          ]
1>          c:\test\boost\boost\core\enable_if.hpp(59) : see reference to class template instantiation 'boost::is_convertible<From,To>' being compiled
1>          with
1>          [
1>              From=boost::fusion::vector1<boost::msm::back::state_machine<State_>>,
1>              To=boost::msm::back::state_machine<State_>
1>          ]
1>          c:\test\boost\boost\fusion\container\vector\convert.hpp(46) : see reference to class template instantiation 'boost::disable_if<Cond,T>' being compiled
1>          with
1>          [
1>              Cond=boost::is_convertible<boost::fusion::vector1<boost::msm::back::state_machine<State_>>,boost::msm::back::state_machine<State_>>,
1>              T=void
1>          ]
1>          c:\test\boost\boost\msm\back\state_machine.hpp(1564) : see reference to function template instantiation 'boost::fusion::vector1<T0> boost::fusion::as_vector<boost::fusion::cons<Car,Cdr>>(const Sequence &)' being compiled
1>          with
1>          [
1>              T0=boost::msm::back::state_machine<State_>,
1>              Car=boost::msm::back::state_machine<State_>,
1>              Cdr=boost::fusion::nil_,
1>              Sequence=boost::fusion::cons<boost::msm::back::state_machine<State_>,boost::fusion::nil_>
1>          ]
1>          c:\test\boost\boost\msm\back\state_machine.hpp(1655) : see reference to function template instantiation 'void boost::msm::back::state_machine<A0>::set_states<Expr>(const Expr &)' being compiled
1>          with
1>          [
1>              A0=TestFSM_,
1>              Expr=boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::shift_left,boost::proto::argsns_::list2<const boost::msm::back::define_states_creation<> &,boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<const boost::msm::back::state_machine<State_> &>,0>>>,2>>
1>          ]
1>          c:\test\boost\boost\msm\back\state_machine.hpp(1655) : see reference to function template instantiation 'void boost::msm::back::state_machine<A0>::set_states<Expr>(const Expr &)' being compiled
1>          with
1>          [
1>              A0=TestFSM_,
1>              Expr=boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::shift_left,boost::proto::argsns_::list2<const boost::msm::back::define_states_creation<> &,boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<const boost::msm::back::state_machine<State_> &>,0>>>,2>>
1>          ]
1>          c:\test\ffc\audioextractor\dataanalyzer\engines\test.cpp(47) : see reference to function template instantiation 'boost::msm::back::state_machine<A0>::state_machine<boost::msm::msm_terminal<Expr>,int>(const boost::msm::msm_terminal<Expr> &,ARG0,void *)' being compiled
1>          with
1>          [
1>              A0=TestFSM_,
1>              Expr=boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::shift_left,boost::proto::argsns_::list2<const boost::msm::back::define_states_creation<> &,boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<const boost::msm::back::state_machine<State_> &>,0>>>,2>,
1>              ARG0=int
1>          ]
1>          c:\test\ffc\audioextractor\dataanalyzer\engines\test.cpp(47) : see reference to function template instantiation 'boost::msm::back::state_machine<A0>::state_machine<boost::msm::msm_terminal<Expr>,int>(const boost::msm::msm_terminal<Expr> &,ARG0,void *)' being compiled
1>          with
1>          [
1>              A0=TestFSM_,
1>              Expr=boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::shift_left,boost::proto::argsns_::list2<const boost::msm::back::define_states_creation<> &,boost::msm::msm_terminal<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<const boost::msm::back::state_machine<State_> &>,0>>>,2>,
1>              ARG0=int
1>          ]
1>c:\test\boost\boost\core\enable_if.hpp(36): error C2065: 'value' : undeclared identifier
1>c:\test\boost\boost\core\enable_if.hpp(36): error C2975: 'B' : invalid template argument for 'boost::enable_if_c', expected compile-time constant expression
1>          c:\test\boost\boost\core\enable_if.hpp(27) : see declaration of 'B'
}}}",Marek Glos <marekglos@…>
10720,boost::interprocess Windows semaphore and mutex creation can fail due to naming convention,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-10-30T13:14:34Z,2014-10-30T13:14:34Z,"boost::interprocess names the mutexes and semaphores using the sync_id and sync_handles classes found in interprocess/sync/windows/sync_utils.hpp. The sync_id class uses winapi::query_performance_counter to obtain a value which is then used to create a supposedly unique identifier for the semaphore or mutex in sync_handles::fill_name.

The problem is that when multiple mutexes and/or semaphores are created within such a short time frame that the value returned by winapi::query_performance_counter does not change, the creation fails with winapi::error_already_exists.",Ville Outamaa <ville.outamaa@…>
10716,"Pool allocators fail to compile under g++4.7, 4.8 and 4.9",pool,Boost 1.56.0,To Be Determined,Bugs,Chris Newbold,new,2014-10-30T06:28:07Z,2014-10-30T06:28:07Z,"Hi,

Usage of either boost::pool_allocator or boost::fast_pool_allocator with std::allocate_shared can cause compile errors on the g++4.7, 4.8, 4.9. There is much more detailed information on the stack overflow question I made: [http://stackoverflow.com/questions/26396293/boost-pool-allocators-wont-compile-with-stdallocate-shared-in-g]

Code exhibiting the error:

{{{
#include ""boost/pool/pool.hpp""
#include ""boost/pool/pool_alloc.hpp""

#include <memory>

int main(int argc, char** argv)
{
  auto fails = std::allocate_shared<int>( boost::fast_pool_allocator<int>() );

  auto works = std::allocate_shared<int>(boost::fast_pool_allocator<int>(), 5);
}
}}}

Simply put boost allocators are still specified using the c++98 style and this causes g++ to fail for the versions of g++ mentioned above. However it should be noted that g++ 5.0 does compile correctly and this implies that updating is not necessarily mandatory. I have made this ticket so that the appropriate people can make a determination about whether to fix this or not. Also note that changing to the c++11 allocator style seems to be straightforward.
",Conrad Mercer <conrad.mercer@…>
10715,Race condition in codecvt() persists in VC++,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2014-10-29T15:51:13Z,2016-06-27T13:45:50Z,"This is a restatement of Ticket #6320, which is still causing me problems; specifically when path objects are used in a DLL with multithreading. Environment is VC++11, although I believe it is also applicable to VC++12. Both versions have documentation warnings against using static local variables in a multithreaded application.

Demo code: A DLL containing the simple function:
{{{
//  exported function.
extern ""C"" DLL_API void fnDll( void )
{
	boost::filesystem::path p(""test_path"");
	return;
}
}}}
The main program creates threads to load the DLL and call this function:
{{{
void thread_func() 
{
	boost::this_thread::sleep(boost::posix_time::milliseconds(100));
	HINSTANCE hLib = LoadLibraryA(""Dll.dll""); 
	if (hLib != NULL) { // Resolve test function in DLL
		FARPROC f = GetProcAddress(hLib,""fnDll"");
		if (f)	f(); // call it
	}
}

int main(int argc, _TCHAR* argv[])
{
	boost::thread_group tg;
	for(int i = 0; i < 2; i++)
		tg.create_thread(thread_func);
	tg.join_all();
	return 0;
}
}}}
Built and run for debug, this code fails when the BOOST_ASSERT:

""codecvt_facet_ptr() facet hasn't been properly initialized""

fires on line 888, in const path::codecvt_type& path::codecvt()

The user workaround is to put code in DllMain's DLL_PROCESS_ATTACH, as described in the earlier ticket, to force initialisation before multiple threads share the DLL.

I attach the Visual Studio project used to test this. This DLL scenario is a simplification of a genuine situation: I found it when an Apache add-on started crashing its host.",willw@…
10710,IGMPv3,asio,Boost 1.56.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-10-28T19:30:12Z,2014-10-28T19:30:12Z,"Hi,

any plans to include IGMPv3 multicasting (i.e. ability to specify source address in IGMP report)? This would be very useful for modern multicast applications

regards
michal",michal.vanco@…
10709,Graph bundled property support in subgraph,graph,Boost Development Trunk,To Be Determined,Patches,Jeremiah Willcock,new,2014-10-28T17:46:08Z,2014-10-28T17:46:08Z,Here's a patch which adds support of graph bundled property access via operator[] in subgraph interface.,Alexey Chernov <4ernov@…>
10708,Property support in add_vertex() method for subgraph,graph,Boost Development Trunk,To Be Determined,Patches,Jeremiah Willcock,new,2014-10-28T17:42:48Z,2014-10-28T17:47:02Z,Patch with added support of bundled properties in add_vertex() method of the subgraph to make it more unified with other graph concepts.,Alexey Chernov <4ernov@…>
10707,Subgraph copy constructor doesn't copy all the data for children subgraphs,graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,new,2014-10-28T17:37:41Z,2014-10-28T17:47:35Z,"Subgraph copy constructor doesn't copy all the data required for normal working in case of the subgraph object actually represents children subgraph. As a result, copied object is not equal to original one and usually can't be used any more.

Here's the data fields that aren't copied:
1. m_graph (is copied only in case the subgraph object represents root subgraph).
2. m_local_vertex and m_local_edge containers (ok for root subgraph, data loss for children subgraphs).

The patch with fix is attached.",4ernov@…
10706,boost::spirit::basic_istream_iterator does not satisfy single pass iterator requirements,spirit,Boost 1.56.0,To Be Determined,Bugs,Joel de Guzman,new,2014-10-28T15:13:58Z,2014-10-28T15:23:42Z,"It is not possible, for example, to use boost::iterator_range with spirit::basic_istream_iterator

{{{
clang++ -v
clang version 3.6.0 (trunk 216817)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
}}}

{{{
using namespace boost;
size (iterator_range<spirit::istream_iterator> ());
}}}

{{{
In file included from /opt/local/include/boost/spirit/include/qi.hpp:16:
In file included from /opt/local/include/boost/spirit/home/qi.hpp:14:
In file included from /opt/local/include/boost/spirit/home/qi/action.hpp:14:
In file included from /opt/local/include/boost/spirit/home/qi/action/action.hpp:14:
In file included from /opt/local/include/boost/spirit/home/qi/meta_compiler.hpp:14:
In file included from /opt/local/include/boost/spirit/home/support/meta_compiler.hpp:19:
In file included from /opt/local/include/boost/proto/proto.hpp:16:
In file included from /opt/local/include/boost/proto/functional.hpp:14:
In file included from /opt/local/include/boost/proto/functional/range.hpp:17:
In file included from /opt/local/include/boost/proto/functional/range/size.hpp:12:
In file included from /opt/local/include/boost/range/size.hpp:21:
In file included from /opt/local/include/boost/range/size_type.hpp:20:
/opt/local/include/boost/range/concepts.hpp:158:26: error: no matching constructor for initialization of 'boost::spirit::basic_istream_iterator<char, std::__1::char_traits<char> >'
                Iterator i2(++i);
                         ^  ~~~
/opt/local/include/boost/concept/usage.hpp:16:43: note: in instantiation of member function 'boost::range_detail::SinglePassIteratorConcept<boost::spirit::basic_istream_iterator<char, std::__1::char_traits<char> > >::~SinglePassIteratorConcept' requested here
    ~usage_requirements() { ((Model*)0)->~Model(); }
                                          ^
/opt/local/include/boost/concept/detail/general.hpp:38:42: note: in instantiation of member function 'boost::concepts::usage_requirements<boost::range_detail::SinglePassIteratorConcept<boost::spirit::basic_istream_iterator<char, std::__1::char_traits<char> > > >::~usage_requirements' requested here
    static void failed() { ((Model*)0)->~Model(); }
                                         ^
/opt/local/include/boost/range/concepts.hpp:156:13: note: in instantiation of member function 'boost::concepts::requirement<boost::concepts::failed ************boost::concepts::usage_requirements<boost::range_detail::SinglePassIteratorConcept<boost::spirit::basic_istream_iterator<char, std::__1::char_traits<char> > > >::************>::failed' requested here
            BOOST_CONCEPT_USAGE(SinglePassIteratorConcept)
            ^
/opt/local/include/boost/concept/usage.hpp:29:7: note: expanded from macro 'BOOST_CONCEPT_USAGE'
      BOOST_CONCEPT_ASSERT((boost::concepts::usage_requirements<model>)); \
      ^
/opt/local/include/boost/concept/assert.hpp:43:5: note: expanded from macro 'BOOST_CONCEPT_ASSERT'
    BOOST_CONCEPT_ASSERT_FN(void(*)ModelInParens)
    ^
/opt/local/include/boost/concept/detail/general.hpp:78:51: note: expanded from macro 'BOOST_CONCEPT_ASSERT_FN'
    &::boost::concepts::requirement_<ModelFnPtr>::failed>    \
                                                  ^
/opt/local/include/boost/spirit/home/support/iterators/istream_iterator.hpp:56:18: note: candidate constructor not viable: no known conversion from 'boost::spirit::multi_pass<std::__1::basic_istream<char>, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted, boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::istream, boost::spirit::iterator_policies::split_std_deque> >' to 'std::basic_istream<char, char_traits<char> > &' for 1st argument
        explicit basic_istream_iterator(std::basic_istream<Elem, Traits>& x)
                 ^
/opt/local/include/boost/spirit/home/support/iterators/istream_iterator.hpp:59:9: note: candidate constructor not viable: no known conversion from 'boost::spirit::multi_pass<std::__1::basic_istream<char>, boost::spirit::iterator_policies::default_policy<boost::spirit::iterator_policies::ref_counted, boost::spirit::iterator_policies::no_check, boost::spirit::iterator_policies::istream, boost::spirit::iterator_policies::split_std_deque> >' to 'const boost::spirit::basic_istream_iterator<char, std::__1::char_traits<char> >' for 1st argument
        basic_istream_iterator(basic_istream_iterator const& x)
        ^
/opt/local/include/boost/spirit/home/support/iterators/istream_iterator.hpp:53:9: note: candidate constructor not viable: requires 0 arguments, but 1 was provided
        basic_istream_iterator()
        ^
1 error generated.
}}}",Nikki Chumakov <nikkikom@…>
10704,[property_tree] Readablilty improvement ini_parser::write_ini result.,property_tree,Boost 1.50.0,To Be Determined,Patches,Sebastian Redl,new,2014-10-28T12:20:50Z,2018-05-20T14:39:15Z,Output file of write_ini lacks readability. Attached patch adds spaces between keys and values and separates sections by newlines.,Eduard Eduardov <eduardov.eduard@…>
10702,"tut1 test:""tut1.cpp"", line 40: Error: noncopyable is not a member of boost w/ studio c++",ptr_container,Boost 1.55.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-10-27T23:20:38Z,2014-10-27T23:20:38Z,"Problem:
ptr_container/tut1 test fails with ""line 40: Error: noncopyable is not a member of boost"" w/ studio c++ and ""tut1.cpp:41:1: error: expected class-name before '{' token  "" with g++-4.8.2.

Solution:
add #include <boost/noncopyable.hpp> into tut1.cpp.

",angela.xie@…
10698,noexcept(true) for ~noncopyable?,core,Boost 1.57.0,To Be Determined,Bugs,Peter Dimov,new,2014-10-25T14:38:44Z,2017-07-08T20:06:27Z,"Shouldn't ~noncopyable be noexcept?

I'm seeing this error:

{{{
class Cconnection : public Cclient, boost::noncopyable

connection.h:5:7: error: looser throw specifier for ‘virtual Cconnection::~Cconnection()’
In file included from connection.h:3:0,
                 from connection.cpp:2:
client.h:10:10: error:   overriding ‘virtual Cclient::~Cclient() noexcept (true)’
}}}",olafvdspek@…
10692,"No ""/lib"" directory or precompiled library binaries [1.56.0]",Getting Started Guide,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,new,2014-10-24T13:14:18Z,2014-10-24T14:59:16Z,"The current release has no ""lib"" directory which should contain precompiled library binaries. The directory is missing in both Windows and Unix distributions.

 - The directory is mentioned in several steps on the getting started page (http://www.boost.org/doc/libs/1_56_0/more/getting_started/windows.html).

 - Without the binaries I'm unable to compile due to the missing ""libboost_system-vc120-mt-gd-1_56.lib"" file.

Any help greatly appreciated.",Richard Livingston <r1ch4rdl@…>
10691,"ip/multicast:runtime failure, error in ""ip_multicast_runtime::test"": 22, Invalid argument",asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-24T00:32:38Z,2014-10-24T00:32:38Z,"Problem:
asio/ip/multicast[_select] fail to execute with error message ""
multicast.cpp(329): error in ""ip_multicast_runtime::test"": 22, Invalid argument""
if compile it with studio 12.4 c++ and g++-4.8.2 on solaris 11.2",angela.xie@…
10690,Boost SSL protocols,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-23T15:35:49Z,2016-08-16T13:47:14Z,"Hello,

I use Boost SSL socket. I want to disable the TLS security protocol so I use set_options like this:

m_context.set_options(ssl::context::no_tlsv1);

But it only disables TLSv1, not TLSv1.1 and TLSv1.2. I looked at the boost source code and I saw this :

BOOST_ASIO_STATIC_CONSTANT(long, no_tlsv1 = SSL_OP_NO_TLSv1);

Why SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 are not wrapped ?

Thx",anonymous
10689,static_assert.hpp: unrecognized #pragma GCC system_header,static_assert,Boost 1.56.0,To Be Determined,Bugs,John Maddock,new,2014-10-23T14:10:52Z,2014-10-23T14:10:52Z,"I am using boost 1.55.0 within my code. Whenever boost's boost/static_assert.hpp is included the compiler complains about unrecognized pragma. The compiler in question is TI DSP for TMS3200C67x processor, invoked with the --gcc option. This option makes it to predefine the __GNUC__ macro, hence, due to conditional preprocessing ""#pragma GCC system_header"" line is being subjected to compilation. This pragma is not supported by the TI compiler causing it to emit a warning.

The issue will be resolved once the same solution as for https://svn.boost.org/trac/boost/ticket/7094 is applied in the static_asssert.hpp file.",Wojciech Migda <wojtek.golf@…>
10683,Boost.Iostreams: typos in the doc,iostreams,Boost 1.56.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-10-21T14:35:23Z,2014-11-04T09:13:27Z,"http://www.boost.org/doc/libs/1_56_0/libs/iostreams/doc/tutorial/shell_comments_filters.html reads

""unix2dos_stdio_filter can be used in place of shell_comments_input_filter and shell_comments_output_filter""

It should read (first id is changed):

""shell_comments_stdio_filter can be used in place of shell_comments_input_filter and shell_comments_output_filter""",akim demaille <akim@…>
10675,support pruning/stopping bfs/dfs traversing,graph,Boost 1.56.0,To Be Determined,Feature Requests,Jeremiah Willcock,new,2014-10-19T02:09:26Z,2014-10-19T02:09:26Z,"In some cases, BFS/DFS traversal is required only in the local neighborhood of a node (i.e. I would like to visit nodes up to a defined distance, and this distance may have an implementation-dependent meaning) or to only traverse certain portions of the graph (i.e. to skip certain edges/target nodes based on some property found during traversal). 
Currently, BFS/DFS do not allow to do this. One way would be to gain access to the underlying color map but the functions take the map by copy. Another (cleaner, IMHO) way, would be to allow the events to return true/false which could allow the BFS/DFS algorithm to skip the target node/edge or not.",phreakuencies@…
10674,Boost 1.56 freezes app on some systems with Windows 7,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-18T23:01:11Z,2014-10-18T23:26:12Z,"I am the developer of qBittorrent. It uses libtorrent-rasterbar which in turn uses Boost (mostly Asio).
I recently made a new release. I compiled against Boost 1.56.
However I got some complaints from users that the GUI freezes for 5-20secs frequently. All these users are using Windows 7.
However I am using Windows XP and I am unable to reproduce.
To make the long story short, I provided different test builds based on Boost.Asio and we pinpointed the commit that introduced the freezing problem.

Here is the relevant issue from our bug tracker: **url removed**
Here is the offending commit: **url removed**

If you need any more info, I'll try to provide it.",sledgehammer_999 <hammered999@…>
10670,stl_concept_covering.cpp:failed to compile w/ studio c++,concept_check,Boost 1.55.0,To Be Determined,Bugs,jsiek,new,2014-10-16T20:02:09Z,2014-10-16T20:02:09Z,"stl_concept_covering.cpp:failed to compile w/ studio c++ with ""stl_concept_covering.cpp"", line 603: Error: FT is not defined.
""stl_concept_covering.cpp"", line 604: Error: T is not defined.
",angela.xie@…
10669,Assertion failed in broadcast with BOOST_MPI_HOMOGENEOUS defined,mpi,Boost 1.56.0,To Be Determined,Bugs,Matthias Troyer,new,2014-10-16T16:34:54Z,2014-10-16T16:34:54Z,"When running a program that does a very simple broadcast of a map<int, int> from the root proc (0) to another proc (1), I get this error:

{{{
Assertion failed: (position+l<=static_cast<int>(buffer_.size())), function load_impl, file /Users/sbateman/tmp/boost_mpi_test/boost_1_56_0/boost/mpi/detail/binary_buffer_iprimitive.hpp, line 110.
}}}

This only happens when I compile Boost with BOOST_MPI_HOMOGENEOUS defined (i.e., uncommented) in boost/mpi/config.hpp.  If I leave that line commented out, the program completes successfully.

I've attached a source file (test.cpp) that reproduces this error.  I tested this on a Mac system with OS X 10.9.5 and compiler version:
{{{
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
}}}

and also on a Linux system with compiler version:
{{{
gcc version 4.8.2 20131016 (Cray Inc.) (GCC)
Target: x86_64-suse-linux
}}}",sam.bateman@…
10667,"VC++ 2013 compiler warning C4244: 'initializing' : conversion from 'double' to 'const coordinate_type', possible loss of data",geometry,Boost 1.66.0,To Be Determined,Support Requests,Barend Gehrels,new,2014-10-16T10:49:39Z,2018-01-04T14:02:29Z,"I'm using Microsoft Visual Studio 12 (2013) to compile boost 1.56.0. I use compiler flag /W4. The following warnings (which we declared errors for our project) occur in geometry, regardless whether I'm compiling for x64 or x86:
{{{
\boost_1_56_0\boost\geometry\algorithms\detail\sections\sectionalize.hpp(612): warning C4244: 'initializing' : conversion from 'double' to 'const coordinate_type', possible loss of data
}}}

Please consider related Ticket #8402.",Volker Schöch <vschoech@…>
10660,svg_mapper crash,geometry,Boost 1.56.0,To Be Determined,Bugs,Barend Gehrels,new,2014-10-15T15:56:42Z,2014-10-15T15:56:42Z,"When I slightly modify the example from the [http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/geometry/reference/io/svg/svg_mapper.html documentation], the code crashes with an obscure (for me) exception deep in the callstack.

Running this code:
{{{
std::ostringstream svg;
 
// Specify the basic type
typedef boost::geometry::model::d2::point_xy<int> point_type;
 
// Declare some geometries and set their values
point_type a;
boost::geometry::assign_values(a, -100, -100);
 
// Declare a stream and an SVG mapper
boost::geometry::svg_mapper<point_type> mapper(svg, 1000, 1000);
 
// Add geometries such that all these geometries fit on the map
mapper.add(a);
 
// Draw the geometries on the SVG map, using a specific SVG style
mapper.map(a, ""fill-opacity:0.5;fill:rgb(153,204,0);stroke:rgb(153,204,0);stroke-width:2"", 5);
 
// Destructor of map will be called - adding </svg>
// Destructor of stream will be called, closing the file
}}}

... throws this exception:
{{{
Microsoft C++ exception: boost::numeric::negative_overflow at memory location 0x00000000001E9D60.
}}}

... at this call-stack:
{{{
tcaddin.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 154	C++
tcaddin.dll!boost::numeric::def_overflow_handler::operator()(boost::numeric::range_check_result r) Line 164	C++
tcaddin.dll!boost::numeric::convdetail::generic_range_checker<boost::numeric::conversion_traits<int,double>,boost::numeric::convdetail::LE_PrevLoT<boost::numeric::conversion_traits<int,double> >,boost::numeric::convdetail::GE_SuccHiT<boost::numeric::conversion_traits<int,double> >,boost::numeric::def_overflow_handler>::validate_range(double s) Line 294	C++
tcaddin.dll!boost::numeric::convdetail::rounding_converter<boost::numeric::conversion_traits<int,double>,boost::numeric::convdetail::generic_range_checker<boost::numeric::conversion_traits<int,double>,boost::numeric::convdetail::LE_PrevLoT<boost::numeric::conversion_traits<int,double> >,boost::numeric::convdetail::GE_SuccHiT<boost::numeric::conversion_traits<int,double> >,boost::numeric::def_overflow_handler>,boost::numeric::raw_converter<boost::numeric::conversion_traits<int,double> >,boost::numeric::Trunc<double> >::convert(double s) Line 494	C++
tcaddin.dll!boost::numeric_cast<int,double>(double arg) Line 54	C++
tcaddin.dll!boost::geometry::strategy::transform::ublas_transformer<double,2,2>::apply<boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian>,boost::geometry::model::point<int,2,boost::geometry::cs::cartesian> >(const boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> & p1, boost::geometry::model::point<int,2,boost::geometry::cs::cartesian> & p2) Line 115	C++
tcaddin.dll!boost::geometry::detail::transform::transform_point::apply<boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian>,boost::geometry::model::point<int,2,boost::geometry::cs::cartesian>,boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> >(const boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> & p1, boost::geometry::model::point<int,2,boost::geometry::cs::cartesian> & p2, const boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> & strategy) Line 58	C++
tcaddin.dll!boost::geometry::resolve_strategy::transform::apply<boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian>,boost::geometry::model::point<int,2,boost::geometry::cs::cartesian>,boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> >(const boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> & geometry1, boost::geometry::model::point<int,2,boost::geometry::cs::cartesian> & geometry2, const boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> & strategy) Line 358	C++
tcaddin.dll!boost::geometry::resolve_variant::transform<boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian>,boost::geometry::model::point<int,2,boost::geometry::cs::cartesian> >::apply<boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> >(const boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> & geometry1, boost::geometry::model::point<int,2,boost::geometry::cs::cartesian> & geometry2, const boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> & strategy) Line 391	C++
tcaddin.dll!boost::geometry::transform<boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian>,boost::geometry::model::point<int,2,boost::geometry::cs::cartesian>,boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> >(const boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> & geometry1, boost::geometry::model::point<int,2,boost::geometry::cs::cartesian> & geometry2, const boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> & strategy) Line 454	C++
tcaddin.dll!boost::geometry::dispatch::svg_map<boost::geometry::point_tag,boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> >::apply<boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> >(std::basic_ostream<char,std::char_traits<char> > & stream, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & style, int size, const boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> & point, const boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> & strategy) Line 87	C++
tcaddin.dll!boost::geometry::svg_map<boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian>,boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> >(std::basic_ostream<char,std::char_traits<char> > & stream, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & style, int size, const boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> & geometry, const boost::geometry::strategy::transform::map_transformer<double,2,2,1,1> & strategy) Line 213	C++
tcaddin.dll!boost::geometry::svg_mapper<boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian>,1>::map<boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> >(const boost::geometry::model::d2::point_xy<int,boost::geometry::cs::cartesian> & geometry, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & style, int size) Line 334	C++
[...]
}}}
",Volker Schöch <vschoech@…>
10659,svg_mapper output is offset for int-based point type,geometry,Boost 1.56.0,To Be Determined,Bugs,Barend Gehrels,new,2014-10-15T15:45:23Z,2014-10-15T15:50:39Z,"Based on the example from the [http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/geometry/reference/io/svg/svg_mapper.html documentation] I find the following oddity: Simply change the following line
{{{
typedef boost::geometry::model::d2::point_xy<double> point_type;
}}}
into
{{{
typedef boost::geometry::model::d2::point_xy<int> point_type;
}}}
Nota bene: All values in the example code are integral numbers, anyway. Yet, the resulting output is different, see attached files. In case of int, the entire graphic is considerably offset to the north.",Volker Schöch <vschoech@…>
10656,build static boost libraries with -fPIC,Building Boost,Boost 1.55.0,To Be Determined,Support Requests,,new,2014-10-14T20:27:00Z,2014-10-24T16:50:14Z,"I am trying to build static boost libraries with -fPIC compliler option. I am using RHEL6 with GCCv4.4.
I am using the following command ""./bootstrap.sh CXXFLAGS=-fPIC"".
After this is use ""./b2""
Is this the proper procedure?
Thanks,
Raymond.",raymond_desantos@…
10644,BOOST_IPC_SHARED_DIR env variable to be used for get_shared_dir(),interprocess,Boost 1.57.0,Boost 1.57.0,Feature Requests,Ion Gaztañaga,new,2014-10-10T17:02:02Z,2018-03-07T18:03:13Z,"Hi,

Will it be possible to have shared_dir not hardcoded?
Currently it is determine by some tricks (some involve event log parsing on windows, which fails a lot).
The only practical solution for us was to use  BOOST_INTERPROCESS_SHARED_DIR_PATH define.

boost/interprocess/detail/shared_dir_helpers.hpp


inline void get_shared_dir(std::string &shared_dir)
{
   #if defined(BOOST_INTERPROCESS_SHARED_DIR_PATH)
      shared_dir = BOOST_INTERPROCESS_SHARED_DIR_PATH;
   #else
      get_shared_dir_root(shared_dir);
      #if defined(BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME)
         shared_dir += ""/"";
         get_bootstamp(shared_dir, true);
      #endif
   #endif
}

That has limitations tough as it makes it very difficult to test software in isolation (it requires access to the same folder).
Similarly it makes is difficult to run program of machines with different file structure.

Can it be configurable by some environment variable ?

----
Ion Gaztañaga :

This seems a good idea. I guess we won't support changing the value of the variable while the program is running, right? For performance reasons, I guess we could just cache the value the first time we access to the environment variable (or maybe in program startup).

""BOOST_INTERPROCESS_SHARED_DIR_PATH"" is too long for that environment variable name?

---------
BOOST_IPC_SHARED_DIR is good name for env variable
It should be read just at the start of the process (no need to change it during running of the program)

thanks a lot!


",qba.szymanski@…
10642,polygon_set_data<int> bug with small coordinates,polygon,Boost 1.58.0,To Be Determined,Bugs,Andrii Sydorchuk,reopened,2014-10-09T18:49:42Z,2015-04-06T21:16:10Z,"The attached test program creates a small polygon with a hole and adds it to a polygon_set_data<int>. The internal representation of the polygon set is rather messed up, as you can confirm by calling .get() or .get_trapezoids().

This test program demonstrates the bug by comparing the area of the polygon to the area of a polygon set containing that single polygon. The area of the polygon is correctly computed as 32; the area of the polygon set is incorrectly computed as 30.

Doubling all coordinates avoids the bug.
","""Patrick LoPresti"" <lopresti@…>"
10633,mingw project was migrated to mingw-w64 6 mos to a year ago,Documentation,Boost 1.56.0,To Be Determined,Bugs,Daniel James,new,2014-10-07T18:36:38Z,2015-02-01T22:06:37Z,"http://www.boost.org/users/history/version_1_56_0.html
under compilers tested, windows you have listed mingw. 

mingw is no longer maintained and has been migrated to mingw-w64. 

you might be confusing mingw-w64 with mingw which are different projects. it gives folks the wrong idea as to which compiler to use.

the current state of mingw-w64 is that a number of cross compilers (auto builds, mostly for linux and darwin) are generated by the build system. the personal donsheng daily builds seem stable:

sf.net mingw-w64 prohject, toolchains targeting win32 and win64, personal builds, dongsheng daily

MSYS can be used for a build environment but it must be configured. I have a configuration for that, but it needs to be submitted to the project yet when it gets completed.

interestingly enough, this bug tracking system rejects my posting of the compiler URLs as spam and says I should have completed the captcha, but no captcha was given. I am using firefox on win7x64.

at best, ""mingw"" might be a misnomer.",jmichae3@…
10632,Problem with range transform with gcc-4.8 optimized,range,Boost 1.55.0,To Be Determined,Bugs,Neil Groves,new,2014-10-07T15:52:45Z,2014-10-07T15:52:45Z,"With gcc4.8, if the option -O is used, the operation "" | transformed(arg1)"" on a transformed range leads to unexpected results.

E.g. if ""initialVec"" is a vector containing any values, the following line gives a null resultVec:[[BR]]
auto resultVec =  initialVec | transformed( arg1 * 2 ) | transformed( arg1 );

This problem is also present with clang (optimized) and visual studio 2013 (in release), but not in debug modes, and not with gcc-4.6.

Note that an operation in the second transformed remove this problem: the following code is working as expected:[[BR]]
auto resultVec =  initialVec | transformed( arg1 * 2 ) | transformed( arg1 * 1 );

This problem has been reproduced with boost 1.49, 1.55 and 1.56.",Fabien Nendaz <fabien@…>
10630,iostreams/test/code_converter_test does not compile with Xcode 6,iostreams,Boost 1.56.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-10-07T12:54:02Z,2014-10-27T14:17:19Z,"Apparently the bundled std::codecvt template has changed in a way incompatible with code_converter_test.

{{{
./b2 toolset=darwin variant=release address-model=32 -a -q architecture=x86 -sNO_BZIP2=1 libs/iostreams/test//code_converter_test
...
darwin.compile.c++ bin.v2/libs/iostreams/test/code_converter_test.test/darwin-4.2.1/release/address-model-32/architecture-x86/code_converter_test.o
In file included from libs/iostreams/test/code_converter_test.cpp:17:
In file included from ./boost/iostreams/code_converter.hpp:35:
./boost/iostreams/detail/codecvt_helper.hpp:217:25: error: implicit instantiation of undefined template 'std::__1::codecvt<wchar_t, char, boost::iostreams::tes\
t::null_padded_codecvt_state>'
struct codecvt_helper : std::codecvt<Intern, Extern, State> {
                        ^
}}}

This same error occurs with debug and 64-bit builds.

This is not a regression: the same failure occurs with Boost 1.55.0.",nat@…
10629,Interprocess Vector resize causes crash,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-10-07T11:21:32Z,2014-10-07T11:21:32Z,"Our existing code that has worked through many versions of Boost has failed in Boost 1.56.0.

I've reduced our code down to a specific example that replicates the issue in the following development environment:
  (1) Windows 7 64-bit
  (2) VS2010 and VS2013 (generating X64 code)

The example code produces a tree-like structure. Each node contains an interprocess vector that contains child nodes. The depth of the tree is 3 (parent, child, grandchild). The parent (root) node contains '''D''' child nodes, each child node contains '''D''' grandchild nodes, and the children of the grandchild nodes are left empty. The example program crashes when using a dimension, '''D''', of 43, but is fine for 42 and less.

The tree is constructed in a depth-first process so there will be some resizing of the vectors in the child and parent nodes after the grandchild nodes have been created and added to the structure.

The crash generates the following error:

''Assertion failed: ptr != 0, file D:\boost64\include\boost-1_56\boost/interprocess/allocators/allocator.hpp, line 268''

The crash can be prevented by reserving the correct amount of space ahead of node insertion.

Sample code is available:
github.com/peter-durrant/sandbox/tree/master/boost_interprocess_vector_broken
(CPP file attached)",peter.durrant@…
10627,Regression in xmldoc/ex_month_add.xml,date_time,Boost 1.56.0,To Be Determined,Bugs,az_sw_dude,new,2014-10-07T09:19:00Z,2014-10-07T09:19:00Z,"xmldoc/ex_month_add.xml example is incomplete.

{{{
error: 'add_month' was not declared in this scope
   add_month mf(1);
   ^
}}}

I think that this regression due to accidental removal of
{{{
    typedef boost::date_time::month_functor<date> add_month;
}}}
in this [29259] changeset",Nikita Kniazev <nok.raven@…>
10624,win_object_handle_service race condition on destroy,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-07T04:38:51Z,2014-10-07T04:38:51Z,"I caught a random crash in our code base that appears to be due to a race condition in win_object_handle_service. Reproduction steps are essentially just:

boost::asio::windows::object_handle* handle = new boost::asio::windows::object_handle(service, hEvent);[[BR]]
handle->async_wait(...);[[BR]]
SetEvent(hEvent);[[BR]]
delete handle;

The race condition occurs in win_object_handle_service::wait_callback. The last few lines of code in this method are:

    lock.unlock();[[BR]]
    impl->owner_->io_service_.post_deferred_completions(completed_ops);

The problem is that while the delete of the handle waits on the same lock as the wait_callback, the call into impl->owner_->io_service_ happens outside the scope of that lock.
Hence there is a race condition that can trigger under multi-threaded/heavy load scenarios where the delete may execute before the call to >io_service_.post_deferred_completions happens

    lock.unlock();[[BR]]
    <----- delete executes here[[BR]]
    impl->owner_->io_service_.post_deferred_completions(completed_ops);

This leaves impl->owner_ pointing at deleted/unintialized memory, and hence the post_deferred_completions call randomly crashes. I can repro this 100% of the time by just adding a Sleep to emulate load:

   lock.unlock();[[BR]]
   Sleep(1000);[[BR]]
   impl->owner_->io_service_.post_deferred_completions(completed_ops);",Rowan Wyborn <rwyborn@…>
10616,tagged_ptr assumes zero leading bits,lockfree,Boost 1.54.0,To Be Determined,Bugs,timblechmann,new,2014-10-05T16:32:01Z,2016-12-11T11:35:51Z,"I've noticed that boost::lockfree::queue does not work on the OSv operating system, crashing when used.

After some investigation, I discovered the problem: lockfree::queue uses tagged_ptr, and that, when compiled on x86_64, uses tagged_ptr_ptrcompression which assumes that pointers always start with 16 zero bits.

The thing is - the x86_64 standard does *not* guarantee that pointers must start with all zero bits. It just guarantees that pointers are so-called ""canonical"", meaning that the first 16 (usually) bits are either all 0, or all 1. But they *can* be all 1-s, and indeed in OSv, malloc()ed memory has addresses starting with all 1s. By the way, in Linux, kernel-space memory (as opposed to user-space memory) also has such addresses.

But tagged_ptr::extract_ptr() assumes that the leading bits of pointers are always zero - which happens to be true on Linux's user-space memory but is not generally guaranteed by x86_64 (and isn't true on OSv).

I'm not sure what to suggest as a fix. One not-really-safe-but-will-probably-work-in-practice option is to choose to fill the pointer with 0 or 1 bits depending on the 47th bit. Another not-quite-foolproof option is to assume that in one program all pointers will start with the same prefix (all 0 or all 1), so calculate this prefix once at runtime and then use it every time.",nyh@…
10610,Add unwrap shared_future constructor,thread,Boost 1.57.0,To Be Determined,Feature Requests,viboes,assigned,2014-10-05T10:17:57Z,2014-10-05T10:21:25Z,"Following N4123, add unwrap shared_future constructor

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

{{{


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

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

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

Postconditions:

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


}}}
",viboes
10606,kqueue broken on FreeBSD,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-05T03:38:55Z,2014-10-05T03:42:51Z,"This ASIO commit 660e9fe30204e0ada0d1fd40c48015810d2647dc broke things pretty badly on FreeBSD. The ""server3"" example, for instance, doesn't ever correctly accept and handle a new connection.",elan@…
10593,boost::locale::generator::generate throws unhelpful error if iconv doesn't support UTF-16,locale,Boost 1.56.0,To Be Determined,Bugs,Artyom Beilis,new,2014-10-04T01:53:09Z,2014-10-04T01:53:09Z,"This actually happens on some older libc's. You end up with an exception complaining about iconv not supporting ANSI_X3.4-1968, when in fact the issue is a lack of support for UTF-16, which should be either ignorable or reported more accurately. Gah, I'm too tired to explain the issue in more detail right now; poke me and I'll expand later if necessary.",Rodger Combs <rodger.combs@…>
10591,boost::filesystem does not build on iOS 8,filesystem,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,reopened,2014-10-04T00:14:33Z,2017-01-27T18:09:40Z,boost::filesystem::detail::operations relies on AT_SYMLINK_NOFOLLOW macro to decide whenever to use fchmodat function or not. Since iOS8 AT_SYMLINK_NOFOLLOW is defined on iOS but fchmodat still not available which breaks this logic and lead to compilation error.,anonymous
10581,Conflict when using boost::interprocess  objects when linking to 2 different boost versions,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-10-02T07:27:54Z,2014-10-24T08:33:57Z,"'''Introduction''':
Boost interprocess directory and file naming has changed after boost 1.54.
Intreprocess communication does not work between version greater than 1.54 and lower than 1.54.
Related bug report: https://svn.boost.org/trac/boost/ticket/9767

'''The Scenario''':
Compile a .dll that uses some shared memory object from the boost::interprocess library with version 1.55. (Think of this as an external 3rd party dll which you have no control over).
Then make another project, using an older version of boost, lets say boost 1.51.
In the new project, open a shared memory object, then call a function from the dll that also opens a shared memory object.
This should have opened 2 shared memory objects, one with the 1.55 version and one with the 1.51 version.

The problem is that the second memory object will always fail (even if you change the order).

'''The Problem''':
Boost uses a singleton object to map the open interprocess memory objects.
Because of the versions mismatch, the first shared memory object that is created, also creates the map (And with it the file naming convention).

'''Solution''':
The singleton '''should''' just map the items, but use the functions according to the calling binary and compiled version of the caller.

'''Workaround''':
I've just changed the names in the singleton object.  
I figured you can't have redundancy if it's incompatible, so lets have a separate memory mapping.
In windows_intermodule_singleton.hpp changing the windows_semaphore_based_map named objects for the 1.55 version will keep the map separated.",Yochai Timmer
10577,‘num_synchronizations’ declared in scope,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-10-02T02:01:48Z,2014-10-12T13:53:53Z,"In 1_54_0/boost/graph/distributed/detail/queue.ipp there is the following:

template<BOOST_DISTRIBUTED_QUEUE_PARMS>
bool
BOOST_DISTRIBUTED_QUEUE_TYPE::do_synchronize() const
{
#ifdef PBGL_ACCOUNTING
  ++num_synchronizations;
#endif

....

}

While editing a PBGL example to use Eager Dijkstra over Delta-Stepping, the following error was produced during compilation:

In file included from /boost_1_54_0/boost/graph/distributed/queue.hpp:273:0,
                 from /boost_1_54_0/boost/graph/distributed/breadth_first_search.hpp:20,
                 from /boost_1_54_0/boost/graph/breadth_first_search.hpp:404,
                 from /boost_1_54_0/boost/graph/dijkstra_shortest_paths.hpp:21,
                 from /parallel-bgl-0.7.0/libs/graph_parallel/test/distributed_shortest_paths_test.cpp:15:
/boost_1_54_0/boost/graph/distributed/detail/queue.ipp: In member function ‘virtual bool boost::graph::distributed::distributed_queue<ProcessGroup, OwnerMap, Buffer, UnaryPredicate>::do_synchronize() const’:
/boost_1_54_0/boost/graph/distributed/detail/queue.ipp:143:5: error: ‘num_synchronizations’ was not declared in this scope
   ++num_synchronizations;

I couldn't locate num_synchronizations anywhere.  I could undefine PBGL_ACCOUNTING or just comment out the num_sync increment field.

I don't see this as having been fixed/removed in any other boost versions (checked 1_56_0).  Not a serious problem clearly unless accurate accounting is wanted.
",M. Harper Langston <harperlangston@…>
10572,Error: get_descriptors is not a member of boost::asio::detail::reactor_op_queue<int>.,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-01T23:25:29Z,2014-10-01T23:25:29Z,"Problem:
asio tests(for example basic_datagram_socket test) failed with error message 
"".../boost/boost_1_56_0/boost/asio/detail/impl/dev_poll_reactor.ipp"", line 116: Error: get_descriptors is not a member of boost::asio::detail::reactor_op_queue<int>."" with studio 12.4 c++ on sparc/solaris 11.2

and 
../boost/asio/detail/impl/dev_poll_reactor.ipp:116:24: error: 'class boost::asio::detail::reactor_op_queue<int>' has no member named 'get_descriptors' with g++4.8.2 on sparc/solaris 11.2.

",anonymous
10571,type_index tests configuration issues for Oracle Studio c++,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-10-01T22:07:51Z,2014-10-01T22:07:51Z,"Problems:
1.type_index library tests failed to compile with error message
""../../../boost/type_index/stl_type_index.hpp"", line 165: Error: abi is not defined."" with studio 12.4 (c++) on Solaris 11.2.

2.nortti test flags are incorrect for studio c++.  

Solution for problem 1:
in boost/type_index/stl_type_index.hpp
42:#ifdef __GNUC__
43 #   include <cxxabi.h>                              // abi::__cxa_demangle
44 #endif

replace line 42 with
#if defined __GNUC__ || (defined(__SUNPRO_CC) && __SUNPRO_CC_COMPAT!=5) 


154:#if defined(_MSC_VER)
155:  std::string ret = data_->name();
156:  std::string::size_type pos_beg = ret.find(cvr_saver_name);
157:  if (pos_beg == std::string::npos) {
158:       return ret;
159:    }

replace line 154 with
#if defined(_MSC_VER) || (defined(__SUNPRO_CC) && (__SUNPRO_CC_COMPAT==5)) 

in boost/type_index/detail/compile_time_type_info.hpp
120:    #elif defined(__PRETTY_FUNCTION__) \
121:               || defined(__GNUC__) \
122:               || (defined(__MWERKS__) && (__MWERKS__ >= 0x3000)) \
123:                || (defined(__ICC) && (__ICC >= 600)) \
124:               || defined(__ghs__) \
125:                || defined(__DMC__)

insert ""|| defined(__SUNPRO_CC) \"" into between line 121, 122
                || defined(__GNUC__) \
                || defined(__SUNPRO_CC) \
                || (defined(__MWERKS__) && (__MWERKS__ >= 0x3000)) \


solution for problem 2:
add -features=no%rtti for nortti test",angela.xie@…
10568,It would be better to improve naming mechanism of the latest log file,log,Boost 1.55.0,To Be Determined,Support Requests,Andrey Semashev,new,2014-09-30T12:27:21Z,2014-10-01T06:23:08Z,"Currently if some format is used for log file name, latest log file name is constructed with that format. For example, if we use a format which includes date and sequential number in the log file name, such log files are being generated:

file_2014-09-26_00.log
file_2014-09-26_01.log
file_2014-09-26_02.log  (this is the latest log file)

It would be better to have such log files:

file_2014-09-26_00.log
file_2014-09-26_01.log
file.log 		(this is the latest log file always)

In this case, it would be easier to determine latest log file.",anih@…
10567,<boost/asio/spawn.hpp> is not inside <boost/asio.hpp>,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-30T08:19:55Z,2014-09-30T08:19:55Z,"According to the document, include <boost/asio.hpp> should implicitly include <boost/asio/spawn.hpp>, but actually it is missing in asio.hpp and has to be included explicitly. I am not sure whether this is intended or not. If it is intended, then the document needs to be updated.",rivercheng@…
10564,iostreams with custom character class,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-09-29T18:52:57Z,2014-09-29T18:52:57Z,"I am trying to use iostreams with custom character class with its own traits.

Exactly:
std::basic_istream<Character, CharacterTraits>
boost::iostreams::filtering_stream<boost::iostreams::input_seekable, Character, CharacterTraits>

This gives me bunch of errors cannot assign std::char_traits<Character> to CharacterTraits.

I have figured out a few places, where the traits does not propagate correctly.

I have attached patch files, for places, where I believe, character trait propagation is missing.",jur.zikmund@…
10561,Bugs in dual seekable mode,iostreams,Boost 1.56.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-09-29T14:16:45Z,2014-10-06T13:16:25Z,"Currently there are no tests for dual seekable streams. So the first thing to do is to add some tests. See dual_seekable_test.cpp attached.
These tests uncover the following bugs:
1. The functions test_seekable_in_chars and test_seekable_in_chunks in test/detail/verification.hpp use seekp in several places where seekg should be used. This has no effect when there is a single head but does not work when the stream is dual seekable. A new verification function test_dual_seekable was  added and tested. See attached verification.hpp.
2. indirect_streambuf::seek_impl does not work for dual seeking. The problem is that both heads are modified for both input and output operations. Since the modification is the same (just resetting the pointers) everything works when there is a single head. This is a duplicate of https://svn.boost.org/trac/boost/ticket/7681. Solved in the attached indirect_streambuf.hpp
3. The function shared_buffer() does not consider dual_seekable stream buffers as shared. Solved in the attached indirect_streambuf.hpp
4. The function init_put_area() does not consider the existing input position. This is a duplicate of https://svn.boost.org/trac/boost/ticket/8572. Solved in the attached indirect_streambuf.hpp
With the attached versions of verification.hpp and indirect_streambuf.hpp all previously existing tests passed. I recommend adding the new tests in dual_seekable_test.cpp.
",jlodos@…
10560,[documentation] wrong path mentioned in getting started guide,Getting Started Guide,Boost 1.56.0,To Be Determined,Bugs,Dave Abrahams,new,2014-09-29T14:04:09Z,2014-09-29T14:04:09Z,"In http://www.boost.org/doc/libs/1_56_0/more/getting_started/unix-variants.html#install-boost-build , it says ""Go to the directory tools/build/v2/""

But, there exists no ""v2"" directory inside the ""build"" directory.

Kindly fix that.",Siddhant Saraf <siddhantsaraf@…>
10559,"1_56 tar file has directories with wrong permissions, will not install",Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2014-09-28T19:09:51Z,2014-09-28T19:09:51Z,"Many of the untarred directories in the tar file have the incorrect following permissions:
drwx------

where group and other permissions are absent, please fix with a recursive chmod to all found directories (find -type d -exec chmod -R a+rx {} \;) to have group and other permissions resulting in the following ls -l 
drwxr-xr-x

Without that, boost will not install and has many permissions errors.
Thanks.",geoffwattles@…
10551,Make futures returned by then()/when_all/when_any don't block.,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-09-27T16:25:20Z,2014-09-27T16:26:27Z,"

Follows the Fundamental TS wording for ::then()/ when_all/when_any functions.
",viboes
10550,Implicit unwrapping from then() calls,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-09-27T16:00:45Z,2014-09-28T22:41:28Z,Follows the Fundamental TS wording for ::then() function.,viboes
10548,Spirit.Lex does not support scoped enum,spirit,Boost 1.55.0,To Be Determined,Feature Requests,Hartmut Kaiser,new,2014-09-27T01:55:54Z,2014-09-27T02:20:38Z,"Currently the class boost::spirit::lex::lexer store the variable next_token_id as a std::size_t, but the scoped enumeration types (c++11) are not implicitly convertible  to integral types. This generetas a lot of errors, I have not a deep knowledge of Spirit.Lex source code, but probably it is necessary to change the code not only in the lexer class, but also in other points. Sorry, but I am not able to patch the code.
I attach a very simple example which shows this issue.",mattia.penati@…
10547,[boost/date_time/gregorian/gregorian.hpp] Purify detected UMRs,date_time,Boost 1.56.0,To Be Determined,Bugs,az_sw_dude,new,2014-09-26T20:15:49Z,2014-09-26T20:15:49Z,"Hello,

We ran Purify on one of the boost tests:
boost_1_56_0/libs/date_time/test/gregorian/testgreg_durations.cpp .

The test succeded, but there were UMRs (Uninitialized memory reads)detected in 

short boost::date_time::wrapping_int2<short, 1, 12 >::add<short>(short) [... /boost_1_56_0/boost/date_time/wrapping_int.hpp:124]

and in 

boost::date_time::month_functor<boost::gregorian::date>::get_offset(boost::gregorian::date const&) const [.../boost_1_56_0/boost/date_time/adjust_functors.hpp:91]

The compiler was gcc version 4.1.0 for Linux

",Yevgeny Kalinsky <yevgeny_kalinsky@…>
10543,circular_buffer::rotate() incorrectly assumes that circular_buffer::pointer is a simple pointer type,circular_buffer,Boost 1.56.0,To Be Determined,Bugs,Jan Gaspar,new,2014-09-26T11:36:48Z,2015-12-11T13:28:07Z,"Dear maintainer,

I am trying to use a boost::circular_buffer inside a shared memory segment, along with Boost.Interprocess. This implies that the type of the stored pointer is an offset_ptr<T>, and not just a T *.

In circular_buffer/base.hpp, the rotate method uses a const_cast from the member of a const iterator, assuming that ""pointer"" is indeed a simple pointer type. This however fails when it is instead a structure, such as boost::interprocess::offset_ptr<T>.

The patch I am attaching below solves the issue for me, by allowing the right template specialization to kick in. I did not test it with different pointer types as I am a bit short on time, but by reading the code alone, it should work also with plain pointers.",Matteo Settenvini <matteo.settenvini@…>
10540,missing std::nullptr_t support in boost/type_traits/is_pointer.hpp,ptr_container,Boost 1.56.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-09-25T13:50:55Z,2014-09-25T16:21:15Z,"...leads to a failures when inserting a nullptr into a boost::ptr_vector:

{{{
$ cat test.cc
#include ""boost/ptr_container/nullable.hpp""
#include ""boost/ptr_container/ptr_vector.hpp""
void f(boost::ptr_vector<boost::nullable<int>> & v) {
    v.insert(v.begin(), nullptr);
}

$ g++ -std=c++11 -c test.cc
In file included from .../boost_1_56_0/boost/ptr_container/nullable.hpp:21:0,
                 from test.cc:1:
.../boost_1_56_0/boost/mpl/eval_if.hpp: In instantiation of ‘struct boost::mpl::eval_if_c<true, boost::range_const_iterator<std::nullptr_t, void>, boost::range_mutable_iterator<std::nullptr_t, void> >’:
.../boost_1_56_0/boost/range/iterator.hpp:69:17:   required from ‘struct boost::range_iterator<std::nullptr_t, void>’
.../boost_1_56_0/boost/range/begin.hpp:106:61:   required by substitution of ‘template<class T> typename boost::range_iterator<const T>::type boost::range_adl_barrier::begin(const T&) [with T = std::nullptr_t]’
.../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:43:   required from ‘typename boost::disable_if<boost::ptr_container_detail::is_pointer_or_integral<Range> >::type boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::insert(boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::iterator, const Range&) [with Range = std::nullptr_t; T = boost::nullable<int>; VoidPtrSeq = std::vector<void*, std::allocator<void*> >; CloneAllocator = boost::heap_clone_allocator; typename boost::disable_if<boost::ptr_container_detail::is_pointer_or_integral<Range> >::type = void; boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::iterator = boost::void_ptr_iterator<__gnu_cxx::__normal_iterator<void**, std::vector<void*, std::allocator<void*> > >, int>]’
test.cc:4:32:   required from here
.../boost_1_56_0/boost/mpl/eval_if.hpp:60:31: error: no type named ‘type’ in ‘boost::mpl::eval_if_c<true, boost::range_const_iterator<std::nullptr_t, void>, boost::range_mutable_iterator<std::nullptr_t, void> >::f_ {aka struct boost::range_const_iterator<std::nullptr_t, void>}’
     typedef typename f_::type type;
                               ^
In file included from .../boost_1_56_0/boost/ptr_container/ptr_vector.hpp:20:0,
                 from test.cc:2:
.../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp: In instantiation of ‘typename boost::disable_if<boost::ptr_container_detail::is_pointer_or_integral<Range> >::type boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::insert(boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::iterator, const Range&) [with Range = std::nullptr_t; T = boost::nullable<int>; VoidPtrSeq = std::vector<void*, std::allocator<void*> >; CloneAllocator = boost::heap_clone_allocator; typename boost::disable_if<boost::ptr_container_detail::is_pointer_or_integral<Range> >::type = void; boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::iterator = boost::void_ptr_iterator<__gnu_cxx::__normal_iterator<void**, std::vector<void*, std::allocator<void*> > >, int>]’:
test.cc:4:32:   required from here
.../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:43: error: no matching function for call to ‘begin(std::nullptr_t&)’
             insert( before, boost::begin(r), boost::end(r) );
                                           ^
.../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:43: note: candidates are:
In file included from .../boost_1_56_0/boost/range/functions.hpp:18:0,
                 from .../boost_1_56_0/boost/ptr_container/detail/reversible_ptr_container.hpp:29,
                 from .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:20,
                 from .../boost_1_56_0/boost/ptr_container/ptr_vector.hpp:20,
                 from test.cc:2:
.../boost_1_56_0/boost/range/begin.hpp:97:55: note: template<class T> typename boost::range_iterator<C>::type boost::range_adl_barrier::begin(T&)
 inline BOOST_DEDUCED_TYPENAME range_iterator<T>::type begin( T& r )
                                                       ^
.../boost_1_56_0/boost/range/begin.hpp:97:55: note:   template argument deduction/substitution failed:
.../boost_1_56_0/boost/range/begin.hpp:106:61: note: template<class T> typename boost::range_iterator<const T>::type boost::range_adl_barrier::begin(const T&)
 inline BOOST_DEDUCED_TYPENAME range_iterator<const T>::type begin( const T& r )
                                                             ^
.../boost_1_56_0/boost/range/begin.hpp:106:61: note:   substitution of deduced template arguments resulted in errors seen above
In file included from .../boost_1_56_0/boost/ptr_container/ptr_vector.hpp:20:0,
                 from test.cc:2:
.../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:58: error: no matching function for call to ‘end(std::nullptr_t&)’
             insert( before, boost::begin(r), boost::end(r) );
                                                          ^
.../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:421:58: note: candidates are:
In file included from .../boost_1_56_0/boost/range/functions.hpp:19:0,
                 from .../boost_1_56_0/boost/ptr_container/detail/reversible_ptr_container.hpp:29,
                 from .../boost_1_56_0/boost/ptr_container/ptr_sequence_adapter.hpp:20,
                 from .../boost_1_56_0/boost/ptr_container/ptr_vector.hpp:20,
                 from test.cc:2:
.../boost_1_56_0/boost/range/end.hpp:91:55: note: template<class T> typename boost::range_iterator<C>::type boost::range_adl_barrier::end(T&)
 inline BOOST_DEDUCED_TYPENAME range_iterator<T>::type end( T& r )
                                                       ^
.../boost_1_56_0/boost/range/end.hpp:91:55: note:   template argument deduction/substitution failed:
.../boost_1_56_0/boost/range/end.hpp:100:61: note: template<class T> typename boost::range_iterator<const T>::type boost::range_adl_barrier::end(const T&)
 inline BOOST_DEDUCED_TYPENAME range_iterator<const T>::type end( const T& r )
                                                             ^
.../boost_1_56_0/boost/range/end.hpp:100:61: note:   template argument deduction/substitution failed:
}}}

What would fix this is:

{{{
--- boost/type_traits/is_pointer.hpp	2014-07-09 20:04:22.000000000 +0200
+++ boost/type_traits/is_pointer.hpp	2014-09-25 15:37:45.895757102 +0200
@@ -72,6 +72,10 @@
 
 BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_pointer,T,::boost::detail::is_pointer_impl<T>::value)
 
+#if !defined( BOOST_NO_CXX11_NULLPTR )
+BOOST_TT_AUX_BOOL_TRAIT_SPEC1(is_pointer,::std::nullptr_t,true)
+#endif
+
 #if defined(__BORLANDC__) && !defined(__COMO__) && (__BORLANDC__ < 0x600)
 BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_pointer,T&,false)
 BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC1_1(typename T,is_pointer,T& const,false)
}}}",Stephan Bergmann <sbergman@…>
10539,Type error in detail::socket_ops::host_to_network_short,asio,Boost Release Branch,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-25T13:43:21Z,2014-09-25T13:43:21Z,"Type of '''result''' local variable should be '''u_short_type'''.  Causes compilation warning C4244 with MSVC ( ""possible loss of data"" ).

{{{
u_short_type host_to_network_short(u_short_type value)
{
#if defined(BOOST_ASIO_WINDOWS_RUNTIME)
  u_long_type result;
  unsigned char* result_p = reinterpret_cast<unsigned char*>(&result);
  result_p[0] = static_cast<unsigned char>((value >> 8) & 0xFF);
  result_p[1] = static_cast<unsigned char>(value & 0xFF);
  return result;
#else // defined(BOOST_ASIO_WINDOWS_RUNTIME)
  return htons(value);
#endif // defined(BOOST_ASIO_WINDOWS_RUNTIME)
}
}}}


",Louis-Michel Veilleux <louismichel.veilleux@…>
10534,'WSASocketA': Use WSASocketW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-24T09:34:38Z,2018-05-09T08:27:22Z,"With msvc-12.0 toolset (VS2013 Update 3):

boost_1_56_0\boost/asio/detail/impl/socket_ops.ipp(1363):
warning C4996: 'WSASocketA': Use WSASocketW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings

which leads to build failure if 'treat warnings as errors' option is on.",Valentin Shtronda <valiko.ua@…>
10515,Range: doc: incorrect return type,range,Boost 1.56.0,Boost 1.58.0,Bugs,Neil Groves,assigned,2014-09-18T07:51:57Z,2015-02-02T01:22:17Z,"This page:
http://www.boost.org/doc/libs/1_56_0/libs/range/doc/html/range/reference/adaptors/reference/filtered.html

reads:

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

But the code shows that it has two template parameters.

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

Maybe other similar pages lack parameters, I don't know, but they all seem to have a single one documented.",akim demaille <akim@…>
10514,Cannot copy const sub_range to non-const,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,new,2014-09-18T04:25:48Z,2015-02-02T20:28:45Z,"The following code does not compile with Visual Studio 2013 using Boost 1.56.0:
{{{
#!c++
typedef std::vector<int> vec_t;
typedef boost::sub_range<vec_t> range_t;
vec_t vec(10);
range_t r(vec.begin(), vec.end());
const range_t & r_ref = r;
range_t v = r_ref;
}}}
The following error results:
{{{
boost/range/iterator_range_core.hpp(69) : error C2440: 'static_cast' : cannot convert from 'std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<int>>>' to 'std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>'
        No constructor could take the source type, or constructor overload resolution was ambiguous
        c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(184) : see reference to function template instantiation 'IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_begin<const boost::range_detail::sub_range_base<ForwardRange,boost::random_access_traversal_tag>>(const boost::range_detail::sub_range_base<ForwardRange,boost::random_access_traversal_tag> &)' being compiled
        with
        [
            IteratorT=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>
,            ForwardRange=vec_t
        ]
        c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(187) : see reference to function template instantiation 'IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_begin<const boost::range_detail::sub_range_base<ForwardRange,boost::random_access_traversal_tag>>(const boost::range_detail::sub_range_base<ForwardRange,boost::random_access_traversal_tag> &)' being compiled
        with
        [
            IteratorT=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>
,            ForwardRange=vec_t
        ]
        c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(184) : while compiling class template member function 'boost::sub_range<vec_t>::sub_range(const boost::sub_range<vec_t> &)'
        sub_range_test.cpp(11) : see reference to function template instantiation 'boost::sub_range<vec_t>::sub_range(const boost::sub_range<vec_t> &)' being compiled
        sub_range_test.cpp(9) : see reference to class template instantiation 'boost::sub_range<vec_t>' being compiled
boost/range/iterator_range_core.hpp(75) : error C2440: 'static_cast' : cannot convert from 'std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<int>>>' to 'std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>'
        No constructor could take the source type, or constructor overload resolution was ambiguous
        c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(186) : see reference to function template instantiation 'IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_end<const boost::range_detail::sub_range_base<ForwardRange,boost::random_access_traversal_tag>>(const boost::range_detail::sub_range_base<ForwardRange,boost::random_access_traversal_tag> &)' being compiled
        with
        [
            IteratorT=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>
,            ForwardRange=vec_t
        ]
        c:\build\ng-10.5-x64\API\inc\boost/range/sub_range.hpp(187) : see reference to function template instantiation 'IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_end<const boost::range_detail::sub_range_base<ForwardRange,boost::random_access_traversal_tag>>(const boost::range_detail::sub_range_base<ForwardRange,boost::random_access_traversal_tag> &)' being compiled
        with
        [
            IteratorT=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>
,            ForwardRange=vec_t
        ]
}}}
So it looks as though having a `const` `sub_range` implies that it uses `const_iterator`s, which doesn't seem appropriate.

Code of this nature compiled using Boost 1.55.0.
",Braden McDaniel <braden@…>
10513,Use operator | and |= for set addition if  | and |= are called,ICL,Boost 1.55.0,To Be Determined,Patches,Joachim Faulhaber,new,2014-09-17T23:33:25Z,2014-09-17T23:33:25Z,"As mentioned in the document (http://www.boost.org/doc/libs/1_56_0/libs/icl/doc/html/boost_icl/function_reference/addition.html), a set union semantics is often attached operators |= and |. This is the case, for example, when using boost::dynamic_bitset, which does not provide operators += and + for set union semantics. 

However, the original implementation of operators |= and | still uses += and + for the underlying set container. This makes operators |= and | less useful. Furthermore, we can't use boost::dynamic_bitset for icl objects currently. I think this is an unnecessary limitation.

To make the code more consistent with the statement above, a proper fix would be changing += and + into |= and | when users call the |= and | operators. 

The patch is on: https://github.com/boostorg/icl/pull/4",clan@…
10508,"Hang occurs if tcp::socket.connect(endpt, errorcode) is called with reserved IP address",asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-16T16:16:59Z,2014-09-16T16:40:59Z,"boost::asio::ip::tcp::socket.connect( EndPt, ec) hangs in detail/impl/socket_opps.ipp:472 on the call

template <typename SockLenType>
inline int call_connect(SockLenType msghdr::*,
    socket_type s, const socket_addr_type* addr, std::size_t addrlen)
{
  return ::connect(s, addr, (SockLenType)addrlen);  <== HANGS
}

if the IP address is Valid but reserved.  127.0.0.1 & any established private network subnet address work fine with either a connection or an errorcode return specifying the connection was refused.

",Ron Hansen <thak@…>
10507,Tools: Wave missing,wave,Boost 1.56.0,To Be Determined,Bugs,Hartmut Kaiser,new,2014-09-15T16:48:17Z,2015-07-29T18:20:38Z,"The documentation states that the Wave tool is distributed with boost but as of version 1.56 there is no tools/wave directory (referenced in Jamfile.v2) so that running the build tool in the tools/ directory fails:

(from the tools directory)


{{{
b2 --user-config=/var/tmp/portage/dev-libs/boost-1.56.0/work/boost_1_56_0-abi_x86_64.amd64/user-config.jam gentoorelease -j4 -q -d+2 -sICU_PATH=/usr --without-mpi --without-context --without-coroutine pch=off --boost-build=/usr/share/boost-build --prefix=""/var/tmp/portage/dev-libs/boost-1.56.0/image/usr"" --layout=system threading=multi link=shared
Performing configuration checks

    - has_icu builds           : yes (cached)
error: Unable to find file or target named
error:     'wave/build//wave'
error: referred to from project at
error:     '../tools'
error: could not resolve project reference 'wave/build'
}}}

",tiagogehring@…
10505,Use gcc/clang built-in endianity macros (too),predef USE GITHUB,Boost 1.56.0,To Be Determined,Bugs,René Rivera,reopened,2014-09-15T10:11:45Z,2017-10-04T03:35:24Z,"Endian detection in `boost/predef/other/endian.h` does consider the gcc/clang built-in `__BYTE_ORDER__` macros and consequently fails to detect endianity of some (usually mobile) platforms.

E.g. on Android I get `_BYTE_ORDER` defined to `_LITTLE_ENDIAN`, but `_LITTLE_ENDIAN` is '''not''' defined, leading to all three conditions (`_BYTE_ORDER == _BIG_ENDIAN`, `_BYTE_ORDER == _LITTLE_ENDIAN` and `_BYTE_ORDER == _PDP_ENDIAN` being satisfied and yielding conflicting definitions.

The `__BYTE_ORDER__` is provided by gcc and clang compilers themselves and therefore should always be there no matter how broken the rest of standard library is. What I am not sure is whether they should be used in preference to any other method or as a fallback (in which case definedness of the `_BIG_ENDIAN`, `_LITTLE_ENDIAN` etc. macros also has to be tested before trying to use them)",Jan Hudec <bulb@…>
10497,Cannot assign filter_range to any_range (gcc only),range,Boost 1.54.0,To Be Determined,Bugs,Neil Groves,new,2014-09-12T11:51:56Z,2015-02-02T01:41:12Z,"When trying to assign a filter_range to a suitable any_range, the attached source code fails to compile under g++ (v4.8.3), but does compile under clang++ (v3.4).

From the error messages I get, it seems that the error triggers when trying to use the default constructor of filter_range with Predicate = lambda and an Iterator = non-default-constructible iterator.",Alex Puchades <alex94puchades+dev@…>
10496,100% cpu usage when reading serial port on MacOSX,asio,Boost 1.58.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-11T21:32:48Z,2018-04-07T14:36:50Z,"Simple test program is attached.  All it does is setup a serial port and start waiting for data.  It prints the first data it receives, and quits.  It is using 100% cpu (according to activity monitor).

I've tried with the following serial ports: silab usb adapter, prolific usb adapter, and pty with master attached to socat.

The profiler puts most of the time in ```kevent``` called from ```boost::asio::detail::kqueue_reactor::run(bool, boost::asio::detail::op_queue<boost::asio::detail::task_io_service_operation>&)```",Christopher Moore <crmoore@…>
10493,"Since 1.56, any_range with non-reference references can cause UB",range,Boost 1.62.0,Boost 1.64.0,Bugs,Neil Groves,assigned,2014-09-11T14:04:19Z,2018-03-08T08:44:24Z,"This must be related to #10360. This is a regression since 1.55.

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

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

{{{
#include <boost/range/any_range.hpp>
#include <boost/range/adaptor/transformed.hpp>
#include <cmath>
#include <iostream>

typedef boost::any_range<
    std::string,
    boost::forward_traversal_tag,
    std::string,
    std::ptrdiff_t
> range_t;

std::string f(std::string a)
{
    return a + ""!"";
}

int main()
{
    std::vector<std::string> v = {""a"", ""b""};
    range_t r = v | boost::adaptors::transformed(f);
    for (auto&& a : r)
        std::cout << a << std::endl;
    return 0;
}

}}}
",nofitserov@…
10492,current_function.hpp Should make use of __FUNCTION__ when compiling with Visual Studio,utility,Boost 1.55.0,To Be Determined,Bugs,No-Maintainer,new,2014-09-11T12:33:52Z,2014-10-12T13:55:02Z,"I would like to use {{{current_function.hpp}}} together with Visual Studio 2013 but {{{BOOST_CURRENT_FUNCTION}}} becomes defined as ""(unknown)"".",anonymous
10490,"boost::geometry::difference produces a ""possible loss of data"" warning in MSVC",geometry,Boost 1.56.0,To Be Determined,Bugs,Barend Gehrels,new,2014-09-11T01:24:28Z,2014-09-11T01:24:28Z,"Using the boost::geometry::difference function causes MSVC to emit the warning:

{{{
c:\boost\include\boost-1_56\boost\geometry\algorithms\detail\sections\sectionalize.hpp(612): warning C4244: 'initializing' : conversion from 'double' to 'const coordinate_type', possible loss of data
}}}

(full compiler output is attached)

This is reproducible using the sample from the [http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/geometry/reference/algorithms/difference.html docs].

Versions of boost prior to 1.56 do not exhibit the problem.

This was reproduced using Visual Studio 2010 and 2013.



",anonymous
10485,heap-use-after-free using C++11 range loop,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-09-09T16:14:17Z,2014-10-26T15:35:40Z,"Repro code:

{{{
#include <stdio.h>
#include <boost/filesystem.hpp>

int main() {
    boost::filesystem::path dir(""/"");
    for (char c : dir.filename().string())
        printf(""%c\n"", c);
}
}}}

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

{{{
=================================================================
==12324==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000ef50 at pc 0x48448a bp 0x7fff08f73990 sp 0x7fff08f73988
READ of size 8 at 0x60300000ef50 thread T0
    #0 0x484489 in std::string::size() const /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:716
    #1 0x484489 in ~path /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:636
    #2 0x484489 in main /run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/main.cpp:6
    #3 0x7f0679cd0d64 in __libc_start_main (/lib64/libc.so.6+0x21d64)
    #4 0x483f1c in _start (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x483f1c)

0x60300000ef50 is located 0 bytes inside of 26-byte region [0x60300000ef50,0x60300000ef6a)
freed by thread T0 here:
    #0 0x46e7b9 in operator delete(void*) (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x46e7b9)
    #1 0x4843f2 in std::string::_M_rep() const /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:249
    #2 0x4843f2 in ~basic_string /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:539
    #3 0x4843f2 in ~basic_string /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:539
    #4 0x4843f2 in ~path /usr/include/boost/filesystem/path.hpp:55
    #5 0x4843f2 in main /run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/main.cpp:6
    #6 0x7f0679cd0d64 in __libc_start_main (/lib64/libc.so.6+0x21d64)

previously allocated by thread T0 here:
    #0 0x46e4b9 in operator new(unsigned long) (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x46e4b9)
    #1 0x7f067a3411d8 (/lib64/libstdc++.so.6+0xbe1d8)
    #2 0x9

SUMMARY: AddressSanitizer: heap-use-after-free /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:716 std::string::size() const
Shadow bytes around the buggy address:
  0x0c067fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c067fff9de0: fa fa fa fa fa fa fa fa fa fa[fd]fd fd fd fa fa
  0x0c067fff9df0: 00 00 00 02 fa fa 00 00 00 03 fa fa 00 00 00 02
  0x0c067fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==12324==ABORTING
}}}",iamvfx@…
10483,boost::is_sorted docs incorrectly describe predicate,range,Boost 1.55.0,Boost 1.58.0,Bugs,Neil Groves,assigned,2014-09-09T13:13:34Z,2015-02-02T01:20:47Z,"From the documentation

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

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

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

So the docs should say
 the expression y < x is false

I get the following with g++'s underlying is_sorted():
{{{
  std::vector<int> v{1, 1};
  std::cout << boost::is_sorted(v) << std::endl; // prints 1
}}}

Reference for is_sorted at cplusplus.com [sorry not allowed to post a link] backs this up.",charlie@…
10473,[Trac] Default assignee for GIL tickets,trac / subversion,,To Be Determined,Bugs,Douglas Gregor,new,2014-09-06T13:59:42Z,2014-09-06T13:59:42Z,"I think the default assignee for GIL tickets is Hailin Jin, but maintenance has been handed over to Christian Henning.  ",anonymous
10471,Boost.Geometry fails to compile when OS X AssertMacros.h are included,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-09-06T01:16:16Z,2014-10-14T21:59:51Z,"The infamous AssertMacros.h header (see #2115) defines a macro called ""check"", which causes a compilation failure in <boost/geometry/geometries/concepts/check.hpp>. The header is automatically included by certain Apple frameworks, so it's a bit unavoidable.

Per the resolution to #2115, instances of the word ""check"" should be replaced by something else to avoid this issue. (Damn you, Apple...)

Testcase program:

{{{
#include <AssertMacros.h>
#include <boost/geometry.hpp>
}}}

Compile with ""c++ test.cpp"". Compile errors:

{{{
In file included from test.cpp:2:
In file included from /opt/local/include/boost/geometry.hpp:17:
In file included from /opt/local/include/boost/geometry/geometry.hpp:43:
In file included from /opt/local/include/boost/geometry/strategies/strategies.hpp:31:
In file included from /opt/local/include/boost/geometry/strategies/intersection.hpp:15:
In file included from /opt/local/include/boost/geometry/policies/relate/intersection_points.hpp:19:
In file included from /opt/local/include/boost/geometry/algorithms/detail/assign_indexed_point.hpp:20:
/opt/local/include/boost/geometry/geometries/concepts/check.hpp:217:1: error: 
      expected unqualified-id
{
^
In file included from test.cpp:2:
In file included from /opt/local/include/boost/geometry.hpp:17:
In file included from /opt/local/include/boost/geometry/geometry.hpp:43:
In file included from /opt/local/include/boost/geometry/strategies/strategies.hpp:31:
In file included from /opt/local/include/boost/geometry/strategies/intersection.hpp:15:
In file included from /opt/local/include/boost/geometry/policies/relate/intersection_points.hpp:19:
In file included from /opt/local/include/boost/geometry/algorithms/detail/assign_indexed_point.hpp:21:
In file included from /opt/local/include/boost/geometry/algorithms/detail/assign_values.hpp:29:
/opt/local/include/boost/geometry/algorithms/append.hpp:217:9: error: no
      template named 'check' in namespace 'boost::geometry::concept'; did you
      mean 'dispatch::check'?
        concept::check<Geometry>();
        ^~~~~~~~~~~~~~
        dispatch::check
/opt/local/include/boost/geometry/geometries/concepts/check.hpp:68:8: note: 
      'dispatch::check' declared here
struct check : not_implemented<GeometryTag>
       ^

... more errors about missing concept::check ...
}}}
",Robert Xiao <nneonneo@…>
10462,throw exception inherits two std::exception,exception,Boost 1.56.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-09-04T18:53:33Z,2014-09-10T06:41:28Z,"
{{{
// example
  class my_exception: public std::exception { };
  try  {
     boost::throw_exception(my_exception());   
  } catch(  my_exception & e)
  {...  }

}}}

Inheritance of e

{{{

-> ... clone_impl<boost::exception_detail::error_info_injector<my_exception> >	
-> ->		my_exception
-> ->  ->		std::exception		
...
->		std::exception
}}}",gilles.guerre-chaley@…
10458,boost::parameter::aux::default_: assignment operator could not be generated,parameter,Boost 1.56.0,To Be Determined,Bugs,Daniel Wallin,new,2014-09-04T16:05:49Z,2014-09-04T16:05:49Z,"boost/parameter/aux_/default.hpp: warning C4512:
 'boost::parameter::aux::default_' : assignment operator could not be
 generated

 This is generated with MSVC12 warning level 4. Compiling with treat
 warnings as error is problematic.",r.korthaus@…
10457,'boost::locale::date_time_duration' : assignment operator could not be generated,locale,Boost 1.56.0,To Be Determined,Bugs,Artyom Beilis,new,2014-09-04T16:00:39Z,2014-09-04T16:00:39Z,"boost/locale/date_time.hpp: warning C4512: 'boost::locale::date_time_duration' : assignment operator could not be generated

This is generated with MSVC12 warning level 4. Compiling with treat warnings as error is problematic.

The fix is simple, just add a deleted assignment operator:

{{{
            /// Get ending point
            ///
            date_time const &end() const { return e_; }

#if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1800))
            // prevent warning C4512: assignment operator could not be generated
            BOOST_DELETED_FUNCTION(date_time_duration& operator=(date_time_duration const&))
#endif
        private:
            date_time const &s_;
            date_time const &e_;
}}}",r.korthaus@…
10454,windows_file_codecvt::do_length doesn't use BOOST_CODECVT_DO_LENGTH_CONST,filesystem,Boost 1.63.0,To Be Determined,Bugs,Beman Dawes,new,2014-09-04T10:19:53Z,2017-01-09T16:59:38Z,"In Visual Studio the first parameter of {{{std::codecvt::do_length}}} is defined as a const reference whereas in the derived class {{{windows_file_codecvt}}} the first parameter of {{{do_length}}} it is defined as non-const reference. This leads to improper overloading of the method.

See also: #10354",m.kosch@…
10452,std::vector does not work with rolling_mean,accumulator,Boost 1.54.0,To Be Determined,Bugs,Eric Niebler,new,2014-09-03T18:57:30Z,2014-09-03T18:57:30Z,"See https://stackoverflow.com/questions/25641378/boostaccumulator-stdvector-does-not-work-with-rolling-mean
",Eric Niebler
10450,Undefined behavior in boost::filesystem::detail::directory_iterator_construct,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,new,2014-09-03T14:16:11Z,2018-04-05T21:10:19Z,"boost/libs/filesystem/src/operations.cpp:2178:28: runtime error: reference binding to null pointer of type 'struct error_code'

The problem is this line: it.increment(*ec);

ec is 0 when directory_iterator_construct is called from operations.hpp:793
{{{
explicit directory_iterator(const path& p)
        : m_imp(new detail::dir_itr_imp)
          { detail::directory_iterator_construct(*this, p, 0); }
}}}
{{{
[...undefined behavior sanitiser noise...]
#3  0x00005555566e623c in boost::filesystem::detail::directory_iterator_construct (it=..., p=..., ec=ec@entry=0x0) at functional/boost/libs/filesystem/src/operations.cpp:2178
#4  0x00005555566b3cfe in directory_iterator (p=..., this=0x7fffffffd7e0) at functional/boost/boost/filesystem/operations.hpp:793
#5  recursive_directory_iterator (opt=boost::filesystem::none, dir_path=..., this=0x7fffffffd760) at functional/boost/boost/filesystem/operations.hpp:1037
[...my code...]
}}}",egrindha@…
10449,directed_graph copy constructor,graph,Boost 1.56.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-09-03T13:48:12Z,2016-02-24T10:05:39Z,"The copy constructor of directed_graph is broken. 

This is virtually identical to ticket #4197: 

Steps to reproduce:

#include <boost/graph/directed_graph.hpp>
typedef boost::directed_graph<> Graph; 
Graph g;  
Graph h( g );

",philip.pfaffe@…
10448,MSVC bug with default argument passing - a workaround is required,filesystem,Boost 1.56.0,To Be Determined,Support Requests,Beman Dawes,new,2014-09-03T12:50:26Z,2014-09-10T12:30:30Z,"MSVC 2010-2013 for x64 may pass default values incorrectly.

I met this bug with such innocent code:
{{{
std::wcout << boost::filesystem::path(L""ABC"");
}}}
and got hieroglyphs around ABC instead of quotation marks.

To workaround the bug: just add '''(Char)''' prior to default values in the declaration of boost::io::detail::quote
(boost/io/detail/quoted_manip.hpp)

{{{
    //  manipulator for const std::basic_string&
    template <class Char, class Traits, class Alloc>
      detail::quoted_proxy<std::basic_string<Char, Traits, Alloc> const &, Char>
        quoted(const std::basic_string<Char, Traits, Alloc>& s,
               Char escape=(Char)'\\', Char delim=(Char)'\""');

    //  manipulator for non-const std::basic_string&
    template <class Char, class Traits, class Alloc>
      detail::quoted_proxy<std::basic_string<Char, Traits, Alloc> &, Char>
        quoted(std::basic_string<Char, Traits, Alloc>& s,
               Char escape=(Char)'\\', Char delim=(Char)'\""');

    //  manipulator for const C-string*
    template <class Char>
      detail::quoted_proxy<const Char*, Char>
        quoted(const Char* s, Char escape=(Char)'\\', Char delim=(Char)'\""');

}}}
I did not scan other sources with similar problem; could you please check them yourselves?


P.S. GODDAMN! Your tracker disallows me to tell you the detailed description of the MSVC bug on its tracker. It treats the URL as spam.
Please combine the URL from these pieces:

{{{connect.microsoft.com /VisualStudio /feedbackdetail /view / 962812}}}
",merkin@…
10447,"io_service destructor hangs if serial_port read is queued, even if not running",asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-09-03T12:33:31Z,2016-08-08T23:06:46Z,"The following program does not terminate.

{{{
#include <boost/asio.hpp>

int main() {
    auto* ios = new boost::asio::io_service;
    auto* port = new boost::asio::serial_port(*ios);
    port->open(""COM6"");
    char c;
    boost::asio::async_read(*port, boost::asio::buffer(&c, 1), [](boost::system::error_code, int) {});

    delete ios;
}
}}}

Despite the fact that the io_service is not running, its destructor hangs if there is a pending async_read from a serial_port. If that read completes (by receiving one byte), the program terminates.",Martinho Fernandes <martinho.fernandes@…>
10444,MPI archive failure,mpi,Boost 1.56.0,To Be Determined,Bugs,Matthias Troyer,new,2014-09-02T16:33:09Z,2014-09-02T16:33:09Z,"Loading a serialized archive from MPI results in crashes/asserts.

Compiler: MSVC 11.0 update 4

Platform: Windows, x64

Other notes: BOOST_MPI_HOMOGENEOUS is enabled

When I load a boost::mpi archive (that was either sent over MPI or even packed within the same process), I end up with a crash (assert in debug versions).  I think I've traced the problem to packed_oarchive.hpp.

When saving, the compiler chooses the templated ""save_override"" function for archive::version_type.  When loading, it chooses the specialized ""load_override"" for archive::version_type.  I think this is because of missing ""const"" on the argument ""t"" for the versions of save_override specialized for archive::class_id_type & archive::version_type (since archive::version_type is actually const, the compiler can't use the non-const overload & defaults to the templated function)

The root issue is that it saves 4 bytes for archive::version_type, but loads only 1.  All future operations on the archive are thus mis-aligned (bad sizes are loaded for containers, etc.).  I always use the homogeneous optimization, so I'm not sure if it is limited to this case.

The same application code worked fine in 1.54.0.  The new save_override/load_override functions for archive::version_type & archive::class_id_type were introduced somewhere between 1.54.0 & 1.56.0.  (I did have to manually apply a fix to 1.54.0 for the zero-length loads in binary_buffer_imprimitive.hpp, but that issue has been resolved).",brian.ventre@…
10440,"boyer_moore.hpp fails on Linux w/ gcc-4.7.2, OK with Mac clang",algorithm,Boost 1.56.0,To Be Determined,Bugs,Marshall Clow,new,2014-09-02T03:51:37Z,2014-09-02T14:07:46Z,"I have a simple find-string-in-file program that uses boyer_moore matching.  On Mac, it compiles and works OK.  (Not sure if Mac is really using gcc; that's the command name, but ""gcc -v"" says ""Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)""

At any rate, the same code, with a freshly-compiled Boost-1.56.0 on Debian 7, gcc-4.7.2, fails to compile:

{{{
g++ -g   -I. -I/usr/local/include   -c -o find.o find.cc
In file included from /usr/local/include/boost/range/iterator.hpp:24:0,
                 from /usr/local/include/boost/range/begin.hpp:24,
                 from /usr/local/include/boost/algorithm/searching/boyer_moore.hpp:18,
                 from find.cc:5:
/usr/local/include/boost/mpl/eval_if.hpp: In instantiation of ‘struct boost::mpl::eval_if_c<false, boost::range_const_iterator<const unsigned char*, void>, boost::range_mutable_iterator<const unsigned char*, void> >’:
/usr/local/include/boost/range/iterator.hpp:69:17:   required from ‘struct boost::range_iterator<const unsigned char*, void>’
/usr/local/include/boost/algorithm/searching/boyer_moore.hpp:243:5:   required by substitution of ‘template<class PatternRange, class CorpusRange> typename boost::range_iterator<CorpusRange>::type boost::algorithm::boyer_moore_search(CorpusRange&, const PatternRange&) [with PatternRange = const unsigned char*; CorpusRange = const unsigned char*]’
find.cc:26:106:   required from here
/usr/local/include/boost/mpl/eval_if.hpp:60:31: error: no type named ‘type’ in ‘boost::mpl::eval_if_c<false, boost::range_const_iterator<const unsigned char*, void>, boost::range_mutable_iterator<const unsigned char*, void> >::f_ {aka struct boost::range_mutable_iterator<const unsigned char*, void>}’
make: *** [find.o] Error 1
}}}

(On Mac also, I compiled a fresh copy of Boost-1.56.0 using the native compiler.)
",boost@…
10432,32-bit offset_ptr crashes on 64-bit platform,interprocess,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-08-31T13:13:20Z,2014-09-18T03:12:12Z,"There seem to be problems with handling offset_ptrs with 32-bit offsets on a 64-bit platform. The attached code sample tries to create a file mapping with managed_external_buffer using 32-bit offset_ptrs. The program crashes sometimes when trying to initialize the mapping (see the attached valgrind log for one of such crashes). The offset_ptr is declared as follows:

{{{
typedef boost::interprocess::offset_ptr< void, std::ptrdiff_t, std::int32_t > void_pointer;
}}}

My theory is that there are incorrect offset conversions somewhere in Boost.Interprocess which sometimes result in incorrect pointers and a subsequent crash. This may not happen on every run of the program because the mapping address of the file region can change between runs.

One of the problems with 32-bit offset_ptrs is that its implementation performs implicit casts of the offset to std::size_t (see calls to offset_ptr_to_raw_pointer and offset_ptr_to_offset), which makes incorrect result if the offset type is unsigned and smaller than std::size_t. I didn't find any restrictions on the offset type in the docs or the code, and by default the offset type is unsigned. IMO, the code should be corrected to perform sign extension of the offset or restrict the offset type to be signed integers. This should be documented as well.

However, even if my program uses a signed offset type, it still crashes, so there have to be other issues elsewhere.

I tested this on Kubuntu 14.04 x86_64.
",Andrey Semashev
10430,joined_range generates invalid range with recent gcc versions with optimization enabled,range,Boost 1.55.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-30T19:40:42Z,2014-09-01T11:54:18Z,"This came up in tracking down unit-test failures when trying to build a project with newer compiler versions with C++11 enabled. The unit-test in question was compiled with multiple compiler versions:
* gcc 4.3.4 (without C++11 enabled): working at all optimization levels
* gcc 4.7.2 (with C++11 enabled): works without optimizations, failed with -O1 or higher
* gcc 4.8.4 (with C++11 enabled): works without optimizations, failed with -O1 or higher
* clang 3.5.0 (recent build, with C++11 enabled): works at all optimization levels

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

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

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

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

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

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

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

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

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

I realize this might be a gcc bug, rather than a Boost bug, but I haven't seen this reported elsewhere and would like to get the behaviour tracked since I'm only seeing problems in relation to joined_range...
",Oliver Seiler <oseiler@…>
10424,future/shared_future::then() in case of continuation return an invalid future,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-08-30T08:50:59Z,2014-09-28T22:40:41Z,"Add this behavior to future/shared_future::then()

- In case of implicit unwrapping, the validity of the `future` returned from `then` cannot be established until after the completion of the functor passed into `then`. In such case, the resulting `future` becomes ready with an exception of type `future_error`, with an error code of `future_errc::broken_promise`. ",viboes
10423,Unnecessary configuring of toolsets,build,Boost Release Branch,To Be Determined,Feature Requests,Vladimir Prus,new,2014-08-30T00:59:35Z,2014-08-30T00:59:35Z,"The toolsets in user-config.jam and site-config.jam ( I will call them the 'global config jam files' ) are configured when a ""using xxx ;"" is encountered in these files, each time b2 is invoked. This occurs despite the fact that the toolset with which b2 is invoked may not be a particular toolset which is being configured in the global config jam files .

This is extremely wasteful and unnecessarily time consuming. The global config jam files should be treated differently than the chain of jam files being invoked whenever b2 is run in some directory. Only the toolset(s) in the global config files which are needed for a particular b2 invocation should be configured when encountered there.

It is very possible that the end-user has a 'using xxx ;' statement in one of the global config jam files which will only work when the appropriate toolset is actually being invoked, otherwise will fail. One example of this is if toolset A depends on a particular version of toolset B. If the end-user has switched to a different version of toolset B, and invoked b2 with that different version of toolset B, then b2 at the very least will issue error(s) when toolset A is configured. This is an actual situation in the relationship of clang to gcc, since a clang built with a particular version of gcc will depend on that particular versions headers/RTL.

Forcing the end-user to comment out that toolset configuration statement until it is ready to be actually used would be tedious for the end-user and Boost Build unfriendly.

Please consider changing Boost Build so that toolsets in the global config jam files are not configured until it can be determined that they actually need to be used.",Edward Diener
10422,Counting Iterator return-type causes lifetime issues,iterator,Boost 1.56.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-08-29T17:18:40Z,2014-09-30T15:33:22Z,"The counting_iterator upon integers has a dereference member function which is a reference to an integral value held in the iterator. Since an iterator may be destroyed, the reference can be invalid.

An example where this occurs was provided by a user of Boost.Range. The application used counting_range with reversed and transformed adaptors. The result was garbage since the reversed dereference member function does *boost::prior(this->base()); Hence it returns a reference to a temporary iterator that results from the ""prior"" function.",Neil Groves
10407,MSC Warning disable: Use pop instead push,endian,Boost 1.56.0,Boost 1.57.0,Bugs,Beman Dawes,new,2014-08-27T06:27:03Z,2014-10-16T06:44:51Z,"In file  endian/detail/disable_warnings_pop.hpp:

{{{
#pragma warning(push)
}}}
 should be changed to

{{{
#pragma warning(pop)
}}}

This ""pop"" is related with ""push"" done in ""disable_warnings.hpp""",anonymous
10397,compilation error with mfc-iteratior-support: ambiguous symbol,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-25T08:19:11Z,2014-08-30T14:33:50Z,"Hi,

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

(MSVC 11 on Windows Server 2008 R2/x64)

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

The problem can be resolved by changing the name of

boost::range_detail::range_const_iterator

to

boost::range_detail::range_const_iterator_helper

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

Tobias ",Tobias Loew
10395,boost::prim_minimum_spanning_tree returning incorrect result,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-08-24T19:06:58Z,2014-08-24T19:23:51Z,"
Prim MST is returning incorrect results for the attached graph.

The correct result for this particular graph is 261159288. Boost Kruskal and other third party MST solvers do work.",cristiano.sousa126@…
10393,Add begin/end specialization for optional<T> type,optional,Boost 1.56.0,Boost 1.57.0,Feature Requests,Fernando Cacciola,new,2014-08-22T12:26:04Z,2015-04-13T17:00:38Z,"optional<T> could be used in many places as if it was just T, but, since C++ does not apply two levels of constructions one could not use this natural looking construct for optional containers:

if (opt_container) {
  for (auto& element : opt_container) {
     ...
  }
}

Simple specialization of begin()/end() functions could solve this problem:

namespace std {

template<class T>
inline auto
begin(const boost::optional<T>& opt) -> decltype(opt.get().begin()) {
 return opt.get().begin();
}

template<class T>
inline auto
begin(boost::optional<T>& opt) -> decltype(opt.get().begin()) {
  return opt.get().begin();
}

template<class T>
inline auto
end(const boost::optional<T>& opt) -> decltype(opt.get().end()) {
  return opt.get().end();
}

template<class T>
inline auto
end(boost::optional<T>& opt) -> decltype(opt.get().end()) {
  return opt.get().end();
}

}
",khimru@…
10384,"Building boost 1.48.0 on Solaris with stlport4.6.2, File system is not building",filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2014-08-20T10:50:25Z,2014-08-20T10:50:25Z,"Hi Team,

I am trying to build boost on solaris with STLport-4.6.2. I am able to build few libraries but failed to build filesystem, wave and graph. I am pasting the errors here. Please let me know if there is any work around or patch available for it.


----------------------------
File system Errors
----------------------------
sun.compile.c++ bin.v2/libs/filesystem/build/sun/release/address-model-32/link-static/stdlib-stlport-4.6.2/threading-multi/v3/src/path.o
""./boost/filesystem/v3/path.hpp"", line 161: Error: iterator_traits is not a member of std.
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: While instantiating ""boost::filesystem3::path::path<const char*>(const char*, const char*)"".
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: Instantiated from non-template code.
""./boost/filesystem/v3/path.hpp"", line 161: Error: "","" expected instead of ""<"".
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: While instantiating ""boost::filesystem3::path::path<const char*>(const char*, const char*)"".
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: Instantiated from non-template code.
""./boost/filesystem/v3/path.hpp"", line 161: Error: Illegal value for template parameter.
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: While instantiating ""boost::filesystem3::path::path<const char*>(const char*, const char*)"".
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: Instantiated from non-template code.
""./boost/filesystem/v3/path.hpp"", line 161: Error: Unexpected type name ""std::basic_string<int>::value_type"" encountered.
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: While instantiating ""boost::filesystem3::path::path<const char*>(const char*, const char*)"".
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: Instantiated from non-template code.
""./boost/filesystem/v3/path.hpp"", line 162: Error: The function ""s"" must have a prototype.
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: While instantiating ""boost::filesystem3::path::path<const char*>(const char*, const char*)"".
""libs/filesystem/v3/src/path.cpp"", line 270:     Where: Instantiated from non-template code.
""libs/filesystem/v3/src/path.cpp"", line 797: Error: Could not find a match for std::use_facet<std::Facet>(std::locale) needed in static boost::filesystem3
::path::wchar_t_codecvt_facet().
""libs/filesystem/v3/src/path.cpp"", line 806: Error: Could not find a match for std::use_facet<std::Facet>(std::locale) needed in static boost::filesystem3
::path::imbue(const std::locale&).
7 Error(s) detected.
--------------------------
Wave Errors
--------------------------
...failed sun.compile.c++ bin.v2/libs/wave/build/sun/release/address-model-32/link-static/stdlib-stlport-4.6.2/threading-multi/instantiate_predef_macros.o
...
sun.compile.c++ bin.v2/libs/wave/build/sun/release/address-model-32/link-static/stdlib-stlport-4.6.2/threading-multi/instantiate_re2c_lexer.o
""./boost/wave/util/flex_string.hpp"", line 124: Error: Templates can only declare classes or functions.
""./boost/wave/util/flex_string.hpp"", line 126: Error: "","" expected instead of ""!="".
""./boost/wave/util/flex_string.hpp"", line 126: Error: A declaration was expected instead of ""--"".
""./boost/wave/util/flex_string.hpp"", line 126: Error: Multiple declaration for n.
""./boost/wave/util/flex_string.hpp"", line 126: Error: Use "";"" to terminate declarations.
""./boost/wave/util/flex_string.hpp"", line 126: Error: A declaration was expected instead of ""++"".
""./boost/wave/util/flex_string.hpp"", line 126: Error: Use "";"" to terminate declarations.
""./boost/wave/util/flex_string.hpp"", line 126: Error: A declaration was expected instead of ""++"".
""./boost/wave/util/flex_string.hpp"", line 126: Error: "","" expected instead of "")"".
""./boost/wave/util/flex_string.hpp"", line 130: Error: A declaration was expected instead of ""return"".
""./boost/wave/util/flex_string.hpp"", line 2605: Error: A declaration was expected instead of ""}"".
""./boost/wave/util/flex_string.hpp"", line 2606: Error: A declaration was expected instead of ""}"".
""./boost/wave/token_ids.hpp"", line 359: Error: flex_string is not a member of boost::wave::util.
""./boost/wave/token_ids.hpp"", line 359: Error: A declaration does not specify a tag or an identifier.
""./boost/wave/token_ids.hpp"", line 359: Error: Use "";"" to terminate declarations.
""./boost/wave/token_ids.hpp"", line 359: Error: A declaration was expected instead of ""<"".
""./boost/wave/token_ids.hpp"", line 359: Error: A declaration does not specify a tag or an identifier.
""./boost/wave/token_ids.hpp"", line 359: Error: Use "";"" to terminate declarations.
""./boost/wave/token_ids.hpp"", line 359: Error: A declaration was expected instead of "","".
""./boost/wave/token_ids.hpp"", line 359: Warning: declarator required in declaration.
""./boost/wave/token_ids.hpp"", line 359: Error: Use "";"" to terminate declarations.
""./boost/wave/token_ids.hpp"", line 359: Error: A declaration was expected instead of "","".
""./boost/wave/token_ids.hpp"", line 359: Warning: declarator required in declaration.
""./boost/wave/token_ids.hpp"", line 359: Error: Use "";"" to terminate declarations.
""./boost/wave/token_ids.hpp"", line 359: Error: A declaration was expected instead of "","".
""./boost/wave/token_ids.hpp"", line 359: Error: CowString is not a member of boost::wave::util.
""./boost/wave/token_ids.hpp"", line 359: Error: A declaration does not specify a tag or an identifier.
Compilation aborted, too many Error messages.

    ""CC"" -xO4 -mt -erroff=%none -m32 -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_USE_LIB=1 -DNDEBUG -D_STLP_USE_DYNAMIC_LIB=1 -I""."" -I""/sw/source/mer_misc_libs/ST
Lport-4.6.2"" -c -o ""bin.v2/libs/wave/build/sun/release/address-model-32/link-static/stdlib-stlport-4.6.2/threading-multi/instantiate_re2c_lexer.o"" ""libs/w
ave/src/instantiate_re2c_lexer.cpp""


Please let me know in case, there is already resolution present. Command used to build is:
---------------------------
 bjam --without-python toolset=sun stdlib=stlport-4.6.2 address-model=32 stage --d2

user_config has below input:
------------------------------
using stlport : 4.6.2 : /sw/source/mer_misc_libs/STLport-4.6.2 : /sw/source/mer_misc_libs/STLport-4.6.2/lib ;



",harshaltan@…
10382,1.56.0 Graph adjacency_list has compile errors on g++ 4.6.4,graph,Boost 1.56.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-08-20T05:11:53Z,2014-10-18T13:11:21Z,"The following code will generate compile errors on g++ 4.6.4 but works on g++ 4.7 and 4.8. The problem looks to be in detail/adjacency_list.hpp:319-21 where the = default; specification is unable to generate a valid implementation so the move operators become implicitly deleted. 

{{{
#include ""boost/graph/adjacency_list.hpp""

int main(int argc, char** argv)
{
  using boost::adjacency_list;
  using boost::vecS;
  using boost::directedS;
  typedef adjacency_list<vecS, vecS, directedS, boost::default_color_type> Graph;

  std::vector< std::pair<int, int> > testVec;
  auto graph = Graph( begin(testVec), end(testVec), testVec.size());

  return 0;
}
}}}
",Conrad Mercer <conrad.mercer@…>
10380,filesystem directory iterator throws on increment,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-08-19T14:41:56Z,2014-08-20T05:56:31Z,"The following code throws an exception:

std::for_each( recursive_directory_iterator(path_to_root_dir), recursive_directory_iterator(), 
                       []( const directory_entry& de )
                       {
                           remove_all( de.path() );
                       }
                     );

if path_to_root_dir contains only a single sub-directory.
This happens in the increment operator of the iterator at line 791 (boost/filesystem/operations.hpp:
m_stack.push(directory_iterator(m_stack.top()->path()));

The sub-directory is successfully deleted. The exception is thrown after the deletion when the iterator is incremented",Richard <richard.j@…>
10376,VS2013: new compiler warnings since v1.56.0,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-19T07:02:38Z,2014-10-13T20:07:48Z,"There are two new level 3 compiler warnings in asio, when compiling with Visual Studio 2013 x64.

1>D:\source\VS2013\libsrc\boost_1_56_0\boost/asio/detail/impl/socket_ops.ipp(1968): warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data

1>D:\source\VS2013\libsrc\boost_1_56_0\boost/asio/detail/impl/socket_ops.ipp(2172): warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
",lex21@…
10374,Build error on cross compiling for QNX 6.6.0 x86,Building Boost,Boost 1.56.0,To Be Determined,Support Requests,,new,2014-08-19T06:05:42Z,2014-09-26T21:37:18Z,"Hello,
I'm trying to build Boost for QNX.
When cross compiling Boost 1.56 for QNX 6.6.0 x86 target, errors occured.
I found similar issue(http://svn.boost.org/trac/boost/ticket/9811) and its state is fixed in 1.56 but errors of that issue and more errors still exist. Is this issue still exist or something I did is wrong?
I'm working on Ubuntu 12.04 32bit x86 with QNX 6.6.0 SDP installed and for QNX 6.6.0 x86.

QNX uses Dinkum standard libraries(libcpp).
If I compile with option cxxflags=-Vgcc_ntox86_gpp for using gnu standard libraries(libstdc++) then it compiled successfully but that's not a solution for me because other libraries are provided built with QNX's default Dinkum libraries.

bootstrap and b2 log file attached.

Thanks.
",hkjin81@…
10371,advise() missing from iostreams mapped_file API,iostreams,Boost 1.56.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2014-08-18T18:52:00Z,2014-08-18T18:52:00Z,"The memory mapped API in interprocess (http://www.boost.org/doc/libs/1_56_0/boost/interprocess/mapped_region.hpp) provides advise() while the memory mapped API in iostreams (http://www.boost.org/doc/libs/1_56_0/libs/iostreams/doc/classes/mapped_file.html) does not.

The iostreams API is easier to use (allows creating and sizing during construction), but is missing the key feature that would allow kernel optimization of random access versus serial.",shao.lo@…
10370,Iterating over ptr_map type is largely broken in 1.56,ptr_container,Boost 1.56.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-08-18T12:51:47Z,2014-08-19T20:42:13Z,"Iteration over map fails on most types, except for value.  Not sure which version this failure began, but definitely present in 1.56

The following simple snippet will fail:

	typedef boost::ptr_map<int, int> test_map_type;
	test_map_type test_map;


	BOOST_FOREACH(test_map_type::const_reference r, test_vector )
	{

	}

Will also fail with reference, iterator, const_iterator.  boost::tie also fails.  Can iterate by value, but this does not help with my application since the mapped type will be an abstract type (so no clone allocator for mapped type)",scottbgoldblatt@…
10368,Boost.Ref: undocumented breaking change: void cref(const T&&) = delete,bind,Boost 1.56.0,To Be Determined,Bugs,Peter Dimov,new,2014-08-18T08:39:29Z,2014-08-30T17:44:11Z,"Boost 1.56.0 adds 'template <class T> void cref(T const&&) = delete' which is an undocumented addition and breaks code like:

std::find_if(..., ..., boost::cref( some_predicate(...) ) );",Geurt Vos <geurt.vos@…>
10367,kqueue on OSX broke support for read-only file descriptors,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-17T23:57:16Z,2014-08-22T13:58:27Z,"Prior 1.56, we were successfully using `boost::asio::posix::stream_descriptor` with libpcap (file descriptor retrieved via `pcap_get_selectable_fd`).

My understanding, that change https_github.com_boostorg_asio_commit_660e9fe30204e0ada0d1fd40c48015810d2647dc (replace _ with /) required all file-descriptors to be both readable and writeable (e.g., register_descriptor always registers EVFILT_READ and  EVFILT_WRITE events).

In the case of libpcap, the file descriptor only works in one direction (read) and attempt to register EVFILT_WRITE event results in `assign: Invalid argument` error.",alexander.afanasyev@…
10364,Release 1.56 broke random::uniform_real_distribution,random,Boost 1.56.0,To Be Determined,Bugs,No-Maintainer,new,2014-08-16T17:59:53Z,2016-02-17T14:40:18Z,"Multiprecision random uniform_real_distribution<mpf_float_50> stopped working correctly with 1.56. It worked fine with 1.55, and the attached code is one of the examples that Boost documentation shows for this class.

I have this problem manifesting on Mac OS X 10.9.4 under all the compilers I got: native clang from Xcode-5.1.1, clang++-mp-3.4 (macports clang v3.4.2), g++ v4.8.3.

Attaching the complete source file that demonstrates the problem (35 lines of code), and the compiler output (748 lines of text).",mouse008@…
10362,Invalid directory in Boost Build getting started,Getting Started Guide,Boost 1.56.0,To Be Determined,Bugs,Dave Abrahams,new,2014-08-16T02:08:47Z,2014-08-16T02:08:47Z,"http://www.boost.org/doc/libs/1_56_0/more/getting_started/unix-variants.html#install-boost-build

Says to go to the path

tools/build/v2/

But tools/build/ does not contain a directory /v2/",david stone <david@…>
10361,Dead link for Boost Build in getting started guide,Getting Started Guide,Boost 1.56.0,To Be Determined,Bugs,Dave Abrahams,new,2014-08-16T02:05:20Z,2014-08-16T02:05:20Z,"http://www.boost.org/doc/libs/1_56_0/more/getting_started/unix-variants.html#prepare-to-use-a-boost-library-binary

Links to

http://www.boost.org/doc/libs/1_56_0/tools/build/index.html

Which does not exist",david stone
10360,"Since 1.56, any_range use static cast of reference instead of implicit conversion",range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-15T13:54:28Z,2014-12-19T12:47:57Z,"Since 1.56, when dereferencing, any_range tries to use static cast of reference instead of implicit conversion like in 1.55.

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

{{{
#include <boost/range/any_range.hpp>
#include <memory>
#include <vector>

struct A {};

int main() {
    std::vector<std::shared_ptr<A> > v;
    boost::any_range<std::shared_ptr<const A>,
                     boost::forward_traversal_tag,
                     std::shared_ptr<const A>,
                     std::ptrdiff_t> r(v);
}

}}}
",vdavid@…
10356,Massive Warnings Wall whenu using signal2 call operator - VS2013U3,signals2,Boost 1.56.0,To Be Determined,Bugs,Frank Mori Hess,new,2014-08-14T14:39:29Z,2016-04-28T18:02:13Z,"
{{{

#include <boost/signals2.hpp>

void foo()
{
  boost::signals2::signal<void()> signal;
  signal();
}
}}}

On VS2013 Update3 I get this output on compilation:

{{{

1>------ Build started: Project: test_distributed_value, Configuration: Debug x64 ------
1>  main.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory(348): warning C4996: 'std::_Uninitialized_copy0': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
1>          C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory(333) : see declaration of 'std::_Uninitialized_copy0'
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(192) : see reference to function template instantiation '_FwdIt std::uninitialized_copy<I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(_InIt,_InIt,_FwdIt)' being compiled
1>          with
1>          [
1>              _FwdIt=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>  ,            _InIt=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(179) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_rai<I,false>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,const boost::integral_constant<bool,false> &)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(179) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_rai<I,false>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,const boost::integral_constant<bool,false> &)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(205) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl<I>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,std::random_access_iterator_tag)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(205) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl<I>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,std::random_access_iterator_tag)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(289) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl<boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(289) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl<boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(282) : while compiling class template member function 'boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::move_to_new_buffer(unsigned __int64,const boost::false_type &)'
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/auto_buffer.hpp(304) : see reference to function template instantiation 'boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::move_to_new_buffer(unsigned __int64,const boost::false_type &)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/slot_call_iterator.hpp(40) : see reference to class template instantiation 'boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>          ]
1>          C:\Users\jlamotte\Documents\sdk\boost\boost\include\boost-1_56\boost/signals2/detail/slot_call_iterator.hpp(44) : see reference to class template instantiation 'boost::signals2::detail::slot_call_iterator_cache<ResultType,Function>' being compiled
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Build Summary
-------------
00:01.496 - Success - Debug x64 - test_distributed_value.vcxproj

Total build time: 00:01.496

========== Build: 1 succeeded or up-to-date, 0 failed, 2 skipped, Completed at 14/08/2014 16:08:05 ==========

}}}



",mjklaim@…
10354,inconsistent declaration of do_length in boost/detail/utf8_codecvt_facet.hpp due to missing BOOST_WORKAROUND,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,reopened,2014-08-13T21:16:29Z,2014-09-05T13:57:36Z,"First, the output when trying to build boost in AIX using xlC

  xlC_r -c     -DBOOST_ALL_NO_LIB=1 -DNDEBUG -qcpluscmt -O3 -qstrict -q64 -qfuncsect -qeh -qrtti -I"".""  -o ""bin.v2/libs/filesystem/build/vacpp-11/release/... utf8_codecvt_facet.o"" ""libs/filesystem/src/utf8_codecvt_facet.cpp""

  ""./boost/detail/utf8_codecvt_facet.ipp"", line 173.5: 1540-0400 (S) ""boost::archive::detail::utf8_codecvt_facet::do_length(const std::mbstate_t &, const char *, const char *, std::size_t) const"" has a conflicting declaration.
  ""./boost/detail/utf8_codecvt_facet.hpp"", line 174.17: 1540-0424 (I) ""do_length"" is declared on line 174 of ""./boost/detail/utf8_codecvt_facet.hpp"".

The problem is that there is a mismatch in the declaration of the function between
* boost/detail/utf8_codecvt_facet.hpp 
* boost/detail/utf8_codecvt_facet.ipp 

{{{
#!cpp
    // boost/detail/utf8_codecvt_facet.hpp 
    virtual int do_length(
        const std::mbstate_t &,
        const char * from,
        const char * from_end,
        std::size_t max_limit
    ) const
}}}
{{{
#!cpp
    // boost/detail/utf8_codecvt_facet.ipp 
    int utf8_codecvt_facet::do_length(
        BOOST_CODECVT_DO_LENGTH_CONST std::mbstate_t &,
        const char * from,
        const char * from_end,
        std::size_t max_limit
    ) const
#if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600))
        throw()
#endif
}}}

The solution is to add BOOST_CODECVT_DO_LENGTH_CONST and the BOOST_WORKAROUND macro in boost/detail/utf8_codecvt_facet.hpp 


Also, unless BOOST_DETECT_OUTDATED_WORKAROUNDS is defined, BOOST_WORKAROUND will always evaluate to 1 for any version of xlC, adding a throw() declaration.

Maybe it should be replaced with
{{{
#!cpp
#if BOOST_WORKAROUND(__IBMCPP__, <=600)
}}}

Last, I've filed this in filesystem component following what was done for https://svn.boost.org/trac/boost/ticket/7660 since there is no specific entry for boost/detail in the component list. It fits as well in serialization, program_options, etc.

",Juan Alday <alday.boost.trac@…>
10353,Interprocess: rbtree_best_fit ABI change from 1.53 to 1.55,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-08-13T20:40:23Z,2014-08-22T17:46:20Z,"I have an issue that seems to be identical to the issue discussed in this thread on the Boost List: http://lists.boost.org/boost-users/2014/01/81159.php

Basically, it seems the size of the Imultiset member in header_t of rbtree_best_fit.hpp has changed between Boost 1.53 and Boost 1.55.  As mentioned in the thread from the Boost List:

>> boost::interprocess::rbtree_best_fit<boost::interprocess::null_mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0> 
>> 
>> has size = 56 
>> member m_header.m_imultiset has size 32 
>> 
>> In code compiled with boost 1.55: 
>> 
>> the same type has size = 72 
>> member m_header.m_imultiset has size 48 
>
>
>Wow, that's too big. I think this is related with MSVC Empty Base 
>Implementation behaviour. I refactored those classes to avoid redundant 
>simple forwarding functions using inheritance and that broke this for 
>MSVC compilers. I should add some checks for 32 and 64 bit compilers to 
>guarantee the minimum size (16 bytes in 32 bit and 32 bytes in 64 bit). ",Terence.Darwen@…
10350,asio build broken for /dev/poll in 1.56,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-13T13:53:43Z,2014-08-13T13:53:43Z,"Commit c06aa74f08a46dda05493f61d2b85cb7818e6f96 (see ticket #9528) breaks build on SunOS (possibly any /dev/poll system), because it removes get_descriptors, but leaves calls to it in include/boost/asio/detail/impl/dev_poll_reactor.ipp.",filip@…
10347,Boost.ProgramOptions without RTTI,program_options,Boost 1.56.0,To Be Determined,Patches,Vladimir Prus,new,2014-08-12T12:19:22Z,2015-03-04T05:54:06Z,Program options utilizes typeid in value semantic. This is a patch for compiling it without RTTI on.,Minmin Gong <gongminmin@…>
10344,"Provide [b,e) constructor for string_ref",utility,Boost 1.56.0,To Be Determined,Feature Requests,No-Maintainer,new,2014-08-11T21:16:16Z,2014-08-11T21:16:16Z,"It would be nice to be able to construct a string_ref from a begin/end pointer pair.  I suppose I could use string_ref(begin, end-begin) but it just feels a little wonky to have to compute the length all the time.",Richard <legalize@…>
10337,"weak_ptr & shared_ptr causes double ""delete"" -> crash",smart_ptr,Boost 1.53.0,To Be Determined,Bugs,Peter Dimov,new,2014-08-10T15:57:00Z,2014-08-10T16:41:19Z,"I am not sure why this happens (VS2005 - VS2013) and specifically on windows (code compiles and runs fine on linux)...

The following is the boost code that is responsible:

    void sp_counted_impl_p<T>::release() // nothrow
    {
        if( BOOST_INTERLOCKED_DECREMENT( &use_count_ ) == 0 )
        {
            dispose();
            weak_release();
        }
    }

    void sp_counted_impl_p<T>::weak_release() // nothrow
    {
        if( BOOST_INTERLOCKED_DECREMENT( &weak_count_ ) == 0 )
        {
            destroy();
        }
    }

Look what MUST happen, when ""use_count = 1"" and ""weak_count = 1"".. It causes a double release which crashes the application. That was a real pain in the ass to track down and unfortunately I have nothing to specifically trigger this issue either. Just look at the code and it should be obvious that this is a race condition.",thesaint1987@…
10336,compilation error in iterator_range and unordered_map,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-10T08:07:32Z,2015-01-31T14:52:10Z,"I get a compilation error with vc10, iterator_range and a (const)
unordered_map (the beta candidate 2 was still ok I think):

{{{#!cpp
#include ""stdafx.h""
#include <boost/range/iterator_range.hpp>
#include <boost/unordered_map.hpp>


int _tmain(int /*argc*/, _TCHAR* /*argv*/[])
{
   typedef boost::unordered_map<int, int>            Container;
   typedef Container::const_iterator                 ContainerIterator;
   typedef boost::iterator_range<ContainerIterator>  ContainerIteratorRange;

   const Container cnt;

   ContainerIteratorRange rng(cnt.cbegin(), cnt.cend());
   
   return 0;
}
}}}

This gives C2248: 

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

cannot access private typedef declared in class

etc.


Eric: Niebler:

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

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

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

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

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

",gast128@…
10333,iostreams generates many warnings with gcc 4.8,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-08-09T23:07:13Z,2014-08-09T23:07:13Z,See attached log for an example,Richard <legalize@…>
10332,»indexed« range adaptor's source-breaking change not mentioned in release notes,range,Boost 1.56.0,To Be Determined,Bugs,Neil Groves,assigned,2014-08-09T20:45:26Z,2014-09-01T11:54:45Z,"The »indexed« range adaptor has changed in v1.56.0 in source-breaking ways. I get the change and that it was necessary for range-based for loops, but this means that you now have to `#if BOOST_VERSION < …` around it. See [[http://boost.codepad.org/VE1QSmSz|this example]] (distilled from actual code).

Why the ticket? Because the change hasn't been mentioned at all in the [[http://www.boost.org/users/history/version_1_56_0.html|release notes]].",Moritz Bunkus <moritz@…>
10330,Boost 1.56 bootstrap.bat  failed  for intel-win32,Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2014-08-09T08:24:14Z,2014-08-28T08:07:19Z,"New boost.1.56.0 bootstrap.bat fails on Windows with old toolset and with new intel-win32 toolset
I used 
# unzip boost_1_56_0.zip
# ./bootstrap.bat intel-win32
Building Boost.Build engine

Failed to build Boost.Build engine.
Please consult bootstrap.log for furter diagnostics.

You can try to obtain a prebuilt binary from
. . .

Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

From attached bootstrap.log: 
. . .
boost_1_56_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=intel-win32 ""--toolset-root= "" -win32 clean
Invalid option: -w

usage: .\bootstrap\jam0 [ options ] targets...

For boost v1.55.0 I used   tar.gz archive and   
./bootstrap.bat --with-toolset=intel-win
but for 1.56.0 it doesn't work. 
According to recommendation for Ticket #10136 I use *.zip on Windows,
but bootstrap.bat doesn't work  for intel-win32
",Elmira Semenova <elmira.a.semenova@…>
10329,Examples declare unused variable 'sefl',asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-08T13:42:41Z,2014-08-08T13:42:41Z,"C++11 example:

http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/example/cpp11/http/server/connection.cpp

declares a variable 'self' as shared_from_this() but never uses it.  Inside the lambda, shared_from_this() is used directly.",Richard <legalize@…>
10325,Win32: including file_lock.hpp results in compilation error,interprocess,Boost 1.56.0,Boost 1.57.0,Bugs,Ion Gaztañaga,new,2014-08-08T07:02:19Z,2014-09-07T21:00:29Z,"Today I switched from Boost 1.55.0 to 1.56.0 and now get the following error just for including file_lock.hpp:

'''error: invalid conversion from 'boost::interprocess::winapi::farproc_t {aka int (__attribute__((__stdcall__)) *)()}' to 'void*' [-fpermissive]'''

{{{
In file included from d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\errors.hpp:37:0,
                 from d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\exceptions.hpp:20,
                 from d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\sync\file_lock.hpp:20,
                 from src\init.cpp:38:
d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\detail\win32_api.hpp: In instantiation of 'static void* boost::interprocess::winapi::function_address_holder<Dummy>::get(unsigned int) [with int Dummy = 0]':
d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\detail\win32_api.hpp:1614:20:   required from here
d:\mingw\mingw32\i686-w64-mingw32\include\boost\interprocess\detail\win32_api.hpp:1541:31: error: invalid conversion from 'boost::interprocess::winapi::farproc_t {aka int (__attribute__((__stdcall__)) *)()}' to 'void*' [-fpermissive]
       return FunctionAddresses[id];
                               ^
}}}

Used compiler: gcc version 4.8.1 (rev5, Built by MinGW-W64 project)

OS: Win8.1 x64

IDE: Qt Creator 3.1.2 (Qt 5.3.1)

I verified that the project compiles fine, if the file_lock stuff is commented out. I'm going to watch this thread, so I don't supply my email address.",anonymous
10322,documentation for erase method of multisets is wrong,intrusive,Boost 1.56.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-08-08T00:21:52Z,2015-03-01T04:31:47Z,"This is a documentation bug.

The page [[http://www.boost.org/doc/libs/1_56_0/doc/html/boost/intrusive/multiset.html#idp34712280-bb|here]] states that `erase(const_reference value)` ""erases the element pointed to by `pos`"". First of all, this is a typo because `pos` is not an argument. One would assume that the element to be erased is the one referenced by `value`.

It turns out that this is wrong: this overload erases not just one element (the given one), but in fact, **all** elements of the multiset with key equivalent to the given one (according to the container's internal comparator method). This is immediately apparent by looking at the definition of `erase(const_reference value)` inside `bstree.hpp`.

Most likely this affects the documentation for the other multiset variants as well (avl, etc).",Matei David <matei@…>
10316,Thread: add subscription operator if the value provide it.,thread,Boost 1.55.0,To Be Determined,Feature Requests,viboes,assigned,2014-08-06T08:51:17Z,2014-09-29T08:19:58Z,"I would like to be able to do 


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


and would expect that last line to be equivalent to


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

    

I'm not totally sure it's possible to do but it would help.",mjklaim@…
10314,Update 59fd3b6 on May 17  to cray.jam breaks cray build,Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2014-08-05T16:49:11Z,2015-03-31T14:49:05Z,"



Download the 1.56 boost beta.

do: ./bootstrap.sh
    ./b2 --with-serialization --with-system --with-filesystem --with-date_time --with-program_options --with-test -d2 toolset=cray stage 

Get lots of errors like ...

    CC -c -O2 -march=bdver1 -mfpmath=sse -mfma4 -mavx -funroll-all-loops -mprefer-avx128 -fprefetch-loop-arrays --param prefetch-latency=300 -minline-all-stringops -ffast-math -fno-finite-math-only -dynamic -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I""."" -o ""bin.v2/libs/date_time/build/cray/release/threading-multi/gregorian/greg_month.o"" ""libs/date_time/src/gregorian/greg_month.cpp""

CC-2115 crayc++: ERROR in command line
  ""-march=bdver1"" is an invalid command-line option.
CC-2115 crayc++: ERROR in command line
  ""-mfpmath=sse"" is an invalid command-line option.
CC-2115 crayc++: ERROR in command line
  ""-mfma4"" is an invalid command-line option.
CC-2115 crayc++: ERROR in command line
  ""-mavx"" is an invalid command-line option.
CC-2115 crayc++: ERROR in command line
  ""-mprefer-avx128"" is an invalid command-line option.
CC-2115 crayc++: ERROR in command line
  ""--param"" is an invalid command-line option.
CC-2115 crayc++: ERROR in command line
  ""-minline-all-stringops"" is an invalid command-line option.
...failed cray.compile.c++ bin.v2/libs/date_time/build/cray/release/threading-multi/gregorian/greg_month.o...
cray.compile.c++ bin.v2/libs/date_time/build/cray/release/threading-multi/gregorian/greg_weekday.o
",Richard Dale <rsd@…>
10313,Dynamic bitset destruction asserts with small size,dynamic_bitset,Boost 1.55.0,To Be Determined,Bugs,jsiek,new,2014-08-05T15:14:07Z,2014-08-05T15:14:07Z,"I created a dynamic bitset and resized it to 2. When the bitset is destructed it asserts when m_check_invariants returns false. A size of 8 was observed to not exhibit this behavior.

This was also observed in the 1.56 beta",Andrew Sasak <andrew.sasak@…>
10312,uBLAS have missing accessors in some expressions,uBLAS,Boost 1.54.0,Boost 1.57.0,Bugs,Gunter,new,2014-08-05T08:03:52Z,2014-08-05T08:03:52Z,"For example, these lines are missing from the class `matrix_binary_scalar1`:


{{{
    public: // around line 2925 in `matrix_expression.hpp`
        // Expression accessors
        BOOST_UBLAS_INLINE
        const expression1_closure_type &expression1 () const {
            return e1_;
        }
        BOOST_UBLAS_INLINE
        const expression2_closure_type &expression2 () const {
            return e2_;
        }
}}}


Without these lines is impossible to access to the expression template built by ""d*matrix<...>"". where d is a scalar. Other similar classes also miss this, in my opinion all this feature should be in based class.

This is most likely an oversight",correaa@…
10310,serialization/smart_cast.hpp uses dynamic_cast and breaks non-RTTI builds,serialization,Boost 1.55.0,To Be Determined,Bugs,Robert Ramey,new,2014-08-04T14:30:03Z,2014-08-06T08:17:42Z,"When serializing through a pointer to a polymorphic base class, dynamic cast is invoked in line 204, thus making it impossible to serialize via base pointer without RTTI.",Mika Fischer <mika.fischer@…>
10305,Abstract namespace endpoint bug in boost::asio,asio,Boost 1.46.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-02T20:38:16Z,2014-08-02T20:38:38Z,"strlen calculated erraounusly, as abstract namespace paths begin with 0.

see boost/asio/local/detail/impl/endpoint.ipp:44

init(path, strlen(path));

Could be replaced with:

init(path, strlen(path + 1) + 1);

Affects more similar lines in file.
",roland.waltersson@…
10304,1.56 rc1 ASIO doesn't compile with mingw32,asio,Boost 1.56.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-08-02T18:03:04Z,2014-08-02T18:03:04Z,"This is from the most recent mingw, the one with GCC 4.8. Yes I agree mingw is broken :(

{{{
In file included from ./boost/asio/detail/win_object_handle_service.hpp:180:0,
                 from ./boost/asio/windows/object_handle_service.hpp:25,
                 from ./boost/asio/windows/basic_object_handle.hpp:27,
                 from ./boost/asio.hpp:108,
                 from ./boost/afio/afio.hpp:24,
                 from libs\afio\test\test_functions.hpp:32:
./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'void boost::asio::detail::win_object_handle_service::move_construct(boost::asio::detail::win_object_handle_service::implementation_type&, boost::asio::detail::win_object_handle_service::implementation_type&)':
./boost/asio/detail/impl/win_object_handle_service.ipp:106:5: error: '::UnregisterWaitEx' has not been declared
     ::UnregisterWaitEx(impl.wait_handle_, INVALID_HANDLE_VALUE);
     ^
./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'void boost::asio::detail::win_object_handle_service::move_assign(boost::asio::detail::win_object_handle_service::implementation_type&, boost::asio::detail::win_object_handle_service&, boost::asio::detail::win_object_handle_service::implementation_type&)':
./boost/asio/detail/impl/win_object_handle_service.ipp:158:5: error: '::UnregisterWaitEx' has not been declared
     ::UnregisterWaitEx(impl.wait_handle_, INVALID_HANDLE_VALUE);
     ^
./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'void boost::asio::detail::win_object_handle_service::destroy(boost::asio::detail::win_object_handle_service::implementation_type&)':
./boost/asio/detail/impl/win_object_handle_service.ipp:200:7: error: '::UnregisterWaitEx' has not been declared
       ::UnregisterWaitEx(wait_handle, INVALID_HANDLE_VALUE);
       ^
./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'boost::system::error_code boost::asio::detail::win_object_handle_service::close(boost::asio::detail::win_object_handle_service::implementation_type&, boost::system::error_code&)':
./boost/asio/detail/impl/win_object_handle_service.ipp:251:7: error: '::UnregisterWaitEx' has not been declared
       ::UnregisterWaitEx(wait_handle, INVALID_HANDLE_VALUE);
       ^
./boost/asio/detail/impl/win_object_handle_service.ipp: In member function 'boost::system::error_code boost::asio::detail::win_object_handle_service::cancel(boost::asio::detail::win_object_handle_service::implementation_type&, boost::system::error_code&)':
./boost/asio/detail/impl/win_object_handle_service.ipp:302:7: error: '::UnregisterWaitEx' has not been declared
       ::UnregisterWaitEx(wait_handle, INVALID_HANDLE_VALUE);
       ^
./boost/asio/detail/impl/win_object_handle_service.ipp: In static member function 'static void boost::asio::detail::win_object_handle_service::wait_callback(PVOID, BOOLEAN)':
./boost/asio/detail/impl/win_object_handle_service.ipp:402:5: error: '::UnregisterWaitEx' has not been declared
     ::UnregisterWaitEx(impl->wait_handle_, NULL);
     ^
}}}

",Niall Douglas
10301,Add shared_queue_front and shared_queue_back,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-08-02T15:20:52Z,2014-08-02T15:41:52Z,Based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#Managed add shared_queue_front and shared_queue_back.,viboes
10299,Add queue iterators,thread,Boost 1.56.0,To Be Determined,Feature Requests,viboes,assigned,2014-08-02T15:10:58Z,2014-08-02T15:11:12Z,As for  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#streaming_iterators add queue iterators. ,viboes
10285,local_time is not monotonic,date_time,Boost 1.55.0,To Be Determined,Bugs,"James E. King, III",assigned,2014-08-01T08:03:44Z,2018-01-06T15:43:11Z,"The following snippet seems to generate non monotonic local_date. 

I'm using boost 1.55 on linux. 

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

int main() { 
  const boost::local_time::time_zone_ptr theTimeZone( 
    new boost::local_time::posix_time_zone( 
          ""CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00"") 
  ); 

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

  for (size_t i = 0; ; ++i) { 
    const boost::local_time::local_date_time myLocalTime = 
        boost::local_time::local_microsec_clock::local_time(theTimeZone); 

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

    myOldValue = myLocalTime; 
  } 
} 

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


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

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


",Gaetano Mendola <mendola@…>
10283,Cross-compiling on MacOSX for linux using clang fails to build static libs correctly.,Building Boost,Boost Development Trunk,To Be Determined,Bugs,,new,2014-07-31T16:26:04Z,2014-07-31T16:26:04Z,"The logic in gcc.jam that dynamically determines the paths to ranlib and ar needs to duplicated in clang-linux.jam and clang-darwin.jam. The current implementation uses the darwin versions of ranlib and ar which doesn't work correctly for linux-elf static libs.



",bayoubengal@…
10282,Compilation error in py_nonblocking.cpp,mpi,Boost Development Trunk,Boost 1.56.0,Bugs,Matthias Troyer,new,2014-07-31T09:43:27Z,2015-08-14T10:37:10Z,"I'm getting the following compilation error on the git master branch on the mpi/src/python/py_nonblocking.cpp when using tip-of-trunk clang and libc++ under MacOs 10.9.4 when compiling in c++11/c++1y modes:

libs/mpi/src/python/py_nonblocking.cpp:166:14: error: no viable conversion from 'optional<(anonymous namespace)::py_call_output_iterator<boost::mpi::status, std::__1::__wrap_iter<boost::mpi::python::request_with_value *> > >' to 'bool'
      return test_all(requests.begin(), requests.end(), 

             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 error generated.

Compilation used:

""clang++"" -x c++ -Wl,-flat_namespace -stdlib=libc++ -nostdinc++ -std=c++1y -I/Users/gnzlbg/src/env/include/libcxx -O3 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I""."" -I""/Users/gnzlbg/src/env/include"" -I""/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/include/python2.7"" -c -o ""/Users/gnzlbg/src/env/boost_build/boost/bin.v2/libs/mpi/build/clang-darwin-4.2.1/release/threading-multi/python/py_nonblocking.o"" ""libs/mpi/src/python/py_nonblocking.cpp""

A patch is attached",gonzalobg88@…
10281,including intrusive/list.hpp breaks compilation using managed_shared_memory,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-07-30T21:57:30Z,2014-07-31T21:32:38Z,"The following small program fails to compile:


{{{
  #include <boost/intrusive/list.hpp> // comment out this to make error go away
  #include <boost/interprocess/managed_shared_memory.hpp>

  using namespace boost::interprocess;
  managed_shared_memory msm;
  void test()
    {
    msm = boost::interprocess::managed_shared_memory(open_or_create, ""test"", 100);
    }
}}}


/code/git/boost/boost/intrusive/pointer_traits.hpp:173:74: error: static_cast from type ‘boost::intrusive::pointer_traits<boost::interprocess::offset_ptr<const void, long int, long unsigned int, 0ul> >::element_type* {aka const void*}’ to type ‘boost::intrusive::pointer_traits<boost::interprocess::offset_ptr<boost::intrusive::bhtraits<boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>::block_ctrl, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, (boost::intrusive::link_mode_type)0u, boost::intrusive::default_tag, 3u>, long int, long unsigned int, 0ul> >::element_type* {aka boost::intrusive::bhtraits<boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>::block_ctrl, boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>, (boost::intrusive::link_mode_type)0u, boost::intrusive::default_tag, 3u>*}’ casts away qualifiers

cc --version
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
",stone@…
10277,reference_wrapper & implicit conversion to parent types,bind,Boost 1.55.0,To Be Determined,Feature Requests,Peter Dimov,new,2014-07-30T03:02:00Z,2014-08-02T14:58:51Z,"I propose a change to reference_wrapper which enables implicit conversion to references and reference_wrappers of base types.

One motivation for this is an unconventional use of reference_wrapper:

Many common library functions in code have a non-trivial set of arguments, some of which being non-const references. When reading code that uses these functions, it is often difficult to tell what side-effects a library function has from call to call. Having a coding policy that mutable references must be reference_wrappers and having calling code use ref() enables readers of the callsites to clearly identify which arguments have the possibility of having side-effects.

However, this is currently not possible without creating a custom implementation of reference_wrapper.

I have attached a proposed modification to the boost 1.55.0 implementation, as well as a simple file testing the extended capability.",Christopher <kemsleyc@…>
10276,For clang toolset Boost 1.56 needs to always specify -Wno-c99-extensions,build,Boost 1.56.0,To Be Determined,Bugs,Vladimir Prus,new,2014-07-30T00:57:38Z,2014-07-30T00:57:38Z,"See mailing list for discussion, but essentially 1.56 Preprocessor turns on variadic macro support for clang which spews many megabytes of warnings on clang versions 3.2, 3.3, and 3.4. This is unacceptable for a 1.56 release, it would be embarrassing.

Adding the above warning suppression makes the problem go away.

Niall",Niall Douglas
10275,darwin.jam fails to detect installed SDK on MacOS 10.9 with XCode 5.1 installed,Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2014-07-30T00:07:25Z,2016-05-23T14:23:22Z,"On MacOS 10.9 / XCode 5.1, the SDKs are installed to a new location instead of ""/Developer/"":

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/

as a result the boost's darwin.jam fails to locate the available SDKs. The following command line will output errors:

./b2 macosx-version-min=10.7

errors:

tools/build/src/build/feature.jam:493: in validate-value-string from module feature
error: ""10.7"" is not a known value of feature <macosx-version-min>
error: legal values:
...
 
The workaround is create a soft link to new SDK location and everything works fine:

cd /
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ Developer


FYI: The XCode5 installs iOS sdks under:

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/

so darwin.jam should search both /Developer/ and these new SDK locations for installed SDKs.  


 ",randy du <randydu@…>
10272,property_tree commit 8af8b6b breaks VS2013 64-bit build,property_tree,Boost Development Trunk,To Be Determined,Bugs,Sebastian Redl,new,2014-07-29T14:11:54Z,2017-07-22T19:14:00Z,"I was attempting to build the PointCloudLibrary using the 1.56.0_beta1 binary from SourceForge; however, I encountered the following compilation errors when doing so:

{{{
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(38): error C2825: 'Str': must be a class or namespace when followed by '::' (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
          C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp(201) : see reference to class template instantiation 'boost::property_tree::xml_parser::xml_writer_settings<char>' being compiled
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(38): error C2039: 'value_type' : is not a member of '`global namespace'' (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(38): error C2146: syntax error : missing ';' before identifier 'Ch' (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(38): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(40): error C2061: syntax error : identifier 'Ch' (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(49): error C2146: syntax error : missing ';' before identifier 'indent_char' (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(49): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(50): error C2825: 'Str': must be a class or namespace when followed by '::' (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(50): error C2039: 'size_type' : is not a member of '`global namespace'' (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(50): error C2146: syntax error : missing ';' before identifier 'indent_count' (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\boost-1_56_0_b1\boost/property_tree/detail/xml_parser_writer_settings.hpp(50): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int (C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp)
C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp(201): error C2661: 'boost::property_tree::xml_parser::xml_writer_settings<char>::xml_writer_settings' : no overloaded function takes 2 arguments
C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp(203): error C2664: 'void boost::property_tree::xml_parser::write_xml<boost::property_tree::ptree>(const std::string &,const Ptree &,const std::locale &,const boost::property_tree::xml_parser::xml_writer_settings<Key> &)' : cannot convert argument 4 from 'boost::property_tree::xml_parser::xml_writer_settings<char>' to 'const boost::property_tree::xml_parser::xml_writer_settings<Key> &'
          with
          [
              Ptree=boost::property_tree::ptree
  ,            Key=std::string
          ]
          and
          [
              Key=std::string
          ]
          Reason: cannot convert from 'boost::property_tree::xml_parser::xml_writer_settings<char>' to 'const boost::property_tree::xml_parser::xml_writer_settings<Key>'
          with
          [
              Key=std::string
          ]
          No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp(221): error C2661: 'boost::property_tree::xml_parser::xml_writer_settings<char>::xml_writer_settings' : no overloaded function takes 2 arguments
C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp(227): error C2664: 'void boost::property_tree::xml_parser::write_xml<boost::property_tree::ptree>(const std::string &,const Ptree &,const std::locale &,const boost::property_tree::xml_parser::xml_writer_settings<Key> &)' : cannot convert argument 4 from 'boost::property_tree::xml_parser::xml_writer_settings<char>' to 'const boost::property_tree::xml_parser::xml_writer_settings<Key> &'
          with
          [
              Ptree=boost::property_tree::ptree
  ,            Key=std::string
          ]
          and
          [
              Key=std::string
          ]
          Reason: cannot convert from 'boost::property_tree::xml_parser::xml_writer_settings<char>' to 'const boost::property_tree::xml_parser::xml_writer_settings<Key>'
          with
          [
              Key=std::string
          ]
          No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp(282): error C2661: 'boost::property_tree::xml_parser::xml_writer_settings<char>::xml_writer_settings' : no overloaded function takes 2 arguments
C:\Users\Will\Source\pcl.git\io\src\lzf_image_io.cpp(287): error C2664: 'void boost::property_tree::xml_parser::write_xml<boost::property_tree::ptree>(const std::string &,const Ptree &,const std::locale &,const boost::property_tree::xml_parser::xml_writer_settings<Key> &)' : cannot convert argument 4 from 'boost::property_tree::xml_parser::xml_writer_settings<char>' to 'const boost::property_tree::xml_parser::xml_writer_settings<Key> &'
          with
          [
              Ptree=boost::property_tree::ptree
  ,            Key=std::string
          ]
          and
          [
              Key=std::string
          ]
          Reason: cannot convert from 'boost::property_tree::xml_parser::xml_writer_settings<char>' to 'const boost::property_tree::xml_parser::xml_writer_settings<Key>'
          with
          [
              Key=std::string
          ]
          No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
}}}

Reverting the `property_tree` module back to commit `85f8d8866ccfa98e4a667343529adb411bd67d08` corrected the build problem I was having.

Thanks,
Will",mevatron@…
10271,It is not possible to build BOOST ptr_container without RTTI except the compiler option BOOST_DISABLE_ASSERT is used.,ptr_container,Boost 1.54.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-07-29T11:54:36Z,2014-07-29T11:54:36Z,"The BOOST_DISABLE_ASSERT define is necessary to build without RTTI ,because there is bug inside the boost_ptr_container (reversible_ptr_container.hpp, clone_allocator.hpp). The implementation uses the typeid(..) function inside a BOOST_ASSERT. Unfortunately it does not care about the RTTI setting (enabled or not). I had this problem in a debug build.",Christoph Perick <christoph.perick@…>
10269,Move the library to its own namespace,range,Boost 1.56.0,To Be Determined,Feature Requests,Neil Groves,new,2014-07-29T07:44:11Z,2014-07-29T07:44:11Z,"Boost.Range defines most of its symbols in the boost:: namespace. This introduces conflicts with other Boost libraries, for example:

http://thread.gmane.org/gmane.comp.lib.boost.devel/249985/focus=249986
http://lists.boost.org/Archives/boost/2014/07/215581.php

Another drawback is that in user's code unqualified function calls with range arguments use boost:: namespace for symbol lookup, which may introduce unexpected results.

I propose to move all Boost.Range symbols to a dedicated namespace (e.g. boost::ranges). For backward compatibility the library can import all public interfaces except operators to the boost:: namespace.
",Andrey Semashev
10265,[asio] AIX 6.1 bug with missing symbol in asio tests,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-07-28T15:56:38Z,2014-07-28T15:56:38Z,"The symbol test_main was left undefined for every single one of the asio tests. As a result I would get the following error over and over:

ld: 0711-317 ERROR: Undefined symbol: .test_main(int, char**)

The weird thing is that the tests did not appear to be using this symbol at all, yet it was still preserved. To compensate I added an empty definition of test_main. This allowed all of the tests in the suite to run. Most of the tests passed except for two, but for unrelated issues that I still need to look at.

It is possible that the semantics of the AIX linker and the way that GCC interacts with the linker are causing extra symbols to be preserved. There might need to be in the future more work that needs to be done for either, but for now I think this is a good solution.


Please look at the Pull Request created for further details:
https://github.com/boostorg/asio/pull/6",Axel Ismirlian <axel.ismirlian@…>
10264,[smart_ptr] AIX 6.1 bug with sched_yield() function out of scope,smart_ptr,Boost 1.55.0,To Be Determined,Bugs,Peter Dimov,new,2014-07-28T15:56:20Z,2014-07-28T15:56:20Z,"The error that pops up in some of the lambda tests is the following:

../libs/lambda/test/algorithm_test.cpp:37:48: error: reference to 'var' is ambiguous
                      protect((_1 = var(sum), ++var(sum)))));
                                                ^
In file included from /usr/include/sys/thread.h:37:0,
                 from /usr/include/sys/ptrace.h:28,
                 from /usr/include/sys/proc.h:42,
                 from /usr/include/sys/pri.h:43,
                 from /usr/include/sys/sched.h:38,
                 from /usr/include/sched.h:51,
                 from ../boost/smart_ptr/detail/yield_k.hpp:101,
                 from ../boost/smart_ptr/detail/spinlock_sync.hpp:18,
                 from ../boost/smart_ptr/detail/spinlock.hpp:50,
                 from ../boost/smart_ptr/detail/spinlock_pool.hpp:25,
                 from ../boost/smart_ptr/shared_ptr.hpp:34,
                 from ../boost/shared_ptr.hpp:17,
                 from ../boost/test/utils/callback.hpp:21,
                 from ../boost/test/execution_monitor.hpp:38,
                 from ../boost/test/impl/execution_monitor.ipp:30,
                 from ../boost/test/minimal.hpp:37,
                 from ../libs/lambda/test/algorithm_test.cpp:14:
/usr/include/sys/var.h:59:8: note: candidates are: struct var
 struct var {
        ^
In file included from ../boost/lambda/core.hpp:53:0,
                 from ../boost/lambda/lambda.hpp:14,
                 from ../libs/lambda/test/algorithm_test.cpp:16:
../boost/lambda/detail/lambda_functor_base.hpp:66:19: note:                 template<class T> boost::lambda::lambda_functor<T> boost::lambda::var(const boost::lambda::lambda_functor<T>&)
 lambda_functor<T> var(const lambda_functor<T>& t) { return t; }
                   ^
../boost/lambda/detail/lambda_functor_base.hpp:60:38: note:                 template<class T> boost::lambda::lambda_functor<boost::lambda::identity<T&> > boost::lambda::var(T&)
 inline lambda_functor<identity<T&> > var(T& t) { return identity<T&>(t); }
                                      ^

In ../boost/lambda/detail/lambda_functor_base.hpp there is variable called var that conflicts with an AIX system variable. Defining var and later undefining it frees that variable name. However, the fix I propose is in the smart_ptr function.

Please look at the Pull Request created for further details:
https://github.com/boostorg/smart_ptr/pull/7",Axel Ismirlian <axel.ismirlian@…>
10258,b2 fails to find gcc if bootstrapped with clang,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2014-07-28T10:18:12Z,2018-01-23T01:01:12Z,"The system showing the problem is Ubuntu 14.04 LTS on ARMv7a. x86 or x64 may not have the same problem. This is in Boost 1.56 beta.

What my CI was always doing for bootstrap is this:

./bootstrap.sh --with-toolset=clang

Unfortunately, this breaks:

./b2 toolset=gcc ...

iff you bootstrapped with clang! It appears to set the gcc executable path to an empty string with obvious consequences.

./b2 toolset=clang works fine though, as does bootstrapping with gcc whereupon both gcc and clang toolsets work fine.
",Niall Douglas
10248,Understanding generated files / targets.,build,Boost 1.51.0,To Be Determined,Support Requests,Vladimir Prus,new,2014-07-27T18:41:49Z,2015-02-27T01:38:18Z,"Attached is a .zip file containing a detailed Jamroot attempting to understand how generated files and dependency analysis work.  There are a few points that are not clear to me, so I hope someone can take a look and see of any of these behaviors are actually bugs.
",anonymous
10244,Erroneous conversion from double to boost::rational<int>,rational,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-07-25T12:58:54Z,2014-07-25T12:58:54Z,"The documentation discusses in detail why conversion from double is not supported, but the following code works fine:

{{{
#include <iostream>
#include <boost/rational.hpp>

int main()
{
  double d = 31.82;
  boost::rational<int> r = d;
  std::cout << r << std::endl;
}
}}}

With the following result ""31/1"". It just discards the fractional part. A double is implicitly converted to int and then the implicit constructor from int is used. 

Such conversion is really confusing. Make it explicitly declared as deleted.",akrzemi1
10241,Please relax template constraints of boost::math::binomial_coefficient,math,Boost 1.55.0,To Be Determined,Feature Requests,John Maddock,new,2014-07-24T15:46:22Z,2014-07-24T15:46:22Z,"boost::math::binomial_coefficient may up to now only be used with floating point types. See also ticket #3100.

This constraint has two problems:

It yields in inaccurate calculations, i. e.
{{{
static_cast<long long unsigned>(boost::math::binomial_coefficient<double>(60, 30));
}}}
is
118264581564861408
but should be
118264581564861424.
(long long unsigned and double are both 8 byte on my machine.)

And it does not make sense for very large or arbitrary-precision integer types: boost::math::binomial_coefficient<boost::multiprecision::cpp_int> would work great if you let it do so.

At the moment it is not possible just to release integer types as template argument, you have to add an extra implementation, i. e. this one with unsigned k and n as input:
{{{
Inttype result = 1;
k = std::min(k, n-k);
for (unsigned i = 1; i < k+1; ++i)
{
	result *= Inttype(n-k+i);
	result /= Inttype(i);
}
}}}",der-storch-85@…
10240,Start tags in XML files are not checked,serialization,Boost 1.55.0,To Be Determined,Bugs,Robert Ramey,reopened,2014-07-24T14:25:36Z,2015-01-13T09:10:37Z,"The exception boost::archive::xml_archive_exception::xml_archive_tag_mismatch is only thrown when end tag is wrong, start tag may be anything.

See attached example:
{{{
<seriobject class_id=""0"" tracking_level=""0"" version=""0"">
	<mem>12</mem>
</seriobject>
}}}
is desired,
{{{
<mem>12</faulty>
}}}
is wrong and noticed as invalid, but
{{{
<faulty>12</mem>
}}}
is valid, should be invalid, too.

Furthermore, in this special example, if you change the end tag of the root node (here: seriobject) to something else, there is also an exception missing.",staehr@…
10235,a strange problem for deadline_timer,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-07-23T16:15:22Z,2014-07-23T16:15:22Z,"os:cent os 6.4 32bit.
boost:1.55.0

I have these codes for tcp async_connect:
session->tcp_socket().async_connect(ep, m_strand.wrap(boost::bind(
	&ifstiotcp::_connected,	this, session, boost::asio::placeholders::error)));

timer.expires_from_now(boost::posix_time::seconds(5), ec);
timer.async_wait(m_strand.wrap(boost::bind(&ifstiotcp::_connect_timeout, this, session, boost::asio::placeholders::error)));

and, in _connected function to cancel timer:
timer.cancel(ec);

and, in _connected_timeout function:
if (boost::asio::error::operation_aborted != ec) {
    // timeout in here
}

now, a strange problem as follows:
1) when run to _connected function and cancel deadline_timer success;
2) after 5 seconds, run the 'timeout in here';
3) anyone has the same problem?",cchehewo <china.ygw@…>
10233,create_directories causes invalid read,filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-07-23T13:48:27Z,2017-12-01T07:07:32Z,"The following code, when run under Valgrind, will report two instances of invalid reads during program close (after main).

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

{{{
#include <stdlib.h>
#include <boost/filesystem.hpp>

int main()
{
	system(""rm -rf /tmp/test""); // make sure directory doesn't already exist
	boost::filesystem::create_directories(""/tmp/test"");
	return 0;
}
}}}
",Itay C <itay.chamiel@…>
10227,Missing HAVE_SONAME causes SONAME to be omitted in qcc.jam,build,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2014-07-23T03:19:45Z,2014-07-23T03:19:45Z,"In the ""actions link.dll bind LIBRARIES"" section of qcc.jam (lines 233-238), the link command includes the following arguments:

{{{
$(HAVE_SONAME)-Wl,-h$(SPACE)-Wl,$(<[1]:D=)
}}}

But, ""HAVE_SONAME"" is never defined in qcc.jam. Resulting in SONAME not getting added to the shared object. Subsequently, boost libraries that link against each other (thread) hardcode the relative path to the dependent library.

Adding 'HAVE_SONAME = """" ;' or removeing ""$(HAVE_SONAME)"" from qcc.jam fixes the issue.

Tested on Windows using the cross-compiler and on QNX in a virtual machine.


Note: I stumbled upon several postings on the mailing list that hint at this happening but all seem to have gone unresolved.",amourdezombi@…
10226,[interprocess] undocumented : size_type,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-07-23T03:19:08Z,2014-07-23T03:19:08Z,"In `basic_managed_mapped_file` class page, `size_type` is undocumented.

http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/basic_managed_mapped_file.html

I think should add follow:

{{{
typedef implementation-defined size_type;
}}}
",Akira Takahashi <faithandbrave@…>
10225,Boost iostreams should use BOOST_TRY/CATCH instead of std try/catch.,iostreams,Boost 1.56.0,To Be Determined,Tasks,Jonathan Turkanis,new,2014-07-22T11:38:29Z,2014-07-22T11:38:29Z,"In order to reduce code size (this is very significant for embedded systems), Boost iostreams should support BOOST_EXCEPTION_DISABLE and BOOST_NO_RTTI configuration macros.",Denys Yurchenko <magnetrom@…>
10224,[property map] compilation error : make_function_property_map,property_map,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2014-07-22T11:02:02Z,2014-07-22T11:02:02Z,"`make_function_property_map()` function can not apply function pointer.

{{{
#include <boost/property_map/function_property_map.hpp>

int get_prop(double) { return 1; }

struct get_prop_functor {
    typedef int result_type;

    result_type operator()(double) const
    { return 1; }
};

int main()
{
    const auto p1 = boost::make_function_property_map<double>(get_prop); // compilation error
    const auto p2 = boost::make_function_property_map<double>(get_prop_functor()); // OK
}
}}}

error message (with gcc 4.8)

{{{
/Users/hogehoge/language/cpp/main.cpp: In function 'int main()':
/Users/hogehoge/language/cpp/main.cpp:14:71: error: no matching function for call to 'make_function_property_map(int (&)(double))'
     const auto p1 = boost::make_function_property_map<double>(get_prop); // compilation error
                                                                       ^
/Users/hogehoge/language/cpp/main.cpp:14:71: note: candidates are:
In file included from /Users/hogehoge/language/cpp/main.cpp:1:0:
/Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:54:1: note: template<class Key, class Func> boost::function_property_map<Func, Key> boost::make_function_property_map(const Func&)
 make_function_property_map(const Func& f) {
 ^
/Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:54:1: note:   template argument deduction/substitution failed:
/Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp: In substitution of 'template<class Key, class Func> boost::function_property_map<Func, Key> boost::make_function_property_map(const Func&) [with Key = double; Func = int(double)]':
/Users/hogehoge/language/cpp/main.cpp:14:71:   required from here
/Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:54:1: error: function returning a function
/Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:60:1: note: template<class Key, class Ret, class Func> boost::function_property_map<Func, Key, Ret> boost::make_function_property_map(const Func&)
 make_function_property_map(const Func& f) {
 ^
/Users/hogehoge/repository/GitHub/boost-develop/boost/property_map/function_property_map.hpp:60:1: note:   template argument deduction/substitution failed:
/Users/hogehoge/language/cpp/main.cpp:14:71: note:   couldn't deduce template parameter 'Ret'
     const auto p1 = boost::make_function_property_map<double>(get_prop); // compilation error
}}}

I think should remove `const &` from parameter.

before:
{{{
template<typename Key, typename Func>
function_property_map<Func, Key>
make_function_property_map(const Func& f) {
  return function_property_map<Func, Key>(f);
}

template<typename Key, typename Ret, typename Func>
function_property_map<Func, Key, Ret>
make_function_property_map(const Func& f) {
  return function_property_map<Func, Key, Ret>(f);
}
}}}

after:
{{{
template<typename Key, typename Func>
function_property_map<Func, Key>
make_function_property_map(Func f) {
  return function_property_map<Func, Key>(f);
}

template<typename Key, typename Ret, typename Func>
function_property_map<Func, Key, Ret>
make_function_property_map(Func f) {
  return function_property_map<Func, Key, Ret>(f);
}
}}}",Akira Takahashi <faithandbrave@…>
10223,Destructor of boost::mpi::environment should not throw exception,mpi,Boost 1.47.0,To Be Determined,Bugs,Matthias Troyer,new,2014-07-22T01:41:31Z,2014-07-22T01:41:31Z,"The destructor of boost::mpi::environment uses the BOOST_MPI_CHECK_RESULT macro to invoke MPI_Finalize.

BOOST_MPI_CHECK_RESULT(MPI_Finalize, ());

If MPI_Finalize does not return MPI_SUCCESS, the macro will throw boost::mpi::exception. However, it is not a good idea for a destructor to throw.


I suggest the destructor just call MPI_Finalize() without using the MACRO",anonymous
10222,root map not correctly computed by strong_components,graph,Boost 1.56.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-07-21T19:52:23Z,2014-07-23T11:16:22Z,"
I think in boost::graph strong_components does not compute the root map as claimed in the documentation, i.e., that it maps each vertex to the  root of the corresponding scc.

For a counter-example consider the following graph (attached as a MWE):

  a <-> b <-> c

Suppose the algorithm starts with node a. The protocol of the algorithm is as follows, the first column being the discovery time, the second being the content of the root map, and * indicating uninitialized values:

1) a -> (0, a), b -> (*, *), c -> (*, *)  // discovered a

2) a -> (0, a), b -> (1, b), c -> (*, *)  // discovered b

3) a -> (0, a), b -> (1, b), c -> (2, c)  // discovered c

4) a -> (0, a), b -> (1, b), c -> (1, b)  // finished c

5) a -> (0, a), b -> (0, b), c -> (1, b)  // finished b

6) a -> (0, a), b -> (0, a), c -> (1, b)  // finished a

The value of the root map for c is 1, correct would be 0.

The output of the example is as follows:[[BR]]
The example graph:[[BR]]
a --> b [[BR]]
b --> a c [[BR]]
c --> b [[BR]]
[[BR]]
Vertex a is in component 0 and has root 0[[BR]]
Vertex b is in component 0 and has root 0[[BR]]
Vertex c is in component 0 and has root 1[[BR]]
",Alex <alxlaus@…>
10214,robust interprocess mutex enhancments proposal,interprocess,Boost 1.55.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-07-18T07:37:36Z,2014-07-18T07:37:36Z,"As we discus with '''Ion Gaztanaga''', I post here my proposal for future enhancements of '''robust interprocess mutex'''.

there is code posted on : codereview.stackexchange.com
with question :  questions/57083/portable-c-boostiterprocessmutex-an-another-try

I'll follow also '''Niall Douglas''' considerations about use timestamp.


Ladislav.",lsopko@…
10213,Reproducible crash with Boost Asio and io_service::post,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-07-18T00:31:30Z,2017-09-21T11:18:54Z,"On OSX, running the following code repeatedly results in an occasional crash with the stack trace following. Unfortunately, I can't find a workaround nor a fix since I don't actually understand why it is crashing...

{{{#!c++
  using namespace boost::asio;

  io_service service;
  io_service::work work(service);
  boost::thread thread{[&](){
      service.reset();
      service.run();
    }
  };
  service.post([&service](){service.stop();});
  thread.join();
}}}

{{{
Error: signal 11:
0   KimiTestApp                         0x0000000105534a02 _Z7handleri + 34
1   libsystem_platform.dylib            0x00007fff97a075aa _sigtramp + 26
2   KimiTestApp                         0x00000001054f154d _ZN5boost6detail12shared_countD2Ev + 45
3   libsystem_pthread.dylib             0x00007fff9665691e _pthread_cond_signal + 612
4   KimiTestApp                         0x0000000105642c43 _ZN5boost4asio6detail11posix_event17signal_and_unlockINS1_11scoped_lockINS1_11posix_mutexEEEEEvRT_ + 115
5   KimiTestApp                         0x0000000105642ab4 _ZN5boost4asio6detail15task_io_service31wake_one_idle_thread_and_unlockERNS1_11scoped_lockINS1_11posix_mutexEEE + 100
6   KimiTestApp                         0x000000010564293f _ZN5boost4asio6detail15task_io_service26wake_one_thread_and_unlockERNS1_11scoped_lockINS1_11posix_mutexEEE + 47
7   KimiTestApp                         0x000000010564247e _ZN5boost4asio6detail15task_io_service25post_immediate_completionEPNS1_25task_io_service_operationEb + 206
8   KimiTestApp                         0x000000010564002e _ZN5boost4asio6detail15task_io_service4postIZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEvE3$_0EEvRT_ + 190
9   KimiTestApp                         0x000000010563ff24 _ZN5boost4asio10io_service4postIZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEvE3$_0EENS0_12async_resultINS0_12handler_typeIT_FvvEE4typeEE4typeEOS7_ + 68
10  KimiTestApp                         0x000000010563fded _ZN42GlobalTestModule_TestNoOpDieImmediate_Test8TestBodyEv + 125
}}}",boost-bugs@…
10212,Don't protect calls to SSL_accept by a static mutex,asio,Boost 1.54.0,To Be Determined,Patches,chris_kohlhoff,new,2014-07-17T15:11:27Z,2016-03-07T12:05:53Z,"Since this commit:
commit ad1c1008321e9b14779816ae19dfaa261c2de293
Author: Christopher Kohlhoff <chris@kohlhoff.com>
Date:   Fri Mar 18 00:25:54 2011 +0000

    New SSL implementation.


    [SVN r70096]

calls to SSL_connect are not protected by ssl_mutex_, but calls to SSL_accept are wrapped by a lock.

I have a http/websocket server application which is extremelly slow in processing requests over a secured connection (about 700 RPS). Under peak load (3K RPS) all threads are waiting for the mutex (for example, 10 threads which are calling to io_service::run()).

For every instance of io_service I use a single ssl_context.

I'm uploading a patch I use to solve this problem. I have tested it under load for 5-6 months and I have no problems with using SSL_accept without this mutex so I propose the patch.",Sergei Nikishin <nordsturm@…>
10207,graph/kamada_kawai: fix matrix size of 3-dimensional linear solver,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-07-16T17:19:09Z,2014-07-16T17:19:09Z,The input matrix for the template instantiation of the 3 dimensional linear solver is of the wrong size. The attached patch fixes this.,totto@…
10206,graph/kamada_kawai: remove calculation of unused debug variable E,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-07-16T17:10:19Z,2016-08-09T09:10:46Z,"The debugging output, which was removed in <https://svn.boost.org/trac/boost/ticket/6239>, printed the variable E.

The calculation of of this variable E remained in the code. The attached patch removes this.",totto@…
10205,FileSystem runtime error: locale::facet::_S_create_c_locale name not valid,filesystem,Boost 1.55.0,Boost 1.57.0,Bugs,Beman Dawes,assigned,2014-07-16T11:59:58Z,2014-10-29T15:18:26Z,"Ok this is still broken (see Ticket #5928). On Solaris 10 (sparc) compile this...

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

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

linking against system and filesystem

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

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

Below are the results...

bash-3.2$ locale
LANG=en_GB.UTF-8
LC_CTYPE=en_GB.ISO8859-1
LC_NUMERIC=en_GB.ISO8859-1
LC_TIME=en_GB.ISO8859-1
LC_COLLATE=en_GB.ISO8859-1
LC_MONETARY=en_GB.ISO8859-1
LC_MESSAGES=C
LC_ALL=
-bash-3.2$ LC_ALL=en_GB.UTF-8  LD_LIBRARY_PATH=. ./a.out
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Abort (core dumped)
-bash-3.2$ LD_LIBRARY_PATH=. ./a.out
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Abort (core dumped)
-bash-3.2$ LC_ALL=en_GB.ISO8859-1  LD_LIBRARY_PATH=. ./a.out
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Abort (core dumped)
-bash-3.2$ LC_ALL=C  LD_LIBRARY_PATH=. ./a.out
/some/random/path/7fff459


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

",sleary@…
10199,"When requested mpi threading level cannot be provided, some sort of error should be reported",mpi,Boost 1.55.0,To Be Determined,Feature Requests,Matthias Troyer,new,2014-07-15T18:17:53Z,2014-07-15T18:17:53Z,"When mpi::environment requests a threading level with one of the constructors:

{{{
explicit environment(threading::level, bool = true);
environment(int &, char **&, threading::level, bool = true);
}}}

there is no guarantee that the requested threading level is actually available.  Boost::mpi receives the actual threading level provided, but ignores it.

Instead, I suggest that an exception should be thrown when the provided level of threading support is less than requested.  This would, for example, catch the common scenario where the MPI library was only compiled for single-threaded programs.",ClaytonGDavis@…
10198,current_exception_diagnostic_information() returns empty string if verbose is false,exception,Boost 1.55.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-07-15T07:16:11Z,2014-07-15T07:16:11Z,,Eugene Ryabtsev <eugene.ryabtsev@…>
10195,Silent Failure for boost::geometry::intersection(),geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-07-14T19:08:42Z,2014-07-14T19:08:42Z,"I am performing intersections between polygons, with points represented using 64-bit integer coordinates. If I use signed ints (int64_t), the intersection operations are correct. If I use unsigned ints (uint64_t), the returned intersection polygon collection is simply one of the two polygons I originally handed in.

The underlying intersection algorithm must require signed information, but this fact is not communicated to users. As a result, the output of unsigned int operations can appear nonsensical. Added documentation is appreciated. Adding an actual exception when attempting to do unsigned-int-based intersections would be even better.",anonymous
10194,basic_xml_grammar<wchar_t> parses class_id failed,serialization,Boost 1.54.0,To Be Determined,Bugs,Robert Ramey,new,2014-07-14T16:02:00Z,2014-12-05T04:19:17Z,"I found this issue when I used xml wserialization to save config in polymorphic case. After debugging, I found basic_xml_grammar<wchar_t> failed to parse ""class_id"" under some conditions. There are some info for this issue:
1. Compile with NDEBUG, without NDEBUG no this issue.
2. basic_xml_grammar<char> works fine.
3. Compile with GCC (when compile with VS2010, no this issue)
Detail of GCC:
gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)

I trimmed the test code:

#include <boost/archive/impl/basic_xml_grammar.hpp>
#include <fstream>
#include <iostream>

using namespace boost::archive;


int main()
{
    std::wifstream ifs(""./dashboard.xml"");

    if (ifs) {
        basic_xml_grammar<wchar_t> xmlGrammer;
        xmlGrammer.parse_start_tag(ifs);

        std::wcout << ""rv.class_id="" << xmlGrammer.rv.class_id << std::endl;
    }
    else {
        std::cout << ""File doesn't exist."" << std::endl;
    }

    return 0;
}

and the dashboard.xml is very simple with only one line:
<item class_id=""4"" class_name=""ComponentDataChart"" tracking_level=""1"" version=""4"" object_id=""_3"">",Andrew Xu <xulei.js@…>
10188,Loses floating point precision on round trip,property_tree,Boost Development Trunk,To Be Determined,Bugs,Sebastian Redl,assigned,2014-07-10T13:54:12Z,2015-01-23T12:25:23Z,"ptrees stream_translator uses a precision of std::numeric_limits<F>::digits10 + 1 when converting floating point values.  This is not always enough, and a more correct value would be digits10+2 or max_digits10 (c++11 only). See ticket:9177 for a similar issue.

The attached test produces the following output pre-patch:
{{{
in : -1.8312345000098765e-08
out: -1.8312345000098762e-08
Wrong
}}}

and after patch:
{{{
in : -1.8312345000098765e-08
out: -1.8312345000098765e-08
Right
}}}",Magne OEstlyngen <magne+boost@…>
10181,Typo in Boost Pool Docs,pool,Boost 1.54.0,To Be Determined,Bugs,Chris Newbold,new,2014-07-07T09:01:21Z,2014-07-07T09:03:16Z,"http://www.boost.org/doc/libs/1_55_0/libs/pool/doc/html/boost_pool/pool/interfaces.html

""An ordered pool maintains it's free list""

should be

""An ordered pool maintains its free list""",Q309185@…
10180,shared_memory_object assertion when used with boost unit test,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-07-07T05:00:56Z,2014-07-30T15:02:21Z,"I am running with Visual Studio 2010, and boost 1.55.
When I run a simple unit test with shared_memory_object, I get an assertion on shutdown.
The test itself creates a shared memory object, maps it to memory, and writes to it; it then opens a shared memory object of the same name and reads from it. This works fine.

On exit, the fini_atomic_func functor in intermodule_singleton_common is run to clean up. This does the following:
{{{
         ref_count_ptr *rcount = intermodule_singleton_helpers::thread_safe_global_map_dependant
         <ThreadSafeGlobalMap>::find(m_map, typeid(C).name());
         //The object must exist
         BOOST_ASSERT(rcount);
}}}
The assertion fails. In the debugger I can see that typeid(C).name() has returned a rubbish string, and therefore no map entry is found. When that same code is executed in init_atomic_func, typeid(C).name() returns ""struct boost::interprocess::ipcdetail::windows_bootstamp"" as expected.
Following the relevant memory address in the debugger, I see that the typeid string is erased in the unit test's framework::shutdown() function. This is done deliberately to eliminate fake memory leak reports from the typeid strings. See boost\test\impl\framework.ipp.

Unfortunately the interprocess cleanup is done via a handler registered with std::atexit, which guarantees it will be after framework has run shutdown. I don't see any options on either side (boost unit test or boost interprocess) which would allow the order to be fixed up.

Simplest code to reproduce:
{{{
#include <boost/test/unit_test.hpp>
#include <boost/interprocess/shared_memory_object.hpp>
namespace IP = boost::interprocess;

BOOST_AUTO_TEST_SUITE( TestSharedMemory )
BOOST_AUTO_TEST_CASE( CauseAssertionFailure )
{
   IP::shared_memory_object lShared( IP::open_only, ""test_string"", IP::read_only );
   BOOST_REQUIRE( lShared.get_name() != 0 );
}
BOOST_AUTO_TEST_SUITE_END()
}}}",andrew.lang@…
10175,Integrating build asio as a library into the boost build system,asio,Boost 1.55.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-07-03T00:08:11Z,2014-07-03T00:08:11Z,"It would be nice if the boost build system had an option ""--with-asio"" to build asio as a shared library.

Yes, it's possible to build it manually, but it would be better to be able to build it like the rest of the boost libraries.

In fact, there's at least one scenario where proper behavior isn't acheived unless it's built as a shared library.  See #10174.",Wade Berrier <wberrier@…>
10174,call_stack not working when building asio as shared module on windows,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-07-02T23:57:38Z,2016-02-02T00:46:27Z,"The call_stack is not working when building asio as shared module on windows.

Also, the call_stack doesn't work on windows when using asio as header only and loading a dll at runtime (ie: LoadLibrary) which is also using asio as header only.

See and run the attached test case that demonstrates the problem in the following scenario:

* MSVC 2010 Express SP1 32bit (I'm guessing it's an issue on other compilers as well, but this is what I was using)
* build asio as a shared library according to instructions for ""separate compilation"" [ 1 ]
* build and run the test case, where all cases should say ""PASS""

Now, I know the documentation says that .dispatch() *may* execute the handler right away (see discussion[ 2 ] on mailing list), so it's officially not a bug.

BUT, I noticed that ""strand.running_in_this_thread()"" worked.  That's what clued me in that call_stack was working as expected for running_in_this_thread(), but not for dispatch().

It appears that the issue is with static storage for boost::asio::detail::callstack::top_ .

It appears that two copies of this static storage item are being referenced: one from the .exe file, and one from the .dll (both of which include the asio headers).

It looks like the reason ""running_in_this_thread()"" works is because it calls callstack<>::contains() from an .ipp file, which is included in the .dll so it references top_ from the .dll.

In the case of using asio as header only, not running any asio code from a .dll, the issue is non-existent.  There is no confusion as to which top_ variable to use.

See the attached patch to asio/detail/impl/strand_service.hpp that fixes strand.dispatch() by calling ""running_in_this_thread()"".  That forces the reference of top_ from the .dll instead of the reference from the .exe that's linked against the asio dll or another .dll that includes asio headers.

Possible fixes for this:
1. put the definition of top_ in an .ipp file to include in the boost asio .dll so there's only one symbol for it.
2. put all usages of call_stack in .ipp files (similar to the attached patch) so there's no confusion about the symbol (ugly and error prone, since it would have to be done for all use cases)

It should be noted that in order for call_stack to work across a dll boundary (ie: sharing io_service or strand between a .exe and .dll), asio *must* be built as a shared library.

Also, note that this only happens on Windows.  Doing the equivalent with .so files works in Linux (maybe by chance?  not sure...).

Not having this fix makes .dispatch() pretty much useless when using asio on windows with .dlls.

",wberrier@…
10170,adding keys to context without file,asio,Boost 1.54.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-07-02T07:31:48Z,2014-07-02T07:31:48Z,"The boost::asio::ssl::context class should have a way to add keys, without a file name. Because sometimes it is necessary to use keys that are already loaded into the program and are stored in a variable ( for example: char *).",anonymous
10167,Wide char tests fail with input stream error on QNX,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,new,2014-07-01T20:54:52Z,2014-07-02T17:05:21Z,"All of the warchive tests have been failing with ""input stream error"" on QNX 6.5.0 (x86) since forever (http://lists.boost.org/boost-testing/2010/10/6697.php).

I finally got around to debugging the issue. test_complex_text_warchive successsfully loads the file signature (""22 serialization::archive""), then the stream indicates failure when the library attempts to read library_version_type from the stream.

Text of archive:
{{{
22 serialization::archive 11 5.77390790e-01 2.92427921e+00 3.10149615851192895e+00 5.51821574551270633e+00
}}}

Hex dump of archive:
{{{
0000000 32 00 00 00 32 00 00 00 20 00 00 00 73 00 00 00 2...2.......s...
0000010 65 00 00 00 72 00 00 00 69 00 00 00 61 00 00 00 e...r...i...a...
0000020 6c 00 00 00 69 00 00 00 7a 00 00 00 61 00 00 00 l...i...z...a...
0000030 74 00 00 00 69 00 00 00 6f 00 00 00 6e 00 00 00 t...i...o...n...
0000040 3a 00 00 00 3a 00 00 00 61 00 00 00 72 00 00 00 :...:...a...r...
0000050 63 00 00 00 68 00 00 00 69 00 00 00 76 00 00 00 c...h...i...v...
0000060 65 00 00 00 20 00 00 00 31 00 00 00 31 00 00 00 e.......1...1...
0000070 20 00 00 00 35 00 00 00 2e 00 00 00 37 00 00 00 ....5.......7...
0000080 37 00 00 00 33 00 00 00 39 00 00 00 30 00 00 00 7...3...9...0...
0000090 37 00 00 00 39 00 00 00 30 00 00 00 65 00 00 00 7...9...0...e...
00000A0 2d 00 00 00 30 00 00 00 31 00 00 00 20 00 00 00 -...0...1.......
00000B0 32 00 00 00 2e 00 00 00 39 00 00 00 32 00 00 00 2.......9...2...
00000C0 34 00 00 00 32 00 00 00 37 00 00 00 39 00 00 00 4...2...7...9...
00000D0 32 00 00 00 31 00 00 00 65 00 00 00 2b 00 00 00 2...1...e...+...
00000E0 30 00 00 00 30 00 00 00 20 00 00 00 33 00 00 00 0...0.......3...
00000F0 2e 00 00 00 31 00 00 00 30 00 00 00 31 00 00 00 ....1...0...1...
0000100 34 00 00 00 39 00 00 00 36 00 00 00 31 00 00 00 4...9...6...1...
0000110 35 00 00 00 38 00 00 00 35 00 00 00 31 00 00 00 5...8...5...1...
0000120 31 00 00 00 39 00 00 00 32 00 00 00 38 00 00 00 1...9...2...8...
0000130 39 00 00 00 35 00 00 00 65 00 00 00 2b 00 00 00 9...5...e...+...
0000140 30 00 00 00 30 00 00 00 20 00 00 00 35 00 00 00 0...0.......5...
0000150 2e 00 00 00 35 00 00 00 31 00 00 00 38 00 00 00 ....5...1...8...
0000160 32 00 00 00 31 00 00 00 35 00 00 00 37 00 00 00 2...1...5...7...
0000170 34 00 00 00 35 00 00 00 35 00 00 00 31 00 00 00 4...5...5...1...
0000180 32 00 00 00 37 00 00 00 30 00 00 00 36 00 00 00 2...7...0...6...
0000190 33 00 00 00 33 00 00 00 65 00 00 00 2b 00 00 00 3...3...e...+...
00001A0 30 00 00 00 30 00 00 00 0a 00 00 00             0...0.......
00001AC
}}}

Stack trace from the failure point (!#2):
{{{
#0  __cxa_throw (obj=0x809de30, tinfo=0x8074888, dest=0x80713ba <boost::archive::archive_exception::~archive_exception()>) at ../../../../../libstdc++-v3/libsupc++/unwind-cxx.h:234
#1  0x0805bb05 in boost::serialization::throw_exception<boost::archive::archive_exception> (e=@0x8047238) at ../../../boost/serialization/throw_exception.hpp:36
#2  0x0806756e in boost::archive::basic_text_iprimitive<std::basic_istream<wchar_t, std::char_traits<wchar_t> > >::load<boost::archive::library_version_type> (this=0x8047704, t=@0x8047406)
    at ../../../boost/archive/basic_text_iprimitive.hpp:86
#3  0x080674f3 in boost::archive::text_wiarchive_impl<boost::archive::text_wiarchive>::load<boost::archive::library_version_type> (this=0x80476f0, t=@0x8047406) at ../../../boost/archive/text_wiarchive.hpp:67
#4  0x080674bb in boost::archive::load_access::load_primitive<boost::archive::text_wiarchive, boost::archive::library_version_type> (ar=@0x80476f0, t=@0x8047406) at ../../../boost/archive/detail/iserializer.hpp:103
#5  0x0806747d in boost::archive::detail::load_non_pointer_type<boost::archive::text_wiarchive>::load_primitive::invoke<boost::archive::library_version_type> (ar=@0x80476f0, t=@0x8047406)
    at ../../../boost/archive/detail/iserializer.hpp:385
#6  0x08067417 in boost::archive::detail::load_non_pointer_type<boost::archive::text_wiarchive>::invoke<boost::archive::library_version_type> (ar=@0x80476f0, t=@0x8047406)
    at ../../../boost/archive/detail/iserializer.hpp:462
#7  0x0806732a in boost::archive::load<boost::archive::text_wiarchive, boost::archive::library_version_type> (ar=@0x80476f0, t=@0x8047406) at ../../../boost/archive/detail/iserializer.hpp:618
#8  0x0806722a in boost::archive::detail::common_iarchive<boost::archive::text_wiarchive>::load_override<boost::archive::library_version_type> (this=0x80476f0, t=@0x8047406)
    at ../../../boost/archive/detail/common_iarchive.hpp:66
#9  0x08067134 in boost::archive::basic_text_iarchive<boost::archive::text_wiarchive>::load_override<boost::archive::library_version_type> (this=0x80476f0, t=@0x8047406)
    at ../../../boost/archive/basic_text_iarchive.hpp:71
#10 0x08067034 in boost::archive::text_wiarchive_impl<boost::archive::text_wiarchive>::load_override<boost::archive::library_version_type> (this=0x80476f0, t=@0x8047406) at ../../../boost/archive/text_wiarchive.hpp:95
#11 0x08066dbe in boost::archive::detail::interface_iarchive<boost::archive::text_wiarchive>::operator>><boost::archive::library_version_type> (this=0x80476f0, t=@0x8047406)
    at ../../../boost/archive/detail/interface_iarchive.hpp:60
#12 0x08066945 in boost::archive::basic_text_iarchive<boost::archive::text_wiarchive>::init (this=0x80476f0) at ../../../boost/archive/impl/basic_text_iarchive.ipp:60
#13 0x080665e7 in boost::archive::text_wiarchive_impl<boost::archive::text_wiarchive>::text_wiarchive_impl (this=0x80476f0, is=@0x80475e0, flags=0) at ../../../boost/archive/impl/text_wiarchive_impl.ipp:112
#14 0x0804f341 in boost::archive::text_wiarchive::text_wiarchive (this=0x80476f0, is=@0x80475e0, flags=0) at ../../../boost/archive/text_wiarchive.hpp:123
#15 0x0804d3a5 in test_main () at test_complex.cpp:64
#16 0x0804d03d in main (argc=1, argv=0x8047840) at test_tools.hpp:203
}}}

This was done with code from the develop branch earlier today:[[br]]
Boost commit 31c60438c5a27ae6d956d01db76e7d84a01b8b2b[[br]]
Serialization commit d9121537826a4e4e9a378c43818bd9b7d5f3a9bd

I noticed that the code that reads the signature string manually skips the space between the length and the actual string. If I remove the space after the signature from the file, it successfully loads library_version_type but then fails when trying to read the first float. So it appears as if the problem has something to do with the spaces between values.

Suggestions?
",Niklas Angare <li51ckf02@…>
10163,Boost.Signal2 performs too many locks in a multi-threaded environment where the life cycle of the source and target are the duration of the program,signals2,Boost 1.54.0,To Be Determined,Bugs,Frank Mori Hess,new,2014-06-30T19:31:50Z,2014-06-30T19:31:50Z,"Boost.Signal2 requires that the receiver be a shared_ptr, or a weak_ptr.

If the life cycle of the receiver is the length of the program (ie, created rather than new'ed as a global object), there is no need to reference count the pointer.  On Linux/X86_64, the act of making it a shared pointer (to protect it from going away underneath us) causes an atomic increment and decrement of the reference counter, which causes high CPU utilization in the atomic lock/unlock when performing lots of signals in parallel across multiple threads.

It would be nice to have a non-shared_ptr interface to eliminate the refrence count bottle neck, as the management of the pointer is higher overhead than actually doing the signal, in many cases.

This was found with a program that has multiple threads signalling very small objects at a very high rate, and looking at the underlying system with both gprof and pprof.  In our test case, 48% of the gprof time was spent in the atomic lock/unlock/test code.

Because of the proprietary nature of our code, I can't attach a sample.",Dave Gotwisner <dgotwisn@…>
10162,ASIO's spawn should accept a stack allocator parameter,asio,Boost 1.55.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-06-30T17:46:23Z,2017-07-07T09:46:42Z,"It is possible to pass coroutine attributes to ""spawn"", but not stack allocators.

Stack allocators are for the moment the only way to have valgrind-aware stacks. Without it, it is nearly impossible to use valgrind as soon as you have a coroutine. So it is quite critical.",vdavid@…
10152,Bimap documentation lacks information on iterator invalidation,bimap,Boost 1.55.0,To Be Determined,Bugs,Matias Capeletto,new,2014-06-25T22:53:02Z,2014-06-25T22:53:02Z,"Bimap in its documentation doesn't mention when iterators are invalidated (if at all). Or at least it doesn't say it explicitly enough.

While it seems that it should and could since it is implemented in terms of MultiIndex while MultiIndex does specify that.

See also thread ""[Bimap] Iterator invalidation"" on gmane.comp.lib.boost.user.",abadura@…
10150,Regression testing can fail if you've modified files,Regression Testing USE GITHUB,Boost Development Trunk,To Be Determined,Bugs,René Rivera,new,2014-06-25T17:00:03Z,2014-06-27T13:21:31Z,"regression.py fails if you have local changes to files that are modified by a new commit, at least if they're under tools_bb. I had a patch_boost that had modified tools_bb/src/tools/testing.jam on the previous run when this occured.

Here's the output:
{{{
# Getting Boost.Build v2...
# Executing GIT command: /extra/boost_regression/ARM/tools_bb> git remote ""set-branches"" ""--add"" ""origin"" ""develop""
# Executing GIT command: /extra/boost_regression/ARM/tools_bb> git pull ""--recurse-submodules""
error: Your local changes to the following files would be overwritten by merge:
        src/tools/testing.jam
Please, commit your changes or stash them before you can merge.
Aborting
Updating 59fd3b6..708ceaf
}}}

Here's what git status showed:
{{{
On branch develop
Your branch is behind 'origin/develop' by 1 commit, and can be fast-forwarded.
  (use ""git pull"" to update your local branch)

Changes not staged for commit:
  (use ""git add <file>..."" to update what will be committed)
  (use ""git checkout -- <file>..."" to discard changes in working directory)

        modified:   src/tools/testing.jam

Untracked files:
  (use ""git add <file>..."" to include in what will be committed)

        src/tools/testing.jam.rej

no changes added to commit (use ""git add"" and/or ""git commit -a"")
}}}
",Niklas Angare <li51ckf02@…>
10149,boost::optional<T> can be constructed from a typed in place factory of the wrong type,optional,Boost 1.49.0,To Be Determined,Bugs,Fernando Cacciola,new,2014-06-25T16:54:48Z,2016-03-15T12:29:59Z,"For example:

boost::optional<char> oa = boost::in_place<double>(0); // type-checks but results in runtime undefined behavior, placement new of double in a buffer of size char.",aastolfi@…
10146,"Trac detects my bug entry as spam, but there is no 'following' to respond to.",trac / subversion,,To Be Determined,Bugs,Douglas Gregor,new,2014-06-25T14:17:50Z,2014-06-25T14:17:50Z,"Tried submitting another bug report now where Trac detects my input as spam, telling:
{{{
Captcha Error

Submission rejected as potential spam (Content contained 1 blacklisted patterns)

Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following.
}}}
I won't care if I would be able to ""provide a response to the following"", but there is nothing shown where I could enter something.

Thank you!",Michael Haubenwallner <michael.haubenwallner@…>
10145,Win2k8R2 specific: boost::filesystem::is_directory() returns false for a directory under C:\Windows\System32,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-06-25T11:51:11Z,2014-06-25T17:46:53Z,"'filesystem::is_directory()' returns false for a directory with whole bunch of sibling directories. Run the following commands to create 2000 sub-directories:

C:\>mkdir temp_dir
C:\>cd temp_dir
C:\>for /L %i in (1, 1, 2000) do mkdir test_dir_%i
C:\>mkdir test_dir

Now try to execute the following statements under a debugger: 'is_directory()' always returns false.

boost::filesystem::path directory(""C:\\temp_dir\\test_dir"");
bool isDir = boost::filesystem::is_directory(directory);",Martin Ghazaryan <martin.ghazaryan@…>
10142,Range lib type_erased.cpp  needs /bigobj option for mcvc and intel-win,range,Boost 1.54.0,To Be Determined,Bugs,Neil Groves,assigned,2014-06-23T11:37:00Z,2014-08-25T21:12:23Z,"Build of range lib on debug mode fails with msvc and icl on type_erased.cpp file. /bigobj option should be added to Jamfile.v2

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

    call ""C:\Program Files (x86)\microsoft visual studio 12.0\vc\vcvarsall.bat"" x86_amd64 >nul
cl /Zm800 -nologo @""..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj.rsp""

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


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

compilation aborted for adaptor_test/type_erased.cpp (code 4)
",Elmira Semenova <elmira.a.semenova@…>
10129,boost::arg and boost::is_placeholder not documented,bind,Boost 1.56.0,To Be Determined,Bugs,Peter Dimov,new,2014-06-18T07:14:22Z,2014-06-18T07:14:22Z,"Boost.Bind default placeholders (anonymous namespace)`::_1`, (anonymous namespace)`::_2` etc. can be not used either by directly creating objects of type `boost::arg<1>`, `boost::arg<2>` etc. or by resorting to user-defined placeholders properly labelled as such via `boost::_is_placeholder`. This comes handy when `BOOST_BIND_NO_PLACEHOLDERS` is set and in general when the `_1` syntax is not welcome for whatever reason.

The problem is that both `boost::arg<N>` and `boost::is_placeholder` are not documented, i.e. they officially do not exist. This, in particular, renders Boost.Bind effectively unusable when `BOOST_BIND_NO_PLACEHOLDERS` is in effect.

This is a request that these constructs be documented. More info on the subject on

http://lists.boost.org/Archives/boost/2014/03/212333.php",Joaquín M López Muñoz
10127,coordinate_matrix sort() fails on to std::swap,uBLAS,Boost 1.54.0,Boost 1.58.0,Bugs,Gunter,new,2014-06-16T08:56:57Z,2014-11-26T15:16:35Z,"Orginally posted here:

http://stackoverflow.com/questions/24228772/c11-compatibility-of-sparse-matrix-implementations

The following program does not compile with gcc 4.8 or clang 3.4 when --std=c++11 is set:

{{{
#include <boost/numeric/ublas/io.hpp>
#include <boost/numeric/ublas/matrix_sparse.hpp>

using namespace boost::numeric::ublas;

int main(int argc, char** argv) {
  coordinate_matrix<int> m1(100, 100, 100);

  for (int i = 0; i < 100; i++)
    m1.insert_element(i,i,i);

  compressed_matrix<int> m2(m1, 100);
}
}}}

We can solve the issue by providing a swap() routine:

{{{
#include <boost/numeric/ublas/io.hpp>
#include <boost/numeric/ublas/matrix_sparse.hpp>

using namespace boost::numeric::ublas;

namespace std {
    template<class M>
    inline
    void swap (boost::numeric::ublas::index_triple<M> i1, boost::numeric::ublas::index_triple<M> i2) {
        i1.swap (i2);
    }
}


int main(int argc, char** argv) {
  coordinate_matrix<int> m1(100, 100, 100);

  for (int i = 0; i < 100; i++)
    m1.insert_element(i,i,i);
  
  compressed_matrix<int> m2(m1, 100);
}
}}}

I am not an expert C++ template programmer, so I am unable to decide what is the cause here, but the C++ reference on std::sort explicitly mentions a swap() method.",anonymous
10122,Recent Python versions trigger compiler error on AIX when compiling modules/regex.c: conflicting types for 'fgetpos64',build,Boost 1.55.0,To Be Determined,Patches,Vladimir Prus,new,2014-06-13T13:08:43Z,2014-06-13T13:08:43Z,"Since bugs.python.org/issue11184, recent Python releases (like Python-2.7.6) now have proper large-file support for AIX, defining _LARGE_FILES in <pyconfig.h>, exposed to the user via <Python.h>.

Now, bootstrapping boost.build for AIX using such a Python release causes the compiler errors shown in attached files when compiling modules/regex.c.

The problem with modules/regex.c is:
* `modules/regex.c` first includes `""../mem.h""`
* `mem.h` includes `<stdlib.h>` includes `<standards.h>`
Due to nothing relevant being defined yet, `<standards.h>` defines `_LARGE_FILE_API`
* `stdlib.h` includes `<sys/types.h>`
* `sys/types.h` does {`typedef long fpos_t;`}, because `_LARGE_FILES` is not defined
If `_LARGE_FILES` were defined before, `sys/types.h` would have done {`typedef long long fpos_t;`} here.
* `sys/types.h` does {`typedef long long fpos64_t;`} due to `_LARGE_FILE_API` being defined
* `modules/regex.c` includes `""../native.h""` includes `""function.h""` includes `""frames.h""` includes `""lists.h""` includes `<Python.h>` includes [`<pyconfig.h>`, `<stdio.h>`]
* `pyconfig.h` defines `_LARGE_FILES`
* `stdio.h` does not redefine the `fpos_t` things
* `stdio.h` does {`#define fgetpos fgetpos64`} due to `_LARGE_FILES` being defined now
* `stdio.h` declares {`extern int fgetpos(FILE*,fpos_t);`}, but remember `fgetpos` is defined to `fgetpos64`
* `stdio.h` declares {`extern int fgetpos64(FILE*,fpos64_t);`} due to `_LARGE_FILE_API` being defined

This problem is the same for the other functions the compilers yell about.

Also, the same errors occur with current git master.

For the fix:
It is important to have all the ABI specific precompiler macros being defined before including any system header. Actually, the first thing `""jam.h""` does is to include `<Python.h>`. But with `modules/regex.c` first including `""../mem.h""` including `<stdlib.h>`, this rule is not followed. So the fix here is:
{{{
--- a/src/engine/mem.h
+++ b/src/engine/mem.h
@@ -8,6 +8,8 @@
 #ifndef BJAM_MEM_H
 #define BJAM_MEM_H

+#include ""jam.h""
+
 #ifdef OPT_BOEHM_GC

     /* Use Boehm GC memory allocator. */
}}}

While the fix for this very problem is quite simple, it doesn't look like if `<Python.h>` being included first everywhere else in build.git/src/engine is on purpose actually...

Thank you!",Michael Haubenwallner <michael.haubenwallner@…>
10118,boost::interprocess windows_intermodule_singleton crashes when mixing compilers,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-06-12T12:04:12Z,2014-06-12T12:04:12Z,"windows_semaphore_based_map uses an std::map to communicate between modules.  However, the ABI of std::map is different between (for example) VS2008 and VS2012, which means that if a DLL compiled with VS2012 is linked with an application compiled with VS2008, the second module to use the intermodule singleton will crash.

This is essentially the same problem as #9262, but with different compiler versions instead of different build types.

A simple workaround is to comment out
{{{#!cpp
#define BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME
}}}

in `interprocess/detail/workaround.hpp`.",emil.styrke@…
10117,corrupt installer boost_1_55_0-msvc-12.0-64.exe downloaded from sourceforge : 1.55.0-build2,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-06-12T06:35:39Z,2014-06-12T06:35:39Z,installer boost_1_55_0-msvc-12.0-64.exe downloaded from sourceforge : 1.55.0-build2 is corrupt,kilian.singer@…
10115,Documentation for Boost MPI gather(),mpi,Boost Development Trunk,To Be Determined,Bugs,Matthias Troyer,new,2014-06-11T15:32:27Z,2014-06-11T15:32:27Z,"This is the current documentation for gather() [taken from github.com/boostorg/mpi/blob/master/include/boost/mpi/collectives.hpp]:

{{{
/**
 *  @brief Gather the values stored at every process into a vector at
 *  the root process.
 *
 *  @c gather is a collective algorithm that collects the values
 *  stored at each process into a vector of values at the @p root
 *  process. This vector is indexed by the process number that the
 *  value came from. The type @c T of the values may be any type that
 *  is serializable or has an associated MPI data type.
 *
 *  When the type @c T has an associated MPI data type, this routine
 *  invokes @c MPI_Gather to gather the values.
 *
 *    @param comm The communicator over which the gather will occur.
 *
 *    @param in_value The value to be transmitted by each process. For
 *    gathering arrays of values, @c in_values points to storage for
 *    @c n*comm.size() values.
 *
 *    @param out_values A vector or pointer to storage that will be
 *    populated with the values from each process, indexed by the
 *    process ID number. If it is a vector, it will be resized
 *    accordingly. For non-root processes, this parameter may be
 *    omitted. If it is still provided, however, it will be unchanged.
 *
 *    @param root The process ID number that will collect the
 *    values. This value must be the same on all processes.
 */
}}}

Surely the sentence ""@c in_values points to storage for @c n*comm.size() values"" is wrong. in_values only needs to hold n values. However, out_values should have storage for n*comm.size() values on the root process.",Max Gerlach <gerlach@…>
10113,[1.55] no lock-free synchronization on Solaris 10 sparcv9 (sp_counted_base.hpp),lockfree,Boost 1.55.0,To Be Determined,Bugs,timblechmann,new,2014-06-11T11:53:58Z,2016-11-19T15:49:26Z,"I wonder, why lock-free synchronization is not in use on solaris 10 (sparcv9).

E.g. check with http://www.boost.org/doc/libs/1_53_0/doc/html/lockfree/examples.html

When i build boost 1.55 with gcc-4.7.2, then i get for 
> ./b2
[...]
  - lockfree boost::atomic_flag : no  

But there seems to be some support for cas32 (e.g.) in ./include/boost/smart_ptr/detail/...

But in ./include/boost/smart_ptr/detail/sp_counted_base.hpp there is in the sequence of #if...#elif...#else...#endif is:

{{{
[...]
#elif defined( __GNUC__ ) && ( defined( __mips__ ) || defined( _mips ) ) && !defined(__PATHSCALE__)
# include <boost/smart_ptr/detail/sp_counted_base_gcc_mips.hpp>

#elif defined( BOOST_SP_HAS_SYNC )
# include <boost/smart_ptr/detail/sp_counted_base_sync.hpp>

#elif defined(__GNUC__) && ( defined( __sparcv9 ) || ( defined( __sparcv8 ) && ( __GNUC__ * 100 + __GNUC_MINOR__ >= 402 ) ) )
# include <boost/smart_ptr/detail/sp_counted_base_gcc_sparc.hpp>
[...]
}}}

I.e. BOOST_SP_HAS_SYNC is preferred.

Is this correct?

- many thanks!

best regards,

Frank
",anonymous
10112,improved shared_ptr visualizer and weak_ptr,smart_ptr,Boost 1.54.0,To Be Determined,Feature Requests,fkonvick,new,2014-06-11T10:39:45Z,2015-02-13T18:36:55Z,"I was trying out the boost::shared_ptr visualizer for Visual Studio 2010, here https://svn.boost.org/svn/boost/sandbox/boost_docs/subprojects/DebuggerVisualizers/shared_ptr.vis.txt

It's ok, but it doesn't show very much. The typical display is:

shared_ptr {...} count = ...

While experimenting with the visualizer, I made several observations:

1) If you view a pointer rather than a dereferenced pointer, you see both the address (which is useful) and more content in the referenced object (which is very useful)

2) Our normal use of shared_ptr is as a pointer. The usage count is not normally something we want to know about. By removing the text formatting, and only showing the pointer in the preview, we see far more content in the referenced object (even more useful)

3) The children are displayed in alphabetic order. It's most useful to be able to see and expand ""ptr"" in the children. Renaming ""count"" to ""use_count"" puts ""ptr"" at the top, where it belongs.

4) weak_ptr can be visualized the same way.

An example boost::shared_ptr is now previewed as:

0x18467058 {parent_bond_=0x184546e0 {type_={...} polymeric_=false annotations_={...} ...} mol_=0x18448768 {m_=0x1246c5ac {impl_={...} annotations_={...} } impl_={...} proxy_atom_creator_={...} ...} graphic_properties_=0x00000000 }

{{{
;------------------------------------------------------------------------------
;  boost::shared_ptr
;------------------------------------------------------------------------------

boost::shared_ptr<*>{
	preview
	( 
		($T1 *)$c.px
	)
	children
	( 
		#( 
			ptr: (($T1 *)$c.px) ,
			use_count: $c.pn.pi_->use_count_ ,
			weak_count: $c.pn.pi_->weak_count_
		)
	)
}

;------------------------------------------------------------------------------
;  boost::weak_ptr
;------------------------------------------------------------------------------

boost::weak_ptr<*>{
	preview
	( 
		($T1 *)$c.px
	)
	children
	( 
		#( 
			ptr: (($T1 *)$c.px) ,
			use_count: $c.pn.pi_->use_count_ ,
			weak_count: $c.pn.pi_->weak_count_
		)
	)
}
}}}",murray read at ccdc
10110,boost::random::negative_binomial_distribution unnecessary restriction to IntType for parameter k,random,Boost 1.55.0,To Be Determined,Bugs,No-Maintainer,new,2014-06-10T20:23:13Z,2015-03-11T08:28:41Z,"Hi.

In the implementation of boost::random::negative_binomial_distribution there is an unnecessary restriction to IntType for parameter k.

A double parameter k will be casted to integer resulting in a different distribution than desired. If one compiles with -Wconversion a warning is given:
warning: conversion to ‘int’ from ‘double’ may alter its value [-Wconversion]
see attached example_file.
This can lead to unwanted realization of a negative binomial distribution for non integer parameters k.

Further there are no assertion checks on the parameters in instantiating a boost::random::negative_binomial_distribution object. These assertions are checked during the sampling process via boost::random::gamma_distribution.
There (and in general for negative binomial distribution) the parameter k must be strictly greater than zero and not as mentioned in the documentation ""Requires: k >=0"".

This can easily be extended by changing IntType to RealType in 5 occurrences regarding the parameter k.

Thank you,
Max

P.S.: I compiled the example file with:
g++ -Wconversion -o negbin_test -std=c++11 negbin_test.cpp",Maximilian Kleinert <kleinert.max@…>
10106,boost shared_ptr.hpp runtime error.,smart_ptr,Boost 1.44.0,To Be Determined,Bugs,Peter Dimov,new,2014-06-09T05:13:13Z,2014-08-02T17:14:03Z,"I have code that previously ran perfectly on a mac 10.6.8 and currently runs on a ubuntu but when I try to run it on a newly installed 10.6.8 machine, I am getting this runtime error. I'm sure this is with the installation but any help is greatly appreciated.

Assertion failed: (px != 0), function operator*, file /usr/local/boost_1_44_0/boost/smart_ptr/shared_ptr.hpp, line 412.
Abort trap""

With Boost 1.44.0 and icu4c 4.3.4. and Code::Blocks compiler. Running on Mac OS X 10.6.8.

We have tried updating to the latest versions of both libraries, however still no dice. However, with Boost 1.55, the runtime error cites a different line (don't quite remember what line number, but it was in the 500s).

The program we are trying to run has ran on Boost 1.38 and I've found a couple solutions including one that says there may be a discrepancy between which version of boost the linker and includer are using. However, there's only one version of boost on my computer. The compiler and linker are both set to the directories mentioned when I installed Boost. Could it be that somewhere else, one of those is still looking for Boost 1.38? If so, where?

I've also found that it could be due to a pointer being improperly initialized, but I am reluctant to go down that road since it used to work (and still works on previous versions of boost on ubuntu) and since it would require me to rewrite quite a bit of code. 

Any thoughts as to how to fix the problem?

Thanks",Spinach <spinach@…>
10105,graphml attribute type mapping for types not in specification,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-06-07T16:53:56Z,2014-06-07T16:53:56Z,"At the moment, {{{write_graphml}}} tries to convert non-standard attribute value types (that are not in specification) which it got from {{{dynamic_properties}}}, to standard ones. A type is converted to a simple form, say {{{unsigned int}}} to {{{int}}}, etc, by a predefined mapping in {{{write_graphml}}}: {{{value_types}}} and {{{type_names}}}. The conversion only affects graph metainformation ({{{<graphml>}}}'s {{{<key>}}} elements): conversion of an attribute value to a string is done by dynamic properties in {{{dynamic_property->get_string()}}} (that is, the value is actually never converted by the writing function).

On the other hand, {{{read_graphml}}} tries to use type info from {{{<key>}}} elements and converts a string to the specified type and then passes it to dynamic property map as a {{{boost::any}}} instance. If a property map is passed to dynamic_properties that has non-standard value_type (not in {{{boost::mutate_graph_impl::value_types}}} list), but still ""supported"", like {{{unsigned int}}}, the {{{read_graphml}}} first checks if value types match and then, because they are not, unconditionally {{{any_cast}}}'s to {{{std::string}}}, which fails with {{{bad_any_cast}}} being thrown.

This is unfortunate - a user has a promise that some attribute types are supported during writing, but then she can't read it back to the same property map.

On the contrary, {{{read_graphvis}}} doesn't try to convert an attribute value before passing it to {{{dynamic_property_map}}}, due to the fact that graphvis files contain no type information :). In its turn, a {{{dynamic_property_map}}} converts passed {{{std::string}}} to its value type successfully.

Maybe a better strategy is:

1) in {{{write_graphml}}}, write attribute types as currently done.

2) in {{{read_graphml}}}, disregard attribute type information and convert string representations to values in a {{{dynamic_property_map}}}. A more sophisticated and maybe type-safe alternative is to use a more complicated logic and check {{{dynamic_property_map->value()}}} for every possible matching value type in {{{write_graphml::value_types}}} for a given type name from {{{write_graphml::type_names}}}.
",Sergey Mitsyn <svm at jinr.ru>
10103,setprecision(0) does displays too many digits of a float128,multiprecision,Boost 1.54.0,To Be Determined,Bugs,John Maddock,assigned,2014-06-07T12:38:29Z,2015-10-14T14:40:49Z,"setprecision(0) is not honored for float128.  Compare
the display of a double and a float128 (default and fixed):

{{{
0.1 0.123400000000000000000000000000000006
0 0.123400000000000000000000000000000006
}}}

This is produced with

{{{
#include <iostream>
#include <boost/multiprecision/float128.hpp>

int main() {
  double x = 0.1234;
  boost::multiprecision::float128 y = 0.1234Q;
  std::cout << std::setprecision(0) << x << "" "" << y << ""\n"";
  std::cout << std::fixed << x << "" "" << y << ""\n"";
}
}}}
",Charles Karney <charles@…>
10102,dynamic_properties inconsistent usage of lexical_cast and stringstream,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-06-07T11:09:13Z,2014-06-07T11:09:13Z,"Hello,

The {{{boost::dynamic_properties}}} is inconsistent with usage of {{{boost::lexical_cast}}} and {{{std::stringstream}}}. In file boost\property_map\dynamic_property_map.hpp, the function

{{{ 
template<typename Value>
  inline Value read_value(const std::string& value)
  }}}

uses {{{boost::lexical_cast}}}, while 

{{{
std::string dynamic_property_map_adaptor::get_string(const any& key)
}}}

uses {{{std::stringstream}}}. 

It is a problem, for example, if used together with a BGL's {{{boost::write_graphvis_dp}}} and {{{boost::read_graphvis}}} if {{{NaN}}} attribute values are written and read. With {{{std::stringstream}}} on my machine (Windows 7 + MSVC 12), NaN's are written as {{{""1.#QNAN""}}}, and lexical_cast produces and consumes {{{nan}}} and {{{NAN}}} [1]. In such case {{{boost::bad_lexical_cast}}} is thrown whenever read_graphvis is called for graphviz file containing {{{NaN}}}s.

Modifying {{{dynamic_property_map_adaptor::get_string}}} to use boost::lexical_cast seems to fix the issue with graph reading/writing. Though I'm not trying to use such files as an input for graphviz.

Speaking about graphviz, docs seem not to define any restrictions on attribute values, and I haven't looked at the source code. Quick googling gave me [http:/_/comments.gmane.org/gmane.comp.video.graphviz/7062], which is not related to this case, but it is stated there that graphviz uses {{{atof()}}}, which is locale-dependent and feels messy.

[1] see boost/lexical_cast.hpp, function
{{{
template <class CharT, class T>
bool parse_inf_nan(const CharT* begin, const CharT* end, T& value)
}}}

",Sergey Mitsyn <svm at jinr.ru>
10101,Failed to build Boost.Build engine,Building Boost,Boost 1.55.0,To Be Determined,Support Requests,,new,2014-06-07T03:33:42Z,2014-07-06T09:58:02Z,"I tried to run bootstrap.bat to build boost, but got the following information:

Failed to bootstrap the build engine
Please consult bootstrap.log for furter diagnostics.",wu_tj@…
10096,Symlink needs to check SEARCH as well as LOCATE,build,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2014-06-05T18:46:56Z,2014-06-06T22:46:41Z,"AMDG

On 06/02/2014 02:31 PM, Kcarr wrote:
> I have found the cause of my problem but I am unsure of what it was added. 
> In 1.54 in the virtual-target.jam file in the rule actualize-location
> (target) there was an added check at the beginning for scanner-target.
> 
>     if $(self.action) &&* ! $(is-scanner-target)*
> 
> This new code causes LOCATE var to never be set. <snip>
> 
> <snip>
> This seems to be a bug in the new build with using LOCATE in the 
> symlink.jam file when it shouldnt be used and instead SEARCH var 
> should be used.

Symlink code needs to be update in ln rule to look in SEARCH as well as LOCATE
",anoynamous
10094,xpressive requires update for range metafunction update,xpressive,Boost Development Trunk,To Be Determined,Bugs,Eric Niebler,new,2014-06-04T19:54:06Z,2014-06-04T19:54:06Z,"Boost.Range has been updated to make the range_iterator meta-functions work more easily with type hierarchies by adding an Enabler template parameter.

Since Xpressive is forward declaring the range meta-functions with one parameter this causes compilation errors.

Would you please update Xpressive to either avoid the forward declaration, or to match the updated signature?",Neil Groves
10090,[graph] missing documentation : member functions for bundled property in adjacency_list,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-06-04T09:14:49Z,2014-06-04T09:14:49Z,"In Bundled property's documentation, `operator[ ]` is documented.
http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/bundles.html

{{{
Map map; // load the map
Map::vertex_descriptor v = *vertices(map).first;
map[v].name = ""Troy"";
map[v].population = 49170;
map[v].zipcodes.push_back(12180);
}}}

But, In `adjacency_list` documentation is not.
http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/adjacency_list.html

Should add follow member functions reference:
{{{
// boost/graph/adjacency_list.hpp
vertex_bundled& operator[](vertex_descriptor v)
{ return get(vertex_bundle, *this)[v]; }

const vertex_bundled& operator[](vertex_descriptor v) const
{ return get(vertex_bundle, *this)[v]; }

edge_bundled& operator[](edge_descriptor e)
{ return get(edge_bundle, *this)[e]; }

const edge_bundled& operator[](edge_descriptor e) const
{ return get(edge_bundle, *this)[e]; }

graph_bundled& operator[](graph_bundle_t)
{ return get_property(*this); }

graph_bundled const& operator[](graph_bundle_t) const
{ return get_property(*this); }
}}}",Akira Takahashi <faithandbrave@…>
10089,constexpr support in units,units,Boost Development Trunk,To Be Determined,Feature Requests,Jürgen Hunold,new,2014-06-03T09:47:40Z,2018-01-10T20:39:45Z,"There is currently no support for using units and quantities within constexpr functions. 
Annotating the constructors and operators with BOOST_CONSTEXPR where possible should be enough to allow this.

I can provide a partial patch that enables constexpr support for the parts of the library that I'm using. Should I use trac or send a pull-request? The later is preferable for me.",gonzalobg88@…
10088,Null Pointer Deference in engine.ipp,asio,Boost Development Trunk,To Be Determined,Bugs,chris_kohlhoff,new,2014-06-03T06:22:15Z,2014-06-03T06:22:15Z,"http://svn.boost.org/svn/boost/trunk/boost/asio/ssl/detail/impl/engine.ipp

In below code, ssl_ is checked to be non NUll (which is already done in costructor), which means it can be NULL, but passed to SSL_get_shutdown without NULL check. If it is passed to this function as NULL, it will crash.
As ssl_ is already checked in constructor and there is no NULL check in other functions also, checking to not NULL in 214 is always true and hence can be avoided.
Please apply the patch. 

{{{
212   // SSL v2 doesn't provide a protocol-level shutdown, so an eof on the
213   // underlying transport is passed through.
214   if (ssl_ && ssl_->version == SSL2_VERSION)
215     return ec;
216
217   // Otherwise, the peer should have negotiated a proper shutdown.
218   if ((::SSL_get_shutdown(ssl_) & SSL_RECEIVED_SHUTDOWN) == 0)
}}}
",g.gupta@…
10086,Backwards compatibility to 1.42 adjacency list serialisation is broken,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-06-02T13:55:55Z,2014-06-02T13:55:55Z,"I have an archive created with boost serialization of an adjacency list which was created with boost 1.42.
When switching to Boost 1.55, the adjacency list cannot be deserialised from the archive anymore.

I identified commit [77549] which probably broke the serialisation:
It appears that the vertex and edges are not wrapped in a 'property' anymore, but stored directly in the adjacency list. 
Additionaly, in [77615] a new member ""graph_property"" was added to the serialisation code.

Unfortunately, the serialisation version number of adjacency list was not incremented and the code in 'boost/graph/adj_list_serialize.hpp' was not changed accordingly.

Furthermore in 'boost/pending/property_serialize.hpp', the serialisation order of 'value' and 'base' was switched, again without changing the class serialisation version number.

I was able to load the old archive by making following changes:


** adj_list_serialize.hpp **
{{{
template<class Archive, class OEL, class VL, class D,
     class VP, class EP, class GP, class EL>
inline void load(
    Archive & ar,
    boost::adjacency_list<OEL,VL,D,VP,EP,GP,EL> &graph,
    const unsigned int /* file_version */
){
  typedef adjacency_list<OEL,VL,D,VP,EP,GP,EL> Graph;
  typedef typename graph_traits<Graph>::vertex_descriptor Vertex;
  typedef typename graph_traits<Graph>::edge_descriptor Edge;

  unsigned int V;
  ar >> BOOST_SERIALIZATION_NVP(V);
  unsigned int E;
  ar >> BOOST_SERIALIZATION_NVP(E);
  
  std::vector<Vertex> verts(V);
  int i = 0;
  while(V-- > 0){
    // >>>>> BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH
    if( ar.get_library_version() <= 7 /* not sure about the 7, could be a greater version */){
      Vertex v = add_vertex(graph);
      boost::property<boost::vertex_bundle_t, VP> vertexAsProperty;
      ar >> vertexAsProperty;
      graph[v] = vertexAsProperty.m_value;
      verts[i++] = v;
    }
    else
    // <<<<< BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH
    {
      Vertex v = add_vertex(graph);
      verts[i++] = v;
      ar >> serialization::make_nvp(""vertex_property"", get(vertex_all_t(), graph, v) );
    }
  }
  while(E-- > 0){
    // >>>>> BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH
    if( ar.get_library_version() <= 7 /* not sure about the 7, could be a greater version */){
      int u; int v;
      ar >> BOOST_SERIALIZATION_NVP(u);
      ar >> BOOST_SERIALIZATION_NVP(v);
      Edge e; bool inserted;
      boost::tie(e,inserted) = add_edge(verts[u], verts[v], graph);
      boost::property<boost::edge_bundle_t, EP> edgeAsProperty;
      ar >> edgeAsProperty;
      graph[e] = edgeAsProperty.m_value;
    }
    else
    // <<<<< BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH
    {
      int u; int v;
      ar >> BOOST_SERIALIZATION_NVP(u);
      ar >> BOOST_SERIALIZATION_NVP(v);
      Edge e; bool inserted;
      boost::tie(e,inserted) = add_edge(verts[u], verts[v], graph);
      ar >> serialization::make_nvp(""edge_property"", get(edge_all_t(), graph, e) );
    }
  }

  // >>>>> BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH
  if(are_Adjacency_list_and_boost_property_in_old_format(ar) == false)
    ar >> serialization::make_nvp(""graph_property"", get_property(graph, graph_all_t()) );
  // <<<<< BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH
}

}}}

** property_serialize.hpp **

{{{
template<class Archive, class Tag, class T, class Base>
  void 
  serialize(Archive& ar, property<Tag, T, Base>& prop, 
            const unsigned int /*version*/) 
  {
    // >>>>> BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH
    if( ar.get_library_version() <= 7 /* not sure about the 7, could be a greater version */){
      ar & serialization::make_nvp( ""property_base"" , prop.m_base);
      ar & serialization::make_nvp( ""property_value"" , prop.m_value );
    }
    else
    // <<<<< BOOST_ADJ_LIST_1_42_SERIALIZATION_PATCH
    {
      ar & serialization::make_nvp( ""property_value"" , prop.m_value );
      ar & serialization::make_nvp( ""property_base"" , prop.m_base );
    }
  }

}}}",oluedecke@…
10083,signals2 fails to compile under Intel Parallel Composer XE,signals2,Boost 1.55.0,To Be Determined,Bugs,Frank Mori Hess,new,2014-05-30T20:59:20Z,2014-06-09T02:28:20Z,"I'm trying to compile the following file:


{{{
class Order {};

class Foo
{
  signal<void(Order*)> beforeOrder;

  void test(Order* o)
  {
    beforeOrder(o);
  }
};

int main(int argc, char* argv[])
{
  Order o;
  Foo foo;

	return 0;
}
}}}


Here's the compiler output I'm getting: 


{{{
1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory(348): warning C4996: 'std::_Uninitialized_copy0': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
1>          C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory(333) : see declaration of 'std::_Uninitialized_copy0'
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(192) : see reference to function template instantiation '_FwdIt std::uninitialized_copy<I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(_InIt,_InIt,_FwdIt)' being compiled
1>          with
1>          [
1>              _FwdIt=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>  ,            _InIt=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(179) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_rai<I,false>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,const boost::integral_constant<bool,false> &)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(179) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_rai<I,false>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,const boost::integral_constant<bool,false> &)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(205) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl<I>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,std::random_access_iterator_tag)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(205) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl<I>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *,std::random_access_iterator_tag)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(289) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl<boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(289) : see reference to function template instantiation 'void boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::copy_impl<boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>*>(I,I,boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>  ,            I=boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *
1>          ]
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(282) : while compiling class template member function 'boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::move_to_new_buffer(unsigned __int64,const boost::false_type &)'
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>          ]
1>          c:\boost\boost/signals2/detail/auto_buffer.hpp(304) : see reference to function template instantiation 'boost::variant<boost::shared_ptr<void>,boost::signals2::detail::foreign_void_shared_ptr,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_> *boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>::move_to_new_buffer(unsigned __int64,const boost::false_type &)' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>          ]
1>          c:\boost\boost/signals2/detail/slot_call_iterator.hpp(40) : see reference to class template instantiation 'boost::signals2::detail::auto_buffer<boost::signals2::detail::void_shared_ptr_variant,boost::signals2::detail::store_n_objects<10>,boost::signals2::detail::default_grow_policy,std::allocator<_Ty>>' being compiled
1>          with
1>          [
1>              _Ty=boost::signals2::detail::void_shared_ptr_variant
1>          ]
1>          c:\boost\boost/signals2/detail/slot_call_iterator.hpp(44) : see reference to class template instantiation 'boost::signals2::detail::slot_call_iterator_cache<ResultType,Function>' being compiled
}}}
",anonymous
10079,libboost_python DSO should link to libpython,python USE GITHUB,Boost 1.55.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2014-05-29T18:11:00Z,2014-05-29T18:11:00Z,"Shared libraries for Boost.Python are not linked to Python shared libraries.  libs/python/build/Jamfile.v2 contains the following explanation why that's so:
{{{
            # On *nix we never link libboost_python to libpython.  When
            # extending Python, all Python symbols are provided by the
            # Python interpreter executable.  When embedding Python, the
            # client executable is expected to explicitly link to
            # /python//python (the target representing libpython) itself.
}}}

I especially wonder about the ""executable is expected to explicitly link"" bit.  Where does this expectation come from?  On Linux it is generally business of the library to care about its own dependencies.  Python is probably something of a borderline case in this, as a Boost.Python client presumably knows they will interface with Python eventually.  Still, it is possible to create a Boost.Python client without mentioning any of Python per se.  Thus linking in libboost_python should be all that's necessary.

The obvious patch is as follows:
{{{
diff -up boost_1_55_0/libs/python/build/Jamfile.v2\~ boost_1_55_0/libs/python/build/Jamfile.v2
--- boost_1_55_0/libs/python/build/Jamfile.v2~	2010-07-13 00:29:41.000000000 +0200
+++ boost_1_55_0/libs/python/build/Jamfile.v2	2014-05-29 19:16:31.238412843 +0200
@@ -122,7 +122,7 @@ rule lib_boost_python ( is-py3 ? )
             # python_for_extensions is a target defined by Boost.Build to
             # provide the Python include paths, and on Windows, the Python
             # import library, as usage requirements.
-            [ cond [ python.configured ] : <library>/python//python_for_extensions ]
+            [ cond [ python.configured ] : <library>/python//python ]
             
             # we prevent building when there is no python available
             # as it's not possible anyway, and to cause dependents to

}}}

However tools/build/v2/tools/python.jam says:

{{{
    # On *nix, we do not want to link either Boost.Python or Python extensions
    # to libpython, because the Python interpreter itself provides all those
    # symbols. If we linked to libpython, we would get duplicate symbols. So
    # declare two targets -- one for building extensions and another for
    # embedding.
}}}

Do you know any details about the duplicate symbol issue?  I track this code down to a commit from Mon Dec 6 14:03:25 2004 by Vladimir Prus, but the commit message doesn't explain anything.

On Linux at least, there's no problem bringing in a dynamic library ""several times"".  Even with static libraries it's not clear to me how the duplication would occur.  But possibly I'm missing something obvious.  I can however make the above patch sensitive to OS if you think the issue is real on other systems.",pmachata@…
10078,"Incomplete API with respect to file related dates (cration, modification, access)",filesystem,Boost 1.55.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2014-05-29T09:38:36Z,2014-05-29T12:27:29Z,"The following features are missing:
- read file's creation date
- read file's last access date
- read file's creation date with a precision higher than seconds
- read file's last access date with a precision higher than seconds
- read file's last access date with a precision higher than seconds
- allow to detect capabilities of the underlying filesystem (e.g. support for creation and last access date that are not supported by all systems, or finding out date precision supported by the current filesystem)

Possible implementation notes:
- How to get high precision file date on Linux
http://stackoverflow.com/questions/13382695/how-to-get-last-modification-time-of-a-file-with-epoch-time-format-precision-mi
- How to get high precision file date on Windows
http://msdn.microsoft.com/en-us/library/aa364946.aspx

Example of current use of this feature in existing applications:

ls --full-time
",David Lastovicka <david@…>
10075,boost::make_filter_iterator(...) calls Predicate(Predicate &) instead of copy constructor,iterator,Boost 1.55.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-05-28T12:48:58Z,2014-05-28T12:48:58Z,Wrong parameter type is used.,jaak+boost@…
10074,"Linker Error in Debug mode VS2010, chrono lib",Building Boost,Boost 1.55.0,To Be Determined,Support Requests,,new,2014-05-27T10:41:25Z,2014-05-27T10:41:25Z,"When the current release of boost 1.55 for MSVC 32 bit is installed, my project includes chrono and compiles fine in release mode. In debug mode, haveing set the same directories for the libraries, the linker stopps with the following error:

1>LINK : fatal error LNK1104: Datei ""libboost_chrono-vc100-mt-sgd-1_52.lib"" kann nicht geöffnet werden.

(sorry for the german, but it means that the file cannot be opened.)
And acutally it is not there, because it should be version 1_55 and not 1_52. I have not installed a previous version before.
I'm linking static.

best regards,

Thomas",thomas.schreiber.privat@…
10072,filtering_stream::size() is not const,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-05-27T08:32:14Z,2017-01-21T16:39:57Z,"According to the documentation at http://www.boost.org/doc/libs/1_55_0/libs/iostreams/doc/classes/filtering_stream.html, filtering_stream::size() should be const, but it is declared non-const. The implementation does not change the class (it calls the const metzhod chain_->size()). Therefore I believe that the non-constness is an oversight. Please make size() const to match the documentation.",Georg Baum <Georg.Baum@…>
10071,[container] flat_map::insert() is ambiguous if used with initializer lists,container,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-05-26T09:43:42Z,2016-01-09T18:35:02Z,"boost::container::flat_map< unsigned int, unsigned int > foo;
foo.insert( { 1u, 1u } );

Doesn't fly, since it can either convert to std::pair<> or boost::container_detail::pair<>.",Sebastian Karlsson <sebastian@…>
10065,wait_any return with -1,mpi,Boost 1.55.0,To Be Determined,Bugs,Matthias Troyer,new,2014-05-21T13:20:42Z,2014-05-21T13:20:42Z,"I have a small example, where every process send his rank to rank 0. The process with rank 0, should receive with ''irecv'' every message and wait for it with ''wait_any''. But the ''wait_any'' function returns with -1. I have seen two other tickets, which are marked as fixed/ solved. I think they are not solved. If they are solve the documentation should be changed, because if I make the same example with MPI_Waitany, the result is completely different.

{{{
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <boost/mpi.hpp>
#include <iostream>
#include <string>
#include <boost/serialization/string.hpp>
#define MAXPROC 16    /* Max number of procsses */

int main(int argc, char* argv[]) {
  int i, np, me, index;
  const int tag  = 42;    /* Tag value for communication */
  const int root = 0;     /* Root process in broadcast */

  boost::mpi::status status;              /* Status object for non-blocing receive */
  boost::mpi::request recv_req[MAXPROC];  /* Request objects for non-blocking receive */
  
  int myname[5];             /* Local host name string */
  int hostname[5];  /* Received host names */
  int namelen;

  boost::mpi::environment env;                /* Initialize MPI */
  boost::mpi::communicator world;                /* Initialize MPI */
  np = world.size();    /* Get nr of processes */
  me = world.rank();    /* Get own identifier */
  

  if (me == 0) {    /* Process 0 does this */
	
	    std::cout <<""Process "" << me << "" broadcasting to all processes\n"";
		boost::mpi::broadcast(world, me, 0);
	
	    std::cout <<""Process "" << me<< "" receiving from all other processes\n"";
	    for (i=1; i<np; i++) {
		recv_req[i] = world.irecv(i,i,hostname[i]);
	    }
	
	    for (i=1; i<np; i++) {
	
		status = wait_any(recv_req,recv_req +5 ).first; 
	      std::cout<<""Received a message from process ""<< status.source() << "" tag "" << status.tag() << std::endl;
	    }
	    std::cout <<""Ready\n"";
	
  } 
	else { 
    int y;  

	boost::mpi::broadcast(world, y, 0);
	sleep(me%3+1);  

	MPI_Send (myname, namelen, MPI_CHAR, 0, tag, world);

  }
	world.barrier();
	
	~world;
	return 0;
}
}}}",florian <boost_error_wait88@…>
10064,generate_uniform_real may go into infinite loop,random,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-05-21T12:24:03Z,2014-08-07T23:43:39Z,"See uniform_real_distribution.hpp:

template<class Engine, class T>
T generate_uniform_real(
    Engine& eng, T min_value, T max_value,
    boost::mpl::true_  /** is_integral<Engine::result_type> */)
{
    for(;;) {
        typedef T result_type;
        typedef typename Engine::result_type base_result;
        result_type numerator = static_cast<T>(subtract<base_result>()(eng(), (eng.min)()));
        result_type divisor = static_cast<T>(subtract<base_result>()((eng.max)(), (eng.min)())) + 1;
        BOOST_ASSERT(divisor > 0);
        BOOST_ASSERT(numerator >= 0 && numerator <= divisor);
        T result = numerator / divisor * (max_value - min_value) + min_value;
        if(result < max_value) return result;
    }
}

Please add a ""BOOST_ASSERT(max_value > min_value);"".

If one declares something like

   boost::random::mt19937 mt;
   boost::random::uniform_real_distribution<double> dist(0.0, 0.0);

dist(mt) makes generate_uniform_real go into an infinite loop.

Thank you and best regards.",Markus Faerber <mf@…>
10063,Option should exist to include ublas entirely from headers without linking to serialization,uBLAS,Boost 1.55.0,Boost 1.56.0,Patches,Gunter,new,2014-05-21T05:38:31Z,2014-05-21T05:38:31Z,"If you include certain ublas files which you wish to include as headers only without linking to prebuilt libs, you get link errors wanting to link to prebuild serialization library.

This problem occurred for example when I included the following in my application:

{{{
#include <boost/numeric/ublas/fwd.hpp>
#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/vector_sparse.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/matrix_sparse.hpp>
#include <boost/numeric/ublas/storage_sparse.hpp>
#include <boost/numeric/ublas/banded.hpp>
#include <boost/numeric/ublas/triangular.hpp>
#include <boost/numeric/ublas/blas.hpp>
#include <boost/numeric/ublas/lu.hpp>

}}}


The attached patch introduces an option BOOST_UBLAS_DISABLE_SERIALIZATION which (if defined using a #define) excludes the serialization code.

The serialization code is unwanted on my platform for ublas objects, as the platform is obscure and difficult to build the serialization library for it.
",Andrew Medlin <andrew@…>
10055,visit_current_states can't be called for const object,msm,Boost 1.53.0,To Be Determined,Bugs,Christophe Henry,new,2014-05-16T06:31:52Z,2014-05-16T06:31:52Z,"Is there any reason the back::state_machine::visit_current_states() method is not const? I've added const to it and to back::state_machine::visitor_fct_helper::execute() and it didn't break compilation.

Regards,
Marcin Pytel",mkp
10053,1.55 boost/crc warning clang -Wshadow,crc,Boost 1.55.0,To Be Determined,Bugs,Daryle Walker,new,2014-05-15T08:58:58Z,2014-05-18T18:39:24Z,"On 1.55 I observed this warning with clang -Wshadow

boost/crc.hpp:758:20: Declaration shadows a static data member of 'crc_basic<Bits>'",adrien.courdavault@…
10052,Runtime check of IEEE-754 rounding modes support,interval,Boost Development Trunk,To Be Determined,Feature Requests,Boris Gubenko,new,2014-05-15T04:04:02Z,2014-05-15T04:04:02Z,"Interval Arithmetic Library has only compile time check of IEEE-754 rounding modes support. Unfortunately it is insufficient for instance when a program is running under Valgrind.


It is quite simple and inexpensive to add some runtime check like the one used in CGAL ([www.cgal.org]) ''CGAL::Interval_nt::Test_runtime_rounding_modes''.",andrey.a.davydov@…
10050,libboost-all-dev available on ARMv7,Building Boost,Boost 1.54.0,To Be Determined,Support Requests,,new,2014-05-13T19:31:15Z,2014-05-18T18:39:50Z,"We are working on a project that requires the use of your package libboost-all-dev, however it is only available for i386 and amd64 architectures. I need it for an ARMv7 architecture 32bit.",spider.kiehtan@…
10047,Using Boost:Interprocess on Android,interprocess,Boost 1.53.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-05-12T15:46:39Z,2018-03-16T01:47:33Z,"It is not a bug, but it might safe some time to others using boost:interprocess library on Android.

This library usually uses a temporary directory to store the data that is being shared among processes. The directory path used for this can be found on os_file_functions.hpp-:get_temporary_path. 

The thing is that if you do not modify this file and add ´/sdcard´ to the possible paths that your process can use, then you cannot share information among android Apps due to the permission restrictions that exist for processes on android storing data outside their sandbox.

It will be a good feature to have boost compile with this option on. Or provide a static method to add my own Temporary Path.


Note: I am not completely sure if something exists to solve this problem.


Regards,",anonymous
10045,boost::numeric::symmetric_matrix serialization code missing,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2014-05-12T13:36:47Z,2017-04-02T10:57:36Z,"boost::numeric::matrix<> and boost::numeric::vector<> have serialization implemented. boost::numeric::symmetric_matrix<> does not implement serialization:

/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9: error: ‘class boost::numeric::ublas::symmetric_matrix<double>’ has no member named ‘serialize’
         t.serialize(ar, file_version);
         ^",maxim.yegorushkin@…
10044,ublas serialization causes no end of warnings,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2014-05-12T13:29:50Z,2014-05-18T18:40:21Z,"boost/numeric/ublas/storage.hpp:276 causes `gcc-4.8.2 -Wall -Wextra` spit no end of warnings because of the unused `version` function argument:

/usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/storage.hpp: In instantiation of ‘void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = double; ALLOC = std::allocator<double>]’:
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9:   required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69:   required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27:   required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:192:5:   required from ‘void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:120:1:   required from ‘class boost::archive::detail::iserializer<boost::archive::binary_iarchive, boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:387:13:   required from ‘static void boost::archive::detail::load_non_pointer_type<Archive>::load_standard::invoke(Archive&, const T&) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:439:28:   required from ‘static void boost::archive::detail::load_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:592:24:   required from ‘void boost::archive::load(Archive&, T&) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_iarchive.hpp:66:40:   required from ‘void boost::archive::detail::common_iarchive<Archive>::load_override(T&, int) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_iarchive.hpp:70:7:   required from ‘void boost::archive::basic_binary_iarchive<Archive>::load_override(T&, int) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_iarchive_impl.hpp:50:9:   required from ‘void boost::archive::binary_iarchive_impl<Archive, Elem, Tr>::load_override(T&, int) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits<char>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:60:9:   required from ‘Archive& boost::archive::detail::interface_iarchive<Archive>::operator>>(T&) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/nvp.hpp:87:9:   required from ‘void boost::serialization::nvp<T>::load(Archivex&, unsigned int) [with Archivex = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:101:9:   required from ‘static void boost::serialization::access::member_load(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/split_member.hpp:54:52:   required from ‘static void boost::serialization::detail::member_loader<Archive, T>::invoke(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/split_member.hpp:69:38:   required from ‘void boost::serialization::split_member(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/nvp.hpp:89:5:   required from ‘void boost::serialization::nvp<T>::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9:   required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69:   required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27:   required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:377:13:   required from ‘static void boost::archive::detail::load_non_pointer_type<Archive>::load_only::invoke(Archive&, const T&) [with T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:439:28:   required from ‘static void boost::archive::detail::load_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:592:24:   required from ‘void boost::archive::load(Archive&, T&) [with Archive = boost::archive::binary_iarchive; T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_iarchive.hpp:66:40:   required from ‘void boost::archive::detail::common_iarchive<Archive>::load_override(T&, int) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_iarchive.hpp:70:7:   required from ‘void boost::archive::basic_binary_iarchive<Archive>::load_override(T&, int) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_iarchive_impl.hpp:50:9:   required from ‘void boost::archive::binary_iarchive_impl<Archive, Elem, Tr>::load_override(T&, int) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits<char>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:60:9:   required from ‘Archive& boost::archive::detail::interface_iarchive<Archive>::operator>>(T&) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:67:32:   required from ‘Archive& boost::archive::detail::interface_iarchive<Archive>::operator&(T&) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/matrix.hpp:1087:16:   required from ‘void boost::numeric::ublas::matrix<T, L, A>::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = double; L = boost::numeric::ublas::basic_row_major<>; A = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9:   required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69:   required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27:   required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:192:5:   required from ‘void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:120:1:   required from ‘class boost::archive::detail::iserializer<boost::archive::binary_iarchive, boost::numeric::ublas::matrix<double> >’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:387:13:   required from ‘static void boost::archive::detail::load_non_pointer_type<Archive>::load_standard::invoke(Archive&, const T&) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:439:28:   required from ‘static void boost::archive::detail::load_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:592:24:   required from ‘void boost::archive::load(Archive&, T&) [with Archive = boost::archive::binary_iarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_iarchive.hpp:66:40:   required from ‘void boost::archive::detail::common_iarchive<Archive>::load_override(T&, int) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_iarchive.hpp:70:7:   required from ‘void boost::archive::basic_binary_iarchive<Archive>::load_override(T&, int) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_iarchive_impl.hpp:50:9:   required from ‘void boost::archive::binary_iarchive_impl<Archive, Elem, Tr>::load_override(T&, int) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits<char>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:60:9:   required from ‘Archive& boost::archive::detail::interface_iarchive<Archive>::operator>>(T&) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:67:32:   required from ‘Archive& boost::archive::detail::interface_iarchive<Archive>::operator&(T&) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_iarchive]’
/home/max/otsquant/src/c++/data_access/data_access.cc:217:12:   required from ‘void {anonymous}::FactorModel::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9:   required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69:   required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27:   required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:192:5:   required from ‘void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:120:1:   required from ‘class boost::archive::detail::iserializer<boost::archive::binary_iarchive, {anonymous}::FactorModel>’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:387:13:   required from ‘static void boost::archive::detail::load_non_pointer_type<Archive>::load_standard::invoke(Archive&, const T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:439:28:   required from ‘static void boost::archive::detail::load_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/iserializer.hpp:592:24:   required from ‘void boost::archive::load(Archive&, T&) [with Archive = boost::archive::binary_iarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_iarchive.hpp:66:40:   required from ‘void boost::archive::detail::common_iarchive<Archive>::load_override(T&, int) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_iarchive.hpp:70:7:   required from ‘void boost::archive::basic_binary_iarchive<Archive>::load_override(T&, int) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_iarchive_impl.hpp:50:9:   required from ‘void boost::archive::binary_iarchive_impl<Archive, Elem, Tr>::load_override(T&, int) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive; Elem = char; Tr = std::char_traits<char>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_iarchive.hpp:60:9:   required from ‘Archive& boost::archive::detail::interface_iarchive<Archive>::operator>>(T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_iarchive]’
/home/max/otsquant/src/c++/data_access/cache_file.h:102:28:   required from ‘bool ot::data_access::CacheFile::try_loading(T*) [with T = {anonymous}::FactorModel]’
/home/max/otsquant/src/c++/data_access/data_access.cc:783:43:   required from here
/usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/storage.hpp:276:14: warning: unused parameter ‘version’ [-Wunused-parameter]
         void serialize(Archive & ar, const unsigned int version)
              ^
/usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/storage.hpp: In instantiation of ‘void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = double; ALLOC = std::allocator<double>]’:
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9:   required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69:   required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27:   required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:152:5:   required from ‘void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:101:1:   required from ‘class boost::archive::detail::oserializer<boost::archive::binary_oarchive, boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:253:13:   required from ‘static void boost::archive::detail::save_non_pointer_type<Archive>::save_standard::invoke(Archive&, const T&) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:308:28:   required from ‘static void boost::archive::detail::save_non_pointer_type<Archive>::invoke(Archive&, const T&) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:525:24:   required from ‘void boost::archive::save(Archive&, T&) [with Archive = boost::archive::binary_oarchive; T = const boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_oarchive.hpp:69:40:   required from ‘void boost::archive::detail::common_oarchive<Archive>::save_override(T&, int) [with T = const boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_oarchive.hpp:75:7:   required from ‘void boost::archive::basic_binary_oarchive<Archive>::save_override(const T&, int) [with T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_oarchive_impl.hpp:51:9:   required from ‘void boost::archive::binary_oarchive_impl<Archive, Elem, Tr>::save_override(T&, int) [with T = const boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_oarchive; Elem = char; Tr = std::char_traits<char>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:63:9:   required from ‘Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = const boost::numeric::ublas::unbounded_array<double, std::allocator<double> >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/nvp.hpp:79:9:   required from ‘void boost::serialization::nvp<T>::save(Archivex&, unsigned int) const [with Archivex = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:93:9:   required from ‘static void boost::serialization::access::member_save(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/split_member.hpp:43:52:   required from ‘static void boost::serialization::detail::member_saver<Archive, T>::invoke(Archive&, const T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/split_member.hpp:69:38:   required from ‘void boost::serialization::split_member(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/nvp.hpp:89:5:   required from ‘void boost::serialization::nvp<T>::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9:   required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69:   required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27:   required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:245:13:   required from ‘static void boost::archive::detail::save_non_pointer_type<Archive>::save_only::invoke(Archive&, const T&) [with T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:308:28:   required from ‘static void boost::archive::detail::save_non_pointer_type<Archive>::invoke(Archive&, const T&) [with T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:525:24:   required from ‘void boost::archive::save(Archive&, T&) [with Archive = boost::archive::binary_oarchive; T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_oarchive.hpp:69:40:   required from ‘void boost::archive::detail::common_oarchive<Archive>::save_override(T&, int) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_oarchive.hpp:75:7:   required from ‘void boost::archive::basic_binary_oarchive<Archive>::save_override(const T&, int) [with T = boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_oarchive_impl.hpp:51:9:   required from ‘void boost::archive::binary_oarchive_impl<Archive, Elem, Tr>::save_override(T&, int) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_oarchive; Elem = char; Tr = std::char_traits<char>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:63:9:   required from ‘Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:71:35:   required from ‘Archive& boost::archive::detail::interface_oarchive<Archive>::operator&(T&) [with T = const boost::serialization::nvp<boost::numeric::ublas::unbounded_array<double, std::allocator<double> > >; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/matrix.hpp:1087:16:   required from ‘void boost::numeric::ublas::matrix<T, L, A>::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = double; L = boost::numeric::ublas::basic_row_major<>; A = boost::numeric::ublas::unbounded_array<double, std::allocator<double> >]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9:   required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69:   required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27:   required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:152:5:   required from ‘void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::binary_oarchive; T = boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:101:1:   required from ‘class boost::archive::detail::oserializer<boost::archive::binary_oarchive, boost::numeric::ublas::matrix<double> >’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:253:13:   required from ‘static void boost::archive::detail::save_non_pointer_type<Archive>::save_standard::invoke(Archive&, const T&) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:308:28:   required from ‘static void boost::archive::detail::save_non_pointer_type<Archive>::invoke(Archive&, const T&) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:525:24:   required from ‘void boost::archive::save(Archive&, T&) [with Archive = boost::archive::binary_oarchive; T = const boost::numeric::ublas::matrix<double>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_oarchive.hpp:69:40:   required from ‘void boost::archive::detail::common_oarchive<Archive>::save_override(T&, int) [with T = const boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_oarchive.hpp:75:7:   required from ‘void boost::archive::basic_binary_oarchive<Archive>::save_override(const T&, int) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_oarchive_impl.hpp:51:9:   required from ‘void boost::archive::binary_oarchive_impl<Archive, Elem, Tr>::save_override(T&, int) [with T = const boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_oarchive; Elem = char; Tr = std::char_traits<char>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:63:9:   required from ‘Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = const boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:71:35:   required from ‘Archive& boost::archive::detail::interface_oarchive<Archive>::operator&(T&) [with T = boost::numeric::ublas::matrix<double>; Archive = boost::archive::binary_oarchive]’
/home/max/otsquant/src/c++/data_access/data_access.cc:217:12:   required from ‘void {anonymous}::FactorModel::serialize(Archive&, unsigned int) [with Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/access.hpp:118:9:   required from ‘static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:69:69:   required from ‘void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/serialization/serialization.hpp:128:27:   required from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::binary_oarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:152:5:   required from ‘void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::binary_oarchive; T = {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:101:1:   required from ‘class boost::archive::detail::oserializer<boost::archive::binary_oarchive, {anonymous}::FactorModel>’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:253:13:   required from ‘static void boost::archive::detail::save_non_pointer_type<Archive>::save_standard::invoke(Archive&, const T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:308:28:   required from ‘static void boost::archive::detail::save_non_pointer_type<Archive>::invoke(Archive&, const T&) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/oserializer.hpp:525:24:   required from ‘void boost::archive::save(Archive&, T&) [with Archive = boost::archive::binary_oarchive; T = const {anonymous}::FactorModel]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/common_oarchive.hpp:69:40:   required from ‘void boost::archive::detail::common_oarchive<Archive>::save_override(T&, int) [with T = const {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/basic_binary_oarchive.hpp:75:7:   required from ‘void boost::archive::basic_binary_oarchive<Archive>::save_override(const T&, int) [with T = {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/binary_oarchive_impl.hpp:51:9:   required from ‘void boost::archive::binary_oarchive_impl<Archive, Elem, Tr>::save_override(T&, int) [with T = const {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive; Elem = char; Tr = std::char_traits<char>]’
/usr/local/ots/4/boost-1.55.0/include/boost/archive/detail/interface_oarchive.hpp:63:9:   required from ‘Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = const {anonymous}::FactorModel; Archive = boost::archive::binary_oarchive]’
/home/max/otsquant/src/c++/data_access/cache_file.h:116:32:   required from ‘void ot::data_access::CacheFile::save(const T&) [with T = {anonymous}::FactorModel]’
/home/max/otsquant/src/c++/data_access/data_access.cc:790:35:   required from here
/usr/local/ots/4/boost-1.55.0/include/boost/numeric/ublas/storage.hpp:276:14: warning: unused parameter ‘version’ [-Wunused-parameter]


",maxim.yegorushkin@…
10042,anonymous enum problem (gcc4.4.7) in asio/completion_condition.hpp,asio,,To Be Determined,Patches,chris_kohlhoff,new,2014-05-11T21:11:49Z,2014-05-11T21:11:49Z,"A similar problem (anonymous enum) as described in 

https://svn.boost.org/trac/boost/ticket/6362

is in asio/completion_condition.hpp (git master). 

This prevents code using asio::spawn to compile when using gcc4.4.7, e.g., asio/example/cpp03/spawn/echo_server.cpp

{{{
asio> git diff
diff --git a/include/boost/asio/completion_condition.hpp b/include/boost/asio/completion_condition.hpp
index bdc041c..372e224 100644
--- a/include/boost/asio/completion_condition.hpp
+++ b/include/boost/asio/completion_condition.hpp
@@ -26,7 +26,7 @@ namespace asio {
 namespace detail {
 
 // The default maximum number of bytes to transfer in a single operation.
-enum { default_max_transfer_size = 65536 };
+enum _dummy_max_transfer_size_type_ { default_max_transfer_size = 65536 };
 
 // Adapt result of old-style completion conditions (which had a bool result
 // where true indicated that the operation was complete).
}}}


",hcab14@…
10039,library_status fails invalid bin directory structure,Regression Testing USE GITHUB,Boost 1.55.0,To Be Determined,Bugs,-,new,2014-05-11T12:13:19Z,2017-08-26T15:50:44Z,"When I run tools/regression/src/library_test_all.sh on Boost 1.55, it fails to generate proper reports for many libraries. The library_status.html generated for those libraries has a header but no results table. The error message from library_status is the following:
{{{
**** exception(205): std::string: invalid bin directory structure
******** errors detected; see standard output for details ********
}}}

One directory where it fails is bin.v2\libs\asio\test\generic_basic_endpoint.test\qcc-arm_4.4.2_0x\debug\debug-symbols-off\target-os-qnxnto\threading-multi. It contains the files generic_basic_endpoint, generic_basic_endpoint.test and test_log.xml as well as the directory generic which contains the files basic_endpoint.o and test_log.xml.

The testing script was started as follows:
C:\Arbete\boost\boost_1_55_0>tools\regression\src\library_test_all.sh toolset=qcc-arm_4.4.2_0x testing.launcher=z:\boost-kompilering\remote-test.bat target-os=qnxnto debug-symbols=off -l240 -j8 2>&1

I've verified that the problem remains on the current git develop branch (commit 195baf8a), running on Ubuntu. Full output and command line in the attached text file.

Googling for the error message turns up results from august last year with no solution.",Niklas Angare <li51ckf02@…>
10037,process_jam_log can't open output file when using library_test_all.sh,Regression Testing USE GITHUB,Boost 1.55.0,To Be Determined,Patches,René Rivera,new,2014-05-10T17:01:03Z,2014-05-10T17:01:03Z,"When I run tools/regression/src/library_test_all.sh on Boost 1.55, it fails to generate proper reports for many libraries. process_jam_log outputs messages like this:
{{{
*****Warning - can't open output file: c:/Arbete\boost\boost_1_55_0\../../bin.v2/libs/atomic/test/native_api.test/qcc-arm_4.4.2_0x/debug/link-static/target-os-qnxnto/threading-multi\test_log.xml
}}}

The ""../../"" shouldn't be there as it escapes BOOST_ROOT. The problem seems to be that paths in bjam.log are relative to sub-directories of BOOST_ROOT/libs. The function parse_skipped_msg_aux() appears to handle the case where paths are relative to immediate sub-directories of BOOST_ROOT, such as BOOST_ROOT/status. The attached patch extends it to handle arbitrarily deep sub-directories.
",Niklas Angare <li51ckf02@…>
10034,Change win_iocp_handle_service to still return bytes_transferred if ReadFile fails with ERROR_MORE_DATA,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-05-10T09:17:51Z,2014-05-10T09:17:51Z,See ticket #8722 for details.,chris_kohlhoff
10027,Allow template parameters with types rather than hardcode typename in BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE (and friends),fusion,Boost 1.55.0,To Be Determined,Feature Requests,Joel de Guzman,new,2014-05-08T23:40:27Z,2014-05-08T23:40:27Z,"Right now, the macro `BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE` creates

{{{
template<typename A, typename B>
struct MyStruct { ... };
}}}

from 

{{{
BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE(
  (A)(B),
  MyStruct,
  (A, foo)
  (B, bar)
)
}}}

But I want to put the class `template<int DIM> class Vector` into a Boost Fusion Struct. So the struct should allow template parameters that are not typenames. I would like to be able to write the following:

{{{
BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE(
  (int DIM)(typename B),
  MyStruct,
  (Vector<DIM>, foo)
  (B, bar)
)

// the above becomes
// template<int DIM, typename B>
// struct MyStruct { ... };

MyStruct<3, double> struct;
}}}

This does not currently work. The following is a working (but cumbersome) workaround (using C++11):

{{{
BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE(
  (DIM)(B),
  MyStructImpl,
  (Vector<DIM::value>, foo)
  (B, bar)
)

template<int DIM>
using MyStruct = MyStructImpl<boost::mpl::int_<DIM>>;

MyStruct<3, double> struct;
}}}

Maybe for backwards compatibility my proposed version of `BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE` where template parameters are declared as `(int DIM)(typename B)` should be named `BOOST_FUSION_DEFINE_FLEXIBLE_TPL_STRUCT_INLINE`.",Jonas Lippuner <jonas@…>
10026,Building Boost with #define BOOST_SP_ENABLE_DEBUG_HOOKS generates compile error C2665 in Visual C++ 2012,smart_ptr,Boost 1.55.0,To Be Determined,Bugs,Peter Dimov,new,2014-05-08T22:19:02Z,2015-02-13T18:50:07Z,"I ran the following command from a Visual C++ command window.

b2 toolset=msvc-11.0 address-model=32 variant=debug link=static threading=multi runtime-link=shared --build-type=complete define=BOOST_SP_ENABLE_DEBUG_HOOKS

I am trying to compile the Boost Libraries with the debug hooks in.
Is this a Visual C++ 2012 compiler issue as I also had problems  with compilation on Visual C++ 2010. Any ideas? Thanks. I have tried this compilation on both Windows 7 and Windows 8.1.

compile-c-c++ bin.v2\libs\thread\build\msvc-11.0\release\address-model-32\link-static\threading-multi\win32\thread.obj
thread.cpp
.\boost/smart_ptr/detail/sp_counted_impl.hpp(69) : error C2665: 'boost::sp_scalar_constructor_hook' : none of the 2 overloads could convert all the argument types
        .\boost/smart_ptr/detail/sp_counted_impl.hpp(45): could be 'void boost::sp_scalar_constructor_hook(void *,size_t,void *)'
        while trying to match the argument list '(const boost::exception_detail::clone_base *, unsigned int, boost::detail::sp_counted_impl_p<X> *const )'
        with
        [
            X=const boost::exception_detail::clone_base
        ]
        .\boost/smart_ptr/detail/sp_counted_impl.hpp(66) : while compiling class template member function 'boost::detail::sp_counted_impl_p<X>::sp_counted_impl_p(X *)'
        with
        [
            X=const boost::exception_detail::clone_base
        ]
        .\boost/smart_ptr/detail/shared_count.hpp(130) : see reference to function template instantiation 'boost::detail::sp_counted_impl_p<X>::sp_counted_impl_p(X *)' being compiled
        with
        [
            X=const boost::exception_detail::clone_base
        ]
        .\boost/smart_ptr/detail/shared_count.hpp(130) : see reference to class template instantiation 'boost::detail::sp_counted_impl_p<X>' being compiled
        with
        [
            X=const boost::exception_detail::clone_base
        ]
        .\boost/smart_ptr/shared_ptr.hpp(276) : see reference to function template instantiation 'boost::detail::shared_count::shared_count<Y>(Y *)' being compiled
        with
        [
            Y=const boost::exception_detail::clone_base
        ]
        .\boost/smart_ptr/shared_ptr.hpp(354) : see reference to function template instantiation 'void boost::detail::sp_pointer_construct<const boost::exception_detail::clone_base,Y>(boost::shared_ptr<T> *,Y *,boost::detail::shared_count &)' being compiled
        with
        [
            Y=const boost::exception_detail::clone_base,
            T=const boost::exception_detail::clone_base
        ]
        .\boost/exception/detail/exception_ptr.hpp(313) : see reference to function template instantiation 'boost::shared_ptr<T>::shared_ptr<const boost::exception_detail::clone_base>(Y *)' being compiled
        with
        [
            T=const boost::exception_detail::clone_base,
            Y=const boost::exception_detail::clone_base
        ]
        .\boost/exception/detail/exception_ptr.hpp(313) : see reference to function template instantiation 'boost::shared_ptr<T>::shared_ptr<const boost::exception_detail::clone_base>(Y *)' being compiled
        with
        [
            T=const boost::exception_detail::clone_base,
            Y=const boost::exception_detail::clone_base
        ]",Clifford.Jackson@…
10024,allocator memory leak,pool,Boost 1.55.0,To Be Determined,Bugs,Chris Newbold,new,2014-05-08T16:26:18Z,2014-05-18T18:42:27Z,"hi~
boost allocaltor memory leak bug.

stl + boost allocator 

check crtdbg.h

sample code.


{{{
#include ""stdafx.h""
#include <string>
#include <vector>
#include <boost/pool/pool_alloc.hpp>
#include <crtdbg.h>
int main()
{
    _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); 
    typedef std::vector<int, boost::pool_allocator<int>> Ints;
    Ints i;
    i.push_back(10);
    return 0;
}


}}}
that code memory leak. not call free.

",anonymous
10022,json_parser_write inconditionally converts CP1252 to escaped unicode,property_tree,Boost 1.55.0,To Be Determined,Feature Requests,Sebastian Redl,new,2014-05-08T12:29:46Z,2014-05-08T12:40:16Z,"See function 'create_escapes' in property_tree/detail/json_parser_write.hpp. I supply a property_tree containing UTF-8 encoded values, encoded in a custom way from data in different code pages. I want JSON with real UTF-8 encoding, which the JSON standard just allows (as far as I googled). So here the encoding of 'special' characters to ""\uXXXX"" should be turned off.

All values the Ch has are directly translated to a unicode number, but when Ch=char this only works correct when the char data is in code page 1252.

Currently the option to encode the characters nor the used code page are parameters here.

I needed to locally adapt the code like in http://stackoverflow.com/questions/10260688/boostproperty-treejson-parser-and-two-byte-wide-characters",anonymous
10016,SO_UPDATE_CONNECT_CONTEXT: Undeclared identifier,asio,Boost Release Branch,To Be Determined,Bugs,chris_kohlhoff,new,2014-05-06T23:33:33Z,2014-06-04T20:59:36Z,"{{{
boost log defaults to _WIN32_WINNT 0x0500 in src/windows_version.hpp
asio now uses SO_UPDATE_CONNECT_CONTEXT in detail/impl/socket_ops.ipp
which is not defined before 0x0501
change 
#define _WIN32_WINNT 0x0500 // _WIN32_WINNT_WIN2K
to
#define _WIN32_WINNT 0x0501 // _WIN32_WINNT_WINXP
in src/windows_version.hpp to fix this compile error
}}}",Joseph Southwell <joseph@…>
10014,date_from_tm incorrectly documented as part of posix_time,date_time,Boost 1.55.0,To Be Determined,Bugs,az_sw_dude,new,2014-05-06T20:31:21Z,2015-02-23T04:28:05Z,"On this page:
http://www.boost.org/doc/libs/1_55_0/doc/html/date_time/posix_time.html#date_time.posix_time.time_duration

date_from_tm is documented as part of the posix_time namespace, which is it not. Instead, ptime_from_tm (which calls date_from_tm from the Gregorian namespace) should be documented in its place.",Edward Brey <edward@…>
10009,Boost Asio should provide also thread-safe sockets,asio,Boost 1.55.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-05-06T14:51:27Z,2016-12-01T09:09:52Z,"The feature I'm requesting is strictly related to the well-known problem reported in ticket #8538, but I'm not reporting it as a bug since the documentation explicitly states that the Asio's sockets are ''not'' thread-safe ''by design'': the user ''must'' use strands at top level to ensure a correct behavior in a multi-threaded environment. If I've correctly understood, the rationale for such design is that in a single threaded environment, one should pay no cost for synchronization.
I disagree with this design decision for several reasons.
== The multi-threaded environments are more important ==
I believe that the environments where asio is seriously (heavily) used are multi-threaded (there is an asio-based thread pool): this means that the optimization is made for the simpler cases (where the cost for a not-contended lock acquisition is negligible); IMHO this is wrong. This adds an additional (significative) overhead to users which have necessarily to:
   1. use strands (through strand::wrap() as suggested in the docs) ''or''
   2. use mutexes (or other lock types) and carry always a reference to them with the relative socket ''or''
   3. wrap asio's socket with a custom class that internally uses locking.
== strand::wrap() is not always that useful ==
I believe that the solution officially recommended to ""solve the problem"" (wrapping the callbacks with strand::wrap()) is theoretically a bad idea since it causes the serialization (which is ''almost'' like what a mutex does) of the callbacks invocation: this is ''deeply'' wrong because it is an anti-pattern: the fundamental principle of synchronization is that ONLY the data has to be ""locked"", NOT the code. Using strand::wrap() ( ~= locking the CODE ) could lead to serious performance bottlenecks if the callbacks' code is not ''carefully'' written (one could unconsciously do a heavy computation (or sync I/O) through several levels of function calls). So, within this model, writing an efficient code will mean to be careful and to necessarily re-schedule all non-trivial tasks: that is not so easy sometimes.[[br]]
What if, for example, one wants to close 100 sockets in a callback? Using strand::wrap() would mean to use a common strand for all the 100 sockets (= to serialize all the callbacks for these sockets): this is an ''unacceptable'' cost to pay. Instead, using a strand for each socket and rescheduling a close() request using strand::post() is much better but would mean always carrying back a reference of the relative strand for each socket: this is same problem of the alternative 2: no one would be happy to do this.[[br]]
It seems that the most attractive alternative is the third one.
== The non-thread-safe sockets are not something one would expect from Asio ==
I'm pretty sure that I'm not the only one who, before reading ''carefully'' the documentation, was expecting that the sockets were ''of course'' thread-safe: we are dealing with a high-level library for asynchronous I/O. The situation is analogue to C++11's atomics: they, by default, use FULL barriers because this way is simpler to use them; advanced users (that really know what they're doing) instead, could always specify the exact type of barrier they need. I think Asio is roughly at the same level of abstraction of standard C++ libraries (if not at higher one), so I think it should follow the same philosophy.
== Synchronization is already used in Asio's internals ==
Even if the official docs declare the asio's sockets as non-thread-safe, actually ''there are'' synchronization mechanisms in asio's reactors (epoll and kqueue) which allow the sockets to ''almost work'' in a multi-threaded environment except when destructive operations like close() are used. In these cases, the subtle race described in #8538 appears since the mutex protecting the access to the descriptor_data node ''has to be'' released before ""freeing it"" because the mutex itself is a member of the (same) node. That mutex makes me suspect that ''maybe'' an attempt has been made to solve the synchronization problem at the reactor level but it failed since the socket's lifetime is bigger than the descriptor_data node which has to die when the descriptor is closed. Since the reactors has no access to the upper level socket services (such thing will break the isolation of the abstraction layers), the only solution seems to use a top-level synchronization mechanism.
== What is my purpose to improve Asio ==
I purpose a simple patch (the attached file) that adds a lock contended only among the async and the destructive operations at the top-level classes (the *_socket_service classes). I think this solution is a good compromise because all the code it adds is under an #ifdef: who wants to work easily with asio's sockets has simply to specify it at compile-time; the others could still pay the ""zero"" cost in single-threaded applications. Even if I'd prefer the define to work in the opposite way, I'm purposing this change because has a minor impact, conserves the old behavior unless specified and so, I hope it has a greater chance to be accepted.
== Just a final remark ==
I'd just like to say that, even if it probably doesn't emerge from my comments, I'm an Asio's fan: overall, it is really a great boost-style library and I use it intensively. That's the reason why I'm spending some much energies trying to improve it. ",Vladislav Valtchev <vladi32@…>
10005,erf_inv_initializer crashes under valgrind,math,Boost 1.54.0,To Be Determined,Bugs,John Maddock,reopened,2014-05-04T00:08:46Z,2017-10-31T15:44:57Z,"It was reported before on the mailing list:
http://lists.boost.org/boost-users/2012/08/75711.php
and I assume it's because valgrind doesn't support long doubles:
https://bugs.kde.org/show_bug.cgi?id=197915

Somehow erfc_inv is called in this place and the argument is then found to be 0:

{{{
#!cpp
         // Some compilers choke on constants that would underflow, even in code that isn't instantiated
         // so try and filter these cases out in the preprocessor:
#if LDBL_MAX_10_EXP >= 800
         if(static_cast<T>(BOOST_MATH_BIG_CONSTANT(T, 64, 1e-800)) != 0)
            boost::math::erfc_inv(static_cast<T>(BOOST_MATH_BIG_CONSTANT(T, 64, 1e-800)), Policy());

}}}

So an exception is thrown during initialization.
While it may not be a bug, valgrind is extremely useful and it would be nice to have a workaround.

I don't understand why erf_inv and erfc_inv are called with these arguments in `erf_inv_initializer<>::init::do_init()`, so I'm not sure what workaround is safe.

Here is a full traceback:
{{{
#0  0x00000036fb435c39 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00000036fb437348 in __GI_abort () at abort.c:89
#2  0x00000036ff860f85 in __gnu_cxx::__verbose_terminate_handler ()
    at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00000036ff85eee6 in __cxxabiv1::__terminate (handler=<optimized out>)
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38
#4  0x00000036ff85ef13 in std::terminate ()
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#5  0x00000036ff85f13f in __cxxabiv1::__cxa_throw (obj=0x526e490, 
    tinfo=<optimized out>, dest=<optimized out>)
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:84
#6  0x0000000004cb1541 in boost::throw_exception<std::overflow_error> (e=...)
    at /usr/include/boost/throw_exception.hpp:67
#7  0x0000000004cb7f28 in boost::math::policies::detail::raise_error<std::overflow_error, long double> (
    function=0x4d2d338 ""boost::math::erfc_inv<%1%>(%1%, %1%)"", 
    message=0x4d1bf8e ""Overflow Error"")
    at /usr/include/boost/math/policies/error_handling.hpp:95
#8  0x0000000004cb7f98 in boost::math::policies::detail::raise_overflow_error<long double> (function=<optimized out>, message=<optimized out>)
    at /usr/include/boost/math/policies/error_handling.hpp:211
#9  0x0000000004cdf17e in raise_overflow_error<long double, boost::math::policies::policy<boost::math::policies::promote_float<false>, boost::math::policies::promote_double<false>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> > (message=0x0, 
    function=<optimized out>)
    at /usr/include/boost/math/policies/error_handling.hpp:515
#10 boost::math::erfc_inv<long double, boost::math::policies::policy<boost::math::policies::promote_float<false>, boost::math::policies::promote_double<false>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> > (z=0, z@entry=0, pol=...)
    at /usr/include/boost/math/special_functions/detail/erf_inv.hpp:383
#11 0x0000000004cdfaae in boost::math::detail::erf_inv_initializer<long double, boost::math::policies::policy<boost::math::policies::promote_float<false>, boost::math::policies::promote_double<false>, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy> >::init::do_init () at /usr/include/boost/math/special_functions/detail/erf_inv.hpp:347
#12 0x0000000004cda34b in init (this=<optimized out>)
    at /usr/include/boost/math/special_functions/detail/erf_inv.hpp:332
#13 __static_initialization_and_destruction_0 (
    __initialize_p=__initialize_p@entry=1, __priority=__priority@entry=65535)
    at /usr/include/boost/math/special_functions/detail/erf_inv.hpp:367
#14 0x0000000004cda463 in _GLOBAL__sub_I_fit.cpp(void) ()
    at ../../fityk/fit.cpp:643
#15 0x00000036fb00f2ea in call_init (l=<optimized out>, argc=argc@entry=1, 
    argv=argv@entry=0xffefffc48, env=env@entry=0xffefffc58) at dl-init.c:82
#16 0x00000036fb00f3d3 in call_init (env=<optimized out>, 
    argv=<optimized out>, argc=<optimized out>, l=<optimized out>)
    at dl-init.c:34
#17 _dl_init (main_map=0x36fb221168, argc=1, argv=0xffefffc48, env=0xffefffc58)
    at dl-init.c:130
#18 0x00000036fb00122a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
}}}",Marcin Wojdyr <wojdyr@…>
10002,No swap for mapped_vector::reference,uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2014-05-02T16:19:21Z,2014-05-02T16:19:21Z,"Hi.

When compiling the following code
{{{#!c++
#include <boost/numeric/ublas/lu.hpp>
#include <boost/numeric/ublas/matrix.hpp>
#include <boost/numeric/ublas/vector_sparse.hpp>

void f(boost::numeric::ublas::matrix<double> &m,
       boost::numeric::ublas::permutation_matrix<unsigned long> &pm,
       boost::numeric::ublas::mapped_vector<double> &v) {
    boost::numeric::ublas::lu_substitute(m, pm, v);
}
}}}

with gcc 4.7 on linux, I get a compile error which at its core has

/usr/include/boost/numeric/ublas/lu.hpp:71:17: error: no matching function for call to ‘swap(boost::numeric::ublas::mapped_vector<double>::reference, boost::numeric::ublas::mapped_vector<double>::reference)’

Shouldn't this be an allowed use of the classes involved?
",Christian Adaker <christian.adaker@…>
9991,WConversion issue in json_parser_write.hpp,property_tree,Boost 1.54.0,To Be Determined,Bugs,Sebastian Redl,assigned,2014-05-02T06:21:11Z,2016-02-10T13:04:37Z,"File Name:
1_54_0/boost/property_tree/detail/json_parser_write.hpp

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

Problematic code:
           else
            {
                const char *hexdigits = ""0123456789ABCDEF"";
                typedef typename make_unsigned<Ch>::type UCh;
                unsigned long u = (std::min)(static_cast<unsigned long>(
                                                 static_cast<UCh>(*b)),
                                             0xFFFFul);

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

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

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

the above need to be fixed.",abhi.california@…
9984,range iterator failing to model forward_iterator,iterator,Boost 1.55.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-05-01T12:06:31Z,2014-09-19T04:11:26Z,"The following code snippet passes successfully with GCC 4.9, but Clang 3.5 (installed from MacPorts) fails to accept std::next.

The symptoms are somewhat alike #9431, but I have no idea if it's the same issue.  According to the code of irange, I guess the problem is rather with Boost.Iterator.

{{{
$ cat bar.cc
#include <boost/range/irange.hpp>

int main()
{
  auto range = boost::irange<int>(0, 10);
  auto i = std::begin(range);
  auto j = std::next(i);
  std::cerr << *j << std::endl;
}
$ clang++-mp-3.5 -std=c++11 -I /opt/local/include bar.cc
bar.cc:7:12: error: no matching function for call to 'next'
  auto j = std::next(i);
           ^~~~~~~~~
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/iterator:514:25: note: candidate template
      ignored: disabled by 'enable_if' [with _ForwardIter =
      boost::range_detail::integer_iterator<int>]
     typename enable_if<__is_forward_iterator<_ForwardIter>::value>::type* = 0)
                        ^
1 error generated.
$ g++-mp-4.9 -std=c++11 -I /opt/local/include bar.cc
}}}
",Akim Demaille <akim.demaille@…>
9971,Use constexpr for boost::mpl::c_str::value when possible.,mpl,Boost Development Trunk,To Be Determined,Patches,Aleksey Gurtovoy,new,2014-05-01T11:23:47Z,2014-05-01T11:23:47Z,"Right now boost::mpl::c_str::value is a static const member variable.
I think it is a decent idea to add the constexpr keyword here.

I have a patch for this issue. Here is an example why it is useful:

{{{
#include<boost/mpl/string.hpp>
int main() {
    using H = boost::mpl::string<'h'>;
    static_assert(boost::mpl::c_str<H>::value[0] == 'h', """");
}
}}}

Without my patch, compiler will complain we could not use c_str::value in constant expression. With my patch, compiler will accept this code.

Tested in clang++ 3.4, CentOS 6.3, but I think GCC should works as well.",ytj000@…
9969,When interior ring of polygon touches exterior,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-04-30T21:38:20Z,2014-04-30T21:38:20Z,"For boost::geometry::intersects and boost::geometry::intersection when a polygon's interior ring touches the exterior ring both functions throw `boost::geometry::overlay_invalid_input_exception`. Example geom:
POLYGON ((-89.58781362007169 48.00097751710655, -89.58781362007169 48.00065167807103, -89.5881394591072 48.00065167807103, -89.58846529814272 48.000    65167807103, -89.58846529814272 48.00032583903552, -89.5881394591072 48.00032583903552, -89.5881394591072 48, -89.58651026392963 48, -89.58651026392    963 48.00032583903552, -89.5861844248941 48.00032583903552, -89.5861844248941 48.00065167807103, -89.58683610296514 48.00065167807103, -89.586836102    96514 48.00097751710655, -89.58781362007169 48.00097751710655), (-89.58781362007169 48.00065167807103, -89.58781362007169 48.00032583903552, -89.587    16194200065 48.00032583903552, -89.58716194200065 48.00065167807103, -89.58781362007169 48.00065167807103))

Throws when intersecting with box,ring,polygon,multi_polygon other geometries untested",ajoseph4@…
9968,[filesystem] Streams don't handle unicode file name on Windows,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-04-30T20:56:08Z,2017-09-25T02:28:15Z,"I want to read / write a file with a unicode file name using boost filesystem, boost locale on Windows (mingw).

This is my code:

#include <boost/locale.hpp>
#define BOOST_NO_CXX11_SCOPED_ENUMS
#include <boost/filesystem.hpp>
#include <boost/filesystem/fstream.hpp>
namespace fs = boost::filesystem;

#include <string>
#include <iostream>

int main() {

  std::locale::global(boost::locale::generator().generate(""""));
  fs::path::imbue(std::locale());

  fs::path file(""äöü.txt"");
  if (!fs::exists(file)) {
    std::cout << ""File does not exist"" << std::endl;
  }

  fs::ofstream(file, std::ios_base::app) << ""Test"" << std::endl;
}

The fs::exists really checks for a file with the name äöü.txt. But the written file has the name äöü.txt.

Reading gives the same problem. Using fs::wofstream doesn't help either, since this just handles wide input.

So it seems the behaviour of fs::ofstream is off.",mike@…
9966,exponential_distribution returns negative zero,random,Boost 1.48.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-30T10:23:40Z,2015-02-27T23:13:00Z,"The code below produces this output:

1.72296[[BR]]
-0[[BR]]
0.295209[[BR]]
0.210905[[BR]]
0.930678[[BR]]

{{{
#!c++
#include <fstream>
#include <boost/random.hpp>

using namespace boost::random;
using namespace std;

int main() {
    ifstream mtfile;
    mtfile.open(""mt.dat""); //see attached file
    mt19937 mt;
    mtfile >> mt;
    mtfile.close();

    for (int i = 0; i < 5; ++i) {
        cout << exponential_distribution<float>(1.f)(mt) << endl;
    }

    return 0;
}

}}}
",mazzamuto@…
9959,boost::date_time::date addition/subtraction assignment operators,date_time,Boost 1.55.0,To Be Determined,Bugs,az_sw_dude,new,2014-04-28T15:11:22Z,2014-04-28T15:11:22Z,"Is there a reason why the += and -= operators of boost::date_time::date return a copy instead of a reference to the current object? Usually I would always expect a reference to be returned for any implementation of these operators.

Thank you for your answers.",s.swiercy@…
9958,issue with modularized contrib/boost.jam,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2014-04-27T20:30:53Z,2014-04-27T20:30:53Z,"The contrib/boost.jam module does not seem to work properly for /boost//headers library in the 'develop' branch of the modularized git repository.  The rest of the targets seem to work properly.

Please find a small example attached that does not work properly (relative to the pre-modularized boost versions).
",tabsoftwareconsulting@…
9954,[ublas] fixed_vector<> broken for msvc-12.0,uBLAS,Boost Development Trunk,To Be Determined,Bugs,Gunter,new,2014-04-25T20:35:08Z,2015-01-23T00:59:09Z,"fixed_vector<> is broken on msvc-12.0 due to the use of constexpr. This heyword is not suported by this compiler.

BOOST_UBLAS_CPP_GE_2011 macro is used to enable/disable the whole class (wrongly on msvc-12.0) instead of enabling only some parts of the code as it's done in other libraries.

Another thing is that fixed_vector<> is only available on some compilers which allows the users to write non-portable code.

Variadic templates may be emulated with Boost.Preprocessor, e.g. see how emplace_back() is implemented in boost::container::vector<> :

https://github.com/boostorg/container/blob/develop/include/boost/container/vector.hpp lines 1309-1380.

constexpr may be conditionally used e.g. by one of macros defined in Boost.Config:

http://www.boost.org/doc/libs/1_55_0/libs/config/doc/html/boost_config/boost_macro_reference.html#boost_config.boost_macro_reference.macros_that_allow_use_of_c__11_features_with_c__03_compilers",awulkiew
9953,lazy_enable_if is not sfinae friendly,core,Boost 1.55.0,To Be Determined,Feature Requests,Peter Dimov,new,2014-04-25T10:53:02Z,2017-07-08T20:37:35Z,"The following code fails to compile, even though boost::result_of itself is sfinae friendly.
{{{
template < typename T >
typename boost::lazy_enable_if_c<
  boost::is_class<T>::value,
  boost::result_of<T(int)>
>::type
test(int){}

template < typename >
void test(...) {}

struct A{}; // boost::result_of<A(int)> is a valid type that doesn't have a member called ""type""

int main(int argc, const char * argv[])
{
  test<A>(0); // test<A>(int) meant to be a substitution failure
  return 0;
}
}}}
I'm not sure if this is a bug/flaw, or a lack of feature, or maybe this kind of use is deliberately disallowed for some reason, but it could be very useful if {{{lazy_enable_if_c<bool B, typename T>}}} etc support uses when {{{typename T::type}}} itself may cause a substitution failure.

Proposing to change implementation of {{{lazy_enable_if_c}}} and {{{lazy_disable_if_c}}} to:
{{{
template <bool B, class T>
struct lazy_enable_if_c : T {}; // inherits from T

template <class T>
struct lazy_enable_if_c<false, T> {};

template <bool B, class T = void>
struct disable_if_c : T {};  // inherits from T

template <class T>
struct disable_if_c<true, T> {};
}}}

",hui.li@…
9945,Regression test using random number generator incorrectly,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-23T18:35:05Z,2014-06-26T21:48:37Z,"libs/utility/operators_test.cpp loops 1000 times, running a variety of tests on seemingly random values.  However, since the randomizer (boost::minstd_rand) is instantiated inside the loop,  it is re-seeded for each loop, meaning it runs the test 1000x with the exact same values each time.

The randomizer must be instantiated outside the loop.
",chris.cooper@…
9944,Regression test relies on undefined compiler behavior,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-23T18:24:48Z,2014-06-26T21:54:56Z,"libs/utility/numeric_traits_test.cpp generates values complement_traits<Number>::min using a clever recursive template, but that template relies on left-shifting a negative value, and according to the C++11 standard that’s a no-no (“the behavior is undefined”) which means it’s not a constant expression, which means it can’t be calculated at compile time, which means the BOOST_STATIC_ASSERT in line 332 won’t compile, saying “static_assert expression is not an integral constant expression” (I’m using clang++). 

The only use for the clever templates, as the comment in the file says, is for ""platforms without <limits> support"" so my proposed fix is:

#ifndef BOOST_NO_LIMITS 
template <class Number> struct complement_traits
{
    BOOST_STATIC_CONSTANT(Number, min = std::numeric_limits<Number>::min());
    BOOST_STATIC_CONSTANT(Number, max = std::numeric_limits<Number>::max());
};
#else
[SNIP] All of the other template definitions for complement_traits, complement_traits_aux, etc.
#endif
",chris.cooper@…
9943,Possible error in MSM state machine docs,msm,Boost 1.55.0,To Be Determined,Bugs,Christophe Henry,new,2014-04-23T17:47:38Z,2014-05-26T21:50:04Z,"http://www.boost.org/doc/libs/1_55_0/libs/msm/doc/HTML/ch01.html

typedef player p; // makes transition table cleaner 
  struct transition_table : mpl::vector11< 
  //    Start     Event        Target      Action                       
  //   +---------+------------+-----------+---------------------------+ 
    row< Stopped , play       ,  Playing  , &p::start_playback        >,

The word ""Start"" should probably be ""State"".",Fred Weed <fweed@…>
9939,"Patch to add ""no exceptions"" support to dynamic_bitset",dynamic_bitset,Boost 1.55.0,Boost 1.56.0,Patches,acharles,assigned,2014-04-22T22:09:13Z,2014-08-21T14:47:23Z,"This patch adds support for compiling with exceptions disabled by using BOOST_TRY/BOOST_CATCH etc.
",Boleslaw Ciesielski <bolek@…>
9935,Support edge multiplicity in brandes_betweenness_centrality,graph,Boost Development Trunk,To Be Determined,Feature Requests,Jeremiah Willcock,new,2014-04-22T09:26:18Z,2014-04-25T09:13:44Z,"There are several possible variations to the Brandes algorithm for the calculation of the betweenness centrality. Several of them were compiled by Brandes himself on his paper [http://www.inf.uni-konstanz.de/algo/publications/b-vspbc-08.pdf ""On variants of shortest-path betweenness centrality and their generic computation""].

I need to compute one of these variations, in particular the one which considers edge multiplicities, understood as an edge property representing the frequency or the amount of times a relationship happens. This variation introduces a quite small change in the algorithm, as explained in the section 3.8, algorithm 11 of the referenced paper.

I was thinking of introducing this functionality in the graph library. I roughly know where and what should be added or modified (namely `<boost/graph/betweenness_centrality.hpp>` and `<boost/graph/distributed/betweenness_centrality.hpp>`), although I have never made modifications to any Boost library, so I would probably need some advice. Basically, I consider three options:

* Adding a third version of the algorithm, parallel to the Dijkstra and the unweighted version (which would not consider weights).
* Add two versions of the algorithm, one based on the Dijsktra version (considering weights) and another based on the unweighted version.
* Modify both existing implementations of the algorithm, adding an optional map holding the edge multiplicity with a constant value of one by default.

However, I don't know if there is interest in adding this kind of feature to the library, or if it is too specific to be considered useful. Another option would be to expose some interface to be able to inject your own variation of the algorithm from your application, but that would be way more complex to develop, use and document, and probably there would always be uncovered cases.

Just for the record, there is actually a way to make computation with the current implementation, if the edge multiplicities are integers (which is not always true), simply replacing each edge with a number of parallel edges equal to its multiplicity (if the current implementation works for multigraphs, which I think is the case). However, this obviously increases (potentially a lot) the time and space complexity of the already CPU-intensive betweenness calculation.",Javier Dehesa <javidcf@…>
9934,Intersection of convex hulls leads to self intersecting polygon,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-04-22T07:56:45Z,2014-04-22T10:59:33Z,"This might be a duplicate of #8419, #9081, or #9909.

Please see here:
http://stackoverflow.com/questions/23157391/taking-intersections-of-convex-hulls-in-boostgeometry

I ran into the same problems with using double coordinates instead of integer ones and thought switching to integer ones would be a sufficient workaround.",anonymous
9926,Invalid limition for Sun compilers in foreach.hpp,foreach,Boost 1.55.0,To Be Determined,Bugs,Eric Niebler,new,2014-04-18T19:59:58Z,2014-04-18T19:59:58Z,"{{{
File boost/foreach.hpp defines the macro BOOST_FOREACH_NO_CONST_RVALUE_DETECTION
for various compiler versions, including for __SUNPRO_CC, >= 0x5100 (at line 63)

This restriction does not seem to be needed for compilers currently supported.
Please remove this line, thus allowing the macro
BOOST_FOREACH_RUN_TIME_CONST_RVALUE_DETECTION to be defined.
}}}",Stephen Clamage <stephen.clamage@…>
9925,operators_test.cpp test_left_shiftable is failing due to invalid parameters,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-18T18:28:38Z,2014-06-26T21:59:15Z,"In libs/utility/operators_test.cpp, test_left_shiftable is checking whether one random value shifted by a second random value, is the same whether called directly or via the Wrapper2<> and Wrapper1<> template classes.

However, according to C++ ISO specification (INCITS/ISO/IEC 14882-2011\[2012\]), section 5.8.2 (which I don't have, but is referenced at http: / / msdn.microsoft.com/en-us/library/336xbhcz.aspx), left-shifting a signed value has undefined behavior (which is much more unpleasant than implementation-defined behavior) if the result doesn't fit in an unsigned value of the same size.

With the clang compiler that comes with Xcode 5.1 (""Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)""), the results of such left-shifts are seemingly random - this code:

{{{
long b1 = 48271;
int s = 1291394886; 
std::cout << (b1 << s) << std::endl;
std::cout << (b1 << s)<< std::endl;
std::cout << (b1 << s)<< std::endl;
}}}


prints three different numbers.",chris.cooper@…
9919,xml_parser::read_xml() and write_xml() are limited to std::string keys,property_tree,Boost 1.54.0,To Be Determined,Patches,Sebastian Redl,new,2014-04-18T02:37:50Z,2014-04-18T02:37:50Z,"boost::property_tree::xml_parser and json_parser are hardcoded to work only with keys of std::string type.  

The following code will fail to compile:

boost::property_tree::basic_ptree<boost::container::string, boost::container::string> pt;
std::string filename(""123.xml"");
boost::property_tree:xml_parser::read_xml(filename, pt);

I have prepared a patch 8af8b6bf3b65fa59792d849b526678f176d87132 that removes this limitation and added a pull request on github",sanderb@…
9912,shared_ptr SEGV in Android debug builds,smart_ptr,Boost 1.55.0,To Be Determined,Bugs,Peter Dimov,new,2014-04-15T18:26:50Z,2014-04-21T17:01:49Z,"Hi,

I get a SEGV in the shared_ptr ref counting code on Android debug builds. Release builds do not have this problem.

Instructions:
1. Install ndk (I used r9d 64-bit mac)
1. Ensure ndk-build is on your path
1. Download the attached sample program
1. Run build.sh
1. Install the executable on an Android device (I used a Nexus 7).


As provided, you should get a SEGV in the sp_counted_base code.

There are two ways to fix this:
1. Remove APP_OPTIM=debug from build.sh
1. Enable # LOCAL_CPPFLAGS := -DBOOST_SP_USE_PTHREADS in Android.mk

Notes:

Android debug builds disable the -mthumb option and instead use -marm. Ultimately this affects spinlock.hpp
{{{
#elif defined(__GNUC__) && defined( __arm__ ) && !defined( __thumb__ )
#  include <boost/smart_ptr/detail/spinlock_gcc_arm.hpp>
 
//code omitted
 
#elif defined(BOOST_HAS_PTHREADS)
#  include <boost/smart_ptr/detail/spinlock_pt.hpp>
}}}
So release builds use spinlock_pt.hpp and debug builds use spinlock_gcc_arm.hpp",ian@…
9909,boost::geometry::intersection on two polygons returns incorrect result in one case,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-04-15T14:03:32Z,2014-04-15T14:04:59Z,"Hi,

There is problem with intersection of 2 BoostMultiPolygons. Result consisted of only one poly, but should contain 2.
Our boost version is 1.55. We use MS VS 2005.

Regards, Roman.

Source:
{{{
typedef boost::geometry::model::d2::point_xy<double>			BoostPoint;
typedef boost::geometry::model::ring<BoostPoint, true>			BoostRing;
typedef boost::geometry::model::polygon<BoostPoint, true>		BoostPolygon;
typedef boost::geometry::model::multi_polygon<BoostPolygon>		BoostMultiPolygon;

std::ifstream in(""input.txt"");

BoostMultiPolygon mpSrc1, mpSrc2, mpRes;
int polyCount;
in>>polyCount;
for (int i=0;i<polyCount;i++)
{
	int pointCount;
	in>>pointCount;
	BoostPolygon curPolygon;
	BoostRing curRing;
	for(int j=0;j<pointCount;j++)
	{
		double x,y;
		in>>x>>y;
		curRing.push_back(BoostPoint(x,y));
	}
	curPolygon.outer() = curRing;
	mpSrc1.push_back(curPolygon);
}
in>>polyCount;
for (int i=0;i<polyCount;i++)
{
	int pointCount;
	in>>pointCount;
	BoostPolygon curPolygon;
	BoostRing curRing;
	for(int j=0;j<pointCount;j++)
	{
		double x,y;
		in>>x>>y;
		curRing.push_back(BoostPoint(x,y));
	}
	curPolygon.outer() = curRing;
	mpSrc2.push_back(curPolygon);
}
boost::geometry::intersection(mpSrc1, mpSrc1, mpRes); // mpRes contain only 1 poly.
}}}

Contaiment of input.txt :
{{{
2
27
1.7795412086922593 -0.6928106373008438
1.7891900856407261 -0.73346701678889104
1.8205003053203772 -0.93531819320144416
1.8121292936644648 -1.1807879269729795
1.7394808987253128 -1.4154103358489794
1.6076723780308959 -1.6226589254855832
1.4259881506704424 -1.7879353774152118
1.2072258150073207 -1.8995978354269698
0.96679470265783485 -1.9497809426285055
0.72163046540975617 -1.934949866855677
0.60267613336191828 -1.8966346198312143
0.41731164084513261 -1.7901953365848997
0.27656953156479103 -1.6293196865339519
0.19571165090939757 -1.4314527634772853
0.18350609592762368 -1.2180509346857271
0.24127641714720549 -1.0122551473377328
0.36470663256680463 -0.8348324228970293
0.67786452669735997 -0.60942974505933833
0.76516102039389844 -0.55513726961522536
0.81184032592082556 -0.52936777403881374
0.9456140934360856 -0.46301076844880257
1.0715439430748541 -0.41043054738175999
1.2051029188121665 -0.39184926061543224
1.3438936378781083 -0.42743758887205224
1.4793480212800743 -0.49201773445646352
1.6124976944936933 -0.5720053785043937
1.7795412086922593 -0.6928106373008438
21
1.1615462164308124 1.9754373027139951
1.5360149764505899 1.886934666316108
1.7087948729537776 1.8041724959027103
1.8362554271519613 1.661147055471015
1.8986519852214538 1.4800141235445734
1.8863188239381428 1.2888326322334416
1.8011664480979825 1.1172181154349941
1.6563856381255915 0.99175502703475193
1.4722208702867912 0.93196155014586246
1.3307251338101709 0.96302852254101112
1.1889015041869535 1.0063804359754345
1.0851554485208663 1.0419536723519502
0.9303284683690195 1.1007328938955687
0.86940784993802189 1.126033284720011
0.73031572956801372 1.2427081650372707
0.64785873725084664 1.4044502129533221
0.63514254042735985 1.5855522394036576
0.69418824418515901 1.7572299913513629
0.81561115796600125 1.8921971045865578
0.98011239294323005 1.9690019829279639
1.1615462164308124 1.9754373027139951
2
27
0.4022007544928915 -0.79320935498558631
0.67786021968757104 -0.59223694917595526
0.72926567327554304 -0.56003487788773432
0.83396700970889248 -0.50259243802045006
0.94559413155101379 -0.44613850745202116
1.0715439430748541 -0.39325208386734267
1.2051029188121665 -0.36717869475972431
1.2079466156233769 -0.36787014029848375
1.383100956224427 -0.42804360792267371
1.5711416115100447 -0.55533336824076429
1.5817841916061597 -0.56708324300601975
1.712343915281392 -0.71850008854626279
1.8205003053203772 -0.93531819320144416
1.812129293664464 -1.1807879269729791
1.7394808987253114 -1.4154103358489782
1.6076723780308948 -1.6226589254855814
1.4259881506704415 -1.7879353774152098
1.2072258150073203 -1.899597835426968
0.96679470265783507 -1.9497809426285047
0.72163046540975617 -1.934949866855677
0.53668372332048819 -1.8329698805024297
0.38798986558594484 -1.6829853756425535
0.28761203927878709 -1.4971642062029744
0.24369363713914372 -1.2905815617733336
0.25979764523973214 -1.0799969565688248
0.33461758716561152 -0.88249457350408611
0.4022007544928915 -0.79320935498558631
24
0.69106840510193146 1.7283118331970613
0.80491403567959896 1.8636891961105639
0.97252446578255225 1.9537292239908663
1.1615462164308124 1.9754373027139951
1.445329131723774 1.9083675258739219
1.6295697181486921 1.8205585564967293
1.778913808591188 1.6814494215012656
1.87956003859109 1.503895640420464
1.9222073685313958 1.304305525338967
1.908582733892098 1.1608175914897563
1.9058154916000392 1.1489111215390388
1.8042808050307477 0.99216149052586733
1.6864779577548399 0.90268670286901209
1.5974991741674556 0.89671357054168577
1.4640547165764142 0.9042573086441501
1.3308383768494927 0.94117823976176729
1.1908244144294404 0.99088339761011279
1.0620930550951979 1.0410213286408192
0.93028741744520127 1.0862837299344523
0.9007363188137486 1.0981042670180636
0.7529401342681733 1.21045558001871
0.66108738214900509 1.3717924996227908
0.6399134449656606 1.5562327178056883
0.69106840510193146 1.7283118331970613
}}}
",romanp@…
9905,Compile error in /libs/utility/assert_test.cpp,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2014-04-14T19:24:00Z,2014-04-23T11:01:48Z,"Compiling this file using clang++ (from Apple LLVM version 5.1) with c++11 features enabled, fails.

Command line:

  ""clang++"" -x c++ -std=c++11 -stdlib=libc++ -O3 -O3 -finline-functions -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I""../../.."" -c -o ""/tmp/boost/bin.v2/libs/utility/test/assert_test.test/clang-darwin-4.2.1/release/link-static/threading-multi/assert_test.o"" ""../assert_test.cpp""

Error:

../assert_test.cpp:86:13: error: out-of-line definition of 'assertion_failed_msg' does not match any declaration in namespace 'boost'

Solution:

Replace

void boost::assertion_failed_msg([SNIP]) { [SNIP] }

with

namespace boost
{

void assertion_failed_msg([SNIP]) { [SNIP] }

}
",chris.cooper@…
9903,patch for GCC -Wundef warning in utility/result_of.hpp,utility,Boost Release Branch,To Be Determined,Patches,No-Maintainer,new,2014-04-14T15:08:43Z,2014-04-14T15:08:43Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9902,patch for GCC 4.8 -Wunused-local-typedefs warning in tuple/detail/tuple_basic.hpp,tuple,Boost Release Branch,To Be Determined,Patches,Joel de Guzman,new,2014-04-14T15:06:35Z,2014-04-16T16:05:58Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",anonymous
9900,patch for GCC -Wshadow warnings in spirit/home/classic,spirit,Boost Release Branch,To Be Determined,Patches,Joel de Guzman,new,2014-04-14T15:01:23Z,2014-04-14T15:01:23Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9898,patch for GCC -Wshadow warnings in random,random,Boost Release Branch,To Be Determined,Patches,No-Maintainer,new,2014-04-14T14:53:56Z,2014-04-15T03:05:52Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9897,patch for GCC -Wunused-parameter warnings in ptr_container,ptr_container,Boost Release Branch,To Be Determined,Patches,Thorsten Ottosen,new,2014-04-14T14:50:59Z,2014-04-14T14:50:59Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9896,patch for GCC -Wextra warning in ptr_container/ptr_map_adapter.hpp,ptr_container,Boost Release Branch,To Be Determined,Patches,Thorsten Ottosen,new,2014-04-14T14:46:58Z,2014-04-14T14:46:58Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9895,patch for GCC -Wignored-qualifiers warnings in ptr_container/detail/map_iterator.hpp,ptr_container,Boost Release Branch,To Be Determined,Patches,Thorsten Ottosen,new,2014-04-14T14:45:01Z,2014-04-14T14:45:01Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9894,patch for GCC -Wshadow warnings in ptr_container,ptr_container,Boost Release Branch,To Be Determined,Patches,Thorsten Ottosen,new,2014-04-14T14:42:42Z,2014-04-14T14:42:42Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9893,patch for Clang -Wtautological-constant-out-of-range-compare in property_tree/detail/json_parser_write.hpp,property_tree,Boost Release Branch,To Be Determined,Patches,Sebastian Redl,new,2014-04-14T14:39:18Z,2014-04-22T11:12:01Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9892,patch for GCC -Wshadow warnings in property_tree,property_tree,Boost Release Branch,To Be Determined,Patches,Sebastian Redl,new,2014-04-14T14:36:01Z,2014-04-14T14:36:01Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9885,path to suppress MSVC 2008 warning C4510 in multi_array/concept_checks.hpp,multi_array,Boost Release Branch,To Be Determined,Patches,Ronald Garcia,new,2014-04-14T13:05:24Z,2014-04-28T17:06:47Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9881,patch for GCC -Wshadow warnings in crc.hpp,crc,Boost Release Branch,To Be Determined,Patches,Daryle Walker,new,2014-04-14T12:51:11Z,2014-04-14T12:51:11Z,"upstreaming patch from LibreOffice project, to fix compiler warnings",mstahl@…
9877,freelist test crashes on Linux/GCC/release/x86,lockfree,Boost Development Trunk,To Be Determined,Bugs,timblechmann,new,2014-04-13T10:33:02Z,2014-04-23T13:09:39Z,"Hello,

on a Redhat 6.5 system with GCC 4.4.7 I compiled the latest trunk with these parameters: ''toolset=gcc architecture=x86 address-model=32 variant=release''

I get the following error in the testsuite:
{{{
unknown location(0): fatal error in ""fixed_size_freelist_test"": memory access violation at address: 0x1c93bbed: no mapping at fault address
freelist_test.cpp(113): last checkpoint
}}}

{{{
(gdb) bt
#0  0x0805d652 in boost::lockfree::queue<dummy*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::push(dummy* const&) ()
#1  0x0805f1f2 in freelist_tester<boost::lockfree::detail::fixed_size_freelist<dummy, boost::lockfree::detail::runtime_sized_freelist_storage<dummy, std::allocator<dummy> > >, true>::allocate() ()
#2  0x08054367 in boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, freelist_tester<boost::lockfree::detail::fixed_size_freelist<dummy, boost::lockfree::detail::runtime_sized_freelist_storage<dummy, std::allocator<dummy> > >, true> >, boost::_bi::list1<boost::_bi::value<freelist_tester<boost::lockfree::detail::fixed_size_freelist<dummy, boost::lockfree::detail::runtime_sized_freelist_storage<dummy, std::allocator<dummy> > >, true>*> > > >::run()
    ()
#3  0x00125b26 in thread_proxy () from /uhome/gjasny/src/modular-boost/bin.v2/libs/thread/build/gcc-4.4.7/release/address-model-32/architecture-x86/threading-multi/libboost_thread.so.1.56.0
#4  0x00cd1b39 in start_thread () from /lib/libpthread.so.0
#5  0x00c14d6e in clone () from /lib/libc.so.6
}}}

I an **not** able to reproduce the crash in x86 debug mode or any x64 mode.

{{{
[gjasny@drsbuild05.drs atomic]$ git describe
fatal: No tags can describe '95c083ddfd990f7c848b785e5a0e9d282da5359b'.
Try --always, or create some tags.


[gjasny@drsbuild05.drs lockfree]$ git describe
fatal: No tags can describe '8ffc9b3f26cd5802655ceb7d4188911f1cf7067d'.
Try --always, or create some tags.
}}}

Thanks,
Gregor",gjasny@…
9874,turning off 'include_next' support breaks includes,wave,Boost 1.55.0,To Be Determined,Bugs,Hartmut Kaiser,new,2014-04-13T01:09:34Z,2014-04-13T01:09:34Z,"The directive '#if BOOST_WAVE_SUPPORT_INCLUDE_NEXT !+ 0"" in file cpp_re2_lexer.hpp is in the wrong place, and causes all #include processing to break if BOOST_WAVE_SUPPORT_INCLUDE_NEXT is set to 0.

I've attached a simple patch.",jon@…
9873,Boost.Geometry: boost::geometry::convex_hull makes a convex polygon look concave for certain values,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-04-11T12:12:13Z,2016-08-24T12:32:31Z,"The goal is to determine if a polygon is convex. boost::geometry::convex_hull can be used to so: if the polygon equals that points, it is convex. 

However, convex_hull does make a convex polygon look concave for certain values.

I found that for these values, convex_hull work as expected:
 * (15.0,631.0)
 * ( 8.0,628.0)
 * ( 8.0,679.0)
 * (15.0,682.0)
I found that for these values, convex_hull work does not work as expected:
 * (15.9835,631.923),
 * (8.24075,628.579),
 * (8.24075,679.58 ),
 * (15.9835,682.926)

Below is the main portion of the code, including comments and assert statements. 

I am using:
 * OS: Lubuntu (with all updates) and Windows 7 (with all updates)
 * GCC: 4.8.0
 * Boost 1.55.0
 * Qt Creator 2.8.1 with Qt 5.1.

Full code can be viewed at GitHub -> project ProjectRichelBilderbeek -> folder Test -> folder CppBoostGeometryExample7 -> code there.

{{{
#include <cassert>
#include <iostream>

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored ""-Weffc++""
#pragma GCC diagnostic ignored ""-Wunused-local-typedefs""
#pragma GCC diagnostic ignored ""-Wunused-variable""
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#pragma GCC diagnostic pop

//Goal: determine if a polygon, derived from points, is convex
//Method: if the convex_hull equals that points, it is convex
//
//Bug: convex_hull does make a convex polygon look concave for certain values
int main()
{
  using namespace boost::geometry;
  typedef model::d2::point_xy<double> Point;
  typedef model::polygon<Point> Polygon;

  //Example A: works as expected
  {
    /* Polygon used:

      -
      |
      -  2---3
      |  |
      -  1---0
      |
      +--|---|---|

    (point values are those simplified from example B)

    */
    const std::vector<Point> points {
        {15.0,631.0},
        { 8.0,628.0},
        { 8.0,679.0},
        {15.0,682.0}
    };

    Polygon polygon;
    append(polygon, points);

    assert(boost::geometry::num_points(polygon) == 4);

    boost::geometry::correct(polygon);

    assert(boost::geometry::num_points(polygon) == 5
      && ""OK: boost::geometry::correct adds a point"");

    Polygon hull;
    boost::geometry::convex_hull(polygon, hull);

    assert(boost::geometry::num_points(hull) == 5
      && ""OK: the hull of a convex polygon has the same number of points as that polygon"");
    assert(boost::geometry::equals(polygon,hull));
  }

  //Example B: does not work as expected
  {
    /* Polygon used:

      -
      |
      -  2---3
      |  |
      -  1---0
      |
      +--|---|---|


    */
    const std::vector<Point> points {
        {15.9835,631.923},
        {8.24075,628.579},
        {8.24075,679.58 },
        {15.9835,682.926}
    };

    Polygon polygon;
    append(polygon, points);
    assert(boost::geometry::num_points(polygon) == 4);

    boost::geometry::correct(polygon);

    assert(boost::geometry::num_points(polygon) == 5
      && ""OK: boost::geometry::correct adds a point"");

    Polygon hull;
    boost::geometry::convex_hull(polygon, hull);

    assert(boost::geometry::num_points(hull) == 6
      && ""Should not add an extra point, as the original polygon was convex"");

    assert(!boost::geometry::equals(polygon,hull)
      && ""Should be equal, but does not"");
  }
}
}}}",richel@…
9872,brandes_betweenness_centrality does not work with graph containing disjoint components.,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-04-11T02:14:19Z,2014-04-11T02:14:19Z,"Assertion `get(path_count, w) != 0' failed, 

Assertion fails at the following if the graph contains disjoint components:
boost/graph/distributed/betweenness_centrality.hpp:926

Sample Graph (in metis format):
5 3
2 
1 3
2
5
4 ",Alok Kumbhare <kumbhare@…>
9871,remove_spikes does not remove spike,geometry,Boost 1.66.0,Boost 1.56.0,Bugs,Barend Gehrels,reopened,2014-04-10T14:35:15Z,2018-06-14T10:23:43Z,"The following call...
{{{
boost::geometry::remove_spikes( ""MULTIPOLYGON(((4287 2160,5984 2160)))"" )
}}}
...does not modify the input at all. Given that my polygons are oriented counter-clockwise, '''open''' and based on int, this is a valid multi-polygon that consists of only a spike, which should be removed.

Please refer to discussion at [http://lists.boost.org/geometry/2014/04/2858.php]",Volker Schöch <vschoech@…>
9855,Corruption in container::string when used with boost::interprocess,container,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-04-08T12:27:47Z,2014-05-02T11:19:21Z,"I have found a rather strange problem in Boost.Container which I can only get to show itself when used from Boost.Interprocess.
So the problem may be in either Boost.Container and Boost.Interprocess.

I have a vector of strings (in shared memory). When I push back some of these strings one of them ends up missing its null termination (c_str() returns a string which has a garbage character at the end).

I have tried to work out what the problem is, and my theory is that it is when the vector gets resized and the strings get moved into their new positions. The move semantics make the now ""empty"" strings ""unconstructed"". A new push_back will do an assign onto an unconstructed slot without ""reconstructing"" it. But this is where I get lost in the vector code...

I have a short test program at https://gist.github.com/DonOregano/10116264. Compile and run and it will hopefully print out some information about the error.

It appears that this error happens only on 64bit OSes. And I have only tried it on Linux (recent Ubuntu and Arch).",Lars Hagström <lars@…>
9850,ICL size() is inconsistent with iterators,ICL,Boost 1.54.0,To Be Determined,Bugs,Joachim Faulhaber,new,2014-04-08T00:07:25Z,2014-04-08T00:07:25Z,"Currently size() of an ICL container is not consistent with std::distance( cont.begin(), cont.end() ), which makes it not a model of the standard container concept and is a source of confusion.",Matt Calabrese
9849,shared_memory_object incompatible between x86 to x64 on Windows.,interprocess,Boost Development Trunk,To Be Determined,Bugs,Ion Gaztañaga,new,2014-04-07T17:47:04Z,2014-04-07T17:47:04Z,"The problem is very similar to Ticket #6054 for OSX and a different sub-folder of 
{{{
C:\\ProgramData/boost_interprocess/
}}}
is created for each x86 or x64. It happens in get_bootstamp (tmp_dir_helpers.hpp:45) which generates a different file.

The code is directly defined for OSX in get_bootstamp, but for windows, it goes to windows_semaphore_based_map() constructor (windows_intermodule_singleton.hpp:57) where it behaves differently depending on the size of void*.

If this behavior is an exception, it should be written in the docs, since mixing x64 and x32 seems to work on OSX and Unix and does work with the native windows functions and the windows_shared_memory.",rich@…
9843,binary serializer wrong behaviour treating enums,serialization,Boost 1.55.0,To Be Determined,Bugs,Robert Ramey,reopened,2014-04-07T01:55:11Z,2014-04-14T05:59:39Z,"from iserializer.hpp
template<class Archive>
struct load_enum_type {
    template<class T>
    static void invoke(Archive &ar, T &t){
        // convert integers to correct enum to load
        int i;
        ar >> boost::serialization::make_nvp(NULL, i);
        t = static_cast< T >(i);
    }
};

it tries to load all enums int-sized.
even in this case:
enum class WrongBehaviour : unsigned char
{ };

it reads 4-byte in my case, while 1 byte's expected.",jpjps@…
9841,BOOST_HAS_INTPTR_T is undocumented.,config,Boost 1.54.0,To Be Determined,Bugs,John Maddock,new,2014-04-06T20:22:02Z,2018-07-31T18:34:11Z,Please document BOOST_HAS_INTPTR_T.,anonymous
9830,memory leak in time_duration,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2014-04-02T18:27:53Z,2014-04-10T15:10:44Z,"Hi folks,
this is a leak i've found compiling this very single line:
boost::posix_time::time_duration td(1,0,0,0); cout << td;

valgrind reports the following leak:
==16902== 25 bytes in 1 blocks are possibly lost in loss record 21 of 29
==16902==    at 0x40290AC: operator new(unsigned int) (vg_replace_malloc.c:313)
==16902==    by 0x455BB54: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==16902==    by 0x455CC72: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned int) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==16902==    by 0x455CD10: std::string::reserve(unsigned int) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==16902==    by 0x455CF8C: std::string::append(char const*, unsigned int) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.19)
==16902==    by 0x8079DE9: boost::date_time::time_facet<boost::posix_time::ptime, char, std::ostreambuf_iterator<char, std::char_traits<char> > >::time_facet(unsigned int) (in /home/marcos/release/sandbox/chutaygol)
==16902==    by 0x8084086: std::basic_ostream<char, std::char_traits<char> >& boost::posix_time::operator<< <char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, boost::posix_time::time_duration const&) 

I hope you find a bug with the help of my report
Marcos Mayorga



",mm@…
9827,"Missing support for some code page(e.g 949, 950) in windows conversion with std backend",locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,assigned,2014-04-02T09:55:42Z,2017-07-13T14:51:24Z,"There is a table windows_encoding all_windows_encodings[] in wconv_codepage.ipp. It contains several code page definitions. However, it misses some code pages, such as the Korean code page(949) or Traditional Chinese Big5 code page(950), which will cause an invalid_charset_error when running in that windows for the following code:

{{{
// Assuming we are using the std backend so it supports ansi encodings
boost::locale::generator gen;
gen.use_ansi_encoding(true);

std::locale loc(gen(""""));
// Throws invalid_charset_error when running in Korean windows but OK in English windows.
// The charset is ""windows949"" in Korean windows, which is not in the table.
std::string us = boost::locale::conv::to_utf<char>(""abcdefg"", loc);
}}}

The root cause of this exception is that the generated code page string is not in the table. When the locale generator with std backend in windows platform generates a locale, it calls boost::locale::util::get_system_locale(bool use_utf8). This function will use the following code to generate the locale string(in default_locale.cpp):
{{{
if(GetLocaleInfoA(LOCALE_USER_DEFAULT,LOCALE_IDEFAULTANSICODEPAGE,buf,sizeof(buf))!=0) {
    if(atoi(buf)==0)
        lc_name+="".UTF-8"";
    else {
        lc_name +="".windows-"";
        lc_name +=buf;
    }
}
}}}
So the encoding part of the lc_name is windows-(code page). In a system with Korean(949) or Traditional Chinese(950) code page, this will generate an encoding string like ""windows-949"" or ""windows-950"". However, when wconv_from_utf::open() initializes, it tries to search ""windows949"" or ""windows950"" in array all_windows_encodings[]. Obviously it will not find the string, and the open() fails, then the exception is thrown.

For a quick fix, I suggest adding the missing code page to the table:
{{{
{ ""cp949"",      949, 0 }, // Korean
{ ""uhc"",        949, 0 }, // From ""iconv -l""
{ ""windows949"",         949, 0 }, // Korean
// ""big5"" already in the table
{ ""windows950"",         950, 0 }, // TC, big5
}}}

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

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

This piece of code directly parses and validates the encoding string. The concern is that the call to IsValidCodePage may decrease the performance(not tested).",hucaonju@…
9826,compress boost::property,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-04-01T23:04:08Z,2014-12-06T15:46:49Z,"Hello,

looking at property_map, I noticed that boost::property is wasting space. property<tag,double> will typically have size 16 because of the no_property member. list_edge<Vertex,no_property> will also be too long for the same reason. A proper use of the empty base optimization (possibly through tuple or compressed_pair) should help with this. Partial specializations for no_property may be a simpler alternative.

Graphs can grow large, and it seems quite important to avoid wasting memory.",marc.glisse@…
9825,mutable_heap wan't to construct Compare in assert in increase and decrease function,heap,Boost 1.55.0,To Be Determined,Patches,timblechmann,new,2014-04-01T12:01:42Z,2014-04-01T12:01:42Z,if Compare class don't have default Constructor and code use increase or decrease function then code don't compile.,Piotr Smulewicz <ps262971@…>
9824,boost::filesystem::is_empty() doesn't work with symlinks on Windows,filesystem,Boost 1.56.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-04-01T09:17:13Z,2015-09-10T13:03:43Z,"See the original information on this problem in this Stackoverflow question:

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

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

    hxxps://github.com/monsdar/BoostSymLinkError

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

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

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

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

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

",michael.burr@…
9819,Documentation issue with Boost Graph Library,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-03-31T18:31:08Z,2014-03-31T18:31:08Z,"The documentation (http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/mcgregor_common_subgraphs.html) for the mcgregor_common_subgraphs() function indicates that the only_connected_subgraphs bool comes after the callback function:
{{{
// named parameter version
template <typename GraphFirst,
          typename GraphSecond,
          typename SubGraphCallback,
          typename Param,
          typename Tag,
          typename Rest>
  void mcgregor_common_subgraphs
  (const GraphFirst& graph1,
   const GraphSecond& graph2,
   SubGraphCallback user_callback,
   bool only_connected_subgraphs,
   const bgl_named_params& params);
}}}

However, in the code it actually comes before the callback (from boost/graph/mcgregor_common_subgraphs.hpp):

{{{
  // Named parameter variant of mcgregor_common_subgraphs
  template <typename GraphFirst,
            typename GraphSecond,
            typename SubGraphCallback,
            typename Param,
            typename Tag,
            typename Rest>
  void mcgregor_common_subgraphs
  (const GraphFirst& graph1,
   const GraphSecond& graph2,
   bool only_connected_subgraphs,
   SubGraphCallback user_callback,
   const bgl_named_params<Param, Tag, Rest>& params)
  {

}}}

The examples in the documentation, though, use the working bool-first order.
",Rocco Moretti <rmorettiase@…>
9817,Boost Asio + Visual Studio 2013 crashes without BOOST_ASIO_DISABLE_IOCP,asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-03-31T02:21:42Z,2014-03-31T02:21:42Z,"In a Visual Studio 2013 SP1 Project with 8 executables using boost 
asio, 1 of them crashes in a repetitive way, always at the same point.
The problem is related to memory management and code generation when
win_iocp_socket_service is used. For example the following code, under
very special circumstances, may trigger the crash:

{{{
   tcp::iostream * sss = new tcp::iostream(""mysite.com"", ""80"");
}}}

I realized that everytime it crashes, win_iocp_io_service constructor
is not called. Hence iocp_.handle is not initialized and is 
later used in CreateIoCompletionPort() containing garbage, this being 
the ultimate reason of the crash.

On the other hand, in the processes that work, the constructor is
properly called, as it should always be. => Is there any known
possibility for win_iocp_io_service constructor not being called?
Is there anything like a default constructor that could be called
instead? 

{{{
  main()
  {
     tcp::iostream * sss = new tcp::iostream(""mysite.com"", ""80"");
  }
}}}

The code won't crash. But the following may do if MyClass instantiates
boost::asio::io_service

{{{
  MyClass * myInstance = NULL;

  main()
  {
     if(myInstance) delete myInstance;
     tcp::iostream * sss = new tcp::iostream(""mysite.com"", ""80"");
  }
}}}

Don't expect to be able to reproduce it this way, as I said 
it's difficult to isolate because it probably is related to a bug in 
the compiler that only manifests in very special conditions that
boost asio sometimes trigger. Simply moving lines of code may fix it.


The problem is not in memory management in our source code, that
was my first thought, but all tests suggest it isn't. In addition,
the code has been working for years with boost 1.45 and GCC 4.5. The
only change was moving to Visual Studio 2013 and boost asio 1.55.

To corroborate, I was able to reproduce in a surrealistic way: just
adding or commenting a line in dead code (code that can never be
reached because it is placed after a return) would fix or make the
application crash.

Finally I solved everything by defining BOOST_ASIO_DISABLE_IOCP. 
I didn't change a single line of code. No more crashes since then.

",kasty.jose@…
9816,boost::filesystem::is_empty does not work for symbolic links on Windows,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,assigned,2014-03-30T10:11:13Z,2015-09-10T13:04:38Z,"Hi,

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

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

I at first asked at Stackoverflow for some help:
[http://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks Boost::filesystem::is_empty() returns false for Symlinks]

I also created a Github project which reproduces the problem:
[https://github.com/monsdar/BoostSymLinkError Github - BoostSymLinkError]",Nils Brinkmann <monsdar+boost@…>
9810,boost serialization: deserialization from boost txt archive fails on -nan for double,serialization,Boost 1.55.0,To Be Determined,Feature Requests,Robert Ramey,reopened,2014-03-27T19:20:37Z,2016-03-14T21:31:49Z,"A double gets correctly serialized to ""-nan"". Deserializing it leads to 
'boost::archive::archive_exception'
  what():  input stream error
when used with a text archive.",florian.burkart@…
9808,"bc_clustering: ""has no edges"" identifier not found",graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-03-25T10:54:54Z,2016-08-09T09:14:14Z,"Function has_no_edges(g) is behind graph namespace. Need to attach graph:: indicator before calling this function in bc_clustering.hpp.

{{{
#!div style=""font-size: 80%""
Original library code:
  {{{#!python
 if (has_no_edges(g)) return;
(...)
  do {
(...)
  } while (!is_done && !has_no_edges(g));
  }}}
}}}

{{{
#!div style=""font-size: 80%""
Modified code:
  {{{#!python
 if (graph::has_no_edges(g)) return;
(...)
  do {
(...)
  } while (!is_done && !graph::has_no_edges(g));
  }}}
}}}",Łukasz Ilnicki <lukaszi89@…>
9806,Possible bug in the transposition of a banded matrix (Boost uBLAS library),uBLAS,Boost 1.55.0,To Be Determined,Bugs,Gunter,new,2014-03-24T15:01:07Z,2014-03-24T15:01:07Z,"The attached small example crashes if line 17 is commented out.[[BR]]
In other words, it seems that it is not possible to assign the transpose of a banded matrix to an empty banded matrix.",michele.de.stefano@…
9804,boost::geometry::intersection returns input polygon when the result should be empty.,geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,new,2014-03-24T08:00:03Z,2014-03-24T08:00:03Z,"The result of an intersection is sometimes equal to one of the input polygons, when the result should be empty. For example:

{{{
    typedef boost::geometry::model::d2::point_xy<double> Point;
    typedef boost::geometry::model::polygon<Point> Polygon;
    Polygon pg1;
    Polygon pg2;
    boost::geometry::model::multi_polygon<Polygon> result;
   
    boost::geometry::append(pg1, Point(-6.0, 3.2500000000000013));
    boost::geometry::append(pg1, Point(-9.0, 3.2500000000000022));
    boost::geometry::append(pg1, Point(-9.0, 6.5));
    boost::geometry::append(pg1, Point(-6.0, 6.5));
    boost::geometry::append(pg1, Point(-6.0, 3.2500000000000013));

    boost::geometry::append(pg2, Point(-3.0, 0.0));
    boost::geometry::append(pg2, Point(-6.0, 0.0));
    boost::geometry::append(pg2, Point(-6.0, 3.2500000000000013));
    boost::geometry::append(pg2, Point(-3.0, 3.2500000000000009));
    boost::geometry::append(pg2, Point(-3.0, 0.0));

    boost::geometry::intersection(pg1, pg2, result);
}}}

After the intersection, result contains a polygon equal to pg1. We're using boost 1.55 and also tried the rescale_to_integer branch, which gives the same results.

The problem seems to be with boost::geometry::within. We've previously had problems with within that we resolved by using a different strategy. Changing the strategy of the within calls in the function update_selection_map in select_rings.hpp makes intersection return the correct result for this case.",Nick <7415963@…>
9797,Scanning files without updating file counter when initializing from settings container,log,Boost 1.55.0,Boost 1.56.0,Feature Requests,Andrey Semashev,new,2014-03-20T09:42:06Z,2014-03-20T10:11:02Z,"When setting up a text file backend programmatically I can call scan_for_files() with the update_counter parameter set to false.

However when initializing logging from a settings container, default_text_file_sink_factory::create_sink() always calls scan_for_files() with the update_counter parameter set to true.

In my project I need to be able to initialize a text file backend from a settings container, and scanning files with update_counter set to false.",robert.hegner@…
9794,"Calling async_read_some before(tcp::socket, ...) before tcp::socket::async_connect handler is called causes async_connect handler to indicate successful connect",asio,Boost 1.55.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-03-20T04:56:44Z,2014-03-20T05:03:35Z,"Given the example in this ticket, and assuming that there is no service running on localhost:29873, I would expect the example to print:
{{{
Failed to read
Failed to connect
}}}
Instead I get:
{{{
Failed to read
Connected!
}}}


{{{
#!cpp
#include <iostream>
#include <istream>
#include <ostream>
#include <string>
#include <boost/asio.hpp>
#include <boost/bind.hpp>

using namespace std;
using namespace boost;
using boost::asio::ip::tcp;

int main(int argc, char* argv[])
{
    asio::io_service ios;
    tcp::socket socket{ios};
    
    tcp::endpoint endpoint(asio::ip::address::from_string(""127.0.0.1""), 29873);

    socket.async_connect(endpoint, [](const system::error_code& ec) {
        if ( !ec ) {
            cout << ""Connected!"" << endl;        
        } else {
            cout << ""Failed to connect"" << endl;
        }
    });

    asio::streambuf readBuffer;
    asio::async_read_until(socket, readBuffer, '\n', [](const system::error_code& ec, size_t size) {
        if ( !ec ) {
            cout << ""Read "" << size << "" "" << endl;
        } else {
            cout << ""Failed to read"" << endl;        
        }
    });
    
    ios.run();
}
}}}

I also have the same problem in boost 1.48.

I know it's not really logical to do what the example shows, but I would not expect the result it gives.",tim.pavlic@…
9792,named_mutex is not process Persistence by default in windows,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-03-19T09:02:27Z,2014-03-19T10:07:53Z,"when the BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION is defined, the named_mutex is ipcdetail::shm_named_mutex and is not process persistence.

BTW: when we can remove the BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION?",huyuguang@…
9791,"[libs/program_options] winmain.cpp fails to compile with -O3, ok with -O0 (gcc-5666.3)",program_options,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2014-03-18T16:07:47Z,2014-03-19T18:50:40Z,"Hello

I have identified a problem when cross-compiling libs\program_options\src\winmain.cpp with Apple's gcc-5666.3 (4.2.1) and the -O3/2/1 switches, it works fine with -O0

{{{
""X:/libs/gcc-5666.3-x86_64-apple-darwin10/bin/g++.exe""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -m32 -w -m32 -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I""."" -c -o ""bin.v2\libs\program_options\build\gcc-4.2.1\release\abi-sysv\address-model-32\binary-format-mach-o\link-static\strip-on\target-os-darwin\threadapi-pthread\threading-multi\winmain.o"" ""libs\program_options\src\winmain.cpp""
}}}

Unfortunately I don't have any more logs but I have uploaded the gcc-5666.3-x86_64-apple-darwin10.tar.xz on my googledrive if you want to give a shot by yourself https://drive.google.com/folderview?id=0B4dcRcayW88VNmRtZDEybEZoLTQ&usp=sharing

",class101 <ad@…>
9790,LINK1104 link error,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-03-18T14:59:46Z,2014-03-18T15:37:54Z,"Downloaded 'latest' (at least I thought it was the lastest - Version pull down below suggests two subsequent versions) package from sourceforge.  After installing, I started reading the ""Getting Started"" pages and came to the list of ""Need to be Compiled"" libraries.  Since I'm currently after the filesystem capabilities, I built (using the bootstrap and .\b2 commands).  I then started through the tutorial for the filesystem lib.  

I set up VS (using MSVS10), to find the boost libraries, and typed in tut1.  Upon compile, I get a link error:

LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc100-mt-gd-1_55.lib'

The reason that it cannot open it, is because there is NO ...vc100-mt...  Instead, we now have ...vc110-mt...  

For now, I believe that I'll uninstall, and go back one version.  Try to get through the tutorials.

I've used boost libraries before, but always with non-compiled headers and with projects at work.  I read about the filesystem iterators online and thought that I'd give it a whirl for a home project.  This is what I ran into, so I thought that I'd report it.",Mitch Oldroyd <Oldroyd_m@…>
9789,Consistent comment support for INI files,program_options,Boost 1.53.0,To Be Determined,Feature Requests,Vladimir Prus,new,2014-03-18T14:06:25Z,2014-03-18T14:14:08Z,"See ticket #5379 - semicolon was supported but hash was not in property tree ini parser, hash was added as a result of that ticket.

I am presently dealing with program options. In config_file.cpp, only hash is supported.

Please can semicolon be added for consistency within boost as well as other applications.

For example, PHP only supports semicolon (they have dropped support for hash which I am given to understand was always the lesser used character for commenting INI files). Many applications do not support hash.
",edward@…
9770,Finish_edge event misbehavior.,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-03-11T14:20:04Z,2014-03-11T18:07:44Z,"Consider the following diamond DAG:

{{{
  3
 / \
1   2
 \ /
  0
}}}


A depth first search on this graph with a visitor that records the on-finish-vertex and on-vinish-edge events should output something that:

{{{
Finish vertex: 3
Finish vertex: 1
Finish edge: (1,3)
Finish edge: (2,3)
Finish vertex: 2
Finish edge: (0,1)
Finish vertex: 0
Finish edge: (0,2
}}}


But it acually outputs:

{{{
Finish vertex: 3
Finish edge: (1,3)
Finish vertex: 1
Finish edge: (1,3)
Finish edge: (2,3)
Finish vertex: 2
Finish edge: (0,2)
Finish vertex: 0
Finish edge: (0,2)
}}}


The edge (0,2) is seen twice while (0,1) not at all (see the attachment).

The problem comes from ""boost/graph/depth_first_search.hpp"" in depth_first_visit_impl(). The variable ""src_e"" is overwritten during the propagation with another tree edge.

The following simple fix solves the problem:



{{{
--- /tmp/depth_first_search.hpp	2014-03-11 15:11:53.616272419 +0100
+++ boost/graph/depth_first_search.hpp	2014-03-11 15:11:14.854137441 +0100
@@ -143,8 +143,8 @@
           ColorValue v_color = get(color, v);
           if (v_color == Color::white()) {
             vis.tree_edge(*ei, g);
-            src_e = *ei;
+            Edge src_e = *ei;
	     stack.push_back(std::make_pair(u, std::make_pair(src_e, std::make_pair(++ei, ei_end))));
             u = v;
             put(color, u, Color::gray());
}}}










   
",edwin.carlinet@…
9769,Add conversion from boost::exception_ptr to std::exception_ptr when available,exception,Boost 1.55.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2014-03-11T06:48:51Z,2014-09-12T17:12:34Z,"Having the conversion from boost::exception_ptr to std::exception_ptr, when the compiler supports it std::exception_ptr, is needed to implement this ticket #9710 ""Support std::exception_ptr in boost::promise"".

Do you think that it is worth adding it to Boost.Exception?
Could this conversion be done more efficiently using the internals of the library?",viboes
9764,posix_time::time_duration::operator/(int) can trigger division by zero error,date_time,Boost Release Branch,To Be Determined,Feature Requests,az_sw_dude,new,2014-03-10T11:12:22Z,2014-03-10T11:12:22Z,"When dividing time_duration by a 64-bit integer the divisor will be implicitly cast to 'int' type (32-bits on most platforms).

This will cause 'division by zero' runtime error for any value which is a multiple of 2^32^. 
It will also cause invalid values to be calculated if the divisor is larger than 2^31^ - 1.

I don't see any reason why the time_duration interface should be limited to division by 32-bit integer values on systems where the storage type used in time_duration is at least 64-bit long.",Michał Ślizak <michal.slizak+boost@…>
9758,boost::geometry::index::rtree does not compile with CoordinateSystem geographic<,geometry,Boost 1.55.0,To Be Determined,Feature Requests,Barend Gehrels,new,2014-03-08T20:30:42Z,2018-04-07T07:12:34Z,"boost::geometry::index::rtree does not compile with CoordinateSystem geographic<

CoordinateSystem cartesian is ok

Example program:
{{{
typedef bg::model::point<double, 2, bg::cs::cartesian> geo_point_ok;
typedef bg::model::point<double, 2, bg::cs::geographic<bg::degree> > geo_point;
typedef std::pair<geo_point, unsigned int> geo_vg_value;

void test() {
      double lon=10.0, lat=60.0;
      geo_point pt(on, lat);
      rtree.insert(std::make_pair(pt, wp->id));

      std::vector<geo_vg_value> result;
      geo_point here(targetLat, targetLat);
      rtree.query(bgi::nearest(here, 20), std::back_inserter(result));
}
}}}
",ola.lykkja@…
9755,Simple way to get hash.,hash,Boost 1.55.0,To Be Determined,Feature Requests,Daniel James,new,2014-03-07T12:25:16Z,2014-03-07T12:25:16Z,"When writing custom hash_value functions, it is often useful to forward to the hash of another value.  However, there is currently no short and simple way to do this.  Consider:

template<class T> struct C {
  some_complex_mpl_expression<T>::type value;
  friend std::size_t hash_value() {
    // First attempt: requires knowledge of the type of the value to hash.
    return boost::hash<some_complex_mpl_expression<T>::type>()(this->value);

    // Second attempt: two lines, not recommended.
    using namespace boost;
    return hash_value(this->value);

    // Third attempt: works, but requires three lines of code and doesn't yield the same hash as the first two attempts.
    std::size_t seed = 0;
    boost::hash_combine(seed, this->value);
    return seed;
  }
};

I propose the addition of a simple function to calculate the hash of any arbitrary value, defined below:

template<class T> std::size_t get_hash(T const& v) {
  return hash<T>()(v);  
}

This would allow me to write the above hash_value function with a single line of
simple and correct code:

  friend std::size_t hash_value() {
     return boost::get_hash(this->value);
  }
",Rainer Deyke <rainerd@…>
9749,bzip2_decompressor input filter gives data_error_magic,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-03-06T20:11:05Z,2015-11-06T02:21:00Z,"The bzip2_decompressor input filter is not able to read some bz2 files properly. It can read only the first few lines of the file then terminates with data_error_magic (BZ_DATA_ERROR_MAGIC in bzlib.h).

After examining the problematic bz2 files I noticed that the first compressed stream is much shorter (536 bytes long) than the following streams. Debugging lead me to the conclusion that the simmetric_filter class's read method fills the buffer with new data even when the buffer hasn't been consumed completely. With the proposed solution below the files can be read to the end without further problems.

The original code segment:

{{{
if (status == f_good)
  status = fill(src);
}}}

The proposed modification:

{{{
if (status == f_good && buf.ptr() == buf.eptr())
  status = fill(src);
}}}

Could someone please make this modification?
Regards,
  Balazs",Balazs Andor Zalanyi <zalanyi.balazs@…>
9747,"Warning from template_arity_impl<F,N> using GCC 4.8.2",mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2014-03-06T08:40:52Z,2014-03-06T08:40:52Z,"This code
{{{
template< typename F, int N >
struct template_arity_impl
{
    BOOST_STATIC_CONSTANT(int, value =
          sizeof(::boost::mpl::aux::arity_helper(type_wrapper<F>(), arity_tag<N>())) - 1
        );
};
}}}

from boost/mpl/aux_/preprocessed/gcc/template_arity.hpp 
assigns int value = sizeof(...) causing a sign-conversion warning.
",Hartmut Schirmer <h.schirmer@…>
9742,for_each causes funny behavior in phoenix V3 expressions,phoenix,Boost 1.54.0,To Be Determined,Bugs,Thomas Heller,new,2014-03-05T08:06:53Z,2014-04-07T16:43:57Z,"Using phoenix::for_each in a Phoenix expression produces a strange behavior, which seems to be reverse execution of the comma-separated expressions.
This does NOT happen when you include Phoenix V2 from the spirit directory.

Sample Code: (Full code attached)


{{{
std::vector<int> v{1,2};
(std::cout << phx::val(""(""),  phx::for_each(arg1, phx::lambda[std::cout << arg1]), std::cout << phx::val("")""))(v);
}}}


This originally showed up for me when using phoenix expressions in spirit semantic actions, discussed here: 
http://boost.2283326.n4.nabble.com/Phoenix-V3-for-each-or-lambda-seem-to-be-ruining-qi-semantic-actions-tp4659691.html",Chromatix
9736,[documentation] document the size() extension points,range,Boost 1.54.0,To Be Determined,Tasks,Neil Groves,new,2014-03-04T12:59:20Z,2014-03-04T12:59:20Z,I added optimisations and extension-points to efficiently get the size() of a range. This means that when passing a type such as std::list that an optimal size() function is chosen in preference to performing std::distance on bidirectional iterators.,Neil Groves
9730,copy_graph doesn't use graph_traits,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-03-02T13:44:49Z,2014-03-02T13:44:49Z,"copy_graph doesn't use graph_traits internally. Therefore, classes which don't have traversal_category and directed_category, such as std::vector or SGB, are not used as the source graph.

follow code is compile error: 
{{{
#include <vector>
#include <list>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/vector_as_graph.hpp>
#include <boost/graph/copy.hpp>

int main()
{
	using VectorGraph = std::vector<std::list<int>>;
	auto vgraph = VectorGraph{{1, 2, 3}, {3, 5}, {5}, {4}, {0, 2}, {0}};
	using Graph = boost::adjacency_list<>;
	auto graph = Graph{};
	boost::copy_graph(vgraph, graph
			, boost::vertex_copy([](
					  boost::graph_traits<VectorGraph>::vertex_descriptor
					, boost::graph_traits<Graph>::vertex_descriptor) {})
			. edge_copy([](
					  boost::graph_traits<VectorGraph>::edge_descriptor
					, boost::graph_traits<Graph>::edge_descriptor) {})
	);
}
}}}

patch is here
{{{
--- /usr/local/include/boost/graph/copy.hpp	2014-03-02 21:44:55.000000000 +0900
+++ copy.hpp	2014-03-02 21:45:05.000000000 +0900
@@ -248,8 +248,8 @@
 
     template <class Graph>
     struct choose_graph_copy {
-      typedef typename Graph::traversal_category Trv;
-      typedef typename Graph::directed_category Dr;
+      typedef typename graph_traits<Graph>::traversal_category Trv;
+      typedef typename graph_traits<Graph>::directed_category Dr;
       enum { algo = 
              (is_convertible<Trv, vertex_list_graph_tag>::value
               && is_convertible<Trv, edge_list_graph_tag>::value)
}}}",Masahiro Nawata <kamo.tanabota@…>
9728,Bootstrap currently fails,Building Boost,Boost Development Trunk,To Be Determined,Bugs,,new,2014-03-01T18:39:41Z,2014-03-01T19:57:44Z,"I just just did a clone from Github.

The instructions that I'm following are at ''more/getting_started/unix-variants.html''.

The first step fails on a missing directory:


{{{
boost$ ./bootstrap.sh 
./bootstrap.sh: 1: ./bootstrap.sh: ./tools/build/v2/engine/build.sh: not found
Building Boost.Build engine with toolset ... 
Failed to build Boost.Build build engine
Consult 'bootstrap.log' for more details
}}}


",myselfasunder@…
9726,transform_iterator does not compile on SUN with Cstd STL,iterator,Boost 1.54.0,To Be Determined,Bugs,jeffrey.hellrung,reopened,2014-03-01T11:11:57Z,2014-04-08T04:44:36Z,"boost/iterator/transform_iterator.hpp:49

{{{
... typename std::iterator_traits<Iterator>::reference ...
}}}

should read:
{{{
... typename boost::detail::iterator_traits<Iterator>::reference ...
}}}

otherwise it fails to compile on SUN with old Cstd STL that does not have proper iterator_traits<>.
All other classes already use boost::detail::iterator_traits<>",Yevgeniy Shaporynskyy <shaporynskyy@…>
9724,Add move semantics for ssl::stream<>,asio,Boost 1.55.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2014-02-28T10:08:32Z,2018-03-01T10:13:17Z,"Hi,

''boost::asio::basic_stream_socket<>'' implements move semantics.
However, ''boost::asio::ssl::stream<>'' does not.

I don't know if this feature is in the roadmap yet, but for c++11 and later users, this could be very handy.
",anonymous
9722,"Changeset 55698 Problem with ""base_unit_info<S>::name());""",units,Boost 1.55.0,To Be Determined,Bugs,Matthias Schabel,new,2014-02-28T09:42:11Z,2014-03-11T00:38:56Z,"In the Changeset 55698 in Line 85 the
return(Scale::name() + S::name()); 
was changed to
return(Scale::name() + base_unit_info<S>::name());

Now I get the compiler-error
/opt/local/include/boost/units/scaled_base_unit.hpp:85:32: Implicit instantiation of undefined template 'boost::units::base_unit_info<boost::units::cgs::gram_base_unit>'

when I try to get the name of a scaled unit:
    boost::units::si::kilogram_base_unit kg;
    std::string strKg{kg.name()};

When I change line 85 back to the original version, the binding results and the output is correct.

The same is valid for line 81 ""symbol"".

Possible solution:
go back to the former version. Side effects?

or add in gram.hpp in line 36
    template<>
    struct base_unit_info<cgs::gram_base_unit> {
        static const char* name()   { return(""gram""); }
        static const char* symbol() { return(""g""); }
    };

but results in double definitions of name and symbol.
The same has to be repeated for the other base_units, e.g. centimeter_base_unit

",Eckhard Nees <eckhard.nees@…>
9721,ptree write_json does not conform to JSON standard,property_tree,Boost 1.67.0,To Be Determined,Bugs,Sebastian Redl,reopened,2014-02-27T14:52:01Z,2018-06-19T15:34:54Z,"According to the JSON standard documented at http://www.json.org, only string values should have quotes around them.  The Boost write_json method puts quotes around all values, not just strings.

For example, the following program:

#include <cstdlib>
#include <string>
#include <iostream>
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/json_parser.hpp>

using boost::property_tree::ptree;
using boost::property_tree::read_json;
using boost::property_tree::write_json;

int main()
{
    ptree pt;
    
    pt.put (""string"", ""string value"");
    pt.put (""integer"", 1);
    pt.put (""float"", 3.14159);

    std::ostringstream buf; 
    write_json (buf, pt);

    std::cout << buf.str();
    return 0;
}

produces this output:

{
    ""string"": ""string value"",
    ""integer"": ""1"",
    ""float"": ""3.14159""
}

According to the JSON standard, the output should be:

{
    ""string"": ""string value"",
    ""integer"": 1,
    ""float"": 3.14159
}

(no quotes around the numeric values)",Mark Pfeifer <Mark_Pfeifer@…>
9717,Boost math library on PPC64 has thousands of errors,math,Boost 1.55.0,To Be Determined,Bugs,John Maddock,new,2014-02-26T14:36:01Z,2014-03-12T16:35:26Z,"Hi,

I'm trying to port Boost 1.55 on PowerPC64 BE and LE.
Thousands of errors appear with math library.

Investigation one test (bessel_zeros_example_1) which loops, I see by means of gdb the following:
  boost::math::cyl_bessel_j_zero< double, .....
  boost::math::detail::cyl_bessel_j_zero_imp<__float128, .....

This  ""__float128"" seems erroneous.
However, looking at boost/math/special_functions/bessel.hpp code, I see that this type is chosen at compilation time, by means of:
 typedef typename policies::evaluation<result_type, Policy>::type value_type;
and it is a nightmare to understand why the compiler did choose __float128. Unless gdb is showing nuts ?

Exact test is:
bin.v2/libs/math/example/bessel_zeros_example_1.test/gcc-4.8.2/debug/bessel_zeros_example_1

Comparing execution path of this test code in PPC64/BE to Intel64, I see some floor() value computed differently on the 2 systems, and leading the test program to enter a wrong path and stay stucked in an infinite loop.

There is some fundamental error, hidden by compiler which compiles templates and gives me no hint.

I need help to determine what is wrong with Boost math on PPC64.

Tony",Tony Reix <tony.reix@…>
9715,Converting std:exception_ptr to boost:exception_ptr,exception,Boost 1.55.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2014-02-26T09:47:25Z,2014-02-26T09:47:47Z,"Please provide a way to convert std::exception_ptr to boost::exception_ptr (if std::exception_ptr is available of course). 

This would important for users who do not want to wrap all of their throws in enable_current_exception() and/or use std::exception_ptr in other parts of their code, but forced to use boost::exception_ptr in their public interface of other boost libraries.

See also:
http://stackoverflow.com/questions/22010388/converting-stdexception-ptr-to-boostexception-ptr

Would it be possible to typedef std::exception_ptr as boost::exception_ptr if boost is compiled with C++11? ",anonymous
9713,Boost.MPI - error in documentation,mpi,Boost 1.55.0,To Be Determined,Bugs,Matthias Troyer,new,2014-02-25T22:26:39Z,2014-02-25T22:26:39Z,"In the section MPI Implementation, page http://www.boost.org/doc/libs/1_55_0/doc/html/mpi/getting_started.html, there is an error in the documentation.

In particular:

  int main()

Should be:

  int main (int argc, char** argv)

Otherwise the example code doesn't compile.",anonymous
9704,b2: Compiler flavour has no flexibility for cross-compiling projects.,build,Boost 1.54.0,To Be Determined,Bugs,Steven Watanabe,assigned,2014-02-24T20:39:19Z,2014-04-04T22:13:25Z,"Hi,

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

I am building my project (i.e. all of my project tree) 
 on 2 platforms:
 * Windows, 
 * Linux,

for 3 different platforms:
 * Windows
 * Linux IA32
 * Linux ARM HF

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

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

{{{
if [ os.name ] = NT
{
using gcc : : :
     <cxxflags>-std=c++11 
     <cxxflags>""-include cmath""
     <cxxflags>-Wdeprecated-declarations
    ;

using gcc : armhf : arm-linux-gnueabihf-g++.exe :
     <cxxflags>-std=c++11
     <cxxflags>""-include cmath""
     <cxxflags>-Wdeprecated-declarations
    ;
}

if [ os.name ] = LINUX
{
using gcc : : :
     <cxxflags>-std=c++11 
     <cxxflags>""-include cmath""
    ;

using gcc : armhf : /usr/bin/arm-linux-gnueabihf-g++ :
     <cxxflags>-std=c++11 
     <cxxflags>""-include cmath""
     <cxxflags>-Wdeprecated-declarations
    ;
}
}}}

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

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

Is there a better way of doing it? 

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

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


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

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

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

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

I really wish that I could specify above:
{{{ 
using gcc : 4.7 : <my-path-to-gcc47> ... ;
using gcc : armhf : <my-path-to-gcc47 arm hf>  ... ;
}}}

and wouldn't have to create links or worry about the build system changing/ coming up with a flavor by concatenating target name (e.g.  on 
{{{
b2 --toolset=gcc-armhf
}}}
with g++ (and having to hack/create symlinks to match this etc.) - 

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


There could also be a support for something like:

{{{
import toolset ;

if [ toolset.name ] == gcc
{
  if [ toolset.flavor ] == flav_1
  {
  }
}

# and my verbosive Jamfiles could be re-written to something like:

local gcc_flavor = [ toolset.flavor ] ;
install copy_binaries_to_release
  : 
    target_names..
  :
    <toolset>gcc,<flavor>4.7:<location>../../release
    <toolset>gcc,<flavor>armhf:<location>../../release_$(gcc_flavor)
    
    # or even to:
    <toolset>gcc:<location>../../release_$(gcc_flavor)
  ;
}}}

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

Thanks,
LUkasz.

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



",lukasz.forynski@…
9703,build system ignores --with-icu= option,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-02-24T19:09:28Z,2014-03-10T22:37:10Z,"Configured as:

./bootstrap.sh --with-icu --with-icu=/opt/icu4c-52.1

I can see that line in project-config.jam exists:

path-constant ICU_PATH : /opt/icu4c-52.1 ;

But when I run ./b2 -a it reports:

    - has_icu builds           : yes (cached)
...
- Boost.Locale needs either iconv or ICU library to be built.
(repeated many times)
",sergey@…
9699,Ticket submission capcha inappropriately mixes non-HTTPS content,trac / subversion,,To Be Determined,Bugs,Douglas Gregor,new,2014-02-23T18:45:11Z,2014-09-16T05:54:57Z,"When an update is flagged as potential spam, the Google capcha request uses http, not https. This prevents more secure browsers from loading the script. I had to switch to Safari to make updates, which you can imagine makes me super uncomfortable this weekend in particular.",Nate Rosenblum <flander@…>
9697,clang fails on 32bit MacOS X (unknown target CPU i686),build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2014-02-22T09:14:46Z,2014-02-22T09:17:12Z,"compiling boost.context with 'b2 toolset=clang' on 32bit MacOS X fails:

    ""clang++"" -x c++ -O0 -g -O0 -fno-inline -Wall -g -march=i686 -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -I""/Users/nat/boost-git"" -c -o ""/Users/nat/boost-git/bin.v2/libs/context/test/test_context.test/clang-darwin-4.2.1/debug/address-model-32/architecture-x86/link-static/threading-multi/test_context.o"" ""/Users/nat/boost-git/libs/context/test/test_context.cpp""

error: unknown target CPU 'i686'
...failed clang-darwin.compile.c++ /Users/nat/boost-git/bin.v2/libs/context/test/test_context.test/clang-darwin-4.2.1/debug/address-model-32/architecture-x86/link-static/threading-multi/test_context.o...
",olli
9692,Add operator[](graph_bundle_t) to compressed_sparse_row_graph<bidirectionalS>,graph,Boost 1.54.0,To Be Determined,Feature Requests,Jeremiah Willcock,new,2014-02-20T19:11:57Z,2014-02-20T19:11:57Z,"Hello,

it would be really fine, if in a bidirectional csr graph the graph's properties were accessible in the same way as in a directed csr graph.",Philipp Büttgenbach <Philipp.Buettgenbach@…>
9691,Unused parameter 'args' in the definition of the macro BOOST_PARAMETER_FUNCTION,parameter,Boost 1.54.0,To Be Determined,Bugs,Daniel Wallin,new,2014-02-20T18:53:54Z,2014-02-20T18:53:54Z,"In CGAL (www.cgal.org), usage of BOOST_PARAMETER_FUNCTION triggers several of such following warnings with recent g++ (4.8) and LLVM/clang:
{{{
CGAL-4.4-Ic-126/include/CGAL/perturb_mesh_3.h:39:1: warning: unused parameter 'args' [-Wunused-parameter]
BOOST_PARAMETER_FUNCTION(
^
/usr/local/include/boost/parameter/preprocessor.hpp:937:5: note: expanded from macro 'BOOST_PARAMETER_FUNCTION'
    BOOST_PARAMETER_FUNCTION_AUX(                                       \
    ^
/usr/local/include/boost/parameter/preprocessor.hpp:933:5: note: expanded from macro 'BOOST_PARAMETER_FUNCTION_AUX'
    BOOST_PARAMETER_FUNCTION_DEFAULT_LAYER(name, args, 0, 0, tag_namespace)
    ^
/usr/local/include/boost/parameter/preprocessor.hpp:911:5: note: expanded from macro 'BOOST_PARAMETER_FUNCTION_DEFAULT_LAYER'
    BOOST_PARAMETER_FUNCTION_DEFAULT_LAYER_AUX( \
    ^
/usr/local/include/boost/parameter/preprocessor.hpp:899:21: note: expanded from macro 'BOOST_PARAMETER_FUNCTION_DEFAULT_LAYER_AUX'
      , Args const& args \
                    ^
}}}

I have verified that indeed the parameter is not used, and I propose that '''patch''':
{{{
diff --git a/include/boost/parameter/preprocessor.hpp b/include/boost/parameter/preprocessor.hpp
index f1bda87..23ddbc4 100644
--- a/include/boost/parameter/preprocessor.hpp
+++ b/include/boost/parameter/preprocessor.hpp
@@ -896,7 +896,7 @@ struct funptr_predicate<void**>
     BOOST_PARAMETER_MEMBER_FUNCTION_STATIC(name) \
     ResultType BOOST_PARAMETER_FUNCTION_DEFAULT_NAME(name)( \
         ResultType(*)() \
-      , Args const& args \
+      , Args const& \
       , int \
         BOOST_PARAMETER_FUNCTION_DEFAULT_ARGUMENTS( \
             BOOST_PARAMETER_FUNCTION_DEFAULT_FUNCTION_ARG \
}}}",Laurent Rineau <Laurent.Rineau__boost@…>
9687,introduce boost::python::raw_method,python USE GITHUB,Boost 1.54.0,To Be Determined,Patches,Ralf W. Grosse-Kunstleve,new,2014-02-20T10:00:39Z,2014-02-20T10:00:39Z,"Hi,

I am developing a Python's module using boost::python. I need to create a method for certain class, which takes {{{*args}}} and {{{**kwargs}}}.

Boost::python is capable of creating a raw function/constructor, but lacks an API for creating a **raw method**. I attach a header, which introduces this option.

Thank you for a feedback.

Regards

----

Example:
{{{
#!cpp

namespace bp = boost::python;

class ClassName
{
public:
    // ...

    static void init()
    {
        s_class = bp::class_<ClassName>(""ClassName"", /* ... */)
            .def(""RawMethodName"",
                 bp::raw_method<ClassName>(
                     &ClassName::MethodName, 2));
    }

    bp::object RawMethodName(
        const bp::tuple &args,
        const bp::dict  &kwargs)
    {
        // Do something with args, kwargs
        return bp::object();
    }

    // ...

private:
    static bp::object s_class;
};

bp::object ClassName::s_class;

}}}",phatina@…
9686,Provide cmd file for building both 32-bit and 64-bit libraries on Windows with Microsoft Visual C++,Building Boost,Boost 1.54.0,To Be Determined,Feature Requests,,new,2014-02-20T00:57:25Z,2014-02-20T23:27:29Z,"It would make sense to provide a cmd file to automate bootstrapping and building both 32-bit and 64-bit libraries (in the Debug and Release configurations) on Windows (placing them under stage32 and stage64, respectively). Running bootstrap and b2 with no command-line arguments as recommended in the Getting Started guide will build only 32-bit libraries. In order to build 64-bit libraries, one has to consult bjam docs to figure out which parameters/options to use. Since targeting both 32-bit, and 64-bit architectures is quite common for developers working under Windows, having a batch file to automate Boost library builds for both architectures in one go will save them some time and effort.",rassokhin@…
9685,Boost.Locale does not link against static ICU on Windows,locale,Boost 1.55.0,To Be Determined,Feature Requests,Artyom Beilis,assigned,2014-02-19T23:06:28Z,2016-12-08T14:40:25Z,"There seems to be no support for linking against the static ICU libraries (sicuXX.lib) on Windows. Is there any plans to add it (?), or is there an inherent problem?

I would be willing to write that support if there is a bit of guidance on how to go about it in the Jamfile.",stathis@…
9682,"first slash in path ""a:/b/c"" is interpreted as second node in [path.begin() parh.end()] sequence (windows)",filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-02-19T11:57:59Z,2014-02-19T11:57:59Z,"//windows
boost::filesystem::path p(""a:/b/c"");
boost::filesystem::path result;
for(boost::filesystem::path::iterator it = p.begin(); it != p.end(); ++it)
{
  result/=*it;  //value of it on second iteration is '/'
}
assert(result.string() == ""a:/b\c"");",anonymous
9681,How Do I Remove C:\ProgramData\boost_Interprocess From My Computer,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-19T04:17:34Z,2014-03-10T22:56:17Z,"Hello, 

I've recently run malware scan and C:\ProgramData\boost_Interprocess keeps popping us as an issue, no matter how many times I try to clean and remove it. When I try to delete it from accessing the C: Drive, it says I do not have permission. It didn't use to be there before and I don't want it there now. 

Can someone please show me how to delete this from my computer? 

Thanks",anonymous
9680,Exceptions disabling in some files,date_time,Boost 1.54.0,To Be Determined,Patches,az_sw_dude,new,2014-02-18T20:00:27Z,2014-02-18T20:00:27Z,"Used the macro BOOST_TRY,BOOST_CATCH,BOOST_CATCH_END and BOOST_RETHROW do be able to use some method/classes when exceptions are disabled",anonymous
9679,documentation about bidirectional iterator,concept_check,Boost 1.54.0,To Be Determined,Bugs,jsiek,new,2014-02-18T13:34:57Z,2014-03-11T03:56:13Z,"http://www.boost.org/doc/libs/1_55_0/doc/html/BidirectionalIterator.html states:

Precondition of predecrement: ""i is incrementable (not off-the-end) and some dereferenceable iterator j exists such that i == ++j""

This can be interpreted that end() iterator can not be decremented, which according to other sources you can do.

http://stackoverflow.com/a/5322234/104774 references ""ISO/IEC 14882:2003 C++ Standard 23.1.1/12 – Sequences""

",Stefaan Verstraeten <stefaan.verstraeten@…>
9677,make_biconnected_planar failure when working with custom planar embedding,graph,Boost 1.53.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-02-17T19:46:00Z,2014-02-17T19:46:00Z,"Using make_biconnected_planar function with a planar graph G and its custom embedding results in a graph, which is no longer planar.

The problem doesn't occur when embedding G with boyer_myrvold_planarty_test.

The custom planar embedding of a graph G with 11 vertices and 18 edges is (each group is a counter clock-wise list of edges adjacent to a vertex):

0 - 1 : 0
0 - 8 : 15

0 - 1 : 0
1 - 2 : 2
4 - 1 : 3
1 - 3 : 1

1 - 2 : 2
2 - 3 : 5
2 - 4 : 4

1 - 3 : 1
3 - 4 : 6
2 - 3 : 5

4 - 1 : 3
2 - 4 : 4
3 - 4 : 6

5 - 6 : 7
5 - 8 : 9
7 - 5 : 8

5 - 6 : 7
6 - 7 : 10
6 - 9 : 12
8 - 6 : 11

7 - 5 : 8
7 - 8 : 13
9 - 7 : 14
6 - 7 : 10

5 - 8 : 9
8 - 6 : 11
8 - 9 : 16
0 - 8 : 15
7 - 8 : 13

6 - 9 : 12
9 - 7 : 14
9 - 10 : 17
8 - 9 : 16

9 - 10 : 17

An example program is attached.",Jakub Oćwieja <netkuba@…>
9676,ptr_container without RTTI,ptr_container,Boost 1.55.0,To Be Determined,Bugs,Thorsten Ottosen,new,2014-02-17T12:03:39Z,2014-02-17T12:03:39Z,"ptr_container requires RTTI support only when compiled in debug mode.
The reason for this seem to be a few assertions in `clone_allocator.hpp` and `detail/reversible_ptr_container.hpp`, which make use of `typeid`.

It seems to me like these assertions should be surrounded by checks for `BOOST_NO_TYPEID` or something to that effect, so as to enable compilation in debug mode without RTTI.

Steps to reproduce:
Attempt to compile ptr_container in debug mode with RTTI support disabled.

Expected result:
Compilation finishes without error.

Actual result:
Compilation fails with errors in `clone_allocator.hpp` and `detail/reversible_ptr_container.hpp` regarding use of typeid when RTTI is disabled.
",d.leinhaeuser@…
9675,qt5: moc invocation broken for Qt 5.2,build,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2014-02-17T08:38:37Z,2014-02-17T08:38:37Z,"Between Qt 5.1 and 5.2, the command line syntax for `moc` changed, breaking builds.
Specifically, the `-f` command line argument works differently: 
previously, it was `-f<file>` where `<file>` could be omitted; in Qt 5.2, it's `-f <file>` – notice the additional space, and `<file>` is not optional any more.
The moc invocation by the Qt5 module relied on the old behaviour as it passed `-f` without a filename. Furthermore, the moc input file was passed right after the `-f` argument. The same usage is now interpreted as the input file being the parameter to `-f`, and the input it expected on `stdin`. Since nothing is ever written into it, moc never finishes.
",frank.richter@…
9674,qt5: <rccflags> support,build,Boost 1.55.0,To Be Determined,Patches,Vladimir Prus,new,2014-02-17T08:27:47Z,2014-02-17T08:27:47Z,Support `<rccflags>` for both qt4 and qt5 by moving the feature declaration to a separate module.,frank.richter@…
9669,Invalid links in Boost python,python USE GITHUB,Boost 1.55.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2014-02-15T00:13:46Z,2014-03-10T22:46:45Z,"The page http://www.boost.org/doc/libs/1_55_0/libs/python/doc/ contains links to web pages that are not valid Eg.
""Building Hybrid Systems With Boost Python""",parama_chakra@…
9667,Testing v 1.55 : bad characters in some .output files,range,Boost 1.55.0,To Be Determined,Bugs,Neil Groves,new,2014-02-14T10:10:50Z,2014-06-26T22:19:04Z,"There are bad characters at end of string of this line of a .output file (generated by ../b2 in status sub-dir):

hello worldhello worlda wide stringanother wide string^@

That prevents some tools to read till end of file.


$ cat boost1.55-1.55.0/bin.v2/libs/range/test/iterator_range.test/gcc-4.8/debug/link-static/threading-multi/iterator_range.output
Running 7 test cases...
hello worldhello worlda wide stringanother wide string
*** No errors detected

EXIT STATUS: 0



$ grep EXIT boost1.55-1.55.0/bin.v2/libs/range/test/iterator_range.test/gcc-4.8/debug/link-static/threading-multi/iterator_range.output 
Binary file boost1.55-1.55.0/bin.v2/libs/range/test/iterator_range.test/gcc-4.8/debug/link-static/threading-multi/iterator_range.output matches

hexdump -C ......./iterator_range.output
........ 00 0a 45 58 49 54 ........
         ^^^^^
         These characters are unexpected in the middle of the file.



There are some more errors in other .output files I'm now analyzing.",Tony Reix <tony.reix@…>
9666,managed_shared_memory constructor crash,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-13T18:30:35Z,2014-07-03T16:33:15Z,"The following code causes a crash on Visual Studio 2013 when compiling for 64-bit and with optimization.

{{{
#include <boost/interprocess/managed_shared_memory.hpp>

using namespace boost::interprocess;
int main()
{
  static const char name[] = ""test_shm"";
  shared_memory_object::remove(name);
  managed_shared_memory segment(create_only, name, 65536);
  return 0;
}
}}}

The reported error is a buffer overrun
The crash doesn't happen on 32-bit builds. It also doesn't happen when building without optimization.
Finally, it doesn't happen when compiling with /GS- (disable security checks).

This is the stack trace:
{{{
msvcr120.dll!__crt_debugger_hook(int _Reserved=1) Line 60	C
testshm.exe!__raise_securityfailure(_EXCEPTION_POINTERS * ExceptionPointers=0x000000013fa8c170) Line 70	C
testshm.exe!__report_gsfailure(unsigned __int64 StackCookie=63963535653567328) Line 241	C
testshm.exe!boost::intrusive::rbtree_algorithms<boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,1> >::rebalance_after_insertion(const boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0> >,__int64,unsigned __int64,0> & header=<struct at NULL>, boost::interprocess::offset_ptr<boost::intrusive::compact_rbtree_node<boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0> >,__int64,unsigned __int64,0> p={...}) Line 528	C++
testshm.exe!boost::intrusive::bstree_impl<boost::intrusive::bhtraits<boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>::block_ctrl,boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,1>,0,boost::intrusive::default_tag,3>,void,unsigned __int64,1,4>::insert_equal(boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>::block_ctrl & value={...}) Line 861	C++
testshm.exe!boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>::priv_add_segment(void * addr=0x0000000050000063, unsigned __int64 segment_size=1374736) Line 426	C++
testshm.exe!boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index>::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index>(unsigned __int64 segment_size=65536) Line 414	C++
testshm.exe!boost::interprocess::ipcdetail::basic_managed_memory_impl<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index,8>::create_impl(void * addr=0x0000000000000000, unsigned __int64 size=1) Line 176	C++
testshm.exe!boost::interprocess::ipcdetail::managed_open_or_create_impl<boost::interprocess::shared_memory_object,8,1,0>::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,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index,8> > >(boost::interprocess::ipcdetail::create_enum_t type=1068023640, const char * const & id=0x00000000000000c2, unsigned __int64 size=8, boost::interprocess::mode_t mode=read_write, const void * addr=0x0000000000000000, const boost::interprocess::permissions & perm={...}, 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,__int64,unsigned __int64,0>,0>,boost::interprocess::iset_index,8> > construct_func) Line 407	C++
testshm.exe!main() Line 9	C++
testshm.exe!__tmainCRTStartup() Line 626	C
kernel32.dll!BaseThreadInitThunk()	Unknown
ntdll.dll!RtlUserThreadStart()	Unknown
}}}",seppleviathan@…
9661,bind: Convert lost qualifier,bind,Boost 1.55.0,To Be Determined,Bugs,Peter Dimov,new,2014-02-12T02:50:13Z,2014-02-12T02:50:13Z,"The following code doesn't compile with vs2013. It will be OK if boost::bind is replaced with std::bind or using less placeholders.

{{{
#include <boost/bind.hpp>
void foo(int&, int, int){}

int main(){
	using boost::bind;	

	int a;
	auto&& f = bind(&foo, _1, _2, _3);
	f(a, 0, 0);
	
	return 0;
}
}}}
",Yuan Yao <yaoyuan1216@…>
9660,"boost_1_55_0.zip will not unzip, path names too long",Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-02-11T21:32:42Z,2016-07-25T21:33:21Z,"boost_1_55_0.zip: Can not unzip long path name files
with WinZip or the windows 7 unzip.",anonymous
9657,Boost Log V2 Library Android Linking,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2014-02-11T12:14:29Z,2014-02-13T09:24:22Z,"I am trying to build Boost 1.55 Log v2 library on Android using NDK 9C. I have used the patches and build the boost using build-android.sh including thread,iostreams,random and log options. I have used the other features of Boost and they have worked. But there seems to be linking problem with the Log V2 on NDK 9c 64 bit which I could not solve with the existing solutions. I keep getting the same ""undefined reference"" error. On the web people solved this problem including ""#define BOOST_ALL_DYN_LINK"" but it did not work for me. 
The build-android.sh file option
LIBRARIES=--with-libraries=date_time,filesystem,program_options,regex,signals,system,thread,iostreams,random,log


Console Output:

{{{
10:35:45 **** Build of configuration Default for project BoostLogLib ****
/home/guven/Desktop/IDP/adt/android-ndk-r9c/ndk-build all 
Android NDK: WARNING: APP_PLATFORM android-9 is larger than android:minSdkVersion 8 in ./AndroidManifest.xml    
Android NDK: WARNING:jni/Android.mk:BoostLogLib: non-system libraries in linker flags: /home/guven/Desktop/IDP/adt/android-ndk-r9c/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi-v7a/libgnustl_static.a -lboost_system-gcc-mt-1_55 -lboost_filesystem-gcc-mt-1_55 -lboost_thread-gcc-mt-1_55 -lboost_iostreams-gcc-mt-1_55 -lboost_date_time-gcc-mt-1_55 -lboost_random-gcc-mt-1_55 -lboost_log-gcc-mt-1_55 -lboost_log_setup-gcc-mt-1_55 -lboost_program_options-gcc-mt-1_55 -lboost_regex-gcc-mt-1_55 -lboost_chrono-gcc-mt-1_55    
Android NDK:     This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES    
Android NDK:     or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the    
Android NDK:     current module    
[armeabi-v7a] Compile++ thumb: BoostLogLib <= BoostLogLib.cpp
[armeabi-v7a] SharedLibrary  : libBoostLogLib.so
jni/BoostLogLib.cpp:20: error: undefined reference to 'boost::log::v2_mt_posix::core::get()'
/home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0/boost/log/attributes/attribute_name.hpp:80: error: undefined reference to 'boost::log::v2_mt_posix::attribute_name::get_id_from_string(char const*)'
jni/BoostLogLib.cpp:20: error: undefined reference to 'boost::log::v2_mt_posix::core::set_filter(boost::log::v2_mt_posix::filter const&)'
/home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0/boost/log/attributes/value_extraction.hpp:232: error: undefined reference to 'boost::log::v2_mt_posix::attribute_value_set::find(boost::log::v2_mt_posix::attribute_name) const'
/home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0/boost/log/attributes/value_extraction.hpp:233: error: undefined reference to 'boost::log::v2_mt_posix::attribute_value_set::end() const'
/home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0/boost/log/attributes/value_extraction.hpp:241: error: undefined reference to 'boost::log::v2_mt_posix::aux::attach_attribute_name_info(boost::exception&, boost::log::v2_mt_posix::attribute_name const&)'
collect2: error: ld returned 1 exit status
make: *** [obj/local/armeabi-v7a/libBoostLogLib.so] Error 1

10:35:50 Build Finished (took 4s.138ms)
}}}

 BoostLogLib.h


{{{
#ifndef BOOSTLOGLIB_H_
#define BOOSTLOGLIB_H_

#include <jni.h>

#include <iostream>

#ifdef __cplusplus
extern ""C"" {
#endif
/*
 * Class:     HelloWorld
 * Method:    print
 * Signature: ()V
 */
JNIEXPORT jstring JNICALL Java_com_example_boostloglib_BoostLogLib_print
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif

#endif /* BOOSTLOGLIB_H_ */
}}}

BoostLogLib.cpp


{{{
#define BOOST_LOG_USE_CHAR
#define BOOST_ALL_DYN_LINK

#include ""BoostLogLib.h""


#include <boost/log/core.hpp>
#include <boost/log/trivial.hpp>
#include <boost/log/expressions.hpp>

namespace logging = boost::log;

//[ example_tutorial_trivial_with_filtering
void init()
{
    logging::core::get()->set_filter
    (
        logging::trivial::severity >= logging::trivial::info
    );
}

int start_logging()
{
    init();

    return 0;
}

JNIEXPORT jstring JNICALL Java_com_example_boostloglib_BoostLogLib_print(JNIEnv * env, jobject obj){

    start_logging();
    jstring result = env->NewStringUTF(""Hello world!!!""); // C style string to Java String
    return result;
}
}}}

Android.mk

{{{
LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := BoostLogLib
LOCAL_SRC_FILES := BoostLogLib.cpp
LOCAL_CPP_EXTENSION := .cpp

LOCAL_CPPFLAGS += -std=c++0x

LOCAL_LDLIBS += $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi-v7a/libgnustl_static.a

LOCAL_CFLAGS += -lpthread
LOCAL_CFLAGS += -I$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.8/include
LOCAL_CFLAGS += -I$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.8/libs/armeabi-v7a/include

LOCAL_CFLAGS += -I/home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/boost_1_55_0
LOCAL_LDLIBS += -L/home/guven/Desktop/IDP/workspace/3rdparty/Boost-for-Android/build/lib -lboost_system-gcc-mt-1_55 -lboost_filesystem-gcc-mt-1_55 -lboost_thread-gcc-mt-1_55 -lboost_iostreams-gcc-mt-1_55 -lboost_date_time-gcc-mt-1_55 -lboost_random-gcc-mt-1_55 -lboost_log-gcc-mt-1_55 -lboost_log_setup-gcc-mt-1_55 -lboost_program_options-gcc-mt-1_55 -lboost_regex-gcc-mt-1_55 -lboost_chrono-gcc-mt-1_55

LOCAL_CPPFLAGS += -fexceptions
LOCAL_CPPFLAGS += -frtti

include $(BUILD_SHARED_LIBRARY)
}}}
Application.mk

{{{
APP_MODULES := BoostLogLib
APP_ABI := armeabi-v7a
APP_STL := gnustl_static
APP_PLATFORM := android-9
NDK_TOOLCHAIN_VERSION := 4.8
APP_CPPFLAGS += -std=c++0x
}}}

",Guven <guveni@…>
9649,"boost_interprocess, Win32: apps built with boost <1.54 remove temp files from apps >=1.54 (and vice versa)",interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-10T17:47:06Z,2014-02-10T21:34:48Z,"In boost 1.54, the format of the interprocess temporary file name changed (previously something like `20140205173952.047159`, now like `1391618455`).
Unfortunately, this means that the ""clean out previous boot session directories"" recognizes the respective other filename as an ""old"" filename, even though it really isn't.
Suppose you create an interprocess object with ""Kernel or Filesystem"" or persistence in an app A build against boost 1.54. You store something in it, but close it with the intention of re-opening it later (the desired persistence allows for that). But you happen to start an app B build against pre-1.54 in the meantime ... this cleans out the temp dir, incorrectly discarding the interprocess objects A created earlier.
The attached patch changes the temp dir name if the ""new"" format is used.",frank.richter@…
9647,BOOST_MPL_ASSERT_RELATION fails to properly handle unsigned types,mpl,Boost 1.54.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2014-02-09T21:00:37Z,2015-04-04T21:29:55Z,"boost/integer_traits.hpp contains the following
{{{
template<>
class integer_traits<unsigned long>
  : public std::numeric_limits<unsigned long>,
    public detail::integer_traits_base<unsigned long, 0, ULONG_MAX>
{ };
}}}

Problem is that, at least on Clang ULONG_MAX resolves to (through <limits.h>) to be

{{{
#define ULONG_MAX (__LONG_MAX__ *2UL+1UL)
}}}

But when __LONG_MAX__ resolves to long and the rules of arithmetic promotion result in the expression
__LONG_MAX__ *2UL+1UL being a long rather than unsigned long. This causes some funky behavior in cases like:

{{{
BOOST_MPL_ASSERT_RELATION(
    (boost::integer_traits<unsigned long>::const_max),
    >,
    (boost::integer_traits<unsigned char>::const_max)
);
}}}

which fails to compile with ""Non-type template argument evaluates to 4294967295, which cannot be narrowed to type 'long'",Robert Ramey
9643,rename should be more eplicit that it allows file move operations,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-02-07T14:57:54Z,2014-02-07T14:57:54Z,"The documentation for rename says that it renames the file and then refers to the ISO C web page for rename for details.  That page implies that the new name can be in another directory with the same filename to perform a move file operation, but it would be much more helpful if the boost filesystem documentation stated this explicitly.

On stackoverflow, someone comments that if the move files due to filesystem differences, then you have to do a copy/delete combination anyway.  It seems like if this is real possibility that boost.filesystme.rename should be enhanced to handle that for me so I don't have to remember a three-step operation in order to move files: 1) try rename and if that fails, then 2) copy file, and 3) delete file",Richard <legalize@…>
9642,Possible race condition in boost::interprocess::message_queue creation,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-07T14:50:29Z,2014-02-07T14:50:29Z,"Dear folks,

I am trying to debug sporadic access violations that occur inside a boost::interprocess message queue. (access violation reading an address in the shared memory region).

Environment: boost 1.54, VC++2010. Occurs in both Debug & Release builds.

It always occurs on or about line 854 (in case of reception) in message_queue.hpp: Comments were added by me

      recvd_size     = top_msg.len; // top_msg points to invalid location

Or line 756 (in case of sending)

BOOST_ASSERT(free_msg_hdr.priority == 0); // free_msg_hdr points to invalid location

Please see this S/O link for the entire question, plus sample code that reproduces the problem for me:

[http://stackoverflow.com/questions/21628306/boostinterprocess-message-queue-race-condition-on-creation]
",namezero@…
9634,v 1.54 - powerpc64/LE : filesystem : operations_test : core,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2014-02-06T13:13:02Z,2014-02-06T13:13:02Z,"Hi,
Test /boost1.54-1.54.0/bin.v2/libs/filesystem/test/operations_test_static.test/gcc-4.8/debug/link-static/operations_test generates a core, when testing it with version 1.54 on powerpc64/LE - Ubuntu 14.04 alpha2.
Defect has already been opened against Ubuntu, since they do not seem to have lunch Boost tests in this environment: no answer yet.
Debugging seems to show that the issue is in:

BOOST : libs/filesystem/src/path.cpp

  std::locale path::imbue(const std::locale& loc)
  {
    std::locale temp(path_locale); <<<<<<<<<<<<<<<<<<<<<<< line 918
    path_locale = loc;
    codecvt_facet_ptr =
      &std::use_facet<std::codecvt<wchar_t, char, std::mbstate_t> >(path_locale);
    return temp;
  }

At line 918, C++ tries to do some initialization. This seems to imply to use field _M_impl of path_locale, which is 0x0.
It seems that no initialization of path_locale is done and thus _M_impl stay 0x0. Then, there is a crash in stdlibc++ code.


(gdb) where
#0  boost::filesystem::path::imbue (loc=...) at ../libs/filesystem/src/path.cpp:918
#1  0x00000000100491b0 in boost::filesystem::path::codecvt () at ../libs/filesystem/src/path.cpp:911
#2  0x000000001004aa3c in boost::filesystem::path::wstring (this=0x3ffffffff5c8) at ../boost/filesystem/path.hpp:386
#3  0x000000001004a540 in boost::filesystem::detail::unique_path (model=..., ec=0x0) at ../libs/filesystem/src/unique_path.cpp:113
#4  0x00000000100238c4 in boost::filesystem::unique_path (p=...) at ../boost/filesystem/operations.hpp:544
#5  0x00000000100200cc in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../libs/filesystem/test/operations_test.cpp:118
#6  0x00000000100201fc in _GLOBAL__sub_I__Z8cpp_mainiPPc () at ../libs/filesystem/test/operations_test.cpp:2034
#7  0x000000001004d444 in __libc_csu_init ()
#8  0x00003fffb7c8e1ec in generic_start_main (main=0x1003173c <main(int, char**)>, argc=<optimized out>, argv=0x3ffffffffa68, auxvec=0x3ffffffffb10, init=0x1004d3b0 <__libc_csu_init>, 
    rtld_fini=<optimized out>, stack_end=<optimized out>, fini=<optimized out>) at ../csu/libc-start.c:246
#9  0x00003fffb7c8e458 in __libc_start_main (argc=<optimized out>, argv=<optimized out>, ev=<optimized out>, auxvec=<optimized out>, rtld_fini=<optimized out>, stinfo=<optimized out>, 
    stack_on_entry=<optimized out>) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:93
#10 0x0000000000000000 in ?? ()


(gdb) p loc
$25 = (const std::locale &) @0x3ffffffff418: {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 = 0x100790f0, static _S_classic = 0x3fffb7fae0b8 <(anonymous namespace)::c_locale_impl>, static _S_global = 0x3fffb7fae0b8 <(anonymous namespace)::c_locale_impl>, 
  static _S_categories = 0x3fffb7f92cb8 <__gnu_cxx::category_names>, static _S_once = 0}


(gdb) p path_locale
$26 = {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 = 0x0, 
  static _S_classic = 0x3fffb7fae0b8 <(anonymous namespace)::c_locale_impl>, static _S_global = 0x3fffb7fae0b8 <(anonymous namespace)::c_locale_impl>, 
  static _S_categories = 0x3fffb7f92cb8 <__gnu_cxx::category_names>, static _S_once = 0}


So, the question is: why path_locale has not been initialized ? and why this happens in PPC/LE and not elsewhere ?

I'm not an expert in C++ and need help.

Thanks/Regards

Tony",Tony Reix <tony.reix@…>
9631,function_input_iterator does not work with lambda,iterator,Boost 1.55.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-02-05T11:04:49Z,2014-02-26T21:29:01Z,"The following program does not compile on g++-4.8.1/clang-3.4 

  1 #define BOOST_RESULT_OF_USE_DECLTYPE
  2 #include <boost/iterator/function_input_iterator.hpp>
  3 
  4 int main() {    
  5     auto f = [](){return 1;};
  6     auto i = boost::make_function_input_iterator(f, 0);
  7     return 0;
  8 }

error:
g++ main.cpp -std=c++0x -I/home/wygos/libs/boost_1_55_0/include/

    In file included from main.cpp:2:0:
    /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp: In     instantiation of ‘class boost::impl::function_input_iterator<main()::__lambda0, int>’:
    /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp:112:11:     required from ‘class boost::function_input_iterator<main()::__lambda0, int>’
main.cpp:6:54:   required from here
    /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp:26:15: error: no type named ‘result_type’ in ‘struct main()::__lambda0’
         class function_input_iterator
               ^
    /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp:48:17: error: no type named ‘result_type’ in ‘struct main()::__lambda0’
                 dereference() const {
                 ^
    /home/wygos/libs/boost_1_55_0/include/boost/iterator/function_input_iterator.hpp:59:62: error: no type named ‘result_type’ in ‘struct main()::__lambda0’
             mutable optional<typename Function::result_type> value;

Suggested solution:
   function_input_iterator should use boost::result_of",Piotr Wygocki <wygos@…>
9627,Missing include and BOOST_NO_TYPEID check,exception,Boost 1.54.0,To Be Determined,Bugs,Emil Dotchevski,new,2014-02-03T07:58:38Z,2014-02-26T21:29:14Z,"Hello,

In boost 1.54 ""#include ""boost/throw_exception.hpp"""" is missing in dynamic_bitset/dynamic_bitset.hpp, so the macro BOOST_THROW_EXCEPTIO would be defined.
Also ""#ifndef BOOST_NO_TYPEID"" check is missing in ptr_container/clone_allocator.hpp and ptr_container/detail/reversible_ptr_container.hpp around the usage of BOOST_ASSERT where it uses typeid()",vency.cvetkov@…
9626,streams: ambiguous call to overloaded function when combining bufferstream and iostreams::filtering_streambuf,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-02-02T08:13:14Z,2014-02-02T08:16:41Z,"Hi,
I'm using interprocess::bufferstream, interprocess::basic_vectorstream and iostreams::filtering_streambuf to compress/decompress bzip2.
The attached code compiles and works fine in 54, but fails to compile in 55.
I've looked inside bufferstream.hpp and saw major changes (like multiple inheritance - which probably caused the problem).
(BTW, I couldn't find the description of these changes in the 55 release notes. Where can I find it?)

Thank you,
Edan Ayal",Edan Ayal <edanayal@…>
9624,boost::icl::swap causes ambiguity with std::swap with ADL,ICL,Boost 1.53.0,To Be Determined,Bugs,Joachim Faulhaber,new,2014-01-31T18:28:35Z,2014-01-31T18:28:35Z,"With C++11, the swap() function overload in boost::icl is ambiguous with std::swap due to ADL.  I'm using boost 1.53, but this doesn't appear to be addressed in git yet either. It think it's the exact same problem previously addressed in Boost.Variant (https://svn.boost.org/trac/boost/ticket/2839).

I've applied the same fix (i.e., using separate template params for two arguments to swap, making it less specialized than std::swap) to my local copy of boost, and it appears to resolve it.

I'm using clang 3.4 / libstdc++ from gcc 4.7.2 / boost 1.53, compile line ==> clang -std=c++11 -o test_adl test_adl.cc

test file and error message attached.

Thanks,
--Nathan
",Nathan Thomas <nthomas@…>
9623,boost::asio does not respect FD_SETSIZE limit in select() based implementation,asio,Boost 1.51.0,To Be Determined,Bugs,chris_kohlhoff,new,2014-01-31T15:02:51Z,2014-01-31T15:02:51Z,Compiled on Linux with BOOST_ASIO_DISABLE_EPOLL.,anonymous
9622,Add function time created file.,filesystem,Boost Release Branch,To Be Determined,Feature Requests,Beman Dawes,new,2014-01-31T11:33:48Z,2014-01-31T11:33:48Z,,bubokastor@…
9614,Optional File Creation for boost::interprocess::file_lock,interprocess,Boost 1.54.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-01-28T21:54:43Z,2014-01-28T21:54:43Z,"An optional overload (default second argument?) for the constructor to create and open the file to use for the file_lock would be very useful.

Currently, when creating a file lock, I typically do something like:

{{{
std::ofstream tmpf(/path/to/lock/file);  tmpf.close();
boost::interprocess:file_lock f_lock(/path/to/lock/file);
}}}

Say I have a class, such as:

{{{
class Foo
{
  public:
    Foo();

  private:
    boost::interprocess::file_lock f_lock;
};
}}}

I have to do the following in the constructor:

{{{
Foo::Foo()
{
  std::ofstream tmpf(/path/to/lock/file);  tmpf.close();
  boost::interprocess:file_lock tmp_lock(/path/to/lock/file);  

  f_lock.swap(tmp_lock);
}
}}}

This is cumbersome and limits usefulness in initializer lists.  Tweaking the constructor to something like:

{{{
file_lock::file_lock(const char *path, bool create = false);
}}}

Would allow a constructor to do the following:

{{{
Foo::Foo()
  : f_lock(/path/to/file/lock, true)
{
}
}}}
",Peter LaDow <petela@…>
9611,boost::algorithm::clamp not available as boost::clamp,algorithm,Boost 1.55.0,To Be Determined,Bugs,Marshall Clow,new,2014-01-27T20:46:57Z,2016-07-18T08:09:12Z,clamp isn't available in boost namespace itself while other algorithms are. Could it be added?,Olaf van der Spek <ml@…>
9608,Reset on Report and Custom String,timer,Boost 1.55.0,To Be Determined,Feature Requests,Beman Dawes,new,2014-01-26T19:38:56Z,2014-01-26T19:38:56Z,"It might be nice if there's a way for the timer to reset on report.
And for report to take a string argument so the output could include what the time is about.",Olaf van der Spek <ml@…>
9607,auto_cpu_timer constructors Typo,timer,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-26T19:33:45Z,2014-01-26T19:33:45Z,"""Otherwise format_string() == std::cout""

I don't think this is correct.",Olaf van der Spek <ml@…>
9606,Boost.LocalFunction cannot bind pointer variables by reference on gcc/clang,local function,Boost Development Trunk,To Be Determined,Bugs,Lorenzo Caminiti,new,2014-01-25T16:44:37Z,2014-03-07T16:05:33Z,"Boost.LocalFunction cannot bind pointer variables by reference on gcc or clang. I have tested this against the latest boost code available in version 1.55.0 and r86799. I have tested that it works on Visual Studio though but not on gcc 4.1 (Linux), 4.6 (Linux), nor clang 5.0 (OSX). Here's the test

{{{
// Example compile: g++ -I /usr/local/include/boost_1_55_0 -o bug bug.cpp
#include <boost/local_function.hpp>
#include <stdio.h>
int main()
{
	int x = 1;
	int *px = &x;

	void BOOST_LOCAL_FUNCTION(bind& px, bind& x)
	{
		printf(""INSIDE:  &px = %p, &x = %p\n"", &px, &x);
	}
	BOOST_LOCAL_FUNCTION_NAME(fubar)

	printf(""OUTSIDE: &px = %p, &x = %p\n"", &px, &x);
	fubar();

	return 0;
}
}}}
 
The pointer values output by this program should be identical for both the INSIDE and OUTSIDE cases. Notice that value  for &px differs.

I found some ways to sort of make this work but none of them are acceptable workarounds for me:
- Binding pointer variables works perfectly in Boost.ScopeExit for all compilers/platforms that I tested
- Adding ""-std=c++0x"" to the compiler line also fixes the problem 
",e4lam@…
9604,compilation failure c1017,parameter,Boost 1.54.0,To Be Determined,Patches,Daniel Wallin,new,2014-01-24T16:41:22Z,2014-01-24T16:41:22Z,"Using MSVC++ 2012, compiling my program gives me the following error.

{{{
C1017: invalid integer constant expression.
in boost\parameter\aux_\unwrap_cv_reference.hpp:47

#if BOOST_WORKAROUND(MSVC, == 1200)
}}}

This can be fixed easily by replacing MSVC by BOOST_MSVC on this line.
",orenaud@…
9599,Add a parallel_transform algorithm,thread,Boost 1.54.0,To Be Determined,Feature Requests,viboes,assigned,2014-01-22T12:03:31Z,2014-01-22T12:06:12Z,"

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

The main difference is that the algorithm could take an Executor as parameter.
",viboes
9598,no operator found which takes a left-hand operand of type 'boost::filesystem::directory_iterator',filesystem,Boost 1.54.0,To Be Determined,Support Requests,Beman Dawes,new,2014-01-22T08:25:26Z,2014-02-26T21:30:13Z,"Hi,

I'm working with the Boost C++ library since a long time and suddenly I got stranges error when I compile my software with Visual Studio 2012 (in debug 64 bits). I have absolutely no idea of the problem and the ""output"" does not really help me.

Here are the kind of errors I got (the output):

_libraries\lib_Boost\boost/iterator/iterator_facade.hpp(847): error C2059: syntax error : ','

And the following one too :


I'm working with the Boost C++ library since a long time and suddenly I got stranges error when I compile my software with Visual Studio 2012 (in debug 64 bits). I have absolutely no idea of the problem and the ""output"" does not really help me.

Here are the kind of errors I got (the output):


{{{
_libraries\lib_Boost\boost/iterator/iterator_facade.hpp(847): error C2059: syntax error : ','
}}}

And the following one too :


{{{
_libraries\lib_Boost\boost/filesystem/operations.hpp(798): error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'boost::filesystem::directory_iterator' (or there is no acceptable conversion)
          _libraries\lib_Boost\boost/filesystem/path.hpp(621): could be 'bool boost::filesystem::operator !=(const boost::filesystem::path &,const boost::filesystem::path &)'
          _libraries\lib_Boost\boost/filesystem/path.hpp(622): or       'bool boost::filesystem::operator !=(const boost::filesystem::path &,const boost::filesystem::path::string_type &)'
          _libraries\lib_Boost\boost/filesystem/path.hpp(623): or       'bool boost::filesystem::operator !=(const boost::filesystem::path::string_type &,const boost::filesystem::path &)'
          _libraries\lib_Boost\boost/filesystem/path.hpp(624): or       'bool boost::filesystem::operator !=(const boost::filesystem::path &,const boost::filesystem::path::value_type *)'
          _libraries\lib_Boost\boost/filesystem/path.hpp(625): or       'bool boost::filesystem::operator !=(const boost::filesystem::path::value_type *,const boost::filesystem::path &)'
          while trying to match the argument list '(boost::filesystem::directory_iterator, boost::filesystem::directory_iterator)'
}}}



Does someone has an idea that can help me to find the reason of theses errors ? Is there some compilation options that can help to find the problem ?

I only have theses 2 errors (a lot of time !!)

Feel free to contact me by email... I'm also available through Skype.

Thanks",krys@…
9597,"""boost::iostreams::file_descriptor"" doesn't close Windows low-level file descriptors properly when specifying ""file_descriptor_flags::close_handle""",iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2014-01-20T15:32:51Z,2014-01-20T15:32:51Z,"When opening a file on Windows using {{{boost::iostreams::file_descriptor}}}, {{{boost::iostreams::file_descriptor_sink}}} or {{{boost::iostreams::file_descriptor_source}}} in combination with a low-level file descriptor and when specifying {{{file_descriptor_flags::close_handle}}}, then the file descriptor isn't closed properly on close/exit.

Using one of the mentioned methods, the low-level file descriptor is converted to a Windows handle using the API call {{{_get_osfhandle}}} [#point1 (1)]: 
{{{#!c++
void file_descriptor_impl::open(int fd, flags f)
{ open(reinterpret_cast<file_handle>(_get_osfhandle(fd)), f); }
}}}
When closing, the file handle is closed using {{{CloseHandle}}}:
{{{#!c++
void file_descriptor_impl::close_impl(bool close_flag, bool throw_) {
    if (handle_ != invalid_handle()) {
        if (close_flag) {
            bool success = 
                #ifdef BOOST_IOSTREAMS_WINDOWS
                    ::CloseHandle(handle_) == 1;
                #else
                    BOOST_IOSTREAMS_FD_CLOSE(handle_) != -1;
                #endif
            if (!success && throw_)
                throw_system_failure(""failed closing file"");
        }
        handle_ = invalid_handle();
        flags_ = 0;
    }
}
}}}

According to [#point1 (1)] the API call {{{_close}}} [#point2 (2)] shall be used to close a low-level file descriptor.
Practical tests shew that every time a file is opened and closed using one of the mentioned methods, Windows (XP) assigns a new file descriptor with an increasing value to it, unless the program runs out of available file handles. Manually closing the file by specifying {{{file_descriptor_flags::close_handle}}} and calling {{{_close}}} solves this issue.

[=#point1 (1)] http://msdn.microsoft.com/en-us/library/ks2530z6.aspx \\
[=#point2 (2)] http://msdn.microsoft.com/en-us/library/5fzwd5ss.aspx",anonymous
9592,Add a parallel_for_each algorithm,thread,Boost 1.55.0,To Be Determined,Feature Requests,viboes,assigned,2014-01-18T11:01:52Z,2014-01-21T18:04:27Z,"Base on  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_for_each algorithm.

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

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

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

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

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

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

The main difference is that the algorithm could take an Executor as parameter.",viboes
9586,Boost Date/Time should use BOOST_TRY/CATCH instead of try,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2014-01-17T17:32:12Z,2018-01-18T13:58:59Z,"Hello,

We had to activate the USE_DATE_TIME_PRE_1_33_FACET_IO and modify a few files in try/catches to BOOST_TRY/CATCH in date_time/gregorian/greg_facet.hpp to get our Date/Time dependency compiling in non-exception code. Here's the attached patch.

However, Date/Time depends too heavily on try/catch behavior in detriment to projects wanting to use it but without exceptions. Can this be fixed for a next iteration of Boost?",catalinalexandru.zamfir@…
9583,Support of wide character filenames in boost::interprocess::file_lock,interprocess,Boost 1.55.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2014-01-16T09:12:54Z,2014-01-16T09:16:51Z,"boost::interprocess::file_lock is unable to handle paths with wide character filenames.

This feature is already commented in the list of future improvements

I attach one patch to add this support for Windows platform (you can use boost::filesystem::c_str() and it will hide if it is char* or wchar_t* for you :))
",jmalo@…
9582,Boost.Units: conversion to double with prefixed unit,units,Boost 1.54.0,To Be Determined,Feature Requests,Matthias Schabel,new,2014-01-16T08:59:23Z,2014-03-16T11:52:09Z,"A post to the Boost-users maillinglist suggested me to request this feature.

In the code below, I convert a double that is known to be in millimeters to a unit and back again. The latter fails, where it works as expected for meters.

I think that adding this feature increases the symmetry in the use of Boost.Units, as I have emphasised in my code.

I am aware of the great care the Boost.Units developers have in maintaining type-safety, so it might be that I am unaware of code compiling that shouldn't would this request be acknowledged.

{{{
using boost::units::conversion_factor;
using boost::units::quantity;
using boost::units::si::length;
using boost::units::si::meter;
using boost::units::si::milli;
typedef quantity<length> Length;

//This value is read from file
const double x_in_mm = 1.0;

//Add units
const Length x(x_in_mm * (milli * meter)); //Brackets added for emphasis

const double x_again_in_m  = x / meter; //Works

const double x_again_in_mm {
  x / (milli * meter) //Same brackets as at emphasis
}; //Why doesn't this?

assert(x_in_mm == x_again_in_mm);
}}}
",richel@…
9580,"[spirit.lex] self(""state"") += calls a wrong operator +=",spirit,Boost Development Trunk,To Be Determined,Bugs,Hartmut Kaiser,new,2014-01-16T00:38:18Z,2014-01-30T15:52:29Z,"This construct
{{{
#!cpp
      this->self(""SOME_STATE"") += someTokenDef;
}}}
doesn't call
{{{
#!cpp
        template <typename LexerDef, typename Expr>
        inline lexer_def_<LexerDef>&
        boost::spirit::lex::detail::operator+= (lexer_def_<LexerDef>& lexdef, Expr&& xpr)
}}}
as it should in order for the definition get added to the lexer. Instead this operator
{{{
#!cpp
        template <typename Left, typename Right>
        typename boost::proto::detail::enable_binary<
            deduce_domain
          , deduce_domain::proto_grammar
          , boost::mpl::or_<is_extension<Left>, is_extension<Right> >
          , boost::proto::tag::plus_assign
          , Left const &
          , Right const &
          >::type const
        operator +=(Left &&left, Right &&right)
        {
            return boost::proto::detail::make_expr_<
                boost::proto::tag::plus_assign
              , deduce_domain
              , Left const &
              , Right const &
              >()(left, right);
        }
}}}
is called from boost::proto::exprns_ namespace.",Vyacheslav Andrejev
9577,trim_copy doesn't support string_ref,algorithm,Boost 1.55.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2014-01-15T19:07:55Z,2014-03-31T20:00:27Z,"{{{
boost::string_ref z = ""  AA BB  "";
boost::string_ref b = boost::trim_copy(z);
}}}
does not compile",ml@…
9576,read_until for string_ref,algorithm,Boost 1.54.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2014-01-15T15:13:20Z,2014-01-24T09:04:41Z,"{{{
string_ref read_until(string_ref& is, const char* sep);
}}}

Could we have a function like this that reads until a separator, returns the part before the separator and then eats the separator?
It should read and return the entire input if no separator is found.",Olaf van der Spek <ml@…>
9575,"is_directory() wrong with NTFS mounted volumes,  and temp_directory_path()  fails then",filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-15T08:59:08Z,2014-01-15T08:59:08Z,"is_directory() returns false with NTFS mounted volumes in Windows.
This look like the same problem as #5649, but the consequences are more serious I think.
Some people put the temp directory on a mounted volume, and in this case temp_directory_path() fails although windows has a valid temporary directory.
I use some commercial software that uses temp_directory_path() which will fail without useful error messages.",andreas.malzahn@…
9573,"type_rebinder<int,type_2,0>  template specialization is not found using Sun's compiler 12.3",interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2014-01-14T20:22:32Z,2014-02-26T21:28:43Z,"'''#include <boost/interprocess/managed_mapped_file.hpp>[[BR]]
using namespace boost::interprocess;[[BR]]
typedef  boost::interprocess::managed_mapped_file::segment_manager        segment_manager_t;'''[[BR]]


/*[[BR]]
Including those 3 lines above , is like code below when Sun's compiler trying to
    specialize type_rebinder<int, second_rebind_type_t, 0> and it does not find it, because of int = Ptr
    and there is no specialization for that type

Compilation command : /appl/toolbox/solarisstudio12.3/bin/CC -v -library=stdcxx4 -D_XOPEN_SOURCE=500 -I/home/uqadir/boost_1_55/boost
_1_55_0/ main.cpp

#include <boost/intrusive/set_hook.hpp>[[BR]]
#include <boost/intrusive/detail/generic_hook.hpp>[[BR]]
#include <boost/interprocess/detail/segment_manager_helper.hpp>[[BR]]
#include <boost/intrusive/pointer_traits.hpp>[[BR]]
#include <boost/intrusive/detail/utilities.hpp>[[BR]]
#include <boost/intrusive/detail/memory_util.hpp>[[BR]]

typedef boost::intrusive::bhtraits<boost::interprocess::ipcdetail::intrusive_value_type_impl< boost::intrusive::generic_hook< boost:
:intrusive::get_set_node_algo<boost::interprocess::offset_ptr<void, int, unsigned, 0>, 1>, boost::intrusive::default_tag, 1, 3>, cha
r, unsigned>, boost::intrusive::rbtree_node_traits< boost::interprocess::offset_ptr<void, int, unsigned, 0>, 1>, 1, boost::intrusive
::default_tag, 3 >  '''second_rebind_type_t''' ;[[BR]]

typedef boost::intrusive::detail::type_rebinder 
<'''int''', second_rebind_type_t, '''0'''>::type my_type; '''<-- no such specialization in boost''' [[BR]]
*/

main ()
{
}


",vladmir.venediktov@…
9570,TTI doesn't support inheritance or at least this is not documented anywhere,tti,Boost 1.54.0,To Be Determined,Bugs,Edward Diener,new,2014-01-13T21:05:51Z,2014-03-04T15:33:48Z,"If I didn't know better (not mentioned in TFM) I'd find the behavior of this program very surprising (g++-mp-4.8 -std=c++0x ..., from macports):

#include ""boost/tti/has_member_function.hpp""

struct Container {
	void func() {}
};

struct Container2 : public Container {
	using Container::func; // doesn't help
};

//typedef Container container_t; // ok
typedef Container2 container_t; // fail

BOOST_TTI_HAS_MEMBER_FUNCTION(func)

static_assert(
	has_member_function_func<
		container_t,
		void,
		boost::mpl::vector<>
	>::value,
	""fail""
);

int main(int, char**) { return 0; }
",anonymous
9568,incomplete type is not allowed,typeof,Boost 1.55.0,To Be Determined,Bugs,Peder Holt,new,2014-01-13T11:49:45Z,2014-01-13T11:49:45Z,"if compiling with latest intel compiler XE Composer 2013 SP1 IA-32 with vs2012 compilation fails, 

--- using BOOST_TYPEOF_SUPPRESS_UNNAMED_NAMESPACE did not modify anything, because reason is due to typeof ---


../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp(50): error: incomplete type is not allowed
      struct encode_type : BOOST_TYPEOF_ENCODE_NS_QUALIFIER::encode_type_impl<V, T>
                           ^
          detected during:
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector1<boost::mpl::size_t<327820U>>, T=Ado::COMPtr_::COMPtr<Ado::
IAdoRepoSession>]"" at line 140 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp""
            instantiation of class ""boost::type_of::encode_type_impl<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=Ado::C
OMPtr_::COMPtr<Ado::IAdoRepoSession>]"" at line 50
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<Ado::COMPtr_::
COMPtr<Ado::IAdoRepoSession>>]"" at line 581 of ""../../src/global/basic/aserialization_handler.cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp(140): error: class ""boost::type_of::encode_type<boost::type_of::vector1<boost::mpl::size_t
<327820U>>, Ado::COMPtr_::COMPtr<Ado::IAdoRepoSession>>"" has no member ""type""
  BOOST_TYPEOF_REGISTER_TEMPLATE(boost::scope_exit::detail::wrapper, 1)
  ^
          detected during:
            instantiation of class ""boost::type_of::encode_type_impl<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=Ado::C
OMPtr_::COMPtr<Ado::IAdoRepoSession>]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp""
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<Ado::COMPtr_::
COMPtr<Ado::IAdoRepoSession>>]"" at line 581 of ""../../src/global/basic/aserialization_handler.cxx""

../../src/global/basic/aserialization_handler.cxx(581): error: class ""boost::type_of::decode_begin<boost::type_of::vector50<boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>>>"" has no member class ""type""
        BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_))
        ^

../../src/global/basic/aserialization_handler.cxx(581): error: not a class or struct name
        BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_))
        ^

../../src/global/basic/aserialization_handler.cxx(581): error: class ""boost_se_wrapped_t_0_581"" has no member ""type""
        BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_))
        ^

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp(50): error: incomplete type is not allowed
      struct encode_type : BOOST_TYPEOF_ENCODE_NS_QUALIFIER::encode_type_impl<V, T>
                           ^
          detected during:
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector1<boost::mpl::size_t<327820U>>, T=Ado::COMPtr_::COMPtr<Ado::
IAdoRepository>]"" at line 140 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp""
            instantiation of class ""boost::type_of::encode_type_impl<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=Ado::C
OMPtr_::COMPtr<Ado::IAdoRepository>]"" at line 50
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<Ado::COMPtr_::
COMPtr<Ado::IAdoRepository>>]"" at line 581 of ""../../src/global/basic/aserialization_handler.cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp(140): error: class ""boost::type_of::encode_type<boost::type_of::vector1<boost::mpl::size_t
<327820U>>, Ado::COMPtr_::COMPtr<Ado::IAdoRepository>>"" has no member ""type""
  BOOST_TYPEOF_REGISTER_TEMPLATE(boost::scope_exit::detail::wrapper, 1)
  ^
          detected during:
            instantiation of class ""boost::type_of::encode_type_impl<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=Ado::C
OMPtr_::COMPtr<Ado::IAdoRepository>]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp""
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<Ado::COMPtr_::
COMPtr<Ado::IAdoRepository>>]"" at line 581 of ""../../src/global/basic/aserialization_handler.cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(29): error: name followed by ""::"" must be a class or namespace name
          BOOST_PP_REPEAT(BOOST_TYPEOF_LIMIT_SIZE, BOOST_TYPEOF_sizer_item, ~)
          ^
          detected during instantiation of class ""boost::type_of::sizer<V> [with V=<error-type>]"" at line 581 of ""../../src/global/basic/aserialization_handler.
cxx""

../../src/global/basic/aserialization_handler.cxx(581): error: class ""boost::type_of::decode_begin<boost::type_of::vector50<boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>>>"" has no member class ""type""
        BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_))
        ^

../../src/global/basic/aserialization_handler.cxx(581): error: not a class or struct name
        BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_))
        ^

../../src/global/basic/aserialization_handler.cxx(581): error: class ""boost_se_wrapped_t_1_581"" has no member ""type""
        BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_))
        ^

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp(50): error: incomplete type is not allowed
      struct encode_type : BOOST_TYPEOF_ENCODE_NS_QUALIFIER::encode_type_impl<V, T>
                           ^
          detected during:
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector1<boost::mpl::size_t<65592U>>, T=Ado::SerializationHandler::
Impl]"" at line 56 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/modifiers.hpp""
            instantiation of class ""boost::type_of::encode_type_impl<V, T *> [with V=boost::type_of::vector0<void>, T=Ado::SerializationHandler::Impl]"" at line
50
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=Ado::SerializationHandler::Impl *]"" at line 581 o
f ""../../src/global/basic/aserialization_handler.cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/modifiers.hpp(56): error: class ""boost::type_of::encode_type<boost::type_of::vector1<boost::mpl::s
ize_t<65592U>>, Ado::SerializationHandler::Impl>"" has no member ""type""
  BOOST_TYPEOF_modifier_support(BOOST_TYPEOF_UNIQUE_ID(), BOOST_TYPEOF_pointer_fun);
  ^
          detected during:
            instantiation of class ""boost::type_of::encode_type_impl<V, T *> [with V=boost::type_of::vector0<void>, T=Ado::SerializationHandler::Impl]"" at line
50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp""
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=Ado::SerializationHandler::Impl *]"" at line 581 o
f ""../../src/global/basic/aserialization_handler.cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/typeof_impl.hpp(44): error: class ""boost::enable_if<boost::integral_constant<bool, 0>, boost::type
_of::sizer<<error-type>>>"" has no member ""type""
          sizer<typename encode_type<V, T>::type> >::type encode(T&);
                                                     ^
          detected during instantiation of ""boost::type_of::encode"" based on template arguments <boost::type_of::vector0<void>, Ado::SerializationHandler::Impl
*> at line 581 of ""../../src/global/basic/aserialization_handler.cxx""

../../src/global/basic/aserialization_handler.cxx(581): error: no instance of constructor ""boost_se_params_t_581::boost_se_params_t_581"" matches the argument li
st
            argument types are: (Ado::COMPtr_::COMPtr<Ado::IAdoRepoSession>, Ado::COMPtr_::COMPtr<Ado::IAdoRepository>, Ado::SerializationHandler::Impl *)
        BOOST_SCOPE_EXIT((pNewRepoSession) (pCurrentRepo) (this_))
        ^

../../src/global/basic/aserialization_handler.cxx(583): error: expression must have pointer type
          this_->_CloseNewRepoSession(pNewRepoSession, pCurrentRepo);
          ^

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp(50): error: incomplete type is not allowed
      struct encode_type : BOOST_TYPEOF_ENCODE_NS_QUALIFIER::encode_type_impl<V, T>
                           ^
          detected during:
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector2<boost::mpl::size_t<327820U>, boost::mpl::size_t<65589U>>,
T=Ado::COMPtr_::COMPtr<Ado::IAdoSerializer>]"" at line 53 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/modifiers.hpp""
            instantiation of class ""boost::type_of::encode_type_impl<V, const T> [with V=boost::type_of::vector1<boost::mpl::size_t<327820U>>, T=Ado::COMPtr_::C
OMPtr<Ado::IAdoSerializer>]"" at line 50
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector1<boost::mpl::size_t<327820U>>, T=const Ado::COMPtr_::COMPtr
<Ado::IAdoSerializer>]"" at line 140 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp""
            instantiation of class ""boost::type_of::encode_type_impl<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=const
Ado::COMPtr_::COMPtr<Ado::IAdoSerializer>]"" at line 50
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<const Ado::COM
Ptr_::COMPtr<Ado::IAdoSerializer>>]"" at line 907 of ""../../src/global/basic/aserialization_handler.cxx""

../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/modifiers.hpp(53): error: class ""boost::type_of::encode_type<boost::type_of::vector2<boost::mpl::s
ize_t<327820U>, boost::mpl::size_t<65589U>>, Ado::COMPtr_::COMPtr<Ado::IAdoSerializer>>"" has no member ""type""
  BOOST_TYPEOF_modifier_support(BOOST_TYPEOF_UNIQUE_ID(), BOOST_TYPEOF_const_fun);
  ^
          detected during:
            instantiation of class ""boost::type_of::encode_type_impl<V, const T> [with V=boost::type_of::vector1<boost::mpl::size_t<327820U>>, T=Ado::COMPtr_::C
OMPtr<Ado::IAdoSerializer>]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp""
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector1<boost::mpl::size_t<327820U>>, T=const Ado::COMPtr_::COMPtr
<Ado::IAdoSerializer>]"" at line 140 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/scope_exit.hpp""
            instantiation of class ""boost::type_of::encode_type_impl<V, boost::scope_exit::detail::wrapper<P0>> [with V=boost::type_of::vector0<void>, P0=const
Ado::COMPtr_::COMPtr<Ado::IAdoSerializer>]"" at line 50 of ""../../../build_link/i140-vc110-mt-gd-6_4/include/boost/typeof/encode_decode.hpp""
            instantiation of class ""boost::type_of::encode_type<V, T> [with V=boost::type_of::vector0<void>, T=boost::scope_exit::detail::wrapper<const Ado::COM
Ptr_::COMPtr<Ado::IAdoSerializer>>]"" at line 907 of ""../../src/global/basic/aserialization_handler.cxx""

../../src/global/basic/aserialization_handler.cxx(907): error: class ""boost::type_of::decode_begin<boost::type_of::vector50<boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost:
:mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>,
          boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>, boost::mpl::size_t<<error-constant>>
, boost::mpl::size_t<<error-constant>>>>"" has no member class ""type""
          BOOST_SCOPE_EXIT(pSerializer)
          ^

../../src/global/basic/aserialization_handler.cxx(907): error: not a class or struct name
          BOOST_SCOPE_EXIT(pSerializer)
          ^

../../src/global/basic/aserialization_handler.cxx(907): error: class ""boost_se_wrapped_t_0_907"" has no member ""type""
          BOOST_SCOPE_EXIT(pSerializer)",iloehken@…
9566,program_options parsers.cpp does not compile: template-related error,program_options,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2014-01-13T10:44:55Z,2014-01-13T10:44:55Z,"When compiling program_options/src/parsers.cpp for sun/release/stdlib-sun-stlport/threading-multi Sun Studio 11 C++ 5.8, the compiler issues the following errors:

 ""libs/program_options/src/parsers.cpp"", line 162: Error: Could not find a match for boost::program_options::parse_config_file<boost::program_options::charT>(const char*, const boost::program_options::options_description&, bool).
 ""libs/program_options/src/parsers.cpp"", line 169: Error: Could not find a match for boost::program_options::parse_config_file<boost::program_options::charT>(const char*, const boost::program_options::options_description&, bool).

The attached patch solves the problem by expliciting the template parameter for parse_config_file. I guess this is a bug in the compiler rather than in boost, but it seems to me that the suggested patch is still correct C++. Since this is the only issue that would inhibit use of program_options on my platform, for me it would be very useful to integrate the patch into the library.",rv1971 <rv1971@…>
9562,boost::detail::operator_brackets_proxy::result_type::operator= return type is wrong,iterator,Boost 1.54.0,To Be Determined,Bugs,jeffrey.hellrung,new,2014-01-11T19:05:22Z,2014-01-14T05:25:06Z,"From boost/iterator/detail/operator_brackets_dispatch.hpp:

{{{
template <class Iterator, class Reference>
struct operator_brackets_proxy
{
    class result_type
    {
        Iterator const m_i;
        explicit result_type(Iterator const & i) : m_i(i) { }
        friend struct operator_brackets_proxy;
        void operator=(result_type&);
    public:
        operator Reference() const { return *m_i; }
        operator_brackets_proxy const & operator=(
          typename Iterator::value_type const & x) const
        { *m_i = x; return *this; }
    };
    static result_type apply(Iterator const & i)
    { return result_type(i); }
};
}}}

The return type of `result_type::operator=` should be `result_type const &`, not `operator_brackets_proxy const &`. This looks like a typo.",Eric Niebler
9560,operations_test_static unit test crashes during static initialization phase on Mac/10.7/32-bit/darwin-4.2.1,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-10T21:11:28Z,2014-04-16T15:20:49Z,"Verifying a 32-bit build of Boost on Mac, I get a consistent crash in operations_test_static during static initialization (prior to main() invocation).  Problem appears to be a lack of initialization of path.hpp's anon namespace 'codecvt_facet_ptr'.

Platform:  1.55.0, Mac OS 10.7, Xcode 4.3.3, darwin-4.2.1,
address-model=32, architecture=x86

Build sequence is (approximately):

{{{
./bjam toolset=darwin variant=debug address-model=32 architecture=x86 --layout=tagged --with-filesystem -sNO_BZIP2=1 -d2 -d+4 stage
cd libs/filesystem/test
../../../bjam toolset=darwin variant=debug address-model=32 architecture=x86 --layout=tagged --with-filesystem -sNO_BZIP2=1 -d2 -d+4 -a -q
}}}

Stacktrace of access violation:

{{{
(gdb) run
Starting program: /Users/monty/3P/3p-boost-update/boost/bin.v2/libs/filesystem/test/operations_test_static.test/darwin-4.2.1/debug/address-model-32/architecture-x86/link-static/operations_test_static 
Reading symbols for shared libraries ++......................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00058054 in std::__codecvt_abstract_base<wchar_t, char, __mbstate_t>::in (this=0x0, __state=@0xbfffeba0, 
    __from=0x1660cc ""operations-test-%%%%-%%%%-%%%%-%%%%"", __from_end=0x1660ef """", __from_next=@0xbfffeb9c, 
    __to=0xbfffec90, __to_end=0xbffff090, __to_next=@0xbfffeb98) at codecvt.h:206
206				   __to, __to_end, __to_next);
(gdb) where
#0  0x00058054 in std::__codecvt_abstract_base<wchar_t, char, __mbstate_t>::in (this=0x0, __state=@0xbfffeba0, 
    __from=0x1660cc ""operations-test-%%%%-%%%%-%%%%-%%%%"", __from_end=0x1660ef """", __from_next=@0xbfffeb9c, 
    __to=0xbfffec90, __to_end=0xbffff090, __to_next=@0xbfffeb98) at codecvt.h:206
#1  0x00057e10 in convert_aux (from=0x1660cc ""operations-test-%%%%-%%%%-%%%%-%%%%"", from_end=0x1660ef """", 
    to=0xbfffec90, to_end=0xbffff090, target=@0xbffff200, cvt=@0x0) at path_traits.cpp:76
#2  0x00057908 in boost::filesystem::path_traits::convert (from=0x1660cc ""operations-test-%%%%-%%%%-%%%%-%%%%"", 
    from_end=0x1660ef """", to=@0xbffff200, cvt=@0x0) at path_traits.cpp:158
#3  0x00058c79 in boost::filesystem::path::wstring (this=0xbffff288, cvt=@0x0) at path.hpp:392
#4  0x00058d0a in boost::filesystem::path::wstring (this=0xbffff288) at path.hpp:386
#5  0x00058346 in boost::filesystem::detail::unique_path (model=@0xbffff288, ec=0x0) at unique_path.cpp:113
#6  0x000375fb in boost::filesystem::unique_path (p=@0xbffff288) at operations.hpp:544
#7  0x000339b5 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
    at operations_test.cpp:118
#8  0x0003371a in global constructors keyed to _ZN12_GLOBAL__N_18platformE () at operations_test.cpp:2035
#9  0x8fe11203 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#10 0x8fe10d68 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#11 0x8fe0e2c8 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
    ()
#12 0x8fe0f268 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
#13 0x8fe03694 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#14 0x8fe07f99 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#15 0x8fe012ef in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_ ()
#16 0x8fe01063 in __dyld__dyld_start ()
}}}
",Monty Brandenberg <mcbinc@…>
9557,BOOST_FOREACH with iterators?,foreach,Boost 1.55.0,To Be Determined,Feature Requests,Eric Niebler,new,2014-01-09T00:02:17Z,2014-01-09T00:02:17Z,"I love BOOST_FOREACH and use it all the time.

The normal signature is 

BOOST_FOREACH( T & t, Collection<T>){...}

Would it be possible to also permit

BOOST_FOREACH( T *, Collection<T>){..>}

This would make it even more useful to me.

Robert Ramey",Robert Ramey
9555,signals - libs/signals/test/swap_test.cpp compilation error on Debian squeeze,signals,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2014-01-08T18:23:25Z,2014-01-08T18:23:25Z,"Unit tests for 'signals' library fail to compile on Debian due to missing '#include <iostream>' in swap_test.cpp.

Platform:  Debian squeeze (6.0.5), target=gcc-4.6, architecture=x86, 32-bit, variant=release (debug variant compiles).  Unit tests being run under bjam with 'variant=release -a -q -d2 -d+4' arguments produce the following error:

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall  -DBOOST_ALL_NO_LIB=1 -DBOOST_SIGNALS_NO_DEPRECATION_WARNING -DBOOST_SIGNALS_STATIC_LINK -DBOOST_TEST_NO_AUTO_LINK=1 -DNDEBUG  -I""../../.."" -c -o ""../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static/swap_test.o"" ""swap_test.cpp""

In file included from ../../../boost/config.hpp:26:0,
                 from ../../../boost/signal.hpp:25,
                 from swap_test.cpp:4:
../../../boost/config/user.hpp:111:0: warning: ""BOOST_ALL_NO_LIB"" redefined [enabled by default]
<command-line>:0:0: note: this is the location of the previous definition
swap_test.cpp: In member function 'void HelloWorld::operator()() const':
swap_test.cpp:11:5: error: 'cout' is not a member of 'std'
0.000007 sec system; 0.000087 sec user
...failed gcc.compile.c++ ../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static/swap_test.o...
...skipped <p../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static>swap_test for lack of <p../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static>swap_test.o...
SEM: <s>gcc-link-semaphore now used by <p../../../bin.v2/libs/signals/test/swap_test.test/gcc-4.6/release/link-static>swap_test
...failed updating 1 target...
...skipped 1 target...
...updated 50 targets...
ERROR: building default configuration returned 1



Mercurial unified diff of fix:


{{{
diff -r af87ea28f909 boost/libs/signals/test/swap_test.cpp
--- a/boost/libs/signals/test/swap_test.cpp     Thu Dec 19 23:16:23 2013 +0000
+++ b/boost/libs/signals/test/swap_test.cpp     Wed Jan 08 18:20:02 2014 +0000
@@ -1,8 +1,9 @@
 //     https://svn.boost.org/trac/boost/ticket/5521 
 //             claims a linker error for this.
 
+#include <iostream>
 #include <boost/signal.hpp>
 #include <boost/signals/connection.hpp>
 
 struct HelloWorld 
 {

}}}
",Monty Brandenberg <mcbinc@…>
9554,read_graphviz example code crashes,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2014-01-08T11:57:46Z,2014-01-08T12:11:48Z,"The example code for read_graphviz crashes when run.

http://www.boost.org/doc/libs/1_55_0/libs/graph/doc/read_graphviz.html#example

See also http://stackoverflow.com/q/20967950/16582",anonymous
9552,bimap compilation fails on 1.55 that was successful on 1.54 (hash_detail issues),bimap,Boost 1.55.0,To Be Determined,Bugs,Matias Capeletto,new,2014-01-08T05:36:30Z,2014-01-08T05:36:30Z,"Bimap compilation fails on Boost 1.55 because of hashing issues.
Platform: gcc (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1 x64, C++11 compilation mode

Bimap declaration:
{{{
	typedef boost::bimap<boost::bimaps::unordered_set_of<Id>,
		boost::bimaps::unconstrained_set_of<Id>,
		boost::bimaps::vector_of_relation>  Nbimap;
	Nbimap  m_nbimap;
}}}
Where id is unsigned int or int (conditional).

Build log is attached.",Artem V L <luart@…>
9549,[graph][BGL][PBGL] Dynamic_properties class does not allow distributed property_maps,graph,Boost Development Trunk,To Be Determined,Patches,Jeremiah Willcock,new,2014-01-07T11:48:26Z,2014-01-07T11:55:14Z,"I am working with parallel graphs and distributed property maps.
I found a problem compiling the code when I intended to add a distributed property map to the dynamic_property variable.
The error was a casting problem:
error: inicialización inválida de una referencia que no es constante de tipo ‘boost::default_property_traits<boost::parallel::distributed_property_map<boost::graph::distributed::mpi_process_group, boost::detail::parallel::global_descriptor_property_map<long unsigned int>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_in_edges_t, std::list<boost::detail::parallel::stored_in_edge<boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int> >, std::allocator<boost::detail::parallel::stored_in_edge<boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int> > > >, VertexProperties>, boost::property<boost::edge_target_processor_id_t, short int, EdgeProperties>, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_in_edges_t, std::list<boost::detail::parallel::stored_in_edge<boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int> >, std::allocator<boost::detail::parallel::stored_in_edge<boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int> > > >, VertexProperties>, boost::property<boost::edge_target_processor_id_t, short int, EdgeProperties>, boost::no_property, boost::listS>*, double, double&, double VertexProperties::*> > >::reference {aka double&}’ desde un r-valor de tipo ‘boost::parallel::distributed_property_map<boost::graph::distributed::mpi_process_group, boost::detail::parallel::global_descriptor_property_map<long unsigned int>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_in_edges_t, std::list<boost::detail::parallel::stored_in_edge<boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int> >, std::allocator<boost::detail::parallel::stored_in_edge<boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int> > > >, VertexProperties>, boost::property<boost::edge_target_processor_id_t, short int, EdgeProperties>, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_in_edges_t, std::list<boost::detail::parallel::stored_in_edge<boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int> >, std::allocator<boost::detail::parallel::stored_in_edge<boost::detail::edge_desc_impl<boost::directed_tag, long unsigned int> > > >, VertexProperties>, boost::property<boost::edge_target_processor_id_t, short int, EdgeProperties>, boost::no_property, boost::listS>*, double, double&, double VertexProperties::*> >::value_type {aka double}’

I also want to propose a patch to solve this problem. ",anonymous
9547,"Boost Filesystem documentation contains now removed ""make_absolute()"" method",filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-06T15:37:19Z,2014-01-06T15:37:19Z,"In http://www.boost.org/doc/libs/1_55_0/libs/filesystem/doc/reference.html#class-path
there is a ""path"" method ""make_absolute()"" that doesn't exist anymore.

It points to the non-member operational function ""absolute()"" that replaces ""make_absolute()"" though.

Has this commit not been backported?
https://svn.boost.org/trac/boost/changeset/80163",riccardi@…
9545,program_options description printout bug,program_options,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2014-01-06T12:29:02Z,2014-01-07T18:44:42Z,"When setting the default value of a float option to 0.05, the help description that is printed by the program states that the default value is 0.0500000007. For double, it states ""0.050000000000000003"". The value of the variable within the program is correct, i.e. 0.05.

I'm compiling with:

$ g++ --version
g++ (GCC) 4.8.3 20131226 (prerelease)

Here is a test program that reproduces the problem when run with the option ""--help"":

{{{
#include ""boost/program_options.hpp""

int main(int argc, char ** argv)
{
	float dt;

	boost::program_options::variables_map vm;
	boost::program_options::options_description desc(""Description"");
	desc.add_options()
		(""help"", ""Print help message"")
		(""dt"", boost::program_options::value<float>(&dt)->default_value(0.05), ""Time step"")
	;

	boost::program_options::store(boost::program_options::parse_command_line(argc, argv, desc), vm);
	boost::program_options::notify(vm);

	if(vm.count(""help"")) desc.print(std::cout);

	std::cout << ""dt = "" << dt << ""\n"";

	return 0;
}
}}}

",Torquil Sørensen <torquil@…>
9542,[system] BOOST_ERROR_CODE_HEADER_ONLY only works with full source tree,system,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2014-01-04T11:24:51Z,2014-01-04T11:24:51Z,defining the BOOST_ERROR_CODE_HEADER_ONLY symbol only works when using the source tree. but it breaks compilation when the boost headers and compiled libraries are installed (e.g. in /usr/include or other fhs-like locations).,timblechmann
9538,BOOST_PROTO_USE_NORMAL_RESULT_OF incorrectly defined,proto,Boost 1.55.0,To Be Determined,Bugs,Eric Niebler,new,2013-12-31T18:32:22Z,2013-12-31T18:32:22Z,"In proto/proto_fwd.hpp, based on how the macro BOOST_PROTO_USE_NORMAL_RESULT_OF is used, it's meant to be defined when the compiler supports c++11 decltype and implements N3276, for example, BOOST_PROTO_RESULT_OF is boost::result_of when BOOST_PROTO_USE_NORMAL_RESULT_OF is defined.

However, its definition seems incorrect, and is inconsistent with the comments next to it.


{{{

#ifdef BOOST_NO_CXX11_DECLTYPE_N3276
^^^^^^ this should be #ifndef 

# // Proto can only use the decltype-based result_of if N3276 has been
# // implemented by the compiler.
# // See http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3276.pdf
# ifndef BOOST_PROTO_USE_NORMAL_RESULT_OF
#  define BOOST_PROTO_USE_NORMAL_RESULT_OF
# endif
#endif

}}}


",Hui Li <Hui.Li@…>
9536,narrow-conversion uses insufficient input char type,date_time,Boost 1.55.0,To Be Determined,Bugs,az_sw_dude,new,2013-12-30T17:20:39Z,2013-12-30T17:32:35Z,"Test runs exhibit this problem:

{{{
compile-c-c++ ..\..\..\bin.v2\libs\date_time\test\teststreams.test\msvc-12.0\debug\address-model-64\posix_time\teststreams.obj
teststreams.cpp
boost/date_time/posix_time/posix_time_legacy_io.hpp(83) : warning C4244: 'argument' : conversion from 'wchar_t' to 'char', possible loss of data
        posix_time\teststreams.cpp(144) : see reference to function template instantiation 'std::basic_istream<wchar_t,std::char_traits<wchar_t>> &boost::posix_time::operator >><wchar_t>(std::basic_istream<wchar_t,std::char_traits<wchar_t>> &,boost::posix_time::time_duration &)' being compiled
}}}

The current implementation uses std::stringstream::narrow(char) with its 'char' input parameter type to transform 'charT' chars taken from a std::basic_istream<charT> into 'char' chars. This is most likely not what is intended if 'charT' is wider than 'char'.

Tests were run against Boost version 1.55.0 and latest 'development' branch using vc10, vc11, and vc12. Test logs are attached.
",dani@…
9533,boost::accumulators::weighted_median different results for debug and release modes,accumulator,Boost 1.55.0,To Be Determined,Bugs,Matthias Troyer,new,2013-12-29T17:05:47Z,2013-12-30T07:38:13Z,"I have a different results for debug and release modes. Look at readme and example in

https://github.com/aurusov/boost_accumulators_weighted_median_error",Andrey Urusov <drobus@…>
9532,BCP stackoverflow on Boost.Log,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-12-29T17:04:48Z,2014-03-14T12:15:28Z,"Boost.BCP fails to process Boost.Log:
{{{
C:\Program Files (x86)\boost\boost_1_55_0>bin.v2\tools\bcp\msvc-11.0\release\link-static\bcp.exe --list log

**** exception(225): stack overflow
******** errors detected; see standard output for details ********
}}}
",Evgeny.Panasyuk@…
9530,Building Boost with minGW,Building Boost,Boost 1.55.0,To Be Determined,Support Requests,,new,2013-12-29T05:47:06Z,2013-12-31T01:33:15Z,"Hey,
I use CodeBlocks(minGW) and I'm having problems with building boost.
""C:\Program Files (x86)\CodeBlocks\MinGW\bin"" is in the Path variable and I was able to build b2 and bjam with ""bootstrap.bat gcc"" but after ""b2 toolset=gcc --build-type=complete"" I get some errors.

output:
{{{
link.jam: No such file or directory

Building the Boost C++ Libraries.


Performing configuration checks

    - 32-bit                   : yes
    - arm                      : no
    - mips1                    : no
    - power                    : no
    - sparc                    : no
    - x86                      : yes
    - has_icu builds           : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add ""using mpi ;"" to your user-config.jam
    - zlib                     : no
    - iconv (libc)             : no
    - iconv (separate)         : no
    - icu                      : no
    - icu (lib64)              : no
    - g++ -shared-* supported  : yes
    - message-compiler         : no
    - compiler-supports-ssse3  : yes
    - compiler-supports-avx2   : yes
    - gcc visibility           : yes
    - long double support      : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add ""using mpi ;"" to user-config.jam.
note: to suppress this message, pass ""--without-mpi"" to bjam.
note: otherwise, you can safely ignore this message.
warning: No python installation configured and autoconfiguration
note: failed.  See http://www.boost.org/libs/python/doc/building.html
note: for configuration instructions or pass --without-python to
note: suppress this message and silently skip all Boost.Python targets
    - zlib                     : no  (cached)
    - zlib                     : no  (cached)
    - zlib                     : no  (cached)
    - zlib                     : no
    - zlib                     : no  (cached)
    - zlib                     : no  (cached)
    - zlib                     : no  (cached)
    - zlib                     : no  (cached)
    - zlib                     : no  (cached)
    - zlib                     : no  (cached)
    - zlib                     : no  (cached)
C:/libs/boost_1_55_0/tools/build/v2/build\virtual-target.jam:1099: in virtual-target.register-actual-name from module virtual-target
error: Duplicate name of actual target: <pstage\lib>libboost_exception-mgw47-mt-1_55.a
error: previous virtual target { common%common.copy-libboost_exception-mgw47-mt-1_55.a.STATIC_LIB { gcc%gcc.archive-libboost_exception-mgw47-mt-1_55.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } } }
error: created from ./stage-proper
error: another virtual target { common%common.copy-libboost_exception-mgw47-mt-1_55.a.STATIC_LIB { gcc%gcc.archive-libboost_exception-mgw47-mt-1_55.a.STATIC_LIB { gcc%gcc.compile.c++-clone_current_exception_non_intrusive.o.OBJ { clone_current_exception_non_intrusive.cpp.CPP } } } }
error: created from ./stage-proper
error: added properties: <linkflags>-shared-libgcc <linkflags>-shared-libstdc++
error: removed properties: none
C:/libs/boost_1_55_0/tools/build/v2/build\virtual-target.jam:484: in actualize-no-scanner from module object(file-target)@5267
C:/libs/boost_1_55_0/tools/build/v2/build\virtual-target.jam:134: in class@virtual-target.actualize from module object(file-target)@5267
C:/libs/boost_1_55_0/tools/build/v2\build-system.jam:720: in load from module build-system
C:\libs\boost_1_55_0\tools\build\v2/kernel\modules.jam:289: in import from module modules
C:\libs\boost_1_55_0\tools\build\v2/kernel/bootstrap.jam:139: in boost-build from module
C:\libs\boost_1_55_0\boost-build.jam:17: in module scope from module

}}}
",anonymous
9525,Assert with program termination due to context<...>() call in simple_state's entry action is incorrect,statechart,Boost 1.49.0,To Be Determined,Bugs,Andreas Huber,new,2013-12-26T12:58:40Z,2014-01-26T18:12:14Z,"{{{
#include <boost/statechart/state_machine.hpp>
#include <boost/statechart/simple_state.hpp>

namespace sc = boost::statechart;

struct state;
struct fsm : sc::state_machine<fsm, state> {
    void test() {}
};

struct state : sc::simple_state<state, fsm> {
    state() { context<fsm>().test(); }
};

int main() {
    fsm test;
    test.initiate();
}

}}}

{{{
statechart_test: /usr/include/boost/statechart/simple_state.hpp:682: static OtherContext& boost::statechart::simple_state<MostDerived, Context, InnerInitial, historyMode>::context_impl_other_context::context_impl(State&) [with OtherContext = fsm; State = boost::statechart::simple_state<state, fsm>; MostDerived = state; Context = fsm; InnerInitial = boost::mpl::list<mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>; boost::statechart::history_mode historyMode = (boost::statechart::history_mode)0u]: Assertion `get_pointer( stt.pContext_ ) != 0' failed.
Аварийный останов
}}}

It's not correct to throw uncatchable surprises like asserts. It's especially incorrect when your library is used in the embedded software.

Not to mention this isn't reflected anywhere in the documentation.

Please change this to exception throwing, or better, find a way to detect calls like that at compile time. But don't use asserts. That's just bad treatment of your users.",anonymous
9523,reserve() corrupts data in boost::bimap vector_of_relation,bimap,Boost 1.54.0,Boost 1.56.0,Bugs,Matias Capeletto,new,2013-12-24T18:15:22Z,2013-12-24T18:15:22Z,"bimap::reserve() has bad behavior:
  1. Corrupts the data by inserting item into the empty bimap
  2. Reserves incorrect amount of elements capacity

Environment: Linux Ubuntu x64 3.2.0-57-generic 87-Ubuntu SMP, gcc (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1

Code:
{{{
	typedef unsigned  Id;
	const unsigned  m_nodes = 1518;

	typedef boost::bimap<boost::bimaps::unordered_set_of<Id>,
		boost::bimaps::unconstrained_set_of<Id>,
		boost::bimaps::vector_of_relation>  Nbimap;
	Nbimap  m_nbimap;


fprintf(stderr, ""Initial bmsize: %u, capacity: %u\n"", m_nbimap.size(), m_nbimap.capacity());
	m_nbimap.reserve(m_nodes);
fprintf(stderr, ""Postreserve bmsize: %u, capacity: %u, nsize: %u\n"", m_nbimap.size(), m_nbimap.capacity(), m_nodes);
}}}

Console output:
{{{
Initial bmsize: 0, capacity: 0
Postreserve bmsize: 1, capacity: 15, nsize: 1518
}}}
",Artem V L <luart@…>
9521,Exception when passing buffer to read_xml(),property_tree,Boost 1.51.0,To Be Determined,Bugs,Sebastian Redl,new,2013-12-24T05:05:03Z,2013-12-24T05:54:48Z,"Hi,
I have taken reference from https://svn.boost.org/trac/boost/ticket/3831

I have made changes for read_xml(), now I am getting below exception
""ex.what():: <unspecified file>(1): expected <""

code:

string fileDataStr ((const char*)xmlFileBuffer);
boost::property_tree::ptree pt;
std::stringstream ss;
ss<<fileDataStr;
boost::property_tree::read_xml( ss, tree );",Hitesh Saxena
9510,std::swap should be pulled in from <utility> in C++11,swap,Boost 1.55.0,To Be Determined,Patches,joseph.gauterin,new,2013-12-19T17:06:03Z,2013-12-19T17:06:03Z,included <utility> and removed <algorithm> in swap.hpp as in c++11 std::swap is present in <utility>,sambitbolt@…
9508,1.54 regression: boost/thread/once.hpp includes boost/placeholders.hpp,bind,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-12-19T02:22:06Z,2014-01-13T22:05:14Z,"{{{
#include <functional>
#include <boost/thread/once.hpp>

using namespace std::placeholders;

static int x = sizeof(_1);
}}}

The code above compiles in C++11 mode on boost 1.53, but it fails on boost 1.54 like this:
{{{
boost_bind_bug.cpp:6:23: error: reference to ‘_1’ is ambiguous
 static int x = sizeof(_1);
                       ^
In file included from boost_bind_bug.cpp:1:0:
/usr/include/c++/4.8.2/functional:1004:34: note: candidates are: const std::_Placeholder<1> std::placeholders::_1
     extern const _Placeholder<1> _1;
                                  ^
In file included from /usr/include/boost/bind/bind.hpp:1742:0,
                 from /usr/include/boost/bind.hpp:22,
                 from /usr/include/boost/thread/pthread/once_atomic.hpp:19,
                 from /usr/include/boost/thread/once.hpp:20,
                 from boost_bind_bug.cpp:2:
/usr/include/boost/bind/placeholders.hpp:55:15: note:                 boost::arg<1> {anonymous}::_1
 boost::arg<1> _1;
               ^
}}}

This magic inclusion of boost/bind/placeholders.hpp is extremely impolite.",luto@…
9507,[bcp] bcp creates broken build for asio component,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-12-18T14:06:23Z,2015-09-09T07:52:51Z,"When I try to extract the 'asio' component via bcp (and custom namespace), I end up with a broken build environment in the target dir. Every other component I tried to extract this way works.

I'm on OS X 10.9.1 using XCode 5 command line tools.

Steps to reproduce (in bash):


{{{
./bootstrap.sh

( cd tools/bcp/ && ../../tools/build/v2/engine/bin.macosxx86_64/bjam toolset=darwin )

./dist/bin/bcp --namespace=akboost --namespace-alias \
    build \
    asio \
    $HOME/build/akboost/

cp bjam $HOME/build/akboost

cd $HOME/build/akboost

./bjam -d+2 debug release \
    toolset=darwin \
    threading=multi \
    link=static \
    cxxflags=-stdlib=libstdc++ \
    cxxflags=-mmacosx-version-min=10.7 \
    linkflags=-stdlib=libstdc++ \
    linkflags=-mmacosx-version-min=10.7 \
    --toolset-root=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk \
    --macosx-version=10.7 --macosx-version-min=10.7 \
    --layout=tagged \
    --build-dir=$HOME/build/akboost_1.55_build \
    --prefix=$HOME/akboost_1.55.0 \
    install
}}}

This yields this error from bjam:


{{{
link.jam: No such file or directory
error: Unable to find file or target named
error:     '/boost/context//boost_context'
error: referred to from project at
error:     'libs/coroutine/build'
error: could not resolve project reference '/boost/context'
}}}

If I use bcp to extract any other component (I tried algorithm, assign, chrono, date_time, detail, filesystem, filesystem3, foreach, gil, iostreams, multi_array, multi_index, numeric, property_tree, regex, serialization spirit signal system, timer and thread) everything works just fine and bjam works its magic.

",virtualritz@…
9505,Replace plain throw with BOOST_THROW_EXCEPTION,tokenizer,Boost 1.55.0,To Be Determined,Patches,jsiek,new,2013-12-17T16:11:10Z,2013-12-17T16:11:10Z,"Hello,

could you please have a look at the pull request here:
https://github.com/boostorg/tokenizer/pull/1

Thanks,
Gregor",Gregor Jasny <gjasny@…>
9502,Unexpected behaviour of boost::mpi::request::test(),mpi,Boost 1.55.0,To Be Determined,Bugs,Matthias Troyer,new,2013-12-17T14:04:33Z,2013-12-17T14:04:33Z,"The following code snippet shows that boost::mpi::request::test() behaves differently depending on whether we send a message of built-in type or a message of custom type:

{{{
struct custom_type {
    template<class Archive>
    void serialize(Archive& ar, const unsigned int version) {}
};

[...]

int i;
auto req = comm.irecv(0,0,i);
req.wait();
std::cout << ""Did we receive the built in type message: "" << bool(req.test()) << std::endl;

custom_type c;
auto req = comm.irecv(0,0,c);
req.wait();
std::cout << ""Did we receive the custom type message: "" << bool(req.test()) << std::endl;
}}}

Output:

{{{
Did we receive the built in type message: 1
Did we receive the custom type message: 0
}}}


Similar behaviour is observed if you just repeatedly call req.test(): For the built-in type, the returned boost::optional switches from empty to non-empty once and then stays non-empty, whereas for the custom type it switches from empty to non-empty and in the next call goes back to empty again. 

For our application, it would be desirable if the custom type behaviour would be the same as the built-in type behaviour. If this is not possible or not advisable, then at least the documentation of boost::mpi::request should mention this difference in behaviour. ",ettersi@…
9499,Oracle Solaris Studio 5.12 warning at os_thread_functions.hpp line 465,interprocess,Boost 1.55.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-12-16T18:14:42Z,2013-12-24T16:29:00Z,"Would be great if the following warning could be rectified.
Thanks!

""path/to/boost/interprocess/detail/os_thread_functions.hpp"", line 465: Warning (Anachronism), badargtype2w: Formal argument 3 of type extern ""C"" void*(*)(void*) in call to pthread_create(unsigned*, const _pthread_attr*, extern ""C"" void*(*)(void*), void*) is being passed void*(*)(void*).
",alessio.massaro@…
9495,property_tree json_read should accept iterators instead of just streams,property_tree,Boost Development Trunk,To Be Determined,Patches,Sebastian Redl,new,2013-12-15T11:57:20Z,2015-07-07T14:05:45Z,"For a project I am using boost::property_tree abundantly. The trees need to be transfered across all kinds of interfaces and I have ran the limited function call several times.

It requires a istream to read from. To make matters worse, as soon as it enters the function, a complete copy is made to a vector. And that happens when I already had to make a copy because the read_json method expects to consume all input data, which rarely happens for me. I know the exact beginning and ending position in the stream, but there is no way to specify this.

The following function signature would be prefered:

{{{#!cpp
 template<typename Iterator, class Ptree>
    void read_json_internal(Iterator begin,
                            Iterator end,
                            Ptree &pt,
                            const std::string &filename)
}}}

This signature could still be used by the existing read_json_internal, which first converts this to a vector and then passed the vector iterators begin and and to this function, to avoid code duplication.

Of course, the proper front-end in json_parser.hpp needs to be added to.

The benefit is that this method can operate directly on my input sequence where I can specify exactly where the JSON states and where the JSON ends, avoiding all copies completely.

I will attach a patch based on SVN Trunk that will accomplish this. ",Egbert van der Wal <ewal@…>
9493,labeled_graph may refer to and operate on released memory after removing a vertex by label,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2013-12-13T12:39:26Z,2015-09-23T13:08:15Z,"Although `labeled_graph` is not officially part of BGL API some people try to use it.

Unfortunately, the current implementation has a serious bug that might lead to a crash. The problem appears when removing a vertex from labeled_graph by its label. My investigation shown that despite of vertex being actually removed, the label is not and it still refers to the removed vertex.

The problem is ""easier"" to reproduce when adjacency_list's VertexList is set to a container like boost::listS.

The attached test case shows the problem.
I also attached the output from a valgrind run on the test case code and a patch that fixes the issue for the ""configuration"" that I use (a more generic fix will probably be needed).",Adam Romanek <romanek.adam@…>
9487,Missing codepage identifiers in wconv_codepage.ipp,locale,Boost Development Trunk,To Be Determined,Bugs,Artyom Beilis,new,2013-12-11T16:36:36Z,2013-12-11T16:36:36Z,"The list of supported charsets in wconv_codepage.ipp is very limited. Any encoding not mentioned there will result in invalid_charset_error exception on Windows.

See list of available Windows codepage identifiers: http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx

Personally I'm very interested in codepage 866 support (legacy/DOS Russian encoding, still widely seen in legacy documents in Russia).
But I think most, if not all, supported Windows encoding should work in Boost.Locale (they do work in ICU/iconv, of course).",Nikita Ofitserov <himikof@…>
9485,stdout and stderr not forwarded to respective channels,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2013-12-10T23:19:46Z,2013-12-10T23:19:46Z,"Apparently, Boost.Build does not forward output sent out by commands it executes to respective channels to which the output is originally sent by executed commands.

Simple test on Linux seems to prove that:

{{{
$ cat Jamroot
exe testcpp : test.cpp ;
$ cat test.cpp 
X main() {}
$ b2 1>/dev/null
$ b2 2>/dev/null
...found 7 targets...
...updating 2 targets...
gcc.compile.c++ bin/gcc-4.8.2/debug/test.o
test.cpp:1:1: error: ‘X’ does not name a type
 X main() {}
 ^

    ""g++""  -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC     -c -o ""bin/gcc-4.8.2/debug/test.o"" ""test.cpp""

...failed gcc.compile.c++ bin/gcc-4.8.2/debug/test.o...
...skipped <pbin/gcc-4.8.2/debug>testcpp for lack of <pbin/gcc-4.8.2/debug>test.o...
...failed updating 1 target...
...skipped 1 target...
$ 
}}}

I've observed the same channel merging in [https://github.com/mloskot/qt-creator-plugin-boostbuild Boost.Build Plugin for Qt Creator] that I have been developing.

I asked on IRC about it, and Volodya confirmed channels should not be merged:
{{{
<volodya> mloskot: I think children stdout and stderr should be forwarded to stdout and stderr respectively.
}}}

So, I think it is a bug.
",Mateusz Loskot
9480,make_permissions slower then it needs to be,filesystem,Boost Development Trunk,To Be Determined,Patches,Beman Dawes,new,2013-12-09T13:06:56Z,2017-04-30T17:17:38Z,"in libs\filesystem\src\operations.cpp the make_permissions calls path::extension four times, which accounts for pretty much 100% of the cpu cycles outside the OS call of the directory iterators increment function.
A better approach would be to get the extension string once and reuse it four times. Even better would be to find the last '.' in the filename and avoid the extra std::string construction.

  perms make_permissions(const path& p, DWORD attr)
  {
    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;
    std::string ext = p.extension().string();
    if (BOOST_FILESYSTEM_STRICMP(ext.c_str(), "".exe"") == 0
      || BOOST_FILESYSTEM_STRICMP(ext.c_str(), "".com"") == 0
      || BOOST_FILESYSTEM_STRICMP(ext.c_str(), "".bat"") == 0
      || BOOST_FILESYSTEM_STRICMP(ext.c_str(), "".cmd"") == 0)
      prms |= fs::owner_exe | fs::group_exe | fs::others_exe;
    return prms;
  }

Or for extra performance (avoids construction of one std::string for the extension at the price of extra nasty code):

  perms make_permissions(const path& p, DWORD attr)
  {
    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;
    const std::string& path_str = p.string();
    if (path_str.size() >= 4) {
      const char* ext = path_str.c_str() + path_str.size() - 4;
      if (BOOST_FILESYSTEM_STRICMP(ext, "".exe"") == 0
        || BOOST_FILESYSTEM_STRICMP(ext, "".com"") == 0
        || BOOST_FILESYSTEM_STRICMP(ext, "".bat"") == 0
        || BOOST_FILESYSTEM_STRICMP(ext, "".cmd"") == 0)
        prms |= fs::owner_exe | fs::group_exe | fs::others_exe;
    }
    return prms;
  }
",Adrian Dorr <a.dorr@…>
9478,boost::iostreams::copy - sink - ENOSPC (No space left on device) error handling,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-12-07T09:39:47Z,2013-12-07T18:57:47Z,"Platform: GCC on Linux; boost 1.55.

In the code fragment below, is there a way to handle ENOSPC?

{{{
#include <fstream>
#include <iostream>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/filter/bzip2.hpp>

// open input file stream of the bzip2 file
std::ifstream ifs(""file.bz2"");

// open output stream to the ""full"" device
// full device is a ""utility-device"" to check how applications handle ENOSPC
// more details in ""man full""
std::ofstream ofs(""/dev/full"");

// Setup the iostreams filter
boost::iostreams::filtering_streambuf<boost::iostreams::output> filters;
filters.push(boost::iostreams::bzip2_decompressor());
filters.push(ofs);

// ""run"" the filter
boost::iostreams::copy(ifs, filters);
}}}

If I do strace of the compiled binary, the code seem to infinitely call writev() with the same data and returns ENOSPC error.

{{{
writev(4, [{NULL, 0}, {""DATA DATA ""..., 4096}], 2) = -1 ENOSPC (No space left on device)
}}}

How can this error be handled or made thrown as an error from `boost::iostreams::copy()`

Is it possible to set appropriate exceptions() on the ofstream object? I tried `ofs.exceptions(std::ios::badbit | std::ios::failbit)` but it didn't make any difference.
",dckorah@…
9477,Trac - captcha not working for new ticket; non-https link blocked by browser,trac / subversion,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2013-12-07T09:38:52Z,2013-12-11T06:38:27Z,Impossible to create new ticket unless you use specific browser features (firefox) to override the blocking.,dckorah@…
9476,boost::iostreams::copy - sink - ENOSPC (No space left on device) error handling,iostreams,Boost 1.55.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-12-07T09:33:56Z,2013-12-11T06:39:27Z,"Platform: GCC on Linux; boost 1.55.

In the code fragment below, is there a way to handle ENOSPC?

{{{
#include <fstream>
#include <iostream>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/filter/bzip2.hpp>

// open input file stream of the bzip2 file
std::ifstream ifs(""file.bz2"");

// open output stream to the ""full"" device
// full device is a ""utility-device"" to check how applications handle ENOSPC
// more details in ""man full""
std::ofstream ofs(""/dev/full"");

// Setup the iostreams filter
boost::iostreams::filtering_streambuf<boost::iostreams::output> filters;
filters.push(boost::iostreams::bzip2_decompressor());
filters.push(ofs);

// ""run"" the filter
boost::iostreams::copy(ifs, filters);
}}}

If I do strace of the compiled binary, the code seem to infinitely call writev() with the same data and returns ENOSPC error.

{{{
writev(4, [{NULL, 0}, {""DATA DATA ""..., 4096}], 2) = -1 ENOSPC (No space left on device)
}}}

How can this error be handled or made thrown as an error from `boost::iostreams::copy()`

Is it possible to set appropriate exceptions() on the ofstream object? I tried `ofs.exceptions(std::ios::badbit | std::ios::failbit)` but it didn't make any difference.
",anonymous
9472,Undocumented define causes header-only libraries to have link dependency on system,system,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2013-12-04T21:54:23Z,2013-12-06T18:12:23Z,"Code using the ASIO library must be linked with a boost binary lib, even though asio is considered 'header only' library.

Test system - ubuntu 13.10, using boost 1.55 download archive (not installed package).

Similar problem reported in ticket 7085.  Suspect this is systemic.

Demo source code:

{{{
/*
$ g++ -I. -Wall asio_link_fail.cpp -Wno-unused-local-typedefs

/tmp/ccjgSD3Q.o: In function `__static_initialization_and_destruction_0(int, int)':
asio_link_fail.cpp:(.text+0x50): undefined reference to `boost::system::generic_category()'
asio_link_fail.cpp:(.text+0x5a): undefined reference to `boost::system::generic_category()'
asio_link_fail.cpp:(.text+0x64): undefined reference to `boost::system::system_category()'
/tmp/ccjgSD3Q.o: In function `boost::asio::error::get_system_category()':
asio_link_fail.cpp:(.text._ZN5boost4asio5error19get_system_categoryEv[_ZN5boost4asio5error19get_system_categoryEv]+0x7): undefined reference to `boost::system::system_category()'
collect2: error: ld returned 1 exit status
*/

#include ""boost/asio.hpp""

int main() {
    return 1;
}
}}}

",soda@…
9470,Example in documentation uses wrong parameter type,program_options,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-12-04T11:48:00Z,2013-12-04T11:48:00Z,"The example of parse_config_file in http://www.boost.org/doc/libs/1_55_0/doc/html/program_options/overview.html#idp163372680 uses a filename as first parameter, but the library expects a std::istream.

",bohn@…
9469,std::swap should be pulled in from <utility> in C++11,swap,Boost 1.55.0,To Be Determined,Bugs,joseph.gauterin,new,2013-12-04T09:34:53Z,2013-12-04T09:34:53Z,"boost/utility/swap.hpp #includes <algorithm> to bring std::swap in, which is OK for C++03 but not so in C++11: std::swap has been moved to <utility> as explained in [diff.cpp03.library].",Joaquín M López Muñoz
9465,"Issues with kqueue_reactor, dynamic libraries and -fvisibility=hidden",asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-12-03T13:22:52Z,2013-12-03T13:22:52Z,"I've discovered a problem within a larger project for MacOS which uses multiple dynamic libraries and asio features (deadline_timers and tcp/udp sockets). 

After investigating the problem I've managed to reproduce it in the following minimal example: 


{{{
////////// Timer.hpp ////////// 

#ifndef TIMER_HPP 
#define TIMER_HPP 

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

#define VISIBLE __attribute__ ((visibility (""default""))) 

class VISIBLE Timer { 
  public: 
    Timer(boost::asio::io_service& service); 
  private: 
    void onTimeout(const boost::system::error_code& code); 
    boost::asio::deadline_timer timer; 
}; 
#endif // Timer_HPP 


////////// Timer.cpp ////////// 

#include <Timer.hpp> 

Timer::Timer(boost::asio::io_service& service) : timer(service) { 
  timer.expires_from_now(boost::posix_time::seconds(1)); 
  timer.async_wait(boost::bind(&Timer::onTimeout, this, _1)); 
} 

void Timer::onTimeout(const boost::system::error_code& code) { 
  std::cout << ""The callback from the dynamic library was called."" << std::endl; 
} 


////////// main.cpp ////////// 

#include <Timer.hpp> 

boost::asio::io_service service; 

void run() { 
  service.run(); 
} 

void onTimeout(const boost::system::error_code& code) { 
  std::cout << ""The callback from main was called."" << std::endl; 
} 

int main() { 
  Timer timer(service); 
  boost::asio::deadline_timer deadline_timer(service); 
  deadline_timer.expires_from_now(boost::posix_time::seconds(1)); 
  deadline_timer.async_wait(boost::bind(&onTimeout, _1)); 
  boost::thread t(boost::bind(&run)); 
  t.join(); 
  return 0; 
} 

}}}

Timer.cpp is compiled into a dynamic library and used by main.cpp which is compiled as an executable. 
The environment: MacOS 10.8.5, Boost 1.54.0, clang 500.2.79 

The parameters which are passed to clang at compilation time are:


{{{
clang++ -ggdb -c Timer.cpp -I. -I/opt/local/include -fPIC -fvisibility=hidden
}}}
 


{{{
clang++ -ggdb -o libTimer.dylib -dynamiclib Timer.o -L/opt/local/lib -lboost_thread-mt -lboost_system-mt -fvisibility=hidden
}}}
 


{{{
clang++ -ggdb main.cpp -o runTest -I. -I/opt/local/include -L. -L/opt/local/lib -lboost_thread-mt -lboost_system-mt -lTimer fvisibility=hidden
}}}
 

The visibility is set to hidden at compilation time in order to expose only desired functions (e.g. the Timer class) from my library. 
The problem that arise is that the callback of the timer from main.cpp is never called. 
If I remove the visibility flag at compilation time the example works as it should (both timer callbacks are called). 

When I did further investigations I've observed that 2 kqueue_reactor instances are create when using hidden visibility and only one kqueue_reactor is created when visibility is set to default. 

When compiling the example on Linux using visibility set to hidden the example works as expected.",avbica@…
9463,Boost subgraph copy constructor in 1.55.0 not working properly but works well i 1.46.0,graph,Boost 1.55.0,To Be Determined,Bugs,Jeremiah Willcock,new,2013-12-03T07:05:01Z,2013-12-03T07:05:01Z,"While using the boost 1.46.0, the copy constructor worked well to copy all deep level subgraphs. In this a recursive call to new subgraph is invoked while iterating over subgraphs hence it works well.
But for boost 1.55.0, children iterator is used to iterate over subgraphs and as children iterator is able to iterate over only next level subgraphs, it do not perform deep copy and hence deep level subgraphs are not getting copied properly.
I think children iterator should be made to iterate all deep level subgraphs so as to make it work like 1.46.0 ",Mayur Narkhede <mayur_narkhede@…>
9460,boost::statechart::fifo_worker not working well when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined,statechart,Boost 1.55.0,To Be Determined,Bugs,Andreas Huber,new,2013-12-02T16:15:43Z,2015-07-07T13:25:04Z,"boost::statechart::fifo_worker uses boost::mutex::scoped_lock typedef which is not accessible when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined (this macro is defined when BOOST_THREAD_VERSION is set to 4).[[BR]]
I suggest to replace scoped_lock typedefs with explicit boost::unique_lock usage.[[BR]]
Best regards, Maksim.",myasnikovmaksim@…
9459,Boost Locale not compiling when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined,locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,new,2013-12-02T16:06:04Z,2013-12-02T16:09:48Z,"Boost Locale uses Boost Thread lock types which definitions are not included through <boost/thread/mutex.hpp> when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined (this macro is defined when BOOST_THREAD_VERSION is set to 4).
I suggest to include <boost/thread/lock_types.hpp> in every file that uses any lock type.
Since I build Boost only on Windows platforms attached patch may be incomplete.
Best regards, Maksim.",myasnikovmaksim@…
9458,Boost Locale not compiling when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined,locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,new,2013-12-02T16:02:49Z,2015-07-07T13:24:49Z,"Boost Locale uses Boost Thread lock types which definitions are not included through <boost/thread/mutex.hpp> when BOOST_THREAD_DONT_PROVIDE_NESTED_LOCKS is defined (this macro is defined when BOOST_THREAD_VERSION is set to 4).[[BR]]
I suggest to include <boost/thread/lock_types.hpp> in every file that uses any lock type.[[BR]]
Since I build Boost only on Windows platforms attached patch may be incomplete.[[BR]]
Best regards, Maksim.",myasnikovmaksim@…
9453,building with --without-context doesn't actually work,Building Boost,Boost 1.55.0,To Be Determined,Bugs,Vladimir Prus,new,2013-12-02T07:00:35Z,2017-01-24T19:14:11Z,"apparently you also need to pass --without-coroutine, but the output from the build does not say that at all:

{{{
Component configuration:

    - atomic                   : building
    - chrono                   : building
    - context                  : not building
    - coroutine                : building
...
}}}

it probably should state something like ""building (for couroutine), but not installing headers"".  or abort.  or disable coroutine too.  something.",Mike Frysinger <vapier@…>
9452,split + is_any_of on char16_t splits on zero character,algorithm,Boost 1.54.0,To Be Determined,Bugs,Marshall Clow,new,2013-12-02T05:19:59Z,2013-12-02T05:19:59Z,"boost::algorithm::split + boost::algorithm::is_any_of on char16_t* splits given string on zero character, which differs from the char* version.

Pseudo-example:
- split(""a\0b"", ""X"") -> (""a\0b"")
- split(u""a\0b"", u""X"") -> (""a"", ""b"")

There's a workaround of wrapping u""X"" in a std::u16string, which works perfectly well.",cool.pepyaka@…
9450,fstream open utf8 filename fails x86_64-w64-mingw32,filesystem,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2013-12-02T01:57:34Z,2014-10-16T03:25:21Z,"boost::filesystem stream classes won't open files with non-ascii filenames provided as utf-8 strings.  This happens with and without imbuing a locale as specified in the boost doc page ""Default Encoding under Microsoft Windows"".  My example is basically the example on that page, but with an ifstream.

I compiled boost on Arch Linux using the AUR mingw-w64 packages.  I reproduced the issue on Windows 7 x64, Windows 7 x64 VM, and in x64 Wine.

I confirmed that the file exists and is named properly by making a parallel test program using _wopen (the file opened successfully).",spoo@…
9449,Boost.MPL min_element bug for equal elements (fix included),mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-12-01T22:24:50Z,2013-12-02T11:27:48Z,"For equal elements, Boost.MPL `min_element` with a predicate `Pred` does not satisfy its own requirements of returning the '''first''' element `i` that satifies `!Pred(j, i)` for all `j`. It turns out that `min_element` is implemented in terms of `max_element` with the negated predicate `not_<Pred>`. In turn, `max_element` with its own predicate `Pred` is required to (and in fact does) return the first element `i` that satisfies `!Pred(i, j)`. 

It is straightforward to see that negating the predicate is a bug. The current implementation of `min_element` has `less` as its default predicate, and subsequently calls `max_element` with `greater_equal`, whereas the requirements indicate that it should use `greater`. This results in `min_element` returning the '''last''' element of the sequence, rather than the first.

To get the required semantics, users currently have to supply `less_equal` to `min_element` as a workaround. The proper fix would be to implement `min_element` by calling `max_element` with the arguments for the predicate reversed: `lambda<Pred, _2, _1>`. 

See below for a short example that displays the problem and implements the fix. The program sets up a `vector` of three equal elements. Both `min_element` and `max_element` are specified to return an iterator to the first (index 0) element. Instead, `min_element` returns an iterator to the last (index 2) element. Both the redefined predicate work-around and the reimplementation of `min_element` fix the problem. The example can be run from http://coliru.stacked-crooked.com/a/c517d85cbc0aee66

{{{#!c++
#include <boost/mpl/begin_end.hpp>
#include <boost/mpl/distance.hpp>
#include <boost/mpl/lambda.hpp>
#include <boost/mpl/less_equal.hpp>
#include <boost/mpl/max_element.hpp>
#include <boost/mpl/min_element.hpp>
#include <boost/mpl/placeholders.hpp>
#include <boost/mpl/vector_c.hpp>
#include <iostream>

using namespace boost::mpl;

template<class Sequence, class Predicate = less<_1,_2>>
struct stable_min_element
: 
    // mpl::min_element uses max_element<Sequence, not_<Predicate>>
    max_element<Sequence, lambda<Predicate, _2, _1>>
{};

int main() 
{
    using V = vector_c<int, 1, 1, 1>;
    
    using MinIdx   = distance<begin<V>::type, min_element<V>::type>;
    using LEMinIdx = distance<begin<V>::type, min_element<V, less_equal<_1, _2> >::type>;
    using SMinIdx  = distance<begin<V>::type, stable_min_element<V>::type>;
    using MaxIdx   = distance<begin<V>::type, max_element<V>::type>;
    
    std::cout << MinIdx::value;     // ERROR: prints 2 instead of 0
    std::cout << LEMinIdx::value;   // 0
    std::cout << SMinIdx::value;    // 0
    std::cout << MaxIdx::value;     // 0
}
}}}",Rein Halbersma <rhalbersma@…>
9439,boost::spawn core dump,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-11-27T03:30:43Z,2014-10-28T12:16:06Z,"My program generate an core dump when I create 50000 coroutines.The number of coroutines is too big?

gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)

My program is:
#include <boost/bind.hpp>
#include <boost/asio/io_service.hpp>
#include <boost/asio/ip/tcp.hpp>
#include <boost/asio/spawn.hpp>
#include <boost/asio/steady_timer.hpp>
#include <boost/asio/write.hpp>
#include <iostream>
#include <memory>
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
                                                                                                                               
using boost::asio::ip::tcp;

void do_echo(boost::asio::yield_context yield,
    boost::asio::io_service *io_service) {
  for (; ;) {
    try {
      tcp::socket sock(*io_service);
      tcp::endpoint ep(boost::asio::ip::address::from_string(""127.0.0.1""), 19011);
      sock.async_connect(ep, yield);
      std::cout<< 1 <<std::endl ;
    }   
    catch (...) {
      std::cout<<""test"";
    }   
  }
}

int main(int argc, char* argv[]) {
  try {
    boost::asio::io_service io_service;
    for (int i=0; i<50000; ++i) {
      boost::asio::spawn(io_service, boost::bind(&do_echo, _1, &io_service));
    }   
    io_service.run();

  } catch(...) {
    std::cerr << ""Exception:\n"";
  }
  return 0;
}",ybb198602@…
9438,call of overloaded ‘ignore_unused_variable_warning(...)’ is ambiguous,concept_check,Boost Development Trunk,To Be Determined,Patches,jsiek,new,2013-11-27T01:01:25Z,2014-03-09T18:01:26Z,"Here are two patches that prevent some compilations errors due to ambiguous definitions of 'ignore_unused_variable_warning' (defined by both boost and lemon) under g++ 4.8.2 (works fine with clang 3.3 though).

It simply fully qualify the uses of the function by addind the boost:: namespace specifier before every 'call' in the concept checks.

Changing only the range concepts gave more errors in the concerpt_check library, so patchs for both libraries are provided.

You'll find as supplementary files the preprocessed source that fail to compile with and the error output.",Thomas Hume <thomas.hume@…>
9436,Add predefined concept for contextual conversion to bool,type_erasure,Boost 1.54.0,To Be Determined,Feature Requests,Steven Watanabe,new,2013-11-26T15:31:25Z,2013-11-26T15:31:25Z,"One concept that is often useful in many types is a contextual conversion to bool. The following expressions should be valid with the concept:

{{{
  if (o) {}
  if (!o) {}
  return bool(o);
}}}
 

Add a predefined concept that catches these requirement. A possible implementation:

{{{
namespace boost { namespace type_erasure {

template<class T>
struct testable
{
  static bool apply(const T& arg)
  { return bool(arg); }
};

template<class T, class Base>
struct concept_interface<testable<T>, Base, T> : Base
{
  explicit operator bool () const
  { return call(testable<T>(), *this); }
};
}}
}}}",akrzemi1@…
9433,boost unit_test_framework is using deprecated version 1 timers,timer,Boost 1.55.0,To Be Determined,Bugs,Beman Dawes,new,2013-11-26T09:11:16Z,2013-11-26T09:11:16Z,"boost::unit_test_framework is using internally the deprecated version 1 timers. As such we are not able to upgrade to the new cpu_timers.

boost/timer/timer.hpp:38:1: error: ‘namespace boost::timer { }’ redeclared as different kind of symbol",pat <pat@…>
9431,Problem compiling zip_iterator with clang and C++11,iterator,Boost 1.49.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-11-25T20:13:00Z,2013-11-27T20:27:15Z,"The following code fails to compile on OSX 10.8.5 with Xcode 5.0.1 and Boost 1.49.0.  This is not real world code, but it demonstrates the problem I'm facing.

{{{
#include <boost/iterator/zip_iterator.hpp>

template<typename T>
void foo()
{
    boost::zip_iterator<boost::tuple<T*> > iter;
    std::fill(iter, iter, boost::make_tuple(T()));
}

void bar()
{
    foo<int>();
}
}}}

Here are the commands I used to compile (if I drop ""-stdlib=libc++"" from the compile line, the code compiles just fine):

{{{
setenv DEVELOPER_DIR /Applications/Xcode5.0.1.app/Contents/Developer
xcrun -sdk macosx10.8 clang++ -c zip_iterator.cpp -I<boost-path>/include -std=c++11 -stdlib=libc++
}}}

and here is a heavily formatted snippet of the key error:

{{{
/Applications/Xcode5.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/algorithm:1824:1:
note: candidate function
    [with _RandomAccessIterator = boost::zip_iterator<boost::tuples::tuple<int *> >, _Tp = boost::tuples::tuple<int>]
not viable: no known conversion from
    'typename iterator_traits<zip_iterator<tuple<int *> > >::iterator_category'
    (aka 'boost::detail::iterator_category_with_traversal<std::__1::input_iterator_tag, boost::random_access_traversal_tag>')
to
    'std::__1::random_access_iterator_tag'
for 4th argument
    __fill(_RandomAccessIterator __first, _RandomAccessIterator __last, const _Tp& __value_, random_access_iterator_tag)
}}}

It appears as if the zip_iterator is not being converted to the correct iterator tag, which is why no calls to std::fill match.",jonathan.jones@…
9428,Lib program_options build fail for mingw,Building Boost,Boost 1.55.0,To Be Determined,Patches,,new,2013-11-24T08:28:49Z,2014-01-17T17:02:24Z,"Library program_options (boost 1.55, same applies to earlier boost versions) does not build for mingw (4.6.2). Don't know if MinGW is fully supported by boost, but some libraries do seem to have adaptation for it.
Solution seems straight-forward. File ...\libs\program_options\src\parsers.cpp:

#if !defined(_WIN32) || defined(__COMO_VERSION__)
extern char** environ;
#else
// SMAL patch for MinGW
#if defined(_WIN32) && defined(__MINGW32__)
extern char** environ;
#endif


(SMAL is a soon-to-be released open-source sw)",Jan Rosendahl <jan.rosendahl@…>
9427,svg_mapper bugs,geometry,Boost 1.54.0,To Be Determined,Bugs,Barend Gehrels,new,2013-11-23T10:15:53Z,2013-11-23T12:50:52Z,"{{{
#!div style=""font-size: 80%""
Code highlighting:
  {{{#!C++
#include <iostream>
#include <fstream>

#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>

void main()
{
	typedef boost::geometry::model::d2::point_xy<double> point_type;

	point_type a(10, 10);

	boost::geometry::model::polygon<point_type> b;
	boost::geometry::read_wkt(""POLYGON((0 0,0 7,4 2,2 0,0 0))"", b);

	std::ofstream svg(""my_map.svg"");
	boost::geometry::svg_mapper<point_type> mapper(svg, 100, 100);

	//mapper.add(a);
	mapper.add(b);

	//mapper.map(a, ""fill-opacity:0.5;fill:rgb(153,204,0);stroke:rgb(153,204,0);stroke-width:2"");
	mapper.map(b, ""fill-opacity:0.3;fill:rgb(51,51,153);stroke:rgb(51,51,153);stroke-width:2"");
}
  }}}
}}}


This code can produce 2 kinds of suspicious behavior:[[BR]]

1)If I output only single point(a), it's coordinates are invalid(svg output fragment: ''circle cx=""-2147483648"" cy=""-2147483648""'').[[BR]]
 
2)If I add polygon to the output(a and b), I get more relevant output, but still invalid(svg output fragment: ''circle cx=""1000"" cy=""0""'').



I use msvssp4 with debug-x64 configuration.",yuyoyuppe
9405,boost::spirit::karma::real_generator prints a number multiplied by 10,spirit,Boost 1.49.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-11-18T08:23:32Z,2015-05-09T00:34:46Z,"When using the attached example, the number 0.09999999999999987 is printed as 0.999999999999999, i.e. multiplied by 10.",Josef Zlomek <josef@…>
9399,Can't build 1.55.0 release with GCC 4.x and -std=c++0x,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-11-16T09:46:49Z,2013-11-20T19:47:45Z,"Hello,

I cannot build boost 1.55.0 with GCC 4.5.4, nor GCC 4.8.2, and -std=c++0x on NetBSD, Solaris, nor OS X. It always stops on ""error: no matching function for call to 'call_once(boost::once_flag&, void (&)())'"". For example:

{{{
gcc.compile.c++ bin.v2/libs/wave/build/gcc-4.5.4/release/threading-multi/instantiate_cpp_grammar.o
In file included from ./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:15:0,
                 from ./boost/spirit/home/classic/core/non_terminal/grammar.hpp:21,
                 from ./boost/spirit/home/classic/core.hpp:42,
                 from ./boost/spirit/include/classic_core.hpp:11,
                 from ./boost/wave/grammars/cpp_grammar.hpp:14,
                 from libs/wave/src/instantiate_cpp_grammar.cpp:24:
./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp: In member function 'IdT boost::spirit::classic::impl::object_with_id_base<TagT, IdT>::acquire_object_id() [with TagT = boost::spirit::classic::impl::grammar_tag, IdT = long unsigned int]':
./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp:78:62:   instantiated from 'boost::spirit::classic::impl::object_with_id<TagT, IdT>::object_with_id() [with TagT = boost::spirit::classic::impl::grammar_tag, IdT = long unsigned int]'
./boost/spirit/home/classic/core/non_terminal/grammar.hpp:51:15:   instantiated from 'boost::spirit::classic::grammar<DerivedT, ContextT>::grammar() [with DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>]'
./boost/wave/grammars/cpp_grammar.hpp:623:41:   instantiated from 'boost::wave::grammars::cpp_grammar<TokenT, ContainerT>::cpp_grammar(bool&, TokenT&, ContainerT&) [with TokenT = boost::wave::cpplexer::lex_token<>, ContainerT = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >]'
./boost/wave/grammars/cpp_grammar.hpp:738:91:   instantiated from 'static boost::spirit::classic::tree_parse_info<IteratorT> boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::parse_cpp_grammar(const LexIteratorT&, const LexIteratorT&, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::position_type&, bool&, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::token_type&, token_container_type&) [with LexIteratorT = boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, TokenContainerT = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::position_type = boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char> > > >, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::token_type = boost::wave::cpplexer::lex_token<>, token_container_type = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >]'
libs/wave/src/instantiate_cpp_grammar.cpp:48:40:   instantiated from here
./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp:140:17: error: no matching function for call to 'call_once(boost::once_flag&, void (&)())'
In file included from ./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp:18:0,
                 from ./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:15,
                 from ./boost/spirit/home/classic/core/non_terminal/grammar.hpp:21,
                 from ./boost/spirit/home/classic/core.hpp:42,
                 from ./boost/spirit/include/classic_core.hpp:11,
                 from ./boost/wave/grammars/cpp_grammar.hpp:14,
                 from libs/wave/src/instantiate_cpp_grammar.cpp:24:
./boost/thread/once.hpp: In function 'void boost::call_once(Function, boost::once_flag&) [with Function = void (*)()]':
./boost/spirit/home/classic/core/non_terminal/impl/static.hpp:72:13:   instantiated from 'boost::spirit::classic::static_<T, Tag>::static_(Tag) [with T = boost::thread_specific_ptr<boost::weak_ptr<boost::spirit::classic::impl::grammar_helper<boost::spirit::classic::grammar<boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, boost::spirit::classic::parser_context<> >, boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> > > > >, Tag = boost::spirit::classic::impl::get_definition_static_data_tag]'
./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:241:81:   instantiated from 'typename DerivedT::definition<ScannerT>& boost::spirit::classic::impl::get_definition(const boost::spirit::classic::grammar<DerivedT, ContextT>*) [with DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>, ScannerT = boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, typename DerivedT::definition<ScannerT> = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >::definition<boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> > >]'
./boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp:296:78:   instantiated from 'typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type boost::spirit::classic::impl::grammar_parser_parse(const boost::spirit::classic::grammar<DerivedT, ContextT>*, const ScannerT&) [with int N = 0, DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>, ScannerT = boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type = boost::spirit::classic::tree_match<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>]'
./boost/spirit/home/classic/core/non_terminal/grammar.hpp:57:54:   instantiated from 'typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type boost::spirit::classic::grammar<DerivedT, ContextT>::parse_main(const ScannerT&) const [with ScannerT = boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>, typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type = boost::spirit::classic::tree_match<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>]'
./boost/spirit/home/classic/core/non_terminal/grammar.hpp:65:9:   instantiated from 'typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type boost::spirit::classic::grammar<DerivedT, ContextT>::parse(const ScannerT&) const [with ScannerT = boost::spirit::classic::scanner<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::pt_match_policy<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>, boost::spirit::classic::action_policy> >, DerivedT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >, ContextT = boost::spirit::classic::parser_context<>, typename boost::spirit::classic::parser_result<boost::spirit::classic::grammar<DerivedT, ContextT>, ScannerT>::type = boost::spirit::classic::tree_match<boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, boost::spirit::classic::nil_t>]'
./boost/wave/grammars/cpp_grammar.hpp:706:69:   instantiated from 'boost::spirit::classic::tree_parse_info<IteratorT, NodeFactoryT> boost::wave::grammars::parsetree_parse(const IteratorT&, const IteratorT&, const boost::spirit::classic::parser<SkipT>&) [with NodeFactoryT = boost::spirit::classic::node_val_data_factory<boost::spirit::classic::nil_t>, IteratorT = boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, ParserT = boost::wave::grammars::cpp_grammar<boost::wave::cpplexer::lex_token<>, std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > > >]'
./boost/wave/grammars/cpp_grammar.hpp:740:58:   instantiated from 'static boost::spirit::classic::tree_parse_info<IteratorT> boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::parse_cpp_grammar(const LexIteratorT&, const LexIteratorT&, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::position_type&, bool&, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::token_type&, token_container_type&) [with LexIteratorT = boost::wave::cpplexer::lex_iterator<boost::wave::cpplexer::lex_token<> >, TokenContainerT = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::position_type = boost::wave::util::file_position<boost::wave::util::flex_string<char, std::char_traits<char>, std::allocator<char>, boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char> > > >, boost::wave::grammars::cpp_grammar_gen<LexIteratorT, TokenContainerT>::token_type = boost::wave::cpplexer::lex_token<>, token_container_type = std::list<boost::wave::cpplexer::lex_token<>, boost::fast_pool_allocator<boost::wave::cpplexer::lex_token<> > >]'
libs/wave/src/instantiate_cpp_grammar.cpp:48:40:   instantiated from here
./boost/thread/once.hpp:38:9: error: no matching function for call to 'call_once(boost::once_flag&, void (*&)())'
./boost/system/error_code.hpp: At global scope:
./boost/system/error_code.hpp:222:36: warning: 'boost::system::posix_category' defined but not used
./boost/system/error_code.hpp:223:36: warning: 'boost::system::errno_ecat' defined but not used
./boost/system/error_code.hpp:224:36: warning: 'boost::system::native_ecat' defined but not used

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -std=c++0x -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I""."" -c -o ""bin.v2/libs/wave/build/gcc-4.5.4/release/threading-multi/instantiate_cpp_grammar.o"" ""libs/wave/src/instantiate_cpp_grammar.cpp""
}}}

With Clang, the release builds fine. Using -std=c++98 and GCC it also builds fine.

Please, advise,

Adam
",adam@…
9398,get-invocation-command is not using user provided value in some cases,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-11-15T14:19:35Z,2013-11-15T14:37:50Z,"Notably, the problem appears when trying to specify a custom <archiver> or <ranlib> option to either gcc or clang toolchains (the latter deriving from the former.

The get-invocation-command rule executes a shell command then return the output, or the user provided value if the execution did not output anything.

However, it means that the user cannot overwrite the tools paths and has to manually patch the toolset file to hardcode the tool path, which is an issue.

The easy fix would be to check for an option before calling get-invocation-command (at least in gcc.jam, but it is possible that other toolsets are also affected). A maybe-not-so-easy-fix would be to change get-invocation-command behavior to return the user provided value if there is one, and to call the specified command if there is none (so the opposite of what is currently done).

tl;dr : '''tools/build/v2/user-config.jam'''

{{{
using clang
: 3.3
: /home/arcanis/emscripten/emcc
: <archiver>""/home/arcanis/emscripten/archiver""
  <ranlib>""/home/arcanis/emscripten/emranlib"" ;
}}}


Doesn't (cannot) work
",nison.mael@…
9396,circular_buffer + gil compiler error,circular_buffer,Boost 1.55.0,To Be Determined,Bugs,Jan Gaspar,new,2013-11-15T12:34:49Z,2013-11-15T12:34:49Z,"When 'boost/gil/bit_aligned_pixel_iterator.hpp' is included, the compiler selects for whatever reason an std::uninitialized_copy overload from the gil header instead of boost::cb_detail::uninitialized_copy within boost::cb_detail::uninitialized_move_if_noexcept_impl (boost/circualr_buffer/details.hpp) for types with !boost::is_nothrow_move_constructible.
A workaround (solution?) is to fully qualify the call to boost::cb_detail::uninitialized_copy, but why the std overload gets even selected? Is this a compiler bug? Or a gil problem?

Tested on: Windows 7 SP1 x64 + MSVC 2010 SP1

{{{
#include <boost/circular_buffer.hpp>
#include <boost/gil/bit_aligned_pixel_iterator.hpp>	// comment this to resolve

struct Foo
{
	Foo(const Foo&) {}
};

int main(int, char*[])
{

#if 1

	boost::circular_buffer<Foo> buffer;
	
	buffer.set_capacity(42);

#endif

#if 0	// minimum example

	typedef boost::cb_details::iterator<
		boost::circular_buffer<int>
		, boost::cb_details::nonconst_traits<
			std::allocator<int>
		>
	> InputIterator;
	
	boost::cb_details::uninitialized_move_if_noexcept_impl<int>(InputIterator(), InputIterator(), (int*)nullptr, boost::false_type());

#endif

	return 0;
}
}}}
",g.kuehnert <g.kuehnert@…>
9393,quantile for hypergeometric distribution - precision/rounding issue,math,Boost Development Trunk,To Be Determined,Feature Requests,John Maddock,new,2013-11-14T21:07:39Z,2014-03-11T17:06:35Z,"Hi (John),

This is the same as Ticket #9183 (https://svn.boost.org/trac/boost/ticket/9183) but applies to the hypergeometric distribution.  For example,

{{{
#define BOOST_MATH_DISCRETE_QUANTILE_POLICY integer_round_up

#include <cstdio>
#include <boost/math/distributions/hypergeometric.hpp>

int main()
{
   unsigned int xmin = 71;
   unsigned int length = 9;

   boost::math::hypergeometric_distribution<> dist( 79u, 101u, 109u );

   for ( unsigned int i = 0; i < length; ++i )
   {
      double x = xmin + i;
      double y =
         boost::math::cdf( dist, x );
         // boost::math::cdf( boost::math::complement( dist, x ) );

      std::printf(
            "" x = %g\tCDF(x) = %f\tinverse-CDF(CDF(x)) = %g\n"",
            x, y, boost::math::quantile( dist, y ) );
   }

   return 0;
}
}}}

returns

{{{
 x = 71	CDF(x) = 0.068671	inverse-CDF(CDF(x)) = 72
 x = 72	CDF(x) = 0.297575	inverse-CDF(CDF(x)) = 72
 x = 73	CDF(x) = 0.615846	inverse-CDF(CDF(x)) = 73
 x = 74	CDF(x) = 0.856699	inverse-CDF(CDF(x)) = 74
 x = 75	CDF(x) = 0.965083	inverse-CDF(CDF(x)) = 75
 x = 76	CDF(x) = 0.994746	inverse-CDF(CDF(x)) = 77
 x = 77	CDF(x) = 0.999561	inverse-CDF(CDF(x)) = 77
 x = 78	CDF(x) = 0.999985	inverse-CDF(CDF(x)) = 78
 x = 79	CDF(x) = 1.000000	inverse-CDF(CDF(x)) = 79
}}}

I was hoping/expecting to obtain:

{{{
       x          y  z
 [1,] 71 0.06867117 71
 [2,] 72 0.29757505 72
 [3,] 73 0.61584552 73
 [4,] 74 0.85669885 74
 [5,] 75 0.96508285 75
 [6,] 76 0.99474584 76
 [7,] 77 0.99956126 77
 [8,] 78 0.99998459 78
 [9,] 79 1.00000000 79
}}}
which I was used to on R.

Thank you!",anonymous
9391,Trac: New Ticket Captcha,trac / subversion,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2013-11-14T16:43:18Z,2013-11-14T17:06:39Z,"The Captcha is not working (FF 25.0 + Chromium 30).

Due to a false positive in the blacklist and to external links to references (removed them already), I can not submit a bug...",Axel Huebl <a.huebl@…>
9385,Call current_exception in concurrent manner for the same exception object,exception,Boost 1.53.0,To Be Determined,Bugs,Emil Dotchevski,new,2013-11-13T14:55:08Z,2013-11-13T14:55:08Z,"In attached file you can find minimal test that crashes when uses boost implementation of exception_ptr. It happens when call current_exception in concurrent manner for the same exception object.

Why does I expect that it should work? Because documentation does not say opposite (and it works in std implementation).

In boost till 1.42([http://www.boost.org/doc/libs/1_43_0/libs/exception/doc/exception_ptr.html]) was said:
  Therefore, in general it is not safe to call rethrow_exception concurrently to throw the same exception object into multiple threads.

And I have called it under mutex. But even in 1.42 was not said that call current_exception in concurrent manner (for the same exception object) not allowed.

The problem in class boost::exception_detail::exception

{{{#!c++
class boost::exception_detail::exception
{
...
  mutable exception_detail::refcount_ptr<exception_detail::error_info_container> data_;
}}}

when you call current_exception it's cloning current object of exception that create race condition.

The documentation not enough clear about thread safety restrictions for current_exception and rethrow_excepoption.

Here is back trace
{{{
#0  0x000000000225a110 in ?? ()
#1  0x0000000000410455 in boost::exception_detail::refcount_ptr<boost::exception_detail::error_info_container>::add_ref() ()
#2  0x000000000040dc0a in boost::exception_detail::refcount_ptr<boost::exception_detail::error_info_container>::refcount_ptr(boost::exception_detail::refcount_ptr<boost::exception_detail::error_info_container> const&) ()
#3  0x000000000040c1ba in boost::exception::exception(boost::exception const&) ()
#4  0x0000000000413033 in boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error>::current_exception_std_exception_wrapper(boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error> const&) ()
#5  0x00000000004130bd in boost::exception_detail::clone_impl<boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error> >::clone_impl(boost::exception_detail::clone_impl<boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error> > const&) ()
#6  0x0000000000420563 in boost::exception_detail::clone_impl<boost::exception_detail::current_exception_std_exception_wrapper<std::runtime_error> >::rethrow() const ()
#7  0x000000000040cca8 in boost::rethrow_exception(boost::exception_ptr const&) ()
#8  0x0000000000409825 in executer(boost::mutex&, boost::exception_ptr) ()
#9  0x0000000000421ff2 in void boost::_bi::list2<boost::reference_wrapper<boost::mutex>, boost::_bi::value<boost::exception_ptr> >::operator()<void (*)(boost::mutex&, boost::exception_ptr), boost::_bi::list0>(boost::_bi::type<void>, void (*&)(boost::mutex&, boost::exception_ptr), boost::_bi::list0&, int) ()
#10 0x00000000004211cd in boost::_bi::bind_t<void, void (*)(boost::mutex&, boost::exception_ptr), boost::_bi::list2<boost::reference_wrapper<boost::mutex>, boost::_bi::value<boost::exception_ptr> > >::operator()() ()
#11 0x0000000000420122 in boost::detail::thread_data<boost::_bi::bind_t<void, void (*)(boost::mutex&, boost::exception_ptr), boost::_bi::list2<boost::reference_wrapper<boost::mutex>, boost::_bi::value<boost::exception_ptr> > > >::run() ()
#12 0x00007fdff7194d29 in thread_proxy () from /home/roman-s/libraries/boost_1_53_0/stage/lib/libboost_thread.so.1.53.0
#13 0x00007fdff6f71f8e in start_thread (arg=0x7fdff5178700) at pthread_create.c:311
#14 0x00007fdff6782a0d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
}}}

In my project where we use boost::exception on more difficult case, problem happens all time in refcount_ptr that try delete already deleted object. In this synthetical test problems arrives in a little bit another manner. But it's exactly reproduce our logic. Of course we can avoid this problem, but problem is.

Thank you.",cupper.jj@…
9384,Ticket spam filter is to restrictive.,trac / subversion,Boost 1.55.0,To Be Determined,Bugs,Douglas Gregor,new,2013-11-13T11:41:29Z,2013-11-14T20:11:10Z,"I tried to sumbit #9383 from

139.1.148.6

but the system said it was spam (ip). So I switched to

79.246.230.3

---

The message was also strange since I was asked to do a captcha, but there was no captcha:


{{{
Captcha Error

Submission rejected as potential spam (Akismet says content is spam, StopForumSpam says this is spam (ip))

Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following.
}}}
",Dominik Muth <dominik.muth@…>
9383,augmented_crc example fails,crc,Boost 1.55.0,To Be Determined,Bugs,Daryle Walker,new,2013-11-13T11:35:36Z,2013-11-13T11:35:36Z,"I just built Boost 1.55.0 with VS 2008. Runs, but the example from

http://www.boost.org/doc/libs/1_55_0/libs/crc/crc.html#crc_func

fails.

Source:

{{{
// boost_ending.cpp : Defines the entry point for the console application.
//

#include ""stdafx.h""

#include <boost/crc.hpp>      // for boost::crc_basic, boost::augmented_crc
#include <boost/cstdint.hpp>  // for boost::uint16_t

#include <cassert>    // for assert
#include <iostream>   // for std::cout
#include <ostream>    // for std::endl

// Main function

int _tmain(int argc, _TCHAR* argv[]) {
    using boost::uint16_t;
    using boost::augmented_crc;

    uint16_t        data[6] = { 2, 4, 31, 67, 98, 0 };
    uint16_t const  init_rem = 0x123;

    uint16_t  crc1 = augmented_crc<16, 0x8005>( data, sizeof(data), init_rem );

    uint16_t const  zero = 0;
    uint16_t const  new_init_rem = augmented_crc<16, 0x8005>( &zero, sizeof(zero) );

    boost::crc_basic<16>  crc2( 0x8005, new_init_rem );
    crc2.process_block( data, &data[5] );  // don't include CRC

	std::cout << ""crc2: "" << crc2.checksum() << std::endl;
	std::cout << ""crc1: "" << crc1 << std::endl;

    assert( crc2.checksum() == crc1 );

    std::cout << ""All tests passed."" << std::endl;

	std::cin.ignore();
	return 0;
}
}}}


Output:

{{{
crc2: 22581
crc1: 36743
Assertion failed: crc2.checksum() == crc1, file boost_ending.cpp, line 33
}}}",Dominik Muth <dominik.muth@…>
9382,flat_stable associative containers.,container,Boost 1.55.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2013-11-13T10:35:34Z,2018-05-24T20:45:45Z,"I think it would be interesting to have flat associative containers based on the stable_vector implementation.

From my understanding of the flat_ containers and stable_vector we may have a good mix of access performance and insert performance.

Maybe it's not a real need thanks to C++11 optimization (move, RVO...), I'm still discovering the new standard.

Congratulation for the job done in the container lib, it's impressive to see what new implementations can bring.

Vincent",vincent.fericelli@…
9372,g++ 4.7 -Wshadow warnings need attention,mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-11-12T23:24:27Z,2013-11-14T02:50:43Z,"Following are warnings from g++ 4.7

boost/mpl/has_xxx.hpp:344:9: warning: ""BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION"" is not defined [-Wundef]

boost/mpl/has_xxx.hpp:357:9: warning: ""BOOST_MPL_HAS_XXX_NO_WRAPPED_TYPES"" is not defined [-Wundef]

boost/mpl/has_xxx.hpp:386:9: warning: ""BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION"" is not defined [-Wundef]

boost/mpl/has_xxx.hpp:459:8: warning: ""BOOST_MPL_HAS_XXX_NEEDS_TEMPLATE_SFINAE"" is not defined [-Wundef]
",Tom Browder <tom.browder@…>
9368,Generalize edge weight types usable in prim_minimum_spanning_tree,graph,Boost Development Trunk,To Be Determined,Patches,Jeremiah Willcock,new,2013-11-12T04:33:31Z,2013-11-12T04:42:54Z,"The current implementation of prim_minimum_spanning_tree makes the following assumptions about edge weight types:

+ weights have the less-than (<) operator defined

+ weight identity value is 0

+ the maximum weight value is accessible by std::numeric_limits<W>::max()

I've attached a patch that removes these requirements of edge weights by allowing users to use the distance_compare, distance_zero, and distance_inf named parameters. These parameters are passed to the dijsktra_shortest_paths() call that underlies the prim_minimum_spanning_tree function.
",lgtorres42@…
9367,Minor typo in Boost.Algorithm,algorithm,Boost Development Trunk,To Be Determined,Bugs,Marshall Clow,new,2013-11-12T03:55:57Z,2013-11-17T22:52:38Z,"Patch attached for fixing it.

Additional comments:

In `ordered-hpp.qbk`, the iterator requirements for `is_sorted` say
  The is_sorted functions will work on all kinds of iterators (except output iterators).
So I think it would be better to use `InputIterator` rather than `Iterator` for template parameters:
{{{
#!diff
Index: libs/algorithm/doc/ordered-hpp.qbk
===================================================================
--- libs/algorithm/doc/ordered-hpp.qbk	(revision 86541)
+++ libs/algorithm/doc/ordered-hpp.qbk	(working copy)
@@ -19,11 +19,11 @@
 
 ``
 namespace boost { namespace algorithm {
-	template <typename Iterator, typename Pred>
-	bool is_sorted ( Iterator first, Iterator last, Pred p );
+	template <typename InputIterator, typename Pred>
+	bool is_sorted ( InputIterator first, InputIterator last, Pred p );
 	
-	template <typename Iterator>
-	bool is_sorted ( Iterator first, Iterator last );
+	template <typename InputIterator>
+	bool is_sorted ( InputIterator first, InputIterator last );
 	
 	
 	template <typename Range, typename Pred>
}}}
Ditto for is_decreasing/increasing and is_strictly_decreasing/increasing. 

In `is_sorted.hpp`, the DOXYGEN comments for `is_sorted` use `ForwardIterator`. 
Is that a typo of `InputIterator`?
Ditto for is_decreasing/increasing and is_strictly_decreasing/increasing. 
",oss.2012.team+2013C@…
9364,linux epoll sizeof(epoll_event) == 12,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-11-11T05:40:08Z,2013-11-11T05:40:08Z,"add gcc flag -malign-double and sizeof(epoll_event) == 16 is not valid;

pls. Add BOOST_STATIC_ASSERT(sizeof(epoll_event) == 12);

ps. Sorry my bad english.",anonymous
9362,Non-const operator() don't compile,phoenix,Boost 1.55.0,To Be Determined,Bugs,Thomas Heller,new,2013-11-11T03:39:18Z,2013-11-11T03:39:18Z,"Using phoenix::bind with a user-defined function object with non-const operator() results in compile errors, even though the operator could be called. It seems that at some point Boost.Phoenix adds const qualifier to the bound function which results in compilation failure either when result_of is invoked (in C++11), or when the function object is called (in C++03).

I've attached a test case and compilation errors from GCC 4.8.1 in C++03 and C++11 modes.",Andrey Semashev
9361,boost::random::xor_combine max() has wrong,random,Boost Development Trunk,To Be Determined,Bugs,No-Maintainer,new,2013-11-10T12:52:13Z,2014-03-10T23:21:47Z,"In haeder <boost/random/xor_combine.hpp> line139:
{{{
static result_type max BOOST_PREVENT_MACRO_SUBSTITUTION () { return (std::max)((URNG1::min)(), (URNG2::max)()); }
}}}

URNG1::min has wrong, maybe correctly is URNG1::max.

correct as below:
{{{
static result_type max BOOST_PREVENT_MACRO_SUBSTITUTION () { return (std::max)((URNG1::max)(), (URNG2::max)()); }
}}}
",bolero.murakami@…
9353,Complete stream-based interface for WKT/WKB geometry I/O,geometry,Boost Development Trunk,To Be Determined,Tasks,Mateusz Loskot,new,2013-11-07T11:45:42Z,2013-11-07T11:45:42Z,"Some time ago, I discussed this idea on the list with [http://lists.boost.org/geometry/2013/07/2409.php Barend]:

> Yes, the WKT input might can be changed to streams.
> I will think about that. Internally it uses Boost.Tokenizer.
> It takes a string as input

and [http://lists.boost.org/geometry/2013/07/2408.php Bruno]:

> yes we should probably think about having this stream-based as well

So, let's not forget about it at some point.",Mateusz Loskot
9350,boost does not use prefix for rpath,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-11-06T21:24:09Z,2013-11-06T21:24:09Z,"How to reproduce:

{{{
MY_PREFIX=/my/boost/target

./bootstrap.sh --prefix=$MY_PREFIX

./b2 -j 14 -d+2 address-model=64 install

ldd $MY_PREFIX/lib/libboost_filesystem.so | grep boost
   libboost_system.so.1.54.0 => NOT FOUND 
}}}

I've observed this issue with Boost 1.52 (using the sun toolset - sun.jam) and with Boost 1.54 (using the gcc toolset - gcc.jam).

It seems that boost sets the rpath to the build directory and not to the specified prefix (during link time).

Expected results:

ldd $MY_PREFIX/lib/libboost_filesystem.so | grep boost
   libboost_system.so.1.54.0 => $MY_PREFIX/lib/libboost_system.so.1.54.0

(note that I've picked libboost_filesystem as an example - other boost libraries have the same issue, e.g. chrono/log/time/...)

Currently I use a dirty workaround to have the rpath set correctly:
{{{
--- a/tools/build/v2/tools/gcc.jam
+++ b/tools/build/v2/tools/gcc.jam
@@ -945,7 +945,7 @@ rule link ( targets * : sources * : properties * )
 
 actions link bind LIBRARIES
 {
-    ""$(CONFIG_COMMAND)"" -L""$(LINKPATH)"" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(RPATH) -Wl,-rpath-link$(SPACE)-Wl,""$(RPATH_LINK)"" -o ""$(<)"" $(START-GROUP) ""$(>)"" ""$(LIBRARIES)"" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS)
+    ""$(CONFIG_COMMAND)"" -L""$(LINKPATH)"" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(MY_PREFIX)/lib -Wl,-rpath-link$(SPACE)-Wl,""$(RPATH_LINK)"" -o ""$(<)"" $(START-GROUP) ""$(>)"" ""$(LIBRARIES)"" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS)
 }


@@ -1011,7 +1011,7 @@ rule link.dll ( targets * : sources * : properties * )
 # Differs from 'link' above only by -shared.
 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)
+    ""$(CONFIG_COMMAND)"" -L""$(LINKPATH)"" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(MY_PREFIX)/lib ""$(.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)
 }

 rule setup-threading ( targets * : sources * : properties * )
}}}

The workaround for {{{tools/build/v2/tools/sun.jam}}} is similar.

",Georg Sauthoff <mail@…>
9349,Could not build development trunk with Visual Studio 2013 without patch for named_slot_map,Building Boost,Boost Development Trunk,To Be Determined,Bugs,,new,2013-11-06T20:33:52Z,2013-11-06T20:33:52Z,"Trying to build the latest svn version of boost with Visual Studio 2013.  

I needed to bump the _MSC_VER, <= 1800 version numbers in the workarounds in libs/signals/src/named_slot_map.cpp and boost/signals/detail/named_slot_map.hpp.

After that it built... although with quite a few warnings.",sbauer230@…
9348,b2 cannot find Jamroot when run at the root of a mounted partition.,Building Boost,Boost 1.56.0,To Be Determined,Bugs,,new,2013-11-06T16:10:31Z,2014-08-28T15:30:04Z,"When boost is extracted to the root of a partion (in this case, one mounted as a folder in windows) B2 fails to build boost when attempting to stage with the following error:
''notice: could not find main target stage 
notice: assuming it is a name of file to create. 
error: Project target requested but not yet assigned for module'

See the following mailing list thread for details [http://lists.boost.org/boost-build/2013/11/27147.php]
",darthpjb@…
9345,Add support for M component to WKT and WKB I/O,geometry,Boost Development Trunk,To Be Determined,Tasks,Mateusz Loskot,new,2013-11-05T18:19:55Z,2013-11-05T18:19:55Z,"This task is related to [http://lists.boost.org/geometry/2013/11/2669.php Changes in WKB (read) behaviour proposal (WKT Part)] discussion on the list.

We should try to add ability to consume/produce the M (measure) component from/to geometries encoded in OGC WKT and WKB formats.

As Barend explained in the thread linked above:

> We drop the M anyway (currently).
> We cannot handle it because our Point Concept does not contain model-values. 
> Something additional would be necessary to be able to assign
> it to the point in question (strategy? policy? assigner?),
> which can do with it what it wants.
> An easy option would be assigning the M to the third dimension
> (if any), and that is probably currently the case
> (I have to check).

I think a form of user-defined data assigner, similar to dimension assigners, which uses can enable for adapted geometries would be useful.",Mateusz Loskot
9344,Document and test non-OGC behaviour of WKT and WKB support,geometry,Boost Development Trunk,To Be Determined,Tasks,Mateusz Loskot,new,2013-11-05T18:15:13Z,2013-11-05T18:15:13Z,"This task is related to [http://lists.boost.org/geometry/2013/11/2669.php Changes in WKB (read) behaviour proposal (WKT Part)] discussion on the list.

Boost.Geometry uses data in WKT format input for unit tests. 
In many cases, non-standard forms of WKT (according to OGC specification) are used what in fact constitutes some form of Boost.Geometry Extended WKT.

The documentation should be clear about OGC standard behaviour and non-standard extensions of WKT and WKB layer as well.

Also, it looks not all forms of geometry input is currently covered with tests. From the thread linked above:

>> The BNF include in the OGC SFS spec is clear the ""third value"" for M 
>> is required: 
>> 
>> <point z> ::= <x> <y> <z> 
>> <point m> ::= <x> <y> <m> 
>> <point zm> ::= <x> <y> <z> <m> 
>
> There are not unit tests for them all, we should check and
> extend the tests. ",Mateusz Loskot
9339,Switch WKB parser to use Boost.Endian,geometry,Boost Development Trunk,To Be Determined,Tasks,Mateusz Loskot,new,2013-11-04T10:02:18Z,2013-11-04T10:02:18Z,"Currently, WKB I/O extension hosts private copy of original code written by Beman Dawes to support endianness [https://svn.boost.org/svn/boost/trunk/boost/geometry/extensions/gis/io/wkb/detail/endian.hpp boost/geometry/extensions/gis/io/wkb/detail/endian.hpp]

Beman [http://lists.boost.org/Archives/boost/2013/11/208236.php has announced] this code has been completed and will be released as Boost.Endian. Once this happens, the Boost.Geometry's extension shall switch to use it, instead of maintaining private copy of the same code.",Mateusz Loskot
9331,Boost Log fails to compile on FreeBSD 10.0,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-11-02T04:07:46Z,2013-11-02T04:07:46Z,"During a release compile of boost with clang 3.3 on FreeBSD 10.0, the log library failed to build:

./boost/math/tools/promotion.hpp:141:10: error: implicit instantiation of undefined template 'boost::STATIC_ASSERTION_FAILURE<false>'

K-ballo on IRC suggested that I comment out line 29 of boost/math/tools/config.hpp:

#  define BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS

This resolved the problem. I am submitting this ticket just in case anyone else runs in to this problem.",anonymous
9330,Add initializer_list constructor to ptr_container,ptr_container,Boost 1.54.0,To Be Determined,Feature Requests,Thorsten Ottosen,new,2013-10-31T10:56:53Z,2013-10-31T10:56:53Z,Pointer container library does not take advantadge of new C++11 features such as std::initializer_list constructor and move constructor.,anonymous
9329,Compilation fixes for Sun CC and its ancient standard library,program_options,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-10-30T23:23:15Z,2013-10-30T23:23:15Z,"This patch avoids the following errors when compiling the library using Sun CC (Sun C++ 5.10 SunOS_i386 2009/06/03):
{{{
""libs/program_options/src/options_description.cpp"", line 422: Error, nomatchoverin: Could not find a match for std::count<std::_InputIterator, std::_T, std::_Size>(char*, char*, char) needed in::format_paragraph(std::ostream &, std::string, unsigned, unsigned).
""libs/program_options/src/options_description.cpp"", line 
""libs/program_options/src/options_description.cpp"", line 483: Error, toofewtargs: Too few arguments for template std::reverse_iterator.
""/opt/sunstudio12.1/prod/include/CC/Cstd/rw/iterator"", line 426: Error, nofunctmpl: ""friend"" declaration is incompatible with function template.
""libs/program_options/src/options_description.cpp"", line 483:     Where, temwhilespec: While specializing ""std::reverse_iterator<const char*>"".
""libs/program_options/src/options_description.cpp"", line 483:     Where, temspecend: Specialized in non-template code.
""libs/program_options/src/options_description.cpp"", line 484: Error, toofewtargs: Too few arguments for template std::reverse_iterator.
472: Error, nomatchoverin: Could not find a match for std::distance<std::_ForwardIterator, std::_Distance>(const char*, const char*const) needed in::format_paragraph(std::ostream &, std::string, unsigned, unsigned).
""libs/program_options/src/value_semantic.cpp"", line 371: Error, nomatchoverin: Could not find a match for std::vector<std::string>::vector(__rwstd::__rb_tree<std::string, std::string, __rwstd::__ident<std::string, std::string>, std::less<std::string>, std::allocator<std::string>>::const_iterator, __rwstd::__rb_tree<std::string, std::string, __rwstd::__ident<std::string, std::string>, std::less<std::string>, std::allocator<std::string>>::const_iterator) needed in boost::program_options::ambiguous_option::substitute_placeholders(const std::string &) const.
}}}

I don't really understand neither of them, unfortunately: looking at the standard library headers both the calls to `count()` and `distance()` should compile. OTOH neither of them is really necessary so I hope this patch can be applied nevertheless. With `reverse_iterator` it's more mysterious but, again, IMHO its use in the original code is not really needed, so I've just replaced it with `rfind()`.

The last error is clear: this compiler standard library doesn't provide template ctor of `std::vector` from an iterator pair, so an alternative method of constructing it must be used. This does make the code less concise and elegant, but unfortunately I don't see any other way to make it work in this case.

TIA!",vz-boost@…
9326,io_service.get_unfinished_work_count(),asio,Boost Development Trunk,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-10-30T18:52:47Z,2013-10-30T18:52:47Z,"Would be good to have this function to return how many work the io_service still have left to do. By diving in the sources, I found out that this function would be simples as:

{{{
long get_unfinished_work_count() { return outstanding_work_; }
}}}

This function is useful to know if asio still have unfinished work to do. Meantime the only way to know if there is still work left to do, is by calling run_one()/run() and see if it returns immediately or not, that approach is not ideal. There are cases that you don't want to block the thread.",edubart <edub4rt@…>
9324,boost\include\boost-1_53\boost\asio\detail\impl\signal_set_service.ipp Off by One Error,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-10-30T16:57:24Z,2013-10-30T21:46:36Z,"In the function

{{{
boost::system::error_code signal_set_service::add(
    signal_set_service::implementation_type& impl,
    int signal_number, boost::system::error_code& ec)

}}}

The guard statement
{{{
// Check that the signal number is valid.
  if (signal_number < 0 || signal_number > max_signal_number)
  {
    ec = boost::asio::error::invalid_argument;
    return ec;
  }
}}}

has an Off-by-One error. 

The guard statement should read
{{{
// Check that the signal number is valid.
  if (signal_number < 0 || signal_number >= max_signal_number)
  {
    ec = boost::asio::error::invalid_argument;
    return ec;
  }
}}}

",Oscar Deits <odeits@…>
9322,spinlock_gcc_arm.hpp fails when building iOS arm64,smart_ptr,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-10-30T14:01:57Z,2014-03-01T00:17:20Z,"I am using boost in my iOS and Android applications and building for arm64 in iOS fails in spinlock_gcc_arm because the the SWP instruction and LDREX are not part of the arm64 instruction set. I do not have enough knowledge about the ARM assembly instructions to implement a proper fix for this myself and was hopeful someone with more expertise could provide a fix for the next release (or a patch for the current, if possible).",Joe Radjavitch <joerad11@…>
9321,named mutex permissions are not reset after application crash,interprocess,Boost 1.50.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-10-30T12:08:25Z,2013-10-30T20:50:12Z,"'''Using boost named_mutex on Windows with the standard permissions object.''' 

An application creates a named mutex and removes it on exit. This works fine even if the application is started by different users one after the other.

Now assume the application crashes and does not call remove, anymore. When a different user starts the same application later on, the named mutex cannot be created and throws an interprocess exception ""access denied"".

This is due to the fact that the mutex file in the folder {{{c:\ProgramData\boost_interprocess}}} still exists, and it has the permissions of the user that started the application first.

'''How to reproduce'''

The following simple application simulates a crash by exiting before removing the mutex.

Run the application as user x. The mutex is successfully constructed, the application crashes unexpectedly.

Then run the application as user y. The mutex cannot be constructed as file {{{c:\ProgramData\boost_interprocess\my_mutex_name}}} is still present and cannot be opened by user y although user x who owns the file does not use it by any process.

{{{
#include ""boost/interprocess/sync/named_mutex.hpp""

int main(const int argc, const char* const * const argv)
{
    try
    {
        boost::interprocess::named_mutex mutex(boost::interprocess::open_or_create, ""my_mutex_name"");

        printf(""mutex construction successful\n"");
    }
    catch (const boost::interprocess::interprocess_exception& ex)
    {
        printf(""mutex construction failed: %s\n"", ex.what());
    }

    exit(0);

    boost::interprocess::named_mutex::remove(""my_mutex_name"");

    return 0;
}
}}}
",Marcus Ackermann <Marcus.Ackermann@…>
9318,Improve performance of boost string algorithms when converting case,string_algo,Boost 1.53.0,To Be Determined,Feature Requests,Marshall Clow,new,2013-10-29T18:35:11Z,2013-10-29T18:35:11Z,"We recently switched STL library to libstdc++ and hit a performance snag on code that use boost string algorithms for converting case or comparing case insensitive.

I noticed that the algorithms use the standard C++ convenience functions for character classification for each and every character being converted or compared.  This is very inefficient as these standard C++ functions in turn call std::use_facet every time they are called.    At least in libstdc++, std::use_facet is very expensive as it involves quite a bit of code including a dynamic_cast.

To quote Josuttis' The C++ Standard Library: ""It is much faster to obtain the corresponding facet from the locale and to use the functions on this object directly"".

Indeed if I wrap boost::to_upper/lower (an other) with functions that cache and reuse the facet within the same call to to_upper/lower, I see a significant run time improvement.  In fact my application can cache the facet for the entire duration of the program running, something the string algorithms cannot do since they must support on the fly locale changes, but I wonder if this latter case should be supported also?

Thanks for a great library.

Soren Soe",boost@…
9315,boost shared_ptr should detect __sync support in clang,smart_ptr,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-10-28T23:11:32Z,2014-02-28T20:16:59Z,clang (at least as of 3.4) has support for GCC __sync functions.  shared_ptr should properly detect that clang has such support (at least on ARM such support is not detected properly).,vlovich@…
9314,boost shared_ptr should use C++11 atomics when available,smart_ptr,Boost 1.54.0,To Be Determined,Feature Requests,Peter Dimov,new,2013-10-28T23:09:49Z,2013-12-13T21:11:51Z,"If a native assembly lock-free version is unavailable, boost should use native C++11 atomics if the library has them.  This will far more reliably pick an efficient implementation for shared_ptr in cases where the optimized assembly version is unavailable and where __sync support may be unavailable/not detected properly.",anonymous
9313,Preserve doxygen syntax highlighting in doxygen2boostbook.,Documentation,Boost 1.54.0,To Be Determined,Bugs,Daniel James,new,2013-10-28T22:38:24Z,2013-10-28T22:38:24Z,"Instead of using the 'language=""c++""' attribute.",Daniel James
9307,future::fallback_to assert with ERRORRRRR boost: mutex lock failed in pthread_mutex_lock: Invalid argument,thread,Boost Development Trunk,Boost 1.57.0,Bugs,viboes,reopened,2013-10-26T11:15:00Z,2018-04-13T07:12:20Z,"rev 86424 

{{{

Test output: marshall-mac - thread - ex_future_fallback_to_lib / clang-darwin-asan
Rev 86424 / Fri, 25 Oct 2013 05:14:04 +0000
Compile [2013-10-25 12:22:41 UTC]: succeed


""/Volumes/TwoTB/LLVM/build/llvm-cmake-nodebug/bin/clang++"" -x c++ -fsanitize=address -O0 -g -Wextra -Wno-long-long -Wunused-function -pedantic -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_LIB=1 -I"".."" -c -o ""/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/test/ex_future_fallback_to_lib.test/clang-darwin-asan/debug/threading-multi/future_fallback_to.o"" ""../libs/thread/test/../example/future_fallback_to.cpp""

            

Link [2013-10-25 12:22:41 UTC]: succeed


""/Volumes/TwoTB/LLVM/build/llvm-cmake-nodebug/bin/clang++""   -o ""/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/test/ex_future_fallback_to_lib.test/clang-darwin-asan/debug/threading-multi/ex_future_fallback_to_lib"" ""/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/test/ex_future_fallback_to_lib.test/clang-darwin-asan/debug/threading-multi/future_fallback_to.o"" ""/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/test/ex_future_fallback_to_lib.test/clang-darwin-asan/debug/threading-multi/tss_null.o"" ""/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/chrono/build/clang-darwin-asan/debug/link-static/threading-multi/libboost_chrono.a"" ""/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/thread/build/clang-darwin-asan/debug/link-static/threading-multi/libboost_thread.a"" ""/Volumes/TwoTB/boost/regression/trunk/results/boost/bin.v2/libs/system/build/clang-darwin-asan/debug/link-static/threading-multi/libboost_system.a""    -g -fsanitize=address

            

Run [2013-10-25 12:22:41 UTC]: fail


0x7fff78e0a180 - ../libs/thread/test/../example/future_fallback_to.cpp[32] <MAIN
0x10beab000 - ../libs/thread/test/../example/future_fallback_to.cpp[26] P1
0x10beac000 - ../libs/thread/test/../example/future_fallback_to.cpp[20] P1
0x7fff78e0a180 - ../libs/thread/test/../example/future_fallback_to.cpp[60] ERRORRRRR boost: mutex lock failed in pthread_mutex_lock: Invalid argument

EXIT STATUS: 1
            


}}}
",viboes
9306,Linking failure - Building BOOST with gcc-4.8 on Mac OSX,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-10-26T07:13:26Z,2013-11-11T11:20:25Z,"Hi,

I am trying to compile boost on mac using gcc-4.8 and getting link errors. I have few reasons for this to be built with gcc and not clang which will deviate the actual issue.
I have built boost with these steps:
1. Edited user-config.jam in /tools/build/v2 and added the following
using gcc : 3.2 : /usr/local/bin/g++-3.2 ;
2. ./bootstrap --prefix=/custom/path
3. ./b2 -d 2 toolset=gcc-4.8

Errors are as below:

{{{
ld: unknown option: -h
collect2: error: ld returned 1 exit status
...failed gcc.link.dll bin.v2/libs/serialization/build/gcc-4.8/release/threading-multi/libboost_serialization.dylib...
...skipped <pstage/lib>libboost_wserialization.dylib for lack of <pbin.v2/libs/serialization/build/gcc-4.8/release/threading-multi>libboost_serialization.dylib...
gcc.link.dll stage/lib/libboost_signals.dylib

    ""/usr/local/bin/g++-4.8""  -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config""  -o ""stage/lib/libboost_signals.dylib"" -Wl,-h -Wl,libboost_signals.dylib -shared  ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/trackable.o"" ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/connection.o"" ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/named_slot_map.o"" ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/signal_base.o"" ""bin.v2/libs/signals/build/gcc-4.8/release/threading-multi/slot.o""        

ld: unknown option: -R
collect2: error: ld returned 1 exit status
...failed gcc.link.dll stage/lib/libboost_signals.dylib...
gcc.link.dll stage/lib/libboost_prg_exec_monitor.dylib

    ""/usr/local/bin/g++-4.8""  -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config""  -o ""stage/lib/libboost_prg_exec_monitor.dylib"" -Wl,-h -Wl,libboost_prg_exec_monitor.dylib -shared  ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/execution_monitor.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/debug.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/cpp_main.o""        

ld: unknown option: -R
collect2: error: ld returned 1 exit status
...failed gcc.link.dll stage/lib/libboost_prg_exec_monitor.dylib...
gcc.link.dll stage/lib/libboost_unit_test_framework.dylib

    ""/usr/local/bin/g++-4.8""  -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib"" -Wl,-R -Wl,""/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config""  -o ""stage/lib/libboost_unit_test_framework.dylib"" -Wl,-h -Wl,libboost_unit_test_framework.dylib -shared  ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/execution_monitor.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/debug.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/compiler_log_formatter.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/exception_safety.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/framework.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/interaction_based.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/logged_expectations.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/plain_report_formatter.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/progress_monitor.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/results_collector.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/results_reporter.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/test_tools.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_log.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_main.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_monitor.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_parameters.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/unit_test_suite.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/xml_log_formatter.o"" ""bin.v2/libs/test/build/gcc-4.8/release/threading-multi/xml_report_formatter.o""        

ld: unknown option: -R
collect2: error: ld returned 1 exit status
...failed gcc.link.dll stage/lib/libboost_unit_test_framework.dylib...
...skipped <pstage/lib>libboost_timer.dylib for lack of <pbin.v2/libs/chrono/build/gcc-4.8/release/threading-multi>libboost_chrono.dylib...
...skipped <pstage/lib>libboost_wave.dylib for lack of <pbin.v2/libs/thread/build/gcc-4.8/release/threading-multi>libboost_thread.dylib...
...failed updating 23 targets...
...skipped 14 targets...

}}}

",karunreddy30@…
9299,Feature Requests: circular_buffer::emplace(...),circular_buffer,Boost Development Trunk,To Be Determined,Feature Requests,No-Maintainer,new,2013-10-24T21:13:43Z,2017-11-28T21:03:11Z,"I think a great addition to circular_buffer would be to support emplace(...)/emplace_back()/emplace_front() to make it more C++11 compliant.

At the first quick glance I took at the source, implementation seems straight-forward, more or less c&p the code from insert/push_back/push_front and construct the items in-place instead. The tricky part however would be to stay compliant with older C++ versions, if that is a desired feature (and it seems to be considering that e.g. Boost.Move can be used instead of the C++11 move semantics). I do not have an idea how to do this as I'm not an experienced boost developer (or actually even user for that matter).

If older C++-compliance is not needed and my assumption of simply ""c&ping insert/push_back/push_front"" is confirmed by a boost developer, I could probably provide a patch a few weeks from now (my time is a bit limited at the moment) if required. If the compliance is needed however, I would prefer that a more experienced developer would implement it.",anonymous
9297,"""boost::iostreams::file_descriptor_sink"" doesn't support translation of line endings on Windows",iostreams,Boost 1.54.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-10-24T09:33:20Z,2013-10-24T09:33:20Z,"When a Windows file descriptor is opened in text mode, all newline characters written to this file are translated to CRLF. However, if ''boost::iostreams::file_descriptor_sink'' is used on such a file descriptor to write newlines to a stream, these newline characters are not translated to CRLF.

The following sample program demonstrates this:
{{{#!c++
#include <boost/iostreams/device/file_descriptor.hpp>
#include <boost/iostreams/stream.hpp>
#include <fcntl.h>
#include <io.h>
#include <string>
#include <sys/stat.h>


int main()
{
    static const std::string str1 = ""This is a line"";
    static const std::string str2 = ""This is another line"";

    int fd = _open(""output.txt"", _O_WRONLY | _O_CREAT | _O_TRUNC | _O_TEXT,
            _S_IREAD | _S_IWRITE);
    _write(fd, str1.data(), str1.size());
    _write(fd, ""\n"", 1);    // This writes ""\r\n""

    boost::iostreams::file_descriptor_sink sink(fd, boost::iostreams::close_handle);
    boost::iostreams::stream<boost::iostreams::file_descriptor_sink> stream(sink);
    stream << str2;
    stream << std::endl;    // This only writes ""\n""

    return 0;
}
}}}",m.kosch@…
9296,synchronous non-blocking support for boost::asio::ip::tcp::socket::connect(),asio,Boost 1.54.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-10-23T19:37:12Z,2013-10-23T19:37:12Z,"Currently the implementation of boost::asio::detail::socket_ops::sync_connect() makes connect operations on a TCP socket which is in non-blocking mode (i.e. via set_user_non_blocking()) behave like a blocking connect(), by calling poll_connect() to wait for the completion of a non-blocking connect.

I have scenarios where I need the connect operation to be non-blocking, but I do not want to use async_connect() because I need to be able to handle the completion of the connect operation synchronously but at a later time. A typical scenario is adapting code which already manages large numbers of non-blocking file descriptors/sockets via epoll(), whereby I want to initiate the connect operation on a boost::asio::ip::tcp:socket object but then pass its native_handle() to epoll to later reap the connect completion.

As for better or worse the current implementation of socket::connect() with a socket in non-blocking mode is expected to have completed the connect attempt upon return (i.e. boost::asio::errors::would_block or in_progress are not expected), a new basic_socket::non_blocking_connect() - or some such - with support down through the various layers would probably be called for.

At the moment, I am achieving what I need by side-stepping socket::connect like this:

{{{
   boost::asio::ip::tcp::socket socket(ios);
   boost::asio::ip::tcp::endpoint addr(...);
   boost::system::error_code ec;
   socket.open(addr.protocol, ec);
   // set various sockopts...
   socket.non_blocking(true, ec);

   // in lieu of a hypothetical socket.non_blocking_connect(addr, ec):
   ::connect(socket.native_handle(), addr.data(), socklen_t(addr.size()));
   ec = make_error_code(boost::asio::error::basic_errors(errno));
}}}
",Stephen C. Pope <stephen.pope@…>
9295,PHOENIX_LIMIT macro clash: property_tree -- log/sink,phoenix,Boost 1.54.0,To Be Determined,Bugs,Thomas Heller,new,2013-10-23T15:11:28Z,2014-02-03T20:56:49Z,"Components:

* spirit
* phoenix
* log
* property_tree

The following does not compile using gcc 4.8.1 or 4.7.2 (linux) using default warning options: 

{{{
#include ""boost/property_tree/json_parser.hpp""
#include ""boost/log/sinks.hpp""
}}}

The reason is that there are two (different?) definitions picked up, from deep within the include graphs:

{{{
boost/phoenix/core/limits.hpp:26
   #define PHOENIX_LIMIT BOOST_PHOENIX_LIMIT

boost/spirit/home/classic/attribute.hpp:30
   #define PHOENIX_LIMIT 6
}}}

(Note to others: A workaround for cases where the two are not truly used together is to use a pimpl.)",Johan Lundberg <lundberj@…>
9292,event_log example crashes.,log,Boost 1.54.0,To Be Determined,Bugs,Andrey Semashev,new,2013-10-23T00:22:58Z,2013-10-23T00:22:58Z,"In supplied event_log_messages.mc:

SeverityNames=(Debug=0x0:MY_SEVERITY_DEBUG
            Info=0x1:MY_SEVERITY_INFO
            Warning=0x2:MY_SEVERITY_WARNING
            Error=0x3:MY_SEVERITY_ERROR
            )

Which translates into:

//
// Define the severity codes
//
#define MY_SEVERITY_WARNING              0x2
#define MY_SEVERITY_INFO                 0x0
#define MY_SEVERITY_ERROR                0x3

in the generated event_log_messages.h

When trying to execute the code:

    type_mapping[error] = sinks::event_log::make_event_type(MY_SEVERITY_ERROR);

in supplied main.cpp

the call to make_event_type throws out_of_range, because only levels 0, 1, 2, and 4 are allowed.

",mike.ferrel@…
9290,"boost statechart documentation does not mention, that the state machine should be terminated with terminate()",statechart,Boost 1.54.0,To Be Determined,Bugs,Andreas Huber,new,2013-10-22T13:04:06Z,2013-10-26T15:20:42Z,"Just hit by the issue described in an old thread:

http://lists.boost.org/boost-users/2007/07/29695.php

In short: for assert-free state machine destruction, terminate() method must be called prior actual destruction of the state machine. This aspect is not mentioned in the tutorial, moreover the method is never called in any tutorial example.",Viatcheslav.Sysoltsev@…
9287,Additional string_ref constructors,utility,Boost 1.54.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2013-10-22T09:09:19Z,2015-05-12T00:57:48Z,"From:
- iterator_range<Char const *>
- std::vector<Char>
- pair of iterators",Domagoj Šarić
9284,WaitForSingleObject(mutex) must handle WAIT_ABANDONED,interprocess,Boost 1.58.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2013-10-22T05:47:55Z,2018-03-08T15:13:50Z,"boost-1_54\boost\interprocess\sync\windows\winapi_mutex_wrapper.hpp
line 53

   void lock()
   {
      if(winapi::wait_for_single_object(m_mtx_hnd, winapi::infinite_time) != winapi::wait_object_0){
         error_info err = system_error_code();
         throw interprocess_exception(err);
      }
   }

The wait_for_single_object maybe return wait_abandon which means the mutex holder thread exited and did not release the mutex. Normally, this should never happen, but if the mutext holder process crash, this will happen.

So the code should change to:
unsigned long ret = winapi::wait_for(...);
if(ret != winapi::wait_object_0 && ret != winapi::wait_abondon) {
  error_info err = system_error_code();
  throw interprocess_exception(err);
}
",huyuguang@…
9281,Give string_path an accessor for the value,property_tree,Boost Development Trunk,To Be Determined,Patches,Sebastian Redl,new,2013-10-21T20:33:17Z,2013-10-21T20:33:17Z,"Is there a reason not to provide an accessor for string_path::m_value?

If not, here is the patch proposal.
",jean
9278,Compiling error in MPL under VC12/VS2013,mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-10-21T04:36:52Z,2013-10-21T21:04:34Z,"Ticket #8750 indicated some compiling problems when using VC12. In 1.55.0 beta 1, most of the problems are gone. But the one in boost/mpl/assert.hpp still exist. The == in line 37 and 247 should be changed to >=.",gongminmin@…
9277,Serial Hardware Handshaking in Windows XP SP3 Broken?,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-10-20T21:08:09Z,2013-10-20T21:08:09Z,"9600 8N1 Transmit only, both DSR and CTS asserted by device (printer).  Behavior is apparently no different than handshake none.  Works fine with  windows-specific code which sets the DCB as follows:

{{{
dcb.fOutxCtsFlow = true;  // Enable CTS monitoring
dcb.fOutxDsrFlow = true;  // Enable DSR monitoring
dcb.fDtrControl = DTR_CONTROL_HANDSHAKE;  // Enable DTR handshaking
dcb.fOutX = false;  // Disable XON/XOFF for transmission
dcb.fInX = false;  // Disable XON/XOFF for receiving
dcb.fRtsControl = RTS_CONTROL_HANDSHAKE;  // Enable RTS handshaking
}}}

Couldn't find where the DCB is set in asio...",bd@…
9270,Hello world example in Boost accumulator reference manual does not compile,accumulator,Boost 1.54.0,To Be Determined,Bugs,Eric Niebler,new,2013-10-19T09:11:27Z,2013-10-19T09:11:27Z,"In the code example http://www.boost.org/doc/libs/1_54_0/doc/html/accumulators/user_s_guide.html#accumulators.user_s_guide.hello__world_


{{{
    std::cout << ""Moment: "" << accumulators::moment<2>(acc) << std::endl;
}}}

should be

{{{
    std::cout << ""Moment: "" << moment<2>(acc) << std::endl;
}}}
",jeadorf@…
9269,boost.exception unqualified enable_if/disable_if causing name clash with boost.test enable_if/disable_if,exception,Boost Development Trunk,To Be Determined,Bugs,Emil Dotchevski,new,2013-10-19T09:04:40Z,2013-10-19T09:04:40Z,"boost/exception/to_string.hpp and
boost/exception/info.hpp
both use enable_if/disable_if unqualified.
This caused ambiguous symbols as
boost/test/tree/decorator.hpp
defines its own versions: boost::unit_test::decorator::disable_if/enable_if.

There also is a related ticket for boost.test:
https://svn.boost.org/trac/boost/ticket/8679

I would recommend adding boost:: at the beginning.
",gdjss2728@…
9264,boost/date_time/local_time_adjustor.hpp requires more headers,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-10-18T14:49:32Z,2013-10-18T14:49:32Z,"
{{{
#include <boost/date_time/local_time_adjustor.hpp>

int main(int argc, char **argv)
{}
}}}

This doesn't compile because the included headers appears to require others headers. I guess the root problem is really with `dst_rules.hpp`.

Error (g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3):
{{{
In file included from /usr/local/include/boost_1_54_0/boost/date_time/local_time_adjustor.hpp:20:0,
                 from tmp.cpp:1:
/usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp: In static member function ‘static boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::date_type boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::local_dst_start_day(boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::year_type)’:
/usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp:317:45: error: ‘gregorian’ has not been declared
/usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp:321:30: error: ‘gregorian’ has not been declared
/usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp: In static member function ‘static boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::date_type boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::local_dst_end_day(boost::date_time::us_dst_rules<date_type_, time_duration_type_, dst_start_offset_minutes, dst_length_minutes>::year_type)’:
/usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp:330:30: error: ‘gregorian’ has not been declared
/usr/local/include/boost_1_54_0/boost/date_time/dst_rules.hpp:334:30: error: ‘gregorian’ has not been declared
}}}",sshannin@…
9262,windows_intermodule_singleton breaks when calling a Debug dll from a Release executable,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2013-10-18T10:28:48Z,2017-08-16T10:05:19Z,"A simplified example of what goes wrong (the reality is more complex, and also very difficult for me to change):

On Windows I have an exe and a dll that both use boost.interprocess. The dll interface is C-like, so that the exe and dll can use different runtimes (i.e. Debug and Release runtimes).
This works fine as long as I comment out the BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME define in workaround.hpp. But if I leave that define in the code I will get random access violations deep inside the tmp_folder function (or one of the other functions in tmp_dir_helpers).

I believe that this is due to the windows_intermodule_singleton, which is only used when ...HAS_KERNEL_BOOTTIME is defined. This singleton will get created in one runtime and then accessed in another, which does not work since it contains a std::map, which is an STL object that is not possible to pass between runtimes in Visual C++.

If it is possible to fix this that would be great, but the other option would be a ""nicer"" way to turn off the singleton without having to patch one of the boost headers.",Lars Hagström <lars@…>
9261,ssl alert are not being sent during handshake failure,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-10-18T09:24:28Z,2014-07-22T10:30:52Z,"According to the SSL protocol alert messages should (and must) be sent under certain circumstances if SSL-handshake fails. When inspecting the network traffic with wireshark during SSL-handshake failure it seems like these messages are being sent. 

When debugging asio and OpenSSL one can see that OpenSSL do indeed write alert messages (as expected) to the buffers asio has set up, but asio do not write them to the socket.

If SSL-handshake fails, OpenSSL writes alert message to asio buffers AND sets error code to SSL_ERROR_SSL. The function perform in the source code file asio/ssl/detail/impl/engine.ipp returns want_nothing if error is SSL_ERROR_SSL, which causes asio not to write data to the socket.   

This is tested on CentOS 6.4 x86_64.",Joakim Goldkuhl <joakim@…>
9260,Phoenix switch_ statements accessing wrong memory and cause segfault,phoenix,Boost 1.54.0,To Be Determined,Bugs,Thomas Heller,new,2013-10-18T07:46:19Z,2014-02-01T17:04:01Z,"Seth Heeren and I tracked down a problem in phoenix 3's switch_ statements that causes a crash in the attached example.

Judging from valgrind outputs, it appears as if the switch_ accesses memory outside it's stack. In the attached case that causes a crash when accessing local variables in the enclosing rule.

To reproduce:

With this rule:
qi::rule<It, bool(), qi::locals<bool, unsigned int, double, std::string>,  Skipper> enclosing;

defined as:
enclosing %= condition[_a = _1] >> double_[_val = _a];

it works.

If it is defined as:
enclosing %= condition[_a = _1] >> double_[_c = _1, _val = _a];

it crashes.

When not using local variables there is no crash but still  undefined behavior caused by the switch_.
Phoenix 2 does not have this problem.

",stephan.menzel@…
9259,errors in iostreams container_device example,iostreams,Boost Development Trunk,To Be Determined,Bugs,Jonathan Turkanis,new,2013-10-18T00:16:06Z,2013-10-18T00:16:06Z,"Hi,

I've been considering container_device as a more controllable alternative to std::stringstream (to append to a std::vector<char>).  I came across two off-by-one errors in the seek() implementation, and a problem in write() which could result in excess characters being written when the container is non-empty to start with.

I'll attach a patch.",chris.foster@…
9257,Fix for clang compiler warning,asio,Boost Development Trunk,To Be Determined,Patches,chris_kohlhoff,new,2013-10-17T14:16:45Z,2013-10-17T14:16:45Z,clang complains about the unsigned value TLS_OUT_OF_INDEXES not fitting into a signed enum value in boost\asio\detail\impl\win_tss_ptr.ipp. The attach patch silences this warning.,marci_r@…
9256,Compile fixes for clang-cl,mpl,Boost Development Trunk,To Be Determined,Patches,Aleksey Gurtovoy,new,2013-10-17T14:11:20Z,2013-10-17T14:11:20Z,Compile fixes for clang-cl and MPL's and.hpp and or.hpp.,marci_r@…
9253,Support for serializing std::u16string,serialization,Boost 1.55.0,To Be Determined,Feature Requests,Robert Ramey,new,2013-10-15T19:45:50Z,2014-02-04T01:26:01Z,"Hi:
I would like to use the boot serialization library with the C++11 std::u16string type. When I use it with a text archive I get the following error. Could you elaborate on the plans by when we will be having support for this. For now, we can get workaround the issue by writing our own non-intrusive ""load"" and ""save"" methods for u16string, but would prefer built in serialization support for it like std::string.

Please find below the stack trace for the error.

Thanks


boost/include/boost/serialization/access.hpp: In instantiation of 'static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = std::basic_string<char16_t>]':
boost/include/boost/serialization/serialization.hpp:102:5:   required from 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = std::basic_string<char16_t>]'
boost/include/boost/serialization/serialization.hpp:161:9:   required from 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive; T = std::basic_string<char16_t>]'
boost/include/boost/archive/detail/oserializer.hpp:148:5:   required from 'void boost::archive::detail::oserializer<Archive, T>::save_object_data(boost::archive::detail::basic_oarchive&, const void*) const [with Archive = boost::archive::text_oarchive; T = std::basic_string<char16_t>]'
boost/include/boost/archive/detail/oserializer.hpp:101:1:   required from 'class boost::archive::detail::oserializer<boost::archive::text_oarchive, std::basic_string<char16_t> >'
boost/include/boost/archive/detail/oserializer.hpp:253:13:   required from 'static void boost::archive::detail::save_non_pointer_type<Archive>::save_standard::invoke(Archive&, const T&) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_oarchive]'
boost/include/boost/archive/detail/oserializer.hpp:308:9:   required from 'static void boost::archive::detail::save_non_pointer_type<Archive>::invoke(Archive&, const T&) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_oarchive]'
boost/include/boost/archive/detail/oserializer.hpp:314:9:   required from 'static void boost::archive::detail::save_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_oarchive]'
boost/include/boost/archive/detail/oserializer.hpp:525:5:   required from 'void boost::archive::save(Archive&, T&) [with Archive = boost::archive::text_oarchive; T = std::basic_string<char16_t>]'
boost/include/boost/archive/detail/common_oarchive.hpp:69:9:   required from 'void boost::archive::detail::common_oarchive<Archive>::save_override(T&, int) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_oarchive]'
boost/include/boost/archive/basic_text_oarchive.hpp:113:9:   required from 'void boost::archive::basic_text_oarchive<Archive>::save_override(T&, int) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_oarchive]'
boost/include/boost/archive/detail/interface_oarchive.hpp:63:9:   required from 'Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_oarchive]'
main.cpp:39:15:   required from here

boost/include/boost/serialization/access.hpp:151:9: error: 'class std::basic_string<char16_t>' has no member named 'serialize'
boost/include/boost/serialization/access.hpp: In instantiation of 'static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive; T = std::basic_string<char16_t>]':
boost/include/boost/serialization/serialization.hpp:102:5:   required from 'void boost::serialization::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive; T = std::basic_string<char16_t>]'
boost/include/boost/serialization/serialization.hpp:161:9:   required from 'void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::archive::text_iarchive; T = std::basic_string<char16_t>]'
boost/include/boost/archive/detail/iserializer.hpp:188:5:   required from 'void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::archive::text_iarchive; T = std::basic_string<char16_t>]'
boost/include/boost/archive/detail/iserializer.hpp:120:1:   required from 'class boost::archive::detail::iserializer<boost::archive::text_iarchive, std::basic_string<char16_t> >'
boost/include/boost/archive/detail/iserializer.hpp:387:13:   required from 'static void boost::archive::detail::load_non_pointer_type<Archive>::load_standard::invoke(Archive&, const T&) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_iarchive]'
boost/include/boost/archive/detail/iserializer.hpp:439:9:   required from 'static void boost::archive::detail::load_non_pointer_type<Archive>::invoke(Archive&, T&) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_iarchive]'
boost/include/boost/archive/detail/iserializer.hpp:592:5:   required from 'void boost::archive::load(Archive&, T&) [with Archive = boost::archive::text_iarchive; T = std::basic_string<char16_t>]'
boost/include/boost/archive/detail/common_iarchive.hpp:66:9:   required from 'void boost::archive::detail::common_iarchive<Archive>::load_override(T&, int) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_iarchive]'
boost/include/boost/archive/basic_text_iarchive.hpp:98:9:   required from 'void boost::archive::basic_text_iarchive<Archive>::load_override(T&, int) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_iarchive]'
boost/include/boost/archive/text_iarchive.hpp:115:9:   required from 'void boost::archive::text_iarchive_impl<Archive>::load_override(T&, int) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_iarchive]'
boost/include/boost/archive/detail/interface_iarchive.hpp:60:9:   required from 'Archive& boost::archive::detail::interface_iarchive<Archive>::operator>>(T&) [with T = std::basic_string<char16_t>; Archive = boost::archive::text_iarchive]'
main.cpp:55:15:   required from here
boost/include/boost/serialization/access.hpp:151:9: error: 'class std::basic_string<char16_t>' has no member named 'serialize'


 
Thanks",learner.cpp@…
9252,Wrong compiler tag in .lib files,Building Boost,Boost 1.55.0,To Be Determined,Bugs,,new,2013-10-15T17:41:46Z,2014-04-03T03:31:45Z,"I build Boost with b2 --toolset=msvc11

The stage dir contains files like libboost_atomic-vc-mt-1_55.lib
Note the ""vc"", which should be ""vc110"", as that's what VC will be looking for later on:
1>LINK : fatal error LNK1104: cannot open file 'libboost_system-vc110-mt-gd-1_55.lib'",Olaf van der Spek <ml@…>
9247,locale - build failure with recommended icu configuration,locale,Boost 1.55.0,To Be Determined,Bugs,Artyom Beilis,new,2013-10-13T16:45:28Z,2013-10-13T16:45:28Z,"Configuring icu as recommended here:[[Br]]
http://source.icu-project.org/repos/icu/icu/trunk/readme.html#RecBuild
[[Br]]More precisely, build fails if icu::UnicodeString contructors are declared explicit.
The attach patch fixes build errors.

All fixes in formatter.cpp constructs UnicodeStrings from invariant strings (invariant characters defined here: http://icu-project.org/apiref/icu4c/platform_8h.html#a7fb0b0fede299f9d74973b15e79d3085). Previously all these constructors would involve an extra overhead as they were depending on the conversion framework.

The change in time_zone.cpp still depends on the conversion framework (behavior not changed). I do not think it is possible to guarantee that the provided string only includes invariant characters. In this case, the resulting string is undefined.",hvemha@…
9244,Respect rings closure of polygon while reading WKB/WKT input,geometry,Boost Development Trunk,To Be Determined,Bugs,Mateusz Loskot,new,2013-10-12T18:34:25Z,2013-11-14T15:33:07Z,"This task is reverse of #9217.

If model of a polygon specifies non-closed rings (first point is not repeated at last position), then this specification should be respected while consuming polygon encoded in OGC WKT format in which all rings are always closed.

For example, the point number assertion below should hold:

{{{
using namespace boost::geometry;

typedef model::point< double, 2, boost::geometry::cs::cartesian > Point;
typedef model::polygon< Point, false, false > Polygon;

Polygon p;
read_wkt(""POLYGON((1 1, 5 1, 5 5, 1 5, 1 1))"", p);

assert(p.outer().size() == 4);
}}}

The above applies to WKB I/O as well.",Mateusz Loskot
9239,"Implicit type conversion without warning, although Wconversion used",units,Boost 1.54.0,To Be Determined,Bugs,Matthias Schabel,new,2013-10-11T15:49:45Z,2014-03-11T00:45:23Z,"When defining a variable with automatic type recognition,
{{{
auto inv_time = 1/si::second;
}}}
this instruction
{{{
inv_time = 0.4/si::second;
}}}
does not generate a warning (using -Wconversion), while
{{{
auto p = 3;
p = 1.0/2.0;
}}}
generates a warning, as it should. Is there any reason for the different behavior in both cases?
It should be mentioned that this is not contingent to ""auto"", for
{{{
quantity<si::time,int>  time = 1/(1/si::second);
time = 0.4*si::second;
}}}
compiles without warning, too (and time = 0 s in the end). I thought implicit typecasts with possible loss of precision were forbidden or would at least trigger a warning.
",Daniel Rings <topwohnung@…>
9237,Vectorizer friendly code,multiprecision,Boost 1.54.0,To Be Determined,Bugs,John Maddock,new,2013-10-11T13:36:07Z,2016-02-10T12:28:17Z,"* use aligned storage (also statically attributed as such, with compiler specific attributes, not just allocated as aligned)
* mind __vectorcall and its ability to pass and return tuples! http://blogs.msdn.com/b/vcblog/archive/2013/07/12/introducing-vector-calling-convention.aspx
* use native/builtin arbitrary sized vectors
http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors",Domagoj Šarić
9232,Template bloat,multiprecision,Boost 1.54.0,To Be Determined,Bugs,John Maddock,new,2013-10-11T13:18:12Z,2013-10-12T12:00:29Z,"With integers of size N powm() will instantiate divide_unsigned_helper<> for N and N*2, since this is a very large function this leads to classical template bloat.
Examining the codegen it appears that both instantiations are nearly identical save for immediate constants -> this would suggest that you could refactor divide_unsigned_helper<> (and probably the rest of the library) so that it separates functionality that actually depends on template parameters from template-parameter independent code into separate functions (in this case divide_unsigned_helper would probably call a helper function that takes the size of the number as a runtime parameter).

ps. even when different function template instantiations result in identical code there are _still_ lousy compilers&linkers that will not merge them (Clang we are looking at you: http://llvm.org/bugs/show_bug.cgi?id=11633)...",Domagoj Šarić
9226,"On some computer, the Common Appdata is empty in registry, so boost interprocess cannot work.",interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2013-10-11T07:24:39Z,2015-03-06T16:16:32Z,"Our application is used by millions of people. I found that about 0.1 ~ 0.3 % computers will miss the registry item, or set to be empty, so lead to lots of trouble shooting.

My suggestion is to use SHGetSpecialFolderPathA instead of get the folder from registry, in HKEY_LOCALMACHINE\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders.

The code is like this:
inline void get_shared_documents_folder(std::string &s)
{
   s.clear();
   char szPath[MAX_PATH];
   if(SHGetSpecialFolderPathA(NULL,szPath,CSIDL_COMMON_APPDATA,FALSE))
   {
	   s = szPath;
   }
}

Thanks
Cheng Yang
",luckyangcheng@…
9222,iostreams documentation hard to read,iostreams,Boost 1.54.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2013-10-10T10:56:26Z,2014-01-13T22:13:33Z,"Hi,

You guys have put a lot of work into iostreams documentation,
but,
where it falls down is when someone unfamiliar with the library (ie, me) wants to quickly figure out how to do something.

For example, I wanted to create an input stream from an existing array.

I found this page:
http://www.boost.org/doc/libs/1_54_0/libs/iostreams/doc/classes/array.html

But frustratingly, there was no example on how to use.
Google was of limited use, eventually I found this page,
http://www.boost.org/doc/libs/1_53_0/libs/iostreams/doc/guide/generic_streams.html#examples

Which was exactly what I wanted to know,
but there really should be an example on the array's page, or at least a link to the relevant documentation that talks about how to use it.

Was very frustrating.

cheers,
Paul

",harris.pc@…
9218,Invalid pointer dereference on MSVC debug builds,lockfree,Boost 1.53.0,To Be Determined,Patches,timblechmann,new,2013-10-10T01:00:44Z,2013-10-10T01:05:25Z,"This is rare (so far only observed with race detection simulation), but due to the MSVC DebugCRT initialising ""new"" allocated memory to 0xCC instead of 0x00 the queue will miss a null pointer check in a particular race condition and try to dereference 0xCCCCCCCC.

If you're interested I could probably get a log of the exact sequence of operations that leads to this error, but it's pretty wordy.",Gavin Lambert <gavinl@…>
9214,(Windows) bjam should choose the msvc version from the current visual studio prompt,Building Boost,Boost 1.53.0,To Be Determined,Bugs,,new,2013-10-09T07:52:23Z,2016-01-13T00:54:13Z,"If you have multiple versions of msvc installed bjam seems to choose itself the version of msvc and do not take the current environment into account.

This behaviour is totally misleading, beacuse I open a specific Visual Studio prompt with a reason.

Bjam should pick the current msvc version out of the msvc prompt by default.

Example: I want to build boost through the cmake ExternalProject mechanism. I have msvc11 and msvc12 installed. Even after I opened a msvc12 prompt, bjam picks msvc11. This will result into linking errors later in the cmake build process because of runtime mismatches.",desurium@…
9211,fstream types don't have move semantics,filesystem,Boost 1.54.0,To Be Determined,Feature Requests,Beman Dawes,new,2013-10-08T13:54:16Z,2014-05-27T12:07:03Z,"boost::filesystem::ofstream etc. lack move semantics for c++11, so they can't be used as a replacement for std::ofstream etc. if move semantics are required",anonymous
9205,[variant or mpl] compilation error VC2013,mpl,Boost 1.55.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-10-07T08:38:13Z,2013-11-12T10:04:50Z,"I tried to use Boost 1.55.0 Beta RC's boost::variant with VC2013 RC.
Compilation error this code:
{{{
#include <boost/variant.hpp>

int main()
{
    boost::variant<int, char> v;
}
}}}

Error message is here:
(sorry, japanese error message...)
{{{
1>------ ビルド開始: プロジェクト:CppConsole, 構成:Debug Win32 ------
1>  main.cpp
1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(149): error C2143: 構文エラー : ';' が '<' の前にありません。
1>          c:\boost\boost-trunk-master\boost\mpl\assert.hpp(153) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::eval_assert<Pred>' の参照を確認してください
1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(149): error C4430: 型指定子がありません - int と仮定しました。メモ: C++ は int を既定値としてサポートしていません
1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(152): error C2238: ';' の前に無効なトークンがあります。
1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(159): error C2143: 構文エラー : ';' が '<' の前にありません。
1>          c:\boost\boost-trunk-master\boost\mpl\assert.hpp(163) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::eval_assert_not<Pred>' の参照を確認してください
1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(159): error C4430: 型指定子がありません - int と仮定しました。メモ: C++ は int を既定値としてサポートしていません
1>c:\boost\boost-trunk-master\boost\mpl\assert.hpp(162): error C2238: ';' の前に無効なトークンがあります。
1>c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\arg.hpp(45): error C2039: 'assert_not_arg' : 'boost::mpl' のメンバーではありません。
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(49) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::arg<1>::apply<T1,T2,boost::mpl::na,boost::mpl::na,boost::mpl::na>' の参照を確認してください
1>          with
1>          [
1>              T1=boost::mpl::l_end
1>  ,            T2=int
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply.hpp(63) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::arg<1>,0>,T1,T2>' の参照を確認してください
1>          with
1>          [
1>              T1=boost::mpl::l_end
1>  ,            T2=int
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\reverse_fold_impl.hpp(74) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply2<ForwardOp,boost::mpl::l_end,int>' の参照を確認してください
1>          with
1>          [
1>              ForwardOp=boost::mpl::arg<1>
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\reverse_fold.hpp(41) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::aux::reverse_fold_impl<2,boost::mpl::l_iter<boost::mpl::list2<T0,T1>>,boost::mpl::l_iter<boost::mpl::l_end>,State,BackwardOp,ForwardOp>' の参照を確認してください
1>          with
1>          [
1>              T0=int
1>  ,            T1=char
1>  ,            State=boost::mpl::l_end
1>  ,            BackwardOp=boost::mpl::bind2<boost::mpl::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<boost::unwrap_recursive,boost::mpl::void_>,boost::mpl::arg<1>>,0>,boost::mpl::_2>>
1>  ,            ForwardOp=boost::mpl::arg<1>
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\transform.hpp(65) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::reverse_fold<Seq,boost::mpl::l_end,boost::mpl::bind2<boost::mpl::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>>,boost::mpl::arg<1>>' の参照を確認してください
1>          with
1>          [
1>              Seq=boost::mpl::list2<int,char>
1>  ,            F=boost::unwrap_recursive
1>  ,            Tag=boost::mpl::void_
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\transform.hpp(113) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::aux::reverse_transform1_impl<P1,P2,boost::mpl::front_inserter<boost::mpl::clear_impl<boost::mpl::aux::list_tag>::apply<Sequence>::type>>' の参照を確認してください
1>          with
1>          [
1>              P1=boost::mpl::list2<int,char>
1>  ,            P2=boost::unwrap_recursive<boost::mpl::_1>
1>  ,            Sequence=boost::mpl::list2<int,char>
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\eval_if.hpp(41) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::transform1<Seq1,Seq2OrOperation,OperationOrInserter>' の参照を確認してください
1>          with
1>          [
1>              Seq1=boost::mpl::list2<int,char>
1>  ,            Seq2OrOperation=boost::unwrap_recursive<boost::mpl::_1>
1>  ,            OperationOrInserter=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\transform.hpp(138) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::eval_if<boost::mpl::or_<boost::mpl::is_na<boost::mpl::na>,boost::mpl::is_lambda_expression<Seq2OrOperation>,boost::mpl::not_<boost::mpl::is_sequence<Seq2OrOperation>>,boost::mpl::false_,boost::mpl::false_>,boost::mpl::transform1<Seq1,Seq2OrOperation,OperationOrInserter>,boost::mpl::transform2<Seq1,Seq2OrOperation,OperationOrInserter,Inserter>>' の参照を確認してください
1>          with
1>          [
1>              Seq2OrOperation=boost::unwrap_recursive<boost::mpl::_1>
1>  ,            Seq1=boost::mpl::list2<int,char>
1>  ,            OperationOrInserter=boost::mpl::na
1>  ,            Inserter=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\variant\variant.hpp(1209) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::transform<boost::mpl::list2<T0,T1>,boost::unwrap_recursive<boost::mpl::_1>,boost::mpl::na,boost::mpl::na>' の参照を確認してください
1>          with
1>          [
1>              T0=int
1>  ,            T1=char
1>          ]
1>          c:\users\a_takahashi\documents\visual studio 2013\projects\cppconsole\cppconsole\main.cpp(5) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::variant<int,char,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>' の参照を確認してください
1>c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\arg.hpp(45): error C3861: 'assert_not_arg': 識別子が見つかりませんでした
1>c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\arg.hpp(63): error C2039: 'assert_not_arg' : 'boost::mpl' のメンバーではありません。
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(80) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::arg<2>::apply<T1,T2,T3,T4,T5>' の参照を確認してください
1>          with
1>          [
1>              T1=boost::mpl::l_end
1>  ,            T2=char
1>  ,            T3=boost::mpl::na
1>  ,            T4=boost::mpl::na
1>  ,            T5=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\bind.hpp(50) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply_wrap5<boost::mpl::arg<2>,U1,U2,U3,U4,U5>' の参照を確認してください
1>          with
1>          [
1>              U1=boost::mpl::l_end
1>  ,            U2=char
1>  ,            U3=boost::mpl::na
1>  ,            U4=boost::mpl::na
1>  ,            U5=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\bind.hpp(143) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::aux::resolve_bind_arg<boost::mpl::arg<2>,U1,U2,U3,U4,U5>' の参照を確認してください
1>          with
1>          [
1>              U1=boost::mpl::l_end
1>  ,            U2=char
1>  ,            U3=boost::mpl::na
1>  ,            U4=boost::mpl::na
1>  ,            U5=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(80) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>::apply<T1,T2,T3,T4,T5>' の参照を確認してください
1>          with
1>          [
1>              F=boost::unwrap_recursive
1>  ,            Tag=boost::mpl::void_
1>  ,            T1=boost::mpl::l_end
1>  ,            T2=char
1>  ,            T3=boost::mpl::na
1>  ,            T4=boost::mpl::na
1>  ,            T5=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\bind.hpp(160) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply_wrap5<boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>,U1,U2,U3,U4,U5>' の参照を確認してください
1>          with
1>          [
1>              F=boost::unwrap_recursive
1>  ,            Tag=boost::mpl::void_
1>  ,            U1=boost::mpl::l_end
1>  ,            U2=char
1>  ,            U3=boost::mpl::na
1>  ,            U4=boost::mpl::na
1>  ,            U5=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\bind.hpp(206) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::aux::resolve_bind_arg<boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>,U1,U2,U3,U4,U5>' の参照を確認してください
1>          with
1>          [
1>              F=boost::unwrap_recursive
1>  ,            Tag=boost::mpl::void_
1>  ,            U1=boost::mpl::l_end
1>  ,            U2=char
1>  ,            U3=boost::mpl::na
1>  ,            U4=boost::mpl::na
1>  ,            U5=boost::mpl::na
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(49) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::bind2<boost::mpl::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>>::apply<T1,T2,boost::mpl::na,boost::mpl::na,boost::mpl::na>' の参照を確認してください
1>          with
1>          [
1>              F=boost::unwrap_recursive
1>  ,            Tag=boost::mpl::void_
1>  ,            T1=boost::mpl::l_end
1>  ,            T2=char
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\apply.hpp(63) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply_wrap2<boost::mpl::bind2<boost::mpl::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<F,Tag>,boost::mpl::arg<1>>,0>,boost::mpl::_2>>,T1,T2>' の参照を確認してください
1>          with
1>          [
1>              F=boost::unwrap_recursive
1>  ,            Tag=boost::mpl::void_
1>  ,            T1=boost::mpl::l_end
1>  ,            T2=char
1>          ]
1>          c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\reverse_fold_impl.hpp(81) : コンパイルされたクラスの テンプレート のインスタンス化 'boost::mpl::apply2<BackwardOp,boost::mpl::l_end,char>' の参照を確認してください
1>          with
1>          [
1>              BackwardOp=boost::mpl::bind2<boost::mpl::lambda<boost::mpl::push_front<boost::mpl::na,boost::mpl::na>,boost::mpl::void_>::type,boost::mpl::_1,boost::mpl::bind1<boost::mpl::protect<boost::mpl::bind1<boost::mpl::quote1<boost::unwrap_recursive,boost::mpl::void_>,boost::mpl::arg<1>>,0>,boost::mpl::_2>>
1>          ]
1>c:\boost\boost-trunk-master\boost\mpl\aux_\preprocessed\plain\arg.hpp(63): error C3861: 'assert_not_arg': 識別子が見つかりませんでした
========== ビルド: 0 正常終了、1 失敗、0 更新不要、0 スキップ ==========
}}}

patch to boost/mpl/assert.hpp, line 137:
{{{
#if BOOST_WORKAROUND(BOOST_MSVC, >= 1700)
}}}
to
{{{
#if BOOST_WORKAROUND(BOOST_MSVC, == 1700)
}}}",Akira Takahashi <faithandbrave@…>
9204,const_multi_array_ref with const,multi_array,Boost 1.53.0,To Be Determined,Bugs,Ronald Garcia,new,2013-10-07T04:09:03Z,2013-10-07T04:09:03Z,"It's now declared as
{{{#!cpp
template <typename T, std::size_t NumDims,
  typename TPtr = const T*
>
}}}
This makes it SFINAE-fail if you use const type for T, like {{{const_multi_array_ref<const double, 2>}}}.

This simple change fixes the problem (tested):
{{{#!cpp
#include ""boost/type_traits/add_const.hpp""
...
template <typename T, std::size_t NumDims,
  typename TPtr = typename boost::add_const<T>::type *
>
}}}",Maxim.Yanchenko@…
9198,boost\boost\crc.hpp warning due to implicit bool cast,crc,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-10-04T09:58:55Z,2013-10-05T10:33:53Z,"While compiling with Visual Studio 2013 RC, the following warning is issued:

boost\boost\crc.hpp(601): warning C4800: 'unsigned int' : forcing value to bool 'true' or 'false' (performance warning)

----
Fix: Change line 601 as follows:

bool const  quotient = (remainder & high_bit_mask) != 0;",Frank Heimes <drfghde@…>
9197,mpl\aux_\integral_wrapper.hpp(72): warning C4307: '+' : integral constant overflow,mpl,Boost Development Trunk,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-10-04T09:54:30Z,2016-08-04T13:26:30Z,"While compiling with Visual Studio 2013 RC, the following warning is issued:

mpl\aux_\integral_wrapper.hpp(72): warning C4307: '+' : integral constant overflow

i.e. for the following line:

typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value + 1)) ) next;
",Frank Heimes <drfghde@…>
9194,Compilation error with Boost.Python,python USE GITHUB,Boost 1.55.0,Boost 1.55.0,Bugs,Ralf W. Grosse-Kunstleve,new,2013-10-03T08:40:35Z,2013-10-03T08:40:35Z,"Extra "")"" in

{{{
In file included from /mnt/server/grups/boost-1.55.0/include/boost/python/class.hpp:17:0,
                 from /mnt/server/grups/boost-1.55.0/include/boost/python.hpp:18,
                 from /mnt/server/grups/src/cttc-pce/pce-unstable/apps/server/plugins/management/mgmt_cli/cli_python_plugin_loader.cpp:1:
/mnt/server/grups/boost-1.55.0/include/boost/python/data_members.hpp:308:47: error: missing '(' in expression

}}}

{{{
# if BOOST_WORKAROUND(__EDG_VERSION__, <= 238))

}}}

The fix seems straightforward",Ramon Casellas <ramon.casellas@…>
9190,boost::filesystem::extension(...) throws runtime_error if the locale is unknown.,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-10-02T06:13:37Z,2013-10-02T06:13:37Z,"Running the following program gives an std::runtime_error if the locale is set to something which the system doesn't support.

{{{
#include <boost/filesystem.hpp>
int main() { boost::filesystem::extension(""test.txt""); }
}}}


{{{
> LC_CTYPE=unknown ./a.out
> terminate called after throwing an instance of 'std::runtime_error'
>   what():  locale::facet::_S_create_c_locale name not valid
> Aborted
}}}

This is reproducible on debian testing and ubuntu 12.04 but I think it's a general issue.

1. Is it the right behavior to throw an exception?

2. If it should throw an exception, it should have been of type filesystem_error.",mkm@…
9188,named_slot_map.cpp fails to build in Solaris Studio 12.3,signals,Boost 1.54.0,To Be Determined,Bugs,Douglas Gregor,new,2013-10-01T22:50:29Z,2013-10-09T17:15:57Z,"I'm getting an ""Overloading ambiguity error"" when building libs/signals/src/named_slot_map.cpp on or around lines 105 & 128 on the calls to `groups.erase`.

This may be related to an issue [http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-unresolved.html talked about here], but that issue seems to indicate the problem would only exist in C++11.

The error goes away with the following minor edits:

{{{
-105:     groups.erase((const_group_iterator) group);
+105:     groups.erase(*(const_group_iterator) group);
-128:     if (empty(g)) groups.erase((const_group_iterator) g++);
+128:     if (empty(g)) groups.erase(*(const_group_iterator) g++);
}}}

I'm doing this work on an airgapped network, and the error is rather verbose ... but I'll give a shorted version of the error:

{{{
""libs/signals/src/named_slot_map.cpp"", line 105: Overloading ambiguity between ""std::map<A>::erase( __rw::__rw_tree_iter<B> )"" and ""std::map<A>::erase(const  boost::signals::detail::stored_group&)"".
""libs/signals/src/named_slot_map.cpp"", line 128: Overloading ambiguity between ""std::map<A>::erase( __rw::__rw_tree_iter<B> )"" and ""std::map<A>::erase(const  boost::signals::detail::stored_group&)"".
}}}

",Brian Vandenberg <phantall+boost@…>
9186,posix_time and time zones,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-10-01T21:07:27Z,2013-10-01T21:07:27Z,"Hi,

When I use something like:
boost::posix_time::time_from_string(""2013-09-29 23:36:54.565+02"");

I end up with:
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >'
  what():  bad lexical cast: source type value could not be interpreted as target
Aborted

However, the following 2 do work:
boost::posix_time::time_from_string(""2013-09-29 23:36:54.565123+02"");
boost::posix_time::time_from_string(""2013-09-29 23:36:54.565"");

It also doesn't seem to be doing anything with the +02.  When I use to_tm() regardless of what is behind the +, I always get the 23 in tm_hour.  The glibc extension tm_gmtoff is also always set to 0.

None of the functions that convert it to strings seem to be able to have a time zone in it.

I really don't understand why there isn't any support for time zones.  A time without time zone seems to be totally useless to me.

PS: The documentation has 3 times tm_isddst in it instead of tm_isdst.",kurt@…
9178,Use type deduction instead of boost::function to store lambda,scope_exit,Boost 1.54.0,To Be Determined,Feature Requests,Lorenzo Caminiti,new,2013-09-29T21:42:09Z,2013-09-29T21:44:19Z,"boost::function is used to store lambda, which may cause superfluous allocation.
It is possible to use type deduction instead.
",Evgeny.Panasyuk@…
9177,Improved serialization of floating point values,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,reopened,2013-09-29T17:08:04Z,2014-06-25T16:44:26Z,"Currently there are several weaknesses with floating point serialization:

1) There's no handling of {{{long double}}} or user-defined floating point types that have been declared primitives.
2) The current code for float and double may fail to print sufficient digits to round trip the value, when the value is less than 1, but not so small as to trigger an automatic switch to scientific format (which from memory occurs around 10^-5).

The attached patch addresses both of these issues, and coincidentally simplifies the code as well.",John Maddock
9176,Intel compiler needs custom archiver,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2013-09-29T09:06:46Z,2013-09-29T09:06:46Z,"The Intel C++ compiler should have static libraries built with xiar not ar on Linux, probably on OSX as well but I don't know about that for sure.  Without this static libraries built with -ipo (inter procedural optimizations) are non-usable.  I'm attaching a partial patch for this, but note that:

* It's only a partial solution since the Intel setup script isn't called before calling xiar - I couldn't figure out how to achieve that.
* Compiled executables often don't run - again the Intel setup script needs to be run before the executable so that Intel's shared libraries can be found.  One workaround would be to always link with the -static-intel flag.",John Maddock
9173,Can't file a bug report (broken bug reporter),trac / subversion,Boost 1.54.0,To Be Determined,Bugs,Douglas Gregor,new,2013-09-29T04:25:20Z,2016-09-19T19:07:50Z,"This is kind of ridiculous. Boost is blocking my bug report because I provided references (and links to those references) in the report???

And the Bug Reporter won't provide the challenge its asking me to solve....",noloader@…
9164,Dereference null return value in make_shared_object.hpp,smart_ptr,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-09-26T06:08:53Z,2013-09-26T06:08:53Z,"Using some static analyzer tool , Boost reports warning messages Dereference null return value.

In codes like:
boost::detail::sp_ms_deleter< T > * pd = static_cast<boost::detail::sp_ms_deleter< T > *>( pt._internal_get_untyped_deleter() );

pd is dereference in next line : void * pv = pd->address();

If pd is NULL in above call, dereferencing it may cause crash.

It can be avoided by using:
BOOST_ASSERT(!pd);

It is at many places.",Gaurav Gupta <g.gupta@…>
9159,bootstrap under Linux w/Solaris Studio 12.3 defaults to 64-bit; doesn't run correctly,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-09-24T20:38:33Z,2013-09-26T18:09:42Z,"I ran bootstrap under Linux using Solaris Studio 12.3 in a few different ways:

{{{
# This defaults to 64-bit; note that
# 'tools/build/v2/engine/build.sh'
# does not have the means to add any
# flags in with any toolset except 'cc'
./bootstrap.sh --with-toolset=sun
# The binary produced doesn't work correctly:
test 0 -lt $(./bjam --help |& wc -c) || echo ""Failed""
Failed

export CC=/opt/oracle/solarisstudio12.3/bin/cc
export CFLAGS=-m32
./bootstrap.sh --with-toolset=cc
test 0 -lt ./bjam --help |& wc -c) && echo ""Succeeded""
Succeeded
}}}

When building with the ```cc``` toolset, the default ```project-config.jam``` file forces ```feature.values``` to contain the 'cc' toolset, which causes problems later on down the line because, or so it seems, ```cc``` is not a valid toolset to use with bjam.  The workaround I used for that was to make the replacement ```s/cc/sun/g``` in the .jam file.

",Brian Vandenberg <phantall+boost@…>
9156,1.54 broke NO_ZLIB=1 and NO_COMPRESSION=1,iostreams,Boost 1.55.0,Boost 1.55.0,Bugs,Jonathan Turkanis,new,2013-09-24T07:43:20Z,2017-01-31T10:02:58Z,"https://github.com/boostorg/iostreams/commit/dfb1f61c26b77556a1cca0654d08847cf87d26ae
This commit broke the ability to build boost with without zlib.  The following bjam succeeds if you remove these two lines added by this patch.  Please fix for 1.55?
{{{
+      [ ac.check-library /zlib//zlib : <library>/zlib//zlib
+        <source>zlib.cpp <source>gzip.cpp ]
}}}

{{{
./bjam toolset=gcc target-os=windows threadapi=win32 threading=multi variant=release link=static --user-config=user-config.jam --without-mpi --without-python -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged --build-type=complete --prefix=/home/ubuntu/out/staging/boost -j2 install
Performing configuration checks

    - 32-bit                   : yes
    - arm                      : no
    - mips1                    : no
    - power                    : no
    - sparc                    : no
    - x86                      : yes
    - has_icu builds           : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add ""using mpi ;"" to your user-config.jam
error: at /home/ubuntu/build/boost_1_54_0/tools/build/v2/kernel/modules.jam:107
error: Unable to find file or target named
error:     '/zlib//zlib'
error: referred to from project at
error:     'libs/iostreams/build'
error: could not resolve project reference '/zlib'
}}}",Warren Togami <wtogami@…>
9148,6 Errors,mpl,Boost 1.54.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-09-22T10:44:07Z,2013-09-26T18:11:37Z,"
{{{
Error   1	error C2143: syntax error : missing ';' before '<'	c:\program files\boost_1_54_0\boost\mpl\assert.hpp	149	1	Frelania Server C++
Error   2	error C4430: missing type specifier - int assumed. Note: C++ does not support default-int	c:\program files\boost_1_54_0\boost\mpl\assert.hpp	149	1	Frelania Server C++
Error   3	error C2238: unexpected token(s) preceding ';'	c:\program files\boost_1_54_0\boost\mpl\assert.hpp	152	1	Frelania Server C++
Error   4	error C2143: syntax error : missing ';' before '<'	c:\program files\boost_1_54_0\boost\mpl\assert.hpp	159	1	Frelania Server C++
Error   5	error C4430: missing type specifier - int assumed. Note: C++ does not support default-int	c:\program files\boost_1_54_0\boost\mpl\assert.hpp	159	1	Frelania Server C++
Error   6	error C2238: unexpected token(s) preceding ';'	c:\program files\boost_1_54_0\boost\mpl\assert.hpp	162	1	Frelania Server C++
}}}

",anonymous
9143,boost can not load bootstrap,Building Boost,Boost 1.54.0,To Be Determined,Support Requests,,new,2013-09-21T02:02:29Z,2016-02-14T22:40:07Z,"when i try to load bootstrap.bat i get this error

cl.exe System Error
   The program can't start because mspdb110.dll is missing from your computer try reinstalling the program (which I did) to fix this probelm",m_hartley4@…
9141,Please document need to run install_name_tool when installing boost on MacOSX,Building Boost,Boost Development Trunk,To Be Determined,Bugs,,new,2013-09-21T01:16:40Z,2013-09-21T01:16:40Z,"This was originally discussed in 2008 on the Boost.build mailing list 
in thread ""Install_name wrong on OS X dylibs with latest CVS""

To recap, building on MacOSX with seems to work, but the resulting shared libraries lack an absolute path in their install_name, so apps using them fail to load; instead, one gets an error like

{{{
dyld: Library not loaded: libboost_thread.dylib
  Referenced from: a.out
  Reason: image not found
Trace/BPT trap: 5
}}}

To work around this, the user can set DYLIB_LIBRARY_PATH to point
to the libraries, but that's not very satisfying.
Or the packager can use Apple's install_name_tool to set the absolute
path at install time.

This last bit was made possible by the fix to bug 1927. 

This should be documented, perhaps near where hardcode-dll-paths
is documented.  The document might say something like

   Note about building on MacOSX

   Shared libraries on MacOSX generally have their absolute path
   embedded in them in a field called install_name.  This field
   is copied into any executable that links against them.  The
   executable then looks exactly at that absolute path to find the
   library.  If the library is not there, the executable will fail
   to load.  
   If you use e.g. homebrew to install Boost, this is taken care 
   of for you, but if you're building boost yourself, read on.

   With the default build of Boost, doing e.g.
      otool -D libboost_regex.dylib
   produces just a pathless filename, and doing
      otool -L a.out | grep libboost
   on a library linked against this will show that the executable
   is trying to load the library without a path.

   A user can work around this by add the install directory 
   to the DYLIB_LIBRARY_PATH environment variable, but that's often
   not acceptable.

   A nicer way to work around this is to use Apple's install_name_tool
   to embed the library's full path inside the library at install
   time, e.g.
      install_name_tool -id /foo/bar/libboost_regex.dylib  /foo/bar/libboost_regex.dylib

   (Alternately, you can patch the use of -install_name in tools/build/v2/tools/darwin.jam before building, but that's ugly.)
",dank@…
9137,mpl::and_<mpl::true_> returns false,mpl,Boost Development Trunk,Boost 1.55.0,Bugs,Aleksey Gurtovoy,new,2013-09-19T13:36:33Z,2013-09-21T03:32:51Z,"The following snippet fails to compile:

{{{
#include <boost/mpl/and.hpp>
#include <boost/mpl/bool.hpp>

int main() {
    using namespace boost::mpl;
    static_assert(and_<true_>::value, ""?""); //fires
}
}}}

See also the following thread at the mailing list http://lists.boost.org/Archives/boost/2013/09/206333.php",Agustín K-ballo Bergé <kaballo86@…>
9136,Typos in documentation.,bimap,Boost Development Trunk,To Be Determined,Bugs,Matias Capeletto,new,2013-09-19T13:04:26Z,2013-09-19T13:04:26Z,"There are a few occurances of ""the the"" in the docs of bimap.
Also, it is alphabetically, not alfabetically.",mlang@…
9134,"Code that uses BOOST_THROW_EXCEPTION produces a lot of ""result may be used uninitialized (...)"" warnings in certain conditions",exception,Boost 1.54.0,To Be Determined,Patches,Emil Dotchevski,new,2013-09-19T12:45:45Z,2013-09-19T12:45:45Z,"The problem appears when using g++ with `-Wuninitialized -fno-exceptions -O3` flags.

Given a simple test:
{{{
#include <boost/lexical_cast.hpp>

int main() {
  return boost::lexical_cast<int>("""");
}
}}}

when compiled using g++ v4.6.3 produces the following output:
{{{
$ g++ test.cpp -Iboost -fno-exceptions -Wuninitialized -O3 -c

In file included from test.cpp:1:0:
boost/boost/lexical_cast.hpp: In static member function ‘static Target boost::detail::lexical_cast_do_cast<Target, Source>::lexical_cast_impl(const Source&) [with Target = int, Source = const char*]’:
boost/boost/lexical_cast.hpp:2353:24: warning: ‘result’ may be used uninitialized in this function [-Wuninitialized]
}}}

Please note that this problem appears only when using `-O3` optimization level.

One way of fixing this issue is to add `BOOST_ATTRIBUTE_NORETURN` to `boost::throw_exception()` declaration in `boost/throw_exception.hpp`, as shown in the attached patch.

It should be safe to do so, as the documentation of `boost::throw_exception()` says that:

> (...) Callers of throw_exception are allowed to assume that the function never returns (...)

This solves the issue completely.",Adam Romanek <romanek.adam@…>
9132,mpl and lexical_cast dependency,mpl,Boost 1.53.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-09-19T10:18:24Z,2013-09-19T10:41:23Z,"Hi,

It took mi one day to find out why my msm stopped to compile after upgrading to new boost. I was upgrading from 1.45 (with msm from 1.51) to 1.53. After many tries with different #define's it turned out the problem is elsewhere. This is code that breaks compilation:

{{{
#include <boost/lexical_cast.hpp>

#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#define BOOST_MPL_LIMIT_VECTOR_SIZE 30
#include <boost/mpl/vector.hpp>

int main()
{
	boost::mpl::vector<int, char, double, int, int, int, int, int, int, char,
	                   int, char, double, int, int, int, int, int, int, char,
	                   int> v;
}
}}}

and compilation output:

{{{
g++ -Wall -Wextra -pedantic -Wlong-long plik.C -o plik -O2 -I /bldtools/3rd/boost/boost1.53/32bitrhel63/include -Wno-unused
plik.C:13:1: warning: ""BOOST_MPL_LIMIT_VECTOR_SIZE"" redefined
In file included from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/mpl/vector.hpp:18,
                 from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/math/policies/policy.hpp:14,
                 from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/math/special_functions/math_fwd.hpp:28,
                 from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/math/special_functions/sign.hpp:17,
                 from /bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/lexical_cast.hpp:167,
                 from plik.C:10:
/bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/mpl/limits/vector.hpp:18:1: warning: this is the location of the previous definition
plik.C: In function âint main()â:
plik.C:41: error: wrong number of template arguments (21, should be 20)
/bldtools/3rd/boost/boost1.53/32bitrhel63/include/boost/mpl/aux_/preprocessed/gcc/vector.hpp:22: error: provided for âtemplate<class T0, class T1, class T2, class T3, class T4, class T5, class T6, class T7, class T8, class T9, class T10, class T11, class T12, class T13, class T14, class T15, class T16, class T17, class T18, class T19> struct boost::mpl::vectorâ
plik.C:41: error: invalid type in declaration before â;â token
make: *** [plik] Error 1
}}}

Removing lexical_cast fixes the problem. Looks like lexical_cast started to use mpl vector with default settings and later #define's don't change the settings.

The issue is complicated because it is not enough to move #define's at the beginning of file. I had to modify all my *.hpp files to include msm headers (and #define's) at the beginning of file. And also *.cpp files to include the above *.hpp at the beginning of file :(.

Regards,

Marcin Pytel",mkp
9131,Memcheck reports invalid read in exit() on boost 1.54 on Ubuntu 12.04,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-19T08:38:53Z,2014-02-28T16:47:54Z,"{{{
==10361== Memcheck, a memory error detector
==10361== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==10361== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==10361== Command: target/test/integration_test
==10361== 
==10361== Invalid read of size 8
==10361==    at 0x5AE7E18: wcscmp (wcscmp.S:479)
==10361==    by 0x55A0113: std::moneypunct<wchar_t, false>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x55A0198: std::moneypunct<wchar_t, false>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x5594A79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x5594C4C: std::locale::~locale() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x5A81D1C: __cxa_finalize (cxa_finalize.c:56)
==10361==    by 0x6733E55: ??? (in /usr/lib/libboost_filesystem.so.1.54.0)
==10361==    by 0x6744A20: ??? (in /usr/lib/libboost_filesystem.so.1.54.0)
==10361==    by 0x5A81900: __run_exit_handlers (exit.c:78)
==10361==    by 0x5A81984: exit (exit.c:100)
==10361==    by 0x5A67773: (below main) (libc-start.c:258)
==10361==  Address 0x6b5fe98 is 0 bytes after a block of size 8 alloc'd
==10361==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10361==    by 0x559FDED: std::moneypunct<wchar_t, false>::_M_initialize_moneypunct(__locale_struct*, char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x559711E: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x559765E: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x6741733: boost::filesystem::path::codecvt() (in /usr/lib/libboost_filesystem.so.1.54.0)
==10361==    by 0x50BF59E: boost::log::v2_mt_posix::sinks::text_file_backend::set_file_name_pattern_internal(boost::filesystem::path const&) (in /usr/lib/libboost_log.so.1.54.0)
==10361==    by 0x50C103D: boost::log::v2_mt_posix::sinks::text_file_backend::construct(boost::filesystem::path const&, std::_Ios_Openmode, unsigned long, boost::log::v2_mt_posix::aux::light_function<bool ()()> const&, bool) (in /usr/lib/libboost_log.so.1.54.0)
==10361==    by 0x413815: void boost::log::v2_mt_posix::sinks::text_file_backend::construct<boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&) (text_file_backend.hpp:511)
==10361==    by 0x412F5E: boost::log::v2_mt_posix::sinks::text_file_backend::text_file_backend<boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&) (text_file_backend.hpp:386)
==10361==    by 0x41280A: boost::detail::sp_if_not_array<boost::log::v2_mt_posix::sinks::text_file_backend>::type boost::make_shared<boost::log::v2_mt_posix::sinks::text_file_backend, boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const, >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&&, ) (make_shared_object.hpp:218)
==10361==    by 0x41066E: main (integration_test.cpp:17)
==10361== 
==10361== Invalid read of size 8
==10361==    at 0x5AE7E18: wcscmp (wcscmp.S:479)
==10361==    by 0x55A0003: std::moneypunct<wchar_t, true>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x55A0088: std::moneypunct<wchar_t, true>::~moneypunct() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x5594A79: std::locale::_Impl::~_Impl() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x5594C4C: std::locale::~locale() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x5A81D1C: __cxa_finalize (cxa_finalize.c:56)
==10361==    by 0x6733E55: ??? (in /usr/lib/libboost_filesystem.so.1.54.0)
==10361==    by 0x6744A20: ??? (in /usr/lib/libboost_filesystem.so.1.54.0)
==10361==    by 0x5A81900: __run_exit_handlers (exit.c:78)
==10361==    by 0x5A81984: exit (exit.c:100)
==10361==    by 0x5A67773: (below main) (libc-start.c:258)
==10361==  Address 0x6b600c8 is 0 bytes after a block of size 8 alloc'd
==10361==    at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10361==    by 0x559F7FD: std::moneypunct<wchar_t, true>::_M_initialize_moneypunct(__locale_struct*, char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x559716B: std::locale::_Impl::_Impl(char const*, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x559765E: std::locale::locale(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16)
==10361==    by 0x6741733: boost::filesystem::path::codecvt() (in /usr/lib/libboost_filesystem.so.1.54.0)
==10361==    by 0x50BF59E: boost::log::v2_mt_posix::sinks::text_file_backend::set_file_name_pattern_internal(boost::filesystem::path const&) (in /usr/lib/libboost_log.so.1.54.0)
==10361==    by 0x50C103D: boost::log::v2_mt_posix::sinks::text_file_backend::construct(boost::filesystem::path const&, std::_Ios_Openmode, unsigned long, boost::log::v2_mt_posix::aux::light_function<bool ()()> const&, bool) (in /usr/lib/libboost_log.so.1.54.0)
==10361==    by 0x413815: void boost::log::v2_mt_posix::sinks::text_file_backend::construct<boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&) (text_file_backend.hpp:511)
==10361==    by 0x412F5E: boost::log::v2_mt_posix::sinks::text_file_backend::text_file_backend<boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&) (text_file_backend.hpp:386)
==10361==    by 0x41280A: boost::detail::sp_if_not_array<boost::log::v2_mt_posix::sinks::text_file_backend>::type boost::make_shared<boost::log::v2_mt_posix::sinks::text_file_backend, boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const, >(boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::file_name, char const [14]> const&&, ) (make_shared_object.hpp:218)
==10361==    by 0x41066E: main (integration_test.cpp:17)

}}}
",asturman@…
9128,Vector deallocation with pool_allocator enters a dead loop,pool,Boost 1.54.0,To Be Determined,Bugs,Chris Newbold,new,2013-09-18T12:21:14Z,2013-09-18T12:21:14Z,"Here is the complete test code to reproduce the bug:

{{{#!c++
#include <ctime>
#include <iostream>
#include <vector>
#include <boost/pool/pool_alloc.hpp>

const size_t LARGE=200000, LEN=30;

template < typename VEC > void time_it( const char* tag )
{
   VEC vec(LARGE);

   std::clock_t start = std::clock() ;
   for ( int i = 0 ; i < LARGE ; ++i ) vec[i].resize (LEN) ;
   std::cout << tag << "": "" << ( std::clock() - start ) /
      double(CLOCKS_PER_SEC) << "" secs.\n"" ;
}

#define TIME_IT( a ) time_it<a>( #a ) ;

int main()
{
   typedef size_t T;
   typedef std::vector<std::vector<T> > std_vec ;

   typedef boost::pool_allocator<T> boost_allocator;
   typedef std::vector<std::vector<T, boost_allocator> > boost_vec;

   TIME_IT( std_vec ) ;
   TIME_IT( boost_vec ) ;
   return 0;
}
}}}

It hangs while cleaning up at the end of the time_it function. I've seen with ddd that it hangs in boost/pool/simple_segregated_storage.hpp in the following block:
{{{#!c++
  while (true)
  {
    // if we're about to hit the end, or if we've found where ""ptr"" goes.
    if (nextof(iter) == 0 || std::greater<void *>()(nextof(iter), ptr))
      return iter;

    iter = nextof(iter);
  }
}}}
If instead of pool_allocator I use fast_pool_allocator then this does not happen and it's equally slow. In this example pool_allocator takes about 4-5 times longer to allocate than the default one - I don't know why.

I compiled it with 

g++-4.7 -O3 -g testPool5.cc

under Ubuntu. I tried Boost versions 1.54.0 and 1.49.0.
",Dragan Vidovic <vitkecar@…>
9121,"""Getting Started"": Atomic missing from libs requiring to be built",Getting Started Guide,Boost 1.54.0,To Be Determined,Bugs,Dave Abrahams,new,2013-09-16T18:24:40Z,2013-09-16T18:24:40Z,The Atomic library is missing from the list of libs needing to be built. ,jeffrey.flinn@…
9120,system_error_category::message() produces non-english error messages in ANSI encoding,system,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-16T14:32:22Z,2013-09-16T14:32:22Z,"In the system_error_category::message(), the FormatMessageA(...,MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),...) is used to create error messages. Unfortunately, this code can produce non-english error messages in the ANSI encoding.

According to the http://www.boost.org/community/error_handling.html, ""internationalization is beyond the scope of the exception class author"". So, I think that it would be better to use MAKELANGID(LANG_ENGLISH, SUBLANG_DEFAULT) here.",s.cheban@…
9119,memory errors and eventual segfault when using Log,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-16T13:55:56Z,2013-10-03T22:13:32Z,"Hello,

I'm using the the Log component of Boost 1.54 compiled from source and I get many memory errors and segfault while invoking the function logging::add_file_log. To make sure it was not my code, I went to the Boost installation and ran valgrind on some of the Log examples that invoke that function and it happens also there. The minimalistic example tutorial_file.cpp reveals the issue (though there may be more issues with Log). I get many memory errors in Mac OS X and Ubuntu, in Mac OS X it doesn't crash the application but I get a segfault in Ubuntu. 

I'm attaching the valgrind output on Ubuntu 12.04 with kernel version ""Linux HPC 3.5.0-40-generic #62~precise1-Ubuntu SMP Fri Aug 23 17:38:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux"". 

Best regards,
Giovanni",Giovanni Azua <bravegag@…>
9118,Seg fault on thread join  when llvm and  libc++ are used,thread,Boost 1.54.0,To Be Determined,Bugs,viboes,reopened,2013-09-15T19:47:04Z,2014-10-11T02:58:27Z,"This issue appears to be specific to llvm libc++ standard library

the program compiled with the following options will have a seg fault on thread join.

{{{
clang -x c++ -arch x86_64 -std=gnu++11 -stdlib=libc++ -I/opt/local/include -c main.cpp -o main.o
clang++ -arch x86_64  -L/opt/local/lib  main.o -stdlib=libc++ -lboost_system-mt -lboost_thread-mt -o mutex_test
}}}


the program compiled with

{{{
clang -x c++ -arch x86_64 -I/opt/local/include -c main.cpp -o main.o
clang++ -arch x86_64  -L/opt/local/lib  main.o -lboost_system-mt -lboost_thread-mt -o mutex_test
}}}



{{{
System Version :  OS X Mountain Lion 10.8.4
Compiler :
$ clang --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
Boost: built/installed with mac ports
}}}

",tconant@…
9116,Binary serialization: bitwise copying should also apply to single POD objects (it now only seems to work on arrays/collections),serialization,Boost 1.53.0,To Be Determined,Bugs,Robert Ramey,new,2013-09-14T19:03:26Z,2013-10-01T12:51:12Z,"I'm trying to find the best settings for fast binary serialization of big POD objects. My tests indicate that, for a structure tagged as bitwise serializable, I only get better performance on arrays and vectors, not on individual objects.

For instance, say I have a structure made up only of POD types:

{{{
struct BigStruct
{
  double    m1;
  long long m2;
  float     m3;
  // ...
  bool      m499;
  short     m500;
};

namespace boost
{
  namespace serialization
  {
    template <class Archive>
    void serialize(Archive& ioArchive, BigStruct& ioStruct, const unsigned int iVersion)
    {
      ioArchive & ioStruct.m1;
      ioArchive & ioStruct.m2;
      ioArchive & ioStruct.m3;
      // ...
      ioArchive & ioStruct.m499;
      ioArchive & ioStruct.m500;
    }
  }
}

#include <boost/serialization/is_bitwise_serializable.hpp>
BOOST_IS_BITWISE_SERIALIZABLE(BigStruct);
}}}

Then, serializing a single !BigStruct object takes considerably (at least 5 times) longer than serializing an array of 1 !BigStruct object.",Louis Zanella <louis.zanella@…>
9114,Documentation examples not working,spirit,Boost 1.54.0,To Be Determined,Bugs,Joel de Guzman,new,2013-09-14T12:18:48Z,2013-09-15T16:14:13Z,"Example of ''qi::phrase_parse'' (from this [http://www.boost.org/doc/libs/1_54_0/libs/spirit/doc/html/spirit/abstracts/attributes/compound_attributes.html page]):
{{{
// the following parses ""1.0 2.0"" into a pair of double
std::string input(""1.0 2.0"");
std::string::iterator strbegin = input.begin();
std::pair<double, double> p;
qi::phrase_parse(strbegin, input.end(),
    qi::double_ >> qi::double_,       // parser grammar 
    qi::space,                        // delimiter grammar
    p);                               
}}}

and example of ''qi::parse'' (from this [http://www.boost.org/doc/libs/1_54_0/libs/spirit/doc/html/spirit/abstracts/attributes/more_compound_attributes.html page]):
{{{
// the following parses ""(1.0, 2.0)"" into a pair of double
std::string input(""(1.0, 2.0)"");
std::string::iterator strbegin = input.begin();
std::pair<double, double> p;
qi::parse(strbegin, input.end(),
    '(' >> qi::double_ >> "", "" >> qi::double_ >> ')', // parser grammar 
    p);
}}}

both produce compile error:
{{{
no matching function for call to 'std::pair<double, double>::pair(const double&)'
}}}

Compiled with gcc 4.7.3",ruslan_baratov@…
9112,[tr1] Failures in test_ref_wrapper_tricky.cpp,result_of,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-09-13T16:22:40Z,2013-09-13T17:00:15Z,"The mentioned test case gives a number of failures.  Those can be tracked down to two problems (at least the test case perceives them as problems).  Google gives hits dating this back to 1.37, I have confirmed it with 1.41 and 1.54.  I'm not sure why this hasn't been addressed--have I inadvertently opened a can of worms?

First, reference_wrapper that wraps function-like objects doesn't derive off std::unary_function, resp. std::binary function.  That's relatively easy to fix by introducing a reference_wrapper_base class template, that reference_wrapper inherits off.  That template optionally derives off unary_ or binary_function as appropriate.

Second, calling reference wrapper as function doesn't work for member functions.  This can be solved by introducing operator() in the above mentioned base class.

I'll attach a patch that implements the above, except for specializations for reference_wrapper<{binary,unary}_function>.  Please let me know whether a patch to this effect would be applicable and advise on areas that need more work.",Petr Machata <pmachata@…>
9105,boost::tokenizer fails if string contains percent signs,tokenizer,Boost 1.54.0,To Be Determined,Bugs,jsiek,new,2013-09-12T07:03:45Z,2013-09-12T07:03:45Z,"[Visual Studio 2010]
Let's use as an example code shown on the bottom of the page http://www.boost.org/doc/libs/1_54_0/libs/tokenizer/escaped_list_separator.htm

=====>>>>
// simple_example_2.cpp
#include<iostream>
#include<boost/tokenizer.hpp>
#include<string>

int main(){
   using namespace std;
   using namespace boost;
   string s = ""Field 1,\""putting quotes around fields, allows commas\"",Field 3"";
   tokenizer<escaped_list_separator<char> > tok(s);
   for(tokenizer<escaped_list_separator<char> >::iterator beg=tok.begin(); beg!=tok.end();++beg){
       cout << *beg << ""\n"";
   }
}
<<<<=====

Works fine.

Let's insert percent sign somewhere inside string s.
As an example
s = ""Field 1,\""putting q%uotes around fields, allows commas\"",Field 3"";

program fails with:
First-chance exception at 0x75c4c41f in test.exe: Microsoft C++ exception: boost::escaped_list_error at memory location 0x007cf060..

It fails even percent sign would be followed by hex code (like %20)
",anonymous
9102,"Various Boost header files define variables with internal linkage, which results in unnecessary code bloat",system,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-11T09:39:06Z,2013-09-17T21:06:03Z,"Some Boost headers define variables with internal linkage. For example, in `boost/system/error_code.hpp`:
{{{
    static const error_category &  posix_category = generic_category();
    static const error_category &  errno_ecat     = generic_category();
    static const error_category &  native_ecat    = system_category();
}}}
In `boost/asio/error.hpp`:
{{{
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();
}}}
Because of this, every translation unit that includes these headers results in a separate instance of each of these variables in the resulting executable file. Because these variables have non-constant initializers, not only they are not eliminated during linking, even if not used, but also each instance of such variable results in a call to a initialization function during program startup.

I think that merely including a Boost header, without using anything from it, should not result in any extra code remaining in the resulting executable - especially not if each translation unit results in a separate copy of such code.",abacabadabacaba@…
9099,boost::filesystem::stem() reporting wrong value on some entries (seen on Linux),filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-10T12:52:20Z,2013-09-10T12:52:20Z,"Compiled with gcc on Linux.

Consider the following example with an empty string as path:
{{{
  boost::filesystem::path mypath("""");
  cout << mypath.parent_path().native() << endl;
  cout << mypath.stem().native() << endl;
}}}

This will print out, as expected, two empty strings. If one now changes the path to be analysed into ""tmp/"", like this:

{{{
  boost::filesystem::path mypath(""tmp/"");
  cout << mypath.parent_path().native() << endl;
  cout << mypath.stem().native() << endl;
}}}

then the output will be ""tmp"" on one line (totally expected and correct) and ""."" on the next line (totally unexpected and wrong, it should be an empty string).
",bach@…
9097,directory_iterator crash with intel release builds on windows,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-09-10T10:11:46Z,2013-09-10T12:14:55Z,"{{{
#include <boost/filesystem.hpp>

int main()
{
    boost::filesystem::directory_iterator i1(""C:\\"");
    boost::filesystem::directory_iterator i2(""C:\\Windows"");
}
}}}

Crashes in Intel (12.1 included in Composer XE 2011 SP1) release builds. 
Construction of i1 works but construction of i2 gives:
''Exception at 0x77a0320e, code: 0xc0000005: read access violation at: 0x0, flags=0x0 (first chance)''

The crash (according to the debugger) happens in operations.cpp:2150.
This used to work with Boost 1.48.0 and also isn't a problem with Debug or MSVC10 builds.",Nils Gladitz <gladitz@…>
9089,missing locale in strings_from_facet.hpp,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-09-07T17:07:14Z,2014-03-15T16:09:13Z,"see my example:

{{{
 std::locale::global(std::locale(""""));
 boost::posix_time::ptime t;
 std::stringstream ss;
 std::string s = ""Sat, 07-Sep-43 10:40:59 GMT"";
 ss.str(s);
 boost::posix_time::time_input_facet* rfc850_date_workarround2 =
     new boost::posix_time::time_input_facet(""%a, %d-%b-%y %H:%M:%S GMT"");
 ss.imbue(std::locale(std::locale::classic(), rfc850_date_workarround2));
 ss >> t;
 if (t != boost::posix_time::not_a_date_time)
 {
    std::cout << ss.str() << std::endl;
 }
}}}

I expected the output:

{{{
2043-Sep-07 10:40:59
}}}

but in fact no output...
",Jackarain
9088,I/O Exception state & status savers may cause std::terminate in C++11,io,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-09-07T13:09:13Z,2016-10-27T19:54:38Z,"The `boost::io::basic_ios_iostate_saver` and `boost::io::basic_ios_exception_saver` class templates in file ""boost/io/ios_state.hpp"" alter the I/O exception state and trigger-mask, respectively, in their constructors and destructors.  When a change in either makes the two statuses have a non-zero result when combined with bitwise-and, an exception is thrown.

A potentially throwing destructor is problematic enough, but C++11 adds a new source of trouble.  C++11 declares all destructors with no exception specification to be `noexcept` by default, which makes all imported pre-C++11 types with a throwing destructor to call `std::terminate` if they throw.  The (immediate) fix would be to add a `noexcept(false)` specification to those destructors when used in C++11 mode.
",Daryle Walker
9084,boost::asio::ip::address::is_loopback() on mapped ip4 127.0.0.1,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-09-06T10:28:46Z,2016-07-22T17:31:29Z,"boost::asio::ip::address_vs::is_loopback() returns false on the address '::ffff:127.0.0.1'. Maybe this is the correct behavior, but it was certainly unexpected to me.

(the ip4 address '127.0.0.1' maps to '::ffff:127.0.0.1'). ",tmoers
9081,boost geometry booleans create self-intersecting polygons from non-self-intersecting polygons,geometry,Boost Development Trunk,Boost 1.56.0,Bugs,Barend Gehrels,reopened,2013-09-04T23:25:02Z,2013-10-22T02:42:03Z,"The attached program mimics aspects of the way in which I am trying to use the boost geometry polygon boolean operations.  It repeatedly selects two polygons from a list, computes the booleans, and adds the results to the list.  It also checks the results for self-intersection and reports the input and operation that lead to the failure before exiting.  When I run it as is I get this result:

FAILED TO SUBTRACT
MULTIPOLYGON(((0.2654871893371946 0.2880663823207319,0.349204346823061 0.3819520178855695,0.4615617830267027 0.4487295340751242,0.2851297065819251 0.2894032238012155,0.2654871893371946 0.2880663823207319)))
MULTIPOLYGON(((0.4615617830267023 0.4487295340751238,0.4809248136210044 0.4662152446243423,0.4861159661340977 0.46332284819279,0.4615617830267023 0.4487295340751238)))
MULTIPOLYGON(((0.4615617830267027 0.4487295340751242,0.4615617830267023 0.4487295340751238,0.2851297065819251 0.2894032238012155,0.2654871893371946 0.2880663823207319,0.349204346823061 0.3819520178855695,0.4615617830267023 0.4487295340751238,0.4615617830267027 0.4487295340751242)))

Expected result: the program completes without finding a self-intersection.

Boost SVN revision: 85565.
",snubdodecahedron@…
9075,Devision by zero in boost/date_time/int_adapter.hpp,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-09-02T09:20:08Z,2013-10-15T18:42:48Z,"line 347
{{{
#!cpp
339  /*! Provided for cases when automatic conversion from 
340   * 'int' to 'int_adapter' causes incorrect results. */
341  int_adapter operator/(const int rhs) const
342  {
343    if(is_special() && rhs != 0)
344    {
345      return mult_div_specials(rhs);
346    }
347    return int_adapter<int_type>(value_ / rhs);
348  }
}}}
rhs is not checked if is_special() returns false.",Alexander Drichel <alexander.drichel@…>
9074,Performance inefficiencies in boost::libs::filesystem::src::operations.cpp,filesystem,Boost 1.54.0,To Be Determined,Feature Requests,Beman Dawes,new,2013-09-02T09:06:42Z,2013-09-02T12:28:21Z,"line 1490
Large stack use

Local variable ""info"" uses 16392 bytes of stack space, which exceeds the maximum single use of 10000 bytes.

it should be replaced by uniqe_ptr

union info_t
{
  char buf[REPARSE_DATA_BUFFER_HEADER_SIZE+MAXIMUM_REPARSE_DATA_BUFFER_SIZE];
  REPARSE_DATA_BUFFER rdb;
} /*info*/;
    
std::unique_ptr<info_t> info( new info_t );
...
",Alexander Drichel <alexander.drichel@…>
9068,`parser_buf` like class moved to boost/detail/basic_pointerbuf.hpp,regex,Boost Development Trunk,To Be Determined,Patches,John Maddock,new,2013-08-30T09:10:40Z,2014-11-13T16:34:27Z,"Boost.LexicalCast uses slightly modifyed version of `parser_buf` from `boost/regex/v4/cpp_regex_traits.hpp` (see #8267).

In [85523] I've moved common code to the boost/detail/basic_pointerbuf.hpp and now `boost/regex/v4/cpp_regex_traits.hpp` can be updated to use the common code (see patch in attachment).",Antony Polukhin
9067,rational::assign doesn't even have the basic guarantee,rational,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-08-30T04:00:51Z,2013-08-30T13:18:38Z,"The current implementation of the `assign` member function assigns the new components before normalization checks.  Normalization throws if the components are too violating to fix, but the object has already been changed and the old values have been lost.  Worse, if the object was created outside of the current stack frame, it will survive the exception in a state still violating its invariant!
",Daryle Walker
9066,Add support for MultiPoint WKB format,geometry,Boost Development Trunk,To Be Determined,Bugs,Mateusz Loskot,new,2013-08-29T23:14:32Z,2016-03-02T20:32:39Z,"Mats Taraldsvik [http://lists.boost.org/geometry/2013/08/2479.php posted three patches] to the list with MultiPoint WKB support:

 * 0001-Adds-an-equal-check-for-MultiPoints-with-number-of-p.patch
 * 0002-Adds-support-for-reading-MultiPoint-WKB.patch
 * 0003-Add-tests-for-MultiPoint-WKB.patch

Those patches have been generated in Git format against the Git mirros.
I have refactored them into SVN format using [https://gist.github.com/mloskot/6384278 simple command].

So, here is combined version of Mats' changes in more convenient form ready for review.

I also have added Jamfile.v2 files, so it is ready to build and test.",Mateusz Loskot
9059,Boost.Asio detail/impl/win_static_mutex leaks a CRITICAL_SECTION,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2013-08-28T12:24:46Z,2016-07-30T10:16:56Z,"A CRITICAL_SECTION is not some POD type. It needs to be freed using DeleteCriticalSection or it will leak resources.

This leak has been found using Microsoft's Application Verifier.",segev208@…
9056,empty_ptree missing from boost,property_tree,Boost 1.54.0,To Be Determined,Bugs,Sebastian Redl,new,2013-08-28T02:47:31Z,2013-08-28T02:47:31Z,"The empty_ptree method is mentioned at http://www.boost.org/doc/libs/1_51_0/doc/html/boost/property_tree/basic_ptree.html and http://www.boost.org/doc/libs/1_46_1/libs/property_tree/examples/empty_ptree_trick.cpp, but it doesn't appear to actually exist in boost. Presumably this should be fixed.",atomic.quark@…
9055,spin_condition.notify()hangs if communication peer crashes,interprocess,Boost 1.54.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-08-27T16:53:51Z,2013-08-27T16:53:51Z,"When using interprocess_condition for signalling availability of new data in shared memory the call to notify_one() or notify_all() hangs forever if the communication peer terminates ungracefully. This happens because spin_condition.notify() calls m_enter_mut.lock().

A possible solution that we apply in our project is to provide notify methods with a timeout argument and a boolean return value that call m_enter_mut.timed_wait(abs_time). The return value can then be handled accordingly.

",stepan.seycek@…
9052,Support of Stateful Allocators in spirit,spirit,Boost 1.54.0,To Be Determined,Feature Requests,Joel de Guzman,new,2013-08-27T09:37:50Z,2013-08-27T09:37:50Z,"Currently it's not possible to avoid allocations from happening with the standard allocators of the used standard library.

That makes it quite impossible to manage the memory for the parser.

Some use case examples:

* Writing a library in C++ with a C interface allowing the user to pass 'malloc' and 'free' replacements.
* Writing a program that uses a pool memory allocator

I know that this probably won't be too high on your todo list, however it'd be great to have.",evilissimo@…
9051,"jam build system refuses to work on windows, won't build on mingw-w64",Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-08-26T18:30:09Z,2014-04-05T05:48:35Z,"- batch files don't run for mingw-w64, they are only for MSVC++.

- no Makefiles 

- Jam build system refuses to run on windows, the file extension is unrecognized, and no exe is provided for it to run like was previously the case.

- windows 7 64-bit and mingw-w64+MSYS (gcc) is my platform.

- I would give you the URL for the compilers, but this bug tracking system rejects them as spam, and there are numerous there, you want personal rubenvb 4.8 stdthread experimental. the x86_64 on the far left is the target processor, and the win32 or win64 on the right is the host (what you are running)



",jmichae3@…
9044,Enable constexpr for applicable operators.,operators,Boost 1.54.0,To Be Determined,Bugs,Daniel Frey,new,2013-08-25T10:25:39Z,2013-08-25T10:25:39Z,"Some operators, like the ones for comparison & equality, generally don't require mutating operations for their work.  That means those functions can be `constexpr` if they use a literal operand type and the base operators are themselves `constexpr`.",Daryle Walker
9043,Boost serialization version does not work on Windows,serialization,Boost 1.54.0,To Be Determined,Bugs,Robert Ramey,reopened,2013-08-24T14:30:18Z,2014-02-03T22:43:17Z,"Have obtained latest version of boost and tried attached demo.cpp. I noticed that the output did not store or restore the driver name. This behaviour is the same as in the supplied example/demofile.txt and example/demo_output.txt which leads me to believe that this is not due to my system configuration.

In VS2010 when I hover over BOOST_CLASS_VERSION it gives an error:

ERROR: version is not a template

but it appears to compile without error or a warning related to this.

It appears the macro for defining versions of a class is not working, and so no classes are saving any data except for data associated with version 0, and also no data from any version other than zero will be read back in to any class either.

I have compiled from source on ubuntu and my output is correct, both saving and loading driver names.",richard.stutt@…
9039,Boost.Bimap documentation misprint,bimap,Boost 1.54.0,To Be Determined,Bugs,Matias Capeletto,new,2013-08-23T12:38:00Z,2013-08-23T12:38:00Z,"http://www.boost.org/doc/libs/1_54_0/libs/bimap/doc/html/boost_bimap/the_tutorial/discovering_the_bimap_framework.html#boost_bimap.the_tutorial.discovering_the_bimap_framework.bimap_mapping_framework

I suppose there is a misprint in '''used''' word.

Current: You have to '''used''' references to views, and not directly views object. Views cannot be constructed as separate objects from the container they belong to, so the following: 

Suggested: You have to '''use''' references to views, and not directly views object. Views cannot be constructed as separate objects from the container they belong to, so the following: 
",sarum9in@…
9038,[pool] Test cases need to link with boost_system DSO on Linux,pool,Boost 1.54.0,To Be Determined,Bugs,Chris Newbold,new,2013-08-22T21:19:48Z,2013-08-22T21:19:48Z,"Currently running the test suite for Boost.Pool gives me messages like the following:

{{{
/home/petr/rpmbuild/BUILD/boost_1_53_0/tests-out/boost/bin.v2/libs/pool/test/test_simple_seg_storage.test/gcc-4.8.1/debug/test_simple_seg_storage.o: In function `__static_initialization_and_destruction_0':
/home/petr/rpmbuild/BUILD/boost_1_53_0/libs/pool/test/../../../boost/system/error_code.hpp:214: undefined reference to `boost::system::generic_category()'
/home/petr/rpmbuild/BUILD/boost_1_53_0/libs/pool/test/../../../boost/system/error_code.hpp:215: undefined reference to `boost::system::generic_category()'
/home/petr/rpmbuild/BUILD/boost_1_53_0/libs/pool/test/../../../boost/system/error_code.hpp:216: undefined reference to `boost::system::system_category()'
}}}

I'm not sure whether Boost.Pool uses Boost.System directly, but on Linux, linking with Boost.System DSO is commonly needed also when one uses Boost.Thread header files.

I'm attaching a patch that fixes the obvious cases.  Unfortunately I don't know enough Jam magic to fix the valgrind invocations as well.",Petr Machata <pmachata@…>
9034,Timezone (%Q) is ignored in time_input_facet / local_time_input_facet,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-08-22T12:19:17Z,2013-08-22T12:19:17Z,"I'm trying to parse an extended ISO 8601 date-time string to ptime or local_time using the following code:

{{{
	boost::local_time::wlocal_time_input_facet *inputFacet = new boost::local_time::wlocal_time_input_facet();
	inputFacet->set_iso_extended_format();
	std::wstringstream ss;
	ss.imbue(std::locale(ss.getloc(), inputFacet));
	ss.str(inputString);
	boost::local_time::local_date_time time(boost::local_time::not_a_date_time);
	ss >> time;
}}}

This works for ""2013-08-20T17:14:21Z"" or ""2013-08-20T17:14:21"", however it doesn't work as soon as I add a timezone to it, e.g. ""2013-08-20T19:14:21+02"" or ""2013-08-20T19:14:21+02:00"". As far as I can tell the error is because the timezone (%Q) is completely ignored in time_facet.hpp.",Maurice Gilden <MauriceG@…>
9033,Resource Leak in boost::filesystem in operation.cpp at resize_file_api() (Windows),filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-08-22T10:48:48Z,2014-08-08T06:48:05Z,"The function resize_file_api() in operations.cpp can lead to a resource leak. The responsible part of code is the following:

{{{
return handle != INVALID_HANDLE_VALUE
      && ::SetFilePointerEx(handle, sz, 0, FILE_BEGIN)
      && ::SetEndOfFile(handle)
      && ::CloseHandle(handle);
}}}

If SetFilePointerEx() or SetEndOfFile() fail, the handle will not be closed.",anonymous
9032,Wrong Boost.Iterator permutation_iterator::base() description,iterator,Boost Development Trunk,To Be Determined,Bugs,jeffrey.hellrung,new,2013-08-22T09:32:03Z,2013-09-04T06:37:31Z,"[http://svn.boost.org/svn/boost/trunk/libs/iterator/doc/permutation_iterator_ref.rst] says that return type of {{{permutation_iterator::base()}}} is {{{ElementIterator}}}, while it has to be {{{IndexIterator}}} ([http://svn.boost.org/svn/boost/trunk/boost/iterator/permutation_iterator.hpp]).",Y. <yar444@…>
9021,Cannot export boost::iostreams::source implementation on MSVC,iostreams,Boost 1.54.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-08-20T20:03:29Z,2013-08-20T20:03:29Z,"The following fails on MSVC 10 (VS2010) and MSVC 11 (VS2012) at least:

    #include <boost/iostreams/concepts.hpp>
    class __declspec(dllexport) mystream : public boost::iostreams::source {};

with the error:

    error C2338: (is_convertible<Mode, two_sequence>::value)

in concepts.hpp line 47. The same think happens with a sink. Are custom sources and sinks not meant to be exported from a library?",mathstuf@…
9018,No cross-version constructor,rational,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-08-20T11:09:39Z,2013-08-27T10:35:27Z,"I was writing a numeric class template, and it has constructor templates for cross-version conversion.  When I tested with two `boost::rational` instantiations as the component types, the code calls `static_cast` at the component level, which fails since we never defined that between `rational` instantiations.  (There's the `boost::rational_cast` function template, but that doesn't help in generic code.)  Let's fix that.

We could be fancy and add a non-explicit constructor template for when the component types are implicitly convertible, and an explicit version otherwise, but that would be rude to add C++11 features to a class that's otherwise C++98.  Maybe we'll add it someday....
",Daryle Walker
9017,Support for std::numeric_traits,rational,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-08-20T10:47:48Z,2013-09-05T00:03:21Z,"Although `boost::rational` uses `std::numeric_limits` in its implementation, it does not provide its own (partial) specialization of the standard class template.  This means that generic numeric code cannot use `rational` in contexts that use the assistance of `numeric_limits`.

This has been brought to my attention by Michael Olea in his message <http://lists.boost.org/boost-users/2013/08/79751.php> to the Users' list.",Daryle Walker
9015,Ptree should have add_or_get,property_tree,Boost 1.54.0,To Be Determined,Feature Requests,Sebastian Redl,new,2013-08-19T13:24:25Z,2015-01-23T11:10:34Z,"When using the method ""..get"" on a Ptree it is possible to retrieve the value of the key. When the key doesn't exits, the default value is used. Then the proper way should be that the default value will be added to the ptree. I don't know how other people think about it? Now you have to add another line to add it to the ptree. Maybe It can with a overloaded function, which has the option to add it to the ptree.",anonymous
9013,Create enum to make sign result more readable.,math,Boost 1.54.0,To Be Determined,Feature Requests,John Maddock,new,2013-08-18T16:28:55Z,2013-08-18T16:28:55Z,"The function 'sign' return 1, 0 or -1 depending on the signal of the z, but comparing the result with -1, 0 or 1 constants could make the source code bad readable specially for people that doesn't know what the 'sign' function return.

{{{
if (math::sign(value) == -1){
....
}
}}}

I propose to create an enumerate type to test the result of the function with a constant, to create a more readable code. The compatibility with the previous implementation of the function is not broken.

Suggested implementation of code:

{{{
enum Sign
{
	SIGN_NEGATIVE = -1,
	SIGN_ZERO = 0,
	SIGN_POSITIVE = 1
}

template <class T>
inline Sign sign BOOST_NO_MACRO_EXPAND(const T& z)
{
   return (z == 0) ? SIGN_ZERO : (boost::math::signbit)(z) ? SIGN_NEGATIVE : SIGN_POSITIVE;
}
}}}

The previous example comparison could be write as:

{{{
if (math::sign(value) == math::SIGN_NEGATIVE){
....
}
}}}
",Joaquim Duran Comas <jduran.gm@…>
9006,read_xml segfaults if run from boost::asio::spawn,property_tree,Boost 1.54.0,To Be Determined,Bugs,Sebastian Redl,new,2013-08-16T14:11:29Z,2013-08-16T14:11:29Z,"I've noticed that if read_xml is run through a boost::asio::spawn then read_xml encounters a segmentation violation.

{{{
#include <boost/property_tree/ptree.hpp>
#include <iostream>
#include <boost/property_tree/xml_parser.hpp>
#include <string>
#include <sstream>
#include <boost/asio.hpp>
#include <boost/asio/spawn.hpp>


void read() {
	std::cout<<""starting read()""<<std::endl;
	std::string xml = R""phi(<?xml version=""1.0""?> <start></start>)phi"";
	std::stringstream ss(std::move(xml));
	boost::property_tree::ptree pt;
	boost::property_tree::read_xml(ss, pt);
	std::cout<<""ending read()""<<std::endl;
}

int main() {
	boost::asio::io_service ios;
	boost::asio::strand mystrand{ios};
	read();
	boost::asio::spawn(mystrand, [](boost::asio::yield_context){read();});
	ios.run();
}

}}}
The code above produces
{{{
starting read()
ending read()
starting read()
Segmentation fault
}}}
Compiled with gcc-4.8.1 and clang-3.3 (release) on Suse Linux 11 x86_64.

",Mátyás Végh <matyas.vegh@…>
9004,Minor corrections for boost.program_options documentation,program_options,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-08-16T11:40:32Z,2013-08-16T11:40:32Z,"Reading the library documentation I noted a few issues.

http://www.boost.org/doc/libs/1_54_0/doc/html/program_options/overview.html

== Section ""Syntactic Information"" ==

Following the code snippet, the text describes four parameters.  However the second option (""compression"") is described as ""the first option"".

Fixed text: ""For the second option, the user must specify a value, using a single token.""

== Section: Description formatting ==

Current text: ""compute the indentation for options's description""
Fixed text: ""compute the indentation for option's description""

Current text: ""Each of the paragraph is output""
Fixed text: ""Each of the paragraphs are output"" or ""Each paragraph is output""

Current text: ""Only one tabulator per paragraph is allowed, otherwisee an exception""
Fixed text: ""Only one tabulator per paragraph is allowed, otherwise an exception""",pfee@…
9002,boots::date_time::from_iso_string() accepts invalid time mark,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-08-16T08:03:40Z,2013-08-16T08:03:40Z,"Both from_iso_string() and time_from_string() allow time > 23:59:59, e.g. they accept ""2013-08-16 26:01:01"" and do not throw. I find that is very strange and confusing, and that also breaks ISO 8601. I see that after parsing the rest of string to time_duration you do not check it to be in valid range [ 0, 24:00:00 ), may be you should? Thank you",Alexey Pavlyutkin <alexey.pavlyutkin@…>
8989,"asio::ip namespace issues, and proposed solution",asio,Boost 1.54.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-08-09T15:22:47Z,2013-08-10T07:24:49Z,"Given an [http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/InternetProtocol.html InternetProtocol] (usually [http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/ip__tcp.html ip::tcp]), there's no generic way to get access to these classes:

{{{
class boost::asio::ip::address_v4;
class boost::asio::ip::address_v6;
}}}

The reason is that boost::tcp::ip is a namespace and not a type.

I propose adding these to the requirements for [http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/InternetProtocol.html InternetProtocol]:

{{{
X::address_v4, return type boost::asio::ip::address_v4
X::address_v6, return type boost::asio::ip::address_v6
}}}

This would enable template classes parameterized on [http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/reference/InternetProtocol.html InternetProtocol] to be able to choose an address type. For example:

{{{
template <typename InternetProtcol>
struct Details
{
    typedef InternetProtocol          protocol_type;
    typedef protocol_type::endpoint   endpoint_type;

    // Good, with this proposal
    typedef protocol_type::address_v4 address_v4;
    endpoint_type get_endpoint ()
    {
        return endpoint_type (address_v4::any (), 1053);
    }

    // Bad, the only current solution
    typedef boost::asio::ip::address_v4 address_v4;
    endpoint_type get_endpoint_bad ()
    {
        return endpoint_type (address_v4::any (), 1053);
    }
};
}}}
",vinnie.falco@…
8985,More -Wunused-local-typedef warnings when building Boost 1.54.0 with gcc 4.8.1,python USE GITHUB,Boost 1.54.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-08-08T23:10:20Z,2013-08-08T23:10:20Z,"These are the unused-local-typedef warnings specific to Boost.Python:

./boost/python/cast.hpp:73:20: warning: typedef ‘must_be_a_complete_type’ locally defined but not used [-Wunused-local-typedefs]
       typedef char must_be_a_complete_type[sizeof(T)];

./boost/python/object/pickle_support.hpp:110:31: warning: typedef ‘error_type’ locally defined but not used [-Wunused-local-typedefs]
           Class_>::error_type error_type;

./boost/python/make_function.hpp:58:32: warning: typedef ‘assertion’ locally defined but not used [-Wunused-local-typedefs]
           >::too_many_keywords assertion;
",lcarreon@…
8982,More -Wunused-local-typedef warnings when building Boost 1.54.0 with gcc 4.8.1,xpressive,Boost 1.54.0,To Be Determined,Bugs,Eric Niebler,new,2013-08-08T22:30:56Z,2013-08-08T22:30:56Z,"These are the unused-local-typedef warnings specific to Boost.Xpressive:

./boost/xpressive/regex_algorithms.hpp:306:57: warning: typedef ‘char_type’ locally defined but not used [-Wunused-local-typedefs]
         typedef typename iterator_value<BidiIter>::type char_type;

./boost/xpressive/detail/dynamic/parser.hpp:331:53: warning: typedef ‘char_type’ locally defined but not used [-Wunused-local-typedefs]
     typedef typename iterator_value<BidiIter>::type char_type;
",lcarreon@…
8978,Segfault crash in boost.python with keyword arguments and overloads.,python USE GITHUB,Boost 1.51.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-08-08T18:28:09Z,2013-08-08T18:32:27Z,"Please see the thread on the python c++ sig email list here (lacking protocol prefix to pass spam check):
mail.python.org/pipermail/cplusplus-sig/2013-August/017012.html

Here is a minimal repro case:
------------------------------------------------
// C++
#include <boost/python.hpp>

static void f1(int a0, int a1) { }
static void f2(int a0, int a1, int a2) { }

BOOST_PYTHON_MODULE(kwargCrash) {
    boost::python::def(""f"", f1, (arg(""a1"")=2));
    boost::python::def(""f"", f2, (arg(""a2"")=2));
}

# Python
import kwargCrash
kwargCrash.f(0, a1=2)
------------------------------------------------

Version found info: boost 1.51.0, Python 2.7.5, gcc 4.8.1.

Please see the list thread linked above for a detailed explanation of why the crash occurs.  In short, boost.python calls PyTuple_GET_ITEM() on None, and then unconditionally uses the result as a key to look up in a dict.  This boost.python code hasn't changed in a long time.  I suspect Python has changed, and is now returning NULL here instead of None, and calling PyDict_GetItem with NULL crashes.

Here is a patch to the boost.python code that fixes the bug.  It simply checks to see if it got None from the m_arg_names tuple, and if so, that means the overload does not accept a keyword arg in that position, so it rejects the overload.  This fixes the crash and works correctly across our codebase and testsuite.

If the patch looks good, it would be great to apply it and add the repro case to the test suite.

Thanks!

--- ./libs/python/src/object/function.cpp.orig	2013-07-22 17:38:54.000000000 -0700
+++ ./libs/python/src/object/function.cpp	2013-08-07 10:25:26.963988000 -0700
@@ -182,6 +182,16 @@
                             // Get the keyword[, value pair] corresponding
                             PyObject* kv = PyTuple_GET_ITEM(f->m_arg_names.ptr(), arg_pos);
 
+                            // If kv is None, this overload does not accept a
+                            // keyword argument in this position, meaning that
+                            // the caller did not supply enough positional
+                            // arguments.  Reject the overload.
+                            if (kv == Py_None) {
+                                PyErr_Clear();
+                                inner_args = handle<>();
+                                break;
+                            }
+
                             // If there were any keyword arguments,
                             // look up the one we need for this
                             // argument position

",amohr@…
8975,Throw exception on allocation failure in cpp_regex_traits::value,xpressive,Boost Development Trunk,To Be Determined,Bugs,Eric Niebler,new,2013-08-08T13:08:36Z,2013-08-08T13:08:36Z,"Sorry, I'm testing the correct handling of allocation failures currently.

STL streams have the annoying property, that they do not throw exceptions on allocation failures (std::bad_alloc). This can be changed by calling basic_stringstream::exceptions(std::ios::badbit).
This is not done in cpp_regex_traits.hpp line 565, causing, in my case, a unrelated exception (invalid quantifier).

See also #8966 for the same thing in lexical_cast.",Martin <martin.raiber@…>
8972,Doxygen \sa see also links are not passed to Quickbook C++ reference section.,quickbook,Boost Development Trunk,To Be Determined,Feature Requests,Steven Watanabe,new,2013-08-06T14:14:15Z,2013-08-06T14:14:15Z,"A Doxygen 'see also' item, for example, to a known function 

\sa sum(int, int) for a slightly useful function.

produces a Quickbook item

See also

sum(int, int) for a slightly useful function.

but the sum(int, int) is not the expected link (as in the Doxygen display).

Similarly for all other links that Doxygen will produce an autolink for.

It would be very nice to allow users to click to go straight to the 'See Also' item.",Paul A. Bristow
8971,-Wunused-local-typedefs warnings with GCC 4.8.1,multi_array,Boost Development Trunk,To Be Determined,Bugs,Ronald Garcia,new,2013-08-06T11:41:53Z,2013-12-07T11:25:23Z,"I'm getting many warnings ""-Wunused-local-typedefs"" when compiling with GCC 4.8.1 using the latest Boost SVN sources:

{{{
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp: In static member function ‘static void boost::multi_array_concepts::detail::idgen_helper<N>::call(Array&, const IdxGen&, Call_Type)’:
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp:42:43: warning: typedef ‘index_range’ locally defined but not used [-Wunused-local-typedefs]
       typedef typename Array::index_range index_range;
                                           ^
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp:43:37: warning: typedef ‘index’ locally defined but not used [-Wunused-local-typedefs]
       typedef typename Array::index index;
                                     ^
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp: In static member function ‘static void boost::multi_array_concepts::detail::idgen_helper<0ul>::call(Array&, const IdxGen&, Call_Type)’:
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp:53:43: warning: typedef ‘index_range’ locally defined but not used [-Wunused-local-typedefs]
       typedef typename Array::index_range index_range;
                                           ^
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array/concept_checks.hpp:54:37: warning: typedef ‘index’ locally defined but not used [-Wunused-local-typedefs]
       typedef typename Array::index index;
}}}

and

{{{
/mn/anatu/cma-u3/tmac/usr/include/boost/tuple/detail/tuple_basic.hpp: In function ‘typename boost::tuples::access_traits<typename boost::tuples::element<N, boost::tuples::cons<HT, TT> >::type>::const_type boost::tuples::get(const boost::tuples::cons<HT, TT>&)’:
/mn/anatu/cma-u3/tmac/usr/include/boost/tuple/detail/tuple_basic.hpp:228:45: warning: typedef ‘cons_element’ locally defined but not used [-Wunused-local-typedefs]
   typedef BOOST_DEDUCED_TYPENAME impl::type cons_element;
}}}

and

{{{
/mn/anatu/cma-u3/tmac/usr/include/boost/bind/arg.hpp: In constructor ‘boost::arg<I>::arg(const T&)’:
/mn/anatu/cma-u3/tmac/usr/include/boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs]
         typedef char T_must_be_placeholder[ I == is_placeholder<T>::value? 1: -1 ];
}}}",Torquil Sørensen <torquil@…>
8964,operator>> missing,units,Boost 1.54.0,To Be Determined,Feature Requests,Matthias Schabel,new,2013-08-04T20:46:36Z,2014-04-13T19:48:21Z,"boost/units/io.hpp defines operator<< but not operator>>.

As a result, dimensionful quantities can be written but not read. This is a serious problem.

Why would I want to use Boost::Units in the first place? Because I'd like to enter dimensionful quantities into my
program, then do some calculations, and have it output
dimensionful quantities.

The latter (i.e. output) works. But the former (i.e. input) is restricted to hardcoded parameters in my source file. If I move the data to a config file and try to read it, I face the problem that there is no operator>>.",pipping@…
8962,adjacency_list doesn't work with hash_setS,graph,Boost 1.54.0,To Be Determined,Bugs,Jeremiah Willcock,new,2013-08-04T00:44:16Z,2013-10-02T19:15:22Z,"When compiling under Clang (3.3 final), the following code results in a compile error due to template lookup failure.  It compiles cleanly under G++ 4.8.  Replacing hash_setS with setS allows the code to compile.

{{{
#include <boost/graph/adjacency_list.hpp>
#include <iostream>

int main(int argc, char* argv[]) {

    typedef boost::adjacency_list<boost::hash_setS, boost::vecS, boost::undirectedS > undirectedGraphT;
    undirectedGraphT G;
    boost::add_edge(1, 2, G);
    typedef boost::graph_traits <undirectedGraphT>::edge_descriptor Edge;
    Edge e;
    bool hasEdge{false};

    std::tie(e, hasEdge) = boost::edge(1, 2, G);

    std::cout << (hasEdge ? ""did "" : ""did not "") << ""find edge\n"";
}
}}}",Rob Patro <rob.patro@…>
8954,clang static analyser undefined value in boost/libs/filesystem/src/unique_path.cpp,filesystem,Boost 1.54.0,Boost 1.55.0,Bugs,Beman Dawes,new,2013-08-01T23:31:21Z,2014-07-28T10:23:18Z,"Assigned value is garbage or undefined at line 131.

Please https://ci.nedprod.com/job/Boost.AFIO%20Static%20Analysis%20Pre-Check/112/clangScanBuildBugs/? for more detail.",Niall Douglas
8952,numeric::interval::nth_root generates empty interval,interval,Boost 1.54.0,To Be Determined,Bugs,Boris Gubenko,new,2013-08-01T23:03:08Z,2013-08-01T23:03:08Z,"The attached code generates an empty interval when compiling to a 32 bits binary (i.e. passing the ""-m32"" flag to gcc) on a 64 bit machine (running Mac OS X). 

It works correctly when compiled to a 64 bits binary (i.e. omitting -m32).

",marco.v.correia@…
8951,Duplicate name of actual target: <pstage-gcc\lib>libboost_exception-mgw47-d-1_54.a,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-08-01T19:24:43Z,2013-08-01T20:36:55Z,"Hi,

I'm trying to build the boost library and I always get the error mentioned in the title.

First, I tried to build it with the default toolset which was Visual Studio and it worked but I cannot make it work with mingw gcc on Windows. I've followed the instructions on page http://www.boost.org/doc/libs/1_54_0/more/getting_started/windows.html#install-boost-build.

Thanks",houdelou@…
8948,iostreams::filtering_stream<outout>::sync does not exist,iostreams,Boost 1.54.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-07-31T17:17:00Z,2013-08-03T16:30:39Z,"The documentation here:

http://www.boost.org/doc/libs/1_54_0/libs/iostreams/doc/classes/filtering_stream.html#sync

claims it should exist; however, the attached code shows it only
exists for filtering_stream<input>.

This missing member function was mentioned in another ticket:

https://svn.boost.org/trac/boost/ticket/4590

but that one did not request the documentation be changed.",cppljevans
8946,filesystem::directory_iterator returns incorrect listing,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-07-31T09:07:41Z,2013-08-07T08:26:09Z,"Both '''directory_iterator''' and '''recursive_directory_iterator''' do not work correctly under linux with g++-4.7.3 : one item, assumed to be the last one, is not listed.

Simple code to reproduce the problem :
{{{
#include <iostream>
#include <stdio.h>
#include <boost/filesystem.hpp>

using namespace std;
namespace bfs = boost::filesystem;

int main () {
	system(""mkdir mydir"");
	system(""touch mydir/file1"");
	system(""touch mydir/file2"");
	bfs::directory_iterator bfs_dir_i_end;
	bfs::directory_iterator bfs_dir_i(""mydir/."");
	while (++bfs_dir_i != bfs_dir_i_end) {
		bfs::file_type type = (*bfs_dir_i).status().type();
		bfs::path source = (*bfs_dir_i).path();
		cout << source << ""  "" << type << endl;
	}
}
}}}

Build with :
{{{
g++-4.7.3 -I/usr/include/crypto++ -O0 -g3 -Wall -c -fmessage-length=0  -std=c++11 show_bug_directory_iterator.cpp
g++-4.7.3 -lboost_filesystem -o show_bug_directory_iterator show_bug_directory_iterator.o
}}}

Code result :
{{{
$ ./show_bug_directory_iterator
""mydir/./file1""  2
}}}

Should be :
{{{
$ ./show_bug_directory_iterator
""mydir/./file1""  2
""mydir/./file2""  2
}}}

Shell result :
{{{
$ ls -lR .
.:
total 1620
drwxr-xr-x 2 alain alain    4096 31 juil. 10:48 mydir
-rwxr-xr-x 1 alain alain  639766 31 juil. 10:48 show_bug_directory_iterator
-rw-r--r-- 1 alain alain     497 31 juil. 10:44 show_bug_directory_iterator.cpp
-rw-r--r-- 1 alain alain 1006376 31 juil. 10:48 show_bug_directory_iterator.o

./mydir:
total 0
-rw-r--r-- 1 alain alain 0 31 juil. 10:48 file1
-rw-r--r-- 1 alain alain 0 31 juil. 10:48 file2
}}}

Notes :
  1) Not tested under other gcc versions.

  2) Tested with same results on Boost 1.52.0 and 1.53.0

  3) suspected regression, cf [https://svn.boost.org/trac/boost/ticket/257]",l.alebarde@…
8945,managed_shared_memory::find  assertion,interprocess,Boost 1.54.0,To Be Determined,Support Requests,Ion Gaztañaga,new,2013-07-31T08:57:00Z,2016-02-12T05:32:15Z,"Hi,

I am using ubuntu 13.04 and the compilator is : g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
I have an application which successfully opened a shared memory (I checked with another client). The problem is, when a client of this shared memory tried to connect, the managed_shared_memory::find is blocking or throw the following error message (I don't know what cause my program to have one of this error rather than the other) :

''mosaique: /usr/local/include/boost/interprocess/segment_manager.hpp:871: void* boost::interprocess::segment_manager::priv_generic_find(const CharT*, IndexType >&, boost::interprocess::ipcdetail::in_place_interface&, boost::interprocess::segment_manager::size_type&, boost::interprocess::ipcdetail::true_, bool) [with CharT = char, CharType = char, MemoryAlgorithm = boost::interprocess::rbtree_best_fit, IndexType = boost::interprocess::iset_index, boost::interprocess::segment_manager::size_type = long unsigned int, boost::interprocess::ipcdetail::true_ = boost::interprocess::ipcdetail::bool_]: Assertion `(ctrl_data->m_value_bytes % table.size) == 0' failed. Aborted (core dumped)''

The size of my shared memory is : 9 953 280
Please help me fix this bug.

The sources :
The server  is managed in the main_shm_server.cpp file
The buggy client is main_mosaique.cpp It use the class SHMClient which is where the problem occur. The strange thing is when I use the same class with the same constructor parameter in another program, it is working.",bersac_1@…
8939,boot filesystem error when copy-overwrite-the file to itself,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-07-30T15:35:20Z,2013-07-30T15:52:40Z,"I'm running RedHat. I tried to copy, and overwrite if existing file 'a' to itself.

namespace fs=boost::filesystem;
fs::copyfile('a', 'a', fs::copy_option::overwrite_if_exist);

This clear the content of 'a', and giving me an empty file.
",hoangtrongminhtuan@…
8937,boost::asio::ip::tcp 5000ms stall,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-29T17:50:16Z,2013-09-24T18:18:06Z,"Under certain circumstances, the boost::asio::ip::tcp module exhibits a, with a bit of patience, reproducible behavior of every now and then stalling for quite exactly 5000ms.

On May 02, 2011, a discussion about this was started by Torben Wiggerich on the Boost Mailing List:
http://boost.2283326.n4.nabble.com/asio-Randomly-having-problems-reading-from-the-socket-td3490016.html

On May 09, 2011, a traffic dump was requested by Cliff Green.

I ran into the problem some time later and posted a traffic dump on Apr 02, 2012. No one has replied since.

Today, I tested whether the issue still persists with

Boost 1.49.0
Boost 1.53.0
Boost 1.54.0

and it still occurs with all of them.

For the CPU I used an Intel Core2 Duo P7350 @ 2.0 GHz, because this bug is only reproducible in a reasonable time frame (under 1 hour) on a sufficiently slow computer. Back then I used an Athlon X2 4400+. An i7 will be too fast to show this behavior reliably, or in a reasonable amount of time, or maybe even ever.

The operating system used was Windows 7 x64 SP1.

The compiler used was Visual Studio 2008 SP1 x86 + all updates from Windows Update.

I attached a Repro Case based on the code posted by Torben in the Thread. With this, on the Core2Duo I used, the behavior was repeatedly observable in under an hour of Server + Client running.",Florian George <fgeorge@…>
8936,month_iterator snaps-to-end when starting on the last day of a 30 day month,date_time,Boost 1.47.0,To Be Determined,Bugs,az_sw_dude,new,2013-07-29T17:31:03Z,2013-08-03T16:34:26Z,"I am using the month_iterator to iterate months, the snap-to-end works fine when I start on a month with 31 days, however if my start date is 2013-11-30 for example, when I iterate forward a month this becomes 2013-12-31. 
This is not what I expect as I never started on 31 and so it should go to 2013-12-30. 

I am using boost 1.47, are you aware of this behavior and has it been resolved in a later version?

Thanks",kieran.jeffrey-smart@…
8934,b2 : failed to write output file,build,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-07-28T12:06:27Z,2014-03-13T00:50:17Z,"Hello,

Executing b2.exe within cmd.exe or powershell :

and

Building boost_1_54_0 with : 

b2 --debug-building --prefix=%USERPROFILE%\pkg\indie\boost address-model=64 --exec-prefix=%USERPROFILE%\programs\boost --libdir=%USERPROFILE%\pkg\lib --includedir=%USERPROFILE%\pkg\include --build-type=complete --build-dir=..\tmp pch=off debug-symbols=on debug-store=database install 2>&1 >> ..\boostbuild.txt

results in an error :

failed to write output file '..\tmp\boost\bin.v2\libs\program_options\build\msvc-11.0\release\address-model-64\debug-store-database\debug-symbols-on\link-static\pch-off\runtime-link-static\threading-multi\libboost_program_options-vc110-mt-s-1_54.lib.rsp'!

My initial thoughts path name is it approaching the MAX_PATH, so I tried redirecting echo to the name file within cmd.exe; it resulted in The system cannot find the path specified.

In powershell, echo redirection was successful but the build still failed at the same point.

The full path length is 246 :
python -c ""print(len(r'C:\Users\Arkhe_2\pkg\src\tmp\boost\bin.v2\libs\program_options\build\msvc-11.0\release\address-model-64\debug-store-database\debug-symbols-on\link-static\pch-off\runtime-link-static\threading-multi\libboost_program_options-vc110-mt-s-1_54.lib.rsp'))""

File system is NTFS located on a usb interconnected hard drive.

Thanks for the great work.






",jeffrey.beu.uz8yz6yl@…
8928,Build failed boost 1.54 on Mac with zlib source (-sZLIB_SOURCE) with clang and c++11,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-07-25T15:21:28Z,2013-07-25T15:25:17Z,"build fail where compile zlib source in build.v2/standalone/zlib.
It is because cxxflags are provided even if compile c source code by clang++ -x c.

{{{
    ""clang++"" -x c -O3 -fPIC -std=c++11 -stdlib=libc++ -O3 -finline-functions -Wno-inline -Wall -DNDEBUG -I""/opt/work/zlib-1.2.8"" -c -o ""bin.v2/standalone/zlib/clang-darwin-4.2.1/release/link-static/threading-multi/adler32.o"" ""/opt/work/zlib-1.2.8/adler32.c""

error: invalid argument '-std=c++11' not allowed with 'C/ObjC'
}}}

{{{
./b2 -d2 -sZLIB_SOURCE=/opt/work/zlib-1.2.8 link=shared,static toolset=clang cxxflags=-std=c++11 cxxflags=-stdlib=libc++ cxxflags=-fPIC cxxflags=""-arch x86_64"" linkflags=-stdlib=libc++ linkflags=-headerpad_max_install_names linkflags=""-arch x86_64""
}}}

{{{
Mac OS X 10.8.4
% clang --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
}}}",Tetsuya Hayashi <tetsu.h@…>
8926,Windows error messages used for errno codes,system,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-07-25T08:10:06Z,2013-09-17T10:04:08Z,"Consider the following:
{{{
using namespace boost::system;
system_error e(errc::resource_unavailable_try_again, system_category());
std::cout << e.what() << std::endl;
}}}
This should print something along the lines of ""Resource unavailable"", but instead it prints ""An attempt was made to load a program with an incorrect format"".

The value of `errc::resource_unavailable_try_again` is 11, or `EAGAIN`.  What is printed, however, is the message for the Windows system error code `ERROR_BAD_FORMAT`, which is also 11.

I encountered this while using boost::thread.  I got the above message when I ran out of memory during thread creation.",Lars T. Kyllingstad <lars.kyllingstad@…>
8923,boost/detail/lightweight_thread.hpp: Ignores failures from WaitForSingleObject,smart_ptr,Boost 1.54.0,To Be Determined,Bugs,Peter Dimov,new,2013-07-25T05:46:26Z,2014-09-16T05:46:03Z,"boost/detail/lightweight_thread.hpp ignores failures from WaitForSingleObject. There's not much point in closing the handle if the wait failed due to ERROR_INVALID_HANDLE.

At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.
",Jeffrey Walton <noloader@…>
8922,boost/asio/detail/wince_thread.hpp: Ignores failures from WaitForSingleObject,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:44:10Z,2013-07-25T05:44:10Z,"boost/asio/detail/wince_thread.hpp ignores failures from WaitForSingleObject.

At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.
",Jeffrey Walton <noloader@…>
8921,boost/asio/detail/win_event.hpp: Ignores failures from WaitForSingleObject,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:42:53Z,2013-07-25T05:42:53Z,"boost/asio/detail/win_event.hpp ignores failures from WaitForSingleObject. There's not much point in locking if the wait failed since your not in an expected state.

At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.",Jeffrey Walton <noloader@…>
8920,boost/asio/detail/impl/win_thread.ipp: Ignores failures from WaitForSingleObject and WaitForMultipleObjects,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:40:28Z,2013-07-25T05:40:28Z,"boost/asio/detail/impl/win_thread.ipp ignores failures from WaitForSingleObject and WaitForMultipleObjects.

At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.",Jeffrey Walton <noloader@…>
8919,boost/asio/detail/impl/win_static_mutex.ipp: Ignores failures from WaitForSingleObject,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:38:09Z,2013-07-25T05:38:09Z,"boost/asio/detail/impl/win_static_mutex.ipp ignores failures from WaitForSingleObject.

At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.",Jeffrey Walton <noloader@…>
8918,boost/asio/detail/impl/win_iocp_io_service.ipp: Ignores failures from WaitForSingleObject,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T05:33:06Z,2013-07-25T05:33:06Z,"boost/asio/detail/impl/win_iocp_io_service.ipp ignores failures from WaitForSingleObject. There's not much point in looping if its just going to fail again.

At minimum (as a user), I would expect Boost to use BOOST_ASSERT with an appropriate exception in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.",Jeffrey Walton <noloader@…>
8913,boost/asio/detail/posix_static_mutex.hpp: Ignores all failures from pthread_* functions,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-25T04:25:37Z,2013-07-25T04:25:37Z,"boost/asio/detail/posix_static_mutex.hpp ignores nearly all failures from pthread_* functions. Functions include pthread_mutex_lock and pthread_mutex_unlock.

A lock failure is usually a bad thing, and I can't come up with scenarios where a silent failure is desired. It will make a bad problem worse by corrupting data or terminating the program.

At minimum (as a user), I would expect for Boost to use BOOST_ASSERT in debugging and diagnostic builds; and BOOST_VERIFY with an appropriate exception for release or production builds.

Perhaps it would be a good idea to use boost/thread/pthread/mutex.hpp. It appears to be more mature and have a bit more stability. In addition, it throws lock exceptions where appropriate.",Jeffrey Walton <noloader@…>
8893,Documentation Error,signals,Boost 1.54.0,To Be Determined,Patches,Douglas Gregor,new,2013-07-24T09:38:17Z,2013-08-04T07:55:17Z,"Hello, 

Sorry for making a ticket here, I didn't know where to report this.  Please forward to the right people.

There's an error in the solution (code) proposed here:

http://www.boost.org/doc/libs/1_54_0/doc/html/signals/s04.html

Towards the end of the code:
// Restore the macro definition of ""signals"", as it was
// defined by Qt's <qobjectdefs.h>.
#  define signals protected

that #define statement should be changed to

#  define signals public

Otherwise, it works on GCC, but does not work on Visual C++, as VC++ compiler will produce a different symbol (after name mangling), and the linker will report errors

Otherwise, the solution works great.  Thanks a million for having it!

If you need to get a hold of me, you can reach me at pm@privacyprotector.eu

Pawel Mroszczyk


",anonymous
8889,Boost.Build MSVC fix building PDBs,build,Boost 1.54.0,To Be Determined,Bugs,Vladimir Prus,new,2013-07-23T15:03:50Z,2013-07-23T15:03:50Z,"Currently emitting debug information to PDBs works with a rather limited set of conditions only. Most importantly, static libs can't be compiled if debug-store=database is requested. The attached patch rectifies this deficiency.

The hardest part was to get around problems with precompiled headers. I got it eventually.

What's still missing:
 * port the changes over to msvc.py. Python is completely out of my knowledge domain so I decided to stay away from this file.
 * No matter what I tried, I found no way to move the generated PDBs from the build directories to the output directory alongside the libraries.
",Daniela Engert <dani@…>
8888,[python] GCC 4.8+ warns about unused local typedef,python USE GITHUB,Boost 1.54.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-07-23T14:31:41Z,2015-04-29T11:34:30Z,"During the build of Boost, GCC warns about several unused typedefs in Boost.Python.  There are many of these that seem like they should be converted to BOOST_STATIC_ASSERT, like this one for example.
{{{
./boost/python/cast.hpp:73:20: warning: typedef 'must_be_a_complete_type' locally defined but not used [-Wunused-local-typedefs]
       typedef char must_be_a_complete_type[sizeof(T)];
}}}
There's at least one other instance of this problem that I know of.  Shall I prepare a patch for this, or is this undesirable for some reason?

In the mean time, I'm attaching a patch for another one.",Petr Machata <pmachata@…>
8886,boost::posix_time::time_from_string has no parameter for ymd order,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-07-23T12:20:16Z,2013-07-23T12:20:16Z,"Function boost::posix_time::time_from_string(const std::string& s) calls parse_date and parse_delimited_time_duration for two parts of datetime string. Function parse_date(const std::string& s, int order_spec = ymd_order_iso) has parameter for ymd order, but time_from_string hasn't. Therefore impossible to parse dates like ""11.09.2001 08:46:26"".",anonymous
8885,"boost asio epoll reactor method ""set_ready_events"" not protected by lock",asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-23T09:59:10Z,2013-07-23T10:30:39Z,"Suggested patch:
Index: boost/asio/detail/epoll_reactor.hpp
===================================================================
--- boost/asio/detail/epoll_reactor.hpp	(Revision 85130)
+++ boost/asio/detail/epoll_reactor.hpp	(Arbeitskopie)
@@ -64,7 +64,12 @@
     bool shutdown_;
 
     BOOST_ASIO_DECL descriptor_state();
-    void set_ready_events(uint32_t events) { task_result_ = events; }
+
+    void set_ready_events(uint32_t events) { 
+      mutex::scoped_lock lock(mutex_);
+      task_result_ = events;
+    }
+
     BOOST_ASIO_DECL operation* perform_io(uint32_t events);
     BOOST_ASIO_DECL static void do_complete(
         io_service_impl* owner, operation* base,
",carsten.becker@…
8884,boost asio in posix_event: lock release before condition signaled,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-23T09:47:28Z,2014-06-30T14:34:51Z,"valgrind drd warns about a possible race condition ...
(possible patch:)

Index: boost/asio/detail/posix_event.hpp
===================================================================
--- boost/asio/detail/posix_event.hpp	(Revision 85130)
+++ boost/asio/detail/posix_event.hpp	(Arbeitskopie)
@@ -58,8 +58,8 @@
   {
     BOOST_ASIO_ASSERT(lock.locked());
     signalled_ = true;
+    ::pthread_cond_signal(&cond_); // Ignore EINVAL.
     lock.unlock();
-    ::pthread_cond_signal(&cond_); // Ignore EINVAL.
   }
 
   // Reset the event.

",carsten.becker@…
8871,[numeric] GCC 4.8+ warns about unused local typedef,numeric,Boost 1.54.0,To Be Determined,Bugs,Douglas Gregor,new,2013-07-22T15:06:20Z,2013-07-22T15:06:20Z,"As a side effect of running Boost.Math test suite, I found out that GCC warned about several unused typedefs.  None of these appear to serve a purpose, so I propose to remove them.",Petr Machata <pmachata@…>
8867,Provide socket options for TCP keepalive configuring,asio,Boost 1.54.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-07-21T17:24:44Z,2013-07-21T17:24:44Z,"Please, provide socket options in asio::ip::tcp to configure TCP keepalive behavior, like described in section 4.2 [http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/ here]. E.g. the following typedefs will suffice:

{{{
typedef boost::asio::detail::socket_option::integer< SOL_TCP, TCP_KEEPIDLE > keepalive_idle_time;
typedef boost::asio::detail::socket_option::integer< SOL_TCP, TCP_KEEPINTVL > keepalive_interval;
typedef boost::asio::detail::socket_option::integer< SOL_TCP, TCP_KEEPCNT > keepalive_probes;
}}}
",Andrey Semashev
8865,comparison of unsigned expression warning,property_tree,Boost 1.53.0,To Be Determined,Bugs,Sebastian Redl,new,2013-07-20T17:45:35Z,2013-07-20T17:45:35Z,"Building with -Werror and -Wtype-limits gives this warning:

{{{
boost/property_tree/detail/ptree_utils.hpp:76:13: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
}}}

",alex@…
8863,BOOST_ATTRIBUTE_NORETURN causes stack pointer corruption,exception,Boost 1.49.0,To Be Determined,Bugs,Emil Dotchevski,new,2013-07-19T21:36:57Z,2016-04-20T07:15:52Z,"Hello,
i ran into a strange problem with a very small project of mine. Whenever an exception is thrown in a boost package using boost::throw_exception and my program terminates (no exceptions are beeing catched yet) i get a message box saying:

    Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call ...

I was able to track this down to the BOOST_ATTRIBUTE_NORETURN declaration of boost::throw_exception. When i remove this from a copy of this function, the problem disappears.

I am compiling with the following settings:
- Compiler: MS Visual Studio C++ 2010 Express
- Multithreading: yes
- Runtime-linking: static
- Build-type: debug

My minimal test-program looks like this:

  #include ""boost/throw_exception.hpp""
  
  int main(int argc, char* argv[])
  {
    boost::throw_exception(std::exception(""foo"")); // <-- this will produce the problem
  
    return 0;
  }

I originally asked about the problem here: http://stackoverflow.com/questions/17599772/boost-exceptions-lead-to-stack-pointer-corruption-run-time-check-failure-0",Janosch <gagabla0@…>
8861,boost 1.39 io_service_pool accept hangs,asio,Boost 1.39.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-19T14:18:07Z,2013-07-19T14:26:56Z,"O.S.: Centos 5.4 64 bit
Boost version: 1.39
Symptom: With io_service-per-CPU and thread pool size 4, after the sever accepted at 8th connection, it cannot accept any connections afterwards.

How to reproduce it:
(1) Get the server2 example at http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/example/http/server2/

(2) Modify connection.cpp to support persistent connection:
void connection::handle_write(const boost::system::error_code& e)
{
  if (!e)
  {
    // Initiate graceful connection closure.
    //boost::system::error_code ignored_ec;
    //socket_.shutdown(boost::asio::ip::tcp::socket::shutdown_both, ignored_ec);
    start();
  }

(3) Modify the server.cpp to use different acceptor_ constructor
server::server(const std::string& address, const std::string& port,
    const std::string& doc_root, std::size_t io_service_pool_size)
  : io_service_pool_(io_service_pool_size),
//    acceptor_(io_service_pool_.get_io_service()),
    acceptor_( io_service_pool_.get_io_service(),
           boost::asio::ip::tcp::endpoint(boost::asio::ip::tcp::v4(), atoi(port.c_str()))),

    new_connection_(new connection(
          io_service_pool_.get_io_service(), request_handler_)),

    request_handler_(doc_root)
{
  // Open the acceptor with the option to reuse the address (i.e. SO_REUSEADDR).

/*
  boost::asio::ip::tcp::endpoint endpoint(boost::asio::ip::tcp::v4(), 1025);
  acceptor_.open(endpoint.protocol());
  acceptor_.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true));
  acceptor_.bind(endpoint);
  acceptor_.listen();
*/
  acceptor_.async_accept(new_connection_->socket(),
      boost::bind(&server::handle_accept, this,
        boost::asio::placeholders::error));
}

(4) The client test harness create threads each second. In the thread, it will connect to the server, send a request and receive the response (both request/response should be small enough for one read/write). After that, the thread will sleep 1000 seconds without closing the connection.

(5) The server cannot accept any connections after 8th requests.


",bill <shuzhouliu@…>
8857,Compile error in boost range when trying to use boost string split,algorithm,Boost 1.54.0,To Be Determined,Bugs,Marshall Clow,new,2013-07-18T22:26:23Z,2013-08-12T17:20:29Z,"I am trying to replace some old string split code with the string split algorithm, but am getting compile errors. OS CentOs 6.3, Boost 1.53 and 1.54 gcc 4.8.1 without -std=c++ parameter. I have done an extensive search and tried multiple possible fixes and the error still occurs.

Here is the error:

In file included from /opt/boost_1_53/boost/range/concepts.hpp:21:0,
                 from XXXX.C:37:
/opt/boost_1_53/boost/range/begin.hpp: In instantiation of 'typename boost::range_iterator<C>::type boost::range_detail::range_begin(C&) [with C = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]':
/opt/boost_1_53/boost/range/begin.hpp:119:27:   required from 'typename boost::range_iterator<const T>::type boost::range_adl_barrier::begin(const T&) [with T = boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/iterator_range_core.hpp:56:64:   required from 'static IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_begin(ForwardRange&) [with ForwardRange = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; IteratorT = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/iterator_range_core.hpp:198:45:   required from 'boost::iterator_range<IteratorT>::iterator_range(const Range&, boost::iterator_range_detail::const_range_tag) [with Range = boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; IteratorT = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/iterator_range_core.hpp:564:63:   required from 'boost::iterator_range<typename boost::range_iterator<const T>::type> boost::make_iterator_range(const ForwardRange&) [with ForwardRange = boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/as_literal.hpp:93:50:   required from 'boost::iterator_range<typename boost::range_iterator<C>::type> boost::range_detail::make_range(T&, long int) [with T = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/as_literal.hpp:109:74:   required from 'boost::iterator_range<typename boost::range_iterator<const T>::type> boost::as_literal(const Range&) [with Range = boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/algorithm/string/iter_find.hpp:153:115:   required from 'SequenceSequenceT& boost::algorithm::iter_split(SequenceSequenceT&, RangeT&, FinderT) [with SequenceSequenceT = std::vector<std::basic_string<char> >; RangeT = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; FinderT = boost::algorithm::detail::token_finderF<boost::algorithm::detail::is_any_ofF<char> >]'
/opt/boost_1_53/boost/algorithm/string/split.hpp:149:69:   required from 'SequenceSequenceT& boost::algorithm::split(SequenceSequenceT&, RangeT&, PredicateT, boost::algorithm::token_compress_mode_type) [with SequenceSequenceT = std::vector<std::basic_string<char> >; RangeT = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; PredicateT = boost::algorithm::detail::is_any_ofF<char>]'
XXXX.C:1287:60:   required from here
/opt/boost_1_53/boost/range/begin.hpp:49:24: error: 'const struct boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >' has no member named 'begin'
         return c.begin();
                        ^
make[2]: Leaving directory `/for_blair/workspace/bluemax3/libcommon/src/common'
In file included from /opt/boost_1_53/boost/range/concepts.hpp:22:0,
                 from XXXX.C:37:
/opt/boost_1_53/boost/range/end.hpp: In instantiation of 'typename boost::range_iterator<C>::type boost::range_detail::range_end(C&) [with C = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]':
/opt/boost_1_53/boost/range/end.hpp:113:25:   required from 'typename boost::range_iterator<const T>::type boost::range_adl_barrier::end(const T&) [with T = boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/iterator_range_core.hpp:62:62:   required from 'static IteratorT boost::iterator_range_detail::iterator_range_impl<IteratorT>::adl_end(ForwardRange&) [with ForwardRange = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; IteratorT = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
make[1]: Leaving directory `/for_blair/workspace/bluemax3/libcommon/src'
/opt/boost_1_53/boost/range/iterator_range_core.hpp:198:74:   required from 'boost::iterator_range<IteratorT>::iterator_range(const Range&, boost::iterator_range_detail::const_range_tag) [with Range = boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; IteratorT = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/iterator_range_core.hpp:564:63:   required from 'boost::iterator_range<typename boost::range_iterator<const T>::type> boost::make_iterator_range(const ForwardRange&) [with ForwardRange = boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/as_literal.hpp:93:50:   required from 'boost::iterator_range<typename boost::range_iterator<C>::type> boost::range_detail::make_range(T&, long int) [with T = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/range/as_literal.hpp:109:74:   required from 'boost::iterator_range<typename boost::range_iterator<const T>::type> boost::as_literal(const Range&) [with Range = boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<const T>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]'
/opt/boost_1_53/boost/algorithm/string/iter_find.hpp:153:115:   required from 'SequenceSequenceT& boost::algorithm::iter_split(SequenceSequenceT&, RangeT&, FinderT) [with SequenceSequenceT = std::vector<std::basic_string<char> >; RangeT = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; FinderT = boost::algorithm::detail::token_finderF<boost::algorithm::detail::is_any_ofF<char> >]'
/opt/boost_1_53/boost/algorithm/string/split.hpp:149:69:   required from 'SequenceSequenceT& boost::algorithm::split(SequenceSequenceT&, RangeT&, PredicateT, boost::algorithm::token_compress_mode_type) [with SequenceSequenceT = std::vector<std::basic_string<char> >; RangeT = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; PredicateT = boost::algorithm::detail::is_any_ofF<char>]'
XXXX.C:1287:60:   required from here
/opt/boost_1_53/boost/range/end.hpp:50:26: error: 'const struct boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >' has no member named 'end'
             return c.end();
                          ^
In file included from /opt/boost_1_53/boost/range/concepts.hpp:21:0,
                 from XXXX.C:37:
/opt/boost_1_53/boost/range/begin.hpp: In function 'typename boost::range_iterator<C>::type boost::range_detail::range_begin(C&) [with C = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]':
/opt/boost_1_53/boost/range/begin.hpp:50:5: warning: control reaches end of non-void function [-Wreturn-type]
     }
     ^
In file included from /opt/boost_1_53/boost/range/concepts.hpp:22:0,
                 from XXXX.C:37:
/opt/boost_1_53/boost/range/end.hpp: In function 'typename boost::range_iterator<C>::type boost::range_detail::range_end(C&) [with C = const boost::sub_match<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> > >; typename boost::range_iterator<C>::type = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >]':
/opt/boost_1_53/boost/range/end.hpp:51:9: warning: control reaches end of non-void function [-Wreturn-type]
         }
         ^",Blair Jennings <blair.jennings@…>
8856,[date_time] GCC 4.8+ warns unused local typedef...,date_time,Boost 1.54.0,To Be Determined,Bugs,az_sw_dude,new,2013-07-18T20:11:35Z,2014-03-12T16:46:08Z,"GCC 4.8+ warns unused local typedef... 

{{{ 
posix_time_io.hpp:50
typedef ‘std_ptime_facet’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
posix_time_io.hpp:117
typedef ‘std_time_facet’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
posix_time_io.hpp:183
typedef ‘std_ptime_facet’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
local_time_io.hpp:39
typedef ‘std_time_facet’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
local_time_io.hpp:126
typedef ‘std_time_facet’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
date_parsing.hpp:116
typedef ‘year_type’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
date_parsing.hpp:163
typedef ‘year_type’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
string_convert.hpp:24
typedef ‘input_type’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
strings_from_facet.hpp:38
typedef ‘ostream_type’ locally defined but not used [-Wunused-local-typedefs]
}}}

{{{
strings_from_facet.hpp:89
typedef ‘ostream_type’ locally defined but not used [-Wunused-local-typedefs]
}}}

Proposed fix attached.",Chris Stylianou <chris5287@…>
8853,[tuple] GCC 4.8+ warns unused local typedef...,tuple,Boost 1.54.0,To Be Determined,Bugs,Joel de Guzman,new,2013-07-18T19:12:38Z,2013-07-18T19:12:38Z,"GCC 4.8+ warns unused local typedef... 

{{{ 
typedef ‘cons_element’ locally defined but not used [-Wunused-local-typedefs] 
}}}

Proposed fix attached.",Chris Stylianou <chris5287@…>
8841,Duplicated rules for mpi.so with MPI support when building both single and multi-threaded flavors,mpi,Boost 1.54.0,To Be Determined,Bugs,Matthias Troyer,new,2013-07-18T06:19:23Z,2016-06-26T00:06:55Z,"When building with all library variants including single and multi-threading as well as static and shared libraries, if ""--with-mpi"" is specified it will complain about duplicated rules for mpi.so. The build log is attached.",Xiyue Deng <manphiz@…>
8836,boost::property_tree and BOM,property_tree,Boost 1.54.0,To Be Determined,Bugs,Sebastian Redl,new,2013-07-17T11:47:58Z,2013-07-17T11:47:58Z,"boost::property_tree::ptree can't handle files with BOM (at least for UTF-8).

{{{
#include <boost/filesystem.hpp>
#include <boost/property_tree/ini_parser.hpp>

#include <cstdlib>
#include <iostream>

int main()
{
    try
    {
        boost::filesystem::path path(""helper.ini"");
        boost::property_tree::ptree pt;
        boost::property_tree::read_ini(path.string(), pt);
        const std::string foo = pt.get<std::string>(""foo"");
        std::cout << foo << '\n';
    }
    catch (const boost::property_tree::ini_parser_error& e)
    {
        std::cerr << ""An error occurred while reading config file: "" << e.what() << '\n';
        return EXIT_FAILURE;
    }
    catch (const boost::property_tree::ptree_bad_data& e)
    {
        std::cerr << ""An error occurred while getting options from config file: "" << e.what() << '\n';
        return EXIT_FAILURE;
    }
    catch (const boost::property_tree::ptree_bad_path& e)
    {
        std::cerr << ""An error occurred while getting options from config file: "" << e.what() << '\n';
        return EXIT_FAILURE;
    }
    catch (...)
    {
        std::cerr << ""Unknown error \n"";
        return EXIT_FAILURE;
    }
}
}}}

'''helper.ini'''

foo=str

'''Output'''

An error occurred while getting options from config file: No such node (foo)",nikita.trophimov@…
8835,failed to use boost::asio::steady_timer w/ clang 3.3,asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-17T11:24:25Z,2013-07-17T11:35:38Z,"boost::asio definitely has incorrect detection of <crono> availability for clang 3.3.
despite the attached sample code compiled well, any attempt to use boost::asio::steady_timer (w/ defined -DBOOST_ASIO_DISABLE_BOOST_CHRONO (to force it to use std::chrono instead) leads to a bunch of errors...
",i.zaufi@…
8831,Reuse capacity from user containers in order to prevent superfluous allocations,string_algo,Boost 1.54.0,To Be Determined,Feature Requests,Marshall Clow,new,2013-07-16T20:08:24Z,2013-07-16T20:08:24Z,"Inside boost::algorithm::split, new variable of container type is created, and then swapped with result when fully filled.

See http://www.boost.org/doc/libs/1_54_0/boost/algorithm/string/iter_find.hpp , there is code like:

{{{
SequenceSequenceT Tmp(itBegin, itEnd);
Result.swap(Tmp);
}}}

Maybe that was done in pursuit of strong exception safety guarantee - but I don't see much value for it in that case, because split is supposed to replace values in original container - https://svn.boost.org/trac/boost/ticket/5915 . I think basic guarantee would be enough.

Often SequenceSequenceT is container like std::vector, which already has capacity from previous usages, which can be reused avoiding costly allocations. For example:

{{{
Result.assign(itBegin, itEnd);
}}}

Maybe that would require stricter requirements on SequenceSequenceT, or maybe overload or traits specialization can be used for common things like std::vector and boost::container::vector or as customization point.

Here is proof-of-concept which avoids allocations showing speed difference: http://coliru.stacked-crooked.com/view?id=bf5dd9f2d9d20d61470e73a6b2940333-9a9914b3e2b7ed07c206d6accecccdb6

On my machine I have following results:
{{{
start
end
0.85 s

64000000
start
end
1.55 s

64000000
}}}

I.e. version with allocations is ~1.8x slower.

Maybe other algorithms have similar issues - I haven't checked.",Evgeny Panasyuk <evgeny.panasyuk@…>
8830,"fix spelling of ""polynomial"" in crc library and documentation",crc,Boost 1.54.0,To Be Determined,Bugs,Daryle Walker,new,2013-07-16T14:45:43Z,2013-07-16T14:45:43Z,"The word ""polynomial"" is incorrectly spelled ""polynominal"" in quite a number of places in both the code and documentation.  This has the unhappy effect of forcing users of the library to misspell a word to use some aspects of the otherwise very useful code.  A patch is attached that corrects all occurrences in library, test code and documentation.",Ed Beroset <beroset@…>
8828,bug in boost_asio/example/cpp03/http/server3/server.cpp,asio,Boost 1.54.0,Boost 1.55.0,Bugs,chris_kohlhoff,new,2013-07-16T09:19:38Z,2013-09-07T20:06:32Z,"please help check the doc/html/boost_asio/example/cpp03/http/server3/server.cpp
I think there is some bug in line 56 and line 69.
in line 56, ""&boost::asio::io_service::run"" is ambitious, because the there are two ""run()"" function in class ""io_service""
in line 69, it seems the parameter type is not correct, I can not compile this line.
",lisendong@…
8822,issues compiling regex on SunOS 5.9 sparc,hash,Boost 1.54.0,To Be Determined,Bugs,Daniel James,new,2013-07-15T11:19:39Z,2013-10-06T08:02:37Z,"./b2 toolset=sun -d+2 address-model=64 threading=multi link=static runtime-link=static variant=debug regex

    ""CC"" +d -library=stlport4 -g -mt -erroff=%none -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1 -I""."" -I""/usr/include"" -c -o ""bin.v2/libs/regex/build/sun/debug/address-model-64/link-static/runtime-link-static/stdlib-sun-stlport/threading-multi/cregex.o"" ""libs/regex/build/../src/cregex.cpp""

CC: Warning: Option -m64 passed to ld, if ld is invoked, ignored otherwise
""./boost/functional/hash/detail/hash_float.hpp"", line 99: Error: complex expression not allowed in dependent template argument expression.
""./boost/functional/hash/detail/hash_float.hpp"", line 113: Error: complex expression not allowed in dependent template argument expression.
""./boost/functional/hash/detail/hash_float.hpp"", line 126: Error: complex expression not allowed in dependent template argument expression.
""./boost/functional/hash/detail/hash_float.hpp"", line 139: Error: complex expression not allowed in dependent template argument expression.
4 Error(s) detected.

Other files are also affected.

Regards, Gert",Gert Grossmann <gert.grossmann@…>
8821,bootstrap build.bat fails for vc11 toolset,Building Boost,Boost Development Trunk,To Be Determined,Bugs,,new,2013-07-14T20:13:30Z,2013-07-14T20:13:30Z,"Changes were made to tools/build/v2/engine/build.bat to support vc12.  While I don't see anything obviously wrong with those changes, it causes my vc11 bootstrap to fail.  If I update that file to it's previous revision, then bootstrapping succeeds.",Richard <legalize@…>
8820,Reduce debug symbols size,spirit,Boost 1.54.0,To Be Determined,Bugs,Joel de Guzman,new,2013-07-14T18:08:47Z,2013-07-15T03:48:41Z,"There is [http://thread.gmane.org/gmane.comp.lib.boost.devel/242660 this ] discussion on Boost developers mailing list concerning Boost.Log compiled binary sizes. The problem by a large degree is caused by Boost.Spirit generating lots of debug info in the compiled libraries. I came to this conclusion by analyzing the object file sizes of Boost.Log (I've presented the object sizes in [http://article.gmane.org/gmane.comp.lib.boost.devel/242699 this] post, and you can see that the most part if the libboost_log_setup-vc110-mt-gd-1_55.lib library is occupied by parsers).

The parsers in question are implemented in libs/log/src/filter_parser.cpp and formatter_parser.cpp. I'm not sure if there's anything I can do on Boost.Log side to mitigate the problem, other than to just rewrite them without Boost.Spirit. However, this example and my other general experience with Boost.Spirit indicates that Boost.Spirit tends to generate lots of debug info even for parsers of moderate complexity (like the ones in Boost.Log). I would really like something to be done about this.
",Andrey Semashev
8818,Python compilation errors with mingw w64/gcc4.8.1,python USE GITHUB,Boost Development Trunk,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-07-13T20:38:47Z,2013-07-13T21:13:32Z,"wrap_python is suppose to undef the evil hypot def by Python, but it doesn't work for mingw w64. Here's a patch which undefs hypot if it's defined at all.

This unfortunately does not fix all boost python compilation errors with Mingw w64/gcc4.8.1 (targetting x64 Windows).",Andrew Ho <helloworld922@…>
8816,Android: error: fatal error: sys/statvfs.h: No such file or directory,filesystem,Boost 1.54.0,To Be Determined,Bugs,Beman Dawes,new,2013-07-12T11:13:48Z,2013-07-12T11:13:48Z,"Android doesn't have sys/statvfs.h. instead sys/vfs.h should be used.

possible fix (libs/filesystem/src/operations.cpp):

{{{
#   if !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__ANDROID__)
#     include <sys/statvfs.h>
#     define BOOST_STATVFS statvfs
#     define BOOST_STATVFS_F_FRSIZE vfs.f_frsize
#   else
#     ifdef __ANDROID__
#     include <sys/vfs.h>
#     endif
#     ifdef __OpenBSD__
#     include <sys/param.h>
#     endif
#     include <sys/mount.h>
#     define BOOST_STATVFS statfs
#     define BOOST_STATVFS_F_FRSIZE static_cast<boost::uintmax_t>(vfs.f_bsize)
#   endif
}}}
",mik01@…
8807,set_union adapter,range,Boost 1.54.0,To Be Determined,Feature Requests,Neil Groves,new,2013-07-10T03:15:20Z,2013-07-10T03:15:20Z,I was looking today for a range adapter that would take two sorted ranges with the same value type and present the union of those sets.  Seems like a natural fit for this library.,Dave Abrahams
8805,Getting error using Shell rule after upgrading to Ubuntu 12.04,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-07-10T00:12:33Z,2014-04-01T02:30:39Z,"I was happily doing development using bjam under the previous Ubuntu LTS release. I using package manager to upgrade to the 12.04 LTS release. Now my Jamfiles no longer work.
example:

SHELL ""mkdir -vp $(SOLUTION_ROOT)/log $(SOLUTION_ROOT)/conf"" ;

used to work just fine. Now I get an error

""*** argument error
* rule SHELL ( command : * )
* called with: (  )
* missing argument command""

I'm guessing that the previous bjam parsed the quote characters differently. I've tried various quoting schemes but can't get it to work. Any ideas/
",ccervo@…
8803,Unused parameter issue,parameter,Boost 1.54.0,To Be Determined,Bugs,Daniel Wallin,new,2013-07-09T11:36:57Z,2013-07-11T20:00:33Z,"When I set the compiler to the highest warning level and treat warnings as errors, lines 123 and 129 of the file boost/parameter/aux_/tagged_argument.hpp causes compilation failures.
",lcarreon@…
8800,result_of.hpp:174: error: invalid use of incomplete type,utility,Boost 1.54.0,To Be Determined,Bugs,No-Maintainer,new,2013-07-08T22:37:31Z,2013-07-08T22:37:31Z,"1. On OSX 10.8.4, invoke ""./b2 toolset=darwin -j 4""
2. Build fails with:

./boost/utility/result_of.hpp:174: error: invalid use of incomplete type ‘struct boost::log::v2_mt_posix::expressions::aux::unary_function_terminal<boost::log::v2_mt_posix::expressions::has_attribute<void> >::result<const boost::log::v2_mt_posix::expressions::aux::unary_function_terminal<boost::log::v2_mt_posix::expressions::has_attribute<void> > ()(boost::phoenix::vector2<boost::phoenix::vector2<const boost::phoenix::actor<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::log::v2_mt_posix::expressions::aux::unary_function_terminal<boost::log::v2_mt_posix::expressions::has_attribute<void> > >, 0l> >*, const boost::log::v2_mt_posix::attribute_value_set&>&, const boost::phoenix::default_actions&>)>’

3. According to ""l_r"" on the #boost IRC channel, he has also reproduced this issue on ""xLinux laptop 3.8.0-25-x86_64 x86_64 GNU/Linux, GCC 4.7.3""
4. I have set severity to ""Showstopper"" because there is no known workaround and Boost cannot be built.",cowwoc@…
8799,named condition notify_all does not wake up waiting process,interprocess,Boost 1.53.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-07-08T13:21:20Z,2014-10-24T09:28:58Z,"The underlying snippet never catches the notify_all() signal. Operating System used is Linux 3.5.0-17-generic.

Can anybody confirm this as a bug or am I doing something wrong?

=== Code snippet ===
{{{
#include <iostream>
#include <boost/interprocess/sync/named_condition.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <boost/interprocess/shared_memory_object.hpp>
#include <boost/interprocess/mapped_region.hpp>
#include <boost/version.hpp>
#include <sys/types.h>
#include <sys/wait.h>

using namespace std;
using namespace boost::interprocess;


void* consumer(void*)
{
    cout << ""Started child"" << endl;

    named_mutex mtx(create_only, ""somemutex"");
    named_condition signal_empty (create_only, ""signal_empty"");
    for(;;)
    {
        cout << ""Child tries to lock"" << endl;
        scoped_lock<named_mutex> lock(mtx);
        cout << ""Child got lock and waits"" << endl;
        signal_empty.wait(lock);
        cout << ""Child WOKE up"" << endl;
    }
    cout << ""Finished child"" << endl;
}

void* producer(void*)
{
    cout << ""Started parent"" << endl;
    sleep(1);
    named_mutex mtx(open_only, ""somemutex"");
    named_condition signal_empty (open_only, ""signal_empty"");

    for(;;)
    {
        cout << ""Parent tries to get lock"" << endl;
        scoped_lock<named_mutex>lock(mtx);
        cout << ""Parent got lock and notifies"" << endl;
        sleep(1);
        cout << ""Parent notifies child"" << endl;
        signal_empty.notify_all();
    }
}

int main(int argc, char** argv)
{
    pid_t pid = fork();

    if(pid == 0)
    {
        consumer(NULL);
    }
    else
    {
        producer(NULL);
    }
}
}}}


=== Application output ===
{{{
Started parent
Started child
Child tries to lock
Child got lock and waits
Parent tries to get lock
Parent got lock and notifies
Parent notifies child
Parent tries to get lock
Parent got lock and notifies
.....
}}}",peter.knafl@…
8795,async_connect incorrectly reports success on failure,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2013-07-08T04:59:35Z,2017-08-04T08:25:12Z,"I've found a regression between 1.53 to 1.54; if you compile
boost/libs/asio/example/cpp11/chat/chat_client.cpp
and point it at a host and port that doesn't exist or refuses the connection, instead of coming back with an error, such as host not found or connection refused, it reports success (on the conversion to bool).  (you might want to embellish the example with a std::cout << error_code.message() << std::endl;)

This appears to be the case across Linux, Darwin, iOS and Android.

synchronous connect seems to work correctly (i.e., echo/blocking_tcp_echo_client.cpp)",benpope81@…
8787,The correct way to Configure Boost 1.54.0 on Mac OS X 10.8.4,Building Boost,Boost 1.54.0,To Be Determined,Support Requests,,new,2013-07-06T01:49:29Z,2013-07-23T14:20:54Z," I am a newby to the Boost Library and I have been trying stupidly , i guess ,without asking for help! I managed to compile successfully but could not link to my projects in Xcode 4.6.3. I want to use  Clang in the process instead of GCC 4.8.1 which the compilation picks up. I need to use a fool proof way and to learn to do correctly in future upgrades.
                 
        thank you.",zmukwa@…
8784,"boost.asio.ssl.stream.set_verify_callback use custom verification callback, always succeed.",asio,Boost 1.54.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-07-05T14:26:54Z,2013-09-26T07:25:52Z,"boost.asio.ssl.stream.set_verify_callback use custom verification callback, always succeed.
and in boost::asio::ssl::rfc2818_verification::operator() function, parameter preverified always 0.",Jackarain
8777,layout=system is always creating symbolic links,Building Boost,Boost 1.54.0,To Be Determined,Feature Requests,,new,2013-07-04T09:55:24Z,2013-07-04T09:55:24Z,"Currently, while building boost binary libraries using ""layout=system runtime-link=shared target-os=linux"", boost build always creates symbolic links without versioning pointing to the real shared libraries.

However, some filesystems don't support symbolic links.

There is anyway to ask to boost build to not create symbolic links and generate the shared libraries without versioning?

I'd like to have the same behavior as cross-building using x86_64-w64-mingw32, but for Linux.
",Augusto Cesar Righetto <augustorighetto@…>
8775,fusion transform and fold not respecting const-ness of the sequence,fusion,Boost Development Trunk,To Be Determined,Bugs,Joel de Guzman,new,2013-07-03T21:14:48Z,2013-07-07T23:44:29Z,"The following does not compile:

{{{
#include <boost/fusion/include/vector.hpp>
#include <boost/fusion/include/transform.hpp>
#include <boost/fusion/include/fold.hpp>
#include <boost/fusion/include/copy.hpp>
namespace fusion = boost::fusion;

struct F
{
    typedef int result_type;
    int operator()(int state, int & val) const
    {
        return state;
    }
};

struct G
{
    typedef int result_type;
    int operator()(int & val) const
    {
        return val;
    }
};

int main()
{
    fusion::vector<int, int> v(1,2);
    fusion::vector<int, int> v2;
    // fold does not respect constness
    fusion::fold(v, 42, F());
    // transform does not respect constness
    fusion::copy(fusion::transform(v, G()), v2);
}
}}}

In my opinion, it should.
",Eric Niebler
8771,Constructor of polymorphic archives,serialization,Boost 1.53.0,To Be Determined,Feature Requests,Robert Ramey,new,2013-07-03T10:51:35Z,2013-07-03T10:51:35Z,"The constructor of polymorphic_iarchive_route assumes that the wrapped archive takes a std::stream argument. While that may be the case for the current archives provided Boost.Serialization, it is not generally the case. I have some archives that takes two iterators (begin/end) instead.

Robert has suggested that the constructor should take an already constructed archive instead. That would solve my problem.",Bjorn Reese <breese@…>
8767,"named_function_params.hpp: Unused variable warnings: (weight_map, tag_namespace)",graph,Boost 1.53.0,To Be Determined,Bugs,Jeremiah Willcock,new,2013-07-03T00:05:49Z,2016-08-09T09:18:51Z,"Similar to bug https://svn.boost.org/trac/boost/ticket/6926, building Boost 1.53 with Xcode 4.6.3 gives many warnings like the following:

In file included from ...lib/../../../eos/mesh/face_graph.cpp:1:
In file included from ...lib/boost_1_53_0/boost/graph/connected_components.hpp:15:
In file included from ...lib/boost_1_53_0/boost/graph/depth_first_search.hpp:21:
...lib/boost_1_53_0/boost/graph/named_function_params.hpp:335:7: warning: unused variable '_weight_map' [-Wunused-variable]
      BOOST_BGL_DECLARE_NAMED_PARAMS
      ^
...lib/boost_1_53_0/boost/graph/named_function_params.hpp:63:5: note: expanded from macro 'BOOST_BGL_DECLARE_NAMED_PARAMS'
    BOOST_BGL_ONE_PARAM_CREF(weight_map, edge_weight) \
    ^
...lib/boost_1_53_0/boost/graph/named_function_params.hpp:334:45: note: expanded from macro 'BOOST_BGL_ONE_PARAM_CREF'
#define BOOST_BGL_ONE_PARAM_CREF(name, key) BOOST_PARAMETER_NAME(name)
                                            ^
...lib/boost_1_53_0/boost/parameter/name.hpp:139:9: note: expanded from macro 'BOOST_PARAMETER_NAME'
      , BOOST_PARAMETER_SIMPLE_NAME                                 \
        ^
note: (skipping 6 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
<scratch space>:113:1: note: expanded from macro '_'
_weight_map
^
...lib/boost_1_53_0/boost/parameter/name.hpp:110:53: note: expanded from macro 'BOOST_PARAMETER_BASIC_NAME'
    BOOST_PARAMETER_NAME_OBJECT(tag_namespace::tag, name)
                                                    ^
...lib/boost_1_53_0/boost/parameter/name.hpp:86:48: note: expanded from macro 'BOOST_PARAMETER_NAME_OBJECT'
       ::boost::parameter::keyword<tag> const& name                 \
                                               ^
",rmann@…
8766,is_iterator_category<Traversal> error,iterator,Boost 1.54.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-07-02T18:02:39Z,2013-10-15T13:21:28Z,"VC12 Preview

{{{
1>  Unknown compiler version - please run the configure tests and report the results
1>c:\vc\include\boost\iterator\detail\facade_iterator_category.hpp(166): error C2039: 'assert_not_arg' : is not a member of 'boost::mpl'
1>          c:\vc\include\boost\mpl\eval_if.hpp(41) : see reference to class template instantiation 'boost::detail::facade_iterator_category_impl<CategoryOrTraversal,ValueParam,Reference>' being compiled
1>          with
1>          [
1>              CategoryOrTraversal=boost::forward_traversal_tag
1>  ,            ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>  ,            Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &
1>          ]
1>          c:\vc\include\boost\iterator\detail\facade_iterator_category.hpp(193) : see reference to class template instantiation 'boost::mpl::eval_if<boost::detail::is_iterator_category<CategoryOrTraversal>,boost::mpl::identity<boost::forward_traversal_tag>,boost::detail::facade_iterator_category_impl<CategoryOrTraversal,ValueParam,Reference>>' being compiled
1>          with
1>          [
1>              CategoryOrTraversal=boost::forward_traversal_tag
1>  ,            ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>  ,            Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &
1>          ]
1>          c:\vc\include\boost\iterator\iterator_facade.hpp(104) : see reference to class template instantiation 'boost::detail::facade_iterator_category<CategoryOrTraversal,ValueParam,Reference>' being compiled
1>          with
1>          [
1>              CategoryOrTraversal=boost::forward_traversal_tag
1>  ,            ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>  ,            Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &
1>          ]
1>          c:\vc\include\boost\iterator\iterator_facade.hpp(620) : see reference to class template instantiation 'boost::detail::iterator_facade_types<Value,CategoryOrTraversal,Reference,Difference>' being compiled
1>          with
1>          [
1>              Value=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>  ,            CategoryOrTraversal=boost::forward_traversal_tag
1>  ,            Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &
1>  ,            Difference=ptrdiff_t
1>          ]
1>          c:\vc\include\boost\token_iterator.hpp(40) : see reference to class template instantiation 'boost::iterator_facade<boost::token_iterator<TokenizerFunc,Iterator,Type>,Type,boost::forward_traversal_tag,const Type &,ptrdiff_t>' being compiled
1>          with
1>          [
1>              TokenizerFunc=char_separator_type
1>  ,            Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>>
1>  ,            Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>          ]
1>          c:\vc\include\boost\date_time\date_parsing.hpp(132) : see reference to class template instantiation 'boost::token_iterator<TokenizerFunc,Iterator,Type>' being compiled
1>          with
1>          [
1>              TokenizerFunc=char_separator_type
1>  ,            Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>>
1>  ,            Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>>
1>          ]
1>          c:\vc\include\boost\date_time\gregorian\parsers.hpp(30) : see reference to function template instantiation 'date_type boost::date_time::parse_date<boost::gregorian::date>(const std::string &,int)' being compiled
1>          with
1>          [
1>              date_type=boost::gregorian::date
1>          ]
}}}",olafvdspek@…
8762,Boost.Build engine build fails with MinGW toolset,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-07-02T12:35:53Z,2013-10-26T21:02:16Z,"MinGW toolset and MSYS shell:

{{{
$ cd boost_1_54_0
$ ./bootstrap.sh --with-toolset=mingw
Building Boost.Build engine with toolset mingw...
Failed to build Boost.Build build engine
Consult 'bootstrap.log' for more details
}}}

bootstrap.log attached


",josuegomes@…
8756,Boost.MPL VS2013 Preview version bump,mpl,Boost 1.54.0,To Be Determined,Patches,Aleksey Gurtovoy,new,2013-07-01T23:25:36Z,2013-07-01T23:25:36Z,"The `BOOST_WORKAROUND` macros at `boost/mpl/assert.hpp` lines 37 and 247 need to be changed to also consider `BOOST_MSVC, == 1800`, patch attached.",Lars Viklund <zao@…>
8755,Boost.-Signals VS2013 compilation error,signals,Boost 1.55.0,Boost 1.56.0,Patches,Douglas Gregor,new,2013-07-01T23:24:18Z,2014-01-20T17:41:07Z,The `BOOST_WORKAROUND` macros at `boost/signals/detail/named_slot_map.hpp:130` and `libs/signals/src/named_slot_map.cpp:27 `needs to be increased to `<= 1800` in order to encompass the Visual Studio 2013 Preview compiler.,Lars Viklund <zao@…>
8749,"Accessing type of insert<map<>, pair<A,B> >::type discards inserted elements",mpl,Boost 1.52.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-06-30T22:04:35Z,2015-02-21T22:19:17Z,"The following code sample illustrates the problem

    typedef insert<map<>, pair<int, int> >::type little_map;

    BOOST_STATIC_ASSERT(size<little_map>::value == 1); /* Success */
    BOOST_STATIC_ASSERT(size<little_map::type>::value == 1); /* Failure */

I have traced the problem to the file boost/mpl/map/aux_/item.hpp in the class definition of m_item.  m_item derives from Base (which is a map<...> type) but does not define a ""typedef m_item type;"" to act as a unary metafunction returning itself.  The result is that Base::type is found instead which means that m_item acts as a unary metafunction returning a map with all the inserted elements removed.  The class m_item_ at the bottom of the file properly defines a ""typedef m_item_ type;"" which strengthens my belief that it missing from m_item is a bug.

The solution, quite staightforwardly is to simply add the line ""typedef m_item type;"" to the class' definition.

It should be noted that I am running version 1.48 of Boost, but have checked http://www.boost.org/doc/libs/1_52_0/boost/mpl/map/aux_/item.hpp and it still lacks the define so I'm convinced that this problem will still be there when I download the latest version of boost.",guylaingreer@…
8740,Possibly invalid assertion in define_with_defaults(),python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-06-27T16:06:13Z,2013-06-27T16:06:37Z,"Hi there,

this assertion in `boost/python/detail/defaults_def.hpp` seems backwards:

{{{
BOOST_STATIC_ASSERT(
    (stubs_type::max_args) <= mpl::size<SigT>::value);
}}}

I.e. I would expect the assertion to be that the actual number of arguments is *smaller* than the max or *larger* than the min.

It caused me a compile error like the following on gcc 4.8:

{{{
In file included from /usr/include/boost/python/overloads.hpp:11:0,
                 from /usr/include/boost/python.hpp:52,
                 from src/wrapper/common.hpp:24,
                 from src/wrapper/id3.cpp:40:
/usr/include/boost/python/detail/defaults_def.hpp: In instantiation of ‘void boost::python::detail::define_with_defaults(const char*, const OverloadsT&, NameSpaceT&, const SigT&) [with OverloadsT = {anonymous}::render_overloads; NameSpaceT = boost::python::class_<TagLib::ID3v2::Tag, boost::noncopyable_::noncopyable, boost::python::bases<TagLib::Tag> >; SigT = boost::mpl::vector2<TagLib::ByteVector, TagLib::ID3v2::Tag&>]’:
/usr/include/boost/python/class.hpp:598:9:   required from ‘void boost::python::class_<T, X1, X2, X3>::def_maybe_overloads(const char*, SigT, const OverloadsT&, const boost::python::detail::overloads_base*) [with OverloadsT = {anonymous}::render_overloads; SigT = TagLib::ByteVector (TagLib::ID3v2::Tag::*)()const; W = TagLib::ID3v2::Tag; X1 = boost::noncopyable_::noncopyable; X2 = boost::python::bases<TagLib::Tag>; X3 = boost::python::detail::not_specified]’
/usr/include/boost/python/class.hpp:245:9:   required from ‘boost::python::class_<T, X1, X2, X3>::self& boost::python::class_<T, X1, X2, X3>::def(const char*, A1, const A2&) [with A1 = TagLib::ByteVector (TagLib::ID3v2::Tag::*)()const; A2 = {anonymous}::render_overloads; W = TagLib::ID3v2::Tag; X1 = boost::noncopyable_::noncopyable; X2 = boost::python::bases<TagLib::Tag>; X3 = boost::python::detail::not_specified; boost::python::class_<T, X1, X2, X3>::self = boost::python::class_<TagLib::ID3v2::Tag, boost::noncopyable_::noncopyable, boost::python::bases<TagLib::Tag> >]’
src/wrapper/id3.cpp:221:8:   required from here
/usr/include/boost/python/detail/defaults_def.hpp:247:1: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’
}}}",Andreas Kloeckner <inform@…>
8737,Notepad++ and MinGW boost/asio ERROR,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-06-27T03:13:26Z,2013-06-27T03:13:26Z,"When compiling the first tutorial using notepad++ as a text editor and MinGW compiler i get this long scary list of errors



In file included from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/
boost/asio/basic_datagram_socket.hpp:18:0,
                 from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/
boost/asio.hpp:20,
                 from asioOne.cpp:2:
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/boost/asio/detail/conf
ig.hpp:207:5: warning: #warning Please define _WIN32_WINNT or _WIN32_WINDOWS app
ropriately. [-Wcpp]
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/boost/asio/detail/conf
ig.hpp:208:5: warning: #warning For example, add -D_WIN32_WINNT=0x0501 to the co
mpiler command line. [-Wcpp]
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/boost/asio/detail/conf
ig.hpp:209:5: warning: #warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP ta
rget). [-Wcpp]
C:\Users\COMPUTER\AppData\Local\Temp\ccrLdVld.o:asioOne.cpp:(.text+0x188): undef
ined reference to `boost::system::generic_category()'
C:\Users\COMPUTER\AppData\Local\Temp\ccrLdVld.o:asioOne.cpp:(.text+0x192): undef
ined reference to `boost::system::generic_category()'
C:\Users\COMPUTER\AppData\Local\Temp\ccrLdVld.o:asioOne.cpp:(.text+0x19c): undef
ined reference to `boost::system::system_category()'
c:/mingw/bin/../lib/gcc/mingw32/4.7.2/../../../../mingw32/bin/ld.exe: C:\Users\C
OMPUTER\AppData\Local\Temp\ccrLdVld.o: bad reloc address 0xe in section `.text$_
ZN5boost6system14error_categoryD2Ev[__ZN5boost6system14error_categoryD2Ev]'
collect2.exe: error: ld returned 1 exit status
",anonymous
8736,Beta1 tarball includes invalid path,Building Boost,Boost 1.54.0,To Be Determined,Bugs,,new,2013-06-27T01:55:19Z,2013-06-27T01:55:19Z,"I tried downloading this a couple of times to verify. There appears to be an invalid path, something like ""/path/to/boost//"" in the archive. If you open it in a Windows system using 7-zip, for instance, you'll find a top-level folder """" followed by Sources, or something like that. The tar.bz2, which is probably preferred if only because it is more compact, does not have the same problem. Nor does the 7z, which is preferred also due to size.",mwpowellhtx@…
8729,"Library Submission, working with pointer containers",functional,Boost 1.52.0,To Be Determined,Library Submissions,No-Maintainer,new,2013-06-25T15:02:20Z,2014-01-30T17:58:04Z,"Hey All,

I don't even know if this is the right place to submit this, but the website seems to indicate it is.

I was reading a book which seems to suggest that working with pointers in containers is harder then it should be.  A couple of templates can make it much easier.  For instance, to work with pointers(this template assumes that T is derived from unary_function, as std::set Compare types are, and long typenames are there to be an example to make this more understandable, final form could cut back:

template <typename T>
struct dereference {
    typename T::result_type operator()(const typename T::first_argument_type* arg1, const typename T::second_argument_type* arg2) const {
        return T()(*arg1, *arg2);
    }
};

e.x.: std::set<string*, Dereference<std::less<string> > > myset;


",Charlie Page <charlie.page@…>
8720,"Fix for boost serialisation, portable binary archive on AIX",serialization,Boost 1.52.0,To Be Determined,Bugs,Robert Ramey,new,2013-06-21T12:10:32Z,2013-06-21T12:10:32Z,"On most platforms, char is signed, however on AIX by default char is unsigned.
The portable binary archive assumes the char type is signed.

The fix is simply to replace 'char' with 'signed char' in the correct places.

This is a fairly safe and quick fix, can I please ask the authors of this
library to add this fix, for the next version of boost.

Here are the changes I made: (flagged under ' // changed ' comment
//--------------------------------------------------------
portable_binary_iarchive.hpp

   void load(signed char & t){  // changed
        this->primitive_base_t::load(t);
    }

//-------------------------------------------------------------
portable_binary_iarchive.cpp

void
portable_binary_iarchive::load_impl(boost::intmax_t & l, char maxsize){
    signed char size;        // changed
    l = 0;
    this->primitive_base_t::load(size);

    if(0 == size){
        return;
    }

    bool negative = (size < 0);
    ......

// -----------------------------------------------------------------
portable_binary_oarchive.hpp

  void save(const signed char & t){      // changed
        this->primitive_base_t::save(t);
    }

// -----------------------------------------------------------
portable_binary_oarchive.cpp

void
portable_binary_oarchive::save_impl(
    const boost::intmax_t l,
    const char maxsize
){
    signed char size = 0;       // changed

    if(l == 0){
        this->primitive_base_t::save(size);
        return;
    }

 ..........
",avi.bahra@…
8719,Not possible to target older iOS major version when using SDK from later version,Building Boost,Boost Development Trunk,To Be Determined,Bugs,,new,2013-06-21T10:50:26Z,2013-06-21T11:41:28Z,"Current example: I want to build using iOS SDK version 6.1, but with the minimum target OS version set to 5.1.

In order to achieve this I set macosx-version-min=5.1, macosx-version=6.1.

The code in darwin.jam, however, does not see 5.1 as a valid minimum version when the SDK version is 6.1. The code below appears to permit only 6.0 and 6.1.

{{{
        if $(version[3]) > 0
        {
            # We have a minor version of an SDK. We want to set up
            # previous minor versions, plus the current minor version.
            # So we recurse to set up the previous minor versions, up to
            # the current version.
            local minor-minus-1 = [ CALC $(version[3]) - 1 ] ;
            return
                [ init-sdk $(condition) : $(root)
                    : $(version[1-2]) $(minor-minus-1) : [ version-to-feature $(version[1-2]) $(minor-minus-1) ] ]
                $(version-feature) ;
        }
}}}

The resulting error when attempting to target 5.1 while using the 6.1 SDK is:

{{{
/Users/williamg/Projects/Experimenta/universe/boost/boost_1_53_0/tools/build/v2/build/feature.jam:485: in validate-value-string from module feature
error: ""iphone-5.1"" is not a known value of feature <macosx-version-min>
error: legal values: ""iphone-6.1"" ""iphone-6.0"" ""iphonesim-6.1"" ""iphonesim-6.0"" ""10.7"" ""10.6"" ""10.5"" ""10.4"" ""10.3"" ""10.2"" ""10.1"" ""10.0"" ""10.8""
}}}

This needs to change so that it's possible to target versions of the OS older than the same major release.

Discovered in Boost 1.53, but still present on trunk at time of writing.",William Gallafent <william@…>
8714,Allow move-only handlers,asio,Boost 1.53.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-06-20T10:42:14Z,2014-08-14T12:19:13Z,"(See also http://stackoverflow.com/questions/17211263)

The requirement that handlers be copy constructible doesn't allow for the following idiom:

{{{
void connection::send_response()
{
    // block until previous response is sent
    std::unique_lock<std::mutex> locker(response_mutex_);

    // prepare response
    response_ = ""foo"";

    // send response back to caller. move the unique_lock into the binder
    // to keep the mutex locked until asio is done sending.
    asio::async_write(stream_,
                      asio::const_buffers_1(response_.data(), response_.size()),
                      std::bind(&connection::response_sent, shared_from_this(),
                                _1, _2, std::move(locker))
                      );
}

void connection::response_sent(const boost::system::error_code& err, std::size_t len)
{
    if (err) handle_error(err);
    // the mutex is unlocked when the binder is destroyed
}
}}}

Please remove this restriction, there is no reason for it when using C++11.",Marton <marton78@…>
8712,[function] Comparison with nullptr differs from std::function<>,function,Boost 1.53.0,To Be Determined,Bugs,Douglas Gregor,new,2013-06-19T11:04:18Z,2017-01-27T11:01:20Z,"Whether or not boost::function<> ''should'' support comparison with (C++11) nullptr is another issue, but at the moment it is inconsistent with std::function<>.

E.g.

{{{
boost::function<void ()> bf;
bool c1 = (bf == nullptr);   // currently false

std::function<void ()> sf;
bool c2 = (sf == nullptr);   // true

assert(c1 == c2);
}}}

Tested with g++ 4.6.3 and Visual Studio 2012.
",boost@…
8708,surprising element segmentation,filesystem,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,new,2013-06-19T03:18:49Z,2013-06-19T03:18:49Z,"I was shocked today to find that this fails:

{{{#!cpp
assert(
    boost::starts_with(
        boost::filesystem::path(""/website/public_html/""),
        boost::filesystem::path(""/website/"")));
}}}

The reason is that the 2nd path has 3 elements, {{{""/""}}}, {{{""website""}}}, and {{{"".""}}}.  I found that last one especially surprising.",Dave Abrahams
8705,BOOST_PP_ENUM_SHIFTED doesn't work with Intel ICC,preprocessor,Boost 1.53.0,To Be Determined,Bugs,No-Maintainer,new,2013-06-17T20:04:30Z,2013-06-17T20:04:30Z,"Consider this example:

{{{
#include <boost/preprocessor/repetition.hpp>

#define F(z, n, p)              n
#define INNER_NORMAL(z, n, p)   f( BOOST_PP_ENUM(n, F, p) ) ;
#define INNER_SHIFTED(z, n, p)  f( BOOST_PP_ENUM_SHIFTED(n, F, p) ) ;

shifted:
BOOST_PP_REPEAT(4, INNER_SHIFTED, ~)

expected:
INNER_SHIFTED(~, 0, ~)
INNER_SHIFTED(~, 1, ~)
INNER_SHIFTED(~, 2, ~)
INNER_SHIFTED(~, 3, ~)

normal:
BOOST_PP_REPEAT(4, INNER_NORMAL, ~)
}}}

With `clang++ -P -E` and `g++ -P -E` it expands correctly:

{{{
shifted:
f( ) ; f( ) ; f( 1 ) ; f( 1 , 2 ) ;
expected:
f( ) ; f( ) ; f( 1 ) ; f( 1 , 2 ) ;
normal:
f( ) ; f( 0 ) ; f( 0 , 1 ) ; f( 0 , 1 , 2 ) ;
}}}

But `icpc -P -E` gets stuck:

{{{
shifted:
f( BOOST_PP_ENUM_SHIFTED_1_2(0, F, ~) );
f( BOOST_PP_ENUM_SHIFTED_1_2(1, F, ~) );
f( BOOST_PP_ENUM_SHIFTED_1_2(2, F, ~) );
f( BOOST_PP_ENUM_SHIFTED_1_2(3, F, ~) );
expected:
f(  ); f(  ); f( 1 ); f( 1, 2 );
normal:
f(  ); f( 0 ); f( 0, 1 ); f( 0, 1, 2 );
}}}

I'm using *Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.1.163 Build 20130313*, not sure if it's a bug in ICC or in Boost.Preprocessor;

",pascal@…
8701,wrong empty polygon-linestring intersection with overlapping edges,geometry,Boost 1.53.0,To Be Determined,Bugs,Barend Gehrels,assigned,2013-06-16T09:21:11Z,2013-08-27T21:04:08Z,"The returned intersection between these geometries is empty, although they overlap completely and I would expect the full linestring to be returned:

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

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

This issue might be related to #8310 and #8183.",aar@…
8694,gcc -Wcast-qual warning in boost/function/function_template.hpp,function,Boost 1.53.0,To Be Determined,Bugs,Douglas Gregor,new,2013-06-13T17:18:05Z,2014-01-30T18:03:18Z,"When using boost function library with -Wcast-qual and -Werror flags enabled the following error comes up boost/function/function_template.hpp:628:35 error:
cast from type 'const ...*' to type 'void*' casts away qualifiers [-Werror=cast-qual]
functor.obj_ref.obj_ptr = (void *)(f.get_pointer()); .....

This warning happens when f.get_pointer() is a const pointer (e.g. it is originating from boost::cref). Which leads to this C-style cast that casts away of constness. I think this can be fixed by replacing C-style cast by const_cast<void*>(static_cast<const void*>(f.get_pointer())) or by adding GCC pragmas to disable -Wcast-qual warning in this header file.",Ruben Adamyan <ruboam@…>
8689,Solaris: make_shared<const T> compile error,smart_ptr,Boost 1.51.0,To Be Determined,Bugs,Peter Dimov,new,2013-06-12T10:19:47Z,2013-06-12T10:19:47Z,"Compile this with Forte 11 (Sun C++ 5.8 Patch 121017-08 2006/12/06):

{{{
#include <boost/make_shared.hpp>
struct Foo { virtual ~Foo() {} };
void f() { boost::make_shared<const Foo>(); }
}}}

Compiler error is:

{{{
""/usr/local/include/boost/smart_ptr/make_shared.hpp"", line 60: Error: Non-const function Foo::__SLIP.DELETER__C() called for const object.
""/usr/local/include/boost/smart_ptr/make_shared.hpp"", line 86:     Where: While instantiating ""boost::detail::sp_ms_deleter<const Foo>::destroy()"".
""/usr/local/include/boost/smart_ptr/make_shared.hpp"", line 86:     Where: Instantiated from boost::make_shared<const Foo>().
""test.cpp"", line 3:     Where: Instantiated from non-template code.
}}}

Further testing shows the compiler incorrectly refuses to compile an explicit destructor call on any const T* with a virtual destructor.

Would it be worth explicitly removing const from sp_ms_deleter's template parameter?",matthew.bergin@…
8688,boost::filesystem::operations won't compile with bionic library,filesystem,Boost Development Trunk,To Be Determined,Bugs,Beman Dawes,new,2013-06-12T06:56:41Z,2013-06-12T06:56:41Z,"While porting to using bionic, we saw that operations in the boost::filesystem library won't compile with bionic, as it doesn't have the sys/statvfs.h header file.

Attached a patch which fixes it for bionic.",Martin Ertsaas <mertsas@…>
8687,ABI-breaking workaround unneccesary with recent ICC versions.,mpl,Boost 1.52.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-06-11T16:58:21Z,2013-06-11T16:58:21Z,"Description of the problem is here, with repro and fix:

http://software.intel.com/en-us/articles/link-error-with-icpc-with-boost-151-mpl-library-and-g",lukeocamden@…
8684,Provide a map-like container with key derivable from value,container,Boost 1.53.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2013-06-10T20:21:03Z,2013-08-06T23:08:52Z,"It would be nice to have a key-value associative container for which the user can provide a functor to derive a key from a value so that no additional memory to store the key is used.

This is different from a set in that the key- and value-types don't have to match.",1zeeky@…
8680,seekable_device missing in boost/iostreams/concepts.hpp,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-06-09T12:58:22Z,2017-11-08T12:34:57Z,"The documentation for [http://www.boost.org/doc/libs/1_53_0/libs/iostreams/doc/tutorial/container_device.html Boost.iosteams:Tutorial:Container_Device] refers to seekable_device as existing in [http://www.boost.org/doc/libs/1_53_0/boost/iostreams/concepts.hpp boost/iostreams/concepts.hpp]. However it does not exist. Either the documentation should be update or something along the lines of the following should be added to concepts.hpp.[[BR]]

{{{
typedef device<seekable> seekable_device;
typedef wdevice<seekable> wseekable_device;
}}}

Not sure if that should be wseekable_device or seekable_wdevice. The latter seems to better match the filter typedef's. 

Alternatively the documentation could be updated to refer to device[seekable].",Eric Molitor <eric@…>
8675,numpy integers not accepted by Boost.Python,python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-06-08T19:14:17Z,2013-06-08T19:14:17Z,"When I pass a numpy integer (or really any object that's not exactly a PyIntObject) to a BPL-wrapped function, I get errors like the following:

{{{
ArgumentError: Python argument types in
    CLAllocator.__call__(CLAllocator, numpy.int64)
did not match C++ signature:
    __call__((anonymous namespace)::cl_allocator {lvalue}, unsigned long)
}}}

It would be great if, instead of checking for exact types, Boost.Python could use obj.__index__() or obj.__int__() to just get the integer value.",Andreas Kloeckner <inform@…>
8673,static libraries compiled without -fPIC using gcc,build,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-06-08T15:20:00Z,2014-10-09T06:07:08Z,"shared libraries use the static libraries of boost，errors occur：
recompile with -fPIC. automake adds -fPIC always.

relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC",eyjian@…
8666,boost::lockfree::spsc_queue::emplace_push,lockfree,Boost 1.53.0,To Be Determined,Feature Requests,timblechmann,new,2013-06-06T22:14:59Z,2013-06-08T16:12:03Z,"It would be nice to be able to write the following function:
{{{
void producer_thread()
{
    while(isRunning)
    {
        T& item = q.emplace_write(); // This feature avoids the need to create the item
        write(item);
        q.emplace_push(); // This feature avoids the need to copy the item
    }
}
}}}

Implementing this:
A slow consumer may be reading the item after the write index so the change is not as easy as exposing the next item.  The change would require a gap of 1 item to always exist to avoid a read/write collision.

Jason Aubrey",aubrey@…
8646,vector_indirect: broader support for vector of indices,uBLAS,Boost 1.53.0,To Be Determined,Feature Requests,Gunter,new,2013-06-04T07:03:28Z,2013-06-04T07:03:28Z,"Hello all,

It would be really useful to be able to construct vector_indirect objects using more types of vector of indices, other than indirect_array. Contrary to the documentation, trying to use a std::vector<size_t> or a boost::numeric::ublas::vector<size_t> results in my compiler (GCC 4.7.2) complaining about a preprocess member missing.

Similar ideas would of course apply to matrix_indirect as well. Thanks for your time.",linuxfever@…
8643,2to3.py Call within python.jam,build,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-06-03T14:29:02Z,2013-06-03T18:01:09Z,"This is all on windows 2008 R2 Server, using Python3.3 and Boost 1.53.0

Within the file python.jam in ...\tools\build\v2\tools\python.jam I had to change the code in the function ""actions 2to3"" from

actions 2to3 
{
     2to3 -wn ""$(<)""
     2to3 -dwn ""$(<)""
}

to 

actions 2to3
{
    python.exe C:\Python33\Tools\Scripts\2to3.py -wn ""$(<)""
    python.exe C:\Python33\Tools\Scripts\2to3.py -dwn ""$(<)""
}

Apparently 2to3.py is a python file, and to call it from the windows shell as it seems to do in python.jam, you must run it with the python interpreter, as above.",trevor.haba@…
8642,Global locale prevents from using Boost.Filesystem in global constructors and destructors,filesystem,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,assigned,2013-06-03T13:06:50Z,2017-03-07T09:17:41Z,"The problem appears in particular with Boost.Log. On program termination, Boost.Log may attempt to perform final log file rotation, which involves calling Boost.Filesystem routines (path construction, in particular). But Boost.Filesystem is not usable at this point because its global locale is already destroyed.

Boost.Filesystem should remain usable during global constructors and destructors. The global locale should either be embedded into the path object (preferred solution, IMHO) or the library should ensure its availability during these stages.
",Andrey Semashev
8637,Warnings in boost/parameter/aux_/tagged_argument.hpp,parameter,Boost 1.54.0,Boost 1.54.0,Bugs,Daniel Wallin,new,2013-05-31T02:57:24Z,2013-06-03T18:01:43Z,The boost/parameter/aux_/tagged_argument.hpp in boost 1.54.0-beta1 rc causes the compiler to emit warnings.  This was fixed in r83985 and should be backported to the 1.54 branch.,Jim Garrison <jim@…>
8634,boost/filesystem/path.hpp is not self-sufficient,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-05-30T13:39:29Z,2016-03-11T08:49:32Z,"The following code is compiled under VC2012:

{{{
#include <boost/filesystem.hpp>
boost::filesystem::path p(""file.txt"");
size_t hash = boost::filesystem::hash_value(p);
}}}

but gives link error:

{{{
error LNK2019: unresolved external symbol ""void __cdecl boost::hash_combine<wchar_t>(unsigned int &,wchar_t const &)"" (??$hash_combine@_W@boost@@YAXAAIAB_W@Z) referenced in function ""unsigned int __cdecl boost::filesystem::hash_value(class boost::filesystem::path const &)"" (?hash_value@filesystem@boost@@YAIABVpath@12@@Z)
}}}

I fixed it by replacing

{{{
#include <boost/functional/hash_fwd.hpp>
}}}

with

{{{
#include <boost/functional/hash.hpp>
}}}",Valentin Shtronda <valiko.ua@…>
8631,property_three -  use user std::locale,property_tree,Boost 1.53.0,To Be Determined,Support Requests,Sebastian Redl,new,2013-05-30T03:57:45Z,2013-05-30T03:57:45Z,"property_tree use locale::global(). :(. 
Unfortunately ""std::locale::global""  global process property.
In multytread programm this problem.

Perhaps a small patch will improve the situation:

property_tree pt;
pt.put_value(12345, locale(""""));",shirshov evgeny <381677383@…>
8628,spsc_queue::pop(OutputIterator it) improperly works with random-access iterators if the read pointer is bigger than the write pointer (stored data consists of 2 blocks),lockfree,Boost 1.53.0,To Be Determined,Bugs,timblechmann,new,2013-05-29T00:40:33Z,2013-05-29T01:23:26Z,"spsc_queue::pop(OutputIterator it) method improperly works with random-access iterators if the queue's read pointer is bigger than the queue's write pointer (the queue's stored data consists of 2 blocks)

The following code will fill dst array improperly if the queue's read pointer is bigger than the queue's write pointer:

unsigned char* dst=new unsigned char[100];

count=q.pop(dst);

The bug caused by the code in spsc_queue.hpp:224:

std::copy(internal_buffer+read_index, internal_buffer+max_size, it);

std::copy(internal_buffer, internal_buffer+count1, it);

It will copy the second fragment starting from the same point it copied the first ftagment. The problem can be fixed as:

it=std::copy(internal_buffer+read_index, internal_buffer+max_size, it);

std::copy(internal_buffer, internal_buffer+count1, it);

",Constantin Fishkin <constantin_fishkin@…>
8625,Add function to indicate if `swap` is no-throw,swap,Boost 1.55.0,Boost 1.55.0,Feature Requests,joseph.gauterin,new,2013-05-28T14:24:02Z,2013-05-28T14:24:02Z,"While writing a library for Boost, I found the need for this function:

{{{
    #include <utility>

    //! Detect if a type's swap (found via ADL for
    //! non-built-ins) throws.
    template < typename T, typename U = T >
    inline constexpr
    bool  is_swap_nothrow() noexcept
    {
        using std::swap;

        return noexcept( swap(std::declval<T &>(),
         std::declval<U &>()) );
    }
}}}

while writing my container's swap.  You would probably use the macros for ""inline,"" ""constexpr,"" operator ""noexcept,"" and the ""noexcept"" flag, but the function is pretty much useless unless all of those features are fully defined.  The function has to be shielded from pre-C++11 compiles, of course.
",Daryle Walker
8623,Remove use of `boost::blank`,function_types,Boost 1.52.0,To Be Determined,Patches,t_schwinger,new,2013-05-28T02:37:12Z,2013-05-28T02:37:12Z,"The attached patch removes the dependency on `boost::blank`, while incidentally improving error messages when the metafunction preconditions do not hold.",K-ballo <kaballo86@…>
8612,unused pointers in copying of handlers,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-05-23T22:15:28Z,2013-07-25T06:22:21Z,"boost/asio/detail/reactive_socket_recv_op.hpp:

{{{
 84  static void do_complete(io_service_impl* owner, operation* base,
 85      const boost::system::error_code& /*ec*/,
 86      std::size_t /*bytes_transferred*/)
 87  {
 88    // Take ownership of the handler object.
 89    reactive_socket_recv_op* o(static_cast<reactive_socket_recv_op*>(base));

CID 11125 (2): Unused pointer value (UNUSED_VALUE)
CID 10926 (#1 of 1): Unused pointer value (UNUSED_VALUE)
returned_pointer: Pointer ""p.h"" returned by ""addressof(o->handler_)"" is never used. 
 90    ptr p = { boost::addressof(o->handler_), o, o };
 91
 92    BOOST_ASIO_HANDLER_COMPLETION((o));
 93
 94    // Make a copy of the handler so that the memory can be deallocated before
 95    // the upcall is made. Even if we're not about to make an upcall, a
 96    // sub-object of the handler may be the true owner of the memory associated
 97    // with the handler. Consequently, a local copy of the handler is required
 98    // to ensure that any owning sub-object remains valid until after we have
 99    // deallocated the memory here.
100    detail::binder2<Handler, boost::system::error_code, std::size_t>
101      handler(o->handler_, o->ec_, o->bytes_transferred_);
102    p.h = boost::addressof(handler.handler_);
103
}}}

boost/asio/detail/reactive_socket_send_op.hpp:
{{{
 81  static void do_complete(io_service_impl* owner, operation* base,
 82      const boost::system::error_code& /*ec*/,
 83      std::size_t /*bytes_transferred*/)
 84  {
 85    // Take ownership of the handler object.
 86    reactive_socket_send_op* o(static_cast<reactive_socket_send_op*>(base));

CID 11126 (4): Unused pointer value (UNUSED_VALUE)
CID 11126 (4): Unused pointer value (UNUSED_VALUE)
CID 10927 (#2 of 2): Unused pointer value (UNUSED_VALUE)
CID 10927 (#1 of 2): Unused pointer value (UNUSED_VALUE)
returned_pointer: Pointer ""p.h"" returned by ""addressof(o->handler_)"" is never used. 
 87    ptr p = { boost::addressof(o->handler_), o, o };
 88
 89    BOOST_ASIO_HANDLER_COMPLETION((o));
 90
 91    // Make a copy of the handler so that the memory can be deallocated before
 92    // the upcall is made. Even if we're not about to make an upcall, a
 93    // sub-object of the handler may be the true owner of the memory associated
 94    // with the handler. Consequently, a local copy of the handler is required
 95    // to ensure that any owning sub-object remains valid until after we have
 96    // deallocated the memory here.
 97    detail::binder2<Handler, boost::system::error_code, std::size_t>
 98      handler(o->handler_, o->ec_, o->bytes_transferred_);
 99    p.h = boost::addressof(handler.handler_);
}}}

boost/asio/detail/wait_handler.cpp:
{{{
43  static void do_complete(io_service_impl* owner, operation* base,
44      const boost::system::error_code& /*ec*/,
45      std::size_t /*bytes_transferred*/)
46  {
47    // Take ownership of the handler object.
48    wait_handler* h(static_cast<wait_handler*>(base));

CID 11127 (2): Unused pointer value (UNUSED_VALUE)
CID 10929: Unused pointer value (UNUSED_VALUE)
CID 10928 (#1 of 1): Unused pointer value (UNUSED_VALUE)
returned_pointer: Pointer ""p.h"" returned by ""addressof(h->handler_)"" is never used. 
49    ptr p = { boost::addressof(h->handler_), h, h };
50
51    BOOST_ASIO_HANDLER_COMPLETION((h));
52
53    // Make a copy of the handler so that the memory can be deallocated before
54    // the upcall is made. Even if we're not about to make an upcall, a
55    // sub-object of the handler may be the true owner of the memory associated
56    // with the handler. Consequently, a local copy of the handler is required
57    // to ensure that any owning sub-object remains valid until after we have
58    // deallocated the memory here.
59    detail::binder1<Handler, boost::system::error_code>
60      handler(h->handler_, h->ec_);
61    p.h = boost::addressof(handler.handler_);
}}}

boost/asio/detail/wait_handler.cpp:
{{{
43  static void do_complete(io_service_impl* owner, operation* base,
44      const boost::system::error_code& /*ec*/,
45      std::size_t /*bytes_transferred*/)
46  {
47    // Take ownership of the handler object.
48    wait_handler* h(static_cast<wait_handler*>(base));

CID 11127 (2): Unused pointer value (UNUSED_VALUE)
CID 10928: Unused pointer value (UNUSED_VALUE)
CID 10929 (#1 of 1): Unused pointer value (UNUSED_VALUE)
returned_pointer: Pointer ""p.h"" returned by ""addressof(h->handler_)"" is never used. 
49    ptr p = { boost::addressof(h->handler_), h, h };
50
51    BOOST_ASIO_HANDLER_COMPLETION((h));
52
53    // Make a copy of the handler so that the memory can be deallocated before
54    // the upcall is made. Even if we're not about to make an upcall, a
55    // sub-object of the handler may be the true owner of the memory associated
56    // with the handler. Consequently, a local copy of the handler is required
57    // to ensure that any owning sub-object remains valid until after we have
58    // deallocated the memory here.
59    detail::binder1<Handler, boost::system::error_code>
60      handler(h->handler_, h->ec_);
61    p.h = boost::addressof(handler.handler_);
}}}

boost/asio/",Richard <legalize@…>
8611,pthread functions are called without checking return values for error,signals2,Boost 1.52.0,To Be Determined,Bugs,Frank Mori Hess,new,2013-05-23T16:09:24Z,2013-06-09T20:46:27Z,"This is similar to https://svn.boost.org/trac/boost/ticket/2681

The errors are detected by coverity static analysis.

{{{
58    void lock()
59    {

CID 11713: Unchecked return value
60        pthread_mutex_lock(&m_);
61    }

68    void unlock()
69    {
  
CID 11714 (#1 of 1): Unchecked return value (CHECKED_RETURN)
1. check_return: Calling function ""pthread_mutex_unlock(pthread_mutex_t *)"" without checking return value (as is done elsewhere 6 out of 7 times). 
2. unchecked_value: No check of the return value of ""pthread_mutex_unlock(&this->m_)"". 
70        pthread_mutex_unlock(&m_);
71    }
}}}
",Richard <legalize@…>
8608,Default lambda expression with mpl::equal,mpl,Boost Development Trunk,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-05-22T21:25:01Z,2013-05-22T21:25:01Z,"Summary of the original message posted on the mailing list:

------------------------------------------------------------------------------
Some higher order algorithms in the MPL have a default for the lambda
expression they accept. A good example is `boost::mpl::equal`:
{{{
    template <typename S1, typename S2, typename Pred = is_same<_, _> >
    struct equal;
}}}

This works fine most of the time, but I was recently bitten by the following:

{{{
    template <typename VectorOfVectors, typename Vector>
    struct find_vector
        : find_if<
            VectorOfVectors, equal<Vector, _1>
        >
    { };

    typedef find_vector<
        vector<
            vector<int, int>,
            vector<char, char>
        >,
        vector<char, char>
    >::type ThisWillBreak;
}}}

What happens here is that the `equal<Vector, _1>` expression inside
`find_vector` really is `equal<Vector, _1, is_same<_1, _2> >` because
of the default value for the predicate to `equal`. When the lambda is
evaluated, the placholders inside the inner `is_same<_1, _2>` expression
are replaced too, which yields unexpected results.
------------------------------------------------------------------------------

Original thread:
http://thread.gmane.org/gmane.comp.lib.boost.devel/241690
",Louis Dionne <ldionne.2@…>
8607,Duplicate Symbols when using Parameter or Graph Library on HP-UX,parameter,Boost 1.48.0,To Be Determined,Patches,Daniel Wallin,new,2013-05-22T20:44:04Z,2013-05-22T20:44:04Z,"On HP-UX 11i v2 (B.11.23), using gcc 4.0.1 and the native linker (ld B.11.59)

When linking a shared library which has multiple object files using the Boost Graph library or other code using the Parameter library, the link process fails with several dozen ""duplicate symbol"" errors, such as:

[18:50:06]/usr/ccs/bin/ld: Duplicate symbol ""boost::graph::keywords::(anonymous namespace)::_vertices_equivalent"" in files .libs/a.o and .libs/b.o

Root cause seems to be that the linker has an issue collapsing variables defined with a templated type into a single definition; specifically when boost/parameter/name.hpp is included in multiple files.

This also appears to be an issue with versions of MSVC before 1300.

The attached patch file corrects the issue by enabling the same fix for MSVC <1300 when compiled on HPPA systems.

Note that this issue does not appear on HPUX 11.23 Itanium (ia64), which has a different native linker implementation.",James Hugard <james_hugard@…>
8601,GCC 4.7.3 prints warning [-Wmaybe-uninitialized] for multi_array.hpp,multi_array,Boost 1.53.0,To Be Determined,Bugs,Ronald Garcia,new,2013-05-21T12:39:43Z,2013-05-25T13:38:20Z,"When compiling the attached test case program using Boost 1.53.0 and GCC 4.7.3:

{{{
g++ -Wall -O2 -DBOOST_DISABLE_ASSERTS -I/path/to/include/dir test_prog.cpp
}}}

where test_prog.cpp is


{{{
#include ""boost/multi_array.hpp""

int main()
{
	boost::multi_array<int,1> A;
	A.resize(boost::extents[2]);
	A[0] = 0;
	A[1] = 0;
	return(0);
}
}}}

I get the following warning:


{{{
In file included from test_prog.cpp:1:0:
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array.hpp: In member function ‘boost::multi_array<T, NumDims, Allocator>& boost::multi_array<T, NumDims, Allocator>::resize(const boost::detail::multi_array::extent_gen<NumDims>&) [with T = int; long unsigned int NumDims = 1ul; Allocator = std::allocator<int>; boost::multi_array<T, NumDims, Allocator> = boost::multi_array<int, 1ul>]’:
/mn/anatu/cma-u3/tmac/usr/include/boost/multi_array.hpp:401:16: warning: ‘new_strides.boost::array<long int, 1ul>::elems[0ul]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
}}}
",Torquil Sørensen <torquil@…>
8600,"wait_for_any hangs, if called with multiple copies of shared_future referencing same task",thread,Boost 1.53.0,To Be Determined,Bugs,viboes,assigned,2013-05-21T11:50:16Z,2013-06-04T06:13:38Z,"The following small test program shows the problem:

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

int calculate_the_answer_to_life_the_universe_and_everything()
{
    return 42;
}

int main(int argc, char* argv[])
{
   boost::packaged_task<int> pt(calculate_the_answer_to_life_the_universe_and_everything);
   boost::shared_future<int> fi1 = boost::shared_future<int>(pt.get_future());
   boost::shared_future<int> fi2 = fi1;

   boost::thread task(boost::move(pt)); // launch task on a thread

   boost::wait_for_any(fi1, fi2);
   std::cout << ""Wait for any returned\n"";
   return (0);
}
}}}

This program hangs infinitely in the call to boost::wait_for_any. From the docs I would expect this to work, because it's allowed to copy shared_futures. If this is not allowed, a possibility would be needed, to find out, if two shared_futures point to the same task or not. Currently wait_for_any is unusable, if there are chances, that multiple shared_futures point to the same result.",Martin Apel <martin.apel@…>
8599,enable_shared_from_this -- no throw alternative,smart_ptr,Boost 1.52.0,To Be Determined,Feature Requests,Peter Dimov,new,2013-05-21T07:00:41Z,2013-05-21T07:00:41Z,"I think  that enable_shared_from_this misses one feature, that is accessible for weak_ptr and allows no throw access to the underlying instance to a shared_ptr, by either a valid pointer or a null_ptr (boost::weak_ptr::lock).

It would be great to have such a mechanism for enable_shared_from_this as well -- i.e. returning the weak_ptr via member functions weak_this and then chain with lock -- to avoid bad_weak_ptr exception.

Background:
Combining intrusive container with enable_shared_from_this and auto-unlink option, where the element own the container, the only way to determine if an element is currently unlinking itself in muti threaded execution, is via an exception, rather than just checking for a null_ptr.

Where this setup might sound very rare, it is one of the most powerful combinations of shared_ptr aliasing, intrusive-containers and enable_shared_from_this for perfect concurrent lookup containers.

And under multi-threading conditions, the exception may get very common and therefore expensive.",ingo.loehken@…
8597,Add single precision float support for spirit and/or utree,spirit,Boost 1.53.0,To Be Determined,Feature Requests,Joel de Guzman,new,2013-05-20T16:44:33Z,2013-05-20T17:18:07Z,"Currently there is only double precision floating point support that I know of. However, we are cross compiling to ArchLinux ARM, and would like to stay in the realm of 32-bit single precision if at all possible, and void ARM hard or soft floating point issues if at all possible.",Michael Powell <mwpowellhtx@…>
8593,enable std::atomic with clang / libc++,lockfree,Boost 1.52.0,To Be Determined,Patches,timblechmann,new,2013-05-19T23:50:10Z,2013-05-21T07:36:04Z,"Attatched is a simple patch that checks if we're usng a version of clang / libc++ that has <atomic> support.

The:


{{{
#if defined(_LIBCPP_VERSION) && __has_include( <atomic> )
}}}

is on a second line because I previously had problems with the __has_include( <> ) macro when this code is interpreted by MSVC compiler - it seems to want to process the entire line despite the first check failing.",reakinator@…
8592,Cross compiling on OS X to linux gets the shared object name wrong,Building Boost,Boost 1.49.0,To Be Determined,Bugs,,new,2013-05-19T21:45:47Z,2013-06-20T16:46:11Z,"I'm compiling boost for openwrt on my OS X machine, but it fails near the end, because the shared libraries produced are given the extension .dylib instead of .so. It also affect SONAME inside the lib, which stops me from just renaming them.

I'm not really sure what the best way of reproduceing is, short of compiling openwrt:
{{{
svn co svn://svn.openwrt.org/openwrt/tags/attitude_adjustment_12.09
cd attitude_adjustment_12.09
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
(enable boost_system in libraries)
make V=s
}}}

Here's the command used to build boost if that helps:

`( cd /Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0 ; echo ""using gcc : mipsel : mipsel-openwrt-linux-gcc : <compileflags>\""-Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float\"" <cxxflags>\""-Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float\"" <linkflags>\""-L/Volumes/data/Unix/openwrt/wl500gp/staging_dir/target-mipsel_uClibc-0.9.33.2/usr/lib -L/Volumes/data/Unix/openwrt/wl500gp/staging_dir/target-mipsel_uClibc-0.9.33.2/lib -L/Volumes/data/Unix/openwrt/wl500gp/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/usr/lib -L/Volumes/data/Unix/openwrt/wl500gp/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/lib -pthread -lrt\"" ;"" > tools/build/v2/user-config.jam ;  bjam '-sBUILD=release <optimization>space <inlining>on <debug-symbols>off'  --toolset=gcc-mipsel --build-type=minimal --layout=system --disable-long-double --target=mipsel-openwrt-linux --host=mipsel-openwrt-linux --build=x86_64-apple-darwin12.3.0 --program-prefix="""" --program-suffix="""" --prefix=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install --exec-prefix=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install --bindir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/bin --sbindir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/sbin --libexecdir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/lib --sysconfdir=/etc --datadir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/share --localstatedir=/var --mandir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/man --infodir=/Volumes/data/Unix/openwrt/wl500gp/build_dir/target-mipsel_uClibc-0.9.33.2/boost_1_49_0/ipkg-install/info --disable-nls   --without-chrono --without-date_time --without-exception --without-filesystem --without-graph --without-graph_parallel  --without-locale --without-math --without-mpi  --without-python --without-random --without-regex --without-serialization --without-signals  --without-test --without-thread --without-timer --without-wave -sNO_BZIP2=1 -sZLIB_INCLUDE=/Volumes/data/Unix/openwrt/wl500gp/staging_dir/target-mipsel_uClibc-0.9.33.2/usr/include -sZLIB_LIBPATH=/Volumes/data/Unix/openwrt/wl500gp/staging_dir/target-mipsel_uClibc-0.9.33.2/usr/lib install )`",per@…
8588,program_options eats parameter instead of reporting previous one missing an argument,program_options,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-05-18T22:03:05Z,2015-11-12T10:29:21Z,"If a parameter is specified with a mandatory argument, but the argument is omitted, the following parameter is used as the argument instead.  For example:

{{{
  ./test --dump-firmware
  Invalid command line syntax: the required argument for option '--firmware' is missing.  Use --help for help.
  ./test --dump-firmware --help
  dumping firmware to file: --help
}}}

Here, --dump-firmware requires an argument, and ""--help"" is passed in as the argument.  Instead, ""--help"" should be treated as a parameter (either valid or not) and --dump-firmware should report a missing parameter instead.
",Adam Nielsen <a.nielsen@…>
8587,Command line response file not being shown in regression tests,Regression Testing USE GITHUB,Boost 1.52.0,To Be Determined,Bugs,-,new,2013-05-18T15:37:52Z,2017-08-26T15:50:16Z,"In the online regression test page, when looking at a particular regression test, the compiler command line can be viewed. But when the compiler command line shows a response file being used for compiler options, the contents of the response file are not being shown.",Edward Diener
8583,tar attempts to change ownership to invalid uid.,Building Boost,Boost 1.52.0,To Be Determined,Bugs,,new,2013-05-18T02:35:03Z,2013-05-25T13:39:07Z,"When running as root, untaring the boost package using gentoo prefix on Interix v3.5 for Windows XP fails with:

     ''Cannot change ownership to uid 501, gid 0: Invalid argument''

This is solved by running tar with flags: 

    ""--user root --no-same-owner""

This issue is unique to boost .tar.gz files and blocks any installation by gentoo emerge.

More information found here:
[http://forums.gentoo.org/viewtopic-t-959612-highlight-.html]",akf@…
8582,Improve string algorithm Stacking,string_algo,Boost 1.55.0,To Be Determined,Feature Requests,Marshall Clow,new,2013-05-17T17:47:12Z,2013-05-17T18:04:32Z,"The documentation for the string algorithm library states:

""Algorithm stacking: Copy versions return a transformed input as a result, thus allow a simple chaining of transformations within one expression (i.e. one can write trim_copy(to_upper_copy(s))). Mutable versions have void return, to avoid misuse. ""

I'm not sure what they mean by misuse but if all of the mutable version returned a reference to the object you are manipulating then you could chain them together without paying the price of copying the string over and over again.
",rlogel@…
8581,Files in C:\ProgramData\boost_interprocess are not accessible.,interprocess,Boost 1.50.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-05-17T14:43:18Z,2016-09-07T20:11:16Z,"When a service running as ""Local System"" user is using managed_shared_memory the file used for that shared memory is created in C:\ProgramData\boost_interprocess\*\*.

The permissions for this file are such that a regular user starting a process that wants to access that shared memory is not able to access the file and thus access the shared memory.",Andreas Neustifter <andreas.neustifter@…>
8579,qi::as/qi::attr_cast<container_type> cannot be combined with some other parsers,spirit,Boost Development Trunk,To Be Determined,Bugs,Joel de Guzman,new,2013-05-16T04:02:38Z,2013-05-16T04:02:38Z,"The following code should compile, but it doesn't. If you remove "">> qi::eoi"" part from the rule, it compiles. There may be other parsers in place of qi::eoi which don't expose any attribute (qi::lit, qi::eps) - the code won't compile either. qi::as<vector_type> is redundant in this particular example, but it can do the work in a real program.

{{{
#include <boost/spirit/include/qi.hpp>
#include <boost/spirit/include/qi_match.hpp>
#include <iostream>
#include <sstream>
#include <vector>

namespace qi = boost::spirit::qi;

int main() {
    typedef std::vector<int> vector_type;
    vector_type vector;

    std::istringstream is(""11 22 33"");
    is >> std::noskipws >> qi::match(qi::as<vector_type>()[qi::int_ % ' '] >> qi::eoi, vector);
//  is >> std::noskipws >> qi::match(qi::attr_cast<vector_type>(qi::int_ % ' ') >> qi::eoi, vector);
    assert(is);

    for (auto value : vector)
        std::cout << value << ' ';
}
}}}
",Vadim Guchenko <yhw@…>
8572,iosteams indirect_streambuf::init_put_area should seek if data has been read from the get buffer,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-05-14T15:54:33Z,2013-05-14T15:54:33Z,"The following code with std::fstream prints 0x1801 but with boost::iostream prints 0x2000:
{{{
  boost::iostreams::stream< boost::iostreams::file > ios( boost::iostreams::file( ""test.dat"", std::ios_base::binary | std::ios_base::in | std::ios_base::out | std::ios_base::trunc ), 0x800 );
  //std::fstream ios( ""test.dat"", std::ios_base::binary | std::ios_base::in | std::ios_base::out | std::ios_base::trunc );
  char buffer[ 0x2000 ];
  ios.write( buffer, 0x2000 );
  ios.seekg( -0x1000, std::ios_base::cur );
  ios.get();
  ios.write( buffer, 0x800 );
  std::cout << std::hex << ios.tellp() << std::endl;
  std::cout << std::hex << ios.tellg() << std::endl;
}}}

I believe the problem lies in indirect_streambuf::init_put_area. The current implementation is:

{{{
    if (shared_buffer() && gptr() != 0)
        setg(0, 0, 0);
    if (output_buffered())
        setp(out().begin(), out().end());
    else
        setp(0, 0);
}}}

I think it should be:
{{{
    if (shared_buffer() && gptr() != 0)
    {
        obj().seek(gptr()-egptr(), BOOST_IOS::cur, BOOST_IOS::in, next_);
        setg(0, 0, 0);
    }
    if (output_buffered())
        setp(out().begin(), out().end());
    else
        setp(0, 0);
}}}
",Alan Birtles <alan.birtles@…>
8566,Enable writing of CDATA,property_tree,,To Be Determined,Feature Requests,Sebastian Redl,new,2013-05-13T14:28:46Z,2018-06-26T14:27:25Z,"If one tries to write a node using write_xml

<example><![CDATA[<>]]></example>

the characters <> (and probably & etc.) get escaped in HTML style. The output file will contain

<example>&lt;![CDATA[&lt;&gt;]]&gt;</example>

Might it be a solution to introduce another sub-key <xmlcdata> (like <xmlcomment>) and write code analogue to function write_xml_comment like 
{{{
    template<class Ch>
    void write_xml_xcdata(std::basic_ostream<Ch> &stream,
                           const std::basic_string<Ch> &s, 
                           int indent,
                           bool separate_line,
                           const xml_writer_settings<Ch> & settings
                           )
    {
        typedef typename std::basic_string<Ch> Str;
        if (separate_line)
            write_xml_indent(stream,indent,settings);
        stream << Ch('<') << Ch('!') << Ch('[') << Ch('C') << Ch('D') << Ch('A') << Ch('T') << Ch('A') << Ch('[');
        stream << s;
        stream << Ch(']') << Ch(']') << Ch('>');
        if (separate_line)
            stream << Ch('\n');
    }
}}}",Wolf A. Heidrich <wolf.heidrich@…>
8565,Lists in admonitions,quickbook,Boost 1.52.0,To Be Determined,Bugs,Daniel James,assigned,2013-05-13T11:12:38Z,2013-09-29T11:35:22Z,"It seems not to be possible to include lists in admonitions.

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

[note Some text for my note

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

]",thomas.moeck@…
8564,Variable hiding errors within nested let blocks in Phoenix,phoenix,Boost 1.53.0,To Be Determined,Bugs,Thomas Heller,new,2013-05-11T23:41:08Z,2015-02-01T21:50:40Z,"I encounter errors when using nested let blocks in Phoenix whenever an ""inner"" local variable hides an ""outer"" local variable. The ""Visibility"" example from the documentation at http://www.boost.org/doc/libs/1_53_0/libs/phoenix/doc/html/phoenix/modules/scope/let.html also fails. Here is that ""Visibility"" example as a standalone module which fails:

{{{
#include <iostream>
#include <boost/phoenix.hpp>

namespace phoenix = boost::phoenix;
using namespace phoenix::local_names;

int main(int argc, char *argv[])
{
  phoenix::let(_x = 1, _y = "", World"")
  [
    phoenix::let(_x = ""Hello"") // hides the outer _x
    [
      std::cout << _x << _y // prints ""Hello, World""
    ]
  ]();

  return 0;
}
}}}

The errors I receive from GCC 4.7.2, GCC 4.8 snapshot, and Clang 3.2, with any of Boost 1.49, 1.53, or trunk, begin as follows:
  GCC:   ""error: function returning an array""

  Clang: ""error: function cannot return array type 'result_type' (aka 'char [6]')""

Another failing example provided in Eric Niebler's Stack Overflow answer [http://stackoverflow.com/questions/16408770/variable-hiding-within-nested-let-blocks-in-boost-phoenix here] is:

{{{
int y = 0;
int x = (phoenix::let(_a = 1, _b = 2)[phoenix::let(_b = 3)[ _a ]])(y);
}}}

...which contrasts with the following example; which does compile: 

{{{
int y = 0;
int x = (phoenix::let(_a = 1, _b = 2)[phoenix::let(_b = _1)[ _a ]])(y);
}}}
",miremare@…
8562,Pool doc lists incorrect header file,pool,Boost 1.53.0,To Be Determined,Tasks,Chris Newbold,new,2013-05-10T21:06:59Z,2013-05-10T21:06:59Z,"The pool documentation (http://www.boost.org/doc/libs/1_53_0/libs/pool/doc/html/boost_pool/pool/conventions.html) specifies that users can include

#include <boost/pool.hpp>

This is incorrect; users must in fact include

#include <boost/pool/pool.hpp>

in order to get the required functionality.",Luis G. Torres <lgtorres42@…>
8558,some misspell fixes,Building Boost,Boost Development Trunk,To Be Determined,Patches,,new,2013-05-09T18:19:38Z,2013-05-15T16:42:44Z,some misspell fixes,vlajos@…
8545,Can quickbook support parts and chapters as well as sections?,quickbook,Boost Development Trunk,To Be Determined,Feature Requests,Daniel James,assigned,2013-05-03T15:56:14Z,2013-05-06T16:38:17Z,"Currently the only ""top level"" structure supported is the section, but it would be very useful for longer documents have to have support for chapters, parts and appendixes as well.  As far as I know these can't be implemented as templates as these get <para>...</para> wrapped around them even when they're block templates.",John Maddock
8540,Named Condition Variable hanging.,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-05-02T04:06:26Z,2013-05-13T21:32:21Z,"Hi, 

I am having problems with the shared memory code below. I can get this working on a Windows, MAC and OpenSUSE machine. However this same code does not work on my redhat v5.0 workstation machine. 

It appears to hang on the wait (condition variable). Any idea why this would be the case on this particular OS? I can't find anything online on the subject.

Website of code:
http://en.highscore.de/cpp/boost/interprocesscommunication.html#interprocesscommunication_managed_shared_memory

#include <boost/interprocess/managed_shared_memory.hpp> 
#include <boost/interprocess/sync/named_mutex.hpp> 
#include <boost/interprocess/sync/named_condition.hpp> 
#include <boost/interprocess/sync/scoped_lock.hpp> 
#include <iostream> 

int main() 
{ 
  boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::open_or_create, ""shm"", 1024); 
  int *i = managed_shm.find_or_construct<int>(""Integer"")(0); 
  boost::interprocess::named_mutex named_mtx(boost::interprocess::open_or_create, ""mtx""); 
  boost::interprocess::named_condition named_cnd(boost::interprocess::open_or_create, ""cnd""); 
  boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(named_mtx); 
  while (*i < 10) 
  { 
    if (*i % 2 == 0) 
    { 
      ++(*i); 
      named_cnd.notify_all(); 
      named_cnd.wait(lock); 
    } 
    else 
    { 
      std::cout << *i << std::endl; 
      ++(*i); 
      named_cnd.notify_all(); 
      named_cnd.wait(lock); 
    } 
  } 
  named_cnd.notify_all(); 
  boost::interprocess::shared_memory_object::remove(""shm""); 
  boost::interprocess::named_mutex::remove(""mtx""); 
  boost::interprocess::named_condition::remove(""cnd""); 
} ",ealfay@…
8539,Windows Extended Path Prefix Suggestion,filesystem,Boost 1.53.0,To Be Determined,Feature Requests,Beman Dawes,new,2013-05-02T03:45:48Z,2013-05-03T20:05:29Z,"With the Windows extended path prefix:
{{{
\\?\
}}}
It might make sense if the path class pre-allocates 4 extra characters for paths and stores the actual path at position m_pathname[4] in the string.  When a path exceeds MAX_PATH, the path functions could write the extended path prefix at m_pathname[0] and pass that along to the Windows API.  It may make sense to return this as something like extended_path() as well.

The only problems in dealing with extended paths are that there can be no relative path (. and ..) segments and no forward slashes.

I realize this may require alot of logic changes in the code (shifting read/write locations); however it could cut down on additional Windows-specific wrappers around the path class.",ascend4nt@…
8535,problem with paths that have whitespace in boost::program_options,program_options,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-05-01T16:45:25Z,2018-07-13T04:22:37Z,"This seems to be a known bug since at least 2008. Full description and suggested solution is mentioned in the external link below:

[boost.2283326.n4.nabble.com/program-options-Problem-with-paths-that-have-spaces-td2576490.html]

In short: when a boost::filesystem::path is used directly to retrieve a path parameter, if the path has a whitespace -- regardless of whether / or \ is used, or the whitespace is escaped, or the path is double-quoted -- a parsing error occurs.

The current workaround is to use string and then convert that to boost::filesystem::path using the = operator of the path class, however this looks more of a ""bug"" in program_options rather than new feature in lexical_cast module since in program_options lexical casting of string to path is obviously failing and should not have been considered.",bdahi@…
8529,boost/spirit/home/karma/stream/stream.hpp comments about special overload incomplete,spirit,Boost 1.52.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-04-30T15:45:12Z,2014-04-09T02:05:49Z,"The comments here:

        // this is a special overload to detect if the output iterator has been
        // generated by a format_manip object.
        template <
            typename T, typename Traits, typename Properties, typename Context
          , typename Delimiter, typename Attribute
        >
        static bool generate(
            karma::detail::output_iterator<
                karma::ostream_iterator<T, Char, Traits>, Properties
            >& sink, Context& context, Delimiter const& d
          , Attribute const& attr)
        {

around line 153 should also indicate that this function is called, at least
sometimes, when just a stream operator is used.  For example, when the
attached is run, the above method is also called despite there being
no format_manip object used.
",cppljevans
8523,Python library warning messages,python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-04-30T06:53:08Z,2013-07-08T00:55:10Z,"Hi,

I built Boost 1.53.0 on Fedora 18 32/64-bit using the following command:

./b2 link=shared runtime-link=shared address-model=32|64 variant=release

and received the following messages during the compilation:

libs/python/src/object/enum.cpp: In function ‘boost::python::api::object boost::python::objects::{anonymous}::new_enum_type(const char*, const char*)’:
libs/python/src/object/enum.cpp:150:44: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
libs/python/src/object/class.cpp: In function ‘PyObject* boost::python::objects::static_data()’:
libs/python/src/object/class.cpp:211:46: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
libs/python/src/object/class.cpp: In function ‘boost::python::type_handle boost::python::objects::class_metatype()’:
libs/python/src/object/class.cpp:319:49: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
libs/python/src/object/class.cpp: In function ‘boost::python::type_handle boost::python::objects::class_type()’:
libs/python/src/object/class.cpp:473:45: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
libs/python/src/object/function.cpp: In constructor ‘boost::python::objects::function::function(const boost::python::objects::py_function&, const boost::python::detail::keyword*, unsigned int)’:
libs/python/src/object/function.cpp:108:39: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
libs/python/src/object/function.cpp:110:39: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
libs/python/src/object/life_support.cpp: In function ‘PyObject* boost::python::objects::make_nurse_and_patient(PyObject*, PyObject*)’:
libs/python/src/object/life_support.cpp:94:43: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
libs/python/src/object/life_support.cpp:96:43: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
",lcarreon@…
8522,Using result_of on pure virtual functions lead to compile errors,result_of,Boost 1.52.0,To Be Determined,Bugs,Daniel Walker,new,2013-04-30T05:21:47Z,2013-04-30T05:21:47Z,"minimal example:

struct Test{
    typedef int result_type;
    virtual int operator()(int)=0;
};
typedef boost::result_of<Test(int)>::type type;

fails because Test is pure virtual and thus the function pointer is invalid.

from the mailing list:

""This is supposed to work:

  typedef boost::result_of<Test&(int)>::type type;""

But apparently it does not:

/usr/include/boost/utility/result_of.hpp:166:8: Error: »Test&« is no class, structure or union type.

",oswin.krause@…
8520,tuples set_delimiter and Unicode,tuple,Boost 1.53.0,To Be Determined,Bugs,Joel de Guzman,new,2013-04-29T12:20:35Z,2013-04-29T12:20:35Z,"set_delimiter does not work with unicode characters, e.g.:

boost::tuples::set_delimiter(L',');

tuple_io.hpp(203): warning C4244: 'argument' : conversion from 'const wchar_t' to 'const char', possible loss of data",gast128@…
8517,Async: Add a variadic shared_future::then,thread,Boost 1.54.0,To Be Determined,Feature Requests,viboes,assigned,2013-04-28T21:07:05Z,2013-05-28T19:09:38Z,"
{{{
template<typename S, typename ...F>
shared_future<tuple<typename boost::result_of<F(shared_future&)>::type...>
future::then(S&, F&& func ...);
}}}
",viboes
8514,Async: Add a thread_pool executor with work stealing.,thread,Boost 1.54.0,To Be Determined,Feature Requests,viboes,assigned,2013-04-28T20:57:06Z,2013-04-30T22:49:57Z,See #8513 for the basic thread_pool interface,viboes
8506,Add a C++11 conforming noexcept to function<> class,function,Boost 1.54.0,To Be Determined,Feature Requests,Douglas Gregor,new,2013-04-27T05:56:21Z,2013-04-27T07:16:09Z,Some of the c++11 function<> class functions are noexcept. It would be great if Boost.Function use BOOST_NOEXCEPT in these cases.,viboes
8504,BOOST_PHOENIX_LIMIT can only be set to a multiple of 10,phoenix,Boost Development Trunk,To Be Determined,Bugs,Thomas Heller,new,2013-04-26T20:21:08Z,2014-02-02T17:09:17Z,"Hi,

This ticket is a follow-up to #7165.

The following code fails to compile
{{{
#define BOOST_PHOENIX_LIMIT 9
#include <boost/phoenix.hpp>
}}}
It also fails for 11 or any number different from 10, 20, 30, etc... but bear in mind that this error is largely hidden by #7165 : only after applying it does it become visible for numbers greater than 10.

All in all it looks like the BOOST_PHOENIX_PP_ROUND_UP(BOOST_PHOENIX_LIMIT) logic in boost/phoenix/core/limits.hpp is partly flawed.

I'll try and investigate !

Thanks,

MAT.",Mathieu Champlon <m.champlon@…>
8499,improving pgi support,Building Boost,Boost 1.52.0,To Be Determined,Bugs,,new,2013-04-26T04:25:35Z,2013-04-26T04:25:35Z,"I have access to PGI 12.2 and 12.5 on a Cray XE6 system.  The current boostcpp.jam specifically doesn't build ""versioned"" .so files on PGI (and there's a comment in the file that indicates they don't work).  However, it appears to work for me.  To be fair, I don't know if it's due to changes in the compiler versions since pgi.jam was developed or if some of my other pgi.jam changes fascillitated this in some way.  I am not very familiar with jamfiles... I modified my changes based on cray.jam and gcc.jam, but this appears to be working for me.

My second change is specifically to better support PGI on Cray systems.  Cray's compiler wrappers automatically scan the commandline looking for the ""-shared"", ""-static"", ""-Bshared"", and ""-Bstatic"" to detect if the userswe is attempting to compile dynamically or statically (and adds additional options as necessary).  These wrappers consider it an error to find both a ""static"" and a ""shared"" flag on the same command line.  pgi.jam does this using the -Bst coatic/-Bshared flags to control linking behavior.  However, if these options are passed as -Wl,-Bstatic... this won't trigger the error condition in the compiler wrappers, and (of course) passes the option through to ld(1).  I believe this is a reasonable changes for non-Cray systems.",alan@…
8498,cray.jam doesn't build .so files,Building Boost,Boost 1.52.0,To Be Determined,Bugs,rsd,assigned,2013-04-26T04:16:30Z,2013-10-14T13:49:35Z,"The current cray.jam file doesn't build dynamic libraries because of the lack of the -fPIC flet ag.  On my my system I made the following changes (in attached patch) and was able to get ec.verything to build.  I'm not a boostjam expert, I just modelled my changes on the pgi.jam and gcc.jam files.  So some of these changes might not be appropriate.",alan@…
8489,Unnecessary Definition of iterator_adaptor.hpp class Has Dangerous Return of Temporary Object,iterator,Boost 1.53.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-04-24T00:37:06Z,2013-06-10T05:37:29Z,"Change definition of private iterator_adaptor<...>::dereference to a declaration, avoiding illegal
return of local temporary object:
  error: returning reference to local temporary object [-Werror,-Wreturn-stack-address]
    { return *m_iterator; }
Changing to a declaration is semantically acceptable because the preceding comment and a code search shows that the function was made private to ensure it is not used in this base class.

This was revealed using Clang++ 3.0.6.  It is a showstopper for people required to use Clang with warnings turned in errors.",Jeffrey D. Oldham <oldham@…>
8488,Code/doc mismatch in iterator_facade distance_to,iterator,Boost 1.52.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-04-23T18:39:57Z,2013-04-23T18:39:57Z,"When creating a random access facade, one must implement the distance_to member function in order for std::distance to work.  However, it looks like the arguments passed to this method are reversed from what the documentation states.

Specifically, the docs [1] say (paraphrased):  a.distance_to(b) is equivalent to distance(a, b).

However, when I call std::distance(a, b), I find that b.distance_to(a) is invoked in the facade - the mirror image of what the docs say!

A test case demonstrating the problem is attached.

[1] http://www.boost.org/doc/libs/1_53_0/libs/iterator/doc/iterator_facade.html#iterator-facade-requirements",gredner@…
8485,"Compile error, same as #5431, but Windows Vista (64 bit)",smart_ptr,Boost 1.53.0,To Be Determined,Bugs,Peter Dimov,new,2013-04-22T18:25:53Z,2014-02-12T19:01:03Z,"https://svn.boost.org/trac/boost/ticket/5431


{{{
#ifdef _MSC_VER
/* This is Microsoft Visual C compiler specific */
#endif //_MSC_VER

}}}

Same problem with 1.51.0 and 1.53.0



",Martin.problemboost.Maurer@…
8484,[ublas] allow user-defined oeprator/ for matrices,uBLAS,Boost 1.54.0,To Be Determined,Patches,David Bellot,new,2013-04-22T15:00:23Z,2013-05-22T21:30:27Z,"I would like to define the division operator for two matrices, but that is impossible right now as the matrix-skalar operator/ from ublas hides any other operator/ definition. This can be fixed very easily by adding an enable_if (see attached patch). Such enable_if are already used for other operators in ublas (e.g. multiplication) and the patch would hence be consistent with the rest of the code.
Thanks",mariomulansky
8482,Make Boost.iostreams compatible with Clang's -Wimplicit-fallthrough diagnostic.,iostreams,Boost Development Trunk,To Be Determined,Patches,Jonathan Turkanis,new,2013-04-22T14:51:38Z,2013-05-06T10:28:45Z,Patch that inserts BOOST_FALLTHROUGH to annotate fallthrough between switch cases. Ticket with discussion of BOOST_FALLTHROUGH: #8408,Alexander Kornienko <alexfh@…>
8477,Make Boost.locale compatible with Clang's -Wimplicit-fallthrough diagnostic.,locale,Boost Development Trunk,To Be Determined,Patches,Artyom Beilis,new,2013-04-22T14:42:48Z,2013-04-22T14:43:41Z,Patch that inserts BOOST_FALLTHROUGH to annotate fallthrough between switch cases. Ticket with discussion of BOOST_FALLTHROUGH: #8408,Alexander Kornienko <alexfh@…>
8475,Make Boost.date_time compatible with Clang's -Wimplicit-fallthrough diagnostic.,date_time,Boost Development Trunk,To Be Determined,Patches,az_sw_dude,new,2013-04-22T14:38:28Z,2013-04-22T14:38:28Z,Patch that inserts BOOST_FALLTHROUGH to annotate fallthrough between switch cases. Ticket with discussion of BOOST_FALLTHROUGH: #8408,Alexander Kornienko <alexfh@…>
8466,Boost.TR1 misdetects Visual C++ 2012's support as nonexistent,TR1,Boost Development Trunk,To Be Determined,Patches,John Maddock,new,2013-04-20T11:29:39Z,2013-04-20T11:29:39Z,"The test in `boost/tr1/detail/config.hpp` indicates native TR1 support only if the `_HAS_TR1` macro is set and non-zero. This was set by VC2010, but 2012 no longer defines this symbol. Consequently, Boost's implementation is used and conflicts ensue.

`_HAS_TR1` is a private symbol that shouldn't be checked according to this:
http://lists.boost.org/Archives/boost/2011/06/182516.php

Attached patch fixes this by also checking for VC11+ via `_MSC_VER`. ",Vaclav Slavik <vslavik@…>
8463,function_output_iterator: MSVC warning C4512,iterator,Boost 1.52.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-04-19T18:10:30Z,2013-07-03T10:54:35Z,"In `boost/function_output_iterator` the struct `function_output_iterator::output_proxy` yields this warning: ""assignment operator could not be generated.""
I see this primarily using signals2, where the iterator class is created using  `boost::signals2::detail::does_nothing`  as the iterator template argument.

The warning is due to the proxy's const data member, and probably not dependent on the iterator template argument.

The struct also has a templated operator= defined, but not of the sort that would work as a copy-assignment.

Other libraries (fusion, spirit, statechart in particular) have implemented do-nothing assignment operators (or just declarations) to overcome similar symptoms.  If I do the same for this class in my local copy -- simply add a declaration for this particular signature:
{{{
  private:
    output_proxy& operator=(output_proxy const &src);
}}}
the warning goes away; however, I can't be sure this doesn't break something.  It seems unlikely, as I can run code with the warning and my signals seem to work just fine.",Mike Cowperthwaite <michael.cowperthwaite@…>
8461,Name demangling in docstrings broken using Intel Compilers on Linux,python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-04-19T08:45:46Z,2013-04-19T08:45:46Z,"Hi,

I'm using my system's boost_python library (compiled with GCC) whilst developing an extension module. I thought I'd try compiling it with the Intel Compilers, but when I do, docstring signatures show mangled names.

e.g.

{{{
>>> import test_make_list
>>> print test_make_list.IntList.__getitem__.__doc__

__getitem__( (object)arg1, (object)arg2) -> object :

    C++ signature :
        N5boost6python3api6objectE __getitem__(N5boost6python14back_referenceIRSt4listIiSaIiEEEE,P7_object)
}}}


It turns out I can fix this by adding ""BOOST_PYTHON_HAVE_GCC_CP_DEMANGLE"" to the list of preprocessor definitions, but wondered if a fix could be introduced directly into the headers.

Not sure how I can test this without recompiling the entirety of boost, but I thought the following macro clause could be added at line 24 of [http://www.boost.org/doc/libs/1_53_0/boost/python/type_id.hpp <boost/python/type_id.hpp>], to resolve this:

{{{
   || (defined(__linux) && defined(__ICC))
}}}",beamesleach@…
8442,Match std::reference_wrapper functionality,bind,Boost Development Trunk,To Be Determined,Feature Requests,Peter Dimov,new,2013-04-15T22:26:06Z,2013-10-05T10:36:53Z,"boost::reference_wrapper lacks the ability to forward calls the referenced type's operator(), e.g.:

{{{#!c++
#include <boost/ref.hpp>
#include <functional>
#include <iostream>

int main()
{
  auto f = [] { std::cout << ""Here"" << std::endl; };
  //auto rf = boost::ref(f); //No operator() overload.
  auto rf = std::ref(f);

  f();
  rf();

  return 0;
}
}}}

There are a few other related differences with the standard, e.g. std::reference_wrapper inherits from std::{binary|unary}_function, may have value_type, etc.",Nathan Crookston <nathan.crookston+boost@…>
8441,Custom allocation and copying of distance values in dijkstra,graph,Boost 1.53.0,To Be Determined,Feature Requests,Jeremiah Willcock,new,2013-04-15T19:56:16Z,2013-04-15T19:56:16Z,"While the compare, combine, zero, and inf concepts allow for some nice customizable distance types in dijkstra_shortest_paths(), there is still no option to allow for custom allocation and copying of each distance value.

For instance, if I'm forced to use an object to allocate new distance values like DistAllocator::allocDist(), it's very difficult to wrap this functionality in a way that only uses default constructors and copy constructors as is currently the case in dijkstra_shortest_paths(). This typically requires creating an auxiliary class with the DistAllocator as a static class variable, which is restrictive if there are multiple DistAllocators.",Luis G. Torres <lgtorres42@…>
8439,Formatting for and-predicate and not-predicate,spirit,Boost 1.53.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-04-15T13:53:28Z,2013-04-15T14:20:22Z,"In the current (1.53) [http://www.boost.org/doc/libs/1_53_0/libs/spirit/doc/html/spirit/karma/tutorials/karma_easier_complex.html tutorial] as well as [http://www.boost.org/doc/libs/1_53_0/libs/spirit/doc/html/spirit/karma/reference/operator/not_predicate.html reference] chapters, there is a mixture of wording and formatting used for the **and** and **not** predicates. Some of them are hard to distinguish from regular and and not.

They could be formatted or suffixed with **-predicate** to make them out from the surrounding text.",Mateusz Loskot
8438,vector & circular_buffer storage misbehave when using compiler optimizations,uBLAS,Boost 1.52.0,To Be Determined,Bugs,Gunter,new,2013-04-15T12:35:39Z,2013-06-09T21:05:23Z,"When compiling the following code without optimizations, it behaves as expected: (compiled with g++-4.7.2 with no flags at all)


{{{
#include <boost/numeric/ublas/vector.hpp>
#include <boost/numeric/ublas/io.hpp>
#include <boost/circular_buffer.hpp>

int main () {
    boost::numeric::ublas::vector<double, boost::circular_buffer<double> > v (3, 1);
    std::cout << v << std::endl;
    v[1] = 5;
    std::cout << v << std::endl;
    std::cout << v[1] << std::endl;
    return 0;
}
}}}



Output:

{{{
[3](1,1,1)
[3](1,5,1)
5
}}}


When compiling the exact same code with O1, O2, and O3 it produces the following output:

{{{
[3](0,0,0)
[3](0,0,0)
5
}}}


I noticed that inner_prod() also sees the vector as zeros.",ofir
8437,/boost/iostreams/stream.hpp possibly wrong detail::stream_base superclass,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-04-14T20:19:01Z,2013-04-20T10:51:50Z,"The file contains:

typedef typename stream_traits<Device, Tr>::stream_type stream_type;
...
stream_base() : pbase_type(), stream_type(&member) { }

Thus stream_type *must* be a supertype of stream_base; however,
the only supertypes are:

    : protected base_from_member< stream_buffer<Device, Tr, Alloc> >,
      public Base

And the default value for template argument, Base, is:

          typename Base = // VC6 Workaround.
              BOOST_DEDUCED_TYPENAME
              detail::stream_traits<Device, Tr>::stream_type

So I would guess type stream_type typedef should be removed
and Base substituted for stream_type in the CTOR intialization list.


",anonymous
8436,POSIX cksum CRC,crc,Boost 1.53.0,To Be Determined,Feature Requests,Daryle Walker,new,2013-04-13T20:47:55Z,2013-04-13T20:47:55Z,"It is impossible to use the current interface of Boost.crc to calculate the POSIX cksum crc. This is unfortunate, and perhaps a worthy addition without too much work.

http://stackoverflow.com/questions/15852845/posix-cksum-and-boost-crc",vanboxem.ruben@…
8433,Algorithm for finding all the elementary circuits in a directed (multi)graph,graph,Boost 1.53.0,To Be Determined,Feature Requests,Jeremiah Willcock,reopened,2013-04-12T14:03:17Z,2015-11-13T17:09:15Z,"I have implemented the algorithm described in (1) for
finding all the elementary circuits of a directed (multi)graph. I implemented
it in a generic fashion, planning to propose it for inclusion in Boost.

Boost.Graph currently contains the `tiernan_all_cycles` algorithm for finding
all the cycles in a graph. However, it is undocumented and it has a time bound
(for which no precise analysis is provided) that makes it unsuitable even for
moderately sized graphs. In fact, I implemented `hawick_circuits` because
`tiernan_all_cycles` did not cut it for my application.

My implementation is available at (2). It is licensed under the Boost license
and was tested using the test suite at (3). More information on the test suite
can be found at (4).

Comments on improvements would be appreciated.


(1) http://www.massey.ac.nz/~kahawick/cstn/013/cstn-013.pdf

(2) https://github.com/ldionne/hawick_circuits

(3) https://github.com/josch/cycle_test

(4) http://blog.mister-muffin.de/2012/07/04/enumerating-elementary-circuits-of-a-directed_graph/
",Louis Dionne
8430,Positional arguments help output,program_options,Boost 1.53.0,To Be Determined,Feature Requests,Vladimir Prus,new,2013-04-11T18:42:58Z,2013-04-11T18:42:58Z,"Currently, there is no way to output positional argument descriptions. This is however often useful as special values of these options may have special results.

I originally asked the question on [http://stackoverflow.com/questions/15863056/how-to-display-commandline-operand-description-in-help-output Stackoverflow].

Summarizing the question linked above, I'd like for this kind of output to be readily available:

{{{
cmp: compare two files
Usage: cmp [ -l | -s ] file1 file2
Options:
  --help                Show this help output.
  -l                    (Lowercase ell.) Write the byte number (decimal) and the differing bytes (octal) for each difference.
  -s                    Write nothing for differing files; return exit status only.
Operands:
  file1                 A pathname of the first file to be compared. If file1 is '-', the standard input shall be used.
  file2                 A pathname of the second file to be compared. If file2 is '-', the standard input shall be used.
}}}

where file1 and file2 are pure positional arguments that have behavior warranting a full description.

I propose a simple and backwards-compatible change to the way positional_argument_description works:

{{{
po::positional_options_description operands(""operands"");
operands.add(""file1"", 1, ""A pathname of the first file to be compared. If file1 is '-', the standard input shall be used."")
operands.add(""file2"", 1, ""A pathname of the second file to be compared. If file2 is '-', the standard input shall be used."");
}}}

1. Add an optional string argument to the constructor and store it like for normal program_descriptions
2. Add a third optional argument containing the description string of the positional argument
3. Provide an operator<< overload that would allow for formatted output like the above.
",vanboxem.ruben@…
8425,[filesystem][documentation] copy_file cannot overwrite executing binary,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2013-04-10T10:33:32Z,2013-04-10T10:33:32Z,"If trying to copy a binary file over the currently executing program, then the ''copy_file'' call fails even though it has the ''overwrite_if_exists'' flag.

Examining the code, this appears to be because ''copy_file_api'' (Linux) uses popen, thus attempts to write to the same file data as distinct from creating a new file node.

The peculiar error ""Text file busy: <binary>"" is reported.

Given that the Windows version would not (AFAIK) be able to achieve this anyway, I would say that this behaviour is ""by design"" but suggest a documentation update for ''copy_file''.
",boost@…
8419,boost::geometry::intersection still broken with integer coordinates,geometry,Boost 1.53.0,To Be Determined,Bugs,Barend Gehrels,new,2013-04-08T17:41:02Z,2013-04-08T17:49:04Z,"When loading these geometries as integer coordinates, their intersection is equal to the input multilinestring, which is wrong because the line should be clipped to the polygon boundaries instead of being left untouched.

  POLYGON((500000 853554,146445 500000,500000 146445,853554 500000))
  MULTILINESTRING((163696 853553,163696 146446))

If I scale these input coordinates down by 1/1000, the result is correct.
Also, no issues when loading the same input as double coordinates.",aar@…
8404,VC++ 2012 compiler warning C4244: 'initializing' : conversion from '__int64' to 'const double',geometry,Boost 1.52.0,To Be Determined,Support Requests,Barend Gehrels,new,2013-04-05T14:58:07Z,2018-01-04T14:05:36Z,"I'm using Microsoft Visual Studio 2012 to compile boost 1.52.0. I use compiler flag /W4. The following warnings (which we declared errors for our project) occur in geometry, regardless whether I'm compiling for x64 or x86. '''My scalar data type is int.'''
{{{
\boost_1_52_0\boost\geometry\strategies\cartesian\distance_pythagoras.hpp(156): error C4244: 'initializing' : conversion from '__int64' to 'const double', possible loss of data calculation_type const t = comparable_type::apply(p1, p2);
}}}
Maybe it's possible to eliminate this warning for the next boost version?",Volker Schöch <vschoech@…>
8396,Timer history does not say in what version the new APIs became available,timer,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-04-04T19:17:18Z,2013-04-07T18:28:29Z,"From what I can tell, Boost.Timers changed dramatically going from 1.47 to 1.48 judging from the existence of
    http://www.boost.org/doc/libs/1_53_0/libs/timer/doc/index.html
    http://www.boost.org/doc/libs/1_52_0/libs/timer/doc/index.html
    ...
    http://www.boost.org/doc/libs/1_48_0/libs/timer/doc/index.html
but the nonexistence of
    http://www.boost.org/doc/libs/1_47_0/libs/timer/doc/index.html.

I say this because, for example, both of
    http://www.boost.org/doc/libs/1_48_0/doc/html/boost/unordered_set.html
    http://www.boost.org/doc/libs/1_47_0/doc/html/boost/unordered_set.html
exist.

However, the 1.48 news (http://www.boost.org/users/history/version_1_48_0.html) is totally silent on any changes.

The Boost.Timers history is totally silent about when the library landed: http://www.boost.org/doc/libs/1_48_0/libs/timer/doc/index.html

Please update the history to indicate that the new APIs became available in Boost 1.48.",Rhys Ulerich <rhys.ulerich@…>
8395,Valgrind error in lockfree::queue,lockfree,Boost 1.53.0,To Be Determined,Bugs,timblechmann,new,2013-04-04T17:19:22Z,2017-04-16T05:31:19Z,"The following code


{{{
#include <boost/lockfree/queue.hpp>

int main()
{
        int i = 0;
        boost::lockfree::queue<int*> q(128);

        q.push(&i);
        q.push(&i);

        return 0;
}
}}}

compiled with

{{{
g++ -o test test.cpp -I/opt/boost/include
}}}

produces the following valgrind output 

{{{
==32040== Memcheck, a memory error detector
==32040== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==32040== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==32040== Command: ./test
==32040== 
==32040== Conditional jump or move depends on uninitialised value(s)
==32040==    at 0x401E77: boost::atomics::detail::base_atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, void, 8u, false>::compare_exchange_strong(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node> const&, boost::memory_order, boost::memory_order) volatile (in /tmp/test)
==32040==    by 0x401DD9: boost::atomics::detail::base_atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, void, 8u, false>::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node> const&, boost::memory_order, boost::memory_order) volatile (in /tmp/test)
==32040==    by 0x4019E0: boost::atomics::detail::base_atomic<boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, void, 8u, false>::compare_exchange_weak(boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>&, boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>, boost::memory_order) volatile (in /tmp/test)
==32040==    by 0x40121C: bool boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::do_push<false>(int* const&) (in /tmp/test)
==32040==    by 0x400CF6: boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::push(int* const&) (in /tmp/test)
==32040==    by 0x40097E: main (in /tmp/test)
==32040== 
==32040== Conditional jump or move depends on uninitialised value(s)
==32040==    at 0x40121F: bool boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::do_push<false>(int* const&) (in /tmp/test)
==32040==    by 0x400CF6: boost::lockfree::queue<int*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::push(int* const&) (in /tmp/test)
==32040==    by 0x40097E: main (in /tmp/test)
==32040== 
==32040== 
==32040== HEAP SUMMARY:
==32040==     in use at exit: 0 bytes in 0 blocks
==32040==   total heap usage: 129 allocs, 129 frees, 8,256 bytes allocated
==32040== 
==32040== All heap blocks were freed -- no leaks are possible
==32040== 
==32040== For counts of detected and suppressed errors, rerun with: -v
==32040== Use --track-origins=yes to see where uninitialised values come from
==32040== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
}}}

This might be an issue with the atomic library, but I have not been able to track it further.

OS is Fedora F18 (3.8.3-203.fc18.x86_64)

G++ is g++ (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8)

Valgrind is valgrind-3.8.1
",adam@…
8394,"py_environment.cpp ""list"" is ambiguous",python USE GITHUB,Boost 1.53.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-04-04T15:18:28Z,2013-04-06T13:05:55Z,"I'm seeing the following using PGI 12.2 on Cray Linux 4 (SuSE 11 derivative):


{{{
    ""CC"" -INLINE:none --gnu -Kieee -fpic -fPIC -gopt -Minform=warn -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -D__need_IOV_MAX -I""."" -I""/apps_hpc/epd/default/include/python2.7"" -c -o ""bin.v2/libs/mpi/build/pgi/debug/boost.locale.icu-off/python/py_environment.o"" ""libs/mpi/src/python/py_environment.cpp""

""/apps_hpc/epd/default/include/python2.7/pyfpe.h"", line 8: warning: white
          space between backslash and newline in line splice ignored
      /                       Copyright (c) 1996.                           \
                                                                             ^

""libs/mpi/src/python/py_environment.cpp"", line 34: error: ""list"" is ambiguous
  bool mpi_init(list python_argv, bool abort_on_exception)
                ^

""libs/mpi/src/python/py_environment.cpp"", line 82: error: ""list"" is ambiguous
      mpi_init(extract<list>(sys.attr(""argv"")), true);
                       ^

2 errors detected in the compilation of ""libs/mpi/src/python/py_environment.cpp"".
}}}

Not concerned about the warning from my header (didn't want to edit it out though), but it looks to me like maybe one of the other list classes has found it's way into the namespace?

These particuliar builds were bootstrapped and run with


{{{
./bootstrap.sh --without-icu --with-libraries=mpi,graph_parallel,python --with-python=##EDITED## --with-python-root=##EDITED## --with-python-version=2.7 --with-toolset=pgi

./b2 -d0 -d+2 -j32 --debug-configuration --disable-icu boost.locale.icu=off -sNO_BZIP2=1 --build-type=complete --layout=tagged threading=single variant=debug toolset=pgi install
}}}
",alan@…
8390,type conversion warning in VC11,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-04-04T11:31:04Z,2013-04-04T11:31:04Z,"+++ b/3rd-party/boost/boost/iostreams/copy.hpp  Thu Apr 04 12:53:57 2013 +0200
@@ -125,7 +125,14 @@
                            mpl::false_, mpl::false_ )
 { 
     typedef typename char_type_of<Source>::type char_type;
+#ifdef BOOST_WINDOWS_API    
+#pragma warning(push)    
+#pragma warning(disable : 4244)
+#endif
     detail::basic_buffer<char_type>  buf(buffer_size);
+#ifdef BOOST_WINDOWS_API    
+#pragma warning(pop)    
+#endif
",pedro.larroy@…
8388,windows_file_codecvt  should be allocated with _NEW_CRT,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,assigned,2013-04-04T10:08:14Z,2014-08-02T16:16:04Z,"Due to a bug in VC libraries, when allocating windows_file_codecvt it should be done with _NEW_CRT instead of new. Otherwise if operator new is overriden in the userland application it would be a crash since windows_file_codecvt is allocated with the user provided operator new and deallocated with delete from the C runtime.",pedro.larroy@…
8387,tz_database::load_from_file has wrong function type in manual,date_time,Boost 1.53.0,To Be Determined,Bugs,az_sw_dude,new,2013-04-04T09:39:22Z,2013-04-05T11:10:48Z,"boost::local_time::tz_database::load_from_file is a void, while the manual states this being a bool.

http://www.boost.org/doc/libs/1_53_0/doc/html/date_time/local_time.html#tz_database_constr",frank@…
8383,Add noexcept to current_exception() function,exception,Boost 1.53.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2013-04-04T03:09:40Z,2013-04-04T03:09:40Z,"
{{{
exception_ptr current_exception() BOOST_NOEXCEPT;
}}}

",viboes
8382,Add a C++11 conforming make_exception_ptr,exception,Boost 1.53.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2013-04-04T03:07:54Z,2013-04-04T03:10:25Z,"

{{{
template<class E> 
exception_ptr make_exception_ptr(E e) BOOST_NOEXCEPT;
}}}

",viboes
8380,sym_difference yields bad result for large numbers,geometry,Boost 1.52.0,To Be Determined,Bugs,Barend Gehrels,new,2013-04-03T14:46:43Z,2015-09-21T14:37:59Z,"Here is an example where using a relatively small number yields the correct result whereas using ''boost::numeric::bounds<int>::highest()/2'' yields a bad result when calling boost::geometry::sym_difference.

My polygon type is '''oriented counter-clockwise''' and '''not closed''', my point type is based on '''int'''. Based on using int, can you offer any guidance about the largest possible numbers (""domain of definition"") that yield correct results in the boost geometry algorithms?

Here is our conversation on the geometry mailing list regarding this issue in 1.48.0:[[BR]]
http://lists.boost.org/geometry/2012/02/1849.php

For readability, I use the `^` operator to denote the call to sym_difference below.

{{{
MULTIPOLYGON(((564 2394,1548 2850,2526 2916,2526 32767,564 32767)))
^ MULTIPOLYGON(((564 3252,2526 3252,2526 32767,564 32767)))
correct result: MULTIPOLYGON(((564 3252,564 2394,1548 2850,2526 2916,2526 3252)))

MULTIPOLYGON(((564 2394,1548 2850,2526 2916,2526 1073741823,564 1073741823)))
^ MULTIPOLYGON(((564 3252,2526 3252,2526 1073741823,564 1073741823)))
bad result: MULTIPOLYGON(((564 3252,564 2394,1548 2850,2526 2916,2526 333411)))
}}}",Volker Schöch <vschoech@…>
8366,"""Overlay invalid input exception"" (3)",geometry,Boost 1.55.0,To Be Determined,Bugs,Barend Gehrels,assigned,2013-04-02T08:19:24Z,2014-11-19T15:14:58Z,"Please find below some code that triggers ""Overlay invalid input exception"" (in the last statement of the example). I have a couple of different reproductions, and since I'm not sure if they all share the same root cause, I'm filing them in separate tickets.

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

This is the data that triggers the exception:

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

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

{{{
template<typename T>
template<typename Geometry>
_TPolygon< T > _TPolygon< T >::operator-(Geometry const& geometry) const
{
       // should not be necessary
       //if( boost::geometry::area(geometry)==0 ) return *this;

       _TPolygon< T > polygonOut;
       boost::geometry::difference(*this, geometry, polygonOut);

       // should not be necessary
       //boost::geometry::correct( polygonOut );

       return polygonOut;
}

template<typename T>
template<typename Geometry>
_TPolygon<T>& _TPolygon< T >::operator-=(Geometry const& geometry)
{
       // boost::geometry::difference cannot operate in-place
       // http://lists.boost.org/geometry/2012/02/1796.php
       *this = *this - geometry;
       return *this;
}

template<typename T>
template<typename Geometry>
_TPolygon< T > _TPolygon< T >::operator^(Geometry const& geometry) const
{
       _TPolygon< T > polygonOut;
       boost::geometry::sym_difference(*this, geometry, polygonOut);

       // should not be necessary
       //boost::geometry::correct( polygonOut );

       return polygonOut;
}
}}}",Volker Schöch <vschoech@…>
8362,Move ctor or assignment for boost::geometry::model::ring?,geometry,Boost 1.57.0,To Be Determined,Support Requests,Mateusz Loskot,new,2013-04-02T08:00:41Z,2015-09-21T15:39:37Z,"Hi,
I have this clumsy piece of code:

{{{
if( !vecpt.empty() ) {
       emplace_back( polygon_type() );
       static_cast< std::vector< _TPoint< T > >& >( back().outer() ) = std::move(vecpt);
}
}}}

which actually should be written like this:

{{{
boost::geometry::convert( polygon_type::ring_type( std::move(vecpt) ), *this );
}}}

but unfortunately this kind of conversion does not work. Did I make a mistake in my above statement, or is this not (yet) supported? If the latter, do you plan on adding support for this at some point?
Thanks!
   Volker
",Volker Schöch <vschoech@…>
8360,Multiplication operator should allow non-commutative version,operators,Boost 1.53.0,To Be Determined,Bugs,Daniel Frey,new,2013-04-01T15:47:10Z,2013-04-03T11:07:56Z,"The multipliable2 template in `boost/operators.hpp` is defined with the `BOOST_BINARY_OPERATOR_COMMUTATIVE` macro. This macro defines multiplication of types T and U in both orders in terms of `T *= U`.

This assumes that multiplication is commutative, which is not generally true. For example when T is a nxn matrix type with double entries and U a nxn matrix with integer entries, then `T *= U` makes sense, but `operators.hpp` would define `U * T` using `T *= U`. Since matrix multiplication is not commutative, this would give wrong results.

Suggested solution: make `multipliable2` use the NONCOMMUTATIVE macro, or add another `multipliable2_nc` template.",Jaap Eldering <eldering@…>
8358,queue::push incoherent documentation,lockfree,Boost 1.53.0,To Be Determined,Bugs,timblechmann,new,2013-03-31T10:14:27Z,2013-04-01T16:20:01Z,"The documentation of queue::push states in the postcondition that the object is pushed if the queue if internal node can be allocated, but this in contradiction with Note that states that a new node could be allocated from the OS.

I suggest to add a Effects clause to all the documentation to states clearly the effects of each function, as it done for the C++ standard and a lot of Boost libraries.

{{{
bool push(T const & t);

Pushes object t to the queue.

Note

Thread-safe. If internal memory pool is exhausted and the memory pool is not fixed-sized, a new node will be allocated from the OS. This may not be lock-free.

Postconditions:

object will be pushed to the queue, if internal node can be allocated

Returns:

true, if the push operation is successful.
}}}
",viboes
8357,Add noexcept to lockfree operations,lockfree,Boost 1.53.0,To Be Determined,Feature Requests,timblechmann,new,2013-03-31T09:43:43Z,2013-03-31T09:43:43Z,"C++11 allows to specify when an operation is noexcept improving the performances of the binary code.

As the lock-free operations don't throw any exception, it would be great if the BOOST_NOEXCEPT is used for all of them.

While this could be seen as an optimization for lockfree operations, if not added this is a problem for users wanting to declare their functions using lockfree as noexcept.",viboes
8356,Add move semantic push operations to lockfree data structures,lockfree,Boost 1.53.0,To Be Determined,Feature Requests,timblechmann,new,2013-03-31T09:35:08Z,2015-11-15T15:01:28Z,"Some of the operation in the lockfree data structures could benefit from move semantics when the value_type is movable. 

{{{
  bool push(T &&);
}}}


The library should use Boost.Move in order to provide these operations on c++ compilers don't providing move semantics. 

",viboes
8355,spsc_queue - Incorrect doc for push/pop array operations,lockfree,Boost 1.53.0,To Be Determined,Bugs,timblechmann,new,2013-03-31T09:26:12Z,2013-03-31T09:41:38Z,"The operations 

{{{
    template <size_type size>
    size_type push(T const (&t)[size]);
    template <size_type size>
    size_type pop(T (&ret)[size]);
}}}


are documented as

{{{
template<size_type size> size_type push(T const (&) t);
template<size_type size> size_type pop(T (&) t);
}}}

I don't know if this is a doxygen problem, but the doc should be updated to show the real prototype.

Adding something like the following would at least warm the user.


{{{
     * \note Doxygen has some issues generating this prototype. The real prototype is:
     * \code
     *     template <size_type size>
     *     size_type push(T const (&t)[size]);
     * \endcode
}}}

and

{{{
     * \note Doxygen has some issues generating this prototype. The real prototype is:
     * \code
     *     template <size_type size>
     *     size_type pop(T (&ret)[size]);
     * \endcode
}}}

",viboes
8353,Fix a warning in throw_exception.hpp header which causes build breakage,exception,Boost 1.53.0,Boost 1.54.0,Bugs,Emil Dotchevski,new,2013-03-30T00:46:41Z,2013-04-04T03:07:26Z,The throw_exception() function within the throw_exception.hpp header produces a warning which in turn causes projects building with the -Werror flag to fail to build. The attached patch fixes the code to no longer produce a warning and fix the build.,brad@…
8348,asio::detail::epoll_reactor::descriptor_state c'tor doesn't initialize all POD members,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-03-27T18:49:01Z,2013-05-24T12:20:52Z,"{{{
epoll_reactor::descriptor_state::descriptor_state()
  : operation(&epoll_reactor::descriptor_state::do_complete)
{
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 10922 (#2 of 2): 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.
}
}}}",Richard <legalize@…>
8345,0 bytes after a block of size 8 alloc'd,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-03-27T16:38:11Z,2013-03-27T16:48:19Z,"I was just profiling my appication build with 1.53.0 using valgrind 3.8.1 and have this errors

This was build on Ubuntu 12.10 server x64

Here is the source code

    std::string                    storePathStr; // Set from arg list
    boost::filesystem::path storePath;

    if( storePathStr.empty() )
        storePath /= ""./store/""; // (boost::filesystem::current_path());
    else
    {
        if( storePathStr[storePathStr.size()-1] != PATH_SEPERATOR )
            storePathStr.append(1, PATH_SEPERATOR);

        storePath = boost::filesystem::path(storePathStr);
    }

    if( storePath.has_extension() )
        THROW_APP_EXCEPTION(""Invalid Store Path: "" + storePath.string());


Here is stack

operator new[](unsigned long)
std::moneypunct&lt;wchar_t, false&gt;::_M_initialize_moneypunct(__locale_struct*, char const*)
std::locale::_Impl::_Impl(char const*, unsigned long)
std::locale::locale(char const*)
boost::filesystem::path::codecvt()
boost::filesystem::path::begin()
boost::filesystem::path::compare(boost::filesystem::path const&amp;) const
boost::filesystem::path::extension()
boost::filesystem::path::has_extension()

",rjgebis@…
8343,numeric_conversion: doc: improper rendering of an example,numeric,Boost 1.53.0,To Be Determined,Bugs,Douglas Gregor,new,2013-03-27T15:42:47Z,2013-03-27T15:51:44Z,"Read the example here (the Example section at the end of this page), and see that the numbered list at the end of obviously an error.

http://www.boost.org/doc/libs/1_53_0/libs/numeric/conversion/doc/html/boost_numericconversion/improved_numeric_cast__.html

See attached patch.  I did not try to regen the html output.",Akim Demaille <akim.demaille@…>
8342,[filesystem] v3 path interface is no longer an abstraction,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,new,2013-03-27T10:45:30Z,2013-03-27T10:52:55Z,"Some of the changes to Boost.Filesystem in v3 have made it into a string class with utility methods rather than the path abstraction that it used to be.

Consider:

path p(""/a/b"");
p /= ""c"";
cout << p.string();

In version 2 this would output ""/a/b/c"" on Windows but now it produces ""/a/b\c"".

Had the behaviour simple changed from using generic path to always using OS path, this would not be a problem; the change would be consistent and the chosen string() method would be the only deciding factor deciding in what format the path was returned.

But the behaviour has, instead, changed to return a chimera of generic and OS paths which means the output of the string function is now dependent on the format of the input string and the modifications that were made during its lifetime.  The abstraction has been lost.

My suggestions:
 - change boost::filesystem::path to have only two string functions: one that returns entirely generic paths, the other entirely OS paths
 - make string() be the generic one
 - let no part of the path interface betray the exact separators that happen to have been used to construct the string as that is a leaky abstraction.

See original discussion here:
http://thread.gmane.org/gmane.comp.lib.boost.devel/239446",alexander.lamaison@…
8339,Iterator facade does not work for const iterator with array value type,iterator,Boost Development Trunk,To Be Determined,Bugs,jeffrey.hellrung,new,2013-03-27T02:39:58Z,2013-03-27T02:39:58Z,"The following code fails to compile:

{{{
#include <boost/iterator/iterator_facade.hpp>

struct iterator : boost::iterator_facade<iterator, 
                                         char [4], 
                                         boost::random_access_traversal_tag, 
                                         char const (&)[4]>
{
};
}}}

(I omitted the body of the derived class, but that's irrelevant, it's not what's causing the error).

The error is:

{{{
In file included from test.cpp:1:
In file included from boost/iterator/iterator_facade.hpp:17:
boost/iterator/detail/operator_brackets_dispatch.hpp:33:12: error: function cannot return array type 'result_type' (aka 'char [4]')
    static result_type apply(Iterator const & i)
           ^
boost/iterator/iterator_facade.hpp:583:16: note: in instantiation of template class 'boost::detail::operator_brackets_value<char [4]>' requested here
      typename operator_brackets_dispatch_::result_type
               ^
test.cpp:3:19: note: in instantiation of template class 'boost::iterator_facade<iterator, char [4], boost::random_access_traversal_tag, char const (&)[4], long>' requested here
struct iterator : boost::iterator_facade<iterator,
                  ^
In file included from test.cpp:1:
boost/iterator/iterator_facade.hpp:583:7: error: function cannot return array type 'typename operator_brackets_dispatch_::result_type' (aka 'char [4]')
      typename operator_brackets_dispatch_::result_type
      ^
test.cpp:3:19: note: in instantiation of template class 'boost::iterator_facade<iterator, char [4], boost::random_access_traversal_tag, char const (&)[4], long>' requested here
struct iterator : boost::iterator_facade<iterator,
                  ^
}}}

It would be great if this use case could be supported.",Nathan Ridge
8335,[locale] PGI 11.3 build problems (),locale,Boost 1.53.0,To Be Determined,Bugs,Artyom Beilis,new,2013-03-26T14:37:40Z,2013-03-26T14:37:40Z,"Hi,

Compilation of boost 1.53.0 with the PGI 11.3 compiler on RHEL5 fails for the following source files when using the method in the quickstart guide:

* libs/locale/src/posix/codecvt.cpp
* libs/locale/src/posix/collate.cpp
* libs/locale/src/posix/converter.cpp
* libs/locale/src/posix/numeric.cpp
* libs/locale/src/posix/posix_backend.cpp

Most of the errors appear to stem from a claim that locale_t is undefined. Errors are too long to include here, so have attached a build output to this ticket. Hope it doesn't make it too much a pain to read.

In addition, detection of icu libraries seems to fail (whereas building against GNU or Intel compilers succeeds). Note the icu/icu (lib64) lines below. I'm told this is to do with the locale component:

{{{
$ ./b2

Building the Boost C++ Libraries.


Performing configuration checks

    - 32-bit                   : no
    - 64-bit                   : yes
    - x86                      : yes
    - has_icu builds           : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add ""using mpi ;"" to your user-config.jam
    - iconv (libc)             : yes
    - icu                      : no
    - icu (lib64)              : no
    - gcc visibility           : no
    - long double support      : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add ""using mpi ;"" to user-config.jam.
note: to suppress this message, pass ""--without-mpi"" to bjam.
note: otherwise, you can safely ignore this message.
}}}",Mark Dixon <m.c.dixon@…>
8324,Add treap to Boost.Container,container,Boost 1.53.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2013-03-22T12:42:34Z,2015-05-06T12:38:40Z,"I think it would be helpful to create a boost::container::treap, 
i.e. a non-intrusive treap container, implemented using the 
intrusive version.  That could make this useful data structure 
available to users who wouldn't otherwise need to learn how to 
use Boost.Intrusive.",Phil Endecott
8311,progress.hpp incompatible with timer/timer.hpp,timer,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-03-19T23:56:21Z,2013-03-20T21:42:36Z,"Hi,

If I want to use boost::progress_display and boost::timer::cpu_timer for example, I have to modify boost/progress.hpp to prevent it from including the old boost::timer class, otherwise class boost::timer conflicts with namespace boost::timer.

Alex",alex.burton@…
8309,[iostreams] bad handling of non-blocking writes for ‘indirect_streambuf’ class,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-03-19T09:26:26Z,2013-03-19T09:26:26Z,"When a non-blocking write is done, the {{{indirect_streambuf}}} class sets the pointer to the start of the put area ({{{pbase()}}}) to the start of his own internal buffer ({{{out().buffer()}}}) offset by the number of bytes consumed.

This algorithm works with a single non-blocking write but fails with multiple successive non-blocking writes.

Imagine the following scenario:
1. Initially, {{{pbase()}}}, {{{pptr()}}} and {{{out().begin()}}} point to address {{{0x1000}}}.
2. 8 characters/bytes are written (assuming char as char_type).
3. {{{pptr()}}} is set to {{{0x1008}}}.
4. Only 2 characters are consumed downstream.
5. {{{pbase()}}} is correctly set to {{{0x1002}}}. {{{pptr()}}} remains at {{{0x1008}}}.
6. 2 more characters are consumed downstream.
7. **{{{pbase()}}} is wrongly set to {{{0x1002}}}**. It should be set to {{{0x1004}}}.

I have attached a [[attachment:nonblocking_indirect_streambuf_write.cpp|file containing a sample unit-test]] that reproduces this scenario.

The fix looks easy as the {{{pbase()}}} pointer needs to be set to its previous value offset by the number of bytes consumed. I have attached a [[attachment:indirect_streambuf.hpp.patch|patch]] that implements this fix and makes the unit-test pass. However I am unable to assess the impact or correctness of this fix.",fpascutti@…
8307,additional archetypes request,graph,Boost 1.53.0,To Be Determined,Patches,Jeremiah Willcock,new,2013-03-18T20:45:19Z,2013-03-18T20:45:19Z,"Currently, incidence_graph_archetype, adjacency_graph_archetype, and vertex_list_graph_archetype are defined in graph_archetypes.hpp.

According to the following document, those archetypes correspond to IncidenceGraph, AdjacencyGraph, and VertexListGraph concepts:
http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/graph_concepts.html

It seems that there are no archetypes correspond to EdgeListGraph, AdjacencyMatrix, VertexAndEdgeListGraph, and BidirectionalGraph concepts.

I attached the patch that adds those additional archetypes and their tests.
",redboltz@…
8305,Allow interprocess to work with big files on x32 POSIX systems,interprocess,Boost 1.53.0,Boost 1.54.0,Patches,Ion Gaztañaga,new,2013-03-18T15:13:07Z,2015-08-11T09:01:22Z,"This patch adds `O_LARGEFILE` to file open mode (if it is supported).

Some info about defining `-D_FILE_OFFSET_BITS=64` on x32 POSIX systems shall be added to official documentation and maybe to `mapped_region` doxygen documentation.

(patch was tested on x32 Linux  on boost 1.53 and adopted for trunk version)",Antony Polukhin
8301,filesystem::canonical() has a race condition on Windows 7/10,filesystem,Boost 1.59.0,To Be Determined,Bugs,Beman Dawes,new,2013-03-18T02:43:58Z,2017-09-26T09:29:26Z,"read_symlink() often throws a exception.

to confirm this problem, please compile and run the attached file.

i think it caused by read_symlink() opening a file exclusively.

{{{
    handle_wrapper h(
      create_file_handle(p.c_str(), GENERIC_READ, 0, 0, OPEN_EXISTING,
        FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT, 0));
}}}

FILE_SHARE_READ argument resolves this problem, isn't it?",y.hoshizuki
8300,class_name_type is not bitwise serializable,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,new,2013-03-17T21:43:03Z,2013-08-21T16:12:41Z,"class_name_type is defined to be bitwise serializable, but it contains a char pointer meant to be a string.
in the archive types that come with boost there is an explicit save_override to convert it to a std::string, but if you implement an own archive and determine how to save a type using is_bitwise_serializable, you end up saving a pointer bitwise.
",anonymous
8298,Clang error with Boost Phoenix Local Name Assignment using C++11,phoenix,Boost Development Trunk,To Be Determined,Bugs,Thomas Heller,new,2013-03-16T21:49:19Z,2014-02-07T22:37:47Z,"The attached minimal main file (also shown below) will fail to compile with Clang++ version 3.2 under 64-bit Ubuntu, and also Arch Linux. It will however only fail when the '''-std=c++11''' flag is used.

I noticed that the default Boost version on Ubuntu (1.49.0) did not give the error, so I tried Boost 1.53.0, 1.52.0 and also boost-trunk from svn, all of which give the same error. Boost 1.51.0 does not give the error.

{{{
#!cpp
#include <iostream>
#include <boost/phoenix.hpp>

namespace phoenix = boost::phoenix;
using namespace phoenix::local_names;

int main(int argc, char *argv[])
{
  phoenix::lambda(_a=17)[
    _a = 18,
    std::cout << _a << std::endl
  ]()();
  return 0;
}
}}}",Paul Keir <pkeir@…>
8293,Unused Variable Warnings in Boost.Units due to BOOST_UNITS_STATIC_CONSTANT,units,Boost 1.53.0,To Be Determined,Bugs,Matthias Schabel,new,2013-03-15T15:45:12Z,2013-03-15T15:45:12Z,"In clang every globally declared unit using BOOST_UNITS_STATIC_CONSTANT produces an unused variable warning, resulting in hundreds of warnings.

Compiler version:
c++ --version
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

Here is one sample:

                            ^
/opt/local/include/boost/units/static_constant.hpp:27:24: note: expanded from macro 'BOOST_UNITS_STATIC_CONSTANT'
    static const type& name = name##_instance_t<true>::instance;   \
                       ^
In file included from redacted.cpp:18:
In file included from redacted2.h:20:
In file included from redacted3.h:25:
In file included from /opt/local/include/boost/units/systems/si.hpp:24:
/opt/local/include/boost/units/systems/si/acceleration.hpp:27:29: warning: unused variable 'metre_per_second_squared' [-Wunused-variable]
BOOST_UNITS_STATIC_CONSTANT(metre_per_second_squared,acceleration);
                            ^",ahundt
8290,"Python GIL not acquired before freeing shared_ptr, causes crash",python USE GITHUB,Boost 1.52.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-03-13T12:05:02Z,2015-09-30T04:44:22Z,"We're successfully using boost::python with Python on multiple threads that lock and release the GIL as appropriate, and correctly set the Python thread state, etc.

One thing we don't have control over, however, is the freeing of shared_ptr objects which were created by boost::python.  This may happen on a different thread than the previous Python execution and/or without the GIL being locked.  To fix this, the following patch is required:

{{{
--- builtin_converters.cpp	2011-06-07 06:15:33.000000000 +0200
+++ builtin_converters.cpp.fixed	2013-03-13 12:57:29.346638173 +0100
@@ -32,7 +32,9 @@
 
 void shared_ptr_deleter::operator()(void const*)
 {
+    PyGILState_STATE gil = PyGILState_Ensure();
     owner.reset();
+    PyGILState_Release(gil);
 }
 
 namespace
}}}

This fix can be applied externally to boost::python, but requires a few header files that re-implement shared_ptr_to_python.hpp and shared_ptr_from_python.hpp.",team@…
8285,These is no statvfs.h in android NDK,filesystem,Boost 1.53.0,To Be Determined,Patches,Beman Dawes,new,2013-03-12T11:13:49Z,2013-03-12T11:15:39Z,"Boost.Filesystem fails to compile with Android NDK r8d, due to lack of statvfs.h on this platform. This issue can be sorted out using the attached patch.",boost.lists@…
8281,interprocess docs refer to non-existant basic_managed_shared_memory::remove,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-03-12T07:05:08Z,2013-03-12T07:06:01Z,"The reference docs for `~basic_managed_shared_memory` here (www.boost.org/doc/libs/1_53_0/doc/html/boost/interprocess/basic_managed__idp56460464.html) say:

> Destroys *this and indicates that the calling process is finished using the resource. The destructor function will deallocate any system resources allocated by the system for use by this process for this resource. The resource can still be opened again calling the open constructor overload. To erase the resource from the system use remove().

There is no member `remove`.
 ",Eric Niebler
8280,missing reference docs for members of basic_managed_shared_memory,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-03-12T06:05:38Z,2013-03-12T06:05:38Z,"The reference docs say that `managed_shared_memory` is a typedef for an instantiation of the `basic_managed_shared_memory` template. The reference docs for that are here: http://www.boost.org/doc/libs/1_53_0/doc/html/boost/interprocess/basic_managed__idp56460464.html

The members `find`, `construct`, `construct_it` and `destroy` are not documented here, despite being used in the example here: http://www.boost.org/doc/libs/1_53_0/doc/html/interprocess/quick_guide.html#interprocess.quick_guide.qg_named_interprocess
",Eric Niebler
8278,BOOST_ASSERT_MSG prerocessed out if NDEBUG is defined regardless of BOOST_ENABLE_ASSERT_HANDLER,utility,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,reopened,2013-03-11T22:55:50Z,2013-03-14T22:01:10Z,"There is an inconsistency in boost/assert.hpp. The macros `BOOST_ASSERT` and `BOOST_VERIFY` are *not* preprocessed out when `BOOST_ENABLE_ASSERT_HANDLER` is defined, but `BOOST_ASSERT_MSG` is. The inconsistency should be resolved one way or the other, and I think making `BOOST_ASSERT_MSG` behave like the other two makes the most sense.

Assigning to you, Peter, since you created this file. Please reassign as appropriate.
",Eric Niebler
8276,Shared Memory Access by 32-bit and 64-bit Processes,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-03-11T17:12:17Z,2016-04-07T14:14:10Z,"Problem: Exception raised in Segment.find_or_construct<>() call.
{{{
Problem: Exception raised in Segment.find_or_construct<>() call.

The system operates if all of the the processes are 64-bit, or if all of the processes are 32-bit.

If the shared memory segment has been constructed by a 64-bit process, attempting to find_or_construct it with a 32-bit process fails.  Similary, if the shared memory segment has been constructed by a 32-bit process, attempting to find_of_construct it with a 64-bit process fails.

I have determined that the actual objects in shared memory report different sizes when compiled for 32-bit or 64-bit.

This is a multi-cast PubSub program.  It constructs the following complex data structure in shared memory:

    // Boost includes
    #include <boost\interprocess\managed_shared_memory.hpp>
    #include <boost\interprocess\containers\map.hpp>
    #include <boost\unordered_map.hpp>
    #include <boost\interprocess\allocators\allocator.hpp>
    #include <boost\interprocess\containers\vector.hpp>
    #include <boost\interprocess\containers\string.hpp>
    #include <boost\interprocess\sync\interprocess_mutex.hpp>
    #include <boost\interprocess\sync\interprocess_semaphore.hpp>
    #include <boost\interprocess\sync\scoped_lock.hpp>
    #include <boost\interprocess\detail\move.hpp>
    #include <boost\thread.hpp>
    #include <boost\foreach.hpp>
    #include <boost\format.hpp>
    #include <functional>
    #include <boost/functional/hash.hpp>

    typedef managed_shared_memory::segment_manager          segment_manager_t;      // this is the segment_manager

    // Define the allocators.
    typedef boost::interprocess::allocator<void, segment_manager_t>              void_allocator;         // void_allocator is convertible to any other allocator<T>.
    typedef boost::interprocess::allocator<int, segment_manager_t>               int_allocator;          // allocator for allocating ints.
    typedef boost::interprocess::vector<int, int_allocator>                      int_vector;             // an int_vector is a vector of ints.
    typedef boost::interprocess::allocator<int_vector, segment_manager_t>        int_vector_allocator;   // an allocator for allocating vectors of ints.
    typedef boost::interprocess::vector<int_vector, int_vector_allocator>        int_vector_vector;      // an int_vector_vector is a vecctor of (vectors of ints)
    typedef boost::interprocess::allocator<interprocess_semaphore, segment_manager_t>  semaphore_allocator;   // an allocator for interprocess_semaphore
    typedef boost::interprocess::allocator<WCHAR, segment_manager_t>             wchar_allocator;        // an allocator for wide chars.
    typedef boost::interprocess::basic_string<WCHAR, std::char_traits<WCHAR>, wchar_allocator>  wchar_string;  // a basic_string (which supports formatting).  This is built on a collection of wide chars, allocated by wchar_alloctor.

    class EventMessage {
        EnumEventType EventType_;           // an enum
        EnumEventSubType EventSubType;      // an enum
        ULONG32 ProcessId_;
        ULONG32 ThreadId_;
        EnumMyType MyType_;                 // an enum
        wchar_string FullPath_;
        GUID GuidPublisher_;
    }

    // Event allocators
    typedef boost::interprocess::allocator<EventMessage, segment_manager_t>     EventMessage_allocator;         // allocator for allocating EventMessage
    typedef boost::interprocess::vector<EventMessage, EventMessage_allocator>   EventMessage_vector;            // vector of EventMessage objects.

    class Subscription {
        ULONG32 uSignature_;
        ULONG32 uSubscribingProcessId_;
        ULONG32 uSubscribingThreadId_;
        EnumEventType nEventType_           // an enum
        offset_ptr<interprocess_semaphore> pSemaphoreSubscription_;
        GUID guidSubscriber_;
        BOOL fDestructed;
        BOOL fWaiting_;
        BOOL fCancelled_;
        EventMessage_vector events_;    // a shared memory vector of EventMessage
    }

    // Define the types related to Subscription
    typedef boost::interprocess::allocator<Subscription, segment_manager_t>                      subscription_allocator;     // allocator for allocating Subscription
    typedef boost::interprocess::allocator<GUID, segment_manager_t>                             guid_allocator;         // allocator for allocating GUID
    typedef std::pair<const GUID, Subscription>                                                 pair_guid_subscription; // a pair of GUID, Subscription
    typedef boost::interprocess::allocator<EnumEventType, segment_manager_t>                    eventtype_allocator;    // allocator for allocating EnumEventType
    typedef boost::interprocess::allocator<pair_guid_subscription, segment_manager_t>           pair_guid_subscription_allocator;  // allocator for pair_guid_subscription
    typedef boost::unordered_map<GUID, Subscription, boost::hash<GUID>, std::equal_to<GUID>, pair_guid_subscription_allocator>  guid_subscription_map;  // a map of GUID => Subscription
    typedef std::pair<const EnumEventType, guid_subscription_map>                               pair_eventtype_pair_guid_subscription;  // a pair(EnumEventType, pair(GUID, Subscription))
    typedef boost::interprocess::allocator<pair_eventtype_pair_guid_subscription, segment_manager_t>  pair_eventtype_pair_guid_subscription_allocator;  // allocator for pair(EnumEventType, pair(GUID, Subscription))
    typedef boost::unordered_map<EnumEventType, guid_subscription_map, boost::hash<int>, std::equal_to<int>, pair_eventtype_pair_guid_subscription_allocator> eventtype_map_guid_subscription_map;  // a map(EnumEventType, map<GUID, Subscription)>
    typedef boost::interprocess::vector<Subscription, subscription_allocator>                    subscription_vector;    // a vector of Subscriptions
    typedef boost::interprocess::allocator<subscription_vector, segment_manager_t>               subscription_vector_allocator;  // allocator for allocating a vector of Subscription.
    typedef boost::interprocess::allocator<guid_subscription_map, segment_manager_t>            guid_subscription_map_allocator;  // allocator for allocating a map of GUID => Subscription
    typedef boost::interprocess::allocator<eventtype_map_guid_subscription_map, segment_manager_t> eventtype_map_guid_subscription_map_allocator;  // allocator for allocating map<EnumEventType, map<GUID, Subscription>>

    // This is the single item defined in the segment
    class Base {
        uint64_t reserved1_;
        uint64_t reserved2_;
        ULONG32 uSignature_;
        interprocess_mutex  mutexSharedMemory_
        eventtype_map_guid_subscription_map subscriptions_;  // a shared memory map of [GUID, Subscription] (the active subscriptions)
    }

The following sizes are reported:
64-bit
    sizeof(IntPtr): 8
    sizeof(ULONG32): 4
    sizeof(BOOL): 4
    sizeof(EnumEventType): 4
    sizeof(EnumEventSubType): 4
    sizeof(EnumCloudAppIconBadgeType): 4
    sizeof(GUID): 16
    sizeof(EventMessage): 72
    sizeof(Subscription): 88
    sizeof(Base): 104
    sizeof(size_t): 8

32-bit:
    sizeof(IntPtr): 4
    sizeof(ULONG32): 4
    sizeof(BOOL): 4
    sizeof(EnumEventType): 4
    sizeof(EnumEventSubType): 4
    sizeof(EnumCloudAppIconBadgeType): 4
    sizeof(GUID): 16
    sizeof(EventMessage): 60
    sizeof(Subscription): 64
    sizeof(Base): 72
    sizeof(size_t): 4

Note that all of the fundamental types are the same size, but the Boost interprocess sizes are different.

I thought that as of Boost 1.48 all of the sizes were normalized to use the same shared memory sizes whether compiled for 32- or 64-bit.

Perhaps I am doing something wrong.  Suggestions will be welcome.  Thanks.

}}}",Bob Stevens <bob@…>
8275,conversion_traits::super/subtype incorrect for UDT's,numeric,Boost Development Trunk,To Be Determined,Bugs,Douglas Gregor,new,2013-03-11T16:54:45Z,2013-03-11T16:54:45Z,"The following static assertion fails:

{{{
#include <boost/numeric/conversion/conversion_traits.hpp>
#include <boost/multiprecision/cpp_dec_float.hpp>

   using namespace boost::multiprecision;
   BOOST_STATIC_ASSERT(boost::numeric::convdetail::get_is_subranged<cpp_dec_float_50, cpp_dec_float_100>::type::value);

}}}

Which causes all sorts of other failures in clients of this class - it looks like UDT conversions are treated as always non-narrowing (?) where as use of numeric_limits would quickly reveal otherwise.",John Maddock
8273,Add externally locked streams,thread,Boost 1.52.0,,Feature Requests,viboes,assigned,2013-03-11T07:21:19Z,2014-09-05T06:11:53Z,"Based on N3354: C++ Stream Mutexes http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3354.html add thread safe streams that gets its  protecting mutex externally instead of internally as in the proposal so that several streams can share the same protecting mutex. 

This will be useful to take in account coherency when working with cout and cin.",viboes
8259,"ICU is used but not cleaned up, leaking memory.",locale,Boost Development Trunk,To Be Determined,Bugs,Artyom Beilis,new,2013-03-07T00:57:19Z,2013-04-10T11:25:07Z,"So ICU is used in Boost.Locale, but not cleaned up, which leaks memory.

I've attached a patch that fixes this, but has some setbacks:

- It's not thread safe (that I know of).
- ICU may be used in other Boost libraries (like Regex) and it will break their data.
- ICU may be used in user applications and it will break their data.

A solution would be to make an interface for the application users to use that cleans up ICU specifically, but that'd break encapsulation would it not?",166291@…
8258,Wave: unexpected pre-processing error,wave,Boost 1.53.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-03-06T18:55:52Z,2013-03-07T13:41:17Z,"Pre-processing the following file with the wave tool (v2.3.2.4101) on OSX 10.8.2 built from Boost 1.53.0 with GCC 4.2.1 produces an unexpected error.

File PPError1.txt:
{{{
#if 0
	""\U0000x""
#endif
}}}

Error:
{{{
/path-to-file/PPError1.txt:2:2: error: universal character name specifies an invalid character: \U0000x""
}}}

Wave was invoked with:[[BR]]
    /path-to-boost/dist/bin/wave PPError1.txt

Wave was built with:[[BR]]
    cd boost_1_53_0/tools/wave/build[[BR]]
    b2 variant=debug

Strangely, deleting any (or all) of the 0's in the second line causes wave to produce no error.[[BR]]
[GNU cpp-4.2.1 produces no errors in all cases.]",chris0@…
8256,Wave tests fail to build on OSX+GCC,wave,Boost 1.53.0,To Be Determined,Bugs,Hartmut Kaiser,new,2013-03-06T18:20:01Z,2013-03-07T16:21:24Z,"When attempting to build & run the Boost (1.53.0) wave tests on OSX 10.8.2 with GCC 4.2.1 the build fails at the link stage.

I built with:[[BR]]
    cd boost_1_53_0/libs/wave/test/build[[BR]]
    b2 variant=debug

The invocation:
{{{
g++-4.2 -o ""../../../../../build/libs/wave/test/build/test_re2c_lexer.test/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/test_re2c_lexer""  ""../../../../../build/libs/wave/test/build/test_re2c_lexer.test/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/test_re2c_lexer.o"" ""../../../../../build/libs/date_time/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_date_time.a"" ""../../../../../build/libs/thread/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_thread.a"" ""../../../../../build/libs/filesystem/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_filesystem.a"" ""../../../../../build/libs/system/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_system.a"" ""../../../../../build/libs/program_options/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_program_options.a"" ""../../../../../build/libs/wave/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_wave.a"" ""../../../../../build/libs/chrono/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_chrono.a"" ""../../../../../build/libs/date_time/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_date_time.a"" ""../../../../../build/libs/thread/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_thread.a"" ""../../../../../build/libs/filesystem/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_filesystem.a"" ""../../../../../build/libs/system/build/gcc-4.2/debug/link-static/runtime-link-static/threading-multi/libboost_system.a"" -g -static -isysroot /Developer/SDKs/MacOSX10.5.sdk
}}}
produces the message:
{{{
ld_classic: can't locate file for: -lcrt0.o
collect2: ld returned 1 exit status
}}}

However, removing the '-static' flag fixes the problem.[[BR]]
(On OSX 'man ld' reports ""-static     Produces a mach-o file that does not use the dyld.  Only used building the kernel."".)

The problem appears to be in boost_1_53_0/tools/build/v2/tools/gcc.jam. Due to these lines (767):
{{{
if [ os.name ] != HPUX
{
    toolset.flags gcc.link OPTIONS <runtime-link>static : -static ;
}
}}}

I was forced to change this, like so, to work around the problem:
{{{
#if [ os.name ] != HPUX && [ os.name ] != darwin # Doesn't work
#if [ os.name ] != HPUX && [ os.name ] != posix # Doesn't work
if [ os.name ] != HPUX
{
#    toolset.flags gcc.link OPTIONS <runtime-link>static : -static ;
# Had to comment out above line for OSX/darwin
}
}}}

Once built the tests all run successfully.
",chris0@…
8250,Bug deleting self loop edges in parallel code,graph,Boost 1.53.0,To Be Determined,Bugs,ngedmond,new,2013-03-05T13:58:30Z,2013-12-20T11:51:41Z,"Hello, 

I think I found a bug in the graph parallel library. 
I have a bidirectional adjacency list which has some self loop edges. 
When I try to delete them with remove_edge_if (or remove_out_edge_if or remove_in_edge_if) the edges are deleted, but it seems that some reference gets broken in the graph. 
If I iterate over the in_edges a reference to a self loop is found. But it does not happen if I iterate over the out_edges. 
If the graph is written in a graphviz file the self loop edges does not appear. 

I think there is some broken reference into the adjacency list that keeps the in_edges. 

I have two different pieces of code (one with pbgl and the other with bgl). They do the same, create a graph, delete the self-edges and print the in_edges. 

Could someone have a look at this problem? 

Thank you",Borja Miñano <bminyano@…>
8244,strerror is not thread-safe on all platforms,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-03-05T09:04:23Z,2013-03-05T09:04:23Z,"boost/iostreams/detail/system_failure.hpp uses strerror function which is not thread-safe on many platforms (e.g. Linux). Its use should be replaced with strerror_r, when possible.

As a hint for implementation see libs/system/src/error_code.cpp.
",Andrey Semashev
8243,strerror is not thread-safe on all platforms,exception,Boost 1.52.0,To Be Determined,Bugs,Emil Dotchevski,new,2013-03-05T09:00:19Z,2013-03-09T00:13:31Z,"boost/exception/errinfo_errno.hpp uses strerror function which is not thread-safe on many platforms (e.g. Linux). Its use should be replaced with strerror_r, when possible.

As a hint for implementation see libs/system/src/error_code.cpp.
",Andrey Semashev
8242,strerror is not thread-safe on all platforms,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2013-03-05T08:54:25Z,2013-03-05T08:54:25Z,"boost/interprocess/errors.hpp uses strerror function which is not thread-safe on many platforms (e.g. Linux). Its use should be replaced with strerror_r, when possible.

As a hint for implementation see libs/system/src/error_code.cpp.
",Andrey Semashev
8235,Toolset “intel-win” fails on .asm files,build,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2013-03-03T15:06:47Z,2014-10-22T14:26:19Z,"Building boost v1.53.0 using intel-win fails because assembler (masm or ml/ml64) doesn’t set:

intel-win.compile.asm bin.v2\libs\context\build\intel-win\debug\link-static\threading-multi\asm\make_x86_64_ms_pe_masm.obj 
'-c' is not recognized as an internal or external command, 
operable program or batch file. 

    -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1 /Zi /Zd /W3  -Fo ""bin.v2\libs\context\build\intel-win\debug\link-static\threadingmulti\asm\make_x86_64_ms_pe_masm.obj"" ""libs\context\src\asm\make_x86_64_ms_pe_masm.asm"" 

...failed intel-win.compile.asm bin.v2\libs\context\build\intel-win\debug\link-static\threading-multi\asm\make_x86_64_ms_pe_masm.obj... 
intel-win.compile.asm bin.v2\libs\context\build\intel-win\debug\link-static\threading-multi\asm\jump_x86_64_ms_pe_masm.obj 
'-c' is not recognized as an internal or external command, 
operable program or batch file. 

",elmira.a.semenova@…
8205,MinGW can't find ICU libraries,locale,,,Bugs,Artyom Beilis,new,2013-02-28T18:07:57Z,2013-02-28T18:07:57Z,"ICU uses MSVC naming schemes in MinGW (at least on Linux when cross-compiling), so the names aren't picked up.

I've attached a patch that fixes the issue with 32bit libraries. This hasn't been tested in Windows, and still requires 64bit library support (stuff in lib64) but I don't have either of those setups to work on. Sorry.",166291@…
8203,filtering_ostream fails to write 0xFF characters with XCode,iostreams,Boost 1.51.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-02-28T12:30:06Z,2013-09-23T09:00:45Z,"I originally found the problem using the zlib_compressor to write to an ofstream. It worked correctly on Windows but in Xcode 4.6 occasionally a 0xFF character was not written to the stream.

I managed to reduce the code required to reproduce it down to:

// filtering stream fails to write 0xFF chars to ostream. Have
// reproduced with ofstream too
std::ostringstream ostm(std::ios_base::out | std::ios_base::binary);

// Use empty filtering stream. Problem was originally found with
//zlib_compressor
boost::iostreams::filtering_ostream filterStream;
filterStream.push( ostm );

const unsigned fileSize = 30000;

for( unsigned nWritten = 0; nWritten < fileSize; ++nWritten)
{
  const char eofTest = -1; // Only fails with 0xFF character any other value fine

  filterStream.write( &eofTest, sizeof eofTest);
}
filterStream.flush();

// This assert fails with Xcode 4.6
assert( ostm.str().size() == fileSize);

The number of missing characters is equal to the number of times overflow gets called. I suspect it's something to do with EOF character detection as the problem doesn't happen with other character values.

I was unable to find the exact reason for the problem but was able to get it work by changing this code in write.hpp:

static std::streamsize write(T& t, const typename char_type_of<T>::type* s, std::streamsize n)
{ 
  return t.rdbuf()->sputn(s, n);
}

to:

static std::streamsize write(T& t, const typename char_type_of<T>::type* s, std::streamsize n)
{ 
  t.write(s, n);
  return n;
}

It looks like bypassing the ofstream in Xcode and going to the lower level rdbuf::sputn causes the issue.
",support@…
8183,boost::geometry::intersection on two polygons returns incorrect empty intersection,geometry,Boost 1.52.0,To Be Determined,Bugs,Barend Gehrels,assigned,2013-02-26T09:24:56Z,2013-03-17T17:47:02Z,"Hi

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

Thanks

Matthew Danielsen

{{{

polygon_2d triangle2D;
{
    const double triangle2Dcoor[] = {{0.891747, 2.28756}, {0.490911, -1.52549}, {-1.72945, -1.52549}, {0.891747, 2.28756}};
    assign(triangle2D, triangle2Dcoor);
}

polygon_2d box2D;
{
    const double box2Dcoor[] = {{-1.6744, -1.52549}, {-1.70498, -1.52549}, {-1.70052, -1.49155}, {-1.67049, -1.49579}, {-1.6744, -1.52549}};
    assign(box2D, box2Dcoor);
}

boost::geometry::model::multi_polygon< boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<T> > > intersectionPolygons;
boost::geometry::intersection(triangle2D, box2D, intersectionPolygons);
assert(intersectionPolygons.size() != 0); //  Assert fails

}}}
",matthewd@…
8174,Add serialization support to Boost.Container,container,Boost 1.52.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2013-02-25T20:20:29Z,2014-01-03T10:16:55Z,"The containers from Boost.Container are not currently serializable with Boost.Serialize. It would be very convenient if this functionality were provided. Boost.Serialize already has code for serializing standard containers, which should be pretty easy to adapt to Boost.Container.",Erik.Jensen@…
8172,Boost ASIO async connect false fail on HP-UX,asio,Boost 1.53.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-02-25T13:15:16Z,2013-02-25T13:15:16Z,"HP-UX migs01a B.11.31 U ia64 
aCC: HP C/aC++ B3910B A.06.20 [May 13 2008]

Im getting weird and unexpected error using socket::async_connect
Handle is called with error_code set to: 22 - system - Invalid argument
(value - category - message)
Even though the socket is actualy connected, because if I force to ignore this particular error, everything goes perfectly fine.
I can even use the socket to transfer whole 400MB file to another server.
Maybe a mismatch in code? Because there are other applications running there that are using POSIX sockets (not asio)
If files are needed I can create some, but I dont see a point in that, since its 4 lines of code. I even tryed using endpoint constructor with ip address or resolver using query.
Localhost works btw. Without calling handler with error.

Thx",pinkerik88@…
8150,gzip_compressor produces corrupt data when used with filtering_ostream,iostreams,Boost 1.53.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-02-23T00:00:11Z,2013-02-25T15:07:55Z,"In some cases, the USE_CORRUPTING_OSTREAM path in the following program will produce corrupt gzip output (fails CRC and the de-gzipped file differs slightly from the original input). This does not occur for all data, so I will attach an input data file that triggers the error.

This bug only affects gzip_stream when used with filtering_ostream. It does not affect filtering_istream usage.

Bug reproduced on Mac 10.8.2, 64-bit, Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn), zlib 1.2.5 (dylib as shipped with Mac OS X), boost 1.53.0.

Bug does not appear to be affected by compiler optimizations (-O0 and -Os tested).

{{{
#include <iostream>
#include <fstream>
#include <vector>
#include <boost/iostreams/filter/gzip.hpp>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/device/back_inserter.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/device/array.hpp>
#include <boost/iostreams/stream.hpp>
#include <boost/iostreams/device/file_descriptor.hpp>

int main(int argc, char *argv[])
{
	std::vector<char> input;
	std::vector<char> output;
	
	boost::iostreams::file_descriptor_source source(""inputdata"");
	boost::iostreams::copy(source, boost::iostreams::back_inserter(input));
	
#define USE_CORRUPTING_OSTREAM 1
#if USE_CORRUPTING_OSTREAM
	boost::iostreams::filtering_ostream gzip_stream;
	gzip_stream.push(boost::iostreams::gzip_compressor());
	gzip_stream.push(boost::iostreams::back_inserter(output));
	gzip_stream.write(&input[0], input.size());
	boost::iostreams::close(gzip_stream);
#else
	boost::iostreams::filtering_istream gzip_stream;
	boost::iostreams::stream<boost::iostreams::array_source> input_array(&input[0], input.size());
	gzip_stream.push(boost::iostreams::gzip_compressor());
	gzip_stream.push(input_array);
	boost::iostreams::copy(gzip_stream, boost::iostreams::back_inserter(output));
#endif
	
	boost::iostreams::file_descriptor_sink destination(""inputdata.gz"");
	destination.write(&output[0], output.size());
}
}}}
",matt@…
8148,mpl::is_lambda_expression bug,mpl,Boost 1.53.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-02-22T23:03:45Z,2013-02-22T23:03:45Z,"The metafunction boost::mpl::is_lambda_expression does not work correctly. 

My attached code example give a metafunction class for which is_lambda_expression evaluates as false.

While is_lambda_expression is not a documented feature of boost::mpl, it is available in the boost::mpl namespace. Moreover, it is used in the implementation of boost::mpl::transform, and presumably results in unintended behaviour there.

The package boost::tti (in the boost/trunk) has boost::tti::detail::is_lambda_expression. I have confirmed that this works correctly on my example (see attached file). The tti author has informed me that tti depends on mpl. Perhaps then, boost::mpl::is_lambda_expression should be replaced by tti's.",James Hirschorn <James.Hirschorn@…>
8134,Compiler error using boost::foreach with boost::bimap,bimap,Boost 1.52.0,To Be Determined,Bugs,Matias Capeletto,new,2013-02-21T05:39:28Z,2013-03-25T23:30:35Z,"boost_1_52_0\boost\multi_index\ordered_index.hpp(1399) : error C3083: 'BOOST_FOREACH': the symbol to the left of a '::' must be a type
boost_1_52_0\boost\multi_index\ordered_index.hpp(1399) : error C2039: 'tag' : is not a member of 'boost'
boost_1_52_0\boost\multi_index\ordered_index.hpp(1399) : error C2061: syntax error : identifier 'tag'

This occurs when using boost::bimap and boost::foreach. Seen first in 1.52, also in 1.53. OK in 1.49, with Visual tudio 2008 and 2010

Very simple VS2008 project included. Need to set environment variable BOOST_DIR to the boost directory, or change the project settings explicitly.",john.x.foster@…
8125,Failure compiling data_members.hpp with i386-mingw32 under OS X,python USE GITHUB,Boost 1.52.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2013-02-20T18:15:48Z,2013-02-20T18:34:16Z,"I'm using boost to compile Python support for libRocket (librocket.com). I compile my engine across a variety of platforms and compilers, and I've only come across this issue with the i386-mingw32 compiler obtained from Mac Ports (macports.org), on OS X. The mingw compiler for Ubuntu seems to work just fine, as well as the native compilers for each system, for Android, iOS, etc.

The error I get is the following:
{{{
In file included from /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/precompiled.h:32,
                 from /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/cython_src/Rocket+Core+Python+ElementChildrenProxy.cpp:28:
/Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/Python.h:38: warning: ignoring #pragma warning 
/Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/Python.h:39: warning: ignoring #pragma warning 
In file included from /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/precompiled.h:32,
                 from /Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/cython_src/Rocket+Core+Python+ElementAttributeProxy.cpp:28:
/Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/Rocket/Core/Python/Python.h:49: warning: ignoring #pragma warning 
/Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/boost/python/data_members.hpp: In function `boost::python::api::object boost::python::make_getter(const D&) [with D = const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*)()]':
/Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/boost/python/class.hpp:484:   instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def_readonly_impl(const char*, D&, const char*) [with D = const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*const)(), W = Rocket::Core::Python::ElementAttributeProxy::AttributeProxy, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
/Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/boost/python/class.hpp:283:   instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def_readonly(const char*, const D&, const char*) [with D = const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*)(), W = Rocket::Core::Python::ElementAttributeProxy::AttributeProxy, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]'
/Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/cython_src/Rocket+Core+Python+ElementAttributeProxy.cpp:49:   instantiated from here
/Users/gabo/ignifuga/tmp/intel_mingw32/ignifuga/boost/python/data_members.hpp:279: error: no matching function for call to `make_getter(const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*const&)(), boost::python::detail::not_specified&, boost::is_member_pointer<const char*(Rocket::Core::Python::ElementAttributeProxy::AttributeProxy::*)()>, long int)'
make: *** [Modules/Rocket+Core+Python+ElementAttributeProxy.o] Error 1

}}}
",gabomdq@…
8095,Invalid XML is produced by write_xml when there is a special character in the key,property_tree,Boost 1.67.0,To Be Determined,Bugs,Sebastian Redl,new,2013-02-18T16:23:13Z,2018-06-30T09:20:05Z,"I have the following property tree, dumped in INFO format:

{{{
CudbAppServiceId=1
{
    userLabel """"
    sqlAppSrvPlSchema identities-pl.sql
    CudbAppServiceId CudbAppServiceId=1
}
}}}

When I dump it in XML format, I got the following:

{{{
<?xml version=""1.0"" encoding=""utf-8""?>
<CudbAppServiceId=1>
<userLabel/>
<sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema>
<CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId>
</CudbAppServiceId=1>
}}}

This is not a valid XML, because we have a tag ""CudbAppServiceId=1"".
Of course, any other xml parser like xmllint will fail to parse it,
because of the equality sign in the tag.

Is there any solution to this problem? Like somehow emitting &#61;
instead of the raw '=' inside the tag and in the text?

This is a possible problem in 1.53 as well, since property tree was not updated.",martongabesz@…
8094,hierarchical_mutex for lock hierarchies (to avoid deadlocks),thread,Boost 1.53.0,To Be Determined,Feature Requests,viboes,assigned,2013-02-17T21:24:36Z,2014-10-26T20:41:49Z,"It would be great if boost::thread could be extended with a ""hierarchical"" mutex to facilitate lock hierarchies. Lock hierarchies is a construct that associates mutexes with software layer numbers, and enforces the application to only lock ""downwards"" in the software hierarchy [1]. This effectively translates potential deadlocks into deterministic run-time failures that be detected during testing.

An example draft implementation is attached. The attachment also includes a BOOST_THREAD_LOCAL work-around for missing ""thread_local"" support that should probably be moved to more neutral ground.

[1] http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163",Fredrik Orderud <forderud@…>
8088,Limited Forward Compatibility,serialization,Boost 1.52.0,To Be Determined,Patches,Robert Ramey,new,2013-02-17T15:32:09Z,2017-11-27T10:56:08Z,"We use xml serialization for saving and loading several types of metadata and we have to support possibility of reading new versions of files with old versions of soft. Boost::serialization is very good at backward compatibility but does not provide anything with opposite problem.

So, This patch introduces new flag boost::archive::skip_unknown_tail_tags. When this flag is set and basic_xml_iarchive is faced with unknown tags at the end of element it will skip them (include nested).
 
E.g., the first version of some file was:
{{{
<Test class_id=""0"" tracking_level=""0"" version=""0"">
    <a>31</a>
    <t2 class_id=""1"" tracking_level=""0"" version=""0"">
        <a>11</a>
        <b>12</b>
    </t2>
    <b>32</b>
</Test>
}}}
 
After a while, the second version could be:
{{{
<Test class_id=""0"" tracking_level=""0"" version=""0"">
    <a>31</a>
    <t2 class_id=""1"" tracking_level=""0"" version=""1"">
        <a>11</a>
        <b>12</b>
        <c>13</c>
        <d>14</d>
        <t1 class_id=""2"" tracking_level=""0"" version=""0"">
            <a>1</a>
            <b>2</b>
        </t1>
    </t2>
    <b>32</b>
</Test>
}}}

Therefore, if the first version software set skip_unknown_tail_tags it can read second version of file (if does not set then exception will be thrown).",Dmitry Shesterkin <dfb@…>
8064,Comment handling in <boost/property_tree/ini_parser.hpp>,property_tree,Boost 1.53.0,To Be Determined,Feature Requests,Sebastian Redl,new,2013-02-14T13:33:27Z,2013-02-14T13:50:43Z,"Hello!

I'd like to propose a patch to the ini_parser.hpp which allowes to handle inline comments like:

key=0.55 ;this comment describing ""key"" would result in an exception when using read_ini()

Patch is attached to this ticket.",stefan.jenisch@…
8054,Where is the PageRank algorithm?,graph,Boost 1.52.0,To Be Determined,Support Requests,Jeremiah Willcock,new,2013-02-13T14:45:45Z,2016-08-09T09:22:51Z,"Hello,

It seems that once where was a PageRank implementation for Boost, which is referenced here 

http://osl.iu.edu/~dgregor/bgl-python/reference/boost.graph.html#-page_rank

which refers to http://www.boost.org/libs/graph/doc/page_rank.html which does not exist. A search in the SVN 
https://svn.boost.org/trac/boost/changeset/29931/trunk/boost/libs/graph/src/python/page_rank.cpp
showed me that there once was a file ""page_rank.cpp"" which seems to no longer exist https://svn.boost.org/trac/boost/browser/trunk/boost/libs/graph/src/python/page_rank.cpp gives an error.

(Why) Has the implementation been removed?



Robert",anonymous
8035,Warning fixes in parameter,parameter,Boost 1.53.0,To Be Determined,Patches,Daniel Wallin,new,2013-02-12T09:29:26Z,2013-02-12T09:29:26Z,"We have a zero warning policy in our development projects and experience
lots of warnings in several boost libraries. With every new boost version
we need to apply a set of warning fixes.

It would help a lot if you could integrate these warning fixes into future
boost releases.

Please find attached a patch file against boost 1.53.0 which fixes several
warnings in boost::parameter.",Franz Detro <franz.detro@…>
8021,gcc: ptree_utils.hpp:76: warning: comparison is always false due to limited range of data type [-Wtype-limits],property_tree,Boost 1.52.0,To Be Determined,Bugs,Sebastian Redl,new,2013-02-09T20:00:59Z,2013-07-18T09:04:13Z,"gcc version 4.7.2 (Built by MinGW-builds project) i686-w64-mingw32

yields

{{{
boost/property_tree/detail/ptree_utils.hpp: In instantiation of 'std::string boost::property_tree::detail::narrow(const Ch*) [with Ch = wchar_t; std::string = std::basic_string<char>]':
boost/property_tree/string_path.hpp:64:36:   required from here
boost/property_tree/detail/ptree_utils.hpp:76:13: warning: comparison is always false due to limited range of data type [-Wtype-limits]

76: if (*text < 0 || *text > (std::numeric_limits<char>::max)())
}}}",anonymous
8013,Fusion sequence attribute compatibility,spirit,Boost 1.53.0,To Be Determined,Bugs,Joel de Guzman,new,2013-02-09T03:03:03Z,2017-12-17T01:31:26Z,"From Spirit point of view, two fusion sequences are compatible if
one of them is a prefix of the other. This is unintentional.",K-ballo <kaballo86@…>
8012,Inconsistency in linearize(),circular_buffer,Boost 1.52.0,To Be Determined,Bugs,No-Maintainer,new,2013-02-08T17:41:28Z,2013-10-24T21:35:39Z,"Assume two equivalent non-empty circular buffers A and B, with A reporting as linearized and B as not linearized. After calling ''clear()'' on them, they will both still report the same linearized state as before; the linearized state applies to all buffers, whether empty or not. However, calling ''linearize()'' on the non-linearized empty buffer B will '''not''' linearize it, which is inconsistent.

One option to fix this would be to automatically linearize a buffer when it becomes empty, but that would force some overhead even in cases where it is unnecessary. A better solution would be to make ''linearize()'' work normally even on empty buffers.",Serge Meynard <serge.meynard@…>
8010,Iterator adaptor and facade are not in TR1,iterator,Boost 1.52.0,To Be Determined,Bugs,jeffrey.hellrung,new,2013-02-08T12:15:12Z,2013-02-08T12:15:12Z,"http://www.boost.org/doc/libs/1_53_0/libs/iterator/doc/#iterator-facade-and-adaptor says 

> Both iterator_facade and iterator_adaptor as well as many of the specialized adaptors mentioned below have been proposed for standardization, and accepted into the first C++ technical report;

Assuming this is referring to TR1 it's incorrect and very out of date, neither was included in TR1.",Jonathan Wakely <jwakely.boost@…>
7996,phoenix::bind does not protoify the bound arguments,phoenix,Boost Release Branch,To Be Determined,Bugs,Thomas Heller,new,2013-02-06T18:10:14Z,2014-07-17T21:09:48Z,"I have a problem with Boost.Phoenix v3 bind implementation when used with attribute keywords from Boost.Log. For some reason phoenix::bind does not apply proto::detail::protoify to the bound arguments which breaks compilation of some formatting expressions in Boost.Log. 

Here's an example:

{{{
#include <boost/phoenix.hpp>
#include <boost/log/trivial.hpp>
#include <boost/log/expressions.hpp>
#include <boost/log/utility/value_ref.hpp>

namespace logging = boost::log;
namespace expr = boost::log::expressions;
namespace phoenix = boost::phoenix;

// Custom severity level formatting function
std::string severity_level_as_urgency(
    logging::value_ref< logging::trivial::severity_level, logging::trivial::tag::severity > const& level)
{
    if (!level || level.get() == logging::trivial::info)
        return ""normal"";
    logging::trivial::severity_level lvl = level.get();
    if (lvl < logging::trivial::info)
        return ""low"";
    else
        return ""critical"";
}

int main(int, char*[])
{
    logging::formatter fmt =
        expr::stream << boost::phoenix::bind(&severity_level_as_urgency, logging::trivial::severity);

    return 0;
}
}}}

The example creates a formatter function object that should call severity_level_as_urgency function to convert the severity level to string and put its result into a stream.

trivial::severity is a keyword of type expr::attribute_keyword< ... >. 
Keywords themselves should never actually be embedded into phoenix 
expressions, instead I have attribute_actor that implements all the necessary work to extract attribute values. I have specialized proto::detail::protoify template for attribute_keyword (including references and reference_wrappers thereof) so that it is automatically converted to attribute_actor whenever it participates in expressions. But it doesn't work with the above code, Boost.Phoenix embeds attribute_keyword as is into the expression. This results 
in the error I attached to the ticket.

I realize that proto::detail::protoify is not for public use and may not be intended for my use case but I did not find any other way to implement what I described. Anyway, I think bind should treat bound arguments as child subexpressions and protoify them.

To compile the test code you will have to checkout Boost.Log from SVN:

{{{
svn co https://boost-log.svn.sourceforge.net/svnroot/boost-log/branches/bleeding-edge -r 822 boost-log
}}}

Then the relevant directories have to be linked/copied into the Boost tree.


PS: The issue came from the mailing list:

[http://lists.boost.org/Archives/boost/2013/02/200701.php]

",Andrey Semashev
7991,Many warnings with uBlas while compiling with clang/libc++,uBLAS,Boost 1.53.0,To Be Determined,Bugs,Gunter,new,2013-02-06T15:14:35Z,2013-02-10T22:06:34Z,"I am currently compiling a project which uses mostly uBLAS library, and the problem is that I am crippled with many warnings, most of them from exterior libraries, among which Boost uBlas.

Granted, I am very though with my compilation options (only an handful of warnings were deleted from clang's -Weverything), but the warnings obtained went from harmless (-Wmissing-noreturn, -Wweak-tables,  -Wunused-parameter) to some a lot more worrying (-Wshadow). 

Do you intend to get rid of these warnings ? The page for this library indicates it is check against quite old compilers (gcc 4.0, Visual Studio 6, no trace of clang)

Best regards,

Sebastien Gilles


",sebastien.gilles@…
7986,iostreams fails to compile on AIX7 XLC11 with _LARGE_FILES,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2013-02-05T22:31:49Z,2014-01-13T22:30:06Z,"AIX version: 7100.01.05.1228 
VACPP version: 11.1.0.12

Compiling iostreams library with _LARGE_FILES support causes the below compilation errors.

I was able to resolve the compilation error by moving the inclusion of fcntl so that it's _LARGE_FILES macro definitions affects all of the source instead of just part.  Patch for 1.52.0 attached.

common.mkdir ../../../bin.v2
common.mkdir ../../../bin.v2/libs
common.mkdir ../../../bin.v2/libs/iostreams
common.mkdir ../../../bin.v2/libs/iostreams/build
common.mkdir ../../../bin.v2/libs/iostreams/build/vacpp
common.mkdir ../../../bin.v2/libs/iostreams/build/vacpp/debug
vacpp.compile.c++ ../../../bin.v2/libs/iostreams/build/vacpp/debug/file_descriptor.o
""../../../libs/iostreams/src/file_descriptor.cpp"", line 400.6: 1540-1140 (S) The member ""void open64(handle_type, file_descriptor_flags)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 404.6: 1540-1140 (S) The member ""void open64(handle_type, bool)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 424.6: 1540-1140 (S) The member ""void open64(const std::string &, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 427.6: 1540-1140 (S) The member ""void open64(const char *, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 447.6: 1540-1140 (S) The member ""void open64(const path &, std::ios::openmode, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 493.6: 1540-1140 (S) The member ""void open64(handle_type, file_descriptor_flags)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 497.6: 1540-1140 (S) The member ""void open64(handle_type, bool)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 513.6: 1540-1140 (S) The member ""void open64(const std::string &, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 517.6: 1540-1140 (S) The member ""void open64(const char *, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 521.6: 1540-1140 (S) The member ""void open64(const path &, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 565.6: 1540-1140 (S) The member ""void open64(handle_type, file_descriptor_flags)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 569.6: 1540-1140 (S) The member ""void open64(handle_type, bool)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 585.6: 1540-1140 (S) The member ""void open64(const std::string &, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 589.6: 1540-1140 (S) The member ""void open64(const char *, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 593.6: 1540-1140 (S) The member ""void open64(const path &, std::ios::openmode)"" must be declared in its containing class definition.
""../../../libs/iostreams/src/file_descriptor.cpp"", line 364.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor::handle_type"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 364.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 369.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor::handle_type"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 369.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 389.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""const std::_LFS_ON::basic_string<char,std::char_traits<char>,std::allocator<char> >"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 389.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 460.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor_source::handle_type"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 460.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 465.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor_source::handle_type"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 465.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 482.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""const std::_LFS_ON::basic_string<char,std::char_traits<char>,std::allocator<char> >"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 482.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 533.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor_sink::handle_type"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 533.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 538.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""boost::iostreams::file_descriptor_sink::handle_type"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 538.8: 1540-1205 (I) The error occurred while converting to parameter 1 of ""open64(const char *, int, ...)"".
""../../../libs/iostreams/src/file_descriptor.cpp"", line 555.8: 1540-0256 (S) A parameter of type ""const char *"" cannot be initialized with an expression of type ""const std::_LFS_ON::basic_string<char,std::char_traits<char>,std::allocator<char> >"".
",Kevin Burge <kevin.burge@…>
7984,"In very rare cases, boost::polygon crashed or generate bad polygon when substracting 2 sets of polygons",polygon,Boost 1.53.0,To Be Determined,Bugs,Andrii Sydorchuk,assigned,2013-02-05T19:25:06Z,2015-01-26T19:53:36Z,"I am using boost:: polygon to calculate sum or difference of sets of polygons.
Recently, When calcualting the difference of 2 sets of polygons, I found 2 cases creating a serious issue:
Depending on the shape of polygons ( a slight change ""fix"" the bug) I have one case which create no polygon and one (in fact 2 samples) which crashes.

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

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

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

Thanks to the developpers.",jp.charras@…
7975,mpl::insert<...>::type::type returns empty map when inserting into an mpl::map,mpl,Boost Development Trunk,To Be Determined,Bugs,Aleksey Gurtovoy,new,2013-02-04T19:59:24Z,2013-02-04T19:59:24Z,"The following code:

{{{
using namespace boost::mpl;

insert<map<>, pair<int_<1>, int_<2> > >::type::type
}}}

gives

{{{
boost::mpl::map0<>
}}}
",Ábel Sinkovics <abel@…>
7968,swap: Add noexcept to conform with C++11 on compilers supporting it.,swap,Boost 1.53.0,To Be Determined,Feature Requests,joseph.gauterin,new,2013-02-03T07:10:58Z,2013-02-06T17:30:24Z,"
{{{

template<class T> void swap(T& a, T& b) noexcept(see below );
1 Remark: The expression inside noexcept is equivalent to:
is_nothrow_move_constructible<T>::value &&
is_nothrow_move_assignable<T>::value

template<class T, size_t N>
void swap(T (&a)[N], T (&b)[N]) noexcept(noexcept(swap(*a, *b)));
}}}
",viboes
7963,"bootstrap.sh uses echo -n, which is not portable",Building Boost,Boost 1.52.0,To Be Determined,Bugs,,new,2013-02-02T00:43:31Z,2013-02-02T00:43:31Z,"The echo builtin in OS X's sh does not support any command line switches, which results in bootstrap.sh's output being somewhat ugly (but still working; this is purely cosmetic). The attach patch simply replaces all of the uses of echo -n with printf, which works on all unix-like systems.",anonymous
7953,phoenix & std::valarray leads to a segfault,phoenix,Boost Development Trunk,To Be Determined,Bugs,Thomas Heller,new,2013-01-30T22:20:20Z,2013-01-30T22:20:20Z,"A phoenix expression [1] applied to valarray<double> [2] leads to a segfault.

[1]  boost::phoenix::at_c<0>(arg1) += boost::phoenix::at_c<1>(arg1) /
val(mass) * arg2

[2] std::tuple<std::valarray<double>, std::valarray<double>>

A simple example is attached triggering the problem. (When compiled with gcc 4.6 or 4.7) ",Philipp Schwaha <philipp@…>
7945,Inhibit inclusion of headers not present in vxWorks,timer,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-01-28T17:02:00Z,2013-01-28T17:02:00Z,Attached a patch inhibiting the inclusion of headers unpresent in vxWorks,p.brockamp@…
7944,Adapt filesystem for vxWorks 6.9,filesystem,Boost 1.53.0,To Be Determined,Bugs,Beman Dawes,new,2013-01-28T16:58:29Z,2013-01-28T16:58:29Z,Attached a small patch to inhibit inclusion of headers not present in vxWorks 6.9,p.brockamp@…
7941,fpos.hpp may not define BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS for vxworks,iostreams,Boost 1.52.0,To Be Determined,Patches,Jonathan Turkanis,new,2013-01-28T16:00:35Z,2013-01-28T16:00:35Z,"in fpos.hpp, l. 26
{{{
#define BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS
}}}
must not be enabled for vxWorks",p.brockamp@…
7937,local_time_types.hpp tries to typedef local_microsec_clock on system without  BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2013-01-28T12:24:39Z,2013-01-28T12:24:39Z,"On platforms that don't define

{{{
BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK
}}}
(e.g. due to a missing gettimeofday()), in file local_time_types.hpp date_time tries to
{{{
typedef date_time::second_clock<local_date_time> local_sec_clock
}}}
This obvioulsy results in a compile error on such systems. This typedef should be embraced by an
{{{
#ifdef BOOST_DATE_TIME_HAS_HIGH_PRECISION_CLOCK
}}}
A patch is attached.
",p.brockamp@…
7934,tuples::element returns wrong typesss for bolatile tuples,tuple,Boost 1.52.0,To Be Determined,Bugs,Joel de Guzman,new,2013-01-28T01:01:27Z,2013-01-28T03:34:46Z,"Hi, 

according to c++11, volatile tuples should return volatile elements.
I think, boost tuple should behave similarly, however it doesn't.

Below is an example with two tests, one test for boost tuple and
one for standard tuple. The boost tuple test fails.



{{{
// file a.cpp
#define BOOST_TEST_MODULE example
#include <boost/test/included/unit_test.hpp>
#include <boost/type_traits.hpp>
#include <boost/tuple/tuple.hpp>
#include <tuple>

BOOST_AUTO_TEST_CASE( boost_tuple )
{
  using boost::is_same;
  using boost::tuple;
  using boost::tuples::element;
  typedef element<0, volatile tuple<int> > VElement;
  typedef element<0, const volatile tuple<int> > CVElement;
  BOOST_CHECK((is_same<typename VElement::type, volatile int>::value));
  BOOST_CHECK((is_same<typename CVElement::type, const volatile int>::value));
}

BOOST_AUTO_TEST_CASE( std_tuple )
{
  using boost::is_same;
  using std::tuple;
  using std::tuple_element;
  typedef tuple_element<0, volatile tuple<int> > VElement;
  typedef tuple_element<0, const volatile tuple<int> > CVElement;
  BOOST_CHECK((is_same<typename VElement::type, volatile int>::value));
  BOOST_CHECK((is_same<typename CVElement::type, const volatile int>::value));
}
}}}


{{{
ptomulik@barakus$ g++ -ansi -std=c++11 -Werror -Wall -Wextra -pedantic a.cpp
ptomulik@barakus$ ./a.out
Running 2 test cases...
a.cpp(15): error in ""boost_tuple"": check (is_same<typename VElement::type, volatile int>::value) failed
a.cpp(16): error in ""boost_tuple"": check (is_same<typename CVElement::type, const volatile int>::value) failed

*** 2 failures detected in test suite ""example""
}}}

my gcc version

{{{
ptomulik@barakus:$ g++ --version
g++ (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 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.
}}}




",ptomulik@…
7933,"Enable population of a map with options described using ""*"" wildcard",program_options,Boost 1.52.0,To Be Determined,Feature Requests,Vladimir Prus,new,2013-01-27T15:56:56Z,2013-01-27T15:56:56Z,"Enable population of a map with options described using ""*"" wildcard.

    map<string, int> itemsMap;
    options_description items(""items options"");
     items.add_options()
        (""item_*"",value<map<string, int>>(&itemsMap)->multitoken(), ""items"")
    ;",smntov@…
7932,"Document the ""*"" wildcard feature in option keys",program_options,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2013-01-27T15:51:31Z,2013-01-27T15:51:31Z,"Document the ""*"" wildcard feature in option keys.",smntov@…
7929,"boost::lexical_cast< std::string, std::wstring > gives a compiler error.",program_options,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2013-01-26T01:44:35Z,2013-06-12T19:07:09Z,"This causes a problem with `boost::program_options::typed_value< std::wstring, wchar_t >::default_value( const std::wstring& v )` which attempts to use lexical_cast to convert `v` into a `std::string`. Using `lexical_cast` to convert a wide string to a normal one may be debatable, but program_options should not give a compiler error on a valid use case such as the one shown below. Luckily you can work around this by providing an explicit `std::string` version or not using the `default_value` method at all.

==== lexical_cast error ====
{{{#!cpp
#include <boost/lexical_cast.hpp>
#include <string>

int main( int argc, wchar_t* argv[] ){
    std::wstring wstr = L""some string"";
    std::string str = boost::lexical_cast< std::string >( wstr );

    return 0;
}
}}}

==== program_options error ====
{{{#!cpp
#include <boost/program_options.hpp>
#include <string>

int main( int argc, wchar_t* argv[] ){
    namespace po = boost::program_options;
    po::options_description opts( ""Some opts"" );

    std::wstring str = L"""";
    opts.add_options()
        (
            ""o"",
            po::wvalue< std::wstring >( &str )
                ->default_value( L""default value"" ), // This line causes error.
            ""an option""
        );

    return 0;
}
}}}
",nate@…
7927,boost::bimap not boost::interprocess compatible.,bimap,Boost 1.52.0,To Be Determined,Bugs,Matias Capeletto,new,2013-01-25T16:33:49Z,2013-01-25T16:33:49Z,"I've been trying to get boost::bimap to work in a
boost::interprocess::managed_mapped_file.

According to Matias Capeletto in this thread on the boost devel mailing list:
http://thread.gmane.org/gmane.comp.lib.boost.devel/238100/

  Bimap is just given your allocator to MultiIndex.
  The issue is that the map views (left, right and relation set) are
  initialized with a reference to the multiindex core in construction
  time... when interprocess read it from memory the second time this
  references are garbage. A direct solution will be to use interprocess
  offset_ptr, but that will have a performance hit so I will have to
  rethink how the views are accessing the core, probably using CRTP.

I've attached two small programs.  Both compile with g++ 4.7.  One
(multiindex.c++) puts a multi_index into the managed_mapped_file.  On
the first run, it creates the data structure puts some stuff in it,
then reopens the data structure and outputs the stuff.  On the second
run, it does the same thing, but it uses the data stored in the mapped
file.

The other program (bimap.c++) does exactly the same thing, but when
run the second time it crashes.  My guess is because bimap isn't quite
interprocess compatible---that is, it isn't using the provided
allocator for EVERYTHING.

Compiled with:
{{{
g++ -o multiindex multiindex.c++   -lpthread
}}}
and
{{{
g++ -g -o bimap bimap.c++   -lpthread
}}}

Joel",jdy@…
7912,boost:thread documentation for 1.50 does not mention BOOST_THREAD_WAIT_BUG,thread,Boost 1.50.0,To Be Determined,Bugs,viboes,assigned,2013-01-21T11:25:12Z,2013-06-09T20:12:37Z,"As I understood from the trac ticket [https://svn.boost.org/trac/boost/ticket/7089] and sources for boost 1.50, boost::thread 1.50 implicitly adds 100 ms to the sleep time of boost::this_thread::sleep and boost::thread_sleep on linux.
If the fix for 7089 cannot be backported into 1.50, the warning about broken functionality must be present in the documentation for 1.50.",Viatcheslav.Sysoltsev@…
7910,MSVC-11 can't find some symbols in Boost::System static library,system,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,new,2013-01-20T21:30:09Z,2013-07-07T16:32:24Z,"
{{{
#ifndef BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND
#define BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND

// I have not had a chance to investigate the root cause of this problem, 
// but it happens when I use boost::asio on MSVC-11 (Visual Studio 2012).
// The problem seems to be that boost::system defines generic_error_category and system_error_category, 
// but then somehow doesn't have these symbols in the libboost_system-vc110-mt-1_52.lib library when you build boost 
// with just ""/b2"" with and toolset=msvc-11.0

// For me the problem happened when I was trying to use boost::asio from something I compiled with MSVC-11.0.
// I got linker errors, so it's a showstopper.
// Feel free to contact me at MyName.MyLastName@Gmail.com for more detail.

// Now, I found that if you build boost on your machine with /b2 and then specifically do these two steps:
// > b2 --with-system threading=multi link=static runtime-link=shared clean
// > b2 --with-system threading=multi link=static runtime-link=shared
// then magicaly the problem goes away and you don't need this workaround below it seems.

// But since the root cause is not clear to me, the problem may not go away for you after the steps above.
// So, if it didn't go away for you indeed, feel free to add this piece of source code into your application.
// Two ways to do it:
//  1. if you are adding this piece of code as an include file, uncomment these two lines:
// #undef BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND 
// #define BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND inline
//  2. but if you are adding it as a separate compilation unit (source file), then don't uncomment anything

#if defined(_MSC_VER) && _MSC_VER >= 1700

#include <system_error> // looks like implementations of three error categories are defined in MSVC 11 include files in 'std' namespace
#include <boost/system/error_code.hpp> // interfaces for those error categories required by boost in 'boost' namespace, but somehow implementations cannot be found in the library files

// glue that hooks up the implementations from MSVC11 to the interfaces required by boost
// (this glue code is **unsafe** in case MSVC or Boost change interfaces for these error categories, because reinterpret_cast is used,
// so a safer way to go about it would be to wrap std::error_category& as a field of some wrapper class that inherits from boost::system::error_category,
// but it works with these versions, because boost and std interfaces are the same (""binary compatible""!) now and I don't yet have time to do it properly)
namespace boost { namespace system {
	error_category const& system_category() { 
		return reinterpret_cast<const error_category&>(std::system_category()); 
	}
	error_category const& generic_category() { 
		return reinterpret_cast<const error_category&>(std::generic_category()); 
	}
	error_category const& iostream_category() {
		return reinterpret_cast<const error_category&>(std::iostream_category());
	}
}}

#endif // defined(_MSC_VER) && _MSC_VER >= 1700

#endif // BOOST_SYSTEM_ERROR_CATEGORY_DIRTY_WORKAROUND
}}}

",Gene Panov
7904,doc: bad qbk macro __boost__ptr_map__,functional/factory,Boost 1.52.0,To Be Determined,Bugs,t_schwinger,new,2013-01-18T19:02:28Z,2013-01-18T19:02:28Z,"see [http://www.boost.org/doc/libs/1_52_0/libs/functional/factory/doc/html/index.html]

search for `__boost__ptr_map__`. It is probably meant to be `boost::ptr_map`.",Eric Niebler
7902,Division by scalar should use enable_if<> (matrix_expression),uBLAS,Boost 1.53.0,To Be Determined,Bugs,Gunter,new,2013-01-18T02:55:55Z,2015-07-01T13:44:01Z,"Bug #6511 added enable_if<> to file: vector_expression.hpp function: operator/( vector, scalar).  The same feature needs to be add to matrix_expression's operator/( matrix, scalar).  See attached e-mail

",campreilly@…
7901,jam's hash.c misaligns hashed entries,build,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2013-01-17T16:05:56Z,2014-10-09T05:59:52Z,"On platforms where a void* is smaller (e.g. 32bit) than a time_t (e.g. 64bit) and where the cpu requires strict alignment, jam bus errors already during bootstrap. NetBSD/sparc is an example for such a platform.

This is because the hash_item_data macro () casts to char* and adds sizeof a struct only containing a pointer, while later filesys code stores file_info_t structures in a hash (which include time_t members and need greater alignment).

Since this is all needed very early, the easiest and most portable solution is to force sizeof(ITEM) to be great enough for the required alignment by making it a union including a dummy time_t member. This has the benefit of beeing a no-op for non affected architectures.

I have a patch tested against the 1.52 release, but the idea should be obvious and applying it to the (a bit different) trunk code should be straighforward. Please let me know if you need a real patch against trunk.",martin@…
7897,Add timeout parameter to all Boost::ASIO socket operations,asio,Boost Development Trunk,To Be Determined,Feature Requests,chris_kohlhoff,new,2013-01-16T00:48:35Z,2013-01-16T00:48:35Z,"Right now the user has to implement some code in order to implement timeouts to be used with ASIO.

A better way is if ASIO could handle timeouts internally.

For example, take the method async_connect.  A new 4-byte integer parameter could be added to the function signature that when greater than zero, would specify the number of milliseconds to wait before timing out.  If the value specified was set to zero, then the code would use whatever default timeout that the raw socket was set to use.  If it was set to less than zero, then it would set the timeout to the maximum value or not use a timeout.

A timeout parameter should be added to any ASIO method call that uses or may use a socket read, write, or connection function.  If a method is buried that uses a socket connection, then the class it is in should provide a way to specify the timeout value.",RobertGBryan@…
7896,"boost::numeric::ublas::unbounded_array::operator= can call std::copy(0, 0, x)",uBLAS,Boost 1.53.0,To Be Determined,Patches,Gunter,new,2013-01-15T13:30:06Z,2013-01-15T13:30:06Z,This causes an assertion failure with Visual Studio 2008+2010 when _ITERATOR_DEBUG_LEVEL == 2,lukeocamden@…
7893,Unresolved link errors when building 64 bit ASIO with 64 bit OpenSSL under Windows,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-01-14T22:55:35Z,2013-02-04T13:43:29Z,"According to this link:

http://stackoverflow.com/questions/9357751/boost-ssl-with-visual-studio-2010-and-openssl

There is a problem when trying to build a very simple program which includes 3 include files from Boost::ASIO.  The program fails to build when linking with the 64 bit version of the Boost library as well as the 64 bit version of the OpenSSL library.

The build succeeds when the 32 bit version of the Boost library is used in conjunction with the 32 bit version of the OpenSSL library.

I have tried building it for Boost versions 1.51 and 1.52.  Have also tried the c and j versions of the 64 bit OpenSSL library for Windows which results in the same error.

The link above is for building with VS2010.  The same error results for me when I try to build with VS2008.  I have also written a description of the problem in StackOverflow.com as well which involved building one of the ASIO example programs:

http://stackoverflow.com/questions/14286346/link-unresolved-error-with-vs2008-boost-asio-and-openssl

The work around to the problem right now is to build it with 32 bit libraries.

If you can successfully build using VS2010 or VS2008 with the 64 bit versions, then please advise on what you think the problem might be.  This problem has been reported by several individuals.",RobertGBryan@…
7884,unused parameter warnings,tokenizer,Boost 1.52.0,To Be Determined,Bugs,jsiek,new,2013-01-11T17:27:57Z,2013-01-11T17:27:57Z,"Hello,

 I've noticed a few 'unused parameter' warnings in the spirit library, as
 discussed in the related bug https://svn.boost.org/trac/boost/ticket/7880.
 After suggestion, I'm submitting a new bug against the specific project.

 Attached is a patch that fixes those ones that I've found (by not naming
 the parameters).",alex@…
7881,ASIO - don't use Winsock when compiling with Cygwin,asio,Boost 1.48.0,To Be Determined,Bugs,chris_kohlhoff,new,2013-01-11T09:49:54Z,2013-01-17T07:40:02Z,"It's not necessarily a bug, but an improvement.
I checked why i can compile with the integrated boost library in normal Cygwin distribution and i cannot do the same with some other boost variant.
The main difference is the __CYGWIN__ compile switch. In the Cygwin integration, the compile switch is removed and it will use linux sockets.
The boost distributions force the usage of Winsock which clearly cause compile problems with Cygwin.

Please remove the compile switch and just let it use the linux sockets.

",Ionut Craioveanu <mosteaca@…>
7879,Optimize equality comparison,multiprecision,Boost 1.53.0,To Be Determined,Feature Requests,John Maddock,new,2013-01-10T23:22:58Z,2013-10-11T13:07:14Z,"Comparing two numbers for equality should be trivial. However, current implementation uses one or two less-then operators. For rational numbers this is very inefficient because less-then operator is both complex and slow.",Stepan Podoskin <stepik-777@…>
7865,error: unknown target CPU 'i386' for the boost b2 build using architecture=x86 address-model=32,build,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2013-01-07T19:33:56Z,2013-05-20T12:58:33Z,"Trying to build boost 1.52 for 32 bit architecture on OS X 10.7.5, using clang:

./b2 toolset=clang cxxflags=""-std=c++11 -stdlib=libc++"" linkflags=""-stdlib=libc++"" architecture=x86 address-model=32

Get a lot of errors of this type:


{{{
    ""clang++"" -x c++ -O3 -std=c++11 -stdlib=libc++ -O3 -finline-functions -Wno-inline -Wall -march=i386 -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I""."" -c -o ""bin.v2/libs/date_time/build/clang-darwin-4.2.1/release/address-model-32/architecture-x86/threading-multi/gregorian/greg_month.o"" ""libs/date_time/src/gregorian/greg_month.cpp""

...failed clang-darwin.compile.c++ bin.v2/libs/date_time/build/clang-darwin-4.2.1/release/address-model-32/architecture-x86/threading-multi/gregorian/greg_month.o...
clang-darwin.compile.c++ bin.v2/libs/date_time/build/clang-darwin-4.2.1/release/address-model-32/architecture-x86/threading-multi/gregorian/greg_weekday.o
error: unknown target CPU 'i386'
}}}
",anonymous
7858,boost should not blindly assume that MinGW installation is in c:\ directory,Building Boost,Boost 1.52.0,To Be Determined,Bugs,,new,2013-01-05T10:09:20Z,2013-01-05T10:09:20Z,"instead it should search the directory in which main boost dir lies and then if not found should withdraw to defauld directory

so in file : boost\tools\build\v2\engine\build.bat

{{{
#!html
<pre>
if EXIST ""C:\MinGW\bin\gcc.exe"" (
    set ""BOOST_JAM_TOOLSET=mingw""
    set ""BOOST_JAM_TOOLSET_ROOT=C:\MinGW\""
    goto :eof)
call :Clear_Error
</pre>
}}}

</pre>
}}}

should instead be:

{{{
#!html
<pre>
if EXIST ""..\MinGW\bin\gcc.exe"" (
    set ""BOOST_JAM_TOOLSET=mingw""
    set ""BOOST_JAM_TOOLSET_ROOT=..\MinGW\""
    goto :eof)
call :Clear_Error
</pre>
}}}

to catch that mingw installation which lies along with boost in the same parent directory. This is needed in case both of them are run from removable drive or there are different pairs of boost and mingw for testing.",anonymous
7854,Boost 1.49 compilation warnings [FreeBSD] - timer,timer,Boost 1.49.0,Boost 1.54.0,Bugs,Beman Dawes,new,2013-01-04T18:32:54Z,2013-01-04T18:32:54Z,"These are the compilation warnings from Boost 1.49 on this platform: FreeBSD RELENG_8 i386 gcc 4.2.2/4.6.3 

libs/timer/src/cpu_timer.cpp:139: warning: comparison between signed and unsigned integer expressions ",grarpamp@…
7852,Boost 1.49 compilation warnings [FreeBSD] - python,python USE GITHUB,Boost 1.49.0,Boost 1.54.0,Bugs,Vladimir Prus,new,2013-01-04T18:30:31Z,2013-01-05T19:27:49Z,"These are the compilation warnings from Boost 1.49 on this platform: FreeBSD RELENG_8 i386 gcc 4.2.2/4.6.3

libs/python/src/list.cpp:16: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/long.cpp:12: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/long.cpp:19: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/long.cpp:26: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/dict.cpp:32: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/tuple.cpp:12: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/str.cpp:16: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/enum.cpp:150: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:211: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:319: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:473: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:621: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/class.cpp:631: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/function.cpp:108: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/function.cpp:110: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/life_support.cpp:94: warning: dereferencing type-punned pointer will break strict-aliasing rules libs/python/src/object/life_support.cpp:96: warning: dereferencing type-punned pointer will break strict-aliasing rules 
",grarpamp@…
7848,[enhancement] supply download tarballs as tar.xz instead of .bz2,Building Boost,Boost 1.52.0,To Be Determined,Feature Requests,,new,2013-01-04T11:46:35Z,2016-07-24T00:41:41Z,"you already have .gz tarballs, which is perfect for systems that don't yet support .xz (which at this time are little, any linux system i know supports it and probably even current macOS X releases)

so the only reason for supplying bzip2 downloads must be for smaller storage/download time requirements.

however, xz packs a lot better than bzip2, and bzip2 is a very slow (highly CPU-bound) to unpack algorithm.

on average, extracting .xz is about 3.5 times faster than bzip2.

/dev/shm $ time tar xf boost_1_52_0.tar.bz2

real    0m10.939s
user    0m10.747s
sys     0m1.390s
/dev/shm $ tar cJf boost_1_52_0.tar.xz boost_1_52_0
boost_1_52_0/         boost_1_52_0.tar.bz2  
/dev/shm $ time tar cJf boost_1_52_0.tar.xz boost_1_52_0

real    2m12.790s
user    2m10.255s
sys     0m3.822s
/dev/shm $ rm -rf boost_1_52_0
/dev/shm $ time tar xf boost_1_52_0.tar.xz 

real    0m4.940s
user    0m4.762s
sys     0m1.232s
/dev/shm $ la boost_1_52_0.tar.xz 
-rw-r--r-- 1 user users 47673912 Jan  4 10:17 boost_1_52_0.tar.xz
/dev/shm $ la boost_1_52_0.tar.bz2 
-rw-r--r-- 1 user users 54421709 Jan  4 10:14 boost_1_52_0.tar.bz2

this testing was done on a high-end 3.1 GHZ machine, and here the difference is that xz is more than 2 times faster, and the tarball 7 MB smaller.
when using 2 distinct steps to create the .xz archive and invoking the xz compressor with -E (extreme), makes the tarball even smaller.

i also build software regularly on mips and arm platforms in qemu.
as an example, untarring the linux kernel sources provides as .bzip2 takes roughly 2 hours, but untarring the .xz archive ""only"" 30 minutes.

so imo it makes much sense to deprecate .bz2 downloads and replace them with .xz.
the .gz files need to stay in order to have a fallback for outdated platforms.
",anonymous
7840,Failure in posix_time_zone when specifying start date as Jn,date_time,Boost 1.50.0,To Be Determined,Bugs,az_sw_dude,new,2013-01-02T02:10:13Z,2013-01-02T02:10:13Z,"If you use the time zone specification ""CST-2CDT,J365/00,J1/00"" to create a boost::local_time::posix_time_zone, it fails with an exception.

The problem appears to be in boost\date_time\local_time\posix_time_zone.hpp, julian_no_leap(...). The conversion of the start date uses this loop which has a ""less than or equal"" clause:
 while(sd >= calendar::end_of_month_day(year,sm)){
  sd -= calendar::end_of_month_day(year,sm++);
 }
sd is the converted start specifier (365 in this case); sm is the current month (initialized to 1). The loop continues until sd=0 and sm=13, at which point end_of_month_day() throws an exception.

Conversion of the end date uses an almost identical loop except that its while clause is ""strictly less than"":
 while(ed > calendar::end_of_month_day(year,em)){
  ed -= calendar::end_of_month_day(year,em++);
 }
So the specifier ""CST-2CDT,J1/00,J365/00"" leaves ed=31 and em=12 as you would hope.

In fact any start specifier at the end of a month (J31, J59,...J334) will fail later because it will result in sd=0 which is outside the range of 1..31.

This code is identical in boost 1.52.0. The fix appears to be just to use ""strictly less than"" in both loops.
",andrew.lang@…
7838,Exposing hander sizes of each call as constants.,asio,Boost 1.52.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2012-12-29T20:11:41Z,2012-12-29T20:14:07Z,"Hello!

This feature request is related to the CustomHandler api.

As the internal handler storage size is fixed for each async api call (I think...), would it be possible to add constants that inform about the maximum size requirements of each async call?

That would ease the implementation of segregated storage pools storing custom handlers, making it more suitable for realtime use.

For example of what I'm using on x86 linux, I found that an ""async_wait"" takes 40 bytes, an ""async_receive_from"" 72, and an ""async_send_to"" 92.

What I'm doing now is ""fake calls"" in initialization time, retreiving the requested sizes through a CustomHandler that traces the sizes, and then initializing the segregated storage pools with the results. 

That could easily be avoided exposing the size constants in some way.

The current custom handler API wouldn't need to change.

I must say that it was very wise to add the block size to the deallocation call, it eased things a lot, it allowed me to write safety code to forward the allocation/deallocation calls to the heap in case that the size requested wasn't the one.

Best regards!
Rafa.",rafael_gago_81@…
7836,Add GIL RAII module to Boost.Python,python USE GITHUB,Boost Development Trunk,To Be Determined,Patches,Ralf W. Grosse-Kunstleve,new,2012-12-29T16:51:53Z,2012-12-29T16:51:53Z,"This ticket follows a recent discussion I started on the Python C++ SIG mailing list (which in turn followed a brief topic on the Boost developers list).

I would like to submit for inclusion in Boost.Python a pair of classes for releasing and acquiring the Python Global Interpreter Lock (GIL) using RAII semantics.

Please see three files attached to this ticket: gil.hpp, gil.cpp, and gil_test.cpp, which implement and (lightly) test this new feature.  They are modified from versions I maintain on GitHub in order to make them more compatible with existing code style in Boost.Python.

This code (with different naming conventions but the same logic) has been used successfully by me ""in production"" and the releaser class is inspired by several examples online that others have until now copy-pasted when needed.",John Zwinck <jzwinck@…>
7822,"waveidl sample does not use the IDL lexer, but the default lexer",wave,Boost 1.52.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-12-21T19:38:17Z,2012-12-21T19:38:17Z,"Dear Boost developpers,

The waveidl sample from the wave lib does not use the included IDL lexer. Instead it uses the default cpp lexer. This can be easily tested by setting a breakpoint in the scan function in idl_re.cpp. The reason is that it is explicitly set up like this in the lex_iterator constructor. The #if 0 branch below is the original code, the #else branch is modified to use the IDL lexer.

    template <typename IteratorT>
    lex_iterator(IteratorT const &first, IteratorT const &last, 
            typename TokenT::position_type const &pos, 
            boost::wave::language_support language)
    :   base_type(
            functor_data_type(
                unique_functor_type(),
#if 0
                cpplexer::lex_input_interface_generator<TokenT>
                    ::new_lexer(first, last, pos, language)
#else
                boost::wave::idllexer::new_lexer_gen<
                std::string::iterator>::new_lexer( first, last, pos, language )
#endif
                )
        )
    {}

Now if I do the above modification, the preprocessor stops after the first include file with this warning:

""warning: last line of file ends without a newline""

Somehow the function which checks if there is a return from an include always returns false.

Btw.: What I want to achieve is a preprocessor for Verilog-A, which is a simplified variant of a C preprocessor with ` instaed of #. It should be easy, but I cannot get it to work.

Thanks & best regards,

Michael",Michael Soegtrop <michael.soegtrop@…>
7821,Cannot user tuple in unordered_set,unordered,Boost 1.52.0,To Be Determined,Bugs,Daniel James,new,2012-12-21T18:58:40Z,2012-12-22T09:37:34Z,"Compiling this program:

#include ""boost/tuple/tuple.hpp""
#include ""boost/unordered_set.hpp""

int main()
{
	boost::unordered_set<boost::tuple::tuple<char> > tuples;

	return 0;
}

using g++ (GCC) 4.8.0 20121216 (experimental) and boost 1.52.0 fails with this error:

In file included from /usr/include/boost/unordered/detail/table.hpp:10:0,
                 from /usr/include/boost/unordered/detail/equivalent.hpp:14,
                 from /usr/include/boost/unordered/unordered_set.hpp:17,
                 from /usr/include/boost/unordered_set.hpp:16,
                 from boost_tuple_hash.cpp:2:
/usr/include/boost/unordered/detail/buckets.hpp: Jäsenfunktio ”void boost::unordered::detail::node_constructor<NodeAlloc>::construct_with_value(const Args&)”:
/usr/include/boost/unordered/detail/buckets.hpp:338:13: virhe: ”construct_value_impl” is not a member of ”boost::unordered::detail”
             boost::unordered::detail::construct_value_impl(
             ^
/usr/include/boost/unordered/detail/buckets.hpp: Jäsenfunktio ”void boost::unordered::detail::node_constructor<NodeAlloc>::construct_with_value2(const A0&)”:
/usr/include/boost/unordered/detail/buckets.hpp:347:13: virhe: ”construct_value_impl” is not a member of ”boost::unordered::detail”
             boost::unordered::detail::construct_value_impl(
             ^
/usr/include/boost/unordered/detail/buckets.hpp: In destructor ”boost::unordered::detail::node_constructor<NodeAlloc>::~node_constructor()”:
/usr/include/boost/unordered/detail/buckets.hpp:377:17: virhe: ”destroy_value_impl” is not a member of ”boost::unordered::detail”
                 boost::unordered::detail::destroy_value_impl(alloc_,
                 ^
/usr/include/boost/unordered/detail/buckets.hpp: Jäsenfunktio ”void boost::unordered::detail::node_constructor<NodeAlloc>::construct()”:
/usr/include/boost/unordered/detail/buckets.hpp:409:17: virhe: ”destroy_value_impl” is not a member of ”boost::unordered::detail”
                 boost::unordered::detail::destroy_value_impl(alloc_,
                 ^
/usr/include/boost/unordered/detail/buckets.hpp: In destructor ”boost::unordered::detail::node_holder<NodeAlloc>::~node_holder()”:
/usr/include/boost/unordered/detail/buckets.hpp:526:13: virhe: ”destroy_value_impl” is not a member of ”boost::unordered::detail”
             boost::unordered::detail::destroy_value_impl(this->alloc_,
             ^
/usr/include/boost/unordered/detail/buckets.hpp: At global scope:
/usr/include/boost/unordered/detail/buckets.hpp:775:12: virhe: ”struct boost::unordered::detail::please_ignore_this_overload” uudelleenmääritelty
     struct please_ignore_this_overload {
            ^
In file included from /usr/include/boost/unordered/detail/buckets.hpp:15:0,
                 from /usr/include/boost/unordered/detail/table.hpp:10,
                 from /usr/include/boost/unordered/detail/equivalent.hpp:14,
                 from /usr/include/boost/unordered/unordered_set.hpp:17,
                 from /usr/include/boost/unordered_set.hpp:16,
                 from boost_tuple_hash.cpp:2:
/usr/include/boost/unordered/detail/allocate.hpp:177:12: virhe: previous definition of ”struct boost::unordered::detail::please_ignore_this_overload”
     struct please_ignore_this_overload {
            ^
In file included from /usr/include/boost/unordered/detail/table.hpp:10:0,
                 from /usr/include/boost/unordered/detail/equivalent.hpp:14,
                 from /usr/include/boost/unordered/unordered_set.hpp:17,
                 from /usr/include/boost/unordered_set.hpp:16,
                 from boost_tuple_hash.cpp:2:
/usr/include/boost/unordered/detail/buckets.hpp:780:12: virhe: ”struct boost::unordered::detail::rv_ref_impl<T>” uudelleenmääritelty
     struct rv_ref_impl {
            ^
In file included from /usr/include/boost/unordered/detail/buckets.hpp:15:0,
                 from /usr/include/boost/unordered/detail/table.hpp:10,
                 from /usr/include/boost/unordered/detail/equivalent.hpp:14,
                 from /usr/include/boost/unordered/unordered_set.hpp:17,
                 from /usr/include/boost/unordered_set.hpp:16,
                 from boost_tuple_hash.cpp:2:
/usr/include/boost/unordered/detail/allocate.hpp:182:12: virhe: previous definition of ”struct boost::unordered::detail::rv_ref_impl<T>”
     struct rv_ref_impl {
            ^
In file included from /usr/include/boost/unordered/detail/table.hpp:10:0,
                 from /usr/include/boost/unordered/detail/equivalent.hpp:14,
                 from /usr/include/boost/unordered/unordered_set.hpp:17,
                 from /usr/include/boost/unordered_set.hpp:16,
                 from boost_tuple_hash.cpp:2:
/usr/include/boost/unordered/detail/buckets.hpp:785:12: virhe: ”struct boost::unordered::detail::rv_ref<T>” uudelleenmääritelty
     struct rv_ref :
            ^
In file included from /usr/include/boost/unordered/detail/buckets.hpp:15:0,
                 from /usr/include/boost/unordered/detail/table.hpp:10,
                 from /usr/include/boost/unordered/detail/equivalent.hpp:14,
                 from /usr/include/boost/unordered/unordered_set.hpp:17,
                 from /usr/include/boost/unordered_set.hpp:16,
                 from boost_tuple_hash.cpp:2:
/usr/include/boost/unordered/detail/allocate.hpp:187:12: virhe: previous definition of ”struct boost::unordered::detail::rv_ref<T>”
     struct rv_ref :
            ^
In file included from /usr/include/boost/unordered/detail/equivalent.hpp:14:0,
                 from /usr/include/boost/unordered/unordered_set.hpp:17,
                 from /usr/include/boost/unordered_set.hpp:16,
                 from boost_tuple_hash.cpp:2:
/usr/include/boost/unordered/detail/table.hpp: Jäsenfunktio ”void boost::unordered::detail::table<Types>::delete_node(boost::unordered::detail::table<Types>::c_iterator)”:
/usr/include/boost/unordered/detail/table.hpp:505:13: virhe: ”destroy_value_impl” is not a member of ”boost::unordered::detail”
             boost::unordered::detail::destroy_value_impl(node_alloc(),
             ^
boost_tuple_hash.cpp: Funktio ”int main()”:
boost_tuple_hash.cpp:6:49: virhe: template argument 1 is invalid
  boost::unordered_set<boost::tuple::tuple<char> > tuples;
                                                 ^
boost_tuple_hash.cpp:6:49: virhe: template argument 2 is invalid
boost_tuple_hash.cpp:6:49: virhe: template argument 3 is invalid
boost_tuple_hash.cpp:6:49: virhe: template argument 4 is invalid
boost_tuple_hash.cpp:6:57: virhe: invalid type in declaration before ”;” token
  boost::unordered_set<boost::tuple::tuple<char> > tuples;
                                                         ^
boost_tuple_hash.cpp:6:51: varoitus: käyttämätön muuttuja ”tuples” [-Wunused-variable]
  boost::unordered_set<boost::tuple::tuple<char> > tuples;
                                                   ^",ilja.honkonen@…
7811,interprocess/synchronization_mechanisms.html message_queue example bug,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-12-19T16:17:40Z,2013-01-03T19:18:29Z,"http://www.boost.org/doc/libs/1_52_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.message_queue.message_queue_example

See the second example here (after ""This is the second process:""):
{{{
      //Open a message queue.
      message_queue mq
         (open_only        //only create
         ,""message_queue""  //name
         );
}}}

The first arguments of the constructor conradicts comment message. It seems that ""only create"" should be replaced by ""only open"".",sarum9in@…
7810,zlib_error::check throws on Z_BUF_ERROR,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-12-19T11:53:51Z,2016-12-09T01:17:31Z,zlib_error::check has a line that checks for Z_BUF_ERROR but it is commented out. Now the documentation for zlib states that Z_BUF_ERROR is not a fatal error and so I think the commented code should actually be activated since it now happens to me that io::zlib_decompressor fails on one of my files.,m.hekkelman@…
7807,message_queue do_send and do_receive blocked for interprocess_mutex,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-12-18T08:35:43Z,2016-01-04T23:00:20Z,"Sending program A  send information to the receiving program B, if the program B quit unexpectedly. Starting the program again B,Program A and B  will block in “scoped_lock<interprocess_mutex> lock(p_hdr->m_mutex)”",zyt1013@…
7803,[program_options] boost/program_options/errors.hpp:253: warning: unused parameter ‘option_name’,program_options,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2012-12-18T01:42:28Z,2013-01-17T20:01:34Z,"The following warning is present in boost.program_options, and the 
boost/program_options/errors.hpp:253: warning: unused parameter ‘option_name’",Andrew Hundt <ATHundt@…>
7793,Not needed code for mapped files in windows,interprocess,Boost 1.52.0,To Be Determined,Tasks,Ion Gaztañaga,new,2012-12-13T23:40:11Z,2012-12-13T23:40:11Z,"The exchange below took place on the boost developer list, it describes the request. Thank you.

> > > When you grow a managed mapped file, the current
> > > implementation fills all the new space with zeroes. This is less
> > > efficient than just resizing the file. The comments in the code
> > > implies there is a reason, so what is  it?
> >

> > Interprocess tries to simulate as much as possible POSIX guarantees.
> > truncate() POSIX system call guarantees that ""If the file is
> extended,
> > the extended area appears as if it were zero-filled"". In windows,
> > SetFileValidData/SetEndOfFile does not zero-fill the extended size so
> > Interprocess needs to write it.

> Given that the mapped file content is not part of the library
> interface, and the only expected user of the mapped file is the library
> itself, why waste time in Windows? Seems to me that a requirement that
> files should be identical is too strong, as long as they work and
> perhaps don't affect platform portability. File portability between
> platforms should be warranted? What about platforms with different
> endianness?

I need to investigate it, but I tried to support similar behaviour for internal file-handling functions. I'll need to think it again. Please fill a ticket so this doesn't get lost when reviewing pending issues.
",lodos@…
7792,Boost serialization is incompatible with final keyword,serialization,Boost 1.52.0,To Be Determined,Bugs,John Maddock,new,2012-12-13T18:58:00Z,2012-12-13T19:12:34Z,"When a class is marked as final using the C++11 final keyword it is not possible to serialize it using boost::serialization, because compilation fails while instantiating boost::detail::is_polymorphic_imp1<...>. 

A minimal example is attached in main.cpp. The output of Visual Studio 2012 SP1 attempting to compile this example can be found in BoostSerializationBugReport.log.",Marco Wannemaker <marco.wannemaker@…>
7790,Length check for destination buffer,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-12-13T09:53:00Z,2012-12-13T09:53:00Z,"In file boost/asio/detail/impl/socket_ops.ipp

In case of IPV6, length of dest is not verified while doing strcat
at line no:1883
This is required to validate argument length passed by user.

Attached patch is proposed fix for this.

",Gaurav Gupta <g.gupta@…>
7786,Add support for RTTI-disabled environments,iostreams,Boost 1.52.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-12-11T13:18:17Z,2014-08-26T11:33:54Z,Boost.Iostreams does not compile when -fno-rtti is defined. There are lots of environments where it is not possible to activate RTTI. It would be useful if it could support non-RTTI settings even if it means a smaller set of functionality.,Adam Romanek <romanek.adam@…>
7777,at() member function required for program_options::variables_map,program_options,Boost 1.52.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-12-09T18:36:39Z,2012-12-09T18:36:39Z,"variables_map provides operator[] which sets an empty value to the option, if the specified key does not exist.[[BR]]
I think it would be nice and more robust to also provide an overrided member function at() which throws an exception for such circumstances.

Related ticket: #7495. If implementing #7495, it will be also required to handle boost::optional values for at().",Nana Sakisaka <n.sakisaka@…>
7769,BOOST_MPL_LIMIT_METAFUNCTION_ARITY > 8 causes compilation error on gcc,mpl,Boost 1.52.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-12-05T20:50:25Z,2015-02-08T23:30:37Z,"
{{{
#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
#define BOOST_MPL_LIMIT_METAFUNCTION_ARITY 9

#include <boost/mpl/lambda.hpp>

int main() {
    return 0;
}

}}}

The above code fails to compile on g++ (4.6.3 and 4.7.2 checked). Visual Compiler(VS 2010) compiles this correctly even with BOOST_MPL_LIMIT_METAFUNCTION_ARITY == 100.

See also [http://boost.2283326.n4.nabble.com/boost-mpl-bimap-BOOST-MPL-LIMIT-METAFUNCTION-ARITY-issue-on-g-4-6-3-and-boost-1-50-td4639407.html#a4639506]
",Adam Lach <salvage@…>
7763,Boost.Parameter functions no longer accept non-moveable types as arguments,parameter,Boost 1.52.0,To Be Determined,Bugs,Daniel Wallin,new,2012-12-04T04:00:23Z,2012-12-04T04:00:23Z,"Boost.Parameter suffered a regression because of a change to the semantics of boost::is_convertible.  It used to be possible to pass a non-movable type to a Boost.Parameter function, but that no longer works as of Boost 1.47 (at least on certain compilers; gcc continued to work for some more Boost versions but doesn't in 1.52).

The issue with is_convertible was discussed in more detail in this thread: http://boost.2283326.n4.nabble.com/type-traits-parameter-Inconsistent-boost-is-convertible-between-gcc-and-clang-td4634162.html

It first manifested in clang, but now also appears in gcc thanks to the bugfix discussed that thread.

I attach an example demonstrating the problem.

I have worked around the problem locally by editing boost/parameter/preprocessor.hpp and changing

    typedef is_convertible<mpl::_, Target> type;

to

    typedef is_convertible<mpl::_, const Target&> type;

I make no claim that this is exactly the correct fix, but I believe something along these lines is required.",John Bytheway <jbytheway+boost@…>
7759,Support ; as comment character in config file,program_options,Boost 1.47.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-12-03T17:09:12Z,2012-12-03T17:09:12Z,"Currently # is hardcoded as comment character, but for ini file, both # and ; are widely used as comment characters.

Because program_options doesn't allow a non-section line without =, the config file parsing will fail if there are ; comments which doesn't have = in it.

For example, this line will fail to parse:

; This is a comment

The easiest fix will be adding check of ; in common_config_file_iterator::get()

Thanks.",uniwangshan@…
7756,Boost.HS install instructions outdated,quickbook,Boost 1.52.0,To Be Determined,Bugs,Daniel James,new,2012-12-02T10:21:38Z,2014-04-09T02:18:45Z,The install instructions and install.sh for Boost.HS are outdated with regard to KDE 4.x. The katepart syntax files are stored in /usr/share/kde4/apps/katepart/syntax rather than /usr/share/apps/katepart/syntax.,Andrey Semashev
7750,iostreams & thread cancellation issue,iostreams,Boost Development Trunk,To Be Determined,Bugs,Jonathan Turkanis,new,2012-11-29T12:59:19Z,2012-11-29T13:01:52Z,"In NPTL thread cancellation is implemented using exceptions.
The iostreams functions contains a catch-all clause which does not rethrow the exception. This is possible to expect but should really never happen in any code. The rules C++ experts developed state that catch-all cases must rethrow. If not then strange things can happen since one doesn't always know exactly what exceptions are thrown.

Simple patch for sync functions attached.",Oleg.Dolgov@…
7747,Wrong header file information in ptr_container documentation,ptr_container,Boost 1.52.0,To Be Determined,Bugs,Thorsten Ottosen,new,2012-11-28T15:29:29Z,2012-12-18T17:09:15Z,"http://www.boost.org/doc/libs/1_52_0/libs/ptr_container/doc/ptr_container.html says ""Serialization has now been made optional thanks to Sebastian Ramacher. You simply include <boost/ptr_container/serialize.hpp> or perhaps just one of the more specialized headers."" This serialize.hpp does not exist (at least in 1.52), the more specialized headers do.
",anonymous
7742,tie like functionality for ranges,range,Boost 1.52.0,To Be Determined,Feature Requests,Neil Groves,assigned,2012-11-27T11:56:41Z,2014-03-03T01:50:10Z,"The Graph library uses std::pair to pass ranges and this allows a nice pattern to use old-fashioned for-loops:

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

This works without any modifications with pair. 

The functionality would be great for all ranges as it provides users
that don't want to use Boost.Range algorithms with a simple way to use
their preferred style or algorithms from std.
",philipp.moeller@…
7737,Minor comment typo in boost/wave/cpplexer/re2clex/cpp_re2c_lexer.hpp,wave,Boost 1.52.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-11-27T02:55:13Z,2012-11-27T02:55:13Z,Patch attached for fixing it.,oss.2012.team+E4@…
7736,Boost.Units io.hpp always includes Boost.serialization and an unwanted Clang warning,units,Boost 1.52.0,To Be Determined,Support Requests,Steven Watanabe,new,2012-11-26T18:01:47Z,2012-11-26T18:01:47Z,"I note that Boost.Units io.hpp''' always''' #includes serialization (a not inconsiderable amount of code to parse etc).  It would be nice if Serialization could only be included when required (but perhaps this is troublesome?)

This became apparent when compiling using Clang 3.1 (Ruben van Boxem's mingw32) on Netbeans 7.2 on Windows 7 when this ugly warning appeared:

{{{

In file included from i:/boost-trunk\boost/units/io.hpp:27:
In file included from i:/boost-trunk\boost/serialization/nvp.hpp:34:
In file included from i:/boost-trunk\boost/serialization/base_object.hpp:39:
i:/boost-trunk\boost/serialization/void_cast_fwd.hpp:29:1: warning: dllexport attribute ignored
BOOST_DLLEXPORT 
^
i:/boost-trunk\boost/serialization/force_include.hpp:37:43: note: expanded from macro 'BOOST_DLLEXPORT'
#       define BOOST_DLLEXPORT __declspec(dllexport)
                                          ^
<built-in>:150:38: note: expanded from macro '__declspec'
#define __declspec(a) __attribute__((a))
                                     ^
1 warning generated.
}}}

This also suggests that inappropriate dllexport attribute is being generated for Clang?



",Paul A. Bristow
7735,Ability to provide option_description name as Regex,program_options,Boost 1.52.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-11-26T13:18:29Z,2013-01-20T06:17:39Z,"It would be nice to have the ability to provide option_description name as Regex in order to parse open-end options like this:
item1 = 234
item2 = 345
...
itemN = 564",smntov@…
7732,"Spirit Karma calls compile unqualified, which causes it to use compile functions found by ADL",spirit,Boost Development Trunk,To Be Determined,Bugs,Joel de Guzman,new,2012-11-25T15:23:10Z,2012-11-25T15:23:10Z,"In boost/spirit/home/karma/generate.hpp, the function generate and generate_delimited calls compile without qualification. Which allows finding compile functions by ADL if the expression contains terminals not defined in the spirit namespace.

The call should be qualified.",felipe.m.almeida@…
7730,Generic specializations of is_nullary for custom terminals are not possible,phoenix,Boost 1.52.0,To Be Determined,Bugs,Thomas Heller,new,2012-11-24T12:34:14Z,2014-03-12T06:51:51Z,"The is_nullary trait is specialized for all custom_terminal<T> to be true (see phoenix/code/is_nullary.hpp).

{{{
template <typename T>
struct is_nullary<custom_terminal<T> >
    : mpl::true_
{};
}}}

This is not true with regard to multiple terminals I define in Boost.Log. This forces me to specialize is_nullary for all my custom terminals, and I cannot provide a single blanket specialization for all my terminals.

The is_nullary trait has a second template parameter which is intended to be used exactly for this purpose. A nested tag void typedef can be used to match the trait for a set of types. I could create the following specialization:

{{{
template <typename T>
struct is_nullary<custom_terminal<T>, typename T::_is_my_terminal >
    : mpl::false_
{};
}}}

However this extension mechanism does not work because the two specializations are considered equally specialized and the compiler reports ambiguity.

I suggest to limit the first specialization to only match the default custom terminals, e.g.:

{{{
template <typename T>
struct is_nullary<custom_terminal<T>, typename custom_terminal<T>::_is_default_custom_terminal >
    : mpl::true_
{};
}}}

Where typedef void _is_default_custom_terminal will be added to the generic custom_terminal template.
",Andrey Semashev
7729,concept_def.hpp multiple inclusion prevention macro bug,graph,Boost 1.52.0,Boost 1.56.0,Bugs,acharles,assigned,2012-11-23T14:35:43Z,2014-02-21T09:35:24Z,"In boost/concept/detail/concept_def.hpp, the BOOST_CONCEPT_DETAIL_CONCEPT_DEF_DWA200651_HPP macro does not apply to the whole include file (search for its pending endif).

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

{{{
""BOOST_concept"" redefined
[...]
}}}
",moala@…
7727,Gettext information retriever,locale,,To Be Determined,Feature Requests,Artyom Beilis,new,2012-11-22T18:43:27Z,2013-01-07T12:08:04Z,"So I figured it'd be nice if we were able to see things about which Gettext catalog is loaded. So I worked up this patch.

The unit test kind of explains how to use it, it's much like locale::info but it requires an object to be created (and deleted by the user, which is a bit shoddy)

If the patch is any good I'm willing to work up some documentation and examples for it.",166291@…
7723,prune include directives,spirit,Boost 1.52.0,To Be Determined,Support Requests,Joel de Guzman,new,2012-11-22T12:04:58Z,2012-11-26T11:34:17Z,"I was trying to figure out what was still including boost/foreach.hpp after removing every include of it in my own code, so I used the /showIncludes MSVC compiler option and it turns out it is some ""deep"" Spirit header finally included 
by boost/spirit/home/karma/generate.hpp. It also showed that boost/spirit/home/karma/generate.hpp includes an enormous amount of other headers while I include it only for a simple boost::spirit::karma::generate() (with real_generator) call.
Please do prune/clean up the included headers in Boost.Spirit (and/or provide more fine grained versions of the current ones)...",Domagoj Šarić
7721,[utility] want get() member function to boost::initialized,utility,Boost 1.52.0,To Be Determined,Feature Requests,No-Maintainer,new,2012-11-22T08:45:55Z,2012-11-22T08:45:55Z,"I am using boost::initialized together boost::optional usually. So, I want get() member function to boost::initialized class for unified interface.",Akira Takahashi <faithandbrave@…>
7715,Fractional seconds are parsed as timezone,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-11-20T08:25:52Z,2012-11-20T08:25:52Z,"We're trying to use Boost's excellent date time functionality, but we've hit a snag. The formatting we require is ""%Y-%m-%dT%H:%M:%S.%F%ZP"", which results in for example ""2012-11-19T23:44:23.122344UTC+1"". We use this to store dates and time in our database as a string.

The problem seems to be that the %F and %ZP flags don't work well together. The following code generates an exception:

{{{
std::string serialized = ""2012-11-19T23:44:23.122344UTC+1"";
std::stringstream ss(serialized);

std::string format = ""%Y-%m-%dT%H:%M:%S.%F%ZP"";

boost::local_time::local_time_facet* facet_output = new boost::local_time::local_time_facet();
facet_output->format(format.c_str());
ss.imbue(std::locale(std::locale::classic(), facet_output));

boost::local_time::local_time_input_facet* facet_input = new boost::local_time::local_time_input_facet();
facet_input->format(format.c_str());
ss.imbue(std::locale(ss.getloc(), facet_input));

boost::local_time::local_date_time result(boost::local_time::not_a_date_time);

ss >> result; // exception
}}}

What happens when you trace the stack to the exception is that the tokenizer doesn't see the ""122344"" bit as fractional seconds and instead thinks it's the timezone. This results in an invalid timezone and thus an exception.

We can circumvent the problem by removing the %F flag, but that is an unacceptable workaround, because we need the precision of the fractional seconds. Removing the %F flag solves the problem.

The problem was found in 1.48.0, but has not yet been fixed in 1.52.0.",knight666@…
7709,Exception library always built as static library.,exception,Boost 1.51.0,To Be Determined,Bugs,Emil Dotchevski,new,2012-11-18T11:46:58Z,2013-01-03T16:40:28Z,"Flag link=shared does not influence on building type of exception library.
The exception library always built as static library.
",asoudarikov@…
7700,remove_if with Placeholder Expression as predicate causes instantiation of PlaceHolder Expression before argument binding in GCC 4.7.2,fusion,Boost 1.52.0,To Be Determined,Bugs,Kohei Takahashi,new,2012-11-15T15:48:10Z,2018-07-06T16:46:38Z,"
The following code instantiates meta_func<mpl::arg<1> >, which causes a compile error.

The problem seems to be with the mpl::not_ which involves the predicate with remove_if. The same error doesn't happen with filter_if. The equivalent code in MPL-only doesn't cause the same error (mpl::remove_if).

#include <boost/fusion/include/as_vector.hpp>
#include <boost/fusion/include/remove_if.hpp>

namespace mpl = boost::mpl;
namespace fusion = boost::fusion;

struct element
{
   typedef mpl::false_ type;
};

template <typename T>
struct meta_func
{
   typedef typename T::type type;
};

int main()
{
   fusion::vector<element, element> e;
   fusion::as_vector(fusion::remove_if<meta_func<mpl::_1> >(e));
}
",felipe.m.almeida@…
7698,Boost directory iterator constructor crashes when folder gives input/output error,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2012-11-15T13:34:43Z,2018-01-23T14:21:59Z,"By using the directory iterator on a non accessible forlder under Linux, the following crash happens:

#0  0x0000003064a329a5 in raise () from /lib64/libc.so.6
#1  0x0000003064a34185 in abort () from /lib64/libc.so.6
#2  0x0000003064a2b935 in __assert_fail () from /lib64/libc.so.6
#3  0x000000000043a7b5 in boost::shared_ptr<boost::filesystem3::detail::dir_itr_imp>::operator-> (this=0x7fffd216cf30)
    at /usr/include/boost/smart_ptr/shared_ptr.hpp:414
#4  0x00000000005e89f2 in boost::filesystem3::detail::directory_iterator_increment (it=..., ec=0x0) at libs/filesystem/v3/src/operations.cpp:1947
#5  0x00000000004363af in boost::filesystem3::directory_iterator::increment (this=0x7fffd216cf30) at /usr/include/boost/filesystem/v3/operations.hpp:630
#6  0x00000000005e8810 in boost::filesystem3::detail::directory_iterator_construct (it=..., p=..., ec=0x7fffd216cf40)
    at libs/filesystem/v3/src/operations.cpp:1918
#7  0x000000000054a120 in boost::filesystem3::directory_iterator::directory_iterator (this=0x7fffd216cf30, p=..., ec=...)
    at /usr/include/boost/filesystem/v3/operations.hpp:598


A sample code that generates the crash is the following:

boost::system::error_code ec;
boost::filesystem3::directory_iterator itr(dir_path, ec);

Where the dir_path is a folder that is not accessible. Using the ls command from terminal on the same folder returns:

input/output error

If the error returned is permission denied, everything works fine. I triggered the input/output error using the curlftpfs library which mounts a ftp as a folder on the system. The permission denied error can be generated on the same folder using nfs share.",cpl
7692,Missing documentation for variables_map::count,program_options,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2012-11-14T13:55:25Z,2012-11-14T13:55:25Z,Neither `variables_map` documentation nor `abstract_variables_map` documentation mentions function `count`.,abadura@…
7687,[date_time] implicit conversion loses integer precision,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-11-13T07:53:12Z,2015-12-01T09:11:50Z,"Compiling with Apple/clang-421.11.66, including boost/date_time.hpp, gives multiple warnings about implicite long64 to int32 conversions:

main.cpp:9
{{{
#include <boost/date_time.hpp>
}}}

{{{
clang -x c++ -stdlib=libstdc++ -Iboost_1_52_0 -Wshorten-64-to-32 -c main.cpp
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:24:
In file included from boost_1_52_0/boost/date_time/posix_time/time_formatters.hpp:16:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_types.hpp:16:
boost_1_52_0/boost/date_time/posix_time/posix_time_duration.hpp:24:21: warning: implicit conversion loses integer precision: 'long' to 'hour_type'
      (aka 'int') [-Wshorten-64-to-32]
      time_duration(h,0,0)
      ~~~~~~~~~~~~~ ^
boost_1_52_0/boost/date_time/posix_time/posix_time_duration.hpp:35:23: warning: implicit conversion loses integer precision: 'long' to 'min_type' (aka 'int')
      [-Wshorten-64-to-32]
      time_duration(0,m,0)
      ~~~~~~~~~~~~~   ^
boost_1_52_0/boost/date_time/posix_time/posix_time_duration.hpp:46:25: warning: implicit conversion loses integer precision: 'long' to 'sec_type' (aka 'int')
      [-Wshorten-64-to-32]
      time_duration(0,0,s)
      ~~~~~~~~~~~~~     ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18:
In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:19:
In file included from boost_1_52_0/boost/date_time/gregorian/greg_calendar.hpp:15:
In file included from boost_1_52_0/boost/date_time/gregorian_calendar.hpp:63:
boost_1_52_0/boost/date_time/gregorian_calendar.ipp:82:12: warning: implicit conversion loses integer precision: 'unsigned long' to 'date_int_type'
      (aka 'unsigned int') [-Wshorten-64-to-32]
    return d;
    ~~~~~~ ^
boost_1_52_0/boost/date_time/date.hpp:71:25: note: in instantiation of member function
      'boost::date_time::gregorian_calendar_base<boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month, boost::gregorian::greg_day>,
      unsigned int>::day_number' requested here
      : days_(calendar::day_number(ymd_type(y, m, d)))
                        ^
boost_1_52_0/boost/date_time/gregorian/greg_date.hpp:56:9: note: in instantiation of member function 'boost::date_time::date<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::date' requested here
      : date_time::date<date, gregorian_calendar, date_duration>(y, m, d)
        ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18:
In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:19:
In file included from boost_1_52_0/boost/date_time/gregorian/greg_calendar.hpp:15:
In file included from boost_1_52_0/boost/date_time/gregorian_calendar.hpp:63:
boost_1_52_0/boost/date_time/gregorian_calendar.ipp:47:14: warning: implicit conversion loses integer precision: 'unsigned long' to 'int'
      [-Wshorten-64-to-32]
      return week;
      ~~~~~~ ^~~~
boost_1_52_0/boost/date_time/gregorian/greg_date.hpp:111:34: note: in instantiation of member function
      'boost::date_time::gregorian_calendar_base<boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month, boost::gregorian::greg_day>,
      unsigned int>::week_number' requested here
      return gregorian_calendar::week_number(ymd);
                                 ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18:
In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:19:
In file included from boost_1_52_0/boost/date_time/gregorian/greg_calendar.hpp:15:
In file included from boost_1_52_0/boost/date_time/gregorian_calendar.hpp:63:
boost_1_52_0/boost/date_time/gregorian_calendar.ipp:52:16: warning: implicit conversion loses integer precision: 'unsigned long' to 'int'
      [-Wshorten-64-to-32]
        return week; //under these circumstances week == 53.
        ~~~~~~ ^~~~
boost_1_52_0/boost/date_time/gregorian_calendar.ipp:63:14: warning: implicit conversion loses integer precision: 'unsigned long' to 'int'
      [-Wshorten-64-to-32]
      return week;
      ~~~~~~ ^~~~
boost_1_52_0/boost/date_time/gregorian_calendar.ipp:66:12: warning: implicit conversion loses integer precision: 'unsigned long' to 'int'
      [-Wshorten-64-to-32]
    return week;  //not reachable -- well except if day == 5 and is_leap_year != true
    ~~~~~~ ^~~~
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:15:
boost_1_52_0/boost/date_time/time_system_counted.hpp:57:52: warning: implicit conversion loses integer precision: 'unsigned long' to
      'typename calendar_type::date_int_type' (aka 'unsigned int') [-Wshorten-64-to-32]
        typename calendar_type::date_int_type dc = day_count();
                                              ~~   ^~~~~~~~~~~
boost_1_52_0/boost/date_time/time_system_counted.hpp:170:18: note: in instantiation of member function
      'boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config>::date' requested here
      return val.date();
                 ^
boost_1_52_0/boost/date_time/time.hpp:72:27: note: in instantiation of member function
      'boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config> >::get_date' requested here
      return time_system::get_date(time_);
                          ^
boost_1_52_0/boost/date_time/posix_time/date_duration_operators.hpp:33:31: note: in instantiation of member function
      'boost::date_time::base_time<boost::posix_time::ptime,
      boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config>> >::date' requested here
    return t + m.get_offset(t.date());
                              ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18:
In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:17:
boost_1_52_0/boost/date_time/date.hpp:180:47: warning: implicit conversion loses integer precision: 'duration_rep_type' (aka 'long') to 'int_type'
      (aka 'unsigned int') [-Wshorten-64-to-32]
      return date_type(date_rep_type(days_) + dd.days());
                       ~~~~~~~~~~~~~          ^~~~~~~~~
boost_1_52_0/boost/date_time/time.hpp:145:49: note: in instantiation of member function 'boost::date_time::date<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::operator+' requested here
      time_ = (time_system::get_time_rep(date() + dd, time_of_day()));
                                                ^
boost_1_52_0/boost/date_time/posix_time/date_duration_operators.hpp:44:14: note: in instantiation of member function
      'boost::date_time::base_time<boost::posix_time::ptime,
      boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config>> >::operator+=' requested here
    return t += m.get_offset(t.date());
             ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:17:
In file included from boost_1_52_0/boost/date_time/time_resolution_traits.hpp:15:
boost_1_52_0/boost/date_time/int_adapter.hpp:233:41: warning: implicit conversion loses integer precision: 'long' to 'int_type' (aka 'unsigned int')
      [-Wshorten-64-to-32]
    return int_adapter<int_type>(value_ + rhs.as_number());
           ~~~~~~~~~~~           ~~~~~~~^~~~~~~~~~~~~~~~~
boost_1_52_0/boost/date_time/date.hpp:178:47: note: in instantiation of function template specialization 'boost::date_time::int_adapter<unsigned
      int>::operator+<long>' requested here
        return date_type(date_rep_type(days_) + dd.get_rep());
                                              ^
boost_1_52_0/boost/date_time/time.hpp:145:49: note: in instantiation of member function 'boost::date_time::date<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::operator+' requested here
      time_ = (time_system::get_time_rep(date() + dd, time_of_day()));
                                                ^
boost_1_52_0/boost/date_time/posix_time/date_duration_operators.hpp:44:14: note: in instantiation of member function
      'boost::date_time::base_time<boost::posix_time::ptime,
      boost::date_time::counted_time_system<boost::date_time::counted_time_rep<boost::posix_time::millisec_posix_time_system_config>> >::operator+=' requested here
    return t += m.get_offset(t.date());
             ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:18:
In file included from boost_1_52_0/boost/date_time/gregorian/gregorian_types.hpp:17:
boost_1_52_0/boost/date_time/date.hpp:162:47: warning: implicit conversion loses integer precision: 'duration_rep_type' (aka 'long') to 'int_type'
      (aka 'unsigned int') [-Wshorten-64-to-32]
      return date_type(date_rep_type(days_) - dd.days());
                       ~~~~~~~~~~~~~          ^~~~~~~~~
boost_1_52_0/boost/date_time/period.hpp:93:21: note: in instantiation of member function 'boost::date_time::date<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::operator-' requested here
    last_(end_point - duration_rep::unit())
                    ^
boost_1_52_0/boost/date_time/date_parsing.hpp:308:14: note: in instantiation of member function 'boost::date_time::period<boost::gregorian::date,
      boost::gregorian::date_duration>::period' requested here
      return period<date_type, typename date_type::duration_type>(d1, d2);
             ^
boost_1_52_0/boost/date_time/gregorian/parsers.hpp:79:12: note: in instantiation of function template specialization
      'boost::date_time::from_simple_string_type<boost::gregorian::date, char>' requested here
    return date_time::from_simple_string_type<date,char>(s);
           ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/posix_time/ptime.hpp:12:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_system.hpp:13:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_config.hpp:17:
In file included from boost_1_52_0/boost/date_time/time_resolution_traits.hpp:15:
boost_1_52_0/boost/date_time/int_adapter.hpp:282:41: warning: implicit conversion loses integer precision: 'long' to 'int_type' (aka 'unsigned int')
      [-Wshorten-64-to-32]
    return int_adapter<int_type>(value_ - rhs.as_number());
           ~~~~~~~~~~~           ~~~~~~~^~~~~~~~~~~~~~~~~
boost_1_52_0/boost/date_time/date.hpp:160:47: note: in instantiation of function template specialization 'boost::date_time::int_adapter<unsigned
      int>::operator-<long>' requested here
        return date_type(date_rep_type(days_) - dd.get_rep());
                                              ^
boost_1_52_0/boost/date_time/period.hpp:93:21: note: in instantiation of member function 'boost::date_time::date<boost::gregorian::date,
      boost::gregorian::gregorian_calendar, boost::gregorian::date_duration>::operator-' requested here
    last_(end_point - duration_rep::unit())
                    ^
boost_1_52_0/boost/date_time/date_parsing.hpp:308:14: note: in instantiation of member function 'boost::date_time::period<boost::gregorian::date,
      boost::gregorian::date_duration>::period' requested here
      return period<date_type, typename date_type::duration_type>(d1, d2);
             ^
boost_1_52_0/boost/date_time/gregorian/parsers.hpp:79:12: note: in instantiation of function template specialization
      'boost::date_time::from_simple_string_type<boost::gregorian::date, char>' requested here
    return date_time::from_simple_string_type<date,char>(s);
           ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:24:
In file included from boost_1_52_0/boost/date_time/posix_time/time_formatters.hpp:16:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_types.hpp:20:
boost_1_52_0/boost/date_time/dst_rules.hpp:57:49: warning: implicit conversion loses integer precision: 'long' to 'min_type' (aka 'int') [-Wshorten-64-to-32]
        if (time_of_day >= time_duration_type(0,offset,0)) {
                           ~~~~~~~~~~~~~~~~~~   ^~~~~~
boost_1_52_0/boost/date_time/dst_rules.hpp:164:18: note: in instantiation of member function 'boost::date_time::dst_calculator<boost::gregorian::date,
      boost::posix_time::time_duration>::process_local_dst_start_day' requested here
          return process_local_dst_start_day(time_of_day,
                 ^
boost_1_52_0/boost/date_time/dst_rules.hpp:116:16: note: in instantiation of member function 'boost::date_time::dst_calculator<boost::gregorian::date,
      boost::posix_time::time_duration>::local_is_dst' requested here
        return local_is_dst(current_day, time_of_day,
               ^
boost_1_52_0/boost/date_time/local_time/local_date_time.hpp:196:16: note: in instantiation of member function
      'boost::date_time::dst_calculator<boost::gregorian::date, boost::posix_time::time_duration>::local_is_dst' requested here
        return dst_calculator::local_is_dst(
               ^
boost_1_52_0/boost/date_time/local_time/local_date_time.hpp:241:16: note: in instantiation of member function
      'boost::local_time::local_date_time_base<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::check_dst' requested here
        switch(check_dst(lt.date(), lt.time_of_day(), zone_)){
               ^
boost_1_52_0/boost/date_time/local_time/conversion.hpp:23:9: note: in instantiation of member function
      'boost::local_time::local_date_time_base<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::is_dst' requested here
  if(lt.is_dst()){
        ^
In file included from main.cpp:9:
In file included from boost_1_52_0/boost/date_time.hpp:15:
In file included from boost_1_52_0/boost/date_time/local_time/local_time.hpp:11:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time.hpp:24:
In file included from boost_1_52_0/boost/date_time/posix_time/time_formatters.hpp:16:
In file included from boost_1_52_0/boost/date_time/posix_time/posix_time_types.hpp:20:
boost_1_52_0/boost/date_time/dst_rules.hpp:78:44: warning: implicit conversion loses integer precision: 'long' to 'int' [-Wshorten-64-to-32]
        int offset = dst_end_offset_minutes-dst_length_minutes;
            ~~~~~~   ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
boost_1_52_0/boost/date_time/dst_rules.hpp:170:18: note: in instantiation of member function 'boost::date_time::dst_calculator<boost::gregorian::date,
      boost::posix_time::time_duration>::process_local_dst_end_day' requested here
          return process_local_dst_end_day(time_of_day,
                 ^
boost_1_52_0/boost/date_time/dst_rules.hpp:116:16: note: in instantiation of member function 'boost::date_time::dst_calculator<boost::gregorian::date,
      boost::posix_time::time_duration>::local_is_dst' requested here
        return local_is_dst(current_day, time_of_day,
               ^
boost_1_52_0/boost/date_time/local_time/local_date_time.hpp:196:16: note: in instantiation of member function
      'boost::date_time::dst_calculator<boost::gregorian::date, boost::posix_time::time_duration>::local_is_dst' requested here
        return dst_calculator::local_is_dst(
               ^
boost_1_52_0/boost/date_time/local_time/local_date_time.hpp:241:16: note: in instantiation of member function
      'boost::local_time::local_date_time_base<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::check_dst' requested here
        switch(check_dst(lt.date(), lt.time_of_day(), zone_)){
               ^
boost_1_52_0/boost/date_time/local_time/conversion.hpp:23:9: note: in instantiation of member function
      'boost::local_time::local_date_time_base<boost::posix_time::ptime, boost::date_time::time_zone_base<boost::posix_time::ptime, char> >::is_dst' requested here
  if(lt.is_dst()){
        ^
15 warnings generated.
}}}


",crueegg@…
7682,boost 1.52 named_mutex/named_condition pairing broken,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2012-11-13T00:00:48Z,2015-12-23T23:35:03Z,"The following program works in boost 1.47, however in 1.52 it does not.  To test it, run 2 instances.  The 2nd instance should output the numbers 1, 3, 5, 7, 9.

Under 1.52, the program outputs the number 1, and then does nothing. The fault appears to be with the named_condition and named_mutex classes.

Tested under Windows 7 Pro, SP1, using Visual Studio 2010 v10.0.40219.1 SP1Rel.  The test was done with a statically linked boost date time, with Platform Toolset set to v90, i.e. linked with the library 'libboost_date_time-vc90-mt-sgd-1_47.lib'.

{{{
#include <boost/interprocess/managed_shared_memory.hpp> 
#include <boost/interprocess/sync/named_mutex.hpp> 
#include <boost/interprocess/sync/named_condition.hpp> 
#include <boost/interprocess/sync/scoped_lock.hpp> 
#include <iostream> 

int main() 
{ 
  boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::open_or_create, ""shm"", 1024); 
  int *i = managed_shm.find_or_construct<int>(""Integer"")(0); 
  boost::interprocess::named_mutex named_mtx(boost::interprocess::open_or_create, ""mtx""); 
  boost::interprocess::named_condition named_cnd(boost::interprocess::open_or_create, ""cnd""); 
  boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(named_mtx); 
  while (*i < 10) 
  { 
    if (*i % 2 == 0) 
    { 
      ++(*i); 
      named_cnd.notify_all(); 
      named_cnd.wait(lock); 
    } 
    else 
    { 
      std::cout << *i << std::endl; 
      ++(*i); 
      named_cnd.notify_all(); 
      named_cnd.wait(lock); 
    } 
  } 
  named_cnd.notify_all(); 
  boost::interprocess::shared_memory_object::remove(""shm""); 
  boost::interprocess::named_mutex::remove(""mtx""); 
  boost::interprocess::named_condition::remove(""cnd""); 
}

}}}",damian.coventry@…
7681,Bug in indirect_streambuf::seek_impl,iostreams,Boost 1.52.0,Boost 1.53.0,Bugs,Jonathan Turkanis,new,2012-11-12T12:10:29Z,2012-11-12T12:10:29Z,"Currently indirect_streambuf::seek_impl always modifies input and output pointers with code:

setg(0, 0, 0);
setp(0, 0);

See detail/indirect_streambuf.hpp. However, this is incorrect for dual seekable streams buffers which only modifies one set of pointers on each seek (in or out). As a consequence, dual seekable devices cannot be correctly seek.
Those 2 lines should be replaced by:

if (is_convertible<category, dual_seekable>::value) {
    if (which == BOOST_IOS::in) {
        setg(0, 0, 0);
    }
    if (which == BOOST_IOS::out) {
        setp(0, 0);
    }
}
else {
    setg(0, 0, 0);
    setp(0, 0);
}
",lodos@…
7680,Poor choice of difference_type for zip_iterator,iterator,Boost 1.52.0,To Be Determined,Bugs,jeffrey.hellrung,new,2012-11-11T04:37:06Z,2012-11-21T22:41:14Z,"Hi,

the following program results in an integer overflow on my system (Linux g++ 4.7.2):
{{{#!c++
#include <boost/iterator/zip_iterator.hpp>
#include <boost/iterator/counting_iterator.hpp>
#include <boost/tuple/tuple.hpp>
#include <iostream>
int main() {
  boost::counting_iterator<unsigned short> i1(0);
  boost::counting_iterator<unsigned long long> i2(0);
  auto i3 = boost::make_zip_iterator(boost::make_tuple(i1, i2));
  i3 += 3221225472u;
  std::cout << boost::get<1>(*i3) << '\n';
}
}}}
It prints 18446744072635809792, but I'd expect it to print 3221225472. boost::zip_iterator seems to use the first underlying iterator's difference_type as its own difference_type, which isn't necessarily the right choice. ",matthias_berndt@…
7679,unhex level 4 compile warning in visual studio,algorithm,Boost 1.52.0,To Be Determined,Bugs,Marshall Clow,new,2012-11-10T15:56:10Z,2016-04-07T13:36:30Z,"
The following code generates a level 4 compiler warning in Visual Studio 2010 and 2012:

{{{
#include <string>
#include <boost/algorithm/hex.hpp>

int main()
{
    std::string base = ""now is the time"";
    std::string hstr = boost::algorithm::hex(base);
    std::string cstr = boost::algorithm::unhex(hstr);
}
}}}

The warnings are:
{{{
1>d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(137): warning C4244: '=' : conversion from 'unsigned int' to 'T', possible loss of data

1>          d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(204) : see reference to function template instantiation 'std::back_insert_iterator<_Container> boost::algorithm::detail::decode_one<InputIterator,OutputIterator,bool(__cdecl *)(Iterator,Iterator)>(InputIterator &,InputIterator,OutputIterator,EndPred)' being compiled
1>          with
1>          [
1>              _Container=std::string,
1>              InputIterator=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>,
1>              OutputIterator=std::back_insert_iterator<std::string>,
1>              Iterator=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>,
1>              EndPred=bool (__cdecl *)(std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>,std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>)
1>          ]
1>          d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(237) : see reference to function template instantiation 'OutputIterator boost::algorithm::unhex<std::_String_const_iterator<_Elem,_Traits,_Alloc>,OutputIterator>(InputIterator,InputIterator,OutputIterator)' being compiled
1>          with
1>          [
1>              OutputIterator=std::back_insert_iterator<std::string>,
1>              _Elem=char,
1>              _Traits=std::char_traits<char>,
1>              _Alloc=std::allocator<char>,
1>              InputIterator=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>
1>          ]
1>          d:\development\libs\boost_1_52_0\boost/algorithm/hex.hpp(263) : see reference to function template instantiation 'OutputIterator boost::algorithm::unhex<String,std::back_insert_iterator<_Container>>(const Range &,OutputIterator)' being compiled
1>          with
1>          [
1>              OutputIterator=std::back_insert_iterator<std::string>,
1>              String=std::string,
1>              _Container=std::string,
1>              Range=std::string
1>          ]
1>          unhex_bug.cpp(10) : see reference to function template instantiation 'String boost::algorithm::unhex<std::string>(const String &)' being compiled
1>          with
1>          [
1>              String=std::string
1>          ]
}}}

",Gary Sanders <lex21@…>
7670,Failed to compile boost 1.48.0 using Xcode 4.5.2,build,Boost 1.48.0,To Be Determined,Bugs,Vladimir Prus,new,2012-11-09T11:49:05Z,2013-10-12T13:20:21Z,"I was trying to build boost 1.48.0 using xcode 4.5.2(LLVM 4.1) on Mac OS X 10.7.5 but got some compilation issues, I was building boost with c++11 and libc++ support

Command:
./bjam toolset=clang debug-symbols=on cxxflags=""-std=c++11 -stdlib=libc++ -arch x86_64 -fvisibility=hidden"" linkflags=""-stdlib=libc++ -arch x86_64"" variant=debug link=static,shared threading=multi --layout=versioned --build-dir=./universal --stagedir=./boost_stage_universal/debug stage --with-filesystem

Build Log:

Component configuration:

    - chrono                   : not building
    - date_time                : not building
    - exception                : not building
    - filesystem               : building
    - graph                    : not building
    - graph_parallel           : not building
    - iostreams                : not building
    - locale                   : not building
    - math                     : not building
    - mpi                      : not building
    - program_options          : not building
    - python                   : not building
    - random                   : not building
    - regex                    : not building
    - serialization            : not building
    - signals                  : not building
    - system                   : not building
    - test                     : not building
    - thread                   : not building
    - timer                    : not building
    - wave                     : not building

...patience...
...found 524 targets...
...updating 34 targets...
clang-darwin.compile.c++ universal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi/error_code.o
In file included from libs/system/src/error_code.cpp:18:
In file included from ./boost/system/config.hpp:13:
In file included from ./boost/config.hpp:40:
In file included from ./boost/config/select_stdlib_config.hpp:37:
In file included from ./boost/config/no_tr1/utility.hpp:21:
In file included from /usr/bin/../lib/c++/v1/utility:125:
In file included from /usr/bin/../lib/c++/v1/__tuple:16:
/usr/bin/../lib/c++/v1/type_traits:737:2: error: #error is_base_of not implemented.
#error is_base_of not implemented.
 ^
/usr/bin/../lib/c++/v1/type_traits:1700:13: error: use of undeclared identifier 'is_base_of'
            is_base_of<_Class, typename remove_reference<_Tp>::type>::value>
            ^
/usr/bin/../lib/c++/v1/type_traits:1700:24: error: '_Class' does not refer to a value
            is_base_of<_Class, typename remove_reference<_Tp>::type>::value>
                       ^
/usr/bin/../lib/c++/v1/type_traits:1697:28: note: declared here
template <class _Rp, class _Class, class _Tp>
                           ^
/usr/bin/../lib/c++/v1/type_traits:1700:62: error: expected class name
            is_base_of<_Class, typename remove_reference<_Tp>::type>::value>
                                                             ^
In file included from libs/system/src/error_code.cpp:19:
In file included from ./boost/system/error_code.hpp:16:
In file included from ./boost/assert.hpp:82:
In file included from /usr/bin/../lib/c++/v1/iostream:38:
In file included from /usr/bin/../lib/c++/v1/ios:216:
In file included from /usr/bin/../lib/c++/v1/__locale:15:
In file included from /usr/bin/../lib/c++/v1/string:434:
In file included from /usr/bin/../lib/c++/v1/algorithm:594:
In file included from /usr/bin/../lib/c++/v1/memory:590:
In file included from /usr/bin/../lib/c++/v1/typeinfo:61:
/usr/bin/../lib/c++/v1/exception:194:20: error: use of undeclared identifier 'is_base_of'
                  !is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                   ^
/usr/bin/../lib/c++/v1/exception:194:31: error: 'nested_exception' does not refer to a value
                  !is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                              ^
/usr/bin/../lib/c++/v1/exception:166:29: note: declared here
class _LIBCPP_EXCEPTION_ABI nested_exception
                            ^
/usr/bin/../lib/c++/v1/exception:194:81: error: parameter declarator cannot be qualified
                  !is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                                                                              ~~^
/usr/bin/../lib/c++/v1/exception:194:85: error: expected ')'
                  !is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                                                                                    ^
/usr/bin/../lib/c++/v1/exception:192:18: note: to match this '('
throw_with_nested(_Tp&& __t, typename enable_if<
                 ^
/usr/bin/../lib/c++/v1/exception:213:19: error: use of undeclared identifier 'is_base_of'
                  is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                  ^
/usr/bin/../lib/c++/v1/exception:213:30: error: 'nested_exception' does not refer to a value
                  is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                             ^
/usr/bin/../lib/c++/v1/exception:166:29: note: declared here
class _LIBCPP_EXCEPTION_ABI nested_exception
                            ^
/usr/bin/../lib/c++/v1/exception:213:80: error: parameter declarator cannot be qualified
                  is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                                                                             ~~^
/usr/bin/../lib/c++/v1/exception:213:84: error: expected ')'
                  is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                                                                                   ^
/usr/bin/../lib/c++/v1/exception:211:18: note: to match this '('
throw_with_nested(_Tp&& __t, typename enable_if<
                 ^
In file included from libs/system/src/error_code.cpp:19:
In file included from ./boost/system/error_code.hpp:16:
In file included from ./boost/assert.hpp:82:
In file included from /usr/bin/../lib/c++/v1/iostream:38:
In file included from /usr/bin/../lib/c++/v1/ios:216:
In file included from /usr/bin/../lib/c++/v1/__locale:18:
In file included from /usr/bin/../lib/c++/v1/mutex:176:
In file included from /usr/bin/../lib/c++/v1/__mutex_base:16:
/usr/bin/../lib/c++/v1/system_error:247:1: error: C++ requires a type specifier for all declarations
_LIBCPP_DECLARE_STRONG_ENUM(errc)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/c++/v1/system_error:247:29: error: use of undeclared identifier 'errc'
_LIBCPP_DECLARE_STRONG_ENUM(errc)
                            ^
/usr/bin/../lib/c++/v1/system_error:247:34: error: expected ';' after top level declarator
_LIBCPP_DECLARE_STRONG_ENUM(errc)
                                 ^
                                 ;
/usr/bin/../lib/c++/v1/system_error:344:1: error: C++ requires a type specifier for all declarations
_LIBCPP_DECLARE_STRONG_ENUM_EPILOG(errc)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/c++/v1/system_error:344:36: error: use of undeclared identifier 'errc'
_LIBCPP_DECLARE_STRONG_ENUM_EPILOG(errc)
                                   ^
/usr/bin/../lib/c++/v1/system_error:344:41: error: expected ';' after top level declarator
_LIBCPP_DECLARE_STRONG_ENUM_EPILOG(errc)
                                        ^
                                        ;
/usr/bin/../lib/c++/v1/system_error:457:1: error: 'inline' can only appear on functions
inline _LIBCPP_INLINE_VISIBILITY
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

    ""clang++"" -x c++ -O0 -g -std=c++11 -stdlib=libc++ -arch x86_64 -fvisibility=hidden -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -I""."" -c -o ""universal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi/error_code.o"" ""libs/system/src/error_code.cpp""

...failed clang-darwin.compile.c++ universal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi/error_code.o...
...skipped <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>libboost_system-clang-darwin42-mt-d-1_48.a(clean) for lack of <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>error_code.o...
...skipped <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>libboost_system-clang-darwin42-mt-d-1_48.a for lack of <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>error_code.o...
...skipped <pboost_stage_universal/debug/lib>libboost_system-clang-darwin42-mt-d-1_48.a for lack of <puniversal/boost/bin.v2/libs/system/build/clang-darwin-4.2.1/debug/link-static/threading-multi>libboost_system-clang-darwin42-mt-d-1_48.a...
clang-darwin.compile.c++ universal/boost/bin.v2/libs/filesystem/build/clang-darwin-4.2.1/debug/link-static/threading-multi/v2/src/v2_operations.o
In file included from libs/filesystem/v2/src/v2_operations.cpp:45:
In file included from ./boost/filesystem/v2/operations.hpp:17:
In file included from ./boost/filesystem/v2/config.hpp:30:
In file included from ./boost/config.hpp:40:
In file included from ./boost/config/select_stdlib_config.hpp:37:
In file included from ./boost/config/no_tr1/utility.hpp:21:
In file included from /usr/bin/../lib/c++/v1/utility:125:
In file included from /usr/bin/../lib/c++/v1/__tuple:16:
/usr/bin/../lib/c++/v1/type_traits:737:2: error: #error is_base_of not implemented.
#error is_base_of not implemented.
 ^
/usr/bin/../lib/c++/v1/type_traits:1700:13: error: use of undeclared identifier 'is_base_of'
            is_base_of<_Class, typename remove_reference<_Tp>::type>::value>
            ^
/usr/bin/../lib/c++/v1/type_traits:1700:24: error: '_Class' does not refer to a value
            is_base_of<_Class, typename remove_reference<_Tp>::type>::value>
                       ^
/usr/bin/../lib/c++/v1/type_traits:1697:28: note: declared here
template <class _Rp, class _Class, class _Tp>
                           ^
/usr/bin/../lib/c++/v1/type_traits:1700:62: error: expected class name
            is_base_of<_Class, typename remove_reference<_Tp>::type>::value>
                                                             ^
In file included from libs/filesystem/v2/src/v2_operations.cpp:45:
In file included from ./boost/filesystem/v2/operations.hpp:18:
In file included from ./boost/filesystem/v2/path.hpp:21:
In file included from ./boost/system/system_error.hpp:11:
In file included from /usr/bin/../lib/c++/v1/string:434:
In file included from /usr/bin/../lib/c++/v1/algorithm:594:
In file included from /usr/bin/../lib/c++/v1/memory:590:
In file included from /usr/bin/../lib/c++/v1/typeinfo:61:
/usr/bin/../lib/c++/v1/exception:194:20: error: use of undeclared identifier 'is_base_of'
                  !is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                   ^
/usr/bin/../lib/c++/v1/exception:194:31: error: 'nested_exception' does not refer to a value
                  !is_base_of<nested_exception, typename remove_reference<_Tp>::type>::value
                 


",amol_ghatge@…
7658,Ambiguity error with function overloads,function,Boost 1.51.0,To Be Determined,Bugs,Douglas Gregor,new,2012-11-07T16:11:48Z,2012-11-07T16:11:48Z,"The following code (relevant for a convenient thread-callback API) fails to compile with VC2010 due to a C2668 error:


{{{
typedef boost::function<void (int i)> fooCallback;
typedef boost::function<void (int i, int k)> barCallback;

void TestBF(fooCallback fc) {}
void TestBF(barCallback bc) {}
void MyFunc (int a, int b) {}

int main(int argc, char **argv) {

    TestBF (&MyFunc);
    return 0;
}
}}}



Without calling TestBF in main, everything is fine, there is no multiple definition error.
A (most likely) related discussion thread can be found here: [http://boost.2283326.n4.nabble.com/Boost-Function-detecting-ignored-arguments-td4631919.html].
",Ulrich Brandstätter <ulien@…>
7655,signed/unsigned mismatch warning in inplace_solver,uBLAS,Boost 1.52.0,To Be Determined,Bugs,Gunter,new,2012-11-07T13:51:01Z,2014-10-06T14:08:24Z,"MSVC 9 emits a warning ""C4018: '<' : signed/unsigned mismatch"" in line 2165 (inplace_solve) in triangular.hpp",Tobias Loew
7652,compile-time checked access,array,Boost 1.52.0,Boost 1.54.0,Feature Requests,Marshall Clow,assigned,2012-11-06T06:56:56Z,2013-02-12T18:11:23Z,"Since code like

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

compiles correctly on some compilers (even without warnings). I suggest adding compile checked functions for static access to arrays like:
        template<size_type i>
        reference at() 
        { 
            BOOST_STATIC_ASSERT( (i < N) );
            return elems[i]; 
        }

        template<size_type i>
        const_reference at() const
        { 
            BOOST_STATIC_ASSERT( (i < N) );
            return elems[i]; 
        }


then code like:

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

would result in the expected errors.",Tobias Loew
7647,b2 incompatible with _STLP_LIB_NAME_MOTIF in stlport (no library names flexibility) - fatal error LNK1181: cannot open input file 'stlportstld.5.2.lib,build,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2012-11-06T03:37:10Z,2013-01-03T16:42:25Z,"B2 seems too rigid with the searched libraries names used for stlport.
It causes problems for someone who needs to use names a suffix _STLP_LIB_NAME_MOTIF that is not empty (see stlport/stl/config/user-config.h).


Here I explain the context the context.
I've tried (succcessfully) to build boost_1_52 with stlport.5.2.1 with Microsoft vs 2010 (vc10)

I've essentially used what suggested in
http://www.lenholgate.com/blog/2010/07/stlport-521-and-vs2010-and-x64.html.
[[BR]]
The author of the pages uses _STLP_LIB_NAME_MOTIF in order to specify the compiler's name in the library name, which is what I need too.


To build with stlport I've followed the usual procedure:

1- added in tools/build/v2/user-config.jam the lines[[BR]]
  using msvc : 10.0 ;
  using stlport : 5.2.1 : <my_path_to_stlport>/STLport-5.2.1/stlport : <my_path_to_stlport>/STLport-5.2.1/lib/vc10 ;

2- and issued the command:[[BR]]
.\tools\build\v2\b2.exe stdlib=stlport-5.2.1 toolset=msvc-10.0 debug/define=_STLP_DEBUG release --build-type=complete stage


What I get is a linking error to the stlport libraries when doing
link=shared threading=multi
(for example with --with-system)[[BR]]
the message error is:
LINK : fatal error LNK1181: cannot open input file 'stlportstld.5.2.lib'

This is because stlport.jam ((probably this jam file) '''forces''' the link to the stlport with its own names, therefore '''bypassing''' what is specified in the file STLport-5.2.1\stlport\stl\config\_auto_link.h

I wonder why this choice, considering that life was beautiful years ago when this everything was delegated to stlport\stl\config\_auto_link.h. I imagine you had your own reasons.

[[BR]]
[[BR]]

Things therefore work if I do:[[BR]]


tools/build/v2/user-config.jam:[[BR]]
  using msvc : 10.0 ;
  using stlport : vc10.5.2.1 : <my_path_to_stlport>/STLport-5.2.1/stlport : <my_path_to_stlport>/STLport-5.2.1/lib/vc10 ;
  
and issue the command:[[BR]]
  .\tools\build\v2\b2.exe stdlib=stlport-vc10.5.2.1 toolset=msvc-10.0 debug/define=_STLP_DEBUG release --build-type=complete stage


But still there is one strange behaviour which is problematic.[[BR]]


Let's take tools/build/v2/user-config.jam again[[BR]]

 with[[BR]]
  using stlport : 5.2.1 : ....[[BR]]
  the library searched was stlportstld.5.2.lib
[[BR]]
 with[[BR]]
  using stlport : vc10.5.2.1 : ....[[BR]]
  the library searched was stlportstldvc10.5.2.lib
[[BR]]
 with[[BR]]
  using stlport : xyz.5.2.1 : ....[[BR]]
  the library searched was stlportstldvc10.5.2.lib
  i.e. not stlportstldxyz.5.2.lib
  [[BR]]

And this is a problem, as people may want to build to the stlport libraries also when their name name is modified according to the _STLP_LIB_NAME_MOTIF macro in stlport/stl/config/user-config.h.
  
Hope this will be fixed, if you agree this is a limitation. Again, I wish everything would be left to what is specified in  STLport-5.2.1\stlport\stl\config\_auto_link.h 
  ",Marcello Pietrobon <marcello.pietrobon@…>
7637,Karma allow integrals as type for real_generator,spirit,Boost 1.52.0,To Be Determined,Patches,Joel de Guzman,new,2012-11-04T01:12:04Z,2012-11-04T01:12:04Z,"The attached patch allows Karma `real_generator` to be instantiated with fundamental integral types, which will otherwise result in an error when calling `modf` due to its pointer argument. The remaining requirements (fmod, floor, et.al.) are satisfied by implicit conversion, though they could be specially handled as well.",K-ballo <kaballo86@…>
7636,Detection of ICU fails,locale,Boost 1.52.0,To Be Determined,Bugs,Artyom Beilis,new,2012-11-04T00:37:18Z,2013-10-12T13:20:54Z,"Detection of ICU fails:
{{{
Building the Boost C++ Libraries.


Performing configuration checks

    - 32-bit                   : no
    - 64-bit                   : yes
    - x86                      : yes
    - has_icu builds           : no
    - iconv (libc)             : yes
    - icu                      : no
    - icu (lib64)              : no
    - gcc visibility           : yes
    - long double support      : yes
}}}

Build system should use `'icu-config --cflags'` (for C) and `'icu-config --cxxflags'` (for C++) to get flags required for compilation with ICU.",Arfrever.FTA@…
7633,Wanted: a way to force a nested result_type,phoenix,Boost 1.52.0,To Be Determined,Bugs,Thomas Heller,new,2012-11-02T23:53:36Z,2012-11-02T23:53:36Z,"For example, I had to use this:

{{{#!c++
template <class F> struct void_function : F
{
    typedef void result_type;
    void_function(F x) : F(x) {}
};

template <class F>
void_function<F> make_void(F x)
{
    return void_function<F>(x);
}
}}}

in order to get the following to work:

{{{#!c++
inline std::ostream& operator<<(std::ostream& s, my_variant const& x)
{
    using namespace boost::phoenix::placeholders;
    using namespace boost::phoenix;
    
    boost::apply_visitor( make_void(s << arg1), x );
    //                    ^^^^^^^^^ HERE
    return s;
}
}}}

Some libraries, like Boost.Variant, don't follow the {{{result_of}}} protocol.",Dave Abrahams
7630,Range adaptors do not play nicely with range-based for loops,range,Boost 1.51.0,To Be Determined,Bugs,Neil Groves,assigned,2012-11-02T18:37:22Z,2016-06-02T23:18:04Z,"Consider the following C++11 code, adapted from the Range documentation:


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

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


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


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

The fix is for each range adaptor to use an rvalue-reference overload to detect whether the input range is a temporary, and if so, move it into the adaptor (i.e. with `std::move`) in order to extend its lifetime.
",gromer@…
7629,"Implement the algorithm deadlock detection ""lockdep""",thread,Boost 1.52.0,To Be Determined,Feature Requests,viboes,assigned,2012-11-02T16:24:53Z,2012-11-04T00:28:06Z,"Implement the algorithm deadlock detection ""lockdep"" (http://ceph.com/dev-notes/lockdep-for-pthreads/)",anonymous
7625,"container.hpp should get reference, etc., from the iterator types",phoenix,Boost 1.52.0,To Be Determined,Bugs,Thomas Heller,new,2012-11-02T02:08:27Z,2012-11-02T02:08:27Z,"Because container.hpp reaches into so many of the ""container's"" typedefs, it doesn't work with iterator_range.  For example, try {{{front(arg1)(boost::as_literal(""foo""))}}}",Dave Abrahams
7622,filesystem - minor documentation issues,filesystem,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,new,2012-11-01T20:17:05Z,2012-11-01T20:17:05Z,".../filesystem/doc/reference.html#path-decomposition

shows

path stem(const path& p) const;
path extension(const path& p) const;

I believe they should show

path stem() const;
path extension() const;

as is shown at:

.../filesystem/doc/reference.html#class-path

Robert Ramey",Robert Ramey
7621,Stateful policies support for Qi bool parsers,spirit,Boost 1.52.0,To Be Determined,Patches,Joel de Guzman,new,2012-11-01T19:26:22Z,2012-11-01T19:26:22Z,The attached patch implements the missing pieces needed for Qi bool parsers to support stateful policies.,K-ballo <kaballo86@…>
7617,"msvc 9.0 (64-bit):  warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data",asio,Boost 1.51.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-10-31T12:40:15Z,2012-10-31T12:40:15Z,"Warnings occured when using boost::asio::ssl implementation in 64-bit configuration:

1>C:\builds\boost_1_51_0\boost/asio/ssl/impl/context.ipp(513) : warning C4267: 'return' : conversion from 'size_t' to 'int', possible loss of data

1>C:\builds\boost_1_51_0\boost/asio/ssl/detail/impl/engine.ipp(169) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data

1>C:\builds\boost_1_51_0\boost/asio/ssl/detail/impl/engine.ipp(180) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data

1>C:\builds\boost_1_51_0\boost/asio/ssl/detail/impl/engine.ipp(299) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data

1>C:\builds\boost_1_51_0\boost/asio/ssl/detail/impl/engine.ipp(304) : warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data",anonymous
7614,duplicate dosctring is generated for pure virtual methods,python USE GITHUB,Boost 1.47.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-10-31T07:41:34Z,2012-10-31T07:41:34Z,"When defining a method through ""def"" and using ""pure_virtual"" (see below) the given docstring is duplicated in the result python definition.

C++ class with pure-virtual method:
===================================
class IOperation 
{
public:

    virtual string AsString() = 0;
}

The wrapper to expose it to Python:
===================================
class_<IOperation, boost::noncopyable, boost::shared_ptr<IOperation> >(""IOperation"",
 ""docstring for class"",
 no_init)

 .def(""AsString"",
      pure_virtual(&IOperation::AsString),
      ""docstring for method AsString"")
;

Result python class definition:
===============================
class IOperation(instance):
  """""" docstring for class """"""

  def AsString(self):
    """""" 
    docstring
    
    docstring """"""
    pass

",tomer.spector@…
7612,Compile fails when including <boost/units/systems/si/codata_constants.hpp>,units,Boost 1.52.0,To Be Determined,Bugs,Matthias Schabel,new,2012-10-30T20:53:06Z,2012-10-30T20:53:06Z,"I found that adding ""#include <boost/units/systems/si/codata_constants.hpp>"" to my program will cause it to fail compilation with a huge amount of template errors. This used to work on version 1.46 but fails on version 1.47 and every version after including 1.52.beta. I am using gcc 4.7.1 on OpenSUSE 12.2. The test program is used to determine which version works is:

#include <boost/units/systems/si/codata_constants.hpp>

#include <iostream>

int main(int argc, char** argv)
{
    std::cout << ""Hello."" << std::endl;
    return 0;
}",Adam Shrader <adam.shrader@…>
7611,segfault in epoll_reactor.ipp,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2012-10-30T18:15:27Z,2018-07-31T12:54:45Z,"During testing of versions 1.46.1 and 1.51 on a 64-bit Ubuntu 12.04 I have found a seg fault condition in epoll_reactor.ipp.

The function is 

void epoll_reactor::deregister_descriptor(socket_type descriptor,
    epoll_reactor::per_descriptor_data& descriptor_data, bool closing)
{
  if (!descriptor_data)
    return;

  mutex::scoped_lock descriptor_lock(descriptor_data->mutex_);

  if (!descriptor_data->shutdown_)
  {

The member descriptor_data is checked for NULL before the mutex is locked, in rare conditions, when the if-statement is reached, descriptor_data is NULL.

I have solved this by adding a second check after the mutex is locked, i.e. 

  if (!descriptor_data)
    return;

  mutex::scoped_lock descriptor_lock(descriptor_data->mutex_);

  if (!descriptor_data)
    return;

  if (!descriptor_data->shutdown_)
  {

Best regards,
Fredrik Jansson",Fredrik Jansson <fredrik.jansson.se@…>
7610,Add support for PSK authentication to boost::asio:ssl,asio,Boost 1.52.0,To Be Determined,Patches,chris_kohlhoff,new,2012-10-30T16:51:39Z,2015-03-06T20:58:00Z,boost::asio:ssl provides methods to set up PKI authentication. But TLS can also use PSK for authentication. This patch adds methods to set a PSK callback on ssl::context.,Roman Bovsunovskiy <a2k0001@…>
7608,Custom service of boost::asio hangs after being interrupted,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-10-30T15:43:33Z,2012-10-30T15:48:20Z,"Custom service like logger_service that presented in boost::asio's example hangs after being added async_wait on signal_set. i.e. One has to hit Ctrl-C twice to stop a program.

FYI, my workaround is [http://stackoverflow.com/questions/13024711/extension-of-boostasio-hangs-after-being-interrupted/13064012#13064012 here].

",Acer Yang <yangacer@…>
7606,u32regex causes bus error,regex,Boost 1.51.0,To Be Determined,Bugs,John Maddock,new,2012-10-30T11:43:49Z,2012-12-20T16:50:53Z,"The Unicode regular expression

   boost::make_u32regex (""[pq]\\.\\.[xy]"");

causes a Bus Error. The same r.e. as a boost::regex is fine.

The r.e. ""[pq][.][.][xy]"" seems to be okay, so it looks like the repeated ""\\."" is at least part of the problem.

The following program Bus Errors on Solaris 10 with gcc 4.6.1 and Boost 1.51. (and all previous versions of Boost as far as I can tell.)

------
# include <boost/regex/icu.hpp>

int main (int, char**)
{
  const boost::u32regex re = boost::make_u32regex (""[pq]\\.\\.[xy]"");
  return 0;
}
-------",a.sanders@…
7597,transform_output_iterator,iterator,Boost Development Trunk,To Be Determined,Feature Requests,jeffrey.hellrung,new,2012-10-29T01:23:17Z,2012-11-21T22:40:45Z,"Hello,

This ticket is related to the proposal that I made in the
mailing list some weeks ago. The proposal is about adding
a new iterator, the transform_output_iterator (initially called
chained_output_iterator). Please see the code, unit tests and
documentation attached for details. Everything is also available
on github:
github.com/ldionne/boost-submissions

I was not able to generate the documentation as a whole, so only
the rst documents are attached. Please do not hesitate to contact
me for any issues/comments.

Thanks,

Louis Dionne

Note: Regarding the mean for composing iterators (using the
and_then method), I am open for discussion if another solution
would be more desirable. However, this is the result of several
attempts to reduce the requirements on the UnaryFunction type
and it is the only way I found not to require UnaryFunction to
have member typedefs.
",louis.dionne92@…
7596,process_jam_log - --locate-root doesn't work as advertised,Regression Testing USE GITHUB,Boost 1.52.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-28T20:50:41Z,2013-03-29T17:27:28Z,"Beman,

I've found that --locate-root doesn't permit one to build/test a library outside the boost root directory.  I've made changes to support this and tested it locally on my own projects.  I can't really test it on the whole boost regression testing on my equipment. So I'm a little bit in a quandary.

I'm attaching the patch with my changes.  I hope you can consider rolling them in.

The intention is that it the changes don't change the functioning of the code for current usage.  However, I'm a little at a loss with the library name function.  The problem occurs when there is a ""sublibrary"" file. I'm still looking at this.

My motivation is that I really, really need to be able to run this program from outside the boost directory.  This is to support the current project I'm trying to finish - ""Help for Boost Library Authors - Simple Tools - Build and Test"".  www.blincubator.com .  Basically this is a effort to make it easier to make quality C++ and Boost libraries and support ""modularization"" of boost.  I've invested a lot of effort and hope to be able to finish up these sticky bits.  I've shown my effort to a few cohorts, and response has been unenthusiastic.  As always, I'm not disuaded and have invested too much effort to bail now.  So I hope you can help me with this one sticky detail.

Thanks for any help you can provide on this critical point.

Robert Ramey

 ",Robert Ramey
7595,Implement interruptible threads on top of non-interruptible threads,thread,Boost 1.52.0,To Be Determined,Feature Requests,viboes,assigned,2012-10-28T20:05:07Z,2012-10-28T20:06:01Z,"Once we will be able to disable thread interruption it would be great if we can provide interruptible threads on top of non-interruptible threads so that the user don't pay for what they don't use, but has yet a mechanism that allows work with interruptible  and non-interruptible threads on the same executable.

See #7594 	Allow to disallow thread interruptions",viboes
7589,Add polymorphic lockables,thread,Boost 1.52.0,,Feature Requests,viboes,assigned,2012-10-28T19:43:12Z,2014-09-05T06:11:43Z,"Mutex are generic classes that work well when generic programming. Sometimes, in a OOP context, it is useful to be able to use polymorphically any model of a lockable.

A poly_lockable class that defines the lockable interface could be added as well as an poly_lockable_adapter to make any Lockable inherit from poly_lockable.",viboes
7586,Add a testable_mutex,thread,Boost 1.52.0,,Feature Requests,viboes,assigned,2012-10-28T19:22:13Z,2014-09-05T06:11:32Z,"Based on Associate Mutexes with Data to Prevent Races, By Herb Sutter, May 13, 2010 - http://www.drdobbs.com/windows/associate-mutexes-with-data-to-prevent-r/224701827?pgno=3

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

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

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

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

When we acquire a lock, we set the thread id; and when we release a lock, we reset it back to its default no id state.""",viboes
7584,boost::interprocess::unique_ptr ambiguous overload for ‘operator=’,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-10-28T01:52:00Z,2012-10-28T01:52:00Z,"Attached code fails to compile on MSVC2005 and MSVC2008:

error C2593: 'operator =' is ambiguous	main.cpp:23	

It also fails on gcc-4.3.4 - http://ideone.com/p4EXFS (but with older Boost version).",Evgeny Panasyuk <evgeny.panasyuk@…>
7583,Missing file?,system,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-27T23:25:28Z,2012-10-29T02:06:10Z,"Build on Windows 7 using Cygwin.

Is there libboost_system.a on the latest Boost build? I can't find it anywhere. Any difference between libboost_system.a and libboost_system-mt.a?",anon
7580,"boost::asio::tcp SEGV after ioservice stopped, restarted and new",asio,Boost 1.49.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-10-27T12:34:52Z,2012-10-27T13:42:34Z,"For solarpowerlog [1] I use boost::asio for the communication via TCP/IP. During an implementation of an new feature I experienced an reproducible segfault when during ioservice->poll()

I hope to give enough information to dig into, but if you need some additional information, please let me know. 

Please let me also know if I am (unknowingly) misuse or use the library wrongly.

Thanks
coldtobi

'''What I am doing:'''

The feature is for sharing a TCP/IP connection within several data sources/sinks in the programm. For this implementation every data source can write and receive at abitrary times where sends have priority over receives. This is realized in the way that receives are interrupted if another data source request a write and then the receive is resumed. The handling of the TCP/IP i/o is done in an dedicated thread (I mark this ""[T]"" below) , the interruption in the ""main"" process (marked [M])

So basically the programm does:
[T] socket->connect() 
[T] socket->async_write(); (in parallel running a deadline_timer to catch timeouts)
[T] socket->read_some(); (in parallel running a deadline_timer to catch timeouts. Later we will socket->read_some again after we know the amount of pending bytes.  and read those. But for this report: The interruption (next step) is usually at the first read_some() )
[M] ioservice->stop(); (this aborts the read_some, ) 

Here the thread making the IO detects that the ioservice has been stopped via ioservice->stopped() and will then abort the current operation, wait for the next request adn  before executing this new request it will call ioservice->reset(): 

[t] ioservice->reset()

As we now close to the crash, I will elabaroate as precise as possible what is done. (This all now is in the I/O thread)

Note: You can find the code at [3]. I add line numbers for better orientation

creating the deadline-timer: (lines 684+)

{{{
	deadline_timer timer(*(this->ioservice));
	boost::posix_time::time_duration td = boost::posix_time::millisec(timeout);
	timer.expires_from_now(td);
	timer.async_wait(boost::bind(&boosthelper_set_result, (int*) &result_timer,
			1));
}}}
(boosthelper_set_result is defined in line 451 and just set result_timer to 1 if called)

write the bytes: (line 692+)
{{{
        
	boost::asio::async_write(*sockt, boost::asio::buffer(s), write_handler);
}}}
s is a std::string and contains the data to be sent. max 255 bytes ASCII)

run the ioservice once to either finish the write or the timeout (line 695)

{{{
	size_t num = ioservice->run_one(ec);
}}}

run_once returns and the evaluation shows that async_write completed
-- num!=0 is checked and the result_timer also

Observation: Wireshark shows that the bytes are not transmitted
 
Then the timer is cancelled and its completion handler catched: (line 703+)
{{{
 timer.cancel();
 LOGTRACE(logger, __PRETTY_FUNCTION__ << "": still alive 2f"");
 ioservice->poll();
 LOGTRACE(logger, __PRETTY_FUNCTION__ << "": still alive 3"");

}}}

 ioservice->poll() is never returning, SEGV is raised here. Unfortunatly the backtrace is also corrupted. 


When not calling the ioservice->stop(), the SEGFAULT is gone too. (Confirmed by working around the need to stop the ioservice by just polling with short timeouts)

'''Testcase'''
Providing a destilled testcase is unfortuantly difficult. However, you can use solarpowerlog to see the issue. I commmited also sample configuration which allows a easy reproduction of the issue. See the git tree here [2].

If you have debian, you can install the build-dependencies by '''apt-get build-dep solarpowerlog'''
Otherwise configure will tell you about missing deps :-)
 

{{{
git clone  git://solarpowerlog.git.sourceforge.net/gitroot/solarpowerlog/solarpowerlog
cd solarpowerlog 
git checkout 47c079d3409c867287888f47bedb4f05b1c353b5
./bootstrap.sh
./configure --enable-sharedcomms --enable-sputniksimulator --enable-dummyinverter
make 
# in one shell (this one will not crash)
src/solarpowerlog -c tools/sputnik_simulator/solarpowerlog_shared.conf
# in another shell: (this one which will crash)
src/solarpowerlog -c example_confs/solarpowerlog_shared_sim.conf
}}}


After some seconds youl'll see the SEGV:

{{{
12839 [0x7f2cc3345760] DEBUG inverter.Simulator2.Comms_SharedConnection.SharedTarget null - virtual void CSharedConnectionSlave::Send(ICommand*): work: 0x7f2cb8003550
12839 [0x7f2cc3345760] DEBUG inverter.Simulator2.Comms_SharedConnection.SharedTarget null -  Not atomic 0x7f2cb8003550
12839 [0x7f2cc3345760] DEBUG inverter.Simulator2.Comms_SharedConnection.SharedTarget null - virtual void CSharedConnectionSlave::Send(ICommand*): submitting work: 0x7f2cb8003550
12839 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - virtual bool CConnectTCPAsio::AbortAll() Aborting 0 backlog entries
12839 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - virtual bool CConnectTCPAsio::AbortAll() Done
12839 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection. null - Ticket for this command is: 0 (current ticket is 0)
12839 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection. null - CSharedConnectionMaster::Send() ICmd: 0x7f2cb8003550
12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - ioservice stopped (1)
12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - Waiting for work
12964 [0x7f2cbfea1700] DEBUG inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - ioservice stopped
12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): now handling: 0x7f2cb8003550
12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): still alive 1
12964 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection. null - virtual void CSharedConnectionMaster::ExecuteCommand(const ICommand*) now handling: 0x7f2cb8004460
12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): still alive 2
12964 [0x7f2cc3345760] DEBUG inverter.Simulator.Comms_SharedConnection. null - virtual void CSharedConnectionMaster::ExecuteCommand(const ICommand*) rescheduling read: 0x7f2cb8003e30
12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): still alive 2e
12964 [0x7f2cbfea1700] TRACE inverter.Simulator.Comms_SharedConnection..Comms_TCP_ASIO null - void CConnectTCPAsio::HandleSend(CAsyncCommand*): still alive 2f
src/solarpowerlog Segmentation fault.
}}}


[1] http://sourceforge.net/projects/solarpowerlog/

[2] http://solarpowerlog.git.sourceforge.net/git/gitweb.cgi?p=solarpowerlog/solarpowerlog;a=commit;h=47c079d3409c867287888f47bedb4f05b1c353b5

[3] http://solarpowerlog.git.sourceforge.net/git/gitweb.cgi?p=solarpowerlog/solarpowerlog;a=blob;f=src/Connections/CConnectTCPAsio.cpp;h=5e3b0a1b13b66cc07e491ed98ad7dfe1f3cc5277;hb=47c079d3409c867287888f47bedb4f05b1c353b5",tobi@…
7579,whole numbers => natural numbers,numeric,Boost 1.52.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-10-27T12:30:24Z,2013-02-16T12:54:13Z,"> A numeric type is integer if the abstract values it represent are
> whole numbers.

Should say ""natural numbers""",Dave Abrahams
7574,Boost iostreams documentation has too many spell misses,iostreams,Boost 1.51.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-10-25T22:26:39Z,2012-10-25T22:26:39Z,"I have listed the spell misses I found in the boost iostreams documentation below (I tried e-mailing Jonathan Turkanis directly, but the e-mail address on the website seems to be not used anymore):

I know this may sound trivial, but I think the overall quality
of the site can be improved by fixing spelling errors.


>2.1.4. Writing a container_device
indicates how off is // interpretted:

characters in the conatiner

The implementation of seek is striaghforward.

>2.2.10. Finite State Filters
Boost Metaprogamming library

>3.1 Concepts
Boost.Iostreams prvides several

>3.3 Generic Streams and Stream Buffers
A C++ standard library charatcer traits type

Assocaites the given instance of T

>3.5 Code Conversion
encapulates code conversion

store charatcres

>3.6 Asynchronous and Non-Blocking I/O
synchronous and asynychronous

with both aynchronous and non-blocking i/o

>3.8 Pipelines
 filter-or-device consiting of

>3.9 Views
represnt the component

>3.10 Exceptions
thrown are propogated by the public

the implementor has a choice

convey aditional information

exception is rasied due

propogated as-is",spe56nw9@…
7573,"Missing operator++, --, %",units,Boost 1.52.0,To Be Determined,Feature Requests,Matthias Schabel,new,2012-10-25T17:27:40Z,2013-09-13T11:12:28Z,"As reported on the boost-users list <https://groups.google.com/forum/?fromgroups=#!msg/boost-list/-8COkmhO_0w/10IGPCxOe4AJ>,

It would be nice if quantity<incrementable type> could increment that type -- same for decrement and modulus.

The attached patch seems to work in my local copy -- it would be nice to get rolled into a future release, however.",nathan.crookston@…
7572,boost::gregorian::to_tm() does not fill in tm_gmtoff and tm_zone fields of the resulting std::tm structure,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-10-25T14:55:10Z,2012-10-25T14:55:10Z,"On Fedora 15 (and maybe on other OSes), std::tm contains fields describing the time zone:

{{{
#ifdef	__USE_BSD
  long int tm_gmtoff;		/* Seconds east of UTC.  */
  __const char *tm_zone;	/* Timezone abbreviation.  */
#else
  long int __tm_gmtoff;		/* Seconds east of UTC.  */
  __const char *__tm_zone;	/* Timezone abbreviation.  */
#endif
}}}

boost::gregorian::to_tm() (and boost::posix_time::to_tm() respectively) does not fill in these fields. So these fields contain garbage. Other code can be misleaded with values of these uninitialized fields.",izimenkov@…
7568,Unused parameter and shadowed member warnings in errors.hpp,program_options,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-10-24T21:24:06Z,2012-10-24T21:33:26Z,"This code


{{{
#include <boost/program_options/errors.hpp>

int main(int, char *[]) { return 0; }
}}}

compiled with


{{{
gcc -I/path/to/boost -c -Wunused-parameter -Wshadow test.cxx
}}}

produces a warning about an unused parameter and several warnings about shadowed class members:

{{{
/opt/local/include/boost/program_options/errors.hpp:253: warning: unused parameter 'option_name'
/opt/local/include/boost/program_options/errors.hpp: In constructor 'boost::program_options::invalid_syntax::invalid_syntax(boost::program_options::invalid_syntax::kind_t, const std::string&, const std::string&, int)':
/opt/local/include/boost/program_options/errors.hpp:311: warning: declaration of 'kind' shadows a member of 'this'
/opt/local/include/boost/program_options/errors.hpp: In constructor 'boost::program_options::invalid_config_file_syntax::invalid_config_file_syntax(const std::string&, boost::program_options::invalid_syntax::kind_t)':
/opt/local/include/boost/program_options/errors.hpp:331: warning: declaration of 'kind' shadows a member of 'this'
/opt/local/include/boost/program_options/errors.hpp: In constructor 'boost::program_options::invalid_command_line_syntax::invalid_command_line_syntax(boost::program_options::invalid_syntax::kind_t, const std::string&, const std::string&, int)':
/opt/local/include/boost/program_options/errors.hpp:350: warning: declaration of 'kind' shadows a member of 'this'
}}}

This was compile on Mac Snow Leopard, gcc 4.2.1 with the boost distribution from macports (although I doubt any of that matters). ",Kenneth Moreland <kmorel@…>
7567,Shadow warnings in timer.hpp,timer,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-24T20:48:50Z,2012-10-24T20:48:50Z,"This code

{{{
#include <boost/timer/timer.hpp>

int main(int, char *[]) { return 0; }
}}}

compiled with

{{{
gcc -I/path/to/boost -c -Wshadow test.cxx
}}}

produces several warnings about shadowed class members:

{{{
/opt/local/include/boost/timer/timer.hpp: In member function 'std::string boost::timer::cpu_timer::format(short int, const std::string&) const':
/opt/local/include/boost/timer/timer.hpp:74: warning: declaration of 'format' shadows a member of 'this'
/opt/local/include/boost/timer/timer.hpp: In constructor 'boost::timer::auto_cpu_timer::auto_cpu_timer(std::ostream&, short int, const std::string&)':
/opt/local/include/boost/timer/timer.hpp:103: warning: declaration of 'format' shadows a member of 'this'
/opt/local/include/boost/timer/timer.hpp:103: warning: declaration of 'places' shadows a member of 'this'
/opt/local/include/boost/timer/timer.hpp: In constructor 'boost::timer::auto_cpu_timer::auto_cpu_timer(std::ostream&, const std::string&)':
/opt/local/include/boost/timer/timer.hpp:107: warning: declaration of 'format' shadows a member of 'this'
}}}

This was compile on Mac Snow Leopard, gcc 4.2.1 with the boost distribution from MacPorts (although I doubt any of that matters).",Kenneth Moreland <kmorel@…>
7565,BOOST_MPL_CFG_HAS_TYPEOF should be defined for recent ICC versions,mpl,Boost 1.52.0,To Be Determined,Patches,Aleksey Gurtovoy,new,2012-10-24T16:38:36Z,2013-06-11T17:10:59Z,"Attached are:

1) A program listing that fails to compile with 'icc -DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=50 z.cpp'. It would pass if BOOST_MPL_CFG_HAS_TYPEOF were defined.

2) A proposed patch.",lukeocamden@…
7564,filesystem::path passed to GTest's assertion leads to stack overflow,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-24T16:25:22Z,2012-10-30T14:44:27Z,"The following code:
{{{
boost::filesystem::path p1(""c:\\123""), p2(""c:\\987"");

ASSERT_EQ(p1, p2);
}}}

leads to stack overflow.
It's because when GTest prints the assertion values it examines `path` as a container and try to print its items which are also `path` instances. This leads to recursion and stack overflow.

Most probably, the problem should be solved at Gtest side, but personal I think the design when `path` consist of `path`s (infinite recursion) is not very good and should be fixed.",oliora@…
7563,slex CONTLINE options parse keyword with backslash,wave,Boost 1.49.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-10-24T14:42:43Z,2012-10-24T14:42:43Z,"I'm using the slex, wrapped by boost::wave library, and it's very very cool. but I got a problem when using it.
that is it seems slex cannot process the following macro correctly:

#define M else\
    +1

the macro content is irrelevant, the point is slex treats ""else\"" as a whole as code detailed in the attachment.
",gongyiling3468@…
7561,bzip2_compressor does not play nicely with either direction of filtering_stream,iostreams,Boost 1.42.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-10-24T08:38:43Z,2012-10-24T08:38:43Z,"With boost::iostreams::filtering_stream<boost::iostreams::input>, bzip2_compressor's output is always empty.
With boost::iostreams::filtering_stream<boost::iostreams::output>, bzip2_compressor segfaults on an empty input.

I'm attaching a program that on my machine reproduces this issue.

Bugs that seem related: #2411, #3348, #5237",Alexander van Gessel (AI0867) <ai0867@…>
7558,MPI missing symbols using serialization's static library design,mpi,Boost 1.51.0,To Be Determined,Bugs,Matthias Troyer,new,2012-10-23T16:01:52Z,2013-01-01T11:26:28Z,"On Mac OS X Lion, we're seeing errors when linking our application using Boost.MPI.  The application is rather large and uses Boost.Serialization for both checkpoint/restart and MPI communication.  The checkpoint/restart bits made serialization a bit of a disaster in terms of compile times (due to headers including basically every other header in the project).  To solve that problem, we followed the Boost.Serialization advice on static libraries.

On Lion (and possibly elsewhere, but definitely on Lion) using
the gcc front-end (i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on
Apple Inc. build 5658) (LLVM build 2336.11.00)), we're seeing link
failures due to serialization calls for MPI archivers not being found when
compiling with -O2 or higher on Boost 1.50.0 and 1.51.0:

  CXXLD    sst.x
Undefined symbols for architecture x86_64:
  ""void SST::Introspector::serialize<boost::mpi::packed_iarchive>(boost::mpi::packed_iarchive&, unsigned int)"", referenced from:
      boost::archive::detail::iserializer<boost::mpi::packed_iarchive,
SST::Introspector>::load_object_data(boost::archive::detail::basic_iarchive
&, void*, unsigned int) const in introspectedComponent.o
      boost::archive::detail::iserializer<boost::mpi::packed_iarchive,
SST::Introspector>::load_object_data(boost::archive::detail::basic_iarchive
&, void*, unsigned int) consti n simulation.o

While I could simply explicitly instantiate the missing archivers, that seems like a bad idea for something in the detail namespace and it appears that the list of archivers I'd need to instantiate has changed over time. The mailing list suggested that this sounded like a bug and that I should file a bug report.

I've attached a test case that shows the problem.  It's essentially the Boost.Serialization demo_pimpl example, but using MPI instead of a text archiver.
",Brian Barrett <bwbarre@…>
7551,unused local variable in_str in tz_db_base.hpp,date_time,Boost 1.52.0,To Be Determined,Patches,az_sw_dude,new,2012-10-22T08:09:20Z,1970-01-01T00:00:00Z,trivial unused in_str variable,Caolán McNamara <caolanm@…>
7549,uBLAS banded storage does not match common BLAS layout (from netlib),uBLAS,Boost 1.52.0,To Be Determined,Bugs,Gunter,new,2012-10-21T20:38:11Z,2014-04-02T14:52:36Z,"A banded_matrix stores the elements in an unusual way. This makes it impossible to call standard BLAS-libraries with these matrix type.

Example data taken from http://www.netlib.org/lapack/lug/node124.html
{{{
Running banded_matrix < column_major > test
Full matrix
[5,5]((11,12,0,0,0),(21,22,23,0,0),(31,32,33,34,0),(0,42,43,44,45),(0,0,53,54,55))
data() of matrix
0 12 23 34 45 11 22 33 44 55 21 32 43 54 0 31 42 53 0 0
Expected data() of matrix
0 11 21 31 12 22 32 42 23 33 43 53 34 44 54 0 45 55 0 0
}}}

{{{
Running banded_matrix < row_major > test
Full matrix
[5,5]((11,12,0,0,0),(21,22,23,0,0),(31,32,33,34,0),(0,42,43,44,45),(0,0,53,54,55))
data() of matrix
0 11 21 31 12 22 32 42 23 33 43 53 34 44 54 0 45 55 0 0
Expected data() of matrix
0 0 11 12 0 21 22 23 31 32 33 34 42 43 44 45 53 54 55 0
}}}
",Gunter
7548,Impossible to query for std::vector<double> converter registration,python USE GITHUB,Boost Release Branch,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-10-21T19:20:18Z,2013-06-02T18:02:16Z,"I have been hitting this wall for some months now and produced some minimalistic code that shows the problem:

{{{
#include <boost/python.hpp>
#include <vector>
#include <iostream>


std::vector<double> list_of_doubles() {
	std::vector<double> retval;
	retval.push_back(3);
	retval.push_back(2);
	return retval;
}


// Instantiate the core module.
BOOST_PYTHON_MODULE(boost_debug)
{
//We check if a converter for std::vector has been registered
boost::python::type_info info = boost::python::type_id<std::vector<double> >(); 
const boost::python::converter::registration* reg = boost::python::converter::registry::query(info); 
//We output to screen the result (should be NULL)
std::cout << reg << "" "";

//We also expose a function that needs such a conversion (to_python)
using namespace boost::python;
def(""list_of_doubles"",list_of_doubles);
}
}}}

in python:

{{{
import boost_debug
}}}

and the result (which should be zero) is instead an address: 0x7f9bc3c4c600

Even more absurdly, if we comment the line ""def(""list_of_doubles"",list_of_doubles);"" things actually go back to normality.
",Dario Izzo <dario.izzo@…>
7545,filesystem::path::filename() specification wrong?,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-21T15:12:14Z,2012-10-21T15:12:14Z,"According to the [[http://www.boost.org/doc/libs/1_51_0/libs/filesystem/doc/reference.html#Definitions|definition]] section of the boost::filesystem documentation,
* a **path** consists of a root-name, a root-directory and (as relative-path) a sequence of filenames (all optional)
* a **filename** is the name of a file, with slashes explicitly forbidden as part of the filename

With these definitions, paths consisting entirely of root-name and/or root-directory parts (like {{{ ""//net""}}}, {{{ ""//net/"" }}} and {{{ ""/""}}}) do not contain filenames.

On the other hand, the specification of path::filename() says

  // Returns: // {{{ empty() ? path() : *--end() }}}

without discrimination between the different parts.  Consequently,
* {{{ Path(""//net"").filename() == Path(""//net"") }}}
* {{{ Path(""/"").filename() == Path(""/"") }}}
instead of the expected empty {{{Path()}}}, and containing the forbidden slash.

**Proposed fix:** \\
To become consistent with the definitions, path::filename() should be specified as follows:

  // Returns: // {{{ relative_path().empty() ? path() : *--end() }}}
",Stefan Große Pawig <boost@…>
7543,Expose range protocol for boost::iostreams::mapped_file,iostreams,Boost 1.52.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-10-21T09:59:31Z,2012-10-21T09:59:31Z,"It will be convenience that `boost::iostreams::mapped_file` expose a `boost::range` protocol using either member function or free function
",zhuo.qiang@…
7538,boost::spirit::istream_iterator does not handle incrememt correctly at the end,spirit,Boost 1.52.0,To Be Determined,Bugs,Joel de Guzman,new,2012-10-21T03:12:10Z,2015-05-09T23:08:23Z,"{{{boost::spirit::istream_iterator}}} (or its super class {{{multi_pass}}} )does not handle incrememt correctly at the end position. 
One more end char will be yielded which is incorrect:

{{{
#!cpp
#include <sstream>
#include <boost/spirit/include/support_istream_iterator.hpp>
#include <boost/test/minimal.hpp>

int test_main(int, char*[])
{
    std::istringstream in(""12"");
    boost::spirit::istream_iterator it(in), end;

    BOOST_CHECK(*it++ == '1');
    BOOST_CHECK(*it++ == '2');

    // it should be end now, however it failed
    BOOST_CHECK(it == end); // !failed here
    // and yield the last char once more
    BOOST_CHECK(*it != '2'); // !failed here

    // only after another dereference will it really equal to end
    BOOST_CHECK(it == end);

    return 0;
}
}}}

The output is:
{{{
test.cpp(14): test it == end failed in function: 'int test_main(int, char **)'
test.cpp(16): test *it != '2' failed in function: 'int test_main(int, char **)'

**** 2 errors detected
}}}

#6750 may be a duplicated issue.

Reproducable under:

* Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)
* Target: x86_64-apple-darwin12.2.0
* With C++ 11 turn on: ""-std=c++11 -stdlib=libc++""
* Boost 1.52 and Boost Trunk rev.81030

 ",zhuo.qiang@…
7536,Fails to Compile under OSX 10.8,Building Boost,Boost 1.51.0,Boost.Jam 4.0.0,Bugs,,new,2012-10-19T20:52:58Z,2016-08-09T00:13:18Z,"I am trying to install the Boost libraries on a MacBook Pro running 10.8. This produces compiler errors.  Any help you can give me would be appreciated. The output of ./b2 is below:

Building the Boost C++ Libraries.


Performing configuration checks

    - 32-bit                   : no
    - 64-bit                   : yes
    - x86                      : yes
    - has_icu builds           : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add ""using mpi ;"" to your user-config.jam
    - iconv (libc)             : no
    - iconv (separate)         : yes
    - icu                      : no
    - icu (lib64)              : no
    - gcc visibility           : yes
    - long double support      : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add ""using mpi ;"" to user-config.jam.
note: to suppress this message, pass ""--without-mpi"" to bjam.
note: otherwise, you can safely ignore this message.

Component configuration:

    - chrono                   : building
    - context                  : building
    - date_time                : building
    - exception                : building
    - filesystem               : building
    - graph                    : building
    - graph_parallel           : building
    - iostreams                : building
    - locale                   : building
    - math                     : building
    - mpi                      : building
    - program_options          : building
    - python                   : building
    - random                   : building
    - regex                    : building
    - serialization            : building
    - signals                  : building
    - system                   : building
    - test                     : building
    - thread                   : building
    - timer                    : building
    - wave                     : building

...patience...
...patience...
...patience...
...patience...
...found 8764 targets...
...updating 8 targets...
darwin.compile.c++ bin.v2/libs/graph/build/darwin-4.5.0/release/threading-multi/graphml.o
In file included from ./boost/property_tree/xml_parser.hpp:19:0,
                 from libs/graph/src/graphml.cpp:20:
./boost/property_tree/detail/xml_parser_read_rapidxml.hpp: In function ‘void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream<typename Ptree::key_type::value_type>&, Ptree&, int, const std::string&) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char>, std::basic_string<char> >, typename Ptree::key_type::value_type = char, typename Ptree::key_type::value_type = char, std::string = std::basic_string<char>]’:
./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:89:10: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -dynamic -gdwarf-2 -fexceptions -fPIC  -DBOOST_ALL_NO_LIB=1 -DBOOST_GRAPH_DYN_LINK=1 -DNDEBUG  -I""."" -I""libs/graph/src"" -c -o ""bin.v2/libs/graph/build/darwin-4.5.0/release/threading-multi/graphml.o"" ""libs/graph/src/graphml.cpp""

...failed darwin.compile.c++ bin.v2/libs/graph/build/darwin-4.5.0/release/threading-multi/graphml.o...
...skipped <pstage/lib>libboost_graph.dylib for lack of <pbin.v2/libs/graph/build/darwin-4.5.0/release/threading-multi>graphml.o...
darwin.link.dll bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/libboost_python.dylib
ld: warning: ignoring file /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/libpython2.6.dylib, missing required architecture x86_64 in file /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config/libpython2.6.dylib (2 slices)
Undefined symbols for architecture x86_64:
  ""_PyCallable_Check"", referenced from:
      boost::python::numeric::(anonymous namespace)::load(bool)                                  in numeric.o
      boost::python::objects::class_base::make_method_static(char const*) in class.o
  ""_PyDict_New"", referenced from:
      boost::python::detail::dict_base::dict_base() in dict.o
      boost::python::detail::dict_base::dict_base() in dict.o
      _instance_get_dict in class.o
  ""_PyType_Ready"", referenced from:
      boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*)                        in enum.o
      _class_setattro in class.o
      boost::python::objects::static_data()    in class.o
      boost::python::objects::class_metatype()    in class.o
      boost::python::objects::class_type()    in class.o
      boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o
      boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&) in class.o
      ...
  ""_PyLong_FromUnsignedLong"", referenced from:
      boost::python::objects::class_base::set_instance_size(unsigned long) in class.o
      boost::python::objects::function_doc_signature_generator::parameter_string(boost::python::objects::py_function const&, unsigned long, boost::python::api::object, bool) in function_doc_signature.o
      boost::python::objects::function_doc_signature_generator::pretty_signature(boost::python::objects::function const*, unsigned long, bool) in function_doc_signature.o
  ""_PyObject_RichCompare"", referenced from:
      boost::python::api::operator>(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
      boost::python::api::operator>=(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
      boost::python::api::operator<(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
      boost::python::api::operator<=(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
      boost::python::api::operator==(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
      boost::python::api::operator!=(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyExc_ValueError"", referenced from:
      boost::python::handle_exception_impl(boost::function0<void>) in errors.o
  ""_PyDict_Update"", referenced from:
      boost::python::detail::dict_base::update(boost::python::api::object const&) in dict.o
  ""_PyExc_StopIteration"", referenced from:
      boost::python::objects::stop_iteration_error()    in iterator.o
  ""__PyObject_New"", referenced from:
      boost::python::objects::make_nurse_and_patient(_object*, _object*) in life_support.o
  ""_PyObject_SetAttr"", referenced from:
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
      boost::python::api::setattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
      boost::python::api::delattr(boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
  ""_PyDict_GetItemString"", referenced from:
      boost::python::detail::wrapper_base::get_override(char const*, _typeobject*) const in wrapper.o
  ""_PyNumber_InPlaceRemainder"", referenced from:
      boost::python::api::operator%=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PyArg_ParseTupleAndKeywords"", referenced from:
      _property_init in class.o
  ""_PyMethod_New"", referenced from:
      _function_descr_get in function.o
  ""_PyObject_Size"", referenced from:
      boost::python::objects::enum_base::export_values()   in enum.o
      boost::python::objects::function::signature(bool) const in function.o
      boost::python::(anonymous namespace)::instance_reduce(boost::python::api::object)                                           in pickle_support.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::python::converter::(anonymous namespace)::wstring_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::objects::function_doc_signature_generator::parameter_string(boost::python::objects::py_function const&, unsigned long, boost::python::api::object, bool) in function_doc_signature.o
      boost::python::objects::function_doc_signature_generator::pretty_signature(boost::python::objects::function const*, unsigned long, bool) in function_doc_signature.o
      boost::python::objects::function_doc_signature_generator::function_doc_signatures(boost::python::objects::function const*) in function_doc_signature.o
      ...
  ""_PyList_Sort"", referenced from:
      boost::python::detail::list_base::sort()  in list.o
  ""_PyCFunction_Type"", referenced from:
      _function_get_class in function.o
  ""_PyDict_Values"", referenced from:
      boost::python::detail::dict_base::values() const in dict.o
  ""_PyNumber_InPlaceSubtract"", referenced from:
      boost::python::api::operator-=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PyTuple_GetItem"", referenced from:
      boost::python::objects::function::argument_error(_object*, _object*) const in function.o
  ""_PyString_Size"", referenced from:
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::python::converter::(anonymous namespace)::string_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""_PyMem_Malloc"", referenced from:
      boost::python::instance_holder::allocate(_object*, unsigned long, unsigned long) in class.o
  ""_PyErr_Occurred"", referenced from:
      boost::python::detail::list_base::insert(boost::python::api::object const&, boost::python::api::object const&) in list.o
      boost::python::detail::str_base::endswith(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::find(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::find(boost::python::api::object const&, boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::find(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::index(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::index(boost::python::api::object const&, boost::python::api::object const&) const in str.o
      ...
  ""_PyInt_FromLong"", referenced from:
      boost::python::numeric::aux::array_base::argmax(long) in numeric.o
      boost::python::numeric::aux::array_base::argmin(long) in numeric.o
      boost::python::numeric::aux::array_base::argsort(long) in numeric.o
      boost::python::numeric::aux::array_base::diagonal(long, long, long) const in numeric.o
      boost::python::numeric::aux::array_base::trace(long, long, long) const in numeric.o
      boost::python::numeric::aux::array_base::repeat(boost::python::api::object const&, long) in numeric.o
      boost::python::numeric::aux::array_base::swapaxes(long, long) in numeric.o
      ...
  ""_PyNumber_Subtract"", referenced from:
      boost::python::api::operator-(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyErr_WarnEx"", referenced from:
      boost::python::converter::registry::insert(_object* (*)(void const*), boost::python::type_info, _typeobject const* (*)()) in registry.o
  ""_PySequence_SetSlice"", referenced from:
      boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*)                           in object_protocol.o
  ""_Py_InitModule4_64"", referenced from:
      boost::python::detail::init_module(char const*, void (*)()) in module.o
  ""_PyString_FromString"", referenced from:
      boost::python::detail::str_base::str_base() in str.o
      boost::python::detail::str_base::str_base() in str.o
      boost::python::detail::str_base::str_base(char const*) in str.o
      boost::python::detail::str_base::str_base(char const*) in str.o
      boost::python::converter::do_return_to_python(char const*) in builtin_converters.o
  ""_PyType_IsSubtype"", referenced from:
      boost::python::objects::find_instance_impl(_object*, boost::python::type_info, bool) in class.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)         in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<float, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*)            in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<double, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*)           in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<long double, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*)      in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)    in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)          in builtin_converters.o
      ...
  ""_PyLong_AsLongLong"", referenced from:
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<long long, boost::python::converter::(anonymous namespace)::long_long_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""_PyLong_AsUnsignedLongLong"", referenced from:
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned long long, boost::python::converter::(anonymous namespace)::unsigned_long_long_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""_PyRun_FileExFlags"", referenced from:
      boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
  ""_PyObject_IsInstance"", referenced from:
      boost::python::numeric::aux::array_object_manager_traits::check(_object*)  in numeric.o
      boost::python::pytype_check(_typeobject*, _object*)     in from_python.o
      _class_setattro in class.o
      boost::python::objects::module_prefix()    in class.o
  ""_PyErr_Clear"", referenced from:
      boost::python::numeric::(anonymous namespace)::load(bool)                                  in numeric.o
      _instance_new in class.o
      boost::python::objects::function::call(_object*, _object*) const in function.o
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
      boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
      boost::python::api::getattr(boost::python::api::object const&, char const*, boost::python::api::object const&) in object_protocol.o
  ""_PyMethod_Type"", referenced from:
      boost::python::detail::wrapper_base::get_override(char const*, _typeobject*) const in wrapper.o
  ""_PyNumber_InPlaceAdd"", referenced from:
      boost::python::api::operator+=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PyString_InternFromString"", referenced from:
      _function_get_name in function.o
  ""_PyFile_AsFile"", referenced from:
      boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
  ""_PyObject_GetItem"", referenced from:
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
      boost::python::api::getitem(boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
      boost::python::api::getslice(boost::python::api::object const&, boost::python::handle<_object> const&, boost::python::handle<_object> const&) in object_protocol.o
  ""_PyType_GenericAlloc"", referenced from:
      boost::python::objects::class_type_object      in class.o
  ""_PyImport_Import"", referenced from:
      boost::python::numeric::(anonymous namespace)::load(bool)                                  in numeric.o
  ""_PyClass_Type"", referenced from:
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
  ""_PyLong_AsUnsignedLong"", referenced from:
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned char, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned char> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned short, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned short> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned int, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned int> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned long, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned long> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""__PyType_Lookup"", referenced from:
      _class_setattro in class.o
  ""_PyNumber_InPlaceLshift"", referenced from:
      boost::python::api::operator<<=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PyLong_Type"", referenced from:
      boost::python::detail::long_base::call(boost::python::api::object const&) in long.o
      boost::python::detail::long_base::call(boost::python::api::object const&, boost::python::api::object const&) in long.o
      boost::python::detail::long_base::long_base() in long.o
      boost::python::detail::long_base::long_base() in long.o
      boost::python::detail::long_base::long_base(boost::python::api::object const&) in long.o
      boost::python::detail::long_base::long_base(boost::python::api::object const&) in long.o
      boost::python::detail::long_base::long_base(boost::python::api::object const&, boost::python::api::object const&) in long.o
      ...
  ""_PyNumber_InPlaceDivide"", referenced from:
      boost::python::api::operator/=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PyDict_Size"", referenced from:
      boost::python::objects::function::call(_object*, _object*) const in function.o
  ""_PyObject_ClearWeakRefs"", referenced from:
      _instance_dealloc in class.o
  ""_PyExc_RuntimeError"", referenced from:
      _no_init in class.o
      boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
      boost::python::detail::pure_virtual_called()    in function.o
      boost::python::(anonymous namespace)::instance_reduce(boost::python::api::object)                                           in pickle_support.o
      boost::python::handle_exception_impl(boost::function0<void>) in errors.o
  ""_PyList_New"", referenced from:
      boost::python::detail::list_base::list_base() in list.o
      boost::python::detail::list_base::list_base() in list.o
  ""_PyNumber_Lshift"", referenced from:
      boost::python::api::operator<<(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyTuple_Type"", referenced from:
      boost::python::detail::tuple_base::call(boost::python::api::object const&) in tuple.o
      boost::python::detail::tuple_base::tuple_base(boost::python::api::object const&) in tuple.o
      boost::python::detail::tuple_base::tuple_base(boost::python::api::object const&) in tuple.o
      global constructors keyed to tuple.cpp in tuple.o
      boost::python::detail::converter_target_type<boost::python::to_python_value<boost::python::tuple const&> >::get_pytype() in pickle_support.o
  ""_PyNumber_Divide"", referenced from:
      boost::python::api::operator/(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyErr_ExceptionMatches"", referenced from:
      boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
      boost::python::api::getattr(boost::python::api::object const&, char const*, boost::python::api::object const&) in object_protocol.o
  ""__Py_NoneStruct"", referenced from:
      global constructors keyed to numeric.cpp in numeric.o
      global constructors keyed to list.cpp in list.o
      global constructors keyed to long.cpp in long.o
      boost::python::detail::dict_base::get(boost::python::api::object const&) const in dict.o
      global constructors keyed to dict.cpp in dict.o
      global constructors keyed to tuple.cpp in tuple.o
      global constructors keyed to str.cpp in str.o
      ...
  ""_PyRun_StringFlags"", referenced from:
      boost::python::eval(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
      boost::python::exec(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
      boost::python::exec_statement(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
  ""_PyString_FromStringAndSize"", referenced from:
      boost::python::numeric::(anonymous namespace)::load(bool)                                  in numeric.o
      boost::python::detail::str_base::str_base(char const*, char const*) in str.o
      boost::python::detail::str_base::str_base(char const*, char const*) in str.o
      boost::python::detail::str_base::str_base(char const*, unsigned long) in str.o
      boost::python::detail::str_base::str_base(char const*, unsigned long) in str.o
      boost::python::converter::do_return_to_python(char) in builtin_converters.o
      boost::python::tuple boost::python::make_tuple<boost::python::str, boost::python::api::object, boost::python::str, boost::python::str, boost::python::str, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >(boost::python::str const&, boost::python::api::object const&, boost::python::str const&, boost::python::str const&, boost::python::str const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) in function_doc_signature.o
      ...
  ""_PyList_Append"", referenced from:
      boost::python::detail::list_base::append(boost::python::api::object const&) in list.o
  ""_PyTuple_New"", referenced from:
      boost::python::detail::tuple_base::tuple_base() in tuple.o
      boost::python::detail::tuple_base::tuple_base() in tuple.o
      boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*)                        in enum.o
      boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o
      boost::python::objects::function::function(boost::python::objects::py_function const&, boost::python::detail::keyword const*, unsigned int) in function.o
      boost::python::objects::function::function(boost::python::objects::py_function const&, boost::python::detail::keyword const*, unsigned int) in function.o
      boost::python::objects::function::signature(bool) const in function.o
      ...
  ""_PyNumber_InPlaceRshift"", referenced from:
      boost::python::api::operator>>=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PyDict_GetItem"", referenced from:
      boost::python::detail::dict_base::get(boost::python::api::object const&) const in dict.o
      boost::python::objects::function::call(_object*, _object*) const in function.o
  ""_PyObject_DelItem"", referenced from:
      boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*)                           in object_protocol.o
      boost::python::api::delitem(boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
  ""_PyNumber_InPlaceAnd"", referenced from:
      boost::python::api::operator&=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PyObject_GetAttr"", referenced from:
      boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
      boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
  ""_PyType_Type"", referenced from:
      boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*)                        in enum.o
      _class_setattro in class.o
      boost::python::objects::static_data()    in class.o
      boost::python::objects::class_metatype()    in class.o
      boost::python::objects::class_type()    in class.o
      boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o
      boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&) in class.o
      ...
  ""_PyExc_ImportError"", referenced from:
      boost::python::numeric::(anonymous namespace)::load(bool)                                  in numeric.o
  ""_PyEval_GetGlobals"", referenced from:
      boost::python::eval(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
      boost::python::exec(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
      boost::python::exec_statement(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
      boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
  ""_PyNumber_Rshift"", referenced from:
      boost::python::api::operator>>(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyList_Reverse"", referenced from:
      boost::python::detail::list_base::reverse()  in list.o
  ""_PyMem_Free"", referenced from:
      _instance_dealloc in class.o
      boost::python::instance_holder::deallocate(_object*, void*) in class.o
  ""_PyString_Type"", referenced from:
      boost::python::detail::str_base::call(boost::python::api::object const&) in str.o
      boost::python::detail::str_base::str_base(boost::python::api::object const&) in str.o
      boost::python::detail::str_base::str_base(boost::python::api::object const&) in str.o
      global constructors keyed to str.cpp in str.o
      boost::python::converter::(anonymous namespace)::string_rvalue_from_python::get_pytype()                                                            in builtin_converters.o
      boost::python::converter::wrap_pytype<&PyString_Type>::get_pytype()             in builtin_converters.o
  ""_PyExc_TypeError"", referenced from:
      boost::python::converter::(anonymous namespace)::lvalue_result_from_python(_object*, boost::python::converter::registration const&, char const*)                 in from_python.o
      boost::python::converter::rvalue_result_from_python(_object*, boost::python::converter::rvalue_from_python_stage1_data&) in from_python.o
      boost::python::converter::rvalue_from_python_stage2(_object*, boost::python::converter::rvalue_from_python_stage1_data&, boost::python::converter::registration const&) in from_python.o
      boost::python::converter::throw_no_pointer_from_python(_object*, boost::python::converter::registration const&) in from_python.o
      boost::python::converter::throw_no_reference_from_python(_object*, boost::python::converter::registration const&) in from_python.o
      boost::python::pytype_check(_typeobject*, _object*)     in from_python.o
      boost::python::converter::registration::get_class_object() const in registry.o
      ...
  ""_PyUnicodeUCS2_FromEncodedObject"", referenced from:
      _encode_string_unaryfunc in builtin_converters.o
  ""_PyNumber_InPlaceXor"", referenced from:
      boost::python::api::operator^=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PyProperty_Type"", referenced from:
      _class_setattro in class.o
      boost::python::objects::static_data()    in class.o
      boost::python::objects::class_base::add_property(char const*, boost::python::api::object const&, char const*) in class.o
      boost::python::objects::class_base::add_property(char const*, boost::python::api::object const&, boost::python::api::object const&, char const*) in class.o
      boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&) in class.o
      boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&, boost::python::api::object const&) in class.o
  ""_PyBool_FromLong"", referenced from:
      boost::python::numeric::aux::array_base::factory(boost::python::api::object const&, boost::python::api::object const&, bool, bool, boost::python::api::object, boost::python::api::object) in numeric.o
      boost::python::objects::class_base::enable_pickling_(bool) in class.o
  ""_PyNumber_Add"", referenced from:
      boost::python::api::operator+(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyErr_NoMemory"", referenced from:
      boost::python::handle_exception_impl(boost::function0<void>) in errors.o
  ""_PyFile_FromString"", referenced from:
      boost::python::exec_file(boost::python::str, boost::python::api::object, boost::python::api::object) in exec.o
  ""_PyInt_Type"", referenced from:
      _enum_str in enum.o
      boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*)                        in enum.o
      boost::python::converter::(anonymous namespace)::signed_int_rvalue_from_python_base::get_pytype()                                                            in builtin_converters.o
      boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python_base::get_pytype()                                                            in builtin_converters.o
  ""_PyNumber_InPlaceMultiply"", referenced from:
      boost::python::api::operator*=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PySequence_GetSlice"", referenced from:
      boost::python::api::getslice(boost::python::api::object const&, boost::python::handle<_object> const&, boost::python::handle<_object> const&) in object_protocol.o
  ""_PyBool_Type"", referenced from:
      boost::python::converter::(anonymous namespace)::bool_rvalue_from_python::get_pytype()                                                            in builtin_converters.o
  ""_PyExc_ReferenceError"", referenced from:
      boost::python::converter::(anonymous namespace)::lvalue_result_from_python(_object*, boost::python::converter::registration const&, char const*)                 in from_python.o
  ""_PyDict_Copy"", referenced from:
      boost::python::detail::dict_base::copy()  in dict.o
  ""__Py_NotImplementedStruct"", referenced from:
      boost::python::objects::(anonymous namespace)::not_implemented(_object*, _object*)                                        in function.o
  ""_PyModule_Type"", referenced from:
      boost::python::objects::module_prefix()    in class.o
  ""_PyComplex_Type"", referenced from:
      boost::python::converter::(anonymous namespace)::complex_rvalue_from_python::get_pytype()                                                            in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)         in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)    in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)          in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      ...
  ""_PyObject_IsTrue"", referenced from:
      boost::python::objects::(anonymous namespace)::new_enum_type(char const*, char const*)                        in enum.o
      boost::python::objects::enum_base::to_python(_typeobject*, long) in enum.o
      boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o
      _function_get_doc in function.o
      boost::python::objects::function::signature(bool) const in function.o
      boost::python::objects::function::add_overload(boost::python::handle<boost::python::objects::function> const&) in function.o
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
      ...
  ""_PyNumber_Remainder"", referenced from:
      boost::python::api::operator%(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyComplex_ImagAsDouble"", referenced from:
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""_PyWeakref_NewRef"", referenced from:
      boost::python::objects::make_nurse_and_patient(_object*, _object*) in life_support.o
  ""_PyList_Insert"", referenced from:
      boost::python::detail::list_base::insert(long, boost::python::api::object const&) in list.o
  ""_PyNumber_Multiply"", referenced from:
      boost::python::api::operator*(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyImport_ImportModule"", referenced from:
      boost::python::import(boost::python::str) in import.o
  ""_PyExc_OverflowError"", referenced from:
      boost::python::handle_exception_impl(boost::function0<void>) in errors.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned char, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned char> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned short, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned short> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned int, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned int> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned long, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned long> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""_PyErr_SetString"", referenced from:
      _no_init in class.o
      _static_data_descr_set in class.o
      _function_get_module in function.o
      boost::python::detail::pure_virtual_called()    in function.o
      boost::python::(anonymous namespace)::instance_reduce(boost::python::api::object)                                           in pickle_support.o
      boost::python::handle_exception_impl(boost::function0<void>) in errors.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<unsigned char, boost::python::converter::(anonymous namespace)::unsigned_int_rvalue_from_python<unsigned char> >::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      ...
  ""_PyInt_AsLong"", referenced from:
      boost::python::detail::list_base::index(boost::python::api::object const&) const in list.o
      boost::python::detail::list_base::insert(boost::python::api::object const&, boost::python::api::object const&) in list.o
      boost::python::detail::list_base::count(boost::python::api::object const&) const in list.o
      boost::python::detail::str_base::endswith(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::find(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::find(boost::python::api::object const&, boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::find(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) const in str.o
      ...
  ""_PySequence_DelSlice"", referenced from:
      boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*)                           in object_protocol.o
  ""_PyIter_Next"", referenced from:
      boost::python::objects::stl_input_iterator_impl::stl_input_iterator_impl(boost::python::api::object const&) in stl_iterator.o
      boost::python::objects::stl_input_iterator_impl::stl_input_iterator_impl(boost::python::api::object const&) in stl_iterator.o
      boost::python::objects::stl_input_iterator_impl::increment()   in stl_iterator.o
  ""_PyErr_SetObject"", referenced from:
      boost::python::converter::(anonymous namespace)::lvalue_result_from_python(_object*, boost::python::converter::registration const&, char const*)                 in from_python.o
      boost::python::converter::rvalue_result_from_python(_object*, boost::python::converter::rvalue_from_python_stage1_data&) in from_python.o
      boost::python::converter::rvalue_from_python_stage2(_object*, boost::python::converter::rvalue_from_python_stage1_data&, boost::python::converter::registration const&) in from_python.o
      boost::python::converter::throw_no_pointer_from_python(_object*, boost::python::converter::registration const&) in from_python.o
      boost::python::converter::throw_no_reference_from_python(_object*, boost::python::converter::registration const&) in from_python.o
      boost::python::converter::registration::to_python(void const volatile*) const in registry.o
      boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o
      ...
  ""_PyDict_Keys"", referenced from:
      boost::python::detail::dict_base::keys() const in dict.o
  ""_PyBaseObject_Type"", referenced from:
      boost::python::objects::class_type()    in class.o
      boost::python::objects::(anonymous namespace)::new_class(char const*, unsigned long, boost::python::type_info const*, char const*) in class.o
  ""_PyString_FromFormat"", referenced from:
      boost::python::converter::(anonymous namespace)::lvalue_result_from_python(_object*, boost::python::converter::registration const&, char const*)                 in from_python.o
      boost::python::converter::rvalue_result_from_python(_object*, boost::python::converter::rvalue_from_python_stage1_data&) in from_python.o
      boost::python::converter::rvalue_from_python_stage2(_object*, boost::python::converter::rvalue_from_python_stage1_data&, boost::python::converter::registration const&) in from_python.o
      boost::python::converter::throw_no_pointer_from_python(_object*, boost::python::converter::registration const&) in from_python.o
      boost::python::converter::throw_no_reference_from_python(_object*, boost::python::converter::registration const&) in from_python.o
      boost::python::converter::registration::to_python(void const volatile*) const in registry.o
      _enum_repr in enum.o
      ...
  ""_PyExc_AttributeError"", referenced from:
      _static_data_descr_set in class.o
      _function_get_module in function.o
      boost::python::api::getattr(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
      boost::python::api::getattr(boost::python::api::object const&, char const*, boost::python::api::object const&) in object_protocol.o
  ""_PyObject_CallMethod"", referenced from:
      boost::python::detail::str_base::capitalize() const in str.o
      boost::python::detail::str_base::center(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::expandtabs() const in str.o
      boost::python::detail::str_base::expandtabs(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::join(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::ljust(boost::python::api::object const&) const in str.o
      boost::python::detail::str_base::lower() const in str.o
      ...
  ""_PyStaticMethod_New"", referenced from:
      boost::python::objects::class_base::make_method_static(char const*) in class.o
  ""_PyErr_Format"", referenced from:
      boost::python::numeric::(anonymous namespace)::load(bool)                                  in numeric.o
      boost::python::pytype_check(_typeobject*, _object*)     in from_python.o
      boost::python::converter::registration::get_class_object() const in registry.o
      boost::python::objects::class_base::make_method_static(char const*) in class.o
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
  ""_PyObject_SetItem"", referenced from:
      boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*)                           in object_protocol.o
      boost::python::api::setitem(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in object_protocol.o
  ""_PyFloat_Type"", referenced from:
      boost::python::converter::(anonymous namespace)::float_rvalue_from_python::get_pytype()                                                            in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)         in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<float, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*)            in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<double, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*)           in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<long double, boost::python::converter::(anonymous namespace)::float_rvalue_from_python>::convertible(_object*)      in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)    in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::convertible(_object*)          in builtin_converters.o
      ...
  ""__PyEval_SliceIndex"", referenced from:
      boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*)                           in object_protocol.o
      boost::python::api::getslice(boost::python::api::object const&, boost::python::handle<_object> const&, boost::python::handle<_object> const&) in object_protocol.o
  ""_PyObject_CallFunction"", referenced from:
      boost::python::detail::list_base::call(boost::python::api::object const&) in list.o
      boost::python::detail::list_base::list_base(boost::python::api::object const&) in list.o
      boost::python::detail::list_base::list_base(boost::python::api::object const&) in list.o
      boost::python::detail::long_base::call(boost::python::api::object const&) in long.o
      boost::python::detail::long_base::call(boost::python::api::object const&, boost::python::api::object const&) in long.o
      boost::python::detail::long_base::long_base() in long.o
      boost::python::detail::long_base::long_base() in long.o
      ...
  ""_PyNumber_Or"", referenced from:
      boost::python::api::operator|(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyUnicodeUCS2_AsWideChar"", referenced from:
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::python::converter::(anonymous namespace)::wstring_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""_PyDict_Items"", referenced from:
      boost::python::detail::dict_base::items() const in dict.o
  ""_PyDict_Type"", referenced from:
      boost::python::detail::dict_base::call(boost::python::api::object const&) in dict.o
      boost::python::detail::dict_base::dict_base(boost::python::api::object const&) in dict.o
      boost::python::detail::dict_base::dict_base(boost::python::api::object const&) in dict.o
      boost::python::detail::dict_base::clear()  in dict.o
      boost::python::detail::dict_base::copy()  in dict.o
      boost::python::detail::dict_base::get(boost::python::api::object const&) const in dict.o
      boost::python::detail::dict_base::items() const in dict.o
      ...
  ""_PyObject_SetAttrString"", referenced from:
      boost::python::objects::class_base::add_property(char const*, boost::python::api::object const&, char const*) in class.o
      boost::python::objects::class_base::add_property(char const*, boost::python::api::object const&, boost::python::api::object const&, char const*) in class.o
      boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&) in class.o
      boost::python::objects::class_base::add_static_property(char const*, boost::python::api::object const&, boost::python::api::object const&) in class.o
      boost::python::objects::class_base::setattr(char const*, boost::python::api::object const&) in class.o
      boost::python::objects::class_base::def_no_init()    in class.o
      boost::python::objects::class_base::enable_pickling_(bool) in class.o
      ...
  ""_PyExc_IndexError"", referenced from:
      boost::python::handle_exception_impl(boost::function0<void>) in errors.o
  ""_PyNumber_And"", referenced from:
      boost::python::api::operator&(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyObject_GetAttrString"", referenced from:
      boost::python::numeric::(anonymous namespace)::load(bool)                                  in numeric.o
      _enum_repr in enum.o
      _instance_new in class.o
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
      boost::python::api::getattr(boost::python::api::object const&, char const*) in object_protocol.o
      boost::python::api::getattr(boost::python::api::object const&, char const*, boost::python::api::object const&) in object_protocol.o
      boost::python::detail::wrapper_base::get_override(char const*, _typeobject*) const in wrapper.o
      ...
  ""_PyString_AsString"", referenced from:
      _enum_repr in enum.o
      boost::python::converter::(anonymous namespace)::convert_to_cstring(_object*)                                                            in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::python::converter::(anonymous namespace)::string_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""_PyStaticMethod_Type"", referenced from:
      boost::python::objects::function::add_to_namespace(boost::python::api::object const&, char const*, boost::python::api::object const&, char const*) in function.o
  ""_PyCFunction_NewEx"", referenced from:
      boost::python::objects::class_base::def_no_init()    in class.o
  ""_PyList_Type"", referenced from:
      boost::python::detail::list_base::call(boost::python::api::object const&) in list.o
      boost::python::detail::list_base::list_base(boost::python::api::object const&) in list.o
      boost::python::detail::list_base::list_base(boost::python::api::object const&) in list.o
      boost::python::detail::list_base::append(boost::python::api::object const&) in list.o
      boost::python::detail::list_base::insert(long, boost::python::api::object const&) in list.o
      boost::python::detail::list_base::reverse()  in list.o
      boost::python::detail::list_base::sort()  in list.o
      ...
  ""_PyErr_NewException"", referenced from:
      boost::python::objects::function::argument_error(_object*, _object*) const in function.o
  ""_PyDict_Clear"", referenced from:
      boost::python::detail::dict_base::clear()  in dict.o
  ""_PyUnicode_Type"", referenced from:
      boost::python::converter::(anonymous namespace)::wstring_rvalue_from_python::get_pytype()                                                            in builtin_converters.o
  ""_PyComplex_RealAsDouble"", referenced from:
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<float>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::complex<long double>, boost::python::converter::(anonymous namespace)::complex_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*) in builtin_converters.o
  ""_PyTuple_Size"", referenced from:
      boost::python::objects::function::argument_error(_object*, _object*) const in function.o
      boost::python::objects::function::call(_object*, _object*) const in function.o
  ""_PyNumber_Xor"", referenced from:
      boost::python::api::operator^(boost::python::api::object const&, boost::python::api::object const&) in object_operators.o
  ""_PyEval_CallFunction"", referenced from:
      boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&) in numeric.o
      boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&) in numeric.o
      boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&) in numeric.o
      boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&) in numeric.o
      boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in numeric.o
      boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in numeric.o
      boost::python::numeric::aux::array_base::array_base(boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&, boost::python::api::object const&) in numeric.o
      ...
  ""_PyNumber_InPlaceOr"", referenced from:
      boost::python::api::operator|=(boost::python::api::object&, boost::python::api::object const&) in object_operators.o
  ""_PySlice_New"", referenced from:
      boost::python::detail::slice_base::slice_base(_object*, _object*, _object*) in slice.o
      boost::python::detail::slice_base::slice_base(_object*, _object*, _object*) in slice.o
      boost::python::api::(anonymous namespace)::assign_slice(_object*, _object*, _object*, _object*)                           in object_protocol.o
      boost::python::api::getslice(boost::python::api::object const&, boost::python::handle<_object> const&, boost::python::handle<_object> const&) in object_protocol.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

    ""g++"" -dynamiclib -Wl,-single_module -install_name ""libboost_python.dylib"" -L""/Library/Frameworks/Python.framework/Versions/2.6/lib"" -L""/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" -o ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/libboost_python.dylib"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/numeric.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/list.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/long.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/dict.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/tuple.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/str.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/slice.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/from_python.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/registry.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/type_id.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/enum.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/class.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/function.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/inheritance.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/life_support.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/pickle_support.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/errors.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/module.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/builtin_converters.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/converter/arg_to_python_base.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/iterator.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/stl_iterator.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object_protocol.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object_operators.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/wrapper.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/import.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/exec.o"" ""bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/object/function_doc_signature.o""  -lpython2.6    -headerpad_max_install_names -Wl,-dead_strip -no_dead_strip_inits_and_terms 

...failed darwin.link.dll bin.v2/libs/python/build/darwin-4.5.0/release/threading-multi/libboost_python.dylib...
...skipped <pstage/lib>libboost_python.dylib for lack of <pbin.v2/libs/python/build/darwin-4.5.0/release/threading-multi>libboost_python.dylib...
darwin.compile.c++ bin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi/graphml.o
In file included from ./boost/property_tree/xml_parser.hpp:19:0,
                 from libs/graph/src/graphml.cpp:20:
./boost/property_tree/detail/xml_parser_read_rapidxml.hpp: In function ‘void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream<typename Ptree::key_type::value_type>&, Ptree&, int, const std::string&) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char>, std::basic_string<char> >, typename Ptree::key_type::value_type = char, typename Ptree::key_type::value_type = char, std::string = std::basic_string<char>]’:
./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:89:10: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions  -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I""."" -I""libs/graph/src"" -c -o ""bin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi/graphml.o"" ""libs/graph/src/graphml.cpp""

...failed darwin.compile.c++ bin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi/graphml.o...
...skipped <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>libboost_graph.a(clean) for lack of <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>graphml.o...
...skipped <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>libboost_graph.a for lack of <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>graphml.o...
...skipped <pstage/lib>libboost_graph.a for lack of <pbin.v2/libs/graph/build/darwin-4.5.0/release/link-static/threading-multi>libboost_graph.a...
...failed updating 3 targets...
...skipped 5 targets...




",roberts@…
7535,filesystem::path::iterator inconsistency with multiple leading separators,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-19T19:31:16Z,2012-10-19T19:31:16Z,"Iterating backwards through a filesystem::path does not terminate at path::begin() if the path starts with several leading directory separators.

For example:

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

int main()
{
  boost::filesystem::path p(""/////foo"");

  boost::filesystem::path::iterator i = p.begin();
  ++i;
  --i;
  std::cout << ((i == p.begin()) ? ""same"" : ""different"") << std::endl;
}
}}}

Expected output: `same` \\
Actual output: `different`

Looking at the source (filesystem/src/path.cpp), it seems that in path::begin() the iterator's m_pos member is set to the position of the last leading directory separator.

During backward iteration, m_pos is set to 0, though, so the iterator comparison (which involves comparing the m_pos members) yields false.
",Stefan Große Pawig <boost@…>
7534,Iostreams filter for LZMA2 (XZ),iostreams,Boost 1.52.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-10-19T18:22:50Z,2018-04-08T07:55:22Z,"I propose a standard LZMA2 (XZ) filter implementation for the Iostreams library.

LZMA2 provides much better compression than gz and bzip2. XZ is the default package format in Slackware GNU/Linux. 7-Zip, the most popular file compressor for Windows also uses LZMA2.

The source code of liblzma is found [http://tukaani.org/xz/ here].

A sample implementation of a Boost Iostream filter for lzma can be found in the [http://fusecompress.sourcearchive.com/documentation/2.6.git913897f4-1ubuntu1/files.html fusecompress source].

I think it would be a big advantage because XZ is an upcoming file format which is used more and more in areas and by applications where saving bandwidth, memory or physical storage is important.",spixxi
7533,Quickbook build fails without bjam --hash if filenames are too long,build,Boost 1.52.0,Boost 1.52.0,Bugs,Vladimir Prus,new,2012-10-19T14:11:34Z,2012-10-19T17:44:16Z,"Quickbook documentation (usually when using both Doxygen and auto-indexing)can cause filenames to become too long so xsltproc fails to process correctly.

A sample of the format of an error message is shown below.

The issue can be triggered by deep nesting of folders, creating very long filename, and will often only occur when autoindex is added with --enable-index  (thereby increasing folder depth). The problem was very puzzling to diagnose because it occured with apparently identical files on different systems!  

The 'cure' is to use the undocumented bjam --hash option (which compresses the filename).

This ticket is to provide a record of this in Trac and to request that the --hash option be documented.  

Building the Odeint docs with automatic index generation enabled.
...patience...
...patience...
...found 1925 targets...
...updating 8 targets...
doxygen-action bin\msvc-10.0\debug\auto-index-internal-on\auto-index-verbose-on\auto-index-on\threading-multi\reference-xml.xml-dir

<snip>

finished...
xslt-xsltproc.windows bin\msvc-10.0\debug\auto-index-internal-on\auto-index-verbose-on\auto-index-on\threading-multi\reference-xml.doxygen
file:///I%3A/boost-sandbox/odeint-v2/libs/numeric/odeint/doc/bin/msvc-10.0/debug/auto-index-internal-on/auto-index-verbose-on/auto-index-on/threading-multi/reference-xml/index.xml:2067: parser error : Opening and ending tag mismatch: compound line 1792 and doxygenindex
</doxygenindex>
               ^
",Paul A. Bristow
7526,zip_iterator does not support std::tuple and std::pair,iterator,Boost 1.50.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2012-10-18T10:05:27Z,2018-03-16T18:40:55Z,"The boost zip_iterator is not compatible with std::tuple and std::pair

The proposed patch solves this problem.

Note that I copied some more general tuple algorithms I created for another project. These are all included in the newly introduced namespace helper. Maybe they can be rewritten using boost::mpl, but since I am not familiar with it I used the existing code.

Furthermore I encountered the problem, that a specialisation of the template functions in namespace  tuple_impl_specific does not work, if this is done outside zip_iterator.hpp. The reason appears to be, that the user overloads are not known to the compiler, when the functions are called. This may be a problem, if users want to specialise for their own tuple class. To overcome this difficulty, I replaced the template functions by template classes, which seem to work even if specialisations are made outside zip_iterator.hpp",claas.koehler@…
7524,Assertion Fail: map/set iterators incompatible (msvc-8),uBLAS,Boost Development Trunk,To Be Determined,Bugs,Gunter,new,2012-10-17T21:32:39Z,2013-11-01T20:15:17Z,"Two regression tests fail in msvc-8 with this error:

Debug Assertion Failed:
   xtree line 293: Expression: map/set iterators incompatible

Tests failing:
  test3_mvov

  test_inplace_solve_mvov

",jim@…
7522,bootstrap.bat fails when TMP/TEMP folder contains a space in the path on Windows,Building Boost,Boost 1.51.0,To Be Determined,Bugs,,new,2012-10-17T16:36:26Z,2012-10-17T17:52:46Z,"To reproduce: (on Windows 7 x64 machine with vs2010)

1. set TEMP=C:\Program Files\Temp
2. set TMP=%TEMP%
3. bootstrap

Gives error.
Bootstrap.log shows that ""Files\Temp\_CL_xxxx.obj"" not found, indicating a problem with ' ' in path.

",David Hait <dhait@…>
7520,boost::interprocess::ipcdetail::truncate_file does not support 64bit size,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-10-17T14:53:16Z,2012-10-17T14:53:16Z,"As far as truncate_file accepts size_t variable, it will be impossible to re-size file to size greater than 2GB in the x32 application.

Here is signature:
inline bool truncate_file (file_handle_t hnd, std::size_t size)",Dmytro Ovdiienko <dmitriyovdienko@…>
7517,indirect_streambuf: invalid state change if write() writes less data then requested,iostreams,Boost 1.49.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-10-17T10:07:03Z,2012-10-17T10:07:03Z,"Currently indirect_streambuf::sync_impl() calls setp() to update pbase() without any regard to current pbase() value. With unreliable write() it will lead to buffer consistency loss and data duplication if write() doesn't satisfy request fully two or more times in a row.

As a solution setp() should use pbase() as current buffer begin instead of out().begin(). See patch.",Oleg Liatte <oleg.liatte@…>
7508,Boost timezonedb incorrect Brazil DST specification,date_time,Boost 1.51.0,To Be Determined,Bugs,az_sw_dude,new,2012-10-15T17:14:11Z,2012-10-15T17:14:11Z,"Today our applications running in Brazil have the incorrect time. We tracked it down to an error in the boost date_time_zonespec.csv specification for America/Sao_Paulo. It specifies that the DST change starts on the second Sunday of October (yesterday). However, it actually starts on the third Sunday (see the attached document from exchange). I downloaded the latest version of boost (1.51), and it is also incorrect there. Also note that Linux does have the correct time. I intend to submit a bug report to Boost, but I don’t know if you prefer if the external communication to go through your team.

Incorrect:
""America/Sao_Paulo"",""BRT"",""BRT"",""BRST"",""BRST"",""-03:00:00"",""+01:00:00"",""2;0;10"",""+00:00:00"",""3;0;2"",""+00:00:00""

Should be (for all BRST):
""America/Sao_Paulo"",""BRT"",""BRT"",""BRST"",""BRST"",""-03:00:00"",""+01:00:00"",""3;0;10"",""+00:00:00"",""3;0;2"",""+00:00:00""

",anonymous
7507,BGL subgraph copy constructor buggy,graph,Boost 1.51.0,To Be Determined,Bugs,Jeremiah Willcock,new,2012-10-15T14:45:45Z,2012-10-16T08:59:02Z,"Hello,

I store subgraph objects in a std::list.

After this, most of the data contained in subgraphs are lost.

Attached is a minimalist code that creates a root graph and two childen, and then displays them directly, then insert them into a (copy-on-write) list, then displays them again.

The root redisplays too much, and children lose data.

I am on MacOSX with gcc 6; maybe on other platforms the copy would not happen, since I don't modify the graphs between insertion and display.

Here is my output: 

{{{

From the stack: 
(root) graph: 6(0,2) 4(1,2) 
num_edges= 2
subgraph: 0(0,1) 
num_edges= 1
subgraph: 0(0,1) 
num_edges= 1

From list: 
graph: 0(0,1) 1(1,2) 2(1,3) 6(2,5) 3(4,1) 4(4,5) 5(5,3) 
num_edges= 7
graph: 
num_edges= 0
graph: 
num_edges= 0
}}}

",Amyn Bennamane <amynbe@…>
7504,boost::interprocess::basic_vectorbuf calls std::char_traits<char>::pbump() with potentially mismatching data type,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-10-14T22:57:17Z,2012-10-14T22:57:17Z,"`boost::interprocess::basic_vectorbuf::seekoff()` makes a call to `base_t::pbump()`, but the datatypes (may) mismatch for the parameter (and do on my system). `std::char_traits<char>::pbump()` takes an `int` (according to the standard), but `basic_vectorbuf()` is passing it a value of type `CharTraits::off_type`, which is implementation defined. Since `std::char_traits<char>::off_type` is `__int64` on my system, I am getting a warning about a conversion from `__int64` to `int`.

I don't know what the most appropriate solution is (maybe just a `static_cast`), but it would be nice to have this resolved so I can get back down to 0 warnings in my codebase.

I am using Visual Studio 2010 and the latest Boost (and I just check svn trunk and it has the same issue). I get this warning when creating a `boost::interprocess::basic_vectorstream` like so:

`basic_vectorstream<std::vector<char>, std::char_traits<char>> vs;`",mbradshaw@…
7502,Planarity test runs in quadratic time on some graphs,graph,Boost 1.52.0,To Be Determined,Bugs,Jeremiah Willcock,new,2012-10-13T16:45:19Z,2012-10-13T19:52:39Z,"The planarity test in the graph library (boyer_myrvold_planarity_test) seems to run in quadratic time for a certain class of graph.

I attached a program that demonstrates the problem. The program reads number N from stdin, generates a certain graph and runs the planarity test on it.

The graph is a bipartite graph K_{2,n} with some additional edges -- specifically, 2 ""left"" vertices of the bipartite graph are connected with an edge and n ""right"" vertices form a path. Note that the order of edge insertion matters -- the problem disappears if we change it.

Unfortunately I don't understand the planarity test enough to fix the problem. What I established (and what makes me believe it runs in quadratic time) is that for my graph in function walkdown (in planar_details/boyer_myrvold_impl.hpp; I understand the function is called once for each vertex) there is a loop on line 663 that is executed k times when the function was called for (k+1)-th time. This loop seems to have to do with Kuratowski subgraph detection, but I can't say anything more about it.

My configuration is Mac OS 10.8 with MacPorts, g++ 4.7 and boost 1.51. I also reproduced it on some Linux and Windows configurations.
",Jan Hązła <jan.hazla@…>
7494,boost::replace_all is very slow on debug build when Format size is big,string_algo,Boost 1.45.0,To Be Determined,Bugs,Marshall Clow,assigned,2012-10-11T09:28:38Z,2016-07-11T21:34:40Z,"Method boost::replace_all(SequenceT& Input, const Range1T& Search, const Range2T& Format) on debug build takes very long time when Format size is about 300k. On call stack I can see push_front for every char.

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

I have Boost library 1.45, Visual Studio 2010, Win7 x64 SP1, 6-core CPU.",Jan Vonasek <jan.vonasek@…>
7483,Exception 'T' is not a legal base class,exception,Boost 1.52.0,To Be Determined,Support Requests,Emil Dotchevski,new,2012-10-08T14:06:18Z,2013-01-17T00:09:47Z,"You might be getting this error for all kinds of reasons. Please provide complete source code of your test, or close the bug.",xaviergxf@…
7482,Build from source with MinGW on Windows,Building Boost,Boost Development Trunk,To Be Determined,Bugs,timblechmann,new,2012-10-07T18:46:34Z,2013-03-29T17:26:09Z," Hello, I've trying to build boost with mingw, and I've got error, when `--layout=system` option is used.

check out (with cygwin):

{{{
> svn co http://svn.boost.org/svn/boost/trunk boost-trunk
> svnversion
80897
}}}


build (windows cmd.exe):

{{{
> g++ --version
g++ (Built by MinGW-builds projects) 4.7.1
> cd boost-trunk
> .\bootstrap gcc
}}}


build with `--layout=tagged` works fine:

{{{
> .\b2 --toolset=gcc --layout=tagged
}}}


but build with `--layout=system` failed:

{{{
> .\b2 --toolset=gcc --layout=system
...
error: Duplicate name of actual target: <pstage\lib>libboost_atomic.a
error: previous virtual target { common%common.copy-libboost_atomic.a.STATIC_LIB { gcc%gcc.archive-libboost_atomic.a.STATIC_LIB { gcc%gcc.compile.c++-
lockpool.o.OBJ { lockpool.cpp.CPP } } } }
error: created from ./stage-proper
error: another virtual target { common%common.copy-libboost_atomic.a.STATIC_LIB { gcc%gcc.archive-libboost_atomic.a.STATIC_LIB { gcc%gcc.compile.c++-l
ockpool.o.OBJ { lockpool.cpp.CPP } } } }
error: created from ./stage-proper
error: added properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release
error: removed properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug
M:/boost-trunk/tools/build/v2/build\virtual-target.jam:491: in actualize-no-scanner from module object(file-target)@4808
M:/boost-trunk/tools/build/v2/build\virtual-target.jam:134: in object(file-target)@4808.actualize from module object(file-target)@4808
M:/boost-trunk/tools/build/v2\build-system.jam:736: in load from module build-system
M:\boost-trunk\tools\build\v2/kernel\modules.jam:289: in import from module modules
M:\boost-trunk\tools\build\v2/kernel/bootstrap.jam:139: in boost-build from module
M:\boost-trunk\boost-build.jam:17: in module scope from module
}}}
",RusBaratov@…
7481,lambda_tests.test fails to compile with BOOST_RESULT_OF_USE_DECLTYPE,phoenix,Boost Development Trunk,To Be Determined,Bugs,Thomas Heller,new,2012-10-07T18:39:50Z,2012-10-07T18:46:47Z,"#5687 (some evaluation functions do not work with `BOOST_RESULT_OF_USE_DECLTYPE`) 
is generally fixed by Eric recently. 
But `libs/phoenix/scope/lambda_tests.cpp` fails to compile on gcc 4.4-4.8 and clang 2.8-3.0
with `BOOST_RESULT_OF_USE_DECLTYPE`. 
Eric also reported it fails to compile on MSVC with `BOOST_RESULT_OF_USE_DECLTYPE`. 

The compilation succeeds on clang 3.1-3.2 (which have N3276 decltype support). 
",Michel Morin
7476,Use of Boost.Filesystem without building as separate library.,filesystem,Boost 1.52.0,To Be Determined,Feature Requests,Beman Dawes,new,2012-10-07T04:26:12Z,2012-10-07T04:26:12Z,"It is really tedious to use Boost.Filesystem (and possibly other non-header-only boost library, e.g. Boost.System) in a program because it needs to be built separately. I think it should be possible to add source files of Boost.Filesystem library to project so that Boost.Filesystem sources are built as a part of program itself. This will remove the dependency of building Boost.Filesystem as a separate library and so it will be as good as a header-only library.
I have tried this and it seems to be working after commenting out #define BOOST_FILESYSTEM_SOURCE from source files.",sacha@…
7475,Functions redeclared inline after been called,system,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-10-06T13:06:56Z,2012-10-06T13:06:56Z,"THe following warnings appear with intel-12.1.3 compiler 
{{{
../../../boost/system/error_code.hpp(489): remark #522: function ""boost::system::error_category::default_error_condition"" redeclared ""inline"" after being called
      inline error_condition error_category::default_error_condition( int ev ) const
                                             ^

../../../boost/system/error_code.hpp(494): remark #522: function ""boost::system::error_category::equivalent(int, const boost::system::error_condition &) const"" redeclared ""inline"" after being called
      inline bool error_category::equivalent( int code,
                                  ^

../../../boost/system/error_code.hpp(500): remark #522: function ""boost::system::error_category::equivalent(const boost::system::error_code &, int) const"" redeclared ""inline"" after being called
      inline bool error_category::equivalent( const error_code & code,
                                  ^

}}}

See the attached patch that solves the issue. ",viboes
7469,Parallel Graph: redistribute() does not compile for bidirected graphs,graph,Boost 1.51.0,To Be Determined,Patches,Jeremiah Willcock,new,2012-10-04T13:32:07Z,2012-10-04T13:32:07Z,"Trying to to use redistribute on a adjacency_list with the bidirectionalS tag leeds to compile erros.

I tracked down the problem to the point, that there is a additional internal property on vertices for this type of graphs. This property is not properly handeled during the call of redistribute. Attached is a patch including a test.",Christoph Koke <c.koke@…>
7468,asio/detail/config.hpp defines _WIN32_WINNT even under WinCE,asio,Boost 1.52.0,To Be Determined,Patches,chris_kohlhoff,new,2012-10-04T13:30:05Z,2012-10-04T13:30:05Z,"Boost.Asio defines _WIN32_WINNT macro even under WinCE environment (_WIN32_WCE == 0x500, Visual Studio 2008).

{{{
# if !defined(_WIN32_WINNT) && !defined(_WIN32_WINDOWS)
#  if defined(_MSC_VER) || defined(__BORLANDC__)
#   pragma message( \
  ""Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For example:\n""\
  ""- add -D_WIN32_WINNT=0x0501 to the compiler command line; or\n""\
  ""- add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.\n""\
  ""Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target)."")
#  else // defined(_MSC_VER) || defined(__BORLANDC__)
#   warning Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately.
#   warning For example, add -D_WIN32_WINNT=0x0501 to the compiler command line.
#   warning Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).
#  endif // defined(_MSC_VER) || defined(__BORLANDC__)
#  define _WIN32_WINNT 0x0501
# endif // !defined(_WIN32_WINNT) && !defined(_WIN32_WINDOWS)
}}}

Maybe it would better to add some UNDER_CE check here?
",listhex@…
7453,Dead link in date::time docs,date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-10-01T18:33:16Z,2012-10-01T18:33:16Z,"In the list of references

http://boost-sandbox.sourceforge.net/doc/html/date_time/details.html#date_time.references

the link to Will Linden's list of calendar links

http://www.ecben.net/calendar.shtml

is a dead link.",wlandry@…
7451,clang-linux.jam : cflags/cxxflags feature is added twice to compiler's command line (other features possibly as well),build,Boost 1.50.0,To Be Determined,Bugs,Vladimir Prus,new,2012-10-01T10:34:53Z,2012-10-01T10:34:53Z,"The crux of the issue appears to be here:

--- clang-linux.jam.orig        2012-10-01 20:31:55.253818173 +1000
+++ clang-linux.jam     2012-10-01 20:29:05.048627617 +1000
@@ -66,8 +66,8 @@
 ###############################################################################
 # Flags
 
-toolset.flags clang-linux.compile OPTIONS <cflags> ;
-toolset.flags clang-linux.compile OPTIONS <cxxflags> ;
+#toolset.flags clang-linux.compile OPTIONS <cflags> ;
+#toolset.flags clang-linux.compile OPTIONS <cxxflags> ;
 
 toolset.flags clang-linux.compile OPTIONS <optimization>off   : ;
 toolset.flags clang-linux.compile OPTIONS <optimization>speed : -O3 ;

Flags are apparently already added by the ""base"" module and then again by the inherited one (does it make sense?).
",oakad@…
7450,Buggy rounded_arith.hpp,interval,Boost 1.52.0,To Be Determined,Bugs,Boris Gubenko,new,2012-10-01T10:33:56Z,2012-10-01T10:33:56Z,"The rounded_arith file is currently buggy, because it misses an explicit this-> to some function calls (due to the evolution in template compilation of g++ since version 4.0).
I attach the small patch to get it working.",Luca Di Gaspero <l.digaspero@…>
7440,boost::filesystem compile error on solaris 10,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-09-28T14:57:09Z,2013-10-21T14:52:05Z,"It fails to compile on gcc 4.7.2 with compile flags cxxflags=-std=c++0x[[BR]]

libs/filesystem/src/operations.cpp: In function 'void boost::filesystem::detail:
:permissions(const boost::filesystem::path&, boost::filesystem::perms, boost::system::error_code*)':
libs/filesystem/src/operations.cpp:1412:11: error: '::fchmodat' has not been declared

in line 1410 there is:[[BR]]
{{{
&& !(defined(__SUNPRO_CC) || defined(sun)) \
}}}


proper check for solaris would be:[[BR]]
{{{
&& !(defined(__SUNPRO_CC) || defined(sun) || defined(__sun)) \
}}}
",aleksandar.vukajlovic@…
7436,Missing python dlls,python USE GITHUB,Boost 1.50.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-09-27T10:00:38Z,2012-09-27T10:00:38Z,"Dears,

When I am building boost 1.50 using:

b2 --toolset=msvc-9.0 --build-type=complete --without-mpi --build-dir=..\lib_msvc9_x86_p26 --stagedir=..\lib_msvc9_x86_p26 install

boost-python dlls are not created. in version 1.45 they had been created.

How can I build boost-python dlls?
There are boost python static libs.
There are other dlls present (e.g. boost-system), so it is rather boost-python package problem or special case of boost build tool chain.

Also there is general problem that mentioned commanline options are not creating delivery folder with all important binaries as it was in the past.

Regards,
Seweryn Habdank-Wojewodzki.
",habdank@…
7433,MSVC runtime check fix in crc,crc,Boost 1.53.0,To Be Determined,Bugs,Daryle Walker,reopened,2012-09-27T08:30:53Z,2013-02-22T07:23:26Z,"With MSVC in debug mode and runtime checks enabled, we encounter an issue in crc.hpp.

Please find attached a simple patch against boost 1.51.0 which fixes this issue.",Franz Detro <franz.detro@…>
7424,Request for more Accumulators rolling capabilities,accumulator,Boost 1.51.0,To Be Determined,Feature Requests,Eric Niebler,new,2012-09-26T12:27:57Z,2012-09-26T12:27:57Z,"Hello,
it would be really cool if the Boost.Accumulators library had other `rolling` features extending what already exists (`rolling_mean` etc.). My understanding of the wikipedia page on ""algorithms for calculating variance"" is that statistical moments could be calculated in a rolling manner.
This is just a suggestion, thanks for everything!
Arthur",Arthur
7420,"If I call managed_shared_memory() function when I create a lot of objects, it ocurrs error.",interprocess,Boost 1.47.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-09-25T07:47:47Z,2012-10-09T21:42:00Z,"
I want to call managed_shared_memory(), when I create a lot of objects... however,it ocurrs error. In additional, it's too show to create shared memory and segment.. 

You can check a attached file. 

Should I call managed_shared_memory() only one time?

please answer.. 
 ",anonymous
7417,"Detailed test status is not available in the Boost.Test log (status, assertions, passed) and so live test case status cannot be tracked",test,Boost Development Trunk,To Be Determined,Patches,Gennadiy Rozental,new,2012-09-24T15:59:12Z,2017-03-09T12:25:41Z,"Currently with Boost.Test it is not possible to use the test output to show detailed live test progress. By detailed I mean, test status, number of passed assertions and total number of assertions. This is because:

  1. Only basic status information is provided through `stdout` (the Boost.Test log) as tests are proceeding. Notably just whether a test has started or a test has finished.
  2. Detailed information is accessible by accessing the test report information captured as part of the Boost.Test report functionality which is typical sent to `stderr`.
  3. Report data is only output when all tests are complete therefore this information cannot be used for live reporting. In other words a solution is not to listen on both `stdout` and `stderr` 

The attached patch adds additional test status information to the information sent to stdout - the Boost.Test log. This allows arbitrary test tools to be developed that interpret the test output for live test progress reporting.

We use one such tool based on scons that allows us to view live test progress on the console. This is not possible with the current Boost.Test since detailed test status is not available until all cases have completed.

This patch compliments the patches attached to:

[[TicketQuery( id=7397|7410 )]] 

and taken together allows for sophisticated test tools to be built on top of the Boost.Test output.
",Jamie Allsop <ja11sop@…>
7411,Matrix with vector interface.,uBLAS,Boost 1.52.0,To Be Determined,Feature Requests,Gunter,new,2012-09-22T23:02:12Z,2012-09-22T23:02:12Z,"Sometimes it is useful to treat a matrix as a range of (independent) columns (or rows). Currently there is no iterator available that iterates over one dimension of the matrix and returns a full column/row as value.

The attached files have been provided by Oswin Krause as a possible solution.",Gunter
7406,Documentation lists the wrong constructor for char_delimiters_separator,tokenizer,Boost 1.52.0,To Be Determined,Bugs,jsiek,new,2012-09-22T07:15:09Z,2012-09-22T16:52:45Z,"http://www.boost.org/doc/libs/1_39_0/libs/tokenizer/char_delimiters_separator.htm

lists as the constructor:
{{{
explicit char_delimiters_separator(bool return_delims = false,
 const Char* returnable = """",const Char* nonreturnable = """" )
}}}

when it is in fact:

{{{
explicit char_delimiters_separator(bool return_delims = false,
   const Char* returnable = 0,const Char* nonreturnable = 0)
}}}

from token_functions.hpp",Therefore <therefore@…>
7405,Coercion to multi_array_ref from array_view,multi_array,Boost 1.47.0,To Be Determined,Feature Requests,Ronald Garcia,new,2012-09-21T22:10:52Z,2012-09-21T22:10:52Z,"I'd like to have functions that can be passed references to arrays of a given storage type and rank. Take a look at the following code:

template <class A>
void foo_duck(A ma)
{
    ma[0][1] = 1.0;
}

typedef boost::multi_array_ref<double, 2> ref_array_2d;
void foo_ref(ref_array_2d ma)
{
    ma[0][1] = 1.0;
}

int main()
{
    typedef boost::multi_array<double, 3>         array_3d;
    typedef boost::multi_array_types::index_range range;

    array_3d A(boost::extents[3][4][4]);
    array_3d::array_view<2>::type slice = A[boost::indices[1][range()][range()]];

    foo_duck(slice);
    foo_ref(slice);

    return 0;
}

foo_duck works fine, but foo_ref does not; I get a compiler error (gcc 4.6.3, boost 1.47) like so: ""error: could not convert ‘slice’ from ‘boost::multi_array<double, 3ul>::array_view<2ul>::type {aka boost::detail::multi_array::multi_array_view<double, 2ul>}’ to ‘ref_array_2d {aka boost::multi_array_ref<double, 2ul>}’""

I suspect, without having looked at the code itself, that multi_array_ref was never designed to be coerced from array_view, but I don't understand why. Is there a solution to my foo_ref problem that doesn't involve moving all such functions to headers and templating them?",Jason Sewall <jasonsewall@…>
7404,filesystem::canonical fails on UNC paths on Windows,filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2012-09-21T20:12:58Z,2012-09-21T22:23:23Z,"The filesystem library function canonical(p, base) fails for all UNC paths on Windows because it gets an ""invalid path"" error when it calls symlink_status at line 816 of operations.cpp. Example: For the path ""//server/share/file"", the first time execution reaches line 816 of operations.cpp, it calls is_symlink(detail::symlink_status(""//server"", ec)) and ec is set to the Windows ""invalid path"" system error code.",Craig Dickson <cdickson@…>
7396,"filesystem::path::remove_all(path, error_code) throws filesystem_error exception",filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2012-09-19T22:55:50Z,2012-09-19T22:55:50Z,"Several methods in filesystem::path, including remove_all, have an overload in which an extra error_code& argument is taken. According to the docs, this is supposed to cause failure (other than failure to allocate storage) to be reported in the error_code rather than as a thrown filesystem_error exception. However, remove_all can still throw filesystem_error exceptions because it uses a directory_iterator internally but makes no attempt to catch exceptions thrown by it. For example, if a subdirectory is deleted by another thread or process just before remove_all tries to list its contents, directory_iterator_construct will throw a filesystem_error that propagates up to remove_all's caller.

As a side note, I think path and directory_iterator are both excessively exception-happy. It makes them painful to use.",Craig Dickson <cdickson@…>
7393,"documentation suggests to store handle in node, why?",heap,Boost 1.52.0,To Be Determined,Tasks,timblechmann,new,2012-09-19T12:48:57Z,2012-09-19T12:48:57Z,"The documentation of the mutability concept includes a section that describes how to store handles into values in the heap.

""Note that handles can be stored inside the value_type (nodes): ""

http://www.boost.org/doc/libs/1_51_0/doc/html/heap/concepts.html#heap.concepts.mutability

I don't understand the point of this note. Handles are used to access nodes. If you store your handles inside nodes and not somewhere else, how can you possibly access nodes. If you do store your handles somewhere else, why would you also store them in the nodes?

I got confused trying to make use of this tip in my own code. Perhaps it is possible to add some motivation for this note, or just remove it. ",Alex Hagen-Zanker <ahh34@…>
7387,marginal improvements to dijkstra_shortest_paths,graph,Boost 1.52.0,To Be Determined,Patches,Jeremiah Willcock,new,2012-09-18T12:26:56Z,2013-09-24T13:33:43Z,"There are a couple of details in the dijkstra_shortest_path calculation that potentially make the implementation less efficient than strictly necessary. All considered the change in performance is marginal. But the code will be more to the point and I was happy to no longer use boost::closed_plus.

1. The tree_edge member function and the gray_target member function call the relax() function. In case of undirected graphs, this function attempts to relax both the target and the source of the edge. This is right for some algorithms (e.g. Bellman-Ford) but not for others (e.g. Dijkstra Shortest Paths). It would therefore be preferred to introduce a new function relax_target(), that only relaxes the target of an edge.

2. The defaults algorithm for summing weights and distances is boost::closed_plus<T>. This implements a simple plus operation with the extension that x + inf = inf, where inf is a special value set upon initialization.  Note that this is not a generic guard against overflows, but only works if one of the inputs is equal to inf. If the new relax_target() is used, then it is no longer necessary to use boost::closed_plus and simple std::plus will suffice. (*)

3. The tree_edge member function of the dijkstra_bfs_visitor is called when a new vertex is found. The distance for this vertex must always reduce. Several checks in relax() or relax_target() are therefore not necessary, and it is recommended to add a function relax_target_confident().(*)

4. If the relax_target_confident function is used, then any comparison  with distance_inf values is avoided. Strictly speaking it is not longer necessary to initialize the values of the distance map, and the precise value becomes irrelevant to the algorithm.

5. The update() function for the d-ary-heap does not need the old_distance therefore the gray_target member function does not need to call it.

(*). There could possibly be one other reason to use boost::closed_plus and that is the case of edge_weights being equal to distance_inf. This could be a hackish way of excluding edges from the shortest path search and IMO does not need to be supported. ",Alex Hagen-Zanker <ahh34@…>
7385,Unused parameter causes compilation error,program_options,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-09-17T23:28:52Z,2012-10-04T08:22:08Z,"When the compiler is set to treat warnings as errors, the line #253:

  virtual void set_option_name(const std::string& option_name) {}

in the file program_options/errors.hpp, causes a compilation error.",lcarreon@…
7377,Abort trap when using Program Options,program_options,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-09-14T14:43:32Z,2012-09-14T14:55:15Z,"Hello,
 I tried to run the simple example provided on the web site at the following URL (file 'first'):

http://www.boost.org/doc/libs/1_51_0/doc/html/program_options/tutorial.html#id2547756

When I run:
./test_po a b c d e   OR  ./test_po --compression 1
there are no problems.

When I run
./test_po --compression 
./test_po -compression
./test_po -a  OR ./test_po -a 1
./test_po -aa oR ./test_po --a 1
the program fails due to an abort trap.

This is my working environment:
- boost 1.51.1
- OS X 10.6.8
- g++ i686-apple-darwin10-g++-4.2.1

Please let me know in case you need more info.

Regards",lordthistle@…
7369,grow() resets permissions,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-09-12T22:01:11Z,2012-09-12T22:01:11Z,"I need to create shared memory with unrestricted permissions (0666). This works fine. When I attempt to grow the shared memory, using the grow() function, the permissions get reset to 0644. 

I followed the code a bit and saw that it was using ftruncate.
Checking the man page for ftruncate reveals, ""the set-user-ID and
set-group-ID permission bits may be cleared."" Not sure what affects the ""may"" clause, but it did it every time for me. Umask was set to 0000.

Obviously this only effects systems using ftruncate. Windows works correctly.

Not sure on what versions may be needed, but:
libc6 - 2.11.1
libglib2.0 - 2.24.1
gcc - 4.4.3",Aaron Wright <Aaron_Wright@…>
7366,program_options/variables_map.hpp warning C4275,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-09-11T12:34:04Z,2012-09-11T12:34:04Z,"When trying to build release version (debug version builds successfully) of our library with boost 1.49 I get the following warning:

1>d:\sb\EventEngine_trunk\outputs\intermediates\include\boost/program_options/variables_map.hpp(148) : warning C4275: non dll-interface class 'std::_Container_base_aux' used as base for dll-interface class 'std::_Container_base_aux_alloc_real<_Alloc>'
1>        with
1>        [
1>            _Alloc=std::allocator<std::pair<const std::string,boost::program_options::variable_value>>
1>        ]
1>        d:\Software\VS2008\VC\include\xutility(377) : see declaration of 'std::_Container_base_aux'

Our software has treat warnings as errors enabled so I have to resort to disabling that compiler warning in order to build. Are there any plans to address this?",maciek.siemczyk@…
7361,Forbid compilation of leaking mistake.,program_options,Boost 1.51.0,To Be Determined,Support Requests,Vladimir Prus,new,2012-09-10T17:26:08Z,2013-03-27T06:52:48Z,"I was adding program_option to my prorgam when I discovered a related leak. Fortunately it was false positive, but it pointed a hidden problem.
I used:
 - Visual Studio 2012
 - Boost 1.51.0
 - Visual Leak Detector to detect the leak

This, generate the leak:


{{{
#include <boost/program_options.hpp>

int main()
{
	namespace bpo = boost::program_options;
	bpo::options_description options( ""Options"" );
	options.add_options()
			( ""test""		, ""Test."" )
		,	( ""value""		, bpo::value<int>(), ""Value."" )
		;

	
}
}}}


The second option is leaking. The reason is because of the comma in the beginning of the line. 
I first added it by reflex when using function arguments so it took me some time to find what was leaking.
Part of the time I spend was figuring out why it don't leak if you don't set a value type: 

{{{

#include <boost/program_options.hpp>

int main()
{
	namespace bpo = boost::program_options;
	bpo::options_description options( ""Options"" );
	options.add_options()
			( ""test""		, ""Test."" )
		,	( ""value""		, ""Value."" ) // no leak but still wrong!
		;

}

}}}

The main problem I see with this is that it is compiled without any problem nor warning.

So here is my question:
Would it be possible to forbid comma operator with options_description_easy_init?",mjklaim@…
7344,Free properties not available in conditional rule,build,Boost 1.52.0,To Be Determined,Bugs,Vladimir Prus,new,2012-09-07T18:37:04Z,2012-09-25T20:04:16Z,"Free properties are not propagated to common-properties2 rule in targets.jam file. Rationale behind this is to optimise caching of already created property-set objects (exactly as stated in rule common-properties, which contains the call).

However, this optimisation causes that free features are not passed e.g. to user-defined rules used for evaluation of <conditional> properties (see example below in the second code listing).

Therefore I would propose to drop this optimisation and propagate also free properties (see code listing below). The other possible solution would be to just pass free properties to the common-properties2 rule and thus make them available to the algorithm, but this will introduce another bug (property-set object from cache will be used even though it contains values created from different free properties).


== SOLUTION PROPOSAL ==


{{{
rule common-properties ( build-request requirements )
{
    local props = [ property-set.create
        [ $(requirements).base ]
        [ $(requirements).incidental ]
        [ $(requirements).free ]
    ] ;

    local key = .rp.$(build-request)-$(props) ;
    if ! $($(key))
    {           
        $(key) = [ common-properties2 $(build-request) $(props) ] ;        
    }        
    return $($(key)) ;
}
}}}


== BUG REPRODUCTION ==


{{{
import feature ;


feature.feature define-prefix : : free ;

rule define-target-os ( properties * )
{
  local define-prefix = [ feature.get-values define-prefix : $(properties) ] ;
  define-prefix ?= """" ;
  local target-os = [ feature.get-values target-os : $(properties) ] ;
  return <define>$(define-prefix)TARGET_OS_$(target-os:U) ;
}


project /root
  : requirements
      <define-prefix>FOOBAR_
      <conditional>@define-target-os
;


exe hello
 : #sources
     hello.cpp
 : #requirements
;
}}}

",anonymous
7343,Extend result_of to work with SFINAE,result_of,Boost 1.52.0,To Be Determined,Feature Requests,Daniel Walker,new,2012-09-07T01:51:26Z,2012-09-25T13:59:42Z,"In response to a problem first identified by Joel de Guzman:

http://thread.gmane.org/gmane.comp.lib.boost.devel/233752/focus=233934

When BOOST_RESULT_OF_USE_DECLTYPE is defined, the attached patch makes the expression result_of<Fn( ArgTypes ...)>::type not well formed when the expression decltype(INVOKE(declval< Fn >(), declval< ArgTypes >()...)) is not well formed, but does not break SFINAE when used as the return type of a function overload.
",Daniel Walker
7341,Vector subscript out of range exception when calling weighted_core_numbers,graph,Boost 1.51.0,To Be Determined,Bugs,Jeremiah Willcock,reopened,2012-09-06T15:06:50Z,2012-09-10T14:12:29Z,"I get a vector subscript out of range exception when calling the weighted_core_numbers function in the boost graph library. The exception is actually thrown from within the mutable_queue::update function, but I  can't tell if the error is in mutable_queue or in weighted_core_numbers.

The attached test program is sufficient to show the problem. The test network is taken from Figure 1 of the Batagelj-Zaversnik paper (http://vlado.fmf.uni-lj.si/pub/networks/doc/cores/cores.pdf), with random integer weights of 1, 2, or 3 added to each edge.
",Ian Robertson <irober67@…>
7340,Visual studio iostreams warnings,iostreams,Boost 1.52.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-09-06T14:41:27Z,2013-05-31T21:55:43Z,"Visual studio 2010 raises ""conditional expression is constant"" warnings from chain.hpp. This can be fixed by simply including the disable_warnings header in chain.hpp

Visual studio 2010 raises various ""unreachable code"" warnings. This can be fixed by adding warning 4702 in disable_warnings.hpp

Visual studio 2012 raises a ""inherits via dominance"" warning from stream.hpp (see http://connect.microsoft.com/VisualStudio/feedback/details/733720/inheriting-from-std-fstream-produces-c4250-warning for the cause of this warning). This requires including the disable_warnings header in stream.hpp and adding warning 4250 to disable_warnings.
",Alan Birtles <alan.birtles@…>
7337,sparse_view.hpp: wrong copy-constructor for compressed_matrix_view,uBLAS,Boost 1.52.0,To Be Determined,Patches,Gunter,new,2012-09-06T08:27:09Z,2013-08-21T12:37:34Z,"The copy constructor for {{{compressed_matrix_view}}} (in {{{boost/numeric/ublas/experimental/sparse_view.hpp}}}) is wrong: it doesn't copy any member from the input argument.

I upload a patch for this, along with the patched file.",Marco Guazzone <marco.guazzone@…>
7333,Provide User-defined Literals for chrono durations on compilers supporting them,chrono,Boost 1.51.0,To Be Determined,Feature Requests,viboes,assigned,2012-09-06T04:13:35Z,2012-09-08T06:46:29Z,"boost::chrono::duration suffixes h, min, s, ms, us, ns in namespace boost::suffixes::chrono",viboes
7332,Missing inline directives in crc.hpp,crc,Boost 1.52.0,To Be Determined,Bugs,Daryle Walker,new,2012-09-05T20:34:12Z,2012-09-05T20:39:23Z,see diff with fix,Sergey Fokin <drigh@…>
7320,"Warnings ""duplicate friend declaration"" with Intel C++ Compiler XE 12.1.5.344",exception,Boost 1.51.0,To Be Determined,Bugs,Emil Dotchevski,new,2012-09-02T11:51:43Z,2012-09-02T11:51:43Z,"There are some warnings ""duplicate friend declaration"" with Intel C++ Compiler XE 12.1.5.344 at Windows (Windows 7 SP1 Pro) during building of programs using Boost.Exception: 
{{{
1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(258): warning #367: duplicate friend declaration
1>            friend struct exception_detail::get_info<throw_function>;
1>            ^
1>  
1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(259): warning #367: duplicate friend declaration
1>            friend struct exception_detail::get_info<throw_file>;
1>            ^
1>  
1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(260): warning #367: duplicate friend declaration
1>            friend struct exception_detail::get_info<throw_line>;
1>            ^
}}}
The warning level is Level4 (/W4).",abrarov@…
7319,Take care of c++std-lib-32966 issue,thread,Boost 1.51.0,To Be Determined,Bugs,viboes,assigned,2012-09-02T08:32:23Z,2012-09-02T08:41:34Z,"Take care of the issue raised by Howard Hinnant in 

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

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

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

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

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


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

""



",viboes
7316,Build boost.python fails with python 3.2.3,python USE GITHUB,Boost 1.51.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-09-01T17:08:04Z,2013-03-12T00:57:20Z,"{{{
$ ./b2 -q -d+2 variant=release link=shared threading=multi runtime-link=shared  | grep err
libs/mpi/src/python/datatypes.cpp:20:33: error: ‘PyInt_Type’ was not declared in this scope
libs/mpi/src/python/py_environment.cpp:53:37: error: cannot convert ‘char**’ to ‘wchar_t**’ for argument ‘2’ to ‘void PySys_SetArgv(int, wchar_t**)’

$ uname -a
Linux asus 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ python3 --version
Python 3.2.3

$ echo ""import sys; print( sys.prefix )"" | python3
/usr

$  cat project-config.jam | grep python
using python : 3.2 : /usr ;
}}}
",Sergey Dmitriev <dmi3evsv@…>
7315,A fusion adapted struct with a single member doesn't work with the Qi list operator,spirit,Boost 1.52.0,To Be Determined,Bugs,Joel de Guzman,new,2012-09-01T07:09:39Z,2012-09-01T07:09:39Z,As demonstrated in the attached file a fusion adapted struct with a single member doesn't work with the Qi list operator whereas its equivalent based on the kleen operator does work.,vexocide
7313,"filesystem reference doc shows path::u16string(), but it doesn't exist",filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2012-08-31T15:53:56Z,2016-02-18T19:22:59Z,"The Boost 1.50 filesystem reference says that filesystem::path has methods u16string(), generic_u16string(), u32string() and generic_u32string(), but they don't exist in the code. MS Visual Studio 2010's C++ compiler can't find them, and a grep of the boost::filesystem source doesn't find them either. Please either implement these methods or remove them from the docs.

(My preference would be that you implement these methods, and also, for completeness, add u8string() and generic_u8string(), which would return UTF-8 instead of using the current locale.)",Craig Dickson <cdickson@…>
7310,filesystem::path::iterator::operator+ is unusable due to compile error,filesystem,Boost 1.50.0,To Be Determined,Bugs,Beman Dawes,new,2012-08-31T15:14:08Z,2012-08-31T15:14:08Z,"Boost 1.50, MS Visual Studio 2010. I find that if I attempt to use the + operator on a path::iterator, I get a compiler error saying that the method ""advance"" is not part of path::iterator. If I comment out my use of this operator, and instead use only ++, then everything compiles.

Here are the details from the compiler:
{{{
boost/iterator/iterator_facade.hpp(544): error C2039: 'advance' : is not a member of 'boost::filesystem::path::iterator'
    boost/filesystem/path.hpp(570) : see declaration of 'boost::filesystem::path::iterator'
    boost/iterator/iterator_facade.hpp(690) : see reference to function template instantiation 'void boost::iterator_core_access::advance<Derived>(Facade &,__w64 int)' being compiled
    with
    [
        Derived=boost::filesystem::path::iterator,
        Facade=boost::filesystem::path::iterator
    ]
    boost/iterator/iterator_facade.hpp(689) : while compiling class template member function 'boost::filesystem::path::iterator &boost::iterator_facade<Derived,Value,CategoryOrTraversal>::operator +=(__w64 int)'
    with
    [
        Derived=boost::filesystem::path::iterator,
        Value=const boost::filesystem::path,
        CategoryOrTraversal=boost::bidirectional_traversal_tag
    ]
    boost/filesystem/path.hpp(574) : see reference to class template instantiation 'boost::iterator_facade<Derived,Value,CategoryOrTraversal>' being compiled
    with
    [
        Derived=boost::filesystem::path::iterator,
        Value=const boost::filesystem::path,
        CategoryOrTraversal=boost::bidirectional_traversal_tag
    ]
}}}",Craig Dickson <cdickson@…>
7305,zip_view silently ignores elements,fusion,Boost Development Trunk,To Be Determined,Bugs,Joel de Guzman,new,2012-08-30T14:22:44Z,2012-08-30T14:22:44Z,"zip_view takes the minimum size of all the sequences it is given. As a result it may silently ignore elements, which is not desirable.

I think it would be better if it checked all sequences were the same size.",Mathias Gaunard
7304,"size of a fusion sequences is signed, should be unsigned",fusion,Boost Development Trunk,To Be Determined,Bugs,Joel de Guzman,new,2012-08-30T14:20:47Z,2012-09-10T02:00:13Z,"fusion::result_of::size< fusion::vector<int, int> >::type::value is signed, even though it should be size_t.

It appears the problem is two-fold:
 - fusion::result_of::size<T>::value is not the same type as fusion::result_of::size<T>::type::value_type
 - size of fusion::vector is defined to be a mpl::int_ (it also seems it is the case for all fusion sequences types!)

The fact that this is wrongly signed causes all sorts of warnings.",Mathias Gaunard
7303,XML Serialization - Skip/Ignore unexpected data.,serialization,Boost 1.51.0,To Be Determined,Feature Requests,Robert Ramey,new,2012-08-30T12:40:15Z,2013-02-19T12:51:23Z,"Please find attached an extension to boost::serialization.  The purpose of this work is to add some support for forward compatibility of boost::serialization XML files; specifically the ability to skip/ignore unexpected data.

I would describe the patch as a ""first working version"", the tests all pass (gcc 4.6) with some expected failures (see below), but further work is required.  I guess I'm trying to gauge interest, get some feedback on the implementation, and get inspired enough to invest more time in it.

== Implementation ==

Two new archive types, `rapidxml_iarchive`, and `rapidxml_wiarchive`, have been created.  Their implementation is based on `xml_[w]iarchive` with the XML parsing provided by the rapidxml parser used in boost::property_tree.

This seemed the best approach to the problem as it avoided issues with `ungetc`.

Polymorphic versions of `rapidxml_[w]iarchive` have not been implemented.

== Test status ==

All tests are passing with the following caveats:

* Polymorphic rapidxml archives have not been implemented resulting in 6 tests failing to compile
* The following tests have had to be tweaked to accommodate rapidxml_[w]iarchive not ignoring element names
  * test_derived_class
  * test_recursion
  * test_nvp 
  * test_non_default_ctor2
  * test_diamond
  * test_diamond_complex

== Notes and further work ==

The current implementation is a ""first working version"" and requires some polishing.  There are a number of things that require further investigation, broadly speaking they can be categorized as:

* Better reuse
  * Factor out a base class (templated on char type) for `rapidxml_iarchive` and `rapidxml_wiarchive`
  * Some code could be shared between `rapidxml_[w]iarchive` and `xml_[w]iarchive`
    * See `[rapid]xml_iarchive::load(std::wstring&)`
    * See `[rapid]xml_wiarchive::load(std::string&)`
* Better error handling
* Flag support
  * Currently there are no plans to support any kind of flags/alternative behaviour so the existing flag code may need to be removed
* Miscellany
  * Go through comments to see what's still relevant
  * Replace history map with vector
",anonymous
7295,mapped_region large file throw exception,interprocess,Boost 1.52.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-08-27T09:09:08Z,2012-09-18T21:37:23Z,"using namespace boost::interprocess;
	const std::size_t FileSize = 10000000000;
	//if(argc == 1)
	{ //Parent process executes this
		{  //Create a file
			std::filebuf fbuf;
			fbuf.open(""e:\\output\\file.bin"", std::ios_base::in | std::ios_base::out 
				| std::ios_base::trunc | std::ios_base::binary); 
			//Set the size
			fbuf.pubseekoff(FileSize-1, std::ios_base::beg);
			fbuf.sputc(0);
		}
		//Remove file on exit
		struct file_remove 
		{
			~file_remove (){  file_mapping::remove(""file.bin""); }
		} destroy_on_exit;

		//Create a file mapping
		file_mapping m_file(""e:\\output\\file.bin"", read_write);

		//Map the whole file with read-write permissions in this process
		try{ 
		mapped_region region(m_file, read_write);
		
		

		//Get the address of the mapped region
		void * addr       = region.get_address();
		std::size_t size  = region.get_size();

		//Write all the memory to 1
		std::memset(addr, 1, size);
		}
		catch( boost::interprocess::interprocess_exception& ex  ){
			cout << ""\njjhhh"" << ex.what() << endl;
		}
		//Launch child process
		//std::string s(argv[0]); s += "" child "";
	//	if(0 != std::system(s.c_str()))
			return 1;
	}

mapped_region region(m_file, read_write); throw a exception",anonymous
7288,Under windows it is possible to use io_service::poll without a previous call to reset!,asio,Boost 1.52.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-08-26T11:58:05Z,2012-08-26T11:58:42Z,"I found out, that it is possible under windows to use io_service::poll without calling reset on the same service before.

Under Linux the internal variable ""stopped_"" is checked in the immplementation. The windows immplementation doesent do that, although the documentation says:
""The poll() function runs handlers [...] until the io_service has been stopped [...].""",code.databyte@…
7276,Add move semantics,tuple,Boost 1.51.0,To Be Determined,Feature Requests,Joel de Guzman,new,2012-08-25T08:12:34Z,2013-02-26T21:40:35Z,Boost.Tuple lack move semantics for its arguments. It should be great if it can comply with the c++11 standard when the compiler provides rvalue references and use Boost.Move otherwise.,viboes
7275,SIGSEGV in boost::asio::connect when compiled with g++ -std=c++0x,asio,Boost 1.50.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-08-24T15:48:51Z,2012-08-24T16:12:31Z,"Works fine when not compiled with -std=c++0x.
GCC v. 4.6.3 on ubuntu 12.04
Linking to static libboost_thread, libboost_system (1.50.0 release config)
Does not matter if server code is listening or not.

Minimal reproducible code below:

int main(int argc, char *argv[])
{
    boost::asio::io_service service;

    using namespace boost::asio::ip;

    tcp::resolver resolver(service);
    tcp::resolver::query query(tcp::v4(), ""127.0.0.1"", ""50001"");
    tcp::resolver::iterator itr = resolver.resolve(query);

    if (itr != tcp::resolver::iterator())
    {
        tcp::socket s(service);
        boost::asio::connect(s, itr); // Segmentation Fault Here
    }
}

Callstack:

#0 0x8054d6e	boost::asio::detail::reactive_socket_service_base::close(this=0x16, impl=..., ec=...) (reactive_socket_service_base.ipp:103)
#1 0x8058f1a	boost::asio::stream_socket_service<boost::asio::ip::tcp>::close(this=0x2, impl=..., ec=...) (stream_socket_service.hpp:151)
#2 0x80589d5	boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::close(this=0xbffff318, ec=...) (basic_socket.hpp:339)
#3 0x8058186	boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp>, boost::asio::detail::default_connect_condition>(s=..., begin=..., end=..., connect_condition=..., ec=...) (connect.hpp:120)
#4 0x80578a5	boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp> >(s=..., begin=..., ec=...) (connect.hpp:56)
#5 0x8056dd2	boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp> >(s=..., begin=...) (connect.hpp:47)
#6 0x8052f41	main(argc=1, argv=0xbffff874) (main.cpp:27)

Thank you.",Alan Yuelkenbeck <ayuelkenbeck@…>
7274,svn server error 413,trac / subversion,Boost 1.52.0,To Be Determined,Bugs,Douglas Gregor,new,2012-08-24T12:10:40Z,2012-09-18T17:01:50Z,"Hi!

I cant preform svn update, on day old copy, without geting this error message:
svn: Server sent unexpected return value (413 Request Entity Too Large) in response to REPORT request for '/repository/!svn/vcc/default'

regard.bartus",bartus@…
7273,Files created by boost::iostreams::mapped_file have unexpected permissions on Linux,iostreams,Boost 1.51.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-08-24T11:35:40Z,2017-08-23T05:12:35Z,"The mapped_file class opens the file unconditionally via:
{{{
#!c++
::open(p.path.c_str(), flags, S_IRWXU);
}}}

Which sets the permissions to read, write, execute for the owner and no permissions for group or others.

This is quite unexpected, and since it cannot be changed by the caller, I think a more sane default behavior would be to just use the default of open and let the user's umask decide the permission of newly created files.

I.e. just remove the last parameter:
{{{
#!c++
::open(p.path.c_str(), flags);
}}}",Mika Fischer <mika.fischer@…>
7268,Invalid DST for Europe/Paris before 1996 (using tzdatabase),date_time,Boost 1.52.0,To Be Determined,Bugs,az_sw_dude,new,2012-08-23T09:34:24Z,2012-08-23T09:34:24Z,"Hello,

Let me start with an example :
For 1992, boost::datetime gives me (using the given timezone database) DST period from
1992-Mar-29 02:00:00 TO 1992-Oct-25 03:00:00

That's simply wrong. For 1996 and following years, it's correct, simply because, in 1996, France decided that DST occurs in the end of October. Before that date, it occured in the end of September.

Here is a table of true DST dates (dates are in European form, ""day/month"") :


{{{
1976 : 28/3 -- 26/9
1977 : 3/4 -- 5/9
1978 : 2/4 -- 1/10
1979 : 1/4 -- 30/9 

1980 : 6/4 -- 28/9 
1981 : 29/3 -- 27/9 
1982 : 28/3 -- 26/9 
1983 : 27/3 -- 25/9 
1984 : 25/3 -- 30/9 
1985 : 31/3 -- 29/9 
1986 : 30/3 -- 28/9 
1987 : 29/3 -- 27/9 
1988 : 27/3 -- 25/9 
1989 : 26/3 -- 24/9

1990 : 25/3 -- 30/9
1991 : 31/3 -- 29/9 
1992 : 29/3 -- 27/9 
1993 : 28/3 -- 26/9 
1994 : 27/3 -- 25/9
1995 : 26/3 -- 24/9 

================

1996 : 31/3 -- 27/10 
1997 : 30/3 -- 26/10 
1998 : 29/3 -- 25/10
1999 : 28/3 -- 31/10

2000 : 26/3 -- 29/10
2001 : 25/3 -- 28/10
2002 : 31/3 -- 27/10
2003 : 30/3 -- 26/10
2004 : 28/3 -- 31/10
2005 : 27/3 -- 30/10
2006 : 26/3 -- 29/10
2007 : 25/3 -- 28/10
2008 : 30/3 -- 26/10 
2009 : 29/3 -- 25/10 

2010 : 28/3 -- 24/10 
2011 : 27/3 -- 30/10
}}}

Thank you,
Guillaume",guillaume.v.sanchez@…
7266,Gettext path formats.,locale,Boost Development Trunk,Boost 1.54.0,Patches,Artyom Beilis,assigned,2012-08-23T05:47:10Z,2013-01-07T06:37:55Z,"{{{
I'm extremely happy about Boost.Locale, but I've found a few things
lacking. So at first I wrote a some wrappers to get around a few flaws
with my usage of Boost.Locale. One of these flaws was how it's hardcoded
to use the Gettext directory hierarchy.

I'd rather store my stuff in 'lang/en_US.mo' rather than
'lang/en_US/LC_MESSAGES/my_app.mo'.

The patch adds a 'path format' feature, which allows you to format the
directory structure when finding Gettext catalogs, to achieve the effect
above. All you really have to do is run:

   gen.add_path_format(""{1}/{2}.mo""); // Use a smaller hierarchy.

to achieve the result that I prefer, or

   gen.add_path_format(""{1}/{2}/{3}/{4}.mo""); // Use a Gettext hierarchy.

to achieve the result that Boost.Locale uses right now. Ripped straight
from Doxygen comments:

   {1} A path to search for catalogs in.
   {2} The locale's name.
   {3} The locale's category.
   {4} The Gettext domain.
}}}

I apologize for the cut and paste from it but I'm having trouble with trac.
The full thread with patches can be found at: http://lists.boost.org/Archives/boost/2012/08/195789.php",166291@…
7261,Boost.Units quantity output overflows ostream width field,units,Boost 1.52.0,To Be Determined,Bugs,Steven Watanabe,new,2012-08-22T16:38:37Z,2012-08-22T16:38:37Z,"Boost.Units quantity output overflows ostream width field

     quantity<length> ql = 2345.6 * meters;

     std::cout << std::setw(20) << ql << std::endl;

outputs 22 chars instead of 20 chars.

The reason is that the first item value() is output using the ios width setting, but the second
unit() 'm' (and separating space) is not.

if os.width() > 0 then a way is to build a single string of the quantity with the width specified for example using an ostringstream
(otherwise, outputing value and unit (perhaps autoprefixed to km)
severally would overflow the width).

(else if os.width() <= 0 then output directly to ostream os as at present).

A test and a patch to deal with this is attached.  

(This is not necessarily the most efficient way to deal with this but appears to work).",Paul A. Bristow
7260,Header order conflicts between Thread and ASIO,asio,Boost 1.51.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-08-22T04:49:48Z,2012-09-18T17:20:52Z,"This problem is still present as of 1.50.  Link to discussion: http://lists.boost.org/boost-users/2012/06/74823.php

Consider this following simple app:


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

#include <boost/asio.hpp>

#include <boost/thread/recursive_mutex.hpp>

 

 

int main() {

 

                return 0;

}
}}}


 

If you try to build that on Windows, you receive the following error:


{{{
In file included from c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/recursive_mutex.hpp:14:0,

                 from c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/recursive_mutex.hpp:14,

                 from build.cpp:3:

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'void boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::lock()':

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:52:21: error: '_InterlockedExchange' is not a member of 'boost::detail'

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'void boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::unlock()':

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:71:21: error: '_InterlockedExchange' is not a member of 'boost::detail'

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::try_basic_lock(long int)':

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:91:21: error: '_InterlockedExchange' is not a member of 'boost::detail'

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::try_timed_lock(long int, const boost::system_time&)':

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:102:21: error: '_InterlockedExchange' is not a member of 'boost::detail'
}}}


If asio.hpp is moved ahead of the thread headers, the error goes away.  We’ve been trying to dictate #include order to work around this problem, but it keeps cropping up.",joshuadavidson@…
7258,boost::filesystem::create_directories(const &path) returns false if the path contains a slash at the end of the string,filesystem,Boost 1.59.0,To Be Determined,Bugs,Beman Dawes,reopened,2012-08-21T15:19:15Z,2017-01-02T08:39:12Z,"for example, if we want to create that following directory: path=""C:/users/test/""

the function create_directories(path) returns false even if the directory is created and exists.

However, if we remove the slash at the end of the string path=""C:/users/test"", the function returns true.

Is it the normal behavior of that function?

Thanks.",francis.thibault@…
7256,wrong error message for program options with dashes,program_options,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-21T13:01:49Z,2014-01-19T17:52:14Z,"Hi,
I defined some options:

{{{
optionsDescription.add_options()
     ....
    (""output-file,o"", program_options::value<std::string>(), ""Result file"")
     ....;
}}}

Now, when I start my program without an argument (e.g. ./myprog -o) the error message says:

the required argument for option '--file' is missing

instead of

the required argument for option '--output-file' is missing

This worked at least with version 1.48.",thomas.zuhl@…
7253,[Boost.Build] Escape command line properly when calling assembler on MSVC,build,Boost 1.53.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-21T07:28:11Z,2013-02-08T07:48:57Z,"Hi.

As of Boost.Context release (since Boost 1.51.0) assembler related build rules are actually used. However, currently these make no attempt whatsoever to properly escape the command line arguments (mostly global defines, that may have characters such as ""<"" and "">"" that are interpreted by command prompt, not good).

The following patch proxies command line arguments thru a RSP file, as done with C/C++ compiling/build rules.

The patch does
	a) Add an ASM_RSPLINE under rule get-rspline,

	b) Add a rule compile.asm that calls get-rspline and compile-asm,

	c) Move the actual assembler call under actions compile-asm, that uses the generated ASM_RSPLINE,

	d) Remove toolset.flags msvc.compile.asm DEFINES as these are now inherited from toolset.flags msvc.compile DEFINES.


That should fix it once and for all.",Pekka Seppänen <pekka.seppanen@…>
7252,bootstrap.sh only works if called as ./bootstrap.sh,Building Boost,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-21T00:23:56Z,2013-10-24T22:19:08Z,"Sometimes we need to be able to call bootstrap.sh from outside the Boost root directory. The following tiny patch allows the bootstrap.sh script to be called from anywhere:

Replace the line 184:

my_dir="".""

by

my_dir=""${0%/bootstrap.sh}""",Júlio Hoffimann <julio.hoffimann@…>
7250,rational.hpp imports header iostream even if stream operators are not needed,rational,Boost 1.51.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-08-19T11:21:21Z,2013-08-28T07:12:49Z,"Many Boost libraries have header variants with and without iostream support:

{{{
#include ""boost/date_time/posix_time/posix_time.hpp"" //include all types plus i/o
}}}
or
{{{
#include ""boost/date_time/posix_time/posix_time_types.hpp"" //no i/o just types
}}}

Likewise, there exists a macro BOOST_NO_IOSTREAM, which should prevent <iostream> from being included, see ticket #4060.

Neither approaches are available in boost::rational<> but either could be put to good use.",Levente Hunyadi <levente@…>
7249,tools/build/v2/test/startup_v2.py fails if boost-build is already installed,build,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-19T09:56:23Z,2012-08-19T09:56:23Z,"I got the following error after I installed boost-build and tried to rerun the tests in temporary build directory:

startup_v2                :  DIFFERENCE
--- /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmp7UjRdwexpected	2012-08-19 11:44:11.236819301 +0200
+++ /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmpA2P_sAactual	2012-08-19 11:44:11.236819301 +0200
@@ -1,2 +1,3 @@
-Unable to load Boost\.Build: could not find ""boost-build.jam""
-.*Attempted search from .* up to the root
\ No newline at end of file
+
+error: error: no Jamfile in current directory found, and no target references specified.
+
Unable to compute difference: diff -u /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmp7UjRdwexpected /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmpA2P_sAactual
FAILED

Reason is: passing the empty string to bjam lets it fallback to the default which is not what is wanted in that test. Attached patch changes the path to something invalid.",dev-zero@…
7247,Expose empty_arg_list to public interface,parameter,Boost 1.51.0,To Be Determined,Feature Requests,Daniel Wallin,new,2012-08-18T17:14:03Z,2016-02-23T10:48:56Z,"The empty_arg_list is defined in the parameter::aux namespace which indicates that this class is not intended to be used by users. However, in generic code it is often useful to be able to pass empty parameter packs to functions when all arguments are optional. Please, make the empty_arg_list class public.
",Andrey Semashev
7240,serialization backward compatibility issue with class_id_type attribute,serialization,Boost 1.50.0,To Be Determined,Patches,Robert Ramey,new,2012-08-16T10:42:29Z,2013-11-20T16:50:17Z,"There is a backward compatibility issue in current boost::serialization around the class_id_type attribute.

It is actually impossible to read binary archives written with boost 1.39 (format 5) with a boost release > 1.43.

For instance, with boost 1.47.0 :

test_serialization: /home/ggagniard/dev/boost-1.47.0.bug/include/boost/archive/basic_archive.hpp:116: boost::archive::class_id_type::class_id_type(int): Assertion `t_ <= boost::integer_traits<base_type>::const_max' failed.

Please note that the same error still occurs with boost 1.50.0, the current stable release.

After having a look at the class_id_type serialization in binary archives, I think I found the culprit :

In boost/archive/basic_binary_iarchive.hpp :

{{{
    void load_override(class_id_type & t, int version){
        library_version_type lvt = this->get_library_version();
        if(boost::archive::library_version_type(7) < lvt){
            this->detail_common_iarchive::load_override(t, version);
        }
        else
        if(boost::archive::library_version_type(6) < lvt){
            int_least16_t x=0;
            * this->This() >> x;
            t = boost::archive::class_id_type(x);
        }
        else{
            int x=0;
            * this->This() >> x;
            t = boost::archive::class_id_type(x);
        }
    }
}}}

Here, archives whose version <= 6 get their class_id_type read as an int ...

However, in boost 1.43 (format 7) :

{{{
    void load_override(class_id_type & t, int){
        // upto 32K classes
        int_least16_t x=0;
        * this->This() >> x;
        t = class_id_type(x);
    }
}}}

It is clear than any library version <= 7 have their class_id_type serialized as a int_least16_t, so the current load_override method is incorrect for versions <= 6 ...",ggagniard@…
7235,mapped_region not accepting size = 0,interprocess,Boost 1.50.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-08-15T19:34:47Z,2012-08-15T21:18:01Z,"Since Linux 2.6.12, and on other platforms, mmap is supposed to fail if the specified ""size"" parameter is 0. This causes some problems in all the Boost.Interprocess library since pretty much all the high-level structures (managed_shared_memory, for instance) use mapped_region (thus mmap) with size = 0, usually when the object is created with the ""open_only"" flag.

I have observed this bug on BlueGene/P's CNK environment, with gcc 4.1.2. It seems logical to me that, when opening an existing shared structure, the size doesn't have to be known. I don't have any solution yet...",matthieu.dorier@…
7225,"xpressvie Symbol Tables,I want get mapped value by iterator ,not by semantic action",xpressive,Boost 1.51.0,To Be Determined,Feature Requests,Eric Niebler,new,2012-08-13T13:01:43Z,2012-08-13T13:22:35Z,"std::map< std::string, string> ones_map = map_list_of(""one"",""1"")(""two"",""2"");
std::string str( ""one two three"");
for(sregex_token_iterator cur( str.begin(), str.end(), number_rx );
 ; cur != sregex_token_iterator(); ++cur )
    {
            std::cout << *cur << ' ';'''//will print 1 2'''
    }
or 
str = regex_replace( str, ones_map, ""$1"");
'''can get ""1 2""'''
or, has existed an easy way?
thank you!",taodm@…
7224,Fix endian.hpp and Filesystem on Android,filesystem,Boost Development Trunk,To Be Determined,Patches,Beman Dawes,new,2012-08-13T10:14:40Z,2012-11-20T19:10:09Z,"The attached patch allows to compile most of Boost for Android. Two changes are required:

1) Tell boost/detail/endian.hpp that Android has <endian.h>
2) Android doesn't have statvfs, so make libs/filesystem/src/operations.cpp use statfs instead.
",roman.donchenko@…
7219,"boost::optional<int> gives strict alias warning on GCC 4.4.6, breaks at runtime",optional,Boost 1.51.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-08-09T19:26:20Z,2013-06-09T19:42:53Z,"Here is my test code:


{{{
#include <boost/optional.hpp>

struct my_type
{
#if 1 // change to 0 to see the problem disappear
    typedef boost::optional<int> value_type;
#else
    typedef boost::optional<int __attribute((__may_alias__))> value_type;
#endif

    value_type value_;

    void set (int value)
    {
        value_ = value;
    }
                
    value_type get ()
    {
        return value_;
    }

}; // class event

void testCase ()
{
    my_type a;
    a.set(4);
    bool const b = 4 == ( *a.get() );
    if( !b ) abort(); // will abort unless 'may_alias' attribute is added to 'int'
}

}}}

Here is my compile line:


{{{
g++ -c src/thread/unittest/test_gcc_bug.cpp -o ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.o -MD -MF ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.d -MP -MT ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.o -I../../../src/include -I../../../derived/glnxa64/src/include -I../include -I../../include -I//mathworks/hub/3rdparty/R2013a/356881/glnxa64/boost/include -I//mathworks/hub/3rdparty/R2013a/356141/glnxa64/cpp11compat/include -I//mathworks/hub/3rdparty/R2013a/356141/glnxa64/cpp11compat/include -I//mathworks/hub/3rdparty/R2013a/350182/glnxa64/protobuf/include -I//mathworks/hub/3rdparty/R2013a/350182/glnxa64/tbb/include   -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_ASIO_DISABLE_EVENTFD -DBOOST_ASIO_DISABLE_EPOLL    -DTBB_AVAILABLE -O2 -pipe -pthread -fPIC -std=c++98 -fvisibility=hidden -g -D_POSIX_C_SOURCE=199506L -fno-omit-frame-pointer -DNDEBUG -W -Wcast-align -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wno-unused -Woverloaded-virtual -Wnon-virtual-dtor -Wno-ignored-qualifiers
}}}


I was also able to work around it by changing the return type of certain optional_base<T> methods (i.e. get_impl()) to 'T __attribute__((__may_alias__))&' (or whatever the analogous pointer or reference type is).
",Tony.Astolfi@…
7216,qcc.jam file could use a minor update for ar,build,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-08-09T15:53:03Z,2013-01-03T16:58:14Z,"The qcc.jam file is apparently intended for building on a QNX OS hosted target.  It is common for the QNX source to be cross compiled on MS Windows and the default archive utility is not available.  Would you please add a comment and alternate solution around line 220 like the following.  This would probably save new Boost users from having to track down a solution to this in the future.

#  Modify archive command for cross-compiling for QNX NTO using a MS Windows hosted environment (x86 target used as example).
#    ntox86-ar rc ""$(<)"" ""$(>)""",steve.lemay@…
7211,path_locale destructor crashes when overloaded operator new and delete are present,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-08-08T20:27:50Z,2012-08-09T15:02:57Z,"path_locale is defined using this construct in path.cpp:

std::locale path_locale(std::locale(), new windows_file_codecvt); 

Under the debugger of VC10/11, the destructor of std::locale calls free() for this facet pointer when refcount reaches 0.

I ackknowledge this is a bug in dinkumware implementation of the microsoft STL.  See for mor information: 

http://connect.microsoft.com/VisualStudio/feedback/details/750951/std-locale-implementation-in-crt-assumes-all-facets-to-be-allocated-on-crt-heap-and-crashes-in-destructor-in-debug-mode-if-a-facet-was-allocated-by-a-custom-allocator

That said, I suggest a workaround made using only standard calls.

in v3/src/windows_file_codecvt.hpp, change the constructor to pass along default refcount:

   explicit windows_file_codecvt(size_t refs = 0)
        : std::codecvt<wchar_t, char, std::mbstate_t>(refs) {}

and in v3/src/path.cpp, define path_locale like this:


  windows_file_codecvt windows_cvt_path_locale(1);

  std::locale path_locale(std::locale(), &windows_cvt_path_locale); 

",Michel Lemay <flaming_mike_@…>
7202,filesystem: Function remove_all_aux() with an argument of type system::error_code& can throw exception in case of filesystem error,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2012-08-07T14:11:02Z,2012-08-07T14:11:02Z,"Function remove_all_aux() calls non-exception safe fs::directory_iterator constructor (without argument of system::error_code& type).

For example, in case of free file descriptors lack in filesystem this constructor can throw an exception ""Too many open files"".

The better way is to use exception-safe overload of fs::directory_iterator constructor (with argument of system::error_code& type).

Possible fix is in attachment.

The issue is actual for any version from 1.47 to 1.50",batsun@…
7199,Lazy at_key for phoenix,phoenix,Boost 1.51.0,To Be Determined,Feature Requests,Thomas Heller,new,2012-08-07T00:41:05Z,2012-08-07T01:58:18Z,"Teleported from [http://boost.2283326.n4.nabble.com/Lazy-at-key-for-phoenix-2-td3746575.html spirit-general aug 2011]:

> I needed a lazy version of at_key to deal with fusion associative 
> sequences in semantic actions. The simple diff attached is based on the 
> phoenix at.hpp file. There is also a small test program attached. 
> 
> Maybe ""we"" can add it to the Spirit 2 trunk? 
>
> Thanks - michael ",Sehe <bugs@…>
7197,Access regex_id from semantic action,xpressive,Boost 1.51.0,To Be Determined,Feature Requests,Eric Niebler,new,2012-08-06T08:38:17Z,2012-08-06T08:38:17Z,"It would be useful to be able to access from a semantic action the regex_id of the regex to which the semantic action belongs.

I propose a special symbol named _regex_id_ for this purpose.

Examples:


{{{
sregex rx = xpr[cout << _regex_id_];
regex_match(str, rx);  // prints rx.regex_id() on success
}}}



{{{
sregex sub = xpr[cout << _regex_id_];
sregex rx = sub >> another_xpr;
regex_match(str, rx);  // prints sub.regex_id() on success (not rx.regex_id())
}}}
",zeratul976@…
7193,vacpp.jam improvements,build,Boost 1.51.0,To Be Determined,Patches,Vladimir Prus,new,2012-08-03T20:02:50Z,2012-08-03T20:02:50Z,"* Common up Linux linking with `gcc.jam`.
* Make use of `$(CONFIG_COMMAND)` instead of hard-coded names.
* Define inlining options.
* Set `-bmaxdata` for 32-bit on AIX.
",Hubert Tong <hstong@…>
7192,[mpl] std::integral_constant support,mpl,Boost 1.51.0,Boost 1.52.0,Feature Requests,Aleksey Gurtovoy,new,2012-08-02T21:48:07Z,2012-08-05T17:13:28Z,"The following reasonable-seeming use of mpl::plus doesn't compile:

{{{
    #include <utility>
    #include <boost/mpl/plus.hpp>

    typedef std::integral_constant<int, 1> one;
    typedef boost::mpl::plus<one, one>::type two;
}}}

That's because mpl only works with its own integral constant wrappers,
not the standard one. That seems unfortunate to me. Is there any
interest in supporting this?

Here's the error (from clang trunk with glibc++):

{{{
    1>  In file included from main.cpp:2:
    1>  In file included from
/home/Eric/boost/org/trunk/boost/mpl/plus.hpp:19:
    1>  In file included from
/home/Eric/boost/org/trunk/boost/mpl/aux_/arithmetic_op.hpp:34:
    1>  In file included from
/home/Eric/boost/org/trunk/boost/mpl/aux_/include_preprocessed.hpp:37:
    1>
/home/Eric/boost/org/trunk/boost/mpl/aux_/preprocessed/gcc/plus.hpp:60:25:
error: no type named 'tag' in 'std::integral_constant<int, 1>'
    1>      typedef typename T::tag type;
    1>              ~~~~~~~~~~~~^~~
    1>
/home/Eric/boost/org/trunk/boost/mpl/aux_/preprocessed/gcc/plus.hpp:111:20:
note: in instantiation of template class
'boost::mpl::plus_tag<std::integral_constant<int, 1> >' requested here
    1>            typename plus_tag<N1>::type
    1>                     ^
}}}
",Eric Niebler
7190,Allow multiple long synonyms for same option,program_options,Boost 1.50.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-08-01T20:37:02Z,2012-08-01T20:37:02Z,"The comma syntax ""blargh,b"" works for a single-character option synonym, but if I want multiple long names for the same option (e.g. for backwards compatibility) I see no way to do that, especially when defaults come into play.",chip@…
7187,boost::rational doesn't provide stream operators for wide streams,rational,Boost 1.51.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-08-01T09:29:00Z,2013-08-30T00:22:02Z,"There are `std::istream& operator>> (std::istream& is, rational<IntType>& r)` and `std::ostream& operator<< (std::ostream& os, const rational<IntType>& r)`, but no wide stream versions.",Mathias Hasselmann <mathias@…>
7186,BOOST_BIND_ENABLE_STDCALL causes bind compilation to fail on x64,bind,Boost 1.51.0,To Be Determined,Feature Requests,Peter Dimov,new,2012-07-31T17:08:12Z,2012-08-15T19:39:48Z,"On Win32, in order to use WINAPI ( =  !__stdcall) functions with boost, developers must define BOOST_BIND_ENABLE_STDCALL before including bind.hpp

On Win64 however, !__stdcall and !__cdecl are equivalent. When the macro BOOST_BIND_ENABLE_STDCALL is defined, bind.hpp fails compilation for multiply defined functions.

This request is that the macro BOOST_BIND_ENABLE_STDCALL will only be effective is possible. ",mitmit@…
7184,atomic_cas32() uses Linux-only compiler intrinsic,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-07-30T15:36:39Z,2012-07-30T15:36:39Z,"atomic_cas32() incorrectly assumes _sync_val_compare_and_swap() intrinsic is available on any host OS using GCC4.1+ when, as of GCC4.4, it is only available on Linux.  This renders it unportable.

Problem was observed on QNX Neutrino 6.5.0.",jbaker@…
7179,boost:::iostream::inverse doesn't work with char_type other then char,iostreams,Boost 1.51.0,To Be Determined,Patches,Jonathan Turkanis,new,2012-07-26T13:37:25Z,2012-07-26T13:37:25Z,"See file \boost\iostreams\invert.hpp

This lines


{{{
std::streamsize read(Source& src, char* s, std::streamsize n)
...
std::streamsize write(Sink& dest, const char* s, std::streamsize n)
}}}


should be changed with:


{{{
std::streamsize read(Source& src, char_type* s, std::streamsize n)
...
std::streamsize write(Sink& dest, const char_type* s, std::streamsize n)
}}}


for appropriate handling of unsigned char, for example.

",mexal@…
7178,[mc] Message compiler toolset broken,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2012-07-26T12:28:59Z,2012-07-26T12:28:59Z,"For some reason, the resource compiler no longer waits for the message compiler output. This results in compilation failures like this:

{{{
msvc.compile.mc bin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi\simple_event_log.h
MC: Compiling libs\log\src\simple_event_log.mc
...skipped <pbin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi>simple_event_log_res.obj for lack of <pbin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi-object(res-scanner)@4128>simple_event_log.rc...
}}}

This is a partial compilation log from [http://sourceforge.net/projects/boost-log/ Boost.Log] project. You can check out trunk or branches/v1 for testing.

After the (unsuccessful) compilation I can see simple_event_log.rc, simple_event_log.h and MSG00001.bin files in the output directory, so the problem is probably caused by resource compiler being invoked too soon.

The Boost.Log Jamfile was not changed for a long time with respect to the .mc compilation, an it worked some time ago. Unfortunately, I cannot tell when it stopped working.
",Andrey Semashev
7176,Infinite loop in regex.replace rule.,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2012-07-26T07:50:06Z,2012-07-26T07:50:06Z,"regex.replace falls into infinite ""while $(parts)"" loop if ""match"" parameter is empty string. Example:

import regex ;

str = blabla ;
from = """" ;
to = "":"" ;
res = [ regex.replace $(str) $(from) $(to) ] ;
ECHO res: ;
ECHO $(res) ;
",Dmitriy Kinoshenko <dvb.kharkov@…>
7160,BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG and DATE_TIME_NO_DEFAULT_CONSTRUCTOR,date_time,Boost 1.47.0,To Be Determined,Bugs,az_sw_dude,new,2012-07-23T14:31:00Z,2012-11-17T16:00:00Z,"I think I found a couple issues that are somewhat related to one another:

'''Issue 1 - Defining BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG and using the ptime default constructor along with a thread causes runtime crash''' 

Steps to reproduce:
1. Define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG (to use nanosecond resolution in a posix_time) in the pre-processor definitions (VS2008).
2. Create a boost::posix_time::ptime using the default constructor.
3. Create a boost::thread and call join.
Example:
{{{
#include <iostream>
#include <boost/thread.hpp>

class ThreadClass
{
   public:
	ThreadClass()
	{
	}

	void operator()()
	{
	   return;
	}
};


int main()
{
	boost::posix_time::ptime currentTimeUTC;

	ThreadClass tc;
	boost::thread t(tc);
	t.join(); //causes a runtime access violation here

	std::cout << ""done"" << std::endl;
	system(""pause"");

	return 0;
}
}}}

'''Issue 2 - defining DATE_TIME_NO_DEFAULT_CONSTRUCTOR causes compile-time error ""no appropriate default constructor available""'''

In Issue 1 above, if you do not use a default constructor for a ptime, it seems to fix the issue. So I figured that was fine and I could prevent a user of my library from using that default constructor by defining DATE_TIME_NO_DEFAULT_CONSTRUCTOR. However, this now breaks at compile time:

Steps to reproduce:
1. Use the same code as above, just for ease of use.
2. Define the pre-processor definition: DATE_TIME_NO_DEFAULT_CONSTRUCTOR.
3. Compile the program.
4. The following error is produced: error C2512: 'boost::posix_time::ptime' : no appropriate default constructor available e:\libraries\boost\boost_1_47\boost\thread\win32\thread_data.hpp	145

The issue, I believe, is that I am using a boost thread, which uses a ptime default constructor in its ''explicit timeout(sentinal_type)'' constructor when it doesn't set the ''abs_time'' member variable.


I am using Boost 1.47, however looking at the latest boost code (1.51), I don't see any fixes for these issues that stand out (I am not able to try the latest versions of Boost, so I apologize if they are fixed, but I would think that they are not)",Ricky Stoneback <rwstoneback@…>
7153,it is not possible to add methods in enum_ using def,python USE GITHUB,Boost 1.51.0,To Be Determined,Feature Requests,Ralf W. Grosse-Kunstleve,new,2012-07-20T08:36:16Z,2012-07-21T21:19:11Z,"Sometimes it is required to add method to exported enum to Python using Boost.Python. For example, if we want to specify __repr__ method to enum. But the following code wont work.

enum_<my_enum>(""my_enum"")
            .def(""__repr__"", &my_enum_to_string)
            ;
",tokiloki7@…
7149,system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used,system,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,reopened,2012-07-18T20:51:04Z,2012-10-29T02:12:51Z,"This no longer compiles on mac osx GCC 4 with BOOST_NO_EXCEPTIONS defined but without -fno-exceptions. BOOST_NO_EXCEPTIONS can be used to simply disable exception handling in boost not necessarily to flag that exception handling is disabled at the compiler level:

http://www.boost.org/doc/libs/1_36_0/libs/utility/throw_exception.html

BOOST_NO_EXCEPTION can be used to supply a custom exception handler.

Wrapping the try block on line 136 on system/error_code.cpp with #ifndef BOOST_NO_EXCEPTIONS fixes this.

See ticket #2098",joeriedel@…
7147,Pool in more depth documentation page has broken image links,pool,Boost 1.50.0,To Be Determined,Bugs,Chris Newbold,new,2012-07-18T16:05:47Z,2012-07-18T16:05:47Z,"If you navigate via browser to 

http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/html/boost_pool/pool/pooling.html

You will see several broken links to images, such as 

http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/images/pc1.png

The directory http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/images/ is readable, and appears to contain the right files, but with differently-cased names (e.g. pc1.PNG). 

I tried this with both Internet Explorer on Windows, and Chrome on Mac and Windows.",scott@…
7145,rational.hpp - Avoid repeated construction,rational,Boost 1.51.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-07-18T13:38:52Z,2013-08-20T11:30:43Z,"In rational.hpp, two times 'IntType zero(0);' is used to
""Avoid repeated construction"" and two times 'int_type const  zero( 0 );'
is used. The two without the const may not be avoiding repeated construction. Since int_type is just a typedef from IntType, it
might be clearer if all int_type were replaced with IntType and the
typedef for int_type removed.",Dan Searles <dansearles@…>
7138,Output of a UDT with autoprefix  requires specialization of auto_prefix_norm,units,Boost 1.51.0,Boost 1.51.0,Bugs,Steven Watanabe,new,2012-07-16T08:42:29Z,2012-07-16T08:42:29Z,"Output of a UDT with autoprefix  requires specialization of auto_prefix_norm for the scaling to take place.  For example, to get expected scaling to kilometers from

quantity<length, measurement<double> > 
biglen(measurement<double>(12345.0,123.0)*meters); autoscaled = 12.345(+/-0.123) km

This can be achieved by adding this to measurement.hpp (where Y is the type of UDT)


{{{
// Specialization of autoprefix_norm for UDTboost::units::measurement<Y>
// See io.hpp.
// This specialization is required to get autoprefix to work with this class.

template<class Y>
typename autoprefix_norm_impl<boost::units::measurement<Y>, true>::type
autoprefix_norm(const boost::units::measurement<Y> & arg)
{
  return autoprefix_norm_impl<Y, true>::call(arg);
}
}}}
However this assumes that the class Y is convertible to double.
autoprefix_norm_impl<T, true>::type appears to be always double.
I am unclear if this is checked or is the responsibility or the user?
",Paul A. Bristow
7126,function is_separator and boost::filesystem::slash<boost::filesystem::path>::value move to main hpp file,filesystem,Boost 1.51.0,To Be Determined,Bugs,Beman Dawes,new,2012-07-13T07:05:37Z,2012-08-15T19:43:34Z,"Please add support get native path separator in main path.hpp header file, because  this function now is inaccesible, and error appears (#   error Compiling Filesystem version 2 file with BOOST_FILESYSTEM_VERSION defined != 2), this reprodused on boost 1.47 version",topilski@…
7125,weak_ptr::lock() thread safety,smart_ptr,Boost 1.50.0,To Be Determined,Feature Requests,Peter Dimov,new,2012-07-12T11:13:40Z,2012-07-12T11:13:40Z,"Imagine the following code:

{{{
shared_ptr<T> sp(new ...);
weak_ptr<T> wp(sp);

sp.reset(); // thread A
shared_ptr<T> sp1 = wp.lock(); // thread B
}}}

It is not clear from documentation, whether it is safe to call shared_ptr::reset() and weak_ptr::lock() concurrently in different threads. It is very frequently asked question and should be documented explicitly.
",Gennady  Proskurin <gpr@…>
7119,[proto] implement an implicit conversion function for expressions,proto,Boost Development Trunk,To Be Determined,Feature Requests,Eric Niebler,new,2012-07-11T18:43:33Z,2012-07-11T18:43:33Z,Revive the old proto::implicit_expr functionality to allow readable expressions to be returned from functions.,Eric Niebler
7118,Condition.Wait with a mutex instead of lock can be mysterious,interprocess,Boost 1.51.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-07-11T16:39:54Z,2012-07-11T16:39:54Z,"This code correctly fails to compile:
#include <boost/interprocess/sync/named_condition.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>


int _tmain(int argc, _TCHAR* argv[])
{
	boost::interprocess::named_mutex mutex( boost::interprocess::open_or_create, ""test"" );
	boost::interprocess::named_condition condition( boost::interprocess::open_or_create, ""test"" );
	condition.wait( mutex );
	return 0;
}

The resulting compile error (at least on VC++ 2010) is a tad mysterious:

1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2248: 'boost::interprocess::interprocess_mutex::mutex' : cannot access private member declared in class 'boost::interprocess::interprocess_mutex'
1>          c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(117) : see declaration of 'boost::interprocess::interprocess_mutex::mutex'
1>          c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(67) : see declaration of 'boost::interprocess::interprocess_mutex'
1>          c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204) : while compiling class template member function 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex_type *boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex(void) const'
1>          with
1>          [
1>              Lock=boost::interprocess::named_mutex
1>          ]
1>          c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(342) : see reference to class template instantiation 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>' being compiled
1>          with
1>          [
1>              Lock=boost::interprocess::named_mutex
1>          ]
1>          c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\named_condition.hpp(156) : see reference to function template instantiation 'void boost::interprocess::ipcdetail::shm_named_condition::wait<L>(L &)' being compiled
1>          with
1>          [
1>              L=boost::interprocess::named_mutex
1>          ]
1>          c:\code\projects\testinterprocess\testinterprocess\testinterprocess.cpp(10) : see reference to function template instantiation 'void boost::interprocess::named_condition::wait<boost::interprocess::named_mutex>(L &)' being compiled
1>          with
1>          [
1>              L=boost::interprocess::named_mutex
1>          ]
1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2064: term does not evaluate to a function taking 0 arguments

It is not obvious that the problem involves the use of a Mutex instead of a ScopedLock or the like.  While the example code makes this clear, if you examine only the documentation, this detail might be confusing.

Recommend adding a concept check to help guide someone towards using a lock instead of a mutex.",Trey Van Riper <fleeb.fantastique@…>
7107,Support property bundles as default parameter in graph algorithms,graph,Boost 1.51.0,To Be Determined,Feature Requests,Jeremiah Willcock,new,2012-07-09T16:07:09Z,2012-07-09T16:07:09Z,"Bundled properties don't support default parameters as internal properties do. Adding a possibility to tag members of a bundle would solve that issue. 


{{{
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/properties.hpp>
#include <boost/graph/dijkstra_shortest_paths.hpp>
#include <string>

using namespace std;
using namespace boost;

struct City{};

struct Highway { double weight; };

typedef adjacency_list<
    listS, vecS, bidirectionalS,
    City, Highway>
Map;

typedef adjacency_list < 
  listS, vecS, directedS,
  no_property, property < edge_weight_t, int > > 
Map2;

int main()
{
  Map m;
  Map2 m2;
  vector<double> distances(num_vertices(m2));
  dijkstra_shortest_paths(
    m2, *vertices(m2).first,
    distance_map(make_iterator_property_map(distances.begin(),
                                                   get(vertex_index, m2))));
  // does not work
  // dijkstra_shortest_paths(
  //   m, *vertices(m).first,
  //   boost::distance_map(make_iterator_property_map(distances.begin(),
  //                                                  get(vertex_index, m))));

  return 0;
}
}}}

One solution could be to add an optional tags typedef that contains an mpl::map between member pointers and property enum types. Alternatively, a traits class could be specified to map to the right enum type. Maybe someone can also come up with a nice mechanism to transparently tag a member.",philipp.moeller@…
7106,multi_array::resize switches to default-constructed allocator,multi_array,Boost Development Trunk,To Be Determined,Bugs,Ronald Garcia,new,2012-07-09T14:00:57Z,2012-07-09T14:00:57Z,"I've run into this with 1.46 but eyeballing the code on trunk it doesn't seem to have changed.

The implementation of `resize` starts like this:
{{{
    // build a multi_array with the specs given
    multi_array new_array(ranges,this->storage_order());
}}}
However, no allocator is passed to this constructor. If `*this` has a non-default allocator, then it will not get used to allocate the resized storage, and furthermore, the default allocator in new_array will get swapped in to `*this`, wiping out the custom allocator.

This can be fixed by changing this line to
{{{
    multi_array new_array(ranges,this->storage_order(),allocator_);
}}}

so that the new array uses the same allocator as the current one.

I'll attach a test case that demonstrates the issue by using an allocator class where instances are named and report the allocations they make (I'm using a more complex version of this to track memory usage, which is where I hit the bug). It currently reports
{{{
Allocated 17 bytes [name = vector]
Allocated 0 bytes [name = multi_array]
Allocated 15 bytes [name = default]
}}}
but with the fix applied it reports
{{{
Allocated 17 bytes [name = vector]
Allocated 0 bytes [name = multi_array]
Allocated 15 bytes [name = multi_array]
}}}

It is the final line where the resize is taking place.",bmerry@…
7102,typo in documantation of boost::program_options::basic_command_line_parser,program_options,Boost 1.51.0,To Be Determined,Bugs,Vladimir Prus,new,2012-07-08T12:03:09Z,2012-08-15T20:09:27Z,"Typo in ""creating overloads with a smaller '''nuber''' of parameters"".

http://www.boost.org/doc/libs/1_50_0/doc/html/boost/program_options/basic_command_line_parser.html",bnagaev@…
7101,b2 defines multiple isysroot on Mac OSX 10.6 when targeting SDK versions earlier than 10.6,build,Boost 1.50.0,To Be Determined,Bugs,Vladimir Prus,new,2012-07-08T08:57:53Z,2013-03-26T16:23:18Z,"Building Boost 1.50.0 on Mac OSX 10.6 included multiple SDK versions when targeting SDK versions 10.5 adn/or 10.4;

./b2 toolset=darwin link=static threading=multi stage --with-program_options architecture=combined macosx-version=10.5 macosx-version-min=10.5 -d3

produces

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -arch i386 -arch ppc  -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I""."" -c -o ""bin.v2/libs/program_options/build/darwin-4.2.1/release/architecture-combined/link-static/macosx-version-min-10.5/macosx-version-10.5/threading-multi/cmdline.o"" ""libs/program_options/src/cmdline.cpp""

and targeting 10.4 SDK

./b2 toolset=darwin link=static threading=multi stage --with-program_options architecture=combined macosx-version=10.4 macosx-version-min=10.4 -d3

produces

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.4 -arch i386 -arch ppc  -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I""."" -c -o ""bin.v2/libs/program_options/build/darwin-4.2.1/release/architecture-combined/link-static/macosx-version-min-10.4/macosx-version-10.4/threading-multi/cmdline.o"" ""libs/program_options/src/cmdline.cpp""

that is, {{{isysroot}}} is defined multiple times. That apparently causes the latest SDK to be used, which leads to linker errors when a project built against an earlier SDK tries to link Boost.

A quick workaround is to hide the later SDK from b2:
{{{
sudo mv /Developer/SDKs/MacOSX10.6.sdk /Developer/SDKs/bak.MacOSX10.6.sdk
}}}
then run b2 as usual, and finally revert the renaming of the SDK
{{{
sudo mv /Developer/SDKs/bak.MacOSX10.6.sdk /Developer/SDKs/MacOSX10.6.sdk
}}}

",mikko.vainio@…
7098,CRC: Initial values should not be reflected,crc,Boost Development Trunk,To Be Determined,Bugs,Daryle Walker,new,2012-07-06T10:58:47Z,2012-07-06T10:58:47Z,"The CRC classes have a parameter 'ReflectIn', which affects whether the message data is reflected. It also causes the initial remainder of the CRC to be reflected, and that's probably incorrect. This has likely remained undetected 'til now because all the included presets use bit-palindromic initial remainders.

LVM2 uses a non-palindromic initial remainder, so I've used its code for a test case. You can see that both LVM's calc_crc() and zlib's crc32() don't reflect the initial remainder. It's evident that boost's crc does, and that no obvious change in template parameters yields the same behaviour as LVM and zlib.

Tested in both clang++ 3.1 and g++ 4.2.",Dave Vasilevsky <dave@…>
7082,Add support for benchmarking,test,Boost 1.51.0,To Be Determined,Feature Requests,Gennadiy Rozental,new,2012-07-05T05:32:07Z,2012-07-31T15:38:08Z,"One useful thing with boost test would be to run the tests in a ""benchmarking mode"". The general idea is to be able to run many iterations of all tests to get an idea of their performance. I believe the following changes would be sufficient:

- BOOST_AUTO_TEST_CASE could have an additional optional parameter: number_of_iterations. This is set by the user manually. For example: BOOST_AUTO_TEST_CASE(my_test_case, 10000). If not passed in, it would default to 1.
- A new command line parameter would trigger benchmarking: say --benchmarking. When passed in, all tests would run number_of_ iterations times.
- the elapsed time for a test would then be the accumulated time taken by all iterations

This would be great for nightlies.

This issue was discussed a bit on the mailing-list on this thread:

http://lists.boost.org/boost-users/2011/01/65790.php",marco.craveiro@…
7080,make_constructor Does Not Initialize base_wrapper,python USE GITHUB,Boost 1.51.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-07-04T21:00:54Z,2013-03-01T15:41:34Z,"When binding a shared_ptr to Python, we're using a custom allocator defined using make_constructor:

{{{
class_< Controller, shared_ptr<Controller>, boost::noncopyable >(""Controller"", no_init)
            .def(""__init__"", boost::python::make_constructor(&Controller::make));
}}}

This works as expected except when classes are derived in Python.  In those cases, get_override does not work, since m_self is NULL.  If you use init<>() in the class_ constructor, instead of the make_constructor line, it works as expected.


The bug is that make_constructor does not initialize the base_wrapper.  I've tried a fix as follows, and it's now functional -- though I can't say if this is a good way to solve it.

{{{
+++ make_constructor.hpp
@@ -59,6 +59,7 @@
           void* memory = holder::allocate(this->m_self, offsetof(instance_t, storage), sizeof(holder));
           try {
               (new (memory) holder(x))->install(this->m_self);
+			  python::detail::initialize_wrapper(this->m_self, get_pointer(x));
           }
           catch(...) {
               holder::deallocate(this->m_self, memory);
}}}

It's also possible to fix this by partially specializing ""template <typename T> struct install_holder;"" before boost::python is included.",team@…
7076,A few trivial 64-bit warning fixes on Windows,filesystem,Boost 1.50.0,To Be Determined,Patches,Beman Dawes,new,2012-07-04T11:15:27Z,2012-07-04T11:15:27Z,"In case they are of any interest...

Regards

Luke Elliott.
",Luke Elliott <lukester_null@…>
7067,The same options in the different groups cause exception while parsing configuration file.,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-07-03T12:30:56Z,2012-07-03T14:01:03Z,"Preconditions:
There are two option descriptions defined, containing the same options. 
The options are stored in the configuration file and grouped by the group.  

Result: 
options_descriptions add method adds two groups  
parse method throws unknown option exception with cat1.op1


namespace po::boost::program_options;
void test()
{
po::options_description cat1(""cat1"");
cat1.add_options()
    (""op1"", po::value<std::string>(), ""op1"")
    (""op2"", po::value<std::string>(), ""op2"")
    (""op3"", po::value<std::string>(), ""op3"")
    (""op4"", po::value<std::string>(), ""op4"");
po::options_description cat2(""cat2"");
cat2.add_options()
    (""op1"", po::value<std::string>(), ""op1"")
    (""op2"", po::value<std::string>(), ""op2"")
    (""op3"", po::value<std::string>(), ""op3"")
    (""op4"", po::value<std::string>(), ""op4"");
po::options_description full(""full"");
full.add(cat1).add(cat2);

po::variables_map map;

boost::filesystem::path path(""option.ini"");

try
{
    po::store(po::parse_config_file<char>(""option.ini"", full), map); //exception is thrown ""Unknown option cat1.op1"" 
    po::notify(map);
}
catch(std::exception & ex)
{
    std::cout << ex.what() << std::endl; 
}

option.ini: 

[cat1]
   op1=v1
   op2=v2
   op3=v3
   op4=v4
[cat2]
   op1=v5
   op2=v6
   op3=v7
   op4=v8

",Grzegorz Andrejczuk <g.andrejczuk@…>
7064,hex() with flag for lowercase output,algorithm,Boost 1.51.0,To Be Determined,Feature Requests,Marshall Clow,new,2012-07-02T14:27:55Z,2016-01-31T09:15:17Z,Could you provide a paramter for hex() to indicate lowercase output is desired?,Olaf van der Spek <olafvdspek@…>
7063,try_unhex() that doesn't throw on bad input,algorithm,Boost 1.51.0,To Be Determined,Feature Requests,Marshall Clow,new,2012-07-02T14:26:46Z,2012-09-27T14:24:27Z,"Could you provide an unhex() variant that doesn't throw on bad input, but returns an error (non-false) instead?",Olaf van der Spek <olafvdspek@…>
7055,Boost build doesn't detect presence of ICU for regex,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-06-29T14:50:35Z,2012-07-08T17:59:29Z,"When building Boost against ICU (currently using version 4.4.2), Boost is not detecting the presence of ICU on multiple platforms (Linux/gcc 4.4.6, Macintosh/gcc 4.2.1, Windows/VS2008).

In order for Boost to detect ICU, I had to apply the attached patches.",Jonathan Jones <jonathan.jones@…>
7047,Deriving custom archive classes from boost::archive::text_oarchive_impl and boost::archive::text_iarchive_impl,serialization,Boost 1.48.0,To Be Determined,Bugs,Robert Ramey,new,2012-06-29T05:31:07Z,2013-08-24T14:09:23Z,"From here[http://stackoverflow.com/questions/10691911/deriving-custom-archive-classes-from-boostarchivetext-oarchive-impl-and-boos]

Summary:
After changing the base classes of my custom archives from binary_?archive_impl to text_?archive_impl, my custom archive classes are no longer ""found"" when the compiler is instantiating the serialize(...) methods in my other classes.

Background:
My application was successfully reading and writing files to disk using subclasses of binary_?archive_impl (the documentation and/or code comments recommend this over deriving from binary_?archive). I needed to switch from a binary file format to a text format, so I switched the base classes of my custom archives to text_?archive_impl. That's when everything blew up.

The problem:
My custom archive classes add functionality, including some additional methods which do not exist in their Boost base classes; these methods are called in the serialize(...) methods in many of my classes, and they were working fine. After changing the base classes from binary_?archive_impl to text_?archive_impl, I received compilation errors all over the place complaining that my custom methods do not exist in text_?archive. Well, that's obvious (!!!), but they do exist in my custom archives, and they were working just fine when I was using Boost's binary base classes. What's the deal?

What I found, and my temporary - but undesirable - solution:
After tearing my hair out and going around in circles for about a day, this is what I found...

1) Some time ago (Boost 1.34 I believe), the files ""binary_?archive.hpp"" were split up into ""binary_?archive_impl.hpp"" and ""binary_?archive.hpp"" (the latter #include the former). This was not done to ""text_?archive.hpp"". (As a result, I changed my application's #include lines from ""binary_?archive_impl.hpp"" to simply ""text_?archive.hpp"".)

2) If I split up ""text_?archive.hpp"" into two parts and #include only the ""..._impl.hpp"" headers, everything works. (But I really don't want to modify my Boost installation!)

3) Looking more closely at these headers and fiddling around a bit, I found that if I use the original, unmodified headers and comment out the line

BOOST_SERIALIZATION_REGISTER_ARCHIVE(boost::archive::text_oarchive)

(and likewise for text_iarchive), then everything works fine again. (By the way I have similar lines in my own archive code to ""register"" my custom archives.)",zachais.vawter@…
7028,NDEBUG should disable asserts even if BOOST_ENABLE_ASSERT_HANDLER is defined,utility,Boost Development Trunk,To Be Determined,Feature Requests,Peter Dimov,reopened,2012-06-26T11:25:00Z,2014-04-15T08:39:36Z,"I have some components that require the use of a specific assert handler.

Compiling those components in debug or release is something that should be fairly independent from the flags required to use my components.

Therefore it would be more practical for me if when both BOOST_ENABLE_ASSERT_HANDLER and NDEBUG are defined the assert handler is not called.",Mathias Gaunard
7027,interprocess: Message queue using Windows shared memory,interprocess,Boost 1.50.0,To Be Determined,Patches,Ion Gaztañaga,new,2012-06-26T11:01:58Z,2012-08-01T16:41:37Z,"`interprocess::message_queue` currently always uses the `shared_memory_object` implementation. However, on Windows it can be desireable to have a message queue backed by `windows_shared_memory` instead. These patches add support for this.

* The first patch generalizes `message_queue_t<>`; the message queue logic is moved into `message_queue_base_t<>`, and the actual storage backend handling is delegated to a derived class. `message_queue_t<>` is changed to be based on `message_queue_base_t<>` and to provide storage in a `shared_memory_object`.
* The second patch adds the `windows_message_queue<>` class which backs the storage with a `windows_shared_memory`. A variant of the message queue test is also added.",frank.richter@…
7026,"bjam: Use 64-bit MSVC tools on Win64, even in a 32-bit shell",build,Boost 1.50.0,To Be Determined,Patches,Vladimir Prus,new,2012-06-26T09:43:54Z,2012-06-26T11:15:16Z,"When building with `toolset=msvc address-model=64` in a 32-bit shell on Win64, the cross tools (32-bit targeting 64-bit) instead of the native 64-bit tools are used. The reason is the `PROCESSOR_ARCHITECTURE` env var pretending to be a 32-bit environment. However, on 64-bit Windows, the correct native value can be found in `PROCESSOR_ARCHITEW6432`.
The attached patch makes the logic to determine the tools to use respect that alternative variable.",frank.richter@…
7017,libs/pool/test/test_simple_seg_storage.cpp produces bus error on 64-bit Solaris SPARC architecture,pool,Boost Development Trunk,To Be Determined,Bugs,Chris Newbold,new,2012-06-22T18:48:14Z,2012-06-22T18:48:14Z,"main() in test_simple_seg_storage.cpp adds blocks with offsets of 0, 49 and 25.  This results in non-word aligned access and a bus error on the Sparc Solaris architecture for the latter two when built and run in 64-bit mode.  It looks like the offsets should have been 48 and 24 since the all three requested chunk sizes are 24.",Mike Liang <mtliang@…>
7015,boost::signals::connection with shared_ptr to connected signal,signals,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-06-22T15:27:26Z,2012-08-15T20:12:25Z,"If you create a connection with a shared_ptr that controls the lifespan of the signal an access violation occurs on disconnection if that is the last remaining reference to the object.

{{{
#!c++
class Child : public boost::signals::trackable
{
public:
    Child(){}

    virtual ~Child(){}

    void callback( int a, int b )
    {
        printf( ""Child::callback( %d, %d )\n"", a, b );
    }

    boost::signal<void(int)> mSignal;
};

int main(int argc, char* argv[])
{
    boost::shared_ptr<Child> c( new Child );
    boost::signals::connection con;
    con = c->mSignal.connect( boost::bind( &Child::callback, c, 1, _1 ) );
    c->mSignal( 5 );
    c.reset();

    // The connection is the only thing keeping it alive. When we disconnect
    // it will also destroy the signal. This causes a memory access violation
    // when the signal containing the list of connections gets deleted while
    // removing an item from that list.
    con.disconnect();
}
}}}

The fix is to prevent the slot from going out of scope during the act of disconnecting from the signal.
{{{
diff --git a/libs/signals/src/signal_base.cpp b/libs/signals/src/signal_base.cpp
index 759672d..918e811 100644
--- a/libs/signals/src/signal_base.cpp
+++ b/libs/signals/src/signal_base.cpp
@@ -143,8 +143,14 @@ namespace boost {
             self->flags.delayed_disconnect = true;
           }
           else {
             // Just remove the slot now, it's safe
+            // There is a chance that the binding has the last reference to
+            // the signal, and destroying it will destroy the signal. To prevent
+            // this from causing a problem keep a local copy of the binding
+            // during it's removal from the slot list.
+            boost::any keep_alive = (*slot)->second;
             self->slots_.erase(*slot);
+            return;
           }
         }
       }
}}}",Nick Mayer <nick.mayer@…>
7013,Serialization Versioning Broken,serialization,Boost 1.49.0,To Be Determined,Bugs,Robert Ramey,new,2012-06-22T15:04:59Z,2012-08-15T19:46:09Z,"Version numbers are set to random garbage numbers with or without using BOOST_CLASS_VERSION. Sample code attached, sample output with version 1.49.0 on RHEL5 is as follows:

{{{
<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes"" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature=""serialization::archive"" version=""9"">
<Nested class_id=""0"" tracking_level=""0"" version=""2057815296"">
        <c>99</c>
</Nested>
</boost_serialization>
}}}",shaderaider@…
7011,Toolset 'intel-darwin' fails as 'stdarg.h' can not be found,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-06-21T16:38:35Z,2013-01-03T18:42:31Z,"Building boost (1.49, and also 1.50 beta) using the 'intel-darwin' toolset currently fails on my system, showing errors such as:
{{{
compile.c(33): catastrophic error: cannot open source file ""stdarg.h""
  # include <stdarg.h>
                      ^
compilation aborted for compile.c (code 4)
}}}

I use the most recent versions of the required developer programs, ICC 12.1.4 and XCode 4.3.3. This appears to be a specific problem of Apple & Intel in case of 'stdarg.h', and the error can be replicated by compiling any C/C++ source file including that header. The problem is also described in Intel's support forum (http://software.intel.com/en-us/forums/showthread.php?t=69724).

Apparently, the problem can be fixed by adding at least one of the following compiler flags:
{{{
-dev-usr-root=/Applications/Xcode.app/Contents/Developer/usr
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
-gcc-name=gcc-4.2 -gxx-name=g++-4.2
}}}
Potentially, a call to `xcode-select -print-path` may be necessary to obtain the correct path. From my perspective, the first option in combination with `xcode-select` looks to be the most robust solution.

I am, unfortunately, a novice concerning bjam, and can thus not offer a real fix. I will be happy to help if a test run is required. Thank you for help!",vogel@…
7010,A few 32/64 bit warning fixes,serialization,Boost Development Trunk,To Be Determined,Bugs,Robert Ramey,new,2012-06-21T15:49:57Z,2012-07-15T19:51:49Z,"if of any interest. Mainly (only?) SunStudio, if memory serves.

Regards

Luke Elliott.
",Luke Elliott <lukester_null@…>
7006,Restricted pointers support.,range,Boost 1.50.0,To Be Determined,Feature Requests,Neil Groves,assigned,2012-06-21T10:11:48Z,2014-03-09T18:11:10Z,Trying to form iterator_ranges with restricted pointers causes compiler errors.,Domagoj Šarić
6998,visibility problems on Mac OS X / GCC,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-06-19T12:35:09Z,2012-06-19T12:40:19Z,"When an application built with -fvisibility=hidden is linked against libboost_program_options.dylib (built with default visibility), the linker emits the following warning:

    ld: warning: direct access in !__static_initialization_and_destruction_0(int, int) to global weak symbol boost::program_options::options_description::~options_description() means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

Even if the two are built with different visibility settings the program_options headers should force whatever needs to be visible to be.",Mathias Gaunard
6997,Bug in specifying alternate build toolset in gcc.jam,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-06-18T23:59:41Z,2013-01-03T17:03:45Z,"You cannot currently specify alternate gcc versions.  For example, if you do the following:
  ./b2 toolset=gcc-44

You will get an error like:

    error: version '44' requested but 'g++-44' not found and version '4.1.2' of default 'g++' does not match

This is because the version-checking code tries to run g++-44 instead of g++44... the patch fixes this in the affected code, comments, and printouts.


",carson.fenimore@…
6994,gzip_decompressor issue with unusual files,iostreams,Boost 1.49.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-06-18T08:48:13Z,2015-03-02T14:22:00Z,"The gzip_decompressor implementation fails on gzip files that contain an empty block after a non-empty one.  (You can make such a file by gzipping a nonempty and an empty file and concatenating them, but they are also sometimes written by other tools.)  Here such a file:

$ hexdump -C hello.txt.gz 
00000000  1f 8b 08 00 0d ea b4 4f  00 03 cb 48 cd c9 c9 57  |.......O...H...W|
00000010  28 c9 48 2d 4a e5 02 00  8e 45 d1 59 0c 00 00 00  |(.H-J....E.Y....|
00000020  1f 8b 08 00 18 ea b4 4f  00 03 03 00 00 00 00 00  |.......O........|
00000030  00 00 00 00                                       |....|
00000034

My file reading code is:

/* test.cpp */
#include <iostream>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/filter/gzip.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/device/file.hpp>

int main( int, char** ) {
	boost::iostreams::filtering_istream stream ;
	stream.push( boost::iostreams::gzip_decompressor() ) ;
	boost::iostreams::file_source file( argv[1] ) ;
	stream.push( file ) ;
	boost::iostreams::copy( stream, std::cout ) ;
}

Using gunzip on the above file works fine:
$ gunzip -c ../hello.txt.bgz 
Hello, this is a test file.

Using the test program does not:
$ ./test  ../hello.txt.bgz 
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::iostreams::gzip_error> >'
  what():  gzip error

",Gavin Band <gavinband@…>
6992,accumulator's median feature skips 1st two data points.,accumulator,Boost 1.41.0,To Be Determined,Bugs,Eric Niebler,assigned,2012-06-16T01:10:15Z,2016-12-14T11:44:04Z,"Hi,

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

Please check what is going on. 

Thanks,
yu",polyactis@…
6991,Provide a way to disable interspersed arguments,program_options,Boost 1.49.0,To Be Determined,Feature Requests,Vladimir Prus,new,2012-06-15T22:08:17Z,2012-10-17T09:09:02Z,"I'm trying to write a program that wraps other programs, and allowing switches to come after the first positional argument in this situation is very annoying from the user's standpoint.

If I define the flag --flag in my wrapper, it means that
{{{    
    my-program target-program --flag
}}}
won't run {{{target-program --flag}}} as one would hope, but will treat {{{--flag}}} as an argument to my program.

This means that the user has to run {{{my-program -- target-program --flag}}} every time, which is both annoying and goes against how most such programs work on Unix. (You never see someone say ""run {{{sudo -- apt-get install blah}}}."" Or xargs, env, nohup, etc.)

As far as I'm concerned, this problem is a showstopper for using the stock Boost po for this sort of program. If the Gflags library didn't have the same limitation, I'd be using it right now instead of having patched Boost. :-)

So I request a setting to disable this sort of interspersed arguments.

----

Fortunately, (one possible) fix seems to be pretty simple from what I can tell. I'll follow up this post with a patch after I get things cleaned back up and such.",driscoll@…
6981,Can't use boost::ptr_vector<T>::auto_type as data member in GCC 4.6,ptr_container,Boost 1.49.0,To Be Determined,Bugs,Thorsten Ottosen,new,2012-06-12T03:56:20Z,2012-06-12T04:57:35Z,"The following code failed to compile with g++ 4.6.3 on Ubuntu Linux 12.04 LTS. 

{{{
#include <boost/noncopyable.hpp>
#include <boost/ptr_container/ptr_vector.hpp>

class Test : boost::noncopyable
{
};

class Pool : boost::noncopyable
{
 public:
  Pool();

 private:
  boost::ptr_vector<Test>::auto_type p_;
};

Pool::Pool()
{
}
}}}

the error is 
{{{
In file included from /usr/include/boost/ptr_container/detail/reversible_ptr_container.hpp:22:0,
                 from /usr/include/boost/ptr_container/ptr_sequence_adapter.hpp:20,
                 from /usr/include/boost/ptr_container/ptr_vector.hpp:20,
                 from ptr_vec.cc:2:
/usr/include/boost/ptr_container/detail/static_move_ptr.hpp: 
In instantiation of 'boost::ptr_container_detail::static_move_ptr<Test, boost::ptr_container_detail::clone_deleter<...> >
::cant_move_from_const<const boost::ptr_container_detail::static_move_ptr<Test, boost::ptr_container_detail::clone_deleter<...> > >':
ptr_vec.cc:17:12:   instantiated from here
/usr/include/boost/ptr_container/detail/static_move_ptr.hpp:168:57: error: no type named 'error' in 'class boost::ptr_container_detail::static_move_ptr<Test, boost::ptr_container_detail::clone_deleter<boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<Test, std::vector<void*, std::allocator<void*> > >, boost::heap_clone_allocator>::null_clone_allocator<false> > >'
}}}

However, if I inline the constructor, it compiles fine.

{{{
class PoolOkay : boost::noncopyable
{
 public:
  PoolOkay()
  {
    // okay to inline constructor
  }

 private:
  boost::ptr_vector<Test>::auto_type p_;
};
}}}

Note: there is no error when compiling with g++ 4.4.3

I am not sure if it's a bug of ptr_container or gcc itself.",Shuo Chen <giantchen@…>
6980,date_time_zonespec.csv has incorrect entries for indiana,date_time,Boost 1.49.0,To Be Determined,Bugs,az_sw_dude,new,2012-06-11T17:55:16Z,2012-08-15T19:46:44Z,"based on http://en.wikipedia.org/wiki/Time_in_Indiana
i think the following setting for indianapolis (and other cities in indiana) is incorrect


""America/Indiana/Indianapolis"",""EST"",""EST"","""","""",""-05:00:00"",""+00:00:00"",""2;0;3"","""",""1;0;11"",""+00:00:00"" 

the above line should be 
""America/New_York"",""EST"",""Eastern Standard Time"",""EDT"",""Eastern Daylight Time"",""-05:00:00"",""+01:00:00"",""2;0;3"",""+02:00:00"",""1;0;11"",""+02:00:00""

indiana observes dst since 2006, so i'm not sure if i haven't overlooked something

",konrad borys <kborys@…>
6979,constexpr support in MPL,mpl,Boost 1.49.0,To Be Determined,Feature Requests,Aleksey Gurtovoy,new,2012-06-11T15:56:16Z,2014-03-28T20:23:26Z,C++11 introduced generalized constant expression with the constexpr keyword. It would be very nice if Boost.MPL static constants could be marked as constexpr so that they can be used in other constant expressions.,anonymous
6977,bug in conversion of mpl iterator category tags,mpl,Boost 1.49.0,To Be Determined,Bugs,Joel Falcou,new,2012-06-10T05:46:48Z,2012-06-10T05:46:48Z,"MPL documentation indicates that bidirectional_iterator_tag is convertible to random_access_iterator_tag. The following code shows that this is not true.
{{{
#include <boost/mpl/iterator_category.hpp>
#include <boost/mpl/iterator_tags.hpp>

#include <boost/mpl/print.hpp>
#include <boost/mpl/assert.hpp>
#include <boost/type_traits/is_convertible.hpp>

using namespace boost::mpl;

print<
    boost::is_convertible<
        bidirectional_iterator_tag,
        random_access_iterator_tag
    >::type
> x5;

BOOST_MPL_ASSERT((
    boost::is_convertible<
        bidirectional_iterator_tag,
        random_access_iterator_tag
    >
));
}}}

The compile time output from this progam is:

{{{
1>------ Build started: Project: test_interval, Configuration: Debug Win32 ------
1>Compiling...
1>test_multi_precision.cpp
1>c:\boostrelease\boost\mpl\print.hpp(51) : warning C4308: negative integral constant converted to unsigned type
1>        c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(15) : see reference to class template instantiation 'boost::mpl::print<T>' being compiled
1>        with
1>        [
1>            T=boost::integral_constant<bool,false>::type
1>        ]
1>c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(22) : error C2664: 'boost::mpl::assertion_failed' : cannot convert parameter 1 from 'boost::mpl::failed ************boost::is_convertible<From,To>::* ***********' to 'boost::mpl::assert<false>::type'
1>        with
1>        [
1>            From=boost::mpl::bidirectional_iterator_tag,
1>            To=boost::mpl::random_access_iterator_tag
1>        ]
1>        No constructor could take the source type, or constructor overload resolution was ambiguous
1>Build log was saved at ""file://c:\Projects\Boost Projects\mpl\tests\vcide\Debug\BuildLog.htm""
1>test_interval - 1 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
}}}

Robert Ramey",Robert Ramey
6976,Waiting on boost interprocess condition consumes 100% CPU on Windows,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-06-10T00:03:20Z,2018-04-22T20:47:11Z,"The problem arises when several threads of several processes waits on same condition. For example, we have application in which we create several threads with thread function like this:

{{{
while (_running)
{
boost::interprocess::scoped_lock<boost::interprocess::interprocess_mutex> lock ( _shm->mutex ) ; // _shm - shared memory
       _shm->condition.wait ( lock ) ; // condition is boost::interprocess::interprocess_condition
}
}}}

In main function we simply create several threads, sleep for a some time and stop threads. If we create 4 threads and start 2 applications, or create 3 threads and start 3 applications, or create 2 threads and start 4 applications then we get this problem. Its funny that the problem arising depends on quantity of threads and processes which we start.
This is tested on windows 7, windows xp. No problem on Linux system (Debian squeeze)


",tmf83 <tmf83@…>
6974,boost::optional compilation error with boost::function and boost::fusion::vector,optional,Boost 1.49.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-06-08T21:16:18Z,2013-02-19T15:54:07Z,"If you compile the following on g++ 4.4.5, it will fail to compile because the optional_base copy constructor and destructor are protected.

boost::optional< boost::fusion::vector1<boost::function0<void> > > 

A duplication program is attached.",Jonathan Jones <jonathan.jones@…>
6972,Boost.Locale doesn't provide sufficient control over collation,locale,Boost 1.49.0,To Be Determined,Feature Requests,Artyom Beilis,new,2012-06-07T21:35:03Z,2012-06-07T21:35:03Z,"I have just started using boost Locale and it is a great addition to the boost library.  However, the collation level options do not give a fine enough control.  From the ICU documentation:  ""In some cases, punctuation can be ignored while searching or sorting data...In other cases, it is desirable for punctuated text to be distinguished from text without punctuation.""  (This appears to be controlled by the Alternate attribute.)

However, boost Locale seems to always assume that punctuation can be ignored when you are also ignoring case.  In particular, I find at the secondary level that ""SINWAVE"" is considered equal to ""sin_wave"" (compare returns 0) when this is not what I (and very likely others) require.

The first two levels (primary and secondary) really need options to not ignore punctuation and whitespace.",Karim Chichakly <kchichakly@…>
6970,Boost Wave incompatible with unicode paths on Windows,wave,Boost 1.47.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-06-07T04:40:16Z,2012-06-07T04:40:16Z,"Boost::Wave frequently casts boost::filesystem::path to std::string, which transforms all unicode characters to '?'. For example, in cpp_context.hpp / init_context(), line 331, but there are many other instances. I suppose that the fix is to just use boost::filesystem::path at all times for paths, instead of converting to std::string and back, or to explicitly convert to utf-8 before converting to string.

I mark this bug as a showstopper because it makes the Wave library unusable for projects that may be deployed on Windows computers in a non-English locale, or with non-ASCII usernames or filenames.",david@…
6965,Handling of sequence of non const reference,fusion,Boost Development Trunk,To Be Determined,Feature Requests,Joel de Guzman,new,2012-06-04T18:58:48Z,2012-06-26T10:19:48Z,"Currently, assigning or copying a fusion sequence of non const reference to another is not possible. Down into the code, the vectorN classes only has a vectorN( const Sequence& ) constructor that calls a const qualified from_sequence method from the base_type.

Sequence of reference has a nice use case of enabling strcuture of array//Array of structure efficient application and this can't be doen with current Fusion.

Could all sequence be amended so passing a non const sequence as initialisation is dealt with correctly ?",Joel Falcou
6962,[function] missing document function::assign(),function,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-06-04T03:26:34Z,2012-06-04T03:26:34Z,"boost::function::assign() member function is undocument.
This function can assign allocator object one of the few way.
I hope documentation this function.
{{{
#include <cassert>
#include <memory>
#include <boost/function.hpp>

struct increment {
    int operator()(int x) const { return x + 1; }
};

int main()
{
    boost::function<int(int)> f;
    f.assign(increment(), std::allocator<increment>());

    assert(f(1) == 2);
}
}}}",Akira Takahashi <faithandbrave@…>
6961,problem with list_c et.all,mpl,Boost 1.49.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-06-03T17:55:46Z,2012-06-03T20:48:06Z,"The documentation for list_c states that it is a model of Front Extensible Sequence.

But some simple testing suggests otherwise.  Here is my test program:


{{{
#include ""../include/multi_precision.hpp""

//#include <boost/mpl/shift_right.hpp>
//#include <boost/mpl/integral_c.hpp>
//#include <boost/cstdint.hpp>

#include <boost/mpl/list.hpp>
#include <boost/mpl/list_c.hpp>
#include <boost/mpl/push_front.hpp>
#include <boost/mpl/front.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/integral_c.hpp>

#include <boost/mpl/print.hpp>

namespace boost {
namespace mpl {

print<
    list_c<int,
       22,
       64 
    >
> x8;

print<
    front< 
        list_c<int,
           22,
           64 
        >
    >::type
> x7;

print<
    push_front< 
        list_c<int,
            22,
            64
        >, 
        integral_c<int, 33> 
    >::type
> x6;


}}}

which produces the following output on my VC 9.0 compiler


{{{
1>------ Build started: Project: test_interval, Configuration: Debug Win32 ------
1>Compiling...
1>test_multi_precision.cpp
1>c:\boostrelease\boost\mpl\print.hpp(51) : warning C4308: negative integral constant converted to unsigned type
1>        c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(24) : see reference to class template instantiation 'boost::mpl::print<T>' being compiled
1>        with
1>        [
1>            T=boost::mpl::list_c<int,22,64>
1>        ]
1>c:\boostrelease\boost\mpl\print.hpp(51) : warning C4308: negative integral constant converted to unsigned type
1>        c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(33) : see reference to class template instantiation 'boost::mpl::print<T>' being compiled
1>        with
1>        [
1>            T=boost::mpl::integral_c<int,22>
1>        ]
1>c:\boostrelease\boost\mpl\print.hpp(51) : warning C4308: negative integral constant converted to unsigned type
1>        c:\projects\boost projects\mpl\tests\test_multi_precision.cpp(44) : see reference to class template instantiation 'boost::mpl::print<T>' being compiled
1>        with
1>        [
1>            T=boost::mpl::l_item<boost::mpl::long_<3>,boost::mpl::integral_c<int,33>,boost::mpl::list2_c<int,22,64>>
1>        ]

}}}

What I hope to see for the third test is:

{{{
T=boost::mpl::list_c<int,33, 22,64>
}}}

If I use

{{{
print<
    push_front< 
        list_c<int,
            22,
            64
        >, 
        33
    >::type
> x5;
}}}

But this fails to compile at all.

To me, the list_c implementation is misconceived. Maybe the following should result

{{{
print<
    list_c<int,
       22,
       64 
    >::type // note the ::type to make it a metafunction
> x8;
}}}

to return

{{{
T=boost::mpl::list<boost::mpl::integral_c<int, 22>,boost::mpl::integral_c<int, 64> >
}}}

Of course the same observations would apply to vector_c, etc.

Robert Ramey







",Robert Ramey
6957,Boost.units: static pow<>() fails for quantities with non-double type,units,Boost 1.48.0,To Be Determined,Bugs,Matthias Schabel,new,2012-05-31T19:07:45Z,2012-05-31T19:07:45Z,"Below is a short example depicting that pow<>() works only in the quantity in the argument has double precision representation. Hope that helps.



ajaruga@granda:~/icicle$ cat test.cpp 
#include <boost/units/pow.hpp>
#include <boost/units/systems/si.hpp>
using namespace boost::units;

int main() {
  quantity<si::length, real_t> a = 1 * si::metres;
  quantity<si::volume, real_t> b = pow<3>(a);
}
ajaruga@granda:~/icicle$ g++ -Dreal_t=double test.cpp && echo OK
OK
ajaruga@granda:~/icicle$ g++ -Dreal_t=float test.cpp && echo OK
test.cpp: In function ‘int main()’:
test.cpp:7:44: error: conversion from ‘boost::units::power_typeof_helper<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> > > > > > > > > > >, float>, boost::units::static_rational<3l> >::type {aka boost::units::quantity<boost::units::unit<boost::units::list<boost::units::dim<boost::units::length_base_dimension, boost::units::static_rational<3l> >, 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> > > > > > > > > > >, double>}’ to non-scalar type ‘boost::units::quantity<boost::units::unit<boost::units::list<boost::units::dim<boost::units::length_base_dimension, boost::units::static_rational<3l> >, 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> > > > > > > > > > >, float>’ requested
",Anna Jaruga <ajaruga@…>
6954,property map 'put' should support move semantics,property_map,Boost Development Trunk,Boost 1.56.0,Bugs,Noel Belcourt,assigned,2012-05-30T19:12:42Z,2014-01-27T23:48:48Z,"The 'put' helper function in the boost property map library should support move semantics. At the moment it takes the value to be put by const reference, I think it would be more appropriate to perfect forward it.",wz258@…
6952,[interprocess] mixed comment styles causing documentation issues?,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-05-29T15:43:02Z,2012-05-29T15:43:02Z,"There are a handful of comments of the form:


{{{
  //! ... */
}}}


In at least one instance (boost/interprocess/ipc/message_queue.hpp), the
code looks like this:


{{{
   //!Sends a message stored in buffer ""buffer"" with size ""buffer_size"" in the
   //!message queue with priority ""priority"". If the message queue is full
   //!the sender is blocked. Throws interprocess_error on error.*/
   void send (const void *buffer,     size_type buffer_size,
              unsigned int priority);
}}}


Which got rendered into the docs like so:

   *void send(const void * buffer, size_type buffer_size, unsigned int priority);

   Sends a message stored in buffer ""buffer"" with size ""buffer_size"" in
   the message queue with priority ""priority"". If the message queue is
   full the sender is blocked. Throws interprocess_error on error.

   -- http://www.boost.org/doc/libs/1_49_0/doc/html/boost/interprocess/message_queue_t.html#id985430-bb

Note the leading ""*"" on the method signature.
",anthony.foiani@…
6946,bootstrap.sh not compatible with python3.,Building Boost,Boost 1.49.0,To Be Determined,Bugs,Stefan Seefeld,new,2012-05-26T18:05:27Z,2017-10-26T13:55:33Z,"Just tried building boost with python3 support and hit a small snag with bootstrap.sh using invalid syntax. 

On line 280, the print statement has been removed from python3 so you need to use the print *function* instead, with brackets:

        PYTHON_ROOT=`$PYTHON -c ""import sys; print(sys.prefix)""`

This change does not break compatibility with python2. ",Robert Park <rbpark@…>
6929,stream and stream_buffer need const versions of operator-> and operator *,iostreams,Boost 1.49.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-05-22T19:49:21Z,2012-05-22T19:49:21Z,"stream and stream_buffer need their operator-> and operator * to be either made const or the const versions need to be added.

These operators do not modify the state of the stream and can be used to execute const functions of the device (like st->handle() for a file_descriptor device) .",Igor Lubashev <igorlord@…>
6928,semaphore.hpp duplicates nested namespace,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-05-22T18:07:14Z,2012-05-22T18:07:14Z,"\boost\interprocess\sync\spin\semaphore.hpp is placed in namespace
boost::interprocess::ipcdetail and is using functions in a nested
namespace ipcdetail causing compilation failure:

e.g.
\proj\boost_1_49_0\boost\interprocess\sync\spin\semaphore.hpp(53): error C2039: 'atomic_write32' : is not a member of 'boost::interprocess'''::ipcdetail::ipcdetail''''
",info@…
6925,BooleanMetafunction,mpl,Boost 1.49.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-05-21T16:56:39Z,2012-05-21T16:56:39Z,"mpl defined the metafunctions max<N1, N2> as:

N1, N2 any type. with semantics equivalent to:

typedef if_< less<x,y>,y,x >::type r;

BUT less<x,y> requires that x & y be a NumericalMetafunction wity x, y modeling IntegralConstant.

So, I believe that N1 and N2 should also be required to model IntegralConstant.  

In addition, it makes sense the max (and min) model the concept of
NumericalMetafunction with value type bool.

Actually, there should be a concept BooleanMetafunction as short hand for NumericalMetafunction.

I came across this problem when I removed the ::type from min<x, y> and got a compile error.  This should work as plus, ... etc do.

Robert Ramey




",Robert Ramey
6923,add compile time inteval arithmetic to TODO list,interval,Boost 1.49.0,To Be Determined,Feature Requests,Boris Gubenko,new,2012-05-20T21:57:10Z,2012-05-20T21:57:10Z,"Please consider adding compile time integer arithmetic ala mpl::plus etc.  I would find this and multply useful.

Rober Ramey
",Robert Ramey
6921,documentation for BOOST_MPL_ASSERT_RELATION inconsistent with implementation,mpl,Boost 1.49.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-05-20T19:24:49Z,2012-10-29T15:18:50Z,"Documenation for MPL states that the proper syntax BOOST_MPL_ASSERT_RELATION
is:

BOOST_MPL_ASSERT_RELATION( x, op, y );

where x and y are integral constants.

Given this, the following assert should trap since 8 is not an integral constant
{{{
BOOST_MPL_ASSERT_RELATION(8, ==, 8); // no assertion 
}}}
But in fact it does not.

On the other hand, the following should not trap
{{{
BOOST_MPL_ASSERT_RELATION(
    (boost::mpl::integral_c<int, 8>), 
    ==, 
    (boost::mpl::integral_c<int, 8>)
);
}}}
But in fact it does.

So it seems that the documentation doesn't agree with the implementation.

Robert Ramey
",Robert Ramey
6916,file_descriptor_sink is missing the definition for its templated open() function.,iostreams,Boost 1.49.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-05-17T19:02:34Z,2012-05-17T19:02:34Z,"file_descriptor_sink has a templated function to open based on any path type, but the function has no definition, resulting in linker errors if you try to call it. I have attached a patch that implements the function by calling open() with detail::path, the same as how file_descriptor and file_descriptor_source do it.",Aaron Barany <akb825@…>
6911,[Phoenix V3] Add tr1_result_of specialization,phoenix,Boost Development Trunk,Boost 1.67.0,Bugs,Kohei Takahashi,assigned,2012-05-17T15:01:15Z,2018-01-19T19:51:45Z,"To make `result_of` and `tr1_result_of` equivalent, we have to add specialization of `tr1_result_of`. 
(Boost.Phoenix V3 already has specialization of `result_of`.)

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

So, instead of 
{{{
template <...>
struct result_of<F()>
{
    typedef XXXX type;
};
}}}
we should write
{{{
#if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE)
template <...>
struct result_of<F()>
{
    typedef XXXX type;
};
#endif

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

A quick grep said the following files specialize `result_of`.
* phoenix/core/actor.hpp
* phoenix/function/function.hpp
",Michel Morin
6909,[Functional/Forward] Add tr1_result_of specialization,functional/forward,Boost Development Trunk,To Be Determined,Bugs,t_schwinger,new,2012-05-17T15:00:58Z,2012-05-17T15:00:58Z,"To make `result_of` and `tr1_result_of` equivalent, we have to add specialization of `tr1_result_of`. 
(Boost.!Functional/Forward already has specialization of `result_of`.)

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

So, instead of 
{{{
template <...>
struct result_of<F()>
{
    typedef XXXX type;
};
}}}
we should write
{{{
#if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE)
template <...>
struct result_of<F()>
{
    typedef XXXX type;
};
#endif

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

A quick grep said the following files specialize `result_of`.
* functional/forward_adapter.hpp
* functional/lightweight_forward_adapter.hpp
",Michel Morin
6906,boost 1.49  takes too much CPU time.,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-05-16T07:51:54Z,2012-05-16T07:51:54Z,"I moved from boost 1.44 with my project building with Visual Studio 2005 to 1.49 (+Visual Studio 2010) and found that CPU usage of my application hovers between 90% to 99-100%.

I found interprocess::message_queue::recieve takes too much CPU time and if I replace this with interprocess::message_queue::timed_receive with a time parameter ( + minor adjustment in client code that was calling recieve), there seems to be some improvement ( CPU usage time hovers between 1% to 25%).",zhussain@…
6903,Including program options header breaks using g++ -static -flto -std=c++11,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-05-15T13:30:10Z,2012-10-24T20:37:59Z,"A minimal example is simply

{{{
#include ""boost/program_options.hpp""

int main ( int argC, char* argV[] )
{
    return 0;
}
}}}

Compiling this using either[[BR]]
g++ main.cpp -static -flto -std=c++11 -fwhole-program[[BR]]
or[[BR]]
g++ main.cpp -static -flto -std=c++11 -fno-use-linker-plugin[[BR]]
gives a lot of errors:


`_ZTIN9__gnu_cxx24__concurrence_lock_errorE' referenced in section
`.text._ZN9__gnu_cxx30__throw_concurrence_lock_errorEv[_ZN9__gnu_cxx30__throw_concurrence_lock_errorEv]'
of /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a(eh_alloc.o): defined in
discarded section `.gnu.linkonce.t._ZTIN9__gnu_cxx24__concurrence_lock_errorE'
of /tmp/ccEoPVoT.o (symbol from plugin)[[BR]]
...[[BR]]
collect2: error: ld returned 1 exit status


I tried g++4.6 and 4.7. I am not sure if it is a bug within the g++ or within boost. If either -static, -flto or -std=c++11 is omited the program compiles fine. Only if all three are present the error occours. I am using Debian Wheezy.
",boostBugs@…
6897,Boost interprocess segfaults,interprocess,Boost 1.49.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-05-14T08:19:39Z,2017-03-11T08:20:39Z,"Having a boost::unordered map in shared memory and after creation
opening it in open_only or open_read_only behaves differently depending 
on the key length.
open_only always works, open_read_only only works if key length is less than 24 bytes.

I've got very simple example code that I'll attach, maybe I am doing something wrong here.

",Mathias Creutz <mathiascreutz@…>
6894,Highlight context forwarding in async state machine docs,statechart,Boost 1.49.0,To Be Determined,Bugs,Andreas Huber,assigned,2012-05-13T21:17:44Z,2013-06-09T18:03:25Z,(as reported by Sebastian Hoffmann),Andreas Huber
6893,Inaccurate Radians/Degrees conversion,units,Boost 1.49.0,To Be Determined,Bugs,Jürgen Hunold,assigned,2012-05-13T10:19:17Z,2018-07-08T16:19:39Z,"LS,

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

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

Using this value improves conversion accuracy significantly.

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

",pieterb@…
6891,Add extension point to define how expressions are created from operators,proto,Boost Development Trunk,To Be Determined,Feature Requests,Eric Niebler,assigned,2012-05-12T16:15:55Z,2012-06-06T17:39:53Z,"As discussed here:
<http://lists.boost.org/proto/2012/05/0637.php>

It would be nice to add a mechanism to allow to define what the operator overloads created by Proto will do. Unlike other functions where a Proto-based library can construct nodes the way it wishes, there is no control and what the built-in C++ operators do.",Mathias Gaunard
6889,Initialise multi_array with a given value,multi_array,Boost 1.49.0,To Be Determined,Feature Requests,Ronald Garcia,new,2012-05-11T03:21:55Z,2013-11-02T04:07:54Z,"The multi-array only allows users to initialise all elements to a default constructed T(). That may not be desirable if you would like a different value, either for performance reasons or because the type does not support default initialisation. For example:


{{{
#include <vector>
#include <boost/multi_array.hpp>

struct no_default
{
    explicit no_default(int i) {}
};

int main()
{
    std::vector<no_default> v(10, no_default(3));
    boost::multi_array<no_default, 3> m(boost::extents[10][10][10]); // won't compile
}
}}}

Offering constructors that accept a value to be used to initialise the elements would be the easiest fix. This would also align with std::vector usage.",Andrew Morris <andy@…>
6884,Add functionality to enumerate filesystem roots,filesystem,Boost 1.49.0,To Be Determined,Feature Requests,Beman Dawes,new,2012-05-09T23:51:47Z,2012-05-10T13:55:16Z,"Unlike POSIX systems, which root everything at '/', some systems (notably Windows) provide multiple filesystem roots.

In order to abstract this difference in a cross-platform way, I propose that a new function be added to boost::filesystem to return a list of path objects, one for each filesystem root. On a POSIX system, this would simply return ![""/""], but on Windows, it would return, e.g., [""C:/"", ""D:/""]. This would make it possible to implement something like a filesystem browser in a platform-independent manner.

There is precedence for this functionality in several cross-platform libraries, including Java (File.listRoots), Qt (QDir::drives), and Poco (Poco::Path::listRoots).",Erik Jensen <Erik.Jensen@…>
6883,build.bat not using the 32-bit Visual Studio 2010 installation path,Building Boost,Boost 1.49.0,To Be Determined,Bugs,,new,2012-05-09T15:05:44Z,2012-05-09T15:05:44Z,"See also #6846 (bootstrap)

I had the same problems there but didn't want to overtake ownership on that trac issue.  

With Visual Studio 2010, in a Visual Studio Command Prompt, bootstrap will fail.  It cannot find any of the headers.  I am looking at the build.bat and I think it's latching on to %ProgramFiles% to set the paths.  Like this:

if EXIST ""%ProgramFiles%\Microsoft Visual Studio 10.0\VC\VCVARSALL.BAT"" (
    set ""BOOST_JAM_TOOLSET=vc10""
    set ""BOOST_JAM_TOOLSET_ROOT=%ProgramFiles%\Microsoft Visual Studio 10.0\VC\""

I used the recommended installation path for my edition and it put vcvarsall.bat in: C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC

Unfortunately %ProgramFiles% comes up with the 64-bit path ""C:\Program Files"" -- note the omission of ""(x86)"" in there.  So dead right there.

I should note I can work fine if I call vcvarsall.bat manually before running bootstrap.

I don't have a firm recommendation here one what to do.  Perhaps you can probe the registry for installation keys for Visual Studio, and from there derive the path.  If you don't have an installation handy on which to experiment I can submit myself to some probes.",adam.preble@…
6882,Interprocess should provide filesystem location of shared memory files,interprocess,Boost 1.49.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2012-05-09T14:51:03Z,2012-05-09T14:51:03Z,"Every now and then we have problems with shared memory files, so our application ceases to work correctly. This is probably not Boost's fault, but a Windows issue.
We would like to be able to print the location of the directory, where Boost Interprocess puts its files, so the user can check and possibly clean up the directory.
Therefore a method providing this information e.g. as a member function of shared_memory_object would be nice.",martin.apel@…
6879,Memory leak using resolve() method from basic_resolver,asio,Boost 1.63.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2012-05-09T00:31:30Z,2017-06-25T13:00:42Z,"Every time I use the resolve(), memory goes up.  I have checked the latest code, it looks like the resolve() in resolver_service.hpp never call freeaddrinfo() to free the memory 'address_info' allocated by getaddrinfo().",Tony Ho <Tony.Ho@…>
6876,Add forwarding of operator() to reference_wrapper,bind,Boost Release Branch,To Be Determined,Patches,Peter Dimov,new,2012-05-08T15:33:15Z,2012-05-08T15:33:15Z,"Adding forwarding of operator() to reference_wrapper will make it comply with the ISO definition of reference_wrapper. The attached patch adds dependencies to Boost.Move and Boost.Preprocessor. The later could be removed by manually expanding the macro. Forwarding in C++03 only works for values, references-to-const and rvalues as this is what Boost.Move provides. In C++11, forwarding works as expected for all kind of values. It might be necessary to make the amount of forwarded arguments configurable, currently it is fixed to 8.",philipp.moeller@…
6875,[signals2] compilation error in fnoexception,signals2,Boost 1.49.0,To Be Determined,Feature Requests,Frank Mori Hess,new,2012-05-08T07:53:16Z,2012-05-08T07:53:16Z,"Boost.Signals2 compile error because Boost.Signals2 using try/catch grammar (not BOOST_TRY/BOOST_CATCH) in fnoexception environment.
This ticket is feature requests (not bug).

{{{
// g++ main.cpp -fno-exceptions -I ""C:\Library\Boost\1_49_0""
#define BOOST_NO_EXCEPTIONS
#include <boost/signals2.hpp>

int main ()
{
}
}}}

{{{
In file included from C:\Library\Boost\boost_1_49_0/boost/signals2/deconstruct.h
pp:29:0,
                 from C:\Library\Boost\boost_1_49_0/boost/signals2.hpp:15,
                 from main.cpp:2:
C:\Library\Boost\boost_1_49_0/boost/signals2/deconstruct_ptr.hpp: In function 'v
oid boost::signals2::detail::do_predestruct(const boost::signals2::predestructib
le_adl_barrier::predestructible*)':
C:\Library\Boost\boost_1_49_0/boost/signals2/deconstruct_ptr.hpp:48:15: error: e
xception handling disabled, use -fexceptions to enable
}}}",Akira Takahashi <faithandbrave@…>
6872,units/io.hpp: autoprefix_norm_impl<> should resolve to no-op for unsigned built-in types,units,Boost Development Trunk,To Be Determined,Bugs,Steven Watanabe,new,2012-05-06T15:37:53Z,2012-05-08T15:47:24Z,"The code 
	using namespace boost::units;
	const quantity<si::length, int> boa = 5 * si::meters;
	std::cout << boa << std::endl;
prints ""5 m"", as expected, yet
	using namespace boost::units;
	const quantity<si::length, unsigned int> boa = 5 * si::meters;
	std::cout << boa << std::endl;
fails to compile due to the std::abs call being ambiguous in io.hpp:
template<class T>
struct autoprefix_norm_impl<T, true>
{
    typedef double type;
    static double call(const T& arg) { return std::abs(arg); }
};

There should be a specialization resolving to a no-op (just return the arg) for unsigned types.

A (probably slightly heavier) user-side workaround possible one can use is to forcibly define the missing std::abs to be a no-op as follows:

namespace std {
    template<typename Unsigned>
    typename boost::enable_if<boost::is_unsigned<Unsigned>, Unsigned>::type
        abs(const Unsigned& x)
    {
        return x; // unsigned type...
    }
}

Alternatively, boost::units should do a static assert that the type underlying the quantity is signed if that is what is intended (but why restrict it thus?)

Found and tested the workaround on 1.47.0, but confirmed to still exist on the trunk.
",Vassilii Khachaturov <vkh@…>
6867,Unclear behavior of parameter 'max_size',pool,Boost 1.49.0,To Be Determined,Bugs,John Maddock,new,2012-05-04T20:41:33Z,2012-07-16T20:03:25Z,"When constructing a pool, a 'max_size' parameter can be given. If non zero, the documentation states that the pool will not allow more than 'max_chunks' at once.

However, this restriction is not taken into account in function ordered_malloc(n) :

{{{
boost::pool<> p(sizeof(int), 16, 16);

void *ptr = p.ordered_malloc(32);  // Succeeds
}}}

Either the documentation should be precised, either the illustrated allocation should fail.
",edupuis
6865,pool.get_size(),pool,Boost 1.49.0,To Be Determined,Feature Requests,John Maddock,new,2012-05-04T19:04:26Z,2012-07-16T20:02:57Z,"It would be nice to have a function get_size() that would return the current size of the pool.

This could be helpful to track a pool's memory usage.",edupuis
6860,Cannot read negative time_duration,date_time,Boost 1.49.0,To Be Determined,Bugs,az_sw_dude,new,2012-05-03T18:43:24Z,2012-05-03T18:43:24Z,"Loading a negative time_duration saved with operator<< does not work.

Test program:

{{{
#include <cassert>
#include <sstream>

#include <boost/date_time.hpp>

int main()
{
  boost::posix_time::time_duration expected(0, 0, 0, -1);
  std::stringstream stream;
  stream << expected;
  boost::posix_time::time_duration time;
  stream >> time;
  assert(expected == time);
  return 0;
}
}}}
",damienrg+bug@…
6856,Critical problem with serialization and class versioning,serialization,Boost 1.49.0,To Be Determined,Bugs,Robert Ramey,new,2012-05-02T15:07:59Z,2012-05-02T15:07:59Z,"I am investigating strange error ""input stream error"" messages that I've been getting for a while when loading XML archives,
and it turns out that boost::serialization is no longer enforcing strictly incrementing versioning numbers.

Specifically the patch:
https://github.com/ryppl/boost-svn/commit/66e85ade721a82bbc2e082749d6af2eefcb63dcb#boost/archive/detail
Which has the comment:
{{{
+    // note: we now comment this out. Before we permited archive
+    // version # to be very large.  Now we don't.  To permit
+    // readers of these old archives, we have to suppress this 
+    // code.  Perhaps in the future we might re-enable it but
+    // permit its suppression with a runtime switch.
}}}


I checked the documentation, and it is still assuming that class versions always increment, and it is implied (to me) that if a class version in an archive is larger than the BOOST_CLASS_VERSION() in the source, then it will not load (and checking the code, looks like it should throw a unsupported_class_version error).


This is a critical problem, and is now my likely candidate for the reason why sometimes my programs crash when loading binary archives that are written by a newer version of my program.

Basically, it NEVER checks if we are loading an archive that is newer than what the program is supported.  Thus, it will assume that it is reading the correct-versioned archive and serialize the wrong data in the wrong order.


I wrote a small program to demonstrate the problem, most of the code was copied from the ""bus"" example in the documentation.

The Makefile compiles 4 different versions:  xml and binary variants, each that write either version=0, version=1 classes.

It is a program that loads an archive file (if the file can be opened), and then writes an archive file.

The class written is a simple class with two integer variables.

In version=0, it writes var1.

In version=1, it writes var2, and then var1.


This is what it looks like when you run the programs:


{{{
$ ./test_version_binary_0
Could not open file to read: bus_route.binary
Saved, var1=1
------- so a binary archive is written to disk, version=0
$ ./test_version_binary_1
Restored, var1=1 var2=2
Saved, var1=1 var2=2
------- archive was loaded correctly, and then written back to disk, now version=1
------- now lets try and run the version=0 program
$ ./test_version_binary_0
Restored, var1=2
FAIL! var1 should always be 1
$ 
------- archive was loaded, apparently without error, but inspecting the data reveals that var1 was loaded with var2's value.
}}}



For the XML archive, we fortunately catch the problem, but only because it was expecting a different set of xml-tags:

{{{
$ ./test_version_xml_0 
Could not open file to read: bus_route.xml
Saved, var1=1
$ ./test_version_xml_1
Restored, var1=1 var2=2
Saved, var1=1 var2=2
$ ./test_version_xml_0
terminate called after throwing an instance of 'boost::archive::xml_archive_exception'
  what():  XML start/end tag mismatch - var1
Aborted
$ 
}}}



It seems to me that there are three solutions to this situation:

1) ignore problem.  allow boost-based software to incorrectly load binary archives.

2) change the documentation, tell users that they will need to manually test the version passed to void serialize(Archive,int) methods, and throw exceptions themselves if required.
That will also mean upgrading all of the existing software and adding a test into every single serialize() function/method in existing production code.

3) turn back on the version check that was turned off in the above patch.

This is what it looks like when I change the #if 0 to #if 1


{{{
$ ./test_version_binary_0
terminate called after throwing an instance of 'boost::archive::archive_exception'
  what():  class version 9bus_route
Aborted
}}}


And that's what I was expecting it to do.
",harris.pc@…
6844,[function] Memory leaks if used with allocator and throwing copy-c'tor of functor,function,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-04-29T11:13:23Z,2012-04-29T11:29:25Z,"There are two places where the implementation of boost::function uses a user-provided allocator:

1. boost/function/function_base.hpp, line 485
2. boost/function/function_template.hpp, line 591

Both use cases do not protected against a possibly throwing copy constructor of a function-object because there is an unprotected two-step sequence of the following style:

{{{
wrapper_allocator_pointer_type copy = wrapper_allocator.allocate(1);
wrapper_allocator.construct(copy, functor_wrapper_type(f,a));
}}}

If the second step fails, no clean-up of the allocated memory takes place. The following test program emulates this situation and demonstrates the problem:

{{{
#include ""boost/function.hpp""
#include <memory>
#include <iostream>

struct F {
  static bool dothrow;
  unsigned char prevent_short_object_opt[sizeof(boost::detail::function::function_buffer) + 1];
  F(){}
  F(const F&) {
    if (dothrow)
      throw 0;
  }
  void operator()() {}
};

bool F::dothrow = false;
int alloc_cnt = 0;

template<class T>
struct my_alloc : std::allocator<T>
{
  template<class Other>
  struct rebind
  {
    typedef my_alloc<T> other;
  };
  void construct(typename std::allocator<T>::pointer p, const T& val)
  {
    F::dothrow = true;
    ::new((void *)p) T(val);
  }
  void deallocate(typename std::allocator<T>::pointer p, 
	              typename std::allocator<T>::size_type n)
  {
    --alloc_cnt;
    std::cout << ""deallocate: "" << alloc_cnt << std::endl;
    return std::allocator<T>::deallocate(p, n);
  }

  typename std::allocator<T>::pointer allocate(typename std::allocator<T>::size_type n)
  {
    ++alloc_cnt;
    std::cout << ""allocate: "" << alloc_cnt << std::endl;
    return std::allocator<T>::allocate(n);
  }

};

int main() {
  F f;
  my_alloc<F> a;
  try {
    boost::function<void()> fu(f, a);
  } catch (int) {
    std::cout << ""Caught expected - allocation count: "" << alloc_cnt << std::endl; 
  }
}
}}}

The program outputs

{{{
allocate: 1
Caught expected - allocation count: 1
}}}

on all systems I tested (Visual Studio 11 beta and mingw with gcc 4.8) showing that the deallocation function is never called.

The two-step process of allocation+construct needs to be made exception-safe. In my own type-erased allocators I'm using a helper type

{{{
template<class Alloc>
struct allocated_ptr
{
  typedef typename Alloc::pointer pointer;

  explicit allocated_ptr(Alloc& alloc)
    : alloc(alloc), ptr(alloc.allocate(1))
  {}

  ~allocated_ptr()
  {
    if (ptr != pointer()) {
      alloc.deallocate(ptr, 1);
    }
  }

  pointer get() const { return ptr; }

  pointer release()
  {
    pointer result = ptr;
    ptr = pointer();
    return result;
  }

private:
  Alloc& alloc;
  pointer ptr;
};
}}}

to handle this, invoking the release function, after successful construction. Of-course other means are possible.


",Daniel Krügler <daniel.kruegler@…>
6839,distributed::adjacency_list fails to propagate mpi_process_group correctly,graph,Boost 1.50.0,To Be Determined,Patches,Jeremiah Willcock,new,2012-04-27T13:59:36Z,2012-07-24T14:00:19Z,In the distributed `adjacency_list` the `named_graph_mixin` of kind maybe_named_graph holds and `mpi_process_group` member which is default constructed rather than appropriately initialized. See patch,Sebastian Jeltsch <sjeltsch@…>
6834,Memory corruption when calling boost::filesystem::exists() from static initializer with Unicode paths,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-26T20:00:26Z,2012-04-26T20:00:26Z,"Assume we have a class MyClass with the constructor as shown below.
Now, if we create a static instance of MyClass (or have some other mechanism to execute this code at static initialization time), then this code will create an access violation exception when exists() is called.

{{{
MyClass::MyClass() {
	boost::filesystem::path path(L""C:\\Windows"");
	path /= boost::filesystem::path(L""notepad.exe"");
	if (!boost::filesystem::exists(path)) {
		std::cout << ""notepad.exe doesn't exist!"" << std::endl;
	}
}
}}}

The code was tested on Windows 7 X64 SP1 with VS 2008 SP1 with boost 1.49.",memger@…
6831,__sync_lock_test_and_set_4 and illegal instruction,asio,Boost 1.43.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-04-26T07:18:03Z,2012-04-26T07:25:07Z,"In the attachment, I’ve prepared a simple test program verifying a trivial asynchronous read operation using asio sockets. The program compiles and runs fine up to boost version 1.42. In version 1.43, compiling the program fails with a linker error:

{{{
/tmp/ccQi0dGl.o: In function `boost::asio::detail::gcc_fenced_block::gcc_fenced_block()':
main.cpp:(.text._ZN5boost4asio6detail16gcc_fenced_blockC1Ev[boost::asio::detail::gcc_fenced_block::gcc_fenced_block()]+0x4c): undefined reference to `__sync_lock_test_and_set_4'
}}}

Since version 1.44 up to version 1.49, the linker error is gone and the program compiles fine. However, the program aborts at runtime upon executing “io.run()”, issuing an “Illegal instruction” error message. My assumption is that whatever “_sync_lock_test_and_set_4” was replaced by in version 1.44 represents an illegal operation on my target system.

The target system is a MOXA UC-8410 embedded ARM computer:

{{{
Linux Moxa 2.6.23.1 #1044 Fri May 6 10:25:20 CST 2011 armv5teb GNU/Linux
arm-linux-g++ (GCC) 4.2.1
}}}
",Pascal Kesseli <pascal.kesseli@…>
6829,[smart_ptr] make_shared is slower than shared_ptr(new) in MSVC,smart_ptr,Boost Development Trunk,To Be Determined,Bugs,Peter Dimov,new,2012-04-25T21:59:25Z,2012-04-28T03:39:27Z,"boost::make_shared() works much slower than it supposed to in MSVC
It uses RTTI to get its custom deleter, and RTTI is painfully slow in MSVC.",mt.wizard@…
6828,functional/forward broken with decltype-based boost::result_of,functional/forward,Boost Development Trunk,Boost 1.50.0,Patches,t_schwinger,new,2012-04-25T17:54:13Z,2012-05-16T12:03:40Z,"The clang c++11 test runner is showing failures with decltype-based result_of that do not happen with TR1-style result_of. See the results here (clang-cxx11 test runner):

http://www.boost.org/development/tests/trunk/developer/functional-forward.html

In particular:

{{{
In file included from ../libs/functional/forward/test/forward_adapter.cpp:16:
In file included from ../boost/functional/forward_adapter.hpp:21:
In file included from ../boost/utility/result_of.hpp:113:
In file included from ../boost/preprocessor/iteration/detail/iter/forward1.hpp:47:
../boost/utility/detail/result_of_iterate.hpp:66:5: error: no matching function for call to object of type 'const test_func<boost::blank>'
    boost::declval<F>()(
    ^~~~~~~~~~~~~~~~~~~
../boost/utility/detail/result_of_iterate.hpp:47:7: note: in instantiation of template class 'boost::detail::cpp0x_result_of_impl<const test_func<boost::blank> ()>' requested here
    : mpl::if_<
      ^
../boost/functional/forward_adapter.hpp:150:36: note: in instantiation of template class 'boost::result_of<const test_func<boost::blank> ()>' requested here
            inline typename boost::result_of< FC() >::type
                                   ^
}}}
",Eric Niebler
6827,Integer overflow in read function,iostreams,Boost Development Trunk,To Be Determined,Bugs,Jonathan Turkanis,new,2012-04-24T17:41:57Z,2012-04-27T17:27:48Z,"The problem with this chunk of code (from boost/iostreams/detail/restrict_impl.hpp read function):
{{{
std::streamsize amt =
    end_ != -1 ?
            (std::min) (n, static_cast<std::streamsize>(end_ - pos_)) :
            n;
}}}
is that it's prone to integer overflow. So if you have let's say end_ that is ''> INT_MAX'' ''std::min'' will return 'wrong' (unwanted) value, e.g.:

{{{
std::streamsize a = 0xb14c1000;
std::streamsize b = 1;

std::streamsize result = (std::min)(a, b);
}}}

This will return ''result = 0xb14c1000'' which if applied to our case means we will read ''0xb14c1000'' instead of 1 bytes.

This can be fixed like this:

{{{
std::streamsize amt(n);

if (end_ != -1 && end_ <= std::numeric_limits<std::streamsize>::max())
{
    amt = (std::min) (n, static_cast<std::streamsize>(end_ - pos_));
}
}}}
",msuvajac@…
6826,boost build fails to detect python3.2 correctly,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-04-24T13:06:03Z,2013-01-03T17:54:50Z,"bootstrap detects python3.2


but does not locate the library and include files correctly


This is because when python3.2 is built with threading support, which is default on Linux, the include subdirectory and library are named python${VERSION}m, with the letter 'm' appended.

#/usr/bin/python3.2-config --includes
-I/usr/include/python3.2m

#/usr/bin/python3.2-config --libs
-lintl -lpthread -ldl -lutil -lm -lpython3.2m
 

or

$ pkg-config python-3.2 --cflags-only-I --libs-only-l
-I/usr/include/python3.2m  -lpython3.2m 


Building in dir: /usr/src/boost_1_49_0
boost    1_49_0

Building Boost.Build engine with toolset gcc... tools/build/v2/engine/bin.linuxx86_64/b2
Detecting Python version... 3.2
Detecting Python root... /usr
Unicode/ICU support for Boost.Regex?... /usr
Generating Boost.Build configuration in project-config.jam...


./boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory
compilation terminated.

    ""g++""  -ftemplate-depth-128 -Wno-strict-aliasing -march=native -mtune=native -m64 -pipe -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC  -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG  -I""."" -I""/usr/include/python3.2"" -c -o ""bin.v2/libs/python/build/gcc-4.7.0/release/threading-multi/numeric.o"" ""libs/python/src/numeric.cpp""


",Treeve Jelbert
6824,warning: delete called on boost::error_info... that has virtual functions but non-virtual destructor,exception,Boost 1.56.0,To Be Determined,Bugs,Emil Dotchevski,reopened,2012-04-23T21:19:52Z,2015-02-27T22:09:52Z,"When compiling boost 1.49.0 thread.hpp with clang with -Wall, I receive warnings:

/Users/richardpowell/boost/include/boost/checked_delete.hpp:34:5: warning: delete called on
      'boost::error_info<boost::tag_original_exception_type, const std::type_info *>' that has virtual functions but non-virtual destructor
      [-Wdelete-non-virtual-dtor]
    delete x;

=-=-=

More details:

$ cat test2.cpp 
#include <boost/thread.hpp>

$ clang++ --version
Apple clang version 4.0 (tags/Apple/clang-421.0.11) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix


$ clang++ -g -I. -Wall -I ~/boost/include   -c test2.cpp 
In file included from test2.cpp:1:
In file included from /Users/richardpowell/boost/include/boost/thread.hpp:13:
In file included from /Users/richardpowell/boost/include/boost/thread/thread.hpp:17:
In file included from /Users/richardpowell/boost/include/boost/thread/pthread/thread_data.hpp:10:
In file included from /Users/richardpowell/boost/include/boost/shared_ptr.hpp:17:
In file included from /Users/richardpowell/boost/include/boost/smart_ptr/shared_ptr.hpp:30:
/Users/richardpowell/boost/include/boost/checked_delete.hpp:34:5: warning: delete called on
      'boost::error_info<boost::tag_original_exception_type, const std::type_info *>' that has virtual functions but non-virtual destructor
      [-Wdelete-non-virtual-dtor]
    delete x;
    ^
/Users/richardpowell/boost/include/boost/smart_ptr/detail/shared_count.hpp:95:13: note: in instantiation of function template specialization
      'boost::checked_delete<boost::error_info<boost::tag_original_exception_type, const std::type_info *> >' requested here
            boost::checked_delete( p );
            ^
/Users/richardpowell/boost/include/boost/smart_ptr/shared_ptr.hpp:183:44: note: in instantiation of function template specialization
      'boost::detail::shared_count::shared_count<boost::error_info<boost::tag_original_exception_type, const std::type_info *> >' requested here
    explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be complete
                                           ^
/Users/richardpowell/boost/include/boost/exception/info.hpp:170:42: note: in instantiation of function template specialization
      'boost::shared_ptr<boost::error_info<boost::tag_original_exception_type, const std::type_info *>
      >::shared_ptr<boost::error_info<boost::tag_original_exception_type, const std::type_info *> >' requested here
            shared_ptr<error_info_tag_t> p( new error_info_tag_t(v) );
                                         ^
/Users/richardpowell/boost/include/boost/exception/info.hpp:191:16: note: in instantiation of function template specialization
      'boost::exception_detail::set_info<boost::unknown_exception, boost::tag_original_exception_type, const std::type_info *>' requested here
        return exception_detail::set_info(x,v);
               ^
/Users/richardpowell/boost/include/boost/exception/detail/exception_ptr.hpp:181:21: note: in instantiation of function template specialization
      'boost::operator<<<boost::unknown_exception, boost::tag_original_exception_type, const std::type_info *>' requested here
            (*this) << original_exception_type(&typeid(e));
                    ^
/Users/richardpowell/boost/include/boost/exception/detail/exception_ptr.hpp:160:13: note: in instantiation of function template specialization
      'boost::unknown_exception::add_original_type<std::exception>' requested here
            add_original_type(e);
            ^
1 warning generated.
",Richard Powell <rmpowell77@…>
6822,Patch to fix process_status_failure behaviour,filesystem,Boost Development Trunk,To Be Determined,Patches,Beman Dawes,new,2012-04-22T19:38:53Z,2012-04-22T19:38:53Z,"Some compilers can call ::SetLastError(0) just before process_status_failure function is called, so ::GetLastError() would return 0. It is much safer to call ::GetLastError() in a function, that triggered a failure.[[BR]]
[[BR]]
This error is discussed in threads [http://lists.boost.org/boost-testing/2011/09/6927.php] and [http://www.mail-archive.com/mingw-w64-public@lists.sourceforge.net/msg04512.html] [[BR]]
Patch is provided by Alexander Potocki.",Antony Polukhin
6818,Tuple subscripting,tuple,Boost Development Trunk,To Be Determined,Feature Requests,Joel de Guzman,new,2012-04-21T16:01:36Z,2012-04-21T16:01:36Z,There is a way to put off ugly get<N>(tpl) and replace it by tpl[N_t] using templated-user-defined literals. It would be great to add this feature into corresponding library. In attached file you could find implementation of it.,d.starosud@…
6816,Using transcendental functions with intervals doesn't work,numeric,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-04-21T15:08:31Z,2013-03-11T08:24:57Z,"The examples that use transcendental functions (e.g. ""transc.cpp"") cannot be compiled.",anonymous
6813,canonical function converts root-directory separator from '\' to '/' on Windows,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-20T22:19:33Z,2018-07-11T07:27:45Z,"boost::filesystem::canonical reverses the path separator on rooted paths

Consider the following line:
{{{
boost::filesystem::path convertedPath = boost::filesystem::canonical(""C:\\Foo\\Bar\\..\\Bar\\Baz"");
}}}

On Windows, convertedPath is set to ""C:/Foo\Bar\Baz"", where I would expect it to be set to ""C:\Foo\Bar\Baz""

The documentation states: ""Returns: A canonical path that refers to the same file system object as absolute(p,base).""

If the input path has no symbolic links, 'dot' directories, or 'dot-dot' directories, then I would expect the output to match a call to boost::filesystem::absolute.

For example:
{{{
boost::filesystem::path canonicalPath = boost::filesystem::canonical(""Bar\\Baz"", ""C:\\Foo"");
boost::filesystem::path absolutePath = boost::filesystem::absolute(""Bar\\Baz"", ""C:\\Foo"");
}}}

canonicalPath is set to ""C:/Foo\Bar\Baz"", while absolutePath is set to ""C:\Foo\Bar\Baz"".

Looking at the implementation, this is related to the issue in ticket 5989 (https://svn.boost.org/trac/boost/ticket/5989).  I agree with the sentiments in that ticket, but if the behavior of the path iterator will not be changing, then I think the canonical function should be updated to preseve path consistency in Windows.",Alex Goldberg <alex.goldberg@…>
6811,Default argument of type multi_array fails under MSVC 2010 SP1,multi_array,Boost 1.49.0,To Be Determined,Bugs,Ronald Garcia,new,2012-04-20T07:46:30Z,2012-04-20T07:46:30Z,"When I write a function with the signature

{{{
typedef boost::multi_array<int, 3> T;
void bar(const T &value = T())
}}}
and compile it with MSVC 2010 SP1 I get the following error messages
{{{
E:\postdoc\boost-bug>cl /EHsc /Ie:/postdoc/tools/boost_1_49_0 mar-bug.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

mar-bug.cpp
e:/postdoc/tools/boost_1_49_0\boost/multi_array/multi_array_ref.hpp(73) : error
C3855: 'boost::const_multi_array_ref': template parameter 'NumDims' is incompati
ble with the declaration
        e:/postdoc/tools/boost_1_49_0\boost/multi_array/multi_array_ref.hpp(417)
 : see reference to class template instantiation 'boost::const_multi_array_ref<T
,NumDims,TPtr>' being compiled
        with
        [
            T=int,
            NumDims=0x03,
            TPtr=int *
        ]
        e:/postdoc/tools/boost_1_49_0\boost/multi_array.hpp(113) : see reference
 to class template instantiation 'boost::multi_array_ref<T,NumDims>' being compi
led
        with
        [
            T=int,
            NumDims=0x03
        ]
        mar-bug.cpp(5) : see reference to class template instantiation 'boost::m
ulti_array<T,NumDims>' being compiled
        with
        [
            T=int,
            NumDims=0x03
        ]
}}}

The offending piece of code appears to be in `boost/multi_array/multi_array_ref.hpp`:

{{{
 #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS
   // make const_multi_array_ref a friend of itself
   template <typename,std::size_t,typename>
   friend class const_multi_array_ref;
#endif
}}}

If I give the template arguments names then the compiler is happy (I'll attach a patch).

I have no idea what is special about using the type as a default argument - I tried to reproduce it using simpler steps (copy constructor, default constructor, assigning a temporary to a const ref inside a function) with no luck.",Bruce Merry <bmerry@…>
6810,boost system auto linking is broken in svn trunk 78080,system,Boost Development Trunk,To Be Determined,Bugs,Beman Dawes,new,2012-04-19T18:12:25Z,2012-05-28T17:17:27Z,"I am now getting...

fatal error LNK1104: cannot open file 'boost_system-vc90-mt-gd-1_50.lib'

When I try to build my project. I don't have that library because I am building the default static libraries.   (note: not runtime-static). I instead have libboost_system-vc90-mt-gd-1_50.lib. Did somebody who had the non default dynamically linkable libraries on their system check in a breaking change? We have tried manually defining BOOST_ALL_STATIC_LIB but that does not make a difference. When we manually define BOOST_ALL_NO_LIB that does remove this error but adds a bunch of undefined symbols that are not the obvious location. IE: boost::filesystem::path_traits::convert... does not appear to be in libboost_filesystem.

my libraries are built with simply
bootstrap.bat
b2 --toolset=msvc-9.0

",anonymous
6807,interval rounded_arith.hpp compilation issues (clang),interval,Boost 1.50.0,Boost 1.52.0,Patches,Boris Gubenko,new,2012-04-18T15:51:09Z,2013-03-11T08:30:30Z,"It appears that the rounded _artith_* classes fail to compile (at least with my version of clang : Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn))

The issue appears for both rounded_arith_std and rounded_arith_opp when they try to call the ""to_int"" static method of the Rounding mother class (which is a template parameter). Replacing the call of 
to_int(...) by Rounding::to_int appears to solve the issue. But I did not check if such issue was present at other places.

I have attached a patch file for this header that appears to compile properly.

",Frederic Py <fredpy@…>
6800,endless loop in dev_poll_reactor on Solaris when using async_write with more than 65536 bytes,asio,Boost 1.49.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-04-16T14:39:49Z,2012-04-16T15:47:44Z,"The following example-program puts io_service thread in a tight endless loop on Solaris when the server is trying to send more than 65536 bytes (the server and client have to be running on a different host) and client is running. truss on server process shows following calls continuously.

{{{
/6:     recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0)              Err#11 EAGAIN 
/6:     write(13, "" 9\0\0\019\0\0\0"", 8)                = 8 
/6:     ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460)          = 1 
/6:     recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0)              Err#11 EAGAIN 
/6:     write(13, "" 9\0\0\019\0\0\0"", 8)                = 8 
/6:     ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460)          = 1 
/6:     recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0)              Err#11 EAGAIN 
/6:     write(13, "" 9\0\0\019\0\0\0"", 8)                = 8 
/6:     ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460)          = 1 
/6:     recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0)              Err#11 EAGAIN 
/6:     write(13, "" 9\0\0\019\0\0\0"", 8)                = 8 
/6:     ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460)          = 1 
/6:     recvmsg(57, 0xFFFFFD7FEB9FDDF0, 0)              Err#11 EAGAIN 
/6:     write(13, "" 9\0\0\019\0\0\0"", 8)                = 8 
/6:     ioctl(13, DP_POLL, 0xFFFFFD7FEB9FE460)          = 1 

}}}

The busy-wait loop continues until we stop the client.

Here is the server code. I've just changed boost asynchronous TCP daytime server sample to return the specified number of bytes message instead of daytime and put the client connection in read mode.


{{{
#include <ctime>
#include <iostream>
#include <cstdlib>
#include <string>
#include <boost/bind.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/enable_shared_from_this.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/asio.hpp>
#include <boost/scoped_array.hpp>

using boost::asio::ip::tcp;

std::string make_message(unsigned int message_size)
{
    using namespace std;
    std::string data(message_size, 'A');
   return data;
}

class tcp_connection : public boost::enable_shared_from_this<tcp_connection>
{
public:
    typedef boost::shared_ptr<tcp_connection> pointer;

    static pointer create(boost::asio::io_service& io_service, unsigned int message_size)
    {
        return pointer(new tcp_connection(io_service, message_size));
    }

    tcp::socket& socket()
    {
        return socket_;
    }

    void handleMessage(const boost::system::error_code& message_error)
    {
        if (message_error) {
            std::cout<<""Error while reading the message from client""<<std::endl;
        }
        else {
           std::cout<<""Read the message from client""<<std::endl;
        }
    }

    void start()
    {
        // Perform async_read on client connection to read data from the client.
        _header.reset(new char[6]);
        _header[5] = '\0';
          boost::asio::async_read(socket_, boost::asio::buffer(_header.get(), 5),
            boost::bind(&tcp_connection::handleMessage, shared_from_this(),
                boost::asio::placeholders::error));

        message_ = make_message(message_size_);
        boost::asio::async_write(socket_, boost::asio::buffer(message_),
            boost::bind(&tcp_connection::handle_write, shared_from_this(),
                boost::asio::placeholders::error,
                boost::asio::placeholders::bytes_transferred));
    }

private:
    tcp_connection(boost::asio::io_service& io_service, int message_size)
        : socket_(io_service), message_size_(message_size)
    {
    }

    void handle_write(const boost::system::error_code& /*error*/,
        size_t bytes_transferred)
    {
        std::cout<<""Bytes written: ""<< bytes_transferred << std::endl;
    }

    tcp::socket socket_;
    std::string message_;
    boost::scoped_array<char> _header;
    unsigned int message_size_;
};

class tcp_server
{
public:
    tcp_server(boost::asio::io_service& io_service, unsigned int port,
    unsigned int message_size)
        : acceptor_(io_service, tcp::endpoint(tcp::v4(), port)),
          message_size_(message_size)
    {
        start_accept();
    }

private:
    void start_accept()
    {
        tcp_connection::pointer new_connection =
        tcp_connection::create(acceptor_.get_io_service(), message_size_);

        acceptor_.async_accept(new_connection->socket(),
            boost::bind(&tcp_server::handle_accept, this, new_connection,
                boost::asio::placeholders::error));
    }

    void handle_accept(tcp_connection::pointer new_connection,
        const boost::system::error_code& error)
    {
        if (!error)
        {
            new_connection->start();
           start_accept();
        }
    }

    tcp::acceptor acceptor_;
    unsigned int message_size_;
};

int main(int argc, char* argv[])
{
    if (argc != 3) {
        std::cerr << ""Usage: server port message_size"" << std::endl;
        return 1;
    }

    unsigned int port = boost::lexical_cast<unsigned int>(argv[1]);
    unsigned int message_size = boost::lexical_cast<unsigned int>(argv[2]);

    try {
        boost::asio::io_service io_service;
        tcp_server server(io_service, port, message_size);
        io_service.run();
    }
    catch (std::exception& e) {
        std::cerr << e.what() << std::endl;
    }

    return 0;
}
}}}


For the client we can use boost synchronous TCP daytime client sample (changed to accept port as an argument) .

{{{
#include <iostream>
#include <boost/array.hpp>
#include <boost/asio.hpp>

using boost::asio::ip::tcp;

int main(int argc, char* argv[])
{
    try {
        if (argc != 3) {
            std::cerr << ""Usage: client <host> <port>"" << std::endl;
            return 1;
        }

        boost::asio::io_service io_service;

        tcp::resolver resolver(io_service);
        tcp::resolver::query query(argv[1], argv[2]);
        tcp::resolver::iterator endpoint_iterator = resolver.resolve(query);
        tcp::resolver::iterator end;

        tcp::socket socket(io_service);
        boost::system::error_code error = boost::asio::error::host_not_found;
        while (error && endpoint_iterator != end) {
            socket.close();
            socket.connect(*endpoint_iterator++, error);
        }
        if (error)
            throw boost::system::system_error(error);

        for (;;) {
            boost::array<char, 128> buf;
            boost::system::error_code error;

            size_t len = socket.read_some(boost::asio::buffer(buf), error);

            if (error == boost::asio::error::eof)
                break; // Connection closed cleanly by peer.
            else if (error)
                throw boost::system::system_error(error); // Some other error.

            std::cout.write(buf.data(), len);
        }
    }
    catch (std::exception& e) {
        std::cerr << e.what() << std::endl;
    }

    return 0;
}
}}}

Here is how I ran the server and client on two different solaris hosts -

{{{
server 9081 200000
client <server_host> 9081
}}}

After running the server and client, do ""truss"" on server which will be showing tight polling loop as mentioned above.

The program works fine on Linux and works fine on Solaris when compiled with the flag -DBOOST_ASIO_DISABLE_DEV_POLL.",p_ranadheer@…
6797,Undefined references for program_options library with mingw64.,program_options,Boost 1.49.0,To Be Determined,Support Requests,Vladimir Prus,new,2012-04-16T08:43:49Z,2015-06-09T07:05:39Z,"I compiled a shared version of boost program_options with mingw64. When I try to link against it I get:

{{{
Linking CXX executable ..\..\..\binary\abc.exe
CMakeFiles\abc.dir/objects.a(test.cpp.obj):test.cpp:(.text+0x65bf): undefined reference to `boost::program_options::detail::common_config_file_iterator::c
ommon_config_file_iterator(std::set<std::string, std::less<std::string>, std::allocator<std::string> > const&, bool)'
CMakeFiles\abc.dir/objects.a(test.cpp.obj):test.cpp:(.text+0x6672): undefined reference to `boost::program_options::detail::common_config_file_iterator::g
et()'
CMakeFiles\abc.dir/objects.a(test.cpp.obj):test.cpp:(.text+0x7871): undefined reference to `boost::program_options::detail::common_config_file_iterator::g
et()'
collect2: ld returned 1 exit status
}}}

I use cmake for my project and everything works fine under linux.
nm gives the following output:
{{{
$ nm libboost_program_options.dll | grep common_config_file_iterator
000000006e1a62c0 d .data$_ZTIN5boost12eof_iteratorINS_15program_options6detail27common_config_file_iteratorENS1_12basic_optionIcEEEE
000000006e1a62e0 d .data$_ZTIN5boost15iterator_facadeINS_15program_options6detail27common_config_file_iteratorEKNS1_12basic_optionIcEENS_21forward_traversal_tag
ERS6_xEE
000000006e1a6660 d .data$_ZTIN5boost15program_options6detail27common_config_file_iteratorE
000000006e1a96a0 d .data$_ZTVN5boost15program_options6detail27common_config_file_iteratorE
000000006e1b578c p .pdata$_ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs
000000006e1b58d0 p .pdata$_ZN5boost15program_options6detail27common_config_file_iteratorD0Ev
000000006e1b58c4 p .pdata$_ZN5boost15program_options6detail27common_config_file_iteratorD1Ev
000000006e1b5d38 p .pdata$_ZN5boost15program_options6detail27common_config_file_iteratorD2Ev
000000006e1b18e0 r .rdata$_ZTSN5boost12eof_iteratorINS_15program_options6detail27common_config_file_iteratorENS1_12basic_optionIcEEEE
000000006e1b1960 r .rdata$_ZTSN5boost15iterator_facadeINS_15program_options6detail27common_config_file_iteratorEKNS1_12basic_optionIcEENS_21forward_traversal_ta
gERS6_xEE
000000006e1b20e0 r .rdata$_ZTSN5boost15program_options6detail27common_config_file_iteratorE
000000006e108c20 t .text$_ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs
000000006e108c30 t .text$_ZN5boost15program_options6detail27common_config_file_iteratorD0Ev
000000006e108e00 t .text$_ZN5boost15program_options6detail27common_config_file_iteratorD1Ev
000000006e108fc0 t .text$_ZN5boost15program_options6detail27common_config_file_iteratorD2Ev
000000006e1be600 r .xdata$_ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs
000000006e1be74c r .xdata$_ZN5boost15program_options6detail27common_config_file_iteratorD0Ev
000000006e1be740 r .xdata$_ZN5boost15program_options6detail27common_config_file_iteratorD1Ev
000000006e1beadc r .xdata$_ZN5boost15program_options6detail27common_config_file_iteratorD2Ev
000000006e198fe0 t _GLOBAL__sub_I__ZN5boost15program_options6detail27common_config_file_iteratorC2ERKSt3setISsSt4lessISsESaISsEEb
000000006e0cd800 T _ZN5boost15program_options6detail27common_config_file_iterator10add_optionEPKc
000000006e0cde20 T _ZN5boost15program_options6detail27common_config_file_iterator3getEv
                 U _ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs
000000006e108c20 T _ZN5boost15program_options6detail27common_config_file_iterator7getlineERSs
000000006e0ceda0 T _ZN5boost15program_options6detail27common_config_file_iteratorC1ERKSt3setISsSt4lessISsESaISsEEb
000000006e0da700 t _ZN5boost15program_options6detail27common_config_file_iteratorC2ERKS2_.constprop.235
000000006e0ceda0 T _ZN5boost15program_options6detail27common_config_file_iteratorC2ERKSt3setISsSt4lessISsESaISsEEb
000000006e108c30 T _ZN5boost15program_options6detail27common_config_file_iteratorD0Ev
                 U _ZN5boost15program_options6detail27common_config_file_iteratorD0Ev
                 U _ZN5boost15program_options6detail27common_config_file_iteratorD1Ev
000000006e108e00 T _ZN5boost15program_options6detail27common_config_file_iteratorD1Ev
000000006e108fc0 T _ZN5boost15program_options6detail27common_config_file_iteratorD2Ev
000000006e0cd660 T _ZNK5boost15program_options6detail27common_config_file_iterator14allowed_optionERKSs
000000006e1a62c0 D _ZTIN5boost12eof_iteratorINS_15program_options6detail27common_config_file_iteratorENS1_12basic_optionIcEEEE
000000006e1a62e0 D _ZTIN5boost15iterator_facadeINS_15program_options6detail27common_config_file_iteratorEKNS1_12basic_optionIcEENS_21forward_traversal_tagERS6_x
EE
000000006e1a6660 D _ZTIN5boost15program_options6detail27common_config_file_iteratorE
000000006e1b18e0 R _ZTSN5boost12eof_iteratorINS_15program_options6detail27common_config_file_iteratorENS1_12basic_optionIcEEEE
000000006e1b1960 R _ZTSN5boost15iterator_facadeINS_15program_options6detail27common_config_file_iteratorEKNS1_12basic_optionIcEENS_21forward_traversal_tagERS6_x
EE
000000006e1b20e0 R _ZTSN5boost15program_options6detail27common_config_file_iteratorE
000000006e1a96a0 D _ZTVN5boost15program_options6detail27common_config_file_iteratorE
}}}

The command I use to build boost is:
{{{
b2 --toolset=gcc variant=release address-model=64 threading=multi optimization=speed link=shared runtime-link=shared cxxflags='-DBOOST_USE_WINDOWS_H -std=gnu++0x -march=core2 -mtune=core2 -msse -msse2 -mssse3 -msse4' --with-thread --with-dat
e_time --with-filesystem --with-program_options --prefix=c:/temp/boost install
}}}

I attach a minimal cmake project (I used Boost 1.48.0 there, but it makes no difference).",tasptz@…
6793,Support construction from range,array,Boost 1.49.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2012-04-14T20:46:23Z,2012-12-17T17:31:46Z,"Could you support construction from a range and from an iterator pair?
I don't know what to do when the input doesn't match the array size. If it's smaller you could default construct the rest of the array. If it's larger, you could truncate, std::terminate() or throw.
Or just consider it undefined behaviour.",Olaf van der Spek <olafvdspek@…>
6778,directory_iterator and recursive_directory_iterator has inconsistent behavior with STL iterator when assignment operator=() is involved.,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-09T23:49:26Z,2012-04-09T23:49:26Z,"For example, in std::vector, the following code shows that *vIterator_1 prints out intVec[1] and *vIteraotr_2 prints out intVec[0].  (The assignment operator=() does not make those two iterators link together...)
{{{
std::vector<int> intVec(10);
intVec[1] = 1;
std::vector<int>::iterator vIterator_1 = intVec.begin();

// iterator assignment operator=() now get involved.
std::vector<int>::iterator vIterator_2 = vIterator_1;  
++vIterator_1;  // vIterator_2 does not increment.
std::cout << ""*vIterator_1: "" << *vIterator_1;
std::cout << ""*vIterator_2: "" << *vIterator_2;
}}}

On the other hand, the following example shows that dirIterator1->path() and dirIterator2->path() both contains '/home/user/test/2.txt' which is not consistent with STL iterator behavior. Since iterators behaves like pointers, after calling vIterator_2 = vIterator_1;, vIterator_2 and vIterator_1 should stays independent.  The problem seems to be directory_iterator forgot to implement the copy constructor and assignment operator=().

{{{
// assuming that under /home/user/test, there are 1.txt and 2.txt
boost::filesystem::path rootPath(""/home/user/test"");
boost::filesystem::directory_iterator dirIterator1(rootPath);

// Now assignment operator=() got involved.
boost::filesystem::directory_iterator dirIterator2 = dirIterator1;

// This line causes dirIterator1 and dirIterator2 both got incremented ...
++dirIterator1;  

std::cout << ""dirItertor1: "" << dirIterator1->path().string() << std::endl;
std::cout << ""dirItertor2: "" << dirIterator2->path().string() << std::endl;
}}}


== Note ==
The symptom occurred in:

boost::filesystem::directory_iterator[[BR]]
boost::filesystem2::directory_iterator[[BR]]
boost::filesystem3::directory_iterator[[BR]]
boost::filesystem::recursive_directory_iterator[[BR]]
boost::filesystem2::recursive_directory_iterator[[BR]]
boost::filesystem3::recursive_directory_iterator[[BR]]

under all platforms.",Chih-Yao Hsieh <josephsieh@…>
6775,"boost::filesystem::path cannot be created from lexical_cast("""")",filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-09T14:04:32Z,2012-04-09T14:04:32Z,"The boost {{{filesystem::path}}} can hold an ""empty"" state, where {{{.string()}}} returns {{{""""}}}. It even has a designated check for this state, {{{empty()}}} This state is useful as a kind of null-value, to turn on or off certain behavior.

However, this state cannot be reached through {{{lexical_cast}}}, the following code will for example end with a {{{boost::bad_lexical_cast}}} error.

{{{
#include <boost/lexical_cast.hpp>
#include <boost/filesystem/path.hpp>
#include <string>

int main() {
  boost::filesystem::path str = boost::lexical_cast<boost::filesystem::path, std::string>("""");
  return 0;
}
}}}

IMO, this is a bug. {{{path}}} clearly has a normal and useful {{{empty()}}} state, which cannot for some reason be reached through {{{lexical_cast}}}. The equivalent test works for {{{std::string}}}, for example, so should not be inherent problem with {{{lexical_cast}}} itself.

One consequence is that {{{path}}} cannot be used as a value-type for {{{program_options}}}, while allowing options with default-values to be turned of using empty values. (I.E. {{{--config-file """"}}})",Ulrik Mikaelsson <ulrik.mikaelsson@…>
6772,Regression on Sandia-gcc-4.3.4_0x when refactoring base_from_member code for T&&,utility,Boost Development Trunk,To Be Determined,Bugs,Daniel Wallin,new,2012-04-07T00:19:06Z,2012-06-03T19:58:53Z,"Since the introduction of 
 svn log boost/utility/base_from_member.hpp 
------------------------------------------------------------------------
r77046 | dlwalker | 2012-02-17 02:55:33 +0100 (Ven, 17 fév 2012) | 1 line

Fixed (hopefully) conflict between boost::base_from_member's C++11 constructor template and the automatically defined non-template copy- and/or move-constructors.
------------------------------------------------------------------------
r76982 | dlwalker | 2012-02-11 19:27:02 +0100 (Sam, 11 fév 2012) | 1 line

Updated boost::base_from_member for C++2011.

There is an error on


{{{
Test output: Sandia-gcc-4.3.4_0x - format - format_test1 / gcc-4.3.4_0x
Rev 77789 / Fri, 6 Apr 2012 05:57:33 +0000
Report Time: Fri, 6 Apr 2012 22:01:09 +0000

Compile [2012-04-06 07:43:02 UTC]: fail

    ""/sierra/Sntools/extras/compilers/gcc-4.3.4/bin/g++""  -ftemplate-depth-128 -std=gnu++0x -O0 -fno-inline -Wall -g -fPIC  -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1  -I"".."" -c -o ""/scratch/kbelco/boost/results/boost/bin.v2/libs/format/test/format_test1.test/gcc-4.3.4_0x/debug/format_test1.o"" ""../libs/format/test/format_test1.cpp""

../boost/utility/base_from_member.hpp: In constructor ???boost::base_from_member<MemberType, UniqueID>::base_from_member(T&& ...) [with T = boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> >*&, boost::io::basic_oaltstringstream<char, std::char_traits<char>, std::allocator<char> >::No_Op, EnableIf = void, MemberType = boost::shared_ptr<boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> > >, int UniqueID = 0]???:
../boost/format/alt_sstream.hpp:146:   instantiated from ???boost::io::basic_oaltstringstream<Ch, Tr, Alloc>::basic_oaltstringstream(boost::io::basic_altstringbuf<Ch, Tr, Alloc>*) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>]???
../boost/format/feed_args.hpp:142:   instantiated from ???void boost::io::detail::put(T, const boost::io::detail::format_item<Ch, Tr, Alloc>&, typename boost::basic_format<Ch, Tr, Alloc>::string_type&, typename boost::basic_format<Ch, Tr, Alloc>::internal_streambuf_t&, boost::io::detail::locale_t*) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const char (&)[11]]???
../boost/format/feed_args.hpp:253:   instantiated from ???void boost::io::detail::distribute(boost::basic_format<Ch, Tr, Alloc>&, T) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const char (&)[11]]???
../boost/format/feed_args.hpp:263:   instantiated from ???boost::basic_format<Ch, Tr, Alloc>& boost::io::detail::feed(boost::basic_format<Ch, Tr, Alloc>&, T) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const char (&)[11]]???
../boost/format/format_class.hpp:64:   instantiated from ???boost::basic_format<Ch, Tr, Alloc>& boost::basic_format<Ch, Tr, Alloc>::operator%(const T&) [with T = char [11], Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>]???
../libs/format/test/format_test1.cpp:40:   instantiated from here
../boost/utility/base_from_member.hpp:137: error: invalid static_cast from type ???boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> >*??? to type ???T&&???

}}}
",viboes
6768,missing std:: qualifier on sqrt calls,numeric,Boost 1.49.0,To Be Determined,Bugs,Douglas Gregor,new,2012-04-05T20:05:04Z,2012-04-05T20:05:04Z,"File libs/numeric/ublas/test/test_complex_norms.cpp includes <cmath> and then calls sqrt twice without a std:: qualifier. Although the code works with some compilers, it is not portable. The C++ standard says that if you include a <cxxx> headaer (like <cmath>) the names in the headers are (only) in namespace std.
Diffs to fix the file:
{{{
37c37
<     const double expected = sqrt(44.0);
---
>     const double expected = std::sqrt(44.0);
65c65
<     const float expected = sqrt(44.0);
---
>     const float expected = std::sqrt(44.0);
}}}",Stephen Clamage <stephen.clamage@…>
6765,boost::mem_fn not entirely compatible with std::mem_fn,bind,Boost 1.49.0,To Be Determined,Feature Requests,Peter Dimov,new,2012-04-05T10:37:15Z,2012-04-05T10:37:15Z,"boost::mem_fn only supports calling member functions through proxies when the proxy type has a matching get_pointer function. This is not necessary for std::mem_fn (20.8.10) as the second or fourth item of INVOKE (20.8.2) should apply in such a case.

A solution would be to change _mfi::dm::call(U const& u, void const*) to simply call (*u).*f_

I couldn't find any documentation why exactly get_pointer is used and don't know which implications this might have, but it would be a nice to have feature (and would also allow mem_fn to work on iterators which are often used as handles).",philipp.moeller@…
6764,rbtree_best_fit breaks if allocation alignment doesn't match the segment manager alignment,interprocess,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-04-05T08:11:57Z,2014-04-04T09:50:15Z,"I have a shared memory queue. The memory segment is divided into 3 parts: a header, a fixed number of element descriptors and an area available for element bodies. The latter is managed by a segment manager with the rbtree_best_fit allocation strategy, which is initialized so that it doesn't use the area with the element descriptors.

If the allocation strategy uses default alignment settings, everything works as expected. But if a stricter alignment requirement is specified (32 bytes in my case), the rbtree_best_fit::priv_add_segment function fails with assertion failure 'priv_end_block() == end_block'.

Apparently, the root of the issue is in the fact that the segment manager itself in my case is not aligned to 32 bytes (but is aligned sufficiently to be operated on). This configuration worked fine with Boost 1.46 but fails with 1.48. I think, such configuration is valid and the code should be made to support it.

I have attached a test case that demonstrates the issue. I'm running on Linux, x86-64, gcc 4.6.

PS: I also have a side question. As you may see in the code, I try to estimate the shared memory segment size to allocate. I assume the segment manager will add an overhead per allocation for its bookkeeping but I failed to see how I can discover the amount of this overhead, so I hardcoded 64 bytes. Is there a better way to do this?
",Andrey Semashev
6761,boost::filesystem::absolute mixes generic and native format,filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2012-04-03T15:53:15Z,2012-05-28T17:21:40Z,"Under Windows:
{{{
absolute(wpath(L""test/filename.ext"")).native()
}}}
returns something akin to
 c:\somedir\test/filename.ext

The problem is that ''absolute'' uses the current working directory when no cwd is given and the cwd under windows uses backslash. wpath using forward slash is valid, but the resulting path uses both, back- and forward slash, which is invalid and cannot be passed to ::CreateFile for example.

absolute must verify that all parts use the same path delimiter.",hajokirchhoff
6759,boost::wave::support_option_option_new_line didn't work as expected.,wave,Boost 1.49.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-04-02T09:51:09Z,2012-05-23T12:55:34Z,"I think following code is error:

if ((!seen_newline || act_pos.get_column() > 1) && 
    !need_single_line(ctx.get_language())) 
{
// warn, if this file does not end with a newline
    BOOST_WAVE_THROW_CTX(ctx, preprocess_exception,
        last_line_not_terminated, """", act_pos);
}

I think we hope that error reported if ""newline not found"" while ""need single line""",wuye9036@…
6757,Add lzw_compressor and lzw_decompressor filters,iostreams,Boost 1.49.0,To Be Determined,Feature Requests,Jonathan Turkanis,new,2012-04-01T19:00:11Z,2012-04-01T19:00:11Z,"Boost.IOstreams has support for BZ2, GZIP, and DEFLATE compression/decompression.  To be able to read output from the POSIX-standard `compress` utility, it would be nice if the library also supported compression and decompression with the Lempel-Ziv-Welch (LZW) algorithm.

Here are some LZW implementations that might be of use:

* [http://marknelson.us/2011/11/08/lzw-revisited/ LZW Revisited] by Mark Nelson
* [http://michael.dipperstein.com/lzw/ Lempel-Ziv-Welch (LZW) Encoding Discussion and Implementation] by Michael Dipperstein
* [http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/lzw libfreetype2's LZW support]
* [http://rosettacode.org/wiki/LZW_compression LZW compression] on Rosetta Code",dtrebbien@…
6756,"gcc gives compile error ""error ‘boost_se_params_t_10::boost_se_param_t_0_10’ is not a type"" in template function for ScopeExit.",scope_exit,Boost 1.49.0,To Be Determined,Bugs,nasonov,new,2012-04-01T14:12:42Z,2012-04-01T15:04:09Z,"When using ScopeExit, I found that gcc can't compile some sources.
After error checking, gcc (4.4.3 in Ubuntu 10.04 and gcc 4.6.1 from MinGW) will raise compile error when I use ScopeExit in template functions.
For the code can't compile by gcc, you can find it in attachment.","Lin, Yi-Li <record.nctu.cis91@…>"
6753,Make message_queue_t::do_send(...) public.,interprocess,Boost 1.49.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2012-03-31T15:47:15Z,2012-03-31T15:47:15Z,"In the file boost/interprocess/ipc/message_queue.hpp, it would be useful if the member function:

{{{
bool message_queue_t::do_send(...)
}}}

was public. 

Doing so, it would be easier to determine the policy to be followed when the memory block is full, using a parameter instead of a further external switch statement.",Pietro Mele <pietrom16@…>
6752,"Addition of cbrt, min, max",units,Boost 1.48.0,To Be Determined,Feature Requests,Matthias Schabel,new,2012-03-31T08:18:23Z,2012-03-31T08:18:23Z,"LS, please consider adding the cubic root and min/max functions to the boost.units library. I have included an implementation and unit tests (all fairly trivial) in cmath.hpp and test_cmath.cpp. Maybe the min/max should be placed elsewhere as these are not part of the original cmath header-it might be nice to have a place (header) for future similar additions. Thanks for your consideration!  - Pieter ",pieterb@…
6746,Boost fails to build 64-bit on Solaris sparc with toolset=gcc,build,Boost 1.38.0,To Be Determined,Bugs,Vladimir Prus,new,2012-03-29T21:24:55Z,2013-01-03T17:56:54Z,"Boost 1.38.0 is needed in order to build PowerDNS, as PowerDNS specifically looks for libboost_program_options_*gcc*.so.

I have tried each and every permutation to convince the Boost build system that it is really OK to use GCC on the sparc platform with Solaris's linker and assembler, but to no avail.

The following is used:

tools/jam/src/bin.solaris/bjam -d4 -j2 --without-mpi --toolset=gcc --prefix=/opt/boost --libdir=/opt/boost/lib/64 address-model=64 cxxflags=-m64 linkflags=-m64

...and here is one of many identical failures during the build process:

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthreads -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG  -I""."" -c -o ""bin.v2/libs/math/build/gcc-3.4.3/release/address-model-64/threading-multi/expm1.o"" ""libs/math/build/../src/tr1/expm1.cpp""

/usr/ccs/bin/as: error: unknown option '-'
/usr/ccs/bin/as: error: unknown option 't'
/usr/ccs/bin/as: error: unknown option 'aditional-format'
/usr/ccs/bin/as: error: unknown option '6'
/usr/ccs/bin/as: error: unknown option '4'
/usr/ccs/bin/as: error: unknown option 'A'
/usr/ccs/bin/as: error: unknown option '9'
usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s]
        [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T]
        [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
        [-m [-Ym,path]] [-n] [-ul] [-xF]
        [-m32] [-m64]
        [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis,sparcvis2,sparcvis3,sparcfmaf,sparcima}]
        [-xcode={pic13,pic32}] file.s...
0.000129 sec system; 0.003178 sec user
...failed gcc.compile.c++ bin.v2/libs/math/build/gcc-3.4.3/release/address-model-64/threading-multi/expm1.o...

Upgrading to newer version of Boost has been unsuccessful, as PowerDNS's ./configure specifically looks for library version in the .so file name, and this has changed sometime after the 1.38.0 revision.

Where is the linker getting the ""-t aditional-format 64A9' from, and why does this happen only on sparc?",tripivceta@…
6736,boost::ptr_unordered_map and some other ptr container's classes aren't listen in library reference,ptr_container,Boost 1.49.0,To Be Determined,Bugs,Thorsten Ottosen,new,2012-03-27T11:44:25Z,2012-03-27T11:44:44Z,"There is no ptr_unordered_map in ptr container's reference
http://www.boost.org/doc/libs/1_49_0/libs/ptr_container/doc/reference.html

It's slightly confusing for the beginner who searching for it: looks like there is no such class at all.
",anonymous
6731,decltype-based boost::result_of does not conform to std::result_of,result_of,Boost Development Trunk,To Be Determined,Bugs,Daniel Walker,new,2012-03-24T09:04:49Z,2012-09-25T14:03:39Z,"`std::result_of` is equivalent to 
{{{
decltype(INVOKE(declval<Fn>(), declval<ArgTypes>()…))
}}}
and so it can deal with pointers to member data. 
Current implementation of decltype-based `boost::result_of` cannot deal with pointers to member data. 
",Michel Morin
6730,error reading archive created by old version when it contains pointer,serialization,Boost 1.45.0,To Be Determined,Bugs,Robert Ramey,new,2012-03-24T06:11:08Z,2012-05-28T17:22:50Z,"Problem is similar to ticket 4660.  Fwiw we just discovered a gap
in our unit tests. :(

Code below contains our local fix.  Note that we only have used
lib ver 3 and lib ver 5 and that this is the reason the fix only 
targets those versions.

One last word, I checked the latest code ( 1.49 ) and it seems to
contain the same flaw as 1.45.

{{{
    void load_override(class_id_type & t, int version){
        library_version_type lvt = this->get_library_version();
        if(boost::archive::library_version_type(7) < lvt){
            this->detail_common_iarchive::load_override(t, version);
        }
        else
        if(boost::archive::library_version_type(6) < lvt){
            int_least16_t x=0;
            * this->This() >> x;
            t = boost::archive::class_id_type(x);
        }
        else
        if(boost::archive::library_version_type(3) == lvt || boost::archive::library_version_type(5) == lvt ){
#pragma message( ""CTMS fix for serialization bug ( lack of backwards compatability ) introduced by boost 1.45."" )
            int_least16_t  x=0;
            * this->This() >> x;
            t = boost::archive::class_id_type(x);
        }
        else{
            int x=0;
            * this->This() >> x;
            t = boost::archive::class_id_type(x);
        }
    }

}}}


",d s m a l l @…
6722,Incorrect behaviour of boost::iostreams::filtering_stream with boost::iterator_range,iostreams,Boost 1.48.0,To Be Determined,Bugs,Jonathan Turkanis,new,2012-03-21T14:12:51Z,2012-10-08T03:13:57Z,"Please consider the following code:

{{{
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/range/iterator_range.hpp>
#include <sstream>

template <class Stream>
std::string read_to_string(Stream& stream)
{
   std::ostringstream destStream;
   destStream << stream.rdbuf();
   return destStream.str();
}

void main()
{
   std::istringstream sourceStream(""123"");

   std::istream_iterator<char> begin(sourceStream);
   std::istream_iterator<char> end;
   auto range = boost::make_iterator_range(begin, end);

   boost::iostreams::filtering_stream<boost::iostreams::input> sourceFilteringStream;
   sourceFilteringStream.push(range, 1);

   std::string output = read_to_string(sourceFilteringStream);
   BOOST_ASSERT(""123"" == output);
}
}}}

After each char from ""sourceStream"" it produces additional garbage char in ""output"" and triggers the assert (at least in VS10).
I've traced it to this code in boost/iostreams/detail/adapter/range_adapter.hpp:

{{{
template<>
struct range_adapter_impl<std::forward_iterator_tag> {
    template<typename Iter, typename Ch>
    static std::streamsize read
        (Iter& cur, Iter& last, Ch* s,std::streamsize n)
    {
        std::streamsize rem = n; // No. of chars remaining.
        while (cur != last && rem-- > 0) *s++ = *cur++;
        return n - rem != 0 ? n - rem : -1;
    }
    ...
}}}
""rem"" becomes -1 after the end of the while-loop and the return value after reading 1 char is 2.",vadik.stepanov@…
6719,Interprocess shared_memory 1.48 files deleted by prior versions...,interprocess,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-03-20T19:55:34Z,2012-03-20T19:55:34Z,"This is reproducible on OSX.

In boost 1.48.0, shared_memory creates a folder in /tmp/ called boost_interprocess/ all shared memory files are put in that folder.

In boost 1.47.0 and prior, shared_memory creates a folder in /tmp/ called boost_interprocess/
and in there, it would create another sub-directory named by the boottime.  It would also delete any other folders/files located in /tmp/boost_interprocess

The problem is, now that I am using boost 1.48, my application uses /tmp/boost_interprocess.
If any program using boost 1.47.0 shared memory, it will delete every files and folder in /tmp/boost_interprocess (which is what boost 1.48 uses.)

I surely have the access to all my programs, and can make sure we are all using boost 1.48+, but I can't guarantee that the user doesn't have a program using boost 1.47 or prior...

To fix this, there's one easy way, change the folder name boost_interprocess to something else... boost_interprocess2 for example.  Hence, boost 1.47 will only delete what's in /tmp/boost_interprocess and leave all the other programs using /tmp/boost_interprocess2 in peace...

or you could give the option to the users to change that folder name.",monkey.d@…
6710,Boost Containers Using interprocess Basic_strings Need external temporaries,container,Boost 1.49.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2012-03-20T00:22:42Z,2012-03-21T20:53:33Z,"When using an interprocess basic string such as:
typedef boost::interprocess::allocator<
        char,
        boost::interprocess::managed_mapped_file::segment_manager
  >                                         char_allocator_t;

typedef boost::interprocess::basic_string<
        char, 
        std::char_traits<char>,
        char_allocator_t
  >                                      key_type;

map, flat_map (and unordered_map) all require that one have an externally created temporary of that type (key_type) created that can temporarily hold the results of a std::string or char*.  This requires code of the form:

      // A temporary string that allocates from the mapped file
      struct shm_clean { // cleanup shared memory on stack-unwind
        shm_clean() { 
          boost::interprocess::shared_memory_object::remove(""StupidSharedMemory"");
        }
        ~shm_clean() {
          boost::interprocess::shared_memory_object::remove(""StupidSharedMemory"");
        }
      } cleaner;
      boost::interprocess::managed_shared_memory
stupid(boost::interprocess::create_only ,""StupidSharedMemory"" ,500);
      key_type key_val(stupid.get_segment_manager());

mymap_in_shared_memory[key_val = mystring.c_str()] = junk;

This is barely ok when we are working with mutable memory regions, but when I am working in a read-only memory map, it is annoying.

Please see this thread:

http://thread.gmane.org/gmane.comp.lib.boost.devel/228874

Bug posted at request of Ion Gaztañaga

Joel",jdy@…
6706,Mersenne Twister discard() speed improvement,random,Boost 1.48.0,To Be Determined,Tasks,No-Maintainer,new,2012-03-19T11:12:15Z,2014-04-05T18:34:27Z,"There is an algorithm for fast jump ahead for the MT:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/JUMP/index.html


Some more references (thanks Topher!)

Hiroshi Haramoto, Makoto Matsumoto, and Pierre L'Ecuyer. 2008. A Fast Jump Ahead Algorithm for Linear Recurrences in a Polynomial Space. In /Proceedings of the 5th international conference on Sequences and Their Applications/ (SETA '08), Solomon W. Golomb, Matthew G. Parker, Alexander Pott, and Arne Winterhof (Eds.). Springer-Verlag, Berlin, Heidelberg, 290-298. DOI=10.1007/978-3-540-85912-3_26 http://dx.doi.org/10.1007/978-3-540-85912-3_26

An accessible online copy is at:

http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/ARTICLES/jump-seta-lfsr.pdf

If I understand it correctly, whether or not it is ""constant time"" is a bit ambiguous.  Applying it to an arbitrary MT generator requires O(k^1.6^) where k is the size of the state, and k must be moderately large before this asymptote is approached. For a particular generator the k is a constant so it is ""constant time"" -- i.e., constant in the size of the jumps.  So, for example, k for MT19937 is 19937 and so is k^1.6^ (about 7.5 million).  The timing tests in the paper seem to indicate reasonable performance for common applications (e.g., where generating the jumps is done infrequently relative to the number of calls to the generators themselves).",info@…
6704,Boost version of mpi_in_place,mpi,Boost 1.48.0,To Be Determined,Bugs,Matthias Troyer,new,2012-03-19T10:33:21Z,2013-08-29T14:40:15Z,"In some mpi collective operations, like [http://www.open-mpi.org/doc/v1.4/man3/MPI_Allreduce.3.php all_reduce], that have an input and output bufer of the same size, it is possible to specify the same buffer for both input and output by using the MPI_IN_PLACE constant as a sendbuffer (see above link).

That feature does not seems to be supported through boost::mpi.

This can be illustrated through the attached program:
{{{
alainm@vai:~/code/boost/mpibug$ mpiexec -np 2 ./a.out 
This is P0 good
This is P1 good
alainm@vai:~/code/boost/mpibug$ 
}}}

{{{
alainm@vai:~/code/boost/mpibug$ mpiexec -np 2 ./a.out bug
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::mpi::exception> >'
  what():  MPI_Allreduce: MPI_ERR_BUFFER: invalid buffer pointer
[vai:03464] *** Process received signal ***
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::mpi::exception> >'
  what():  MPI_Allreduce: MPI_ERR_BUFFER: invalid buffer pointer
[vai:03465] *** Process received signal ***
[vai:03465] Signal: Aborted (6)
[vai:03465] Signal code:  (-6)
[vai:03464] Signal: Aborted (6)
[vai:03464] Signal code:  (-6)
[vai:03465] [ 0] [0x4002040c]
[vai:03465] *** End of error message ***
[vai:03464] [ 0] [0x4002040c]
[vai:03464] *** End of error message ***
--------------------------------------------------------------------------
mpiexec noticed that process rank 1 with PID 3465 on node vai exited on signal 6 (Aborted).
--------------------------------------------------------------------------
2 total processes killed (some possibly by mpiexec during cleanup)
alainm@vai:~/code/boost/mpibug$ 
}}}

",Alain Miniussi <alain.miniussi@…>
6701,integer overflows in ordered_malloc(),pool,Boost Development Trunk,To Be Determined,Bugs,John Maddock,new,2012-03-18T02:08:33Z,2015-08-20T09:17:11Z,"Consider pool::ordered_malloc(size_type n).

    const size_type total_req_size = n * requested_size;

Given a large n, total_req_size will wrap around to a small integer.  The allocated memory would be smaller than expected, leading to a potential buffer overflow.
",Xi Wang <xi.wang@…>
6688,better support for exporting symbols from DLL,asio,Boost Development Trunk,To Be Determined,Feature Requests,chris_kohlhoff,new,2012-03-15T05:53:03Z,2012-03-19T03:52:41Z,"Currently asio/detail/config.hpp only supports exporting symbols from compilers that supports __declspec (i.e. msvc). In order to support many more compilers, including GCC (and gcc compatibles) and sun studio etc. The config header could be simplified to use boost config's BOOST_SYMBOL_EXPORT/IMPORT macro.

Patch against trunk is attached.",arvid@…
6686,Boost does not build with Xcode 4.3,build,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-03-14T18:36:29Z,2013-01-03T18:04:26Z,"With Xcode 4.3, Apple changed it's layout of the SDKs. The folder /Developer does not exist anymore. Instead everything is contained withing the Xcode.app: /Applications/Xcode.app/Contents/Developer is the new starting point. However, the darwin.jam file also globs at the wrong position. The new SDKs for Xcode 4.3.1 are at /Applications/Xcode.app/Contents/Developer/Platforms/*/Developer/SDKs/*.sdk
",arne.schmitz@…
6684,clang-darwin: handle LTO in archives,build,Boost 1.49.0,To Be Determined,Patches,Vladimir Prus,new,2012-03-13T15:09:48Z,2012-03-28T07:10:55Z,,Bruno Santos <bsantos@…>
6683,find family of functions needs const Range1T& Input overloads,algorithm,Boost 1.48.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2012-03-13T14:16:05Z,2012-03-14T08:54:17Z,"It's cumbersome to have to create named temporaries when searching using these functions. I presume the reason for why Input isn't const is due to the fact that iterator_range<> that's returned can modify Input. In the spirit of std & the rest of boost I propose an overload which returns const_iterator_range<>, which would provide the same functionality as iterator_range<> save for being able to modify the source.",sairony@…
6679,[asio] request : repeat timer,asio,Boost 1.49.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2012-03-12T08:01:08Z,2012-03-12T08:01:08Z,"This ticket is feature request.
I want repeat feature in deadline_timer/waitable_timer.
Many libraries timer have repeat features.
follow code is example.


before:
{{{
void on_timer(error_code error, steady_timer& timer)
{
    if (error)
        return;

    timer.expires_from_now(seconds(1));
    timer.async_wait(boost::bind(&on_timer, _1, boost::ref(timer)));
}

int main()
{
    ...
    timer.expires_from_now(seconds(1));
    timer.async_wait(boost::bind(&on_timer, _1, boost::ref(timer)));
}
}}}

after:
{{{
void on_timer(error_code error, steady_timer& timer)
{
    if (error)
        return;

    // no boiler plate
}

int main()
{
    ...
    timer.expires_from_now(seconds(1), steady_timer::repeat);
    timer.async_wait(boost::bind(&on_timer, _1, boost::ref(timer)));
}
}}}",Akira Takahashi <faithandbrave@…>
6668,support overloads of read_xxx from boost::filesystem::path,property_tree,Boost Development Trunk,To Be Determined,Feature Requests,Sebastian Redl,new,2012-03-09T09:32:39Z,2013-03-01T09:19:14Z,"It would be great to have overloads of

read_info
read_json
read_xml
read_ini

from boost::filesystem::path.
",vanyacpp@…
6664,"std::setw() is ignored by operator<< for ptime, time_duration, and date",date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2012-03-08T21:15:41Z,2012-03-08T21:15:41Z,"The following complete program demonstrates the issue.  when using operator<< to display a ptime/time_duration/date, then the setw() manipulator is ignored. 

My development environment is boost 1.48, building a 32-bit app on Win7 (x64) under VS2008. 

I consider this a cosmetic issue as there is a very simple work-aroud - simply manually convert the ptime/date/duration object to a string before inserting it into the ostream object.

{{{
#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/date_time/gregorian/gregorian.hpp>
#include <iomanip>
#include <iostream>
#include <string>


int main()
{

    boost::posix_time::ptime const now = boost::posix_time::second_clock::local_time();

    std::cout 
        << ""\ncorrectly formatted: "" << std::setw(40) << boost::posix_time::to_simple_string(now)
        << ""\nptime:               "" << std::setw(40) << now
        << ""\ntime_duration:       "" << std::setw(40) << now.date()
        << ""\ndate:                "" << std::setw(40) << now.time_of_day()
        << std::endl;
}
}}}
",Mark van Dijk <mark.van.dijk@…>
6662,Add osx framework support to clang,build,Boost 1.49.0,To Be Determined,Patches,Vladimir Prus,new,2012-03-08T16:23:58Z,2012-03-08T16:23:58Z,,bsantos@…
6661,Different behavior on WIN and Linux,asio,Boost 1.49.0,To Be Determined,Bugs,chris_kohlhoff,new,2012-03-08T07:58:05Z,2012-03-08T07:58:05Z,"Hi, I've found a different behavior at use of some functions with UDP protocol.

Look at this code

{{{
	io_service ios;
	
	udp::endpoint to(address::from_string(""127.0.0.1""), port);
	udp::socket sender(ios, udp::v4());
	udp::socket receiver(ios, udp::endpoint(udp::v4(), port));
	
	const char buf[] = ""Some test data..."";
	const size_t buf_len = sizeof(buf);
	
	char read_buf[buf_len];
	char half_read_buf[buf_len / 2];
	
	sender.send_to(buffer(buf, buf_len), to);
	try
	{
		udp::endpoint sender_point;
		receiver.receive_from(buffer(half_read_buf, sizeof(half_read_buf)),
								sender_point);
	}
	catch(exception& ex)
	{
		string str = ex.what();
		cerr << ""Exception: ""<< ex.what() << endl;
	}
	cout << string(half_read_buf, sizeof(half_read_buf)) << endl;
	
	sender.send_to(buffer(buf, buf_len), to);
	sender.send_to(buffer(buf, buf_len), to);
	
	cout << ""Available: "" << receiver.available() << endl;
	receiver.receive(buffer(read_buf, sizeof(read_buf)));
	
	cout << ""Available: "" << receiver.available() << endl;
	receiver.receive(buffer(read_buf, sizeof(read_buf)));
	
	cout << ""Available: "" << receiver.available() << endl;
}}}

Here we are reading half an datagramm and use socket::available() to look how much data into the socket.
Execute this code on WIN32 and you get this output

{{{
Exception: receive_from: The message was too large for the specified buffer and (for unreliable protocols only) any trailing portion of the message that did not fit into the 
buffer has been discarded.
Some test
Available: 36
Available: 18
Available: 0
}}}
Execute it on Linux and you get

{{{
Some test
Available: 18
Available: 18
Available: 0

}}}

It looks strange.[[BR]]
Look into source

{{{
boost/asio/detail/impl/socket_ops.ipp
-------------------------------------
int recvfrom(socket_type s, buf* bufs, size_t count, int flags,
    socket_addr_type* addr, std::size_t* addrlen,
    boost::system::error_code& ec)
{
...
#if defined(BOOST_WINDOWS) || defined(__CYGWIN__)
  int result = error_wrapper(::WSARecvFrom(s, bufs, recv_buf_count,
        &bytes_transferred, &recv_flags, addr, &tmp_addrlen, 0, 0), ec);
  *addrlen = (std::size_t)tmp_addrlen;
...
  if (result != 0)
    return socket_error_retval;
  ec = boost::system::error_code();
  return bytes_transferred;
#else // defined(BOOST_WINDOWS) || defined(__CYGWIN__)
  msghdr msg = msghdr();
  init_msghdr_msg_name(msg.msg_name, addr);
  msg.msg_namelen = *addrlen;
  msg.msg_iov = bufs;
  msg.msg_iovlen = count;
  int result = error_wrapper(::recvmsg(s, &msg, flags), ec);
  *addrlen = msg.msg_namelen;
  if (result >= 0)
    ec = boost::system::error_code();
  return result;
}
}}}
For WIN32 uses functions family WSARecv([http://msdn.microsoft.com/en-us/library/windows/desktop/ms741686(v=vs.85).aspx]) they return status of error. And one of which is

{{{
WSAEMSGSIZE 
The message was too large for the specified buffer and (for unreliable protocols only) any trailing portion of the message that did not fit into the buffer has been discarded.
}}}

For Linux uses functions family recv ([http://linux.die.net/man/2/recv]). They return the length of the message on successful completion or -1 and set status in errno if was error. But for them no the error if buffer length less that a received datagram.[[BR]]

But if we uses function recvfrom, it sets this error into struct msghdr in the msg_flags

{{{
MSG_TRUNC
indicates that the trailing portion of a datagram was discarded because the datagram was larger than the buffer supplied.
}}}

And also about function basic_datagram_socket::available. For WIN32 it returns length of all datagrams in the socket BUT for linux in returns length a one datagramm.",cupper.jj@…
6659,Filesystem compilation broken on Solaris 9 and 10,filesystem,Boost 1.49.0,To Be Determined,Bugs,Beman Dawes,reopened,2012-03-07T10:15:58Z,2015-04-06T12:22:25Z,"Output message:

libs/filesystem/v3/src/operations.cpp: In function âvoid boost::filesystem3::detail::permissions(const boost::filesystem3::path&, boost::filesystem3::perms, boost::system::error_code*)â:
libs/filesystem/v3/src/operations.cpp:1391:11: error: â::fchmodatâ has not been declared

This is regression, 1.48 compiles well. I reproduced on both sparc and x86 platforms.",Vasily Sukhanov <basil@…>
6644,"Windows: auto_link.hpp incorrectly errors with ""Mixing a dll boost library with a static runtime is a really bad idea...""",python USE GITHUB,Boost 1.48.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-03-01T23:42:09Z,2015-07-07T10:54:42Z,"I'm building a DLL which uses *static* runtime linking. Static runtime linking uses the /MT (and /MTd) switch. When Boost is compiled with under the DLL, the following error is reported:

C:\Users\Public\boost-trunk\boost/config/auto_link.hpp(354) : fatal error C1189: #error :  ""Mixing a dll boost library with a static runtime is a really bad idea...""

According to ""/MD, /MT, /LD (Use Run-Time Library)"", http://msdn.microsoft.com/en-US/library/2kzt1wy3(v=vs.90).aspx:

/MT - Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.

For completeness, here is the switch for dynamic runtime linking:

/MD - Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file. ... Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR90.DLL, which must be available at run time to applications linked with MSVCRT.lib...

To summarize, ""_MT"" is defined for both static and dynamic linking. ""_DLL"" is defined for just dynamic linking. And because I am building a DLL, ""_WINDLL"" is also defined.

Perhaps the following would be better logic for auto_link.hpp (my apologies for not trying to figure out all the Boost defines):

#if defined(BOOST_OS_WINDOWS) && defined(_MT) && !defined(_DLL)
# define BOOST_OS_WINDOWS_STATIC 1
#elif defined(BOOST_OS_WINDOWS) && defined(_MT) && defined(_DLL)
# define BOOST_OS_WINDOWS_DYNAMIC 1
#elif defined(BOOST_OS_WINDOWS)
# pragma warning(""Neither static nor dynamic runtime linking has been picked up"")
#endif
",noloader@…
6643,token_functions.hpp warning: unused parameters,tokenizer,Boost 1.49.0,To Be Determined,Bugs,jsiek,new,2012-03-01T23:25:25Z,2012-03-01T23:25:25Z,"
/boost/include/boost/token_functions.hpp:312:33: warning: unused parameter 'b' [-Wunused-parameter,3]
     static void assign(Iterator b, Iterator e, Token & t) { }
                                 ^
/boost/include/boost/token_functions.hpp:312:45: warning: unused parameter 'e' [-Wunused-parameter,3]
     static void assign(Iterator b, Iterator e, Token & t) { }
                                             ^
/boost/include/boost/token_functions.hpp:312:56: warning: unused parameter 't' [-Wunused-parameter,3]
     static void assign(Iterator b, Iterator e, Token & t) { }",nealgmeyer@…
6638,convert_aux fails while intializing global variable,filesystem,Boost 1.59.0,To Be Determined,Bugs,Beman Dawes,assigned,2012-02-29T22:39:27Z,2017-04-26T16:12:09Z,"''path_traits.cpp''[[BR]]

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

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

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

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

Additional info: WIN 32 and 64 bit, MSVS2010[[BR]]
{{{
#include <iostream>
#include <boost/filesystem.hpp>

using namespace boost::filesystem;

path p(L""C:\\TEMP\\"");
path q(p / L""wide"");  // Works!
path r(p / ""narrow""); // Breaks :(

int _tmain(int argc, _TCHAR* argv[])
{
    path p(L""C:\\TEMP\\"");
    path q(p / L""wide"");  // Works!
    path r(p / ""narrow""); // Works here!

    std::cout << r.string() << std::endl;
	return 0;
}
}}}
[[BR]]

P.S. If more info is required I will reply here not by email.",john doe <johndoe>
6629,NVCC chokes on boost/mpl/map,mpl,Boost 1.44.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-02-29T01:44:02Z,2012-05-28T17:28:47Z,"We're now receiving a bug report from our customers that they are hitting a problem compiling a code including boost with NVCC. 

The bug report from our customer:
-----------------------------------------
Unfortunately I’m now hitting a real problem with NVCC elsewhere in boost too. Once again, merely including the header is enough to trip up NVCC (but only on Windows): 

boost_mpl_map.cu: 
#include <boost/mpl/map.hpp> 
int main( int argc, char ** argv ) 
{ 
} 

C:\>nvcc boost_mpl_map.cu -o boost_mpl_map.exe -Iboost/include/boost-1_44 
boost_mpl_map.cu 
tmpxft_00000764_00000000-3_boost_mpl_map.cudafe1.gpu 
tmpxft_00000764_00000000-8_boost_mpl_map.cudafe2.gpu 
boost_mpl_map.cu 
tmpxft_00000764_00000000-3_boost_mpl_map.cudafe1.cpp 
tmpxft_00000764_00000000-14_boost_mpl_map.ii 
stuff/boost/include/boost-1_44\boost/mpl/aux_/order_impl.hpp(35) : error C2064: term does not evaluate to a function taking 2 arguments 
stuff/boost/include/boost-1_44\boost/mpl/aux_/order_impl.hpp(57) : see reference to class template instantiation 'boost::mpl::x_order_impl<Seq,Key>' being compiled 

As with the previous issues, compiling as a .cpp (still using NVCC) is fine. This affects both CUDA 4.0 and CUDA 4.1, and I’m using VS2010 for CL. A workaround would be greatly appreciated if you can find one as I haven’t managed to come up with one yet! 
-----------------------------------------

This issue has been investigated by our developers and finally it was root caused as a boost issue. He downloaded boost 1.44.0, and found that boost is doing something special when __CUDACC__ is defined.

boost_1_44_0$ grep -IR CUDACC *
boost/config/select_compiler_config.hpp:#elif defined __CUDACC__
boost/concept/detail/has_constraints.hpp:#if BOOST_WORKAROUND(__SUNPRO_CC, <= 0x580) || defined(__CUDACC__)
boost/type_traits.hpp:#if !defined(__BORLANDC__) && !defined(__CUDACC__)

Unfortunately, this special workaround in boost does not work properly.

If he just compile the example code supplied in the description with the Microsoft compiler, after renaming it to .cpp, with __CUDACC__ defined, the compilation fails.

U:\> type main.cpp
#include <boost/mpl/map.hpp>
int main(int argc, char *argv[]) { return 0; }

U:\> cl -D__CUDACC__ -Iboost_1_44_0 main.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

main.cpp
boost_1_44_0\boost/mpl/aux_/order_impl.hpp(50) : error C2064: term does not evaluate to a function taking 2 arguments
boost_1_44_0\boost/mpl/aux_/order_impl.hpp(57) : see reference to class
template instantiation 'boost::mpl::x_order_impl<Seq,Key>' being compiled

So, this might be a bug in boost.
If the boost implementers put this special treatment for nvcc due to a bug in nvcc, we are willing to work on the real bug, but this one is a bug in the special treatment code. 

Best regards,
Andrew Shao",gshao@…
6626,shallow_array_adaptor bug in swap function,uBLAS,Boost 1.49.0,Boost 1.50.0,Bugs,Gunter,new,2012-02-28T16:49:59Z,2012-02-28T16:49:59Z,"''boost::numeric::ublas::vector< T,shallow_array_adaptor<T> >'' fails when it is assigned with an expression. For example:

{{{
#define BOOST_UBLAS_SHALLOW_ARRAY_ADAPTOR
#include <boost/numeric/ublas/vector.hpp>

struct point {
   double x;
   double y;
   double z;
};

void test() {
   using namespace boost::numeric::ublas;

   point p = { 1, 2, 3 }
   shallow_array_adaptor<double> a(3, &p.x);            // Ok, a holds p address
   vector<double, shallow_array_adaptor<double> > v(a); // Ok, v holds p address
   
   v += v;     // Ok, now p = { 2, 4, 6 }
   v /= 2;     // Ok, now p = { 1, 2, 3 }
   v = v*2;    // <- Oh no, p = { 1, 2, 3 } !!!
}
}}}

''vector'' creates a temporary object and it calls to ''shallow_array_adaptor::swap''. This function doesn't check if it is the owner of pointers to swap. When both are data owners can do that (as unbounded_array does). But if they are not then they should swap as bounded_array does.",Guillermo Ruiz Troyano <ruiztroyano@…>
6622,boost::mpl::transform fails on boost::mpl::set in non-inserter form,mpl,Boost 1.48.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-02-26T22:44:53Z,2013-04-23T13:51:09Z,"The following code does not compile with boost-1.48.0:
{{{
typedef boost::mpl::transform<
	boost::mpl::set<double,float>,
	boost::add_pointer<boost::mpl::_1>
>::type pointer_set;
}}}
It fails on a compile-time assert deeply into boost.mpl with ""REQUESTED_PUSH_FRONT_SPECIALIZATION_FOR_SEQUENCE_DOES_NOT_EXIST"". This makes sense, as boost::mpl::set is not a front extensible sequence. One can get this to work by using a custom inserter that utilises boost::mpl::insert instead of boost::mpl::push_front, or using a different sequence class in the output.
However, I think boost::mpl::transform should either be able to detect a set properly, or the documentation should state that the non-inserter version of boost::mpl::transform requires a front extensible sequence.",hack@…
6618,boost::container::flat_map not transparently accepting move-only values,container,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,new,2012-02-25T23:28:54Z,2015-12-06T08:48:52Z,"I would have expected to be able to store move-only values in a boost::container::flat_map, and to have no code changes except in the header files, since it is supposed to be a drop-in replacement for std::map. However, I cannot create a key-value pair of a type it will accept, because of const errors. The attached program shows the problem.

Perhaps allowing a non-const std::pair reference to be passed to insert would help, or even a new make_pair helper function that returned a BOOST_RV_REF(value_type)?

The same thing happens with boost::container::map.

",Charles David Tallman <DaveTallman@…>
6617,filesystem::remove_all can't delete directory that contains directory junction,filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2012-02-25T21:08:30Z,2012-02-25T21:08:30Z,"filesystem::remove_all tries to delete junction by DeleteFile but it should be deleted by RemoveDirectory.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488%28v=vs.85%29.aspx

Diff with fix is in attach",Nikolay Shelukhin <nikola-sh@…>
6614,Start adapting Quaternions and Octonions for C++11,math,Boost 1.49.0,To Be Determined,Feature Requests,John Maddock,new,2012-02-25T01:28:16Z,2012-02-25T01:28:16Z,"When I read up on C++11 features like `constexpr` and `noexcept`, I wonder what classes in Boost can be adapted for them.  The quaternion and octonion class templates represent value-types that can easily be made `constexpr` compliant.  Further, the specializations for the built-in floating-point types can be made `noexcept` for their operations.  I have a patch that starts work on both fronts.

Since the library is implemented with macro madness, I can't change too much without making the file unrecognizable to `diff` utilities.  This means that some stuff in the specializations that could be `noexcept` can't be since they share textual implementation with the general templates' versions of the code.

Some aggresive marking of constructors as `explicit` has been toned down, still conforming to the docs.  Speaking of which, they have been changed to match the new code (plus two doc errors).

For future directions, the big hurdle is the idiom that binary-operator @@ is implemented in terms of @@=.  That's generally OK in C++03, but now it disqualifies the former from being declared `constexpr` since the latter is mutating.  Fixing this would entail flipping the relationship between the functions around.
",Daryle Walker
6611,boost::pool_allocator construct() with single argument required by GCC 4.6 stl,pool,Boost 1.51.0,To Be Determined,Bugs,Chris Newbold,new,2012-02-24T19:14:41Z,2013-11-06T15:57:50Z,"I tried to compile a MSVC code using custom std::vector/pool_allocator under win32/codeblocks (which uses GCC 4.6.0), and I get an error because on vector::resize() and underlying call _ _ uninitialized_default_a(), the stl implemented try to call _ _ alloc.construct() with a single placement address as argument. 

The thing is that boost:pool_allocator provides only one version of construct() which takes 2 arguments. 
Why isn't a ""default"" construct( const pointer& ) implemented in pool_allocator ? Or why this version of the stl implements that ? Or what am I doing wrong ?

Thanks",vivien.millet@…
6610,customizing boost::pool/boost::object_pool via template parameter for ordered/non-ordered usage,pool,Boost 1.48.0,To Be Determined,Feature Requests,John Maddock,new,2012-02-24T17:38:44Z,2012-07-16T20:01:58Z,"1.
A documentation conflict between declaration and definition of boost::pool::purge_memory(). The definition documentation is 
{{{
//! pool must be ordered
}}}
, but the declaration documentation does not provide this information.

2.
Version of non-ordered boost::pool::release_memory()

Thereby there is the question - 
are there any differences in implementation or perfomance of ordered/non-ordered versions of this function?

3.
Providing ordered/non-ordered release_memory() and purge_memory() for boost::object_pool

4.
Efficient(non-ordered) construct/destroy of single objects in boost::object_pool(i.e. when boost::object_pool will be used for allocating single objects only, not arrays of objects)

5.
Introduce some template parameter in the boost::object_pool(and in the boost::pool) in order to customize the pool for ordered/non-ordered or both usage.",rad_d@…
6593,patch: bjam SHELL builtin: fix for strip-eol and added join-lines,build,Boost 1.48.0,To Be Determined,Bugs,Vladimir Prus,new,2012-02-22T18:51:06Z,2012-02-22T18:51:06Z,"The implementation of the 'strip-eol' option (which I submitted as a patch some time ago) had a flaw (as identified by Marc Dürner on the boost-build mailing list) in which it could strip newlines in the middle of the output, as opposed to only at the end of output, as intended.

This patch fixes that issue and introduces a new option called 'join-lines' which will replace ALL newlines in the output with a space.

Note that I've introduced a pair of functions that are candidates for the string module and which perhaps should be moved there.
",codemonkey@…
6591,Download of boost source and documentation should be separate,Documentation,Boost 1.48.0,To Be Determined,Feature Requests,No-Maintainer,new,2012-02-22T16:34:19Z,2012-11-08T11:14:06Z,"The documentation bundle should be separated into a different archive for download from the actual library code.

This would make extracting just the libraries much faster for initial setup especially if someone doesn't want the documentation locally anyway.",business2008+boost.org@…
6590,BOOST_AUTO fails on C++11 lambdas,typeof,Boost 1.48.0,To Be Determined,Feature Requests,Peder Holt,new,2012-02-21T22:46:09Z,2012-02-21T22:46:09Z,"`BOOST_AUTO` fails on C++11 lambdas as follows (tested with g++ 4.6.2-14ubuntu2):
{{{
#!C++
#include <boost/typeof/typeof.hpp>
BOOST_AUTO(f, [](){});
}}}
{{{
$ g++ -c -std=c++0x test.cc
test.cc:2:1: error: lambda-expression in unevaluated context
test.cc:2:1: error: conversion from ‘<lambda()>’ to non-scalar type ‘<lambda()>’ requested
}}}

Although it’s apparently not possible to use `typeof` or `decltype` on a lambda expression, this could be fixed by defining `BOOST_AUTO` with C++11 `auto` on compilers that support it:
{{{
#!C++
#define BOOST_AUTO(Var, Expr) auto Var = Expr
BOOST_AUTO(f, [](){});
}}}
",Anders Kaseorg <andersk@…>
6589,"boost::wave samples won't build with ""Simplified Build From Source"" build",wave,Boost 1.48.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-02-21T20:23:58Z,2012-02-21T20:23:58Z,"According to a quick check on the #boost irc channel, jam _should_ be forcing the build of any boost libraries it needs.

This does not appear to be happening when I try to build the boost::wave (1.48.0) samples with VS10 on WinXP.

I get a series of linking errors, when I attempt:
C:\boost_1_48_0> bjam.exe libs\wave\samples

References to filesystem3 or even wave itself fail to link.

A solution is to force everything to build in boost with:
C:\boost_1_48_0> b2.exe --build-type=complete

At that point many of the projects will build, but still some don't in a possibly unrelated issue documented here: https://svn.boost.org/trac/boost/ticket/6588",Joe Kerian <jkerian+boost@…>
6588,boost::wave list_includes sample will not link with cpplexer,wave,Boost 1.48.0,To Be Determined,Bugs,Hartmut Kaiser,new,2012-02-21T20:23:12Z,2012-03-08T16:40:51Z,"After working around a jamfile problem where none of the wave samples will build(ticket will be posted shortly after this), list_includes (among others) still refuses to link.

This is with VS10 on WindowsXP, Boost 1.48.0 having been built succesfully with --build-type=complete, but not installed.

I apologize for the nasty formatting, but the Command Prompt just isn't very helpful.
{{{
C:\boost_1_48_0>b2.exe libs\wave\samples -q
...patience...
...patience...
...patience...
...found 2677 targets...
...updating 7 targets...
msvc.link bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-static\threading-multi\list_includes.exe
   Creating library bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-o
n\link-static\threading-multi\list_includes.lib and object bin.v2\libs\wave\samples\list_includes\bu
ild\msvc-10.0\debug\asynch-exceptions-on\link-static\threading-multi\list_includes.exp
list_includes.obj : error LNK2019: unresolved external symbol ""public: static struct boost::wave::cp
plexer::lex_input_interface<class boost::wave::cpplexer::lex_token<struct boost::wave::util::file_po
sition<class boost::wave::util::flex_string<char,struct std::char_traits<char>,class std::allocator<
char>,class boost::wave::util::CowString<class boost::wave::util::AllocatorStringStorage<char,class
std::allocator<char> >,char *> > > > > * __cdecl boost::wave::cpplexer::lexertl::new_lexer_gen<class
 std::_String_iterator<char,struct std::char_traits<char>,class std::allocator<char> >,struct boost:
:wave::util::file_position<class boost::wave::util::flex_string<char,struct std::char_traits<char>,c
lass std::allocator<char>,class boost::wave::util::CowString<class boost::wave::util::AllocatorStrin
gStorage<char,class std::allocator<char> >,char *> > > >::new_lexer(class std::_String_iterator<char
,struct std::char_traits<char>,class std::allocator<char> > const &,class std::_String_iterator<char
,struct std::char_traits<char>,class std::allocator<char> > const &,struct boost::wave::util::file_p
osition<class boost::wave::util::flex_string<char,struct std::char_traits<char>,class std::allocator
<char>,class boost::wave::util::CowString<class boost::wave::util::AllocatorStringStorage<char,class
 std::allocator<char> >,char *> > > const &,enum boost::wave::language_support)"" (?new_lexer@?$new_l
exer_gen@V?$_String_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@U?$file_position@V?$flex_
string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator@
D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boost@@@lexertl@cpplexer@
wave@boost@@SAPAU?$lex_input_interface@V?$lex_token@U?$file_position@V?$flex_string@DU?$char_traits@
D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator@D@std@@@util@wave@boost
@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boost@@@cpplexer@wave@boost@@@345@ABV?$_String_i
terator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0ABU?$file_position@V?$flex_string@DU?$char_tr
aits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringStorage@DV?$allocator@D@std@@@util@wave@
boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@45@W4language_support@45@@Z) referenced in funct
ion ""public: static struct boost::wave::cpplexer::lex_input_interface<class boost::wave::cpplexer::l
ex_token<struct boost::wave::util::file_position<class boost::wave::util::flex_string<char,struct st
d::char_traits<char>,class std::allocator<char>,class boost::wave::util::CowString<class boost::wave
::util::AllocatorStringStorage<char,class std::allocator<char> >,char *> > > > > * __cdecl boost::wa
ve::cpplexer::lexertl::lexertl_input_interface<class boost::wave::cpplexer::lex_token<struct boost::
wave::util::file_position<class boost::wave::util::flex_string<char,struct std::char_traits<char>,cl
ass std::allocator<char>,class boost::wave::util::CowString<class boost::wave::util::AllocatorString
Storage<char,class std::allocator<char> >,char *> > > > >::new_lexer<class std::_String_iterator<cha
r,struct std::char_traits<char>,class std::allocator<char> > >(class std::_String_iterator<char,stru
ct std::char_traits<char>,class std::allocator<char> > const &,class std::_String_iterator<char,stru
ct std::char_traits<char>,class std::allocator<char> > const &,struct boost::wave::util::file_positi
on<class boost::wave::util::flex_string<char,struct std::char_traits<char>,class std::allocator<char
>,class boost::wave::util::CowString<class boost::wave::util::AllocatorStringStorage<char,class std:
:allocator<char> >,char *> > > const &,enum boost::wave::language_support)"" (??$new_lexer@V?$_String
_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@?$lexertl_input_interface@V?$lex_token@U?$f
ile_position@V?$flex_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringS
torage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boos
t@@@cpplexer@wave@boost@@@lexertl@cpplexer@wave@boost@@SAPAU?$lex_input_interface@V?$lex_token@U?$fi
le_position@V?$flex_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStringSt
orage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@wave@boost
@@@cpplexer@wave@boost@@@234@ABV?$_String_iterator@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@0AB
U?$file_position@V?$flex_string@DU?$char_traits@D@std@@V?$allocator@D@2@V?$CowString@V?$AllocatorStr
ingStorage@DV?$allocator@D@std@@@util@wave@boost@@PAD@util@wave@boost@@@util@wave@boost@@@util@34@W4
language_support@34@@Z)
bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-static\thread
ing-multi\list_includes.exe : fatal error LNK1120: 1 unresolved externals

        call ""c:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86 >nul
link /NOLOGO /INCREMENTAL:NO /DEBUG /MACHINE:X86 /subsystem:console /out:""bin.v2\libs\wave\samples\l
ist_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-static\threading-multi\list_includes.ex
e""   @""bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-static
\threading-multi\list_includes.exe.rsp""
        if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL%

...failed msvc.link bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-o
n\link-static\threading-multi\list_includes.exe bin.v2\libs\wave\samples\list_includes\build\msvc-10
.0\debug\asynch-exceptions-on\link-static\threading-multi\list_includes.pdb...
...removing bin.v2\libs\wave\samples\list_includes\build\msvc-10.0\debug\asynch-exceptions-on\link-s
tatic\threading-multi\list_includes.pdb
...failed updating 1 target...

C:\boost_1_48_0>
}}}",Joe Kerian <jkerian+boost@…>
6587,pb : tuple_basic.hpp 396 eror c2678,tuple,Boost 1.47.0,To Be Determined,Bugs,Joel de Guzman,new,2012-02-21T13:34:57Z,2012-04-26T06:37:02Z,"C:/Program Files (x86)/boost/boost_1_47\boost/tuple/detail/tuple_basic.hpp(396): error C2678: binary '=' : no operator found which takes a left-hand operand of type 'const std::_Smanip<_Arg>' (or there is no acceptable conversion)


",hoel.langouet@…
6580,problem with OpenMP > 1.3I and boost-mpi-python,mpi,Boost 1.48.0,To Be Determined,Bugs,Douglas Gregor,new,2012-02-19T17:12:56Z,2012-05-28T17:32:25Z,"when installing with bjam and using openmpi for MPI, the bjam generated mpi.so can not be loaded from within python.

the packagers for ubuntu solve this problem by putting 

mpi.so 
within a subdirectory 
boost

so something like
my_boost/lib/boost/mpi.so

together with a __init__.py file that contains:

import sys
if sys.platform == 'linux2':
    import DLFCN as dl
    flags = sys.getdlopenflags()
    sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)
    import mpi
    sys.setdlopenflags(flags)
else:
    import mpi

this way the mpi library can be imported as

import boost.mpi

this will open the __init__.py and ensure that the lib can be correctly loaded

without this the lib should be imported as
import mpi

which fails with openmpi

",anonymous
6579,"""linked list"" bug Boost.Concept_check documentation",concept_check,Boost 1.48.0,To Be Determined,Bugs,jsiek,new,2012-02-19T02:03:05Z,2012-02-19T02:03:05Z,"Right under the [http://www.boost.org/doc/libs/1_48_0/libs/concept_check/concept_check.htm#motivating-example ""Motivating Example"" section], first sentence it says ""...  is applied to a linked list."" whereas the example does not have (or need) one. ",anonymous
6568,Warnings with -Wundef,parameter,Boost 1.49.0,To Be Determined,Bugs,Daniel Wallin,new,2012-02-16T21:27:49Z,2012-03-27T07:17:56Z,"Compiling with GCC 4.3.2 on Linux with -Wundef -Werror:

{{{
In file included from boost_1_49_0_beta1/boost/parameter/parameters.hpp:44,
                 from boost_1_49_0_beta1/boost/parameter.hpp:11,
                 from boost_1_49_0_beta1/boost/heap/policies.hpp:12,
                 from boost_1_49_0_beta1/boost/heap/detail/stable_heap.hpp:20,
                 from boost_1_49_0_beta1/boost/heap/binomial_heap.hpp:19,
                 ...
boost_1_49_0_beta1/boost/parameter/aux_/unwrap_cv_reference.hpp:47:1: error: ""MSVC_WORKAROUND_GUARD"" is not defined
boost_1_49_0_beta1/boost/parameter/aux_/unwrap_cv_reference.hpp:47:1: error: ""MSVC"" is not defined
}}}",driscoll@…
6565,Warnings with -Wundef,preprocessor,Boost 1.49.0,To Be Determined,Bugs,pmenso57,new,2012-02-16T21:21:59Z,2012-02-17T09:29:10Z,"The following occurs when compiling with GCC 4.3.2 on Linux with -Wundef -Werror:

{{{
In file included from boost_1_49_0_beta1/boost/preprocessor/cat.hpp:17,
                 from boost_1_49_0_beta1/boost/concept/detail/general.hpp:7,
                 from boost_1_49_0_beta1/boost/concept/assert.hpp:36,
                 from boost_1_49_0_beta1/boost/heap/detail/heap_comparison.hpp:14,
                 from boost_1_49_0_beta1/boost/heap/binomial_heap.hpp:17,
                 ...
boost_1_49_0_beta1/boost/preprocessor/config/config.hpp:86:77: error: ""__GXX_EXPERIMENTAL_CXX0X__"" is not defined
}}}

I'm not sure what version introduced this.

(I'm going to be filing a couple of these bugs because they appear in different components... sorry if that's the wrong thing to do.)",driscoll@…
6563,system_complete documention note broken link/missing info,filesystem,Boost 1.49.0,Boost 1.49.0,Bugs,Beman Dawes,new,2012-02-16T14:25:51Z,2012-02-16T14:25:51Z,"http://www.boost.org/doc/libs/1_49_0_beta1/libs/filesystem/v3/doc/reference.html#system_complete

Has the following broken link, evidently to a removed operational function = complete().

""See complete() note for usage suggestions. -- end note]""

It would be nice if the ref'd usage suggestions could be resurrected here if they are applicable to system_complete.",Jeff Flinn <Jeffrey.Flinn@…>
6561,pool.free() crashes if given a null pointer,pool,Boost 1.47.0,To Be Determined,Bugs,John Maddock,new,2012-02-15T15:02:27Z,2018-05-12T21:30:27Z,"The documentation states that the pointer given to pool.free() should be a pointer returned by pool.malloc().

However, if pool.malloc() fails and return a null value, calling pool.free() with the returned value does crash...

It would be nice if pool.free() did not crash given a null pointer.

Example crash :
{{{
pool.free(pool.malloc());
}}}

Regards",Étienne Dupuis <e.dupuis@…>
6554,Compiler error dereferencing multi_array value via an iterator,multi_array,Boost 1.49.0,To Be Determined,Bugs,Ronald Garcia,new,2012-02-13T17:46:47Z,2012-04-11T20:55:25Z,"It is currently impossible to dereference/access the values contained in a multi_array via the -> operator from an iterator to the multi_array element. However, use the * operator works.

Example:

{{{
struct data
{
	int	value;
};
typedef boost::multi_array<data, 2> array_type;

array_type	a(boost::extents[4][5]);

// ERROR: Cannot compile this line
a.begin()->begin()->value = 7;

// Compiles successfully
(*a.begin()->begin()).value = 5;

}}}

I'm using Visual Studio 2010. This is an error in both debug and release modes. This is the error:

boost/multi_array/iterator.hpp(40): error C2528: '->' : pointer to reference is illegal
",Bill Buklis
6551,BOOST_CLASS_VERSION emits use of old-style cast when compiling with -Wold-style-cast,mpl,Boost Development Trunk,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-02-13T09:30:24Z,2012-02-14T08:17:52Z,"In our project we want to compile all code with -Wold-style-cast and treat warnings as errors. We pass the boost/include directory with -isystem to gcc. This keeps warnings from boost from obfuscating our build output. However if a macro from constains warnings we still get them.

BOOST_CLASS_VERSION uses BOOST_MPL_ASSERT which causes the warning. I changed the old style casts to c++ casts in the macro's from boost/mpl/assert.hpp.
",andre.kwakernaak@…
6547,Missing tribool in interval compare,interval,Boost 1.48.0,To Be Determined,Bugs,Boris Gubenko,new,2012-02-11T20:37:29Z,2012-02-11T20:37:29Z,boost/numeric/interval/compare.hpp fails to include boost/numeric/interval/compare/tribool.hpp (needed for tribool comparison mode),matt.keeter@…
6546,mpl::constant_c does not support min and max values for signed types,mpl,Boost Development Trunk,To Be Determined,Bugs,Aleksey Gurtovoy,new,2012-02-11T18:21:04Z,2018-04-25T09:20:32Z,"Boost.Ratio test fails on debian linux with gcc 4.6.

{{{
gcc.compile.c++ ../../../bin.v2/libs/ratio/test/ratio_add_pass.test/gcc-4.6/debug/ratio_add_pass.o
In file included from ../../../boost/mpl/integral_c.hpp:32:0,
                 from ../../../boost/ratio/detail/mpl/abs.hpp:15,
                 from ../../../boost/ratio/ratio.hpp:36,
                 from ratio_arithmetic/ratio_add_pass.cpp:16:
../../../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of ‘mpl_::integral_c<long int, 9223372036854775807l>’:
../../../boost/ratio/detail/mpl/abs.hpp:38:29:   instantiated from ‘boost::mpl::abs_tag<mpl_::integral_c<long int, 9223372036854775807l> >’
../../../boost/ratio/detail/mpl/abs.hpp:44:8:   instantiated from ‘boost::mpl::abs<mpl_::integral_c<long int, 9223372036854775807l> >’
../../../boost/ratio/detail/mpl/abs.hpp:58:8:   instantiated from ‘boost::mpl::abs_c<long int, 9223372036854775807l>’
../../../boost/ratio/ratio.hpp:79:74:   instantiated from ‘const intmax_t boost::ratio<9223372036854775807l, 1l>::ABS_N’
../../../boost/ratio/ratio.hpp:81:5:   instantiated from ‘boost::ratio<9223372036854775807l, 1l>’
../../../boost/ratio/detail/overflow_helpers.hpp:227:95:   instantiated from ‘const intmax_t boost::ratio_detail::ratio_add<boost::ratio<9223372036854775807l, 1l>, boost::ratio<-0x00000000000000001l, 1l> >::gcd_n1_n2’
../../../boost/ratio/detail/overflow_helpers.hpp:243:18:   instantiated from ‘boost::ratio_detail::ratio_add<boost::ratio<9223372036854775807l, 1l>, boost::ratio<-0x00000000000000001l, 1l> >’
../../../boost/ratio/ratio.hpp:136:8:   instantiated from ‘boost::ratio_add<boost::ratio<9223372036854775807l, 1l>, boost::ratio<-0x00000000000000001l, 1l> >’
ratio_arithmetic/ratio_add_pass.cpp:70:37:   instantiated from here
../../../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow]
../../../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: overflow in constant expression [-fpermissive]
../../../boost/mpl/aux_/integral_wrapper.hpp:72:96: note: in template argument for type ‘long int’ 

}}}
",smr@…
6545,boost:::python doesn't recognize std::shared_ptr,python USE GITHUB,Boost 1.48.0,To Be Determined,Bugs,Jim Bosch,assigned,2012-02-11T14:03:12Z,2015-09-18T07:17:12Z,"boost::python specially handles boost::shared_ptr, but special handling is also needed for std::shared_ptr",Neal Becker <ndbecker2@…>
6544,The documentation of iterator_property_map is overly complicated and incorrect,property_map,Boost 1.48.0,To Be Determined,Bugs,Douglas Gregor,new,2012-02-10T15:40:40Z,2012-04-16T17:49:27Z,"The example that is used, is very complicated especially because it refers to the Graph library. 

The operator[] does not take a pointer_diff as parameter but an IndexMap::key_type",anonymous
6542,cannot assign empty matrix to matrix,uBLAS,Boost 1.48.0,To Be Determined,Bugs,Gunter,new,2012-02-10T11:05:21Z,2012-02-10T11:05:21Z,"The following gives a runtime error, because matrix b is empty

boost::numeric::ublas::matrix<int>  a, b;
a = b;

I am submitting a patch to storage.hpp, but don't know if the problem appears elsewhere too.",Alex Hagen-Zanker <ahh34@…>
6538,property map documentation is overlay complicated,property_map,Boost 1.48.0,To Be Determined,Tasks,Douglas Gregor,new,2012-02-09T16:30:35Z,2012-02-10T12:59:31Z,"The documentation of property map is overly complicated, for a few reasons:

1. References to the Graph library. Considering that many readers of the documentation will be referred from the Graph library, they are being send in circles. Those not referred from the Graph library  won't be helped either.

2. Too many indications of what property_map is similar to. These are generally not helpful: better to say what it is, than what it looks like.

3. Complicated examples.

I am attaching a rewrite of property_map.html",anonymous
6532,KeyError: 'attachment',python USE GITHUB,Boost 1.48.0,To Be Determined,Bugs,Ralf W. Grosse-Kunstleve,new,2012-02-07T13:24:36Z,2012-02-07T13:25:48Z,"==== How to Reproduce ====

While doing a POST operation on `/attachment/ticket/5372/`, Trac issued an internal error.

''(please provide additional details here)''
}
void doSomething(boost::weak_ptr<int> weakp, int* number) {

int i = 0; while(++i<10000) {


User agent: `Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3`

==== System Information ====
''System information not available''

==== Enabled Plugins ====
''Plugin information not available''

==== Python Traceback ====
{{{
Traceback (most recent call last):
  File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 513, in _dispatch_request
    dispatcher.dispatch(req)
  File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 235, in dispatch
    resp = chosen_handler.process_request(req)
  File ""build/bdist.linux-i686/egg/trac/attachment.py"", line 448, in process_request
    self._do_save(req, attachment)
  File ""build/bdist.linux-i686/egg/trac/attachment.py"", line 620, in _do_save
    upload = req.args['attachment']
KeyError: 'attachment'
}}}",Trvus549@…
6529,Build process ignores --with-icu path on some icu tests?,locale,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-02-06T21:19:57Z,2013-07-07T16:37:10Z,"When bootstrap.sh --with-icu=/usr/local/Cellar/icu4c/1.8.1.1, I get in the logs:


1) when testing 'has_icu'

darwin.compile.c++ bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o

    ""g++""  -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC  -DBOOST_ALL_NO_LIB=1 -DBOOST_HAS_ICU=1  -I""."" -I""/usr/local/Cellar/icu4c/1.8.1.1/include"" -c -o ""bin.v2/libs/regex/build/darwin-4.2.1/debug/has_icu_test.o"" ""libs/regex/build/has_icu_test.cpp""

Note the -I flag with my icu path.

2) Later, in the same config.log, I see:

darwin.compile.c++ bin.v2/libs/locale/build/darwin-4.2.1/debug/has_icu_obj.o

    ""g++""  -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC  -DBOOST_ALL_NO_LIB=1  -I""."" -c -o ""bin.v2/libs/locale/build/darwin-4.2.1/debug/has_icu_obj.o"" ""libs/locale/src/../build/has_icu_test.cpp""

libs/locale/src/../build/has_icu_test.cpp:12:30: error: unicode/uversion.h: No such file or directory

Note that in this g++ line there is no -I flag with my icu path.",hashashin@…
6527,Segmentation fault from program_options with intel compiler and openmp,program_options,Boost 1.49.0,To Be Determined,Bugs,Vladimir Prus,new,2012-02-06T05:15:58Z,2012-05-28T05:44:16Z,"When using program_options to parse the command line, a segmentation fault results from the store() function after a call to parse_command_line(). This seems to only happens when using the -openmp flag with the intel c++ (icpc) compiler (version 11) and -openmp compiler directive. ",Ryan Scott Davis <rsdavis@…>
6525,format atldbgmem.h m_storage VS2010,optional,Boost 1.48.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-02-05T15:36:02Z,2017-10-12T14:47:08Z,"Hi,

Format component of Boost 1.48 doesn't compile with memory debugging enabled in VS2010.

With <atldbgmem.h> included in stdafx.h (precompiled header), compiler says error:


{{{
1>d:\boost\boost_1_48_0\boost\optional\optional.hpp(346): error C2061: syntax error : identifier 'm_storage'
1>          d:\boost\boost_1_48_0\boost\optional\optional.hpp(345) : while compiling class template member function 'void boost::optional_detail::optional_base<T>::construct(const std::locale &)'
1>          with
1>          [
1>              T=boost::io::detail::locale_t
1>          ]
1>          d:\boost\boost_1_48_0\boost\optional\optional.hpp(500) : see reference to class template instantiation 'boost::optional_detail::optional_base<T>' being compiled
1>          with
1>          [
1>              T=boost::io::detail::locale_t
1>          ]
1>          d:\boost\boost_1_48_0\boost\format\internals.hpp(56) : see reference to class template instantiation 'boost::optional<T>' being compiled
1>          with
1>          [
1>              T=boost::io::detail::locale_t
1>          ]
1>          d:\boost\boost_1_48_0\boost\format\internals.hpp(57) : see reference to class template instantiation 'boost::io::detail::stream_format_state<Ch,Tr>' being compiled
1>
1>Build FAILED.

}}}
The code itself:



{{{
#include <boost/format.hpp>

int _tmain(int argc, _TCHAR* argv[])
{
	boost::format fmt(""Value: %d\nString: %s\n"");
	fmt % 10 % _T(""My string"");
	printf(fmt.str().c_str());

	return 0;
}
}}}

Without atldbgmem.h included the code compiles with no error messages

Regards,
Evgeniy
",epodkopaev@…
6521,Directory listing using C++11 range-based for loops,filesystem,Boost 1.48.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2012-02-04T18:15:21Z,2017-06-13T14:11:26Z,"I have written a simple 'container' class for a directory, 'containing' all of its subdirectories:

{{{
namespace boost{
    namespace filesystem{
        class directory{
            path p_;
            public:
                inline directory(path p):p_(p){
                    return;
                }
                directory_iterator begin(){
                    return directory_iterator(p_);
                }
                directory_iterator end(){
                    return directory_iterator();
                }
        };
    }
}
}}}
so that that range-based for loop can be used:
{{{
for(auto i:directory(""/home"")){
    ...
}
}}}",mustrumr97@…
6515,Serilaization of std::vector<bool> is broken for optimizing archives,serialization,Boost 1.48.0,To Be Determined,Bugs,Robert Ramey,assigned,2012-02-02T18:40:38Z,2012-07-15T20:35:16Z,"Serializing a vector<bool> causes corruptions in the created archive. The reason is this function (in boost/serialization/vector.hpp):

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

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

I'm encountering this problem with MSVC10, 64bit, Windows7.",Hartmut Kaiser
6512,Find a framework directory on darwin not work,python USE GITHUB,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2012-02-02T10:33:58Z,2012-02-02T18:04:19Z,"patch for '''python.jam'''
{{{
866c866
<         local framework-directory = $(libraries[-1]) ;
---
>         framework-directory = $(libraries[-1]) ;
}}}

Sorry, my English is very bad to explain more, patch should fix it.",iinik@…
6506,date_time\test\posix_time\testperiod.cpp is obsolete and should be removed,date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2012-02-01T13:10:50Z,2012-02-02T15:47:42Z,"Quote from the file itself, which is otherwise empty:
{{{
//FILE OBSOLETE: replace by testtime_period.cpp
}}}
",Ulrich Eckhardt <ulrich.eckhardt@…>
6500,testfrom_facet.cpp is unused and broken,date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2012-01-31T09:05:31Z,2012-01-31T09:05:31Z,"The above file is part of the test directory of the DateTime library, but it isn't compiled as part thereof. It also doesn't compile, because it depends on algorithm_ext/container_print.hpp.

I'd either revive it or drop it.
",Ulrich Eckhardt <ulrich.eckhardt@…>
6497,bjam build failing when including QtUiTools,build,Boost 1.48.0,To Be Determined,Bugs,Vladimir Prus,new,2012-01-30T20:25:54Z,2014-12-15T17:15:49Z,"qt//QtUiTools causes bjam to fail prior to starting compilation with an error...[[BR]]
xx/tools\builtin.jam:869: in linking-generator.generated-targets[[BR]]
'* argument error[[BR]]
'* rule generator.generated-targets ( sources + : property-set : project name ? )[[BR]]
'* called with: (  : object(property-set)@1776 : object(project-target)@46 QtUiTools )[[BR]]
'* missing argument sources[[BR]]
xx/build/v2/build\generators.jam:543:see definition of rule 'generator.generated-targets' being called[[BR]]

Commenting out qt//QtUiTools from my Jamfile allows the build to work up to the point that I need QUILoader.h, which is part of of qt//QtUiTools

I'm Using bjam from boost 1.48 with QT 4.8.0, both compiled sucessfully on Windows 7 with 32-bit MSVC 2010.

If you have any suggestions for a work-arround, please let me know",Brad Jascob <bradley.jascob@…>
6496,interval equality operator throws,interval,Boost 1.47.0,To Be Determined,Bugs,Boris Gubenko,new,2012-01-30T20:02:50Z,2012-01-30T20:05:38Z,"the following code throws:

boost::numeric::interval<double> intv(1.0, 2.0);
boost::numeric::interval<double> intv2 = intv;

bool b = (intv == intv2);

bug or my fault?",gast128 <gast128@…>
6494,Using BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG flag ruins date_time library under MinGW,date_time,Boost 1.49.0,To Be Determined,Bugs,az_sw_dude,new,2012-01-30T05:31:28Z,2012-01-30T05:31:28Z,"I've built static boost libraries under windows (Win7 64) with MinGW 3.20 (32 bit, GCC 4.6.1) with '''BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG''' option and threading=multi link=static runtime-link=static address-model=32

Simple test like
 

{{{
#include <iostream>
#include <boost/thread/thread.hpp>
#include <boost/date_time/posix_time/posix_time.hpp>

using namespace std;
using namespace boost;

void func()
{
    this_thread::sleep(boost::posix_time::milliseconds(5000));
}

int main()
{
     thread trd(func);
    trd.join();
    cout << ""wait ok"" << endl;
    return 0;
}
}}}

When built statically with '''date_time''' and '''thread''' libraries.

It fails with segfault in date_time library. That happens in ctor of structure simple_time_rep, but I didn't dig too much. I guess the problem is in date_time library.

Without flag '''BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG''' it's going all right with timings and threads. 

I also tried flags BOOST_HAS_WINTHREADS and _REENTRANT(for MinGW) - that does not affect the case. BOOST_THREAD_USE_LIB was defined (to let it work with static libs).

I've tested this for boost '''1.48.0''' and '''1.49.0-beta1'''. Neither did work. 
I asked about this problem in boost mailing lists but got no answer, so I post it as a possible bug.

Sincerely, Yana A. Kireyonok",death.iron.bug@…
6461,12-hour clock support for time_input_facet,date_time,Boost 1.48.0,To Be Determined,Feature Requests,az_sw_dude,new,2012-01-29T09:03:29Z,2012-01-29T09:03:29Z,"Please implement 12-hour clock format options for time_input_facet (%I, %l, %p, %P).
Thanks!",dev@…
6460,add xpressive grammar example to docs,xpressive,Boost 1.48.0,To Be Determined,Tasks,Eric Niebler,new,2012-01-27T17:56:14Z,2012-01-27T17:56:14Z,see attached file,Eric Niebler
6458,Bug in a multi_array print_array example,multi_array,Boost 1.48.0,To Be Determined,Bugs,Ronald Garcia,new,2012-01-27T14:52:09Z,2012-08-18T15:13:20Z,"http://www.boost.org/doc/libs/1_48_0/libs/multi_array/example/print_array.cpp

change

'''void print(std::ostream& os, const double& x)'''

to

'''template<> void print<double>(std::ostream& os, const double& x)'''

reference:
http://stackoverflow.com/questions/9034554/pretty-print-of-boostmulty-array-example-fails/",nootropic.kint@…
6454,Problem when using phoenix::_if with boost::optional in Spirit,phoenix,Boost Development Trunk,To Be Determined,Bugs,Thomas Heller,new,2012-01-26T18:05:09Z,2012-01-26T18:05:09Z,"A rule that yields a boost::optional as attribute won't compile when using qi::_1 as condition for phoenix::_if.
However, if you add a phoenix statement after the if_ statement the rule compiles.

  //Doesn't compile
  qi::rule<Iter, boost::optional<int>()> rule_a = 
    (-qi::int_)[
      phx::if_(qi::_1)[
        phx::nothing
      ]
      //Uncomment next line and it compiles
      // , phx::nothing
    ]
 ;

It doesn't help if you use another operator than -

  //Doesn't compile
  qi::rule<Iter, boost::optional< boost::variant<int, double> >() > rule_b =
    (qi::int_ | qi::double_ | qi::eps)[
      phx::if_(qi::_1)[
        phx::nothing
      ]
      //Uncomment next line and it compiles
      // , phx::nothing
    ]
  ;

The error doesn't manifest if you don't refer to qi::_1

  //Compiles
  qi::rule<Iter, boost::optional< boost::variant<int, double> >() > rule_c =
    (qi::int_ | qi::double_ | qi::eps)[
      phx::if_(phx::val(true))[
        phx::nothing
      ]
    ]
  ;

It also works if you refer to qi::_1 but don't use phoenix::if_

  //Compiles
  qi::rule<Iter, boost::optional<int>()> rule_d = 
    (-qi::int_)[
      std::cout << qi::_1
    ]
  ;

Doing the same thing as in rule_a and rule_b outside of Spirit semantic actions also works

  //Compiles
  phx::if_(arg1)[
    phx::nothing
  ]
  (boost::optional<int>(5));

The problem doesn't seem to occur when using Phoenix v2 only v3",Öyvind Strand <oyvind.strand@…>
6451,Patch to allow user to specify other current filename macro on ASSERT,utility,Boost 1.48.0,To Be Determined,Patches,Beman Dawes,new,2012-01-26T17:12:11Z,2013-02-08T14:48:09Z,"When BOOST_ENABLE_ASSERT_HANDLER is defined, compiler generates a string with function name.
If a function is templated, compiler will generate a string for each function template. That leads to a huge binary files.

Attached patch, that allows to disable construction of such strings or to use different macro for current function name (for example macro that prints ONLY function name).

[http://lists.boost.org/Archives/boost/2012/01/189853.php More info]",Antony Polukhin
6449,numeric_cast is broken when using VC and /RTCc option,numeric,Boost 1.48.0,To Be Determined,Bugs,Douglas Gregor,new,2012-01-26T13:29:17Z,2012-01-26T13:29:17Z,"run-time checker detects the illegal assignment in GT_HiT::apply() in numeric\conversion\detail\converter.hpp called by 'numeric_cast<int, unsigned short>'.

please compile the attached file with below command.
> cl.exe numeric.cpp /EHsc /RTCc /Zi

I confirmed same problem using VC2005 + boost 1.47.0 and VC2010 + boost 1.48.0.
",y.hoshizuki
6448,basic_filesystem_error still referenced in docs,filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2012-01-26T12:05:48Z,2012-05-28T17:35:25Z,"In /trunk/libs/filesystem/v3/index.html:

""...Boost.Filesystem functions throw basic_filesystem_error exceptions if...""

In /trunk/libs/filesystem/v3/doc/reference.html:

""class basic_filesystem_error : public system_error""

""The class template basic_filesystem_error ...""

basic_filesystem_error doesn't exist in v3 AFAICT and filesystem_error isn't a class template as basic_filesystem_error was.",bibil.thaysose@…
6446,Mulicast receiver does not work,asio,Boost 1.47.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2012-01-26T10:05:16Z,2015-10-31T00:19:44Z,"Quickfast 1.4 uses Boost 1.47.0 to receive FAST Marketdata via Multicast. We are developing an EBS (Eurex) Market Data Feed on Red Hat Linux 5.7 64 Bit. 
Starting the InterpretApplication from quickfast no data are received. Starting in parallel a Java based multicast reader, then the data are then received in the InterpretApplication. I have also tried it with the boost test program:
http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/example/multicast/receiver.cpp
with the same behaviour

best regards

Dieter",dieter.mayer@…
6444,qi::lit(<char>) parses into a '\0' in 1.47 and 1.48,spirit,Boost 1.48.0,To Be Determined,Bugs,Joel de Guzman,reopened,2012-01-24T20:15:20Z,2012-01-25T08:50:08Z,"In 1.46.0, qi::lit(<char>) would end up in the result. This changed in 1.47.0 such that they were not parsed into the result (qi::char_ is to be used instead). However, NUL characters now show up in the resulting token. Example code and output attached.

Synopsis:

Parser:
+(qi::alnum | qi::lit('-'))

Input:
""a-b-c""

1.46.0:
""a-b-c""

1.47.0:
""a\000b\000c""

1.48.0:
""a\000b\000c""

The '\000' characters can be seen in gdb; std::ostream just shows ""abc"" instead.",mathstuf@…
6442,Let the user work with a header-only library,system,Boost 1.48.0,To Be Determined,Feature Requests,Beman Dawes,new,2012-01-23T22:14:22Z,2012-01-24T15:35:50Z,Many libraries using Boost.System directly or indirectly could find more user if Boost.System were a header-only library.,viboes
6439,convert.cpp does not compile when defining BOOST_NO_STD_LOCALE,program_options,Boost 1.48.0,To Be Determined,Bugs,Vladimir Prus,new,2012-01-23T20:57:38Z,2012-04-03T12:55:16Z,"
The reason for this build failure is that BOOST_USE_FACET is not defined when compiling with  BOOST_NO_STD_LOCALE. The two methods can easily be excluded for NO_STD_LOCALE. See attached patch. The patch is against trunk as of today.

gcc.compile.c++ bin.v2/libs/program_options/build/gcc-4.6.1/release/threading-multi/convert.o
libs/program_options/src/convert.cpp: In Funktion »std::wstring boost::from_local_8_bit(const string&)«:
libs/program_options/src/convert.cpp:134:53: Fehler: expected primary-expression before »,« token
libs/program_options/src/convert.cpp:134:63: Fehler: »BOOST_USE_FACET« wurde in diesem Gültigkeitsbereich nicht definiert
libs/program_options/src/convert.cpp: In Funktion »std::string boost::to_local_8_bit(const wstring&)«:
libs/program_options/src/convert.cpp:142:51: Fehler: expected primary-expression before »,« token
libs/program_options/src/convert.cpp:142:61: Fehler: »BOOST_USE_FACET« wurde in diesem Gültigkeitsbereich nicht definiert
libs/program_options/src/convert.cpp:143:5: Warnung: Kontrollfluss erreicht Ende von Nicht-void-Funktion [-Wreturn-type]
libs/program_options/src/convert.cpp: In Funktion »std::wstring boost::from_local_8_bit(const string&)«:
libs/program_options/src/convert.cpp:135:5: Warnung: Kontrollfluss erreicht Ende von Nicht-void-Funktion [-Wreturn-type]

    ""g++""  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_NO_STD_LOCALE -DBOOST_ALL_NO_LIB=1 -DBOOST_PROGRAM_OPTIONS_DYN_LINK=1 -DNDEBUG  -I""."" -c -o ""bin.v2/libs/program_options/build/gcc-4.6.1/release/threading-multi/convert.o"" ""libs/program_options/src/convert.cpp""

(The reason for BOOST_NO_STD_LOCALE is the libstdc++ in my target system that throws an exceptions for std::locale(""""); 8-((( )",leutloff@…
6437,"Documentation bug: ptr_map inherits from ptr_map_adapter, not ptr_multi_map_adapter",ptr_container,Boost 1.48.0,To Be Determined,Bugs,Thorsten Ottosen,new,2012-01-23T12:08:39Z,2012-01-23T13:03:57Z,"It seems that the documentation for ptr_multi_map_adatpter is wrong as there is a discrepancy with the code. I am a beginner, so if I am wrong, please gently explain why.

http://www.boost.org/doc/libs/1_48_0/libs/ptr_container/doc/ptr_multimap_adapter.html 
shows:
{{{

    class ptr_multimap_adapter 
    {
        // ...
        iterator  insert( key_type& k, T* x ); 
        template< class U >
        iterator  insert( const key_type&, std::auto_ptr<U> x );  
        // ...
     }
}}}

However, the source code shows:

{{{

        std::pair<iterator,bool> insert( key_type& key, mapped_type x )
        {
            return insert_impl( key, x );
        }

        template< class U >
        std::pair<iterator,bool> insert( const key_type& key, std::auto_ptr<U> x )
        {
            return insert_impl( key, x.release() );
        }
}}}

It seems there is a mismatch between the documentation and the code as to the type of the return value (iterator vs. pair).

The following test code provides an example of what I was trying to do after reading the documentation, but obviously that didn't compile:

{{{
#include <boost/ptr_container/ptr_map.hpp>
#include <string>
#include <utility>

int main() {
        boost::ptr_map<int, std::string> map;
        boost::ptr_map<int, std::string>::iterator map_it;
        std::string* s = new std::string(""one"");
        int i = 1;
        //map_it = map.insert(i, s); // Does not compile.
        std::pair< boost::ptr_map<int, std::string>::iterator, bool> ret = map.insert(i, s); // This compiles.
}
}}}

How is the code documentation generated? By hand?

While learning how to use ptr_container, I have often wished there were more extensive documentation and examples on how to use ptr_map. If the above is indeed a documentation bug, can you use this opportunity to add a sample code section on how to create, insert and retrieve elements with a ptr_map?

Thanks.



",augustin <augustin_boost@…>
6427,OperationalError: database is locked,trac / subversion,Boost 1.48.0,To Be Determined,Bugs,Douglas Gregor,new,2012-01-20T07:38:05Z,2012-01-20T07:38:05Z,"==== How to Reproduce ====

While doing a GET operation on `/query`, Trac issued an internal error.

''(please provide additional details here)''

Request parameters:
{{{
{'col': [u'id', u'summary', u'status', u'type', u'milestone', u'component'],
 'component': u'exception',
 'order': u'priority',
 'status': [u'assigned', u'new', u'reopened']}
}}}

User agent: `#USER_AGENT#`

==== System Information ====
''System information not available''

==== Enabled Plugins ====
''Plugin information not available''

==== Python Traceback ====
{{{
Traceback (most recent call last):
  File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 513, in _dispatch_request
    dispatcher.dispatch(req)
  File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 258, in dispatch
    req.session.save()
  File ""build/bdist.linux-i686/egg/trac/web/session.py"", line 88, in save
    @self.env.with_transaction()
  File ""build/bdist.linux-i686/egg/trac/db/api.py"", line 77, in transaction_wrapper
    fn(ldb)
  File ""build/bdist.linux-i686/egg/trac/web/session.py"", line 110, in delete_session_cookie
    """""", (self.sid,))
  File ""build/bdist.linux-i686/egg/trac/db/util.py"", line 65, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 78, in execute
    result = PyFormatCursor.execute(self, *args)
  File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 56, in execute
    args or [])
  File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 48, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: database is locked
}}}",Andrey Semashev
6404,Documentation bug for iterator_facade,iterator,Boost 1.48.0,To Be Determined,Bugs,jeffrey.hellrung,new,2012-01-16T15:50:34Z,2014-06-04T10:11:58Z,"In the documentation for iterator_facade, there's a bit of a booboo where the function is first written:
{{{
iterator-category(CategoryOrTraversal, value_type, reference)
}}}

Then defined as:
{{{
iterator-category(C,R,V)
}}}
So I think the argument order is flipped.
",Ronald Garcia
6403,Erroneous comment,iterator,Boost 1.48.0,To Be Determined,Bugs,jeffrey.hellrung,new,2012-01-16T15:49:48Z,2014-06-04T10:09:40Z,"In boost/iterator/detail/facade_iterator_category.hpp, line 76, there's a comment:
{{{
// If writability has been disabled per the above metafunction, the
// result will not be convertible to output_iterator_tag.
}}}
This comment corresponds to behavior that was removed in changeset:
https://svn.boost.org/trac/boost/changeset/21683

Now the result will never be convertible to output_iterator_tag.
",Ronald Garcia
6402,boost::spirit::lazy( *X ) does not have same semantics as *X,spirit,Boost 1.46.1,To Be Determined,Bugs,Joel de Guzman,new,2012-01-16T10:51:29Z,2012-01-16T13:37:15Z,"I use a very dynamic parser where I need to inherit & parse attributes using the Nabialek trick. As the Nabialek trick sadly seems to require pointer to rules for efficiency lazy must be used to deffer the derefence. However, if the rule is lets say rule< Iterator, void( T& ) >, then it would seem it's impossible to pass T& to the rule as lazy() doesn't provide the same semantics as rule< Iterator, void( T& ) >. ",sairony@…
6398,intermodule_singleton crash in Windows,interprocess,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,reopened,2012-01-13T20:10:52Z,2014-10-30T15:00:22Z,"Steps to reproduce the problem:

* Create singleton_dll.dll.
* Create singleton_exe.exe, which uses singleton_dll.dll.
* Run. On exit, an access violation happens.

Seemingly, the problem happens when two different singletons are
created, one in the main executable and the other in a DLL. If both
singletons are created in the same module everything's OK, though. 

More context in http://lists.boost.org/Archives/boost/2012/01/189577.php",Joaquín M López Muñoz
6391,New reverse_graph edge descriptor type breaks shared property maps,graph,Boost 1.48.0,To Be Determined,Bugs,Jeremiah Willcock,new,2012-01-11T15:00:26Z,2012-03-23T10:35:05Z,"The newly implemented data type for the edge descriptor of reversed_graph does not allow for the transparent sharing of edge property maps between the base and reversed graphs, which was possible with the old code (< 1.48), since its type is not related to the base graph. This is a very useful feature, and I think it should be preserved.

I'm sending attached a patch which makes the reversed edge descriptior a derived class from the base edge descriptor. This makes the type itself distinct from the base graph, avoiding any ambiguities, while at the same time preserving interchangeability with the base descriptor when required, e.g. when accessing property maps. This also makes the code a bit more elegant.",tiago@…
6369,gcc -Wshadow typedef patch,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2012-01-09T11:08:12Z,2012-01-23T06:09:39Z,"With -Wshadow and gcc 4.6.1 I get...

LibreOffice/core/solver/callcatcher/inc/boost/date_time/gregorian/gregorian_io.hpp: In function 'std::basic_istream<_CharT, _Traits>& boost::gregorian::operator>>(std::basic_istream<_CharT, _Traits>&, boost::gregorian::date&)':
LibreOffice/core/solver/callcatcher/inc/boost/date_time/gregorian/gregorian_io.hpp:80:67: error: declaration of 'date_input_facet' shadows a global declaration [-Werror=shadow]
/home/caolan/LibreOffice/core/solver/callcatcher/inc/boost/date_time/gregorian/gregorian_io.hpp:43:57: error: shadowed declaration is here [-Werror=shadow]

patch to silence these attached",caolanm@…
6365,Compiler warnings when running static code analysis after build on MSVC 10,exception,Boost 1.48.0,To Be Determined,Bugs,Emil Dotchevski,new,2012-01-07T14:36:49Z,2012-01-07T14:36:49Z,"As the title says I'm getting several compiler warnings when running static code analysis in Visual Studio 10 (attached the list to the ticket).

The reported warnings are harmless (are only triggered by the static analyzer and not when compiling with warning level 4), but could you fix them if you have the time?

I'm getting two type of warnings.

== Warning type 1 ==
 
warning C6246: Local declaration of 'l' hides declaration of the same name in outer scope. For additional information, see previous declaration at line '131' of 'c:\users\seppe\boost_1_48_0\boost\exception\diagnostic_information.hpp': Lines: 131	c:\users\seppe\boost_1_48_0\boost\exception\diagnostic_information.hpp	140

warning C6246: Local declaration of 'fn' hides declaration of the same name in outer scope. For additional information, see previous declaration at line '132' of 'c:\users\seppe\boost_1_48_0\boost\exception\diagnostic_information.hpp': Lines: 132	c:\users\seppe\boost_1_48_0\boost\exception\diagnostic_information.hpp	144

and the affected code:

{{{
130: char const * const * f=get_error_info<throw_file>(*be);
131: int const * l=get_error_info<throw_line>(*be);
132: char const * const * fn=get_error_info<throw_function>(*be);
133: if( !f && !l && !fn )
134:    tmp << ""Throw location unknown (consider using BOOST_THROW_EXCEPTION)\n"";
135: else
136: {
137:    if( f )
138:    {
139:       tmp << *f;
140:       if( int const * l=get_error_info<throw_line>(*be) )
141:          tmp << '(' << *l << ""): "";
142:    }
143:    tmp << ""Throw in function "";
144:    if( char const * const * fn=get_error_info<throw_function>(*be) )
145:       tmp << *fn;
146:    else
147:       tmp << ""(unknown)"";
148:    tmp << '\n';
149: }
}}}

Both warnings can be fixed by:

    - line 140: replacing if( int const * l=get_error_info<throw_line>(*be) ) with if( l )
    - line 144: replacing if( char const * const * fn=get_error_info<throw_function>(*be) ) with if( fn )

== Warning type 2 ==

Only displaying the first warning.

warning C6246: Local declaration of 'e' hides declaration of the same name in outer scope. For additional information, see previous declaration at line '300' of 'c:\users\seppe\boost_1_48_0\boost\exception\detail\exception_ptr.hpp': Lines: 300	c:\users\seppe\boost_1_48_0\boost\exception\detail\exception_ptr.hpp	332

and the affected code:


{{{

296: inline
297: exception_ptr
298: current_exception_impl()
299:     {
300:     exception_detail::clone_base const * e=0;

<<snip>>

328:         try
329:             {
330:             throw;
331:             }
332:         catch(
333:         exception_detail::clone_base & e )
334:             {
335:             return exception_ptr(shared_ptr<exception_detail::clone_base const>(e.clone()));
336:             }

...

}}}

Well this is more of a false positive of the static analyzer, but can be avoided by changing the variable name of the caught exception.

'''Remark''': A warning is generated for each caught exception in the method (see attached list).

",seppe.de.clercq@…
6363,Incorrect error documentation for time_zone_from_region() in tz_db_base.hpp,date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2012-01-07T00:50:48Z,2012-01-07T00:50:48Z,"In the event of an error, time_zone_from_region()'s documentation is incorrect in the following ways:

- The function returns a null pointer. It does not throw an exception.
- The specified ""record_not_found"" exception does not exist.

Here's the doc/code in question (identical in at least 1.46.0-1.48.0):

{{{
      //! Returns a time_zone object built from the specs for the given region
      /*! Returns a time_zone object built from the specs for the given 
       * region. If region does not exist a local_time::record_not_found 
       * exception will be thrown */
      boost::shared_ptr<time_zone_base_type> 
      time_zone_from_region(const string_type& region) const 
      {
        // get the record
        typename map_type::const_iterator record = m_zone_map.find(region);
        if(record == m_zone_map.end()){
          return boost::shared_ptr<time_zone_base_type>(); //null pointer
        }
        return record->second;
      }
}}}",nickbp@…
6358,Documentation,numeric,Boost 1.48.0,To Be Determined,Bugs,Fernando Cacciola,new,2012-01-04T20:40:27Z,2012-01-04T20:40:27Z,"I want to use boost numeric conversion.

I NEED to use boost numeric conversion.

But I can't really figure out how to use it.

a) the interface with policies which contain function options which contain...
is just too hard to follow.  I  think this is a design problem.

b) the documentation of all this isn't complete - and it reflects the interface.  trying to figure it out is like pulling teeth.

It ""looks like"" it depends upon numeric_limits for minimums, maximums, etc.  I would hope this means that if I create my own numeric type and specialize numeric_limits for it, the convert<...> will ""just work"" and I'll get an overflow/under flow exception when I need it.  But trying to verify that this works like this by looking at the documentation is like pulling teeth.  I believe the library works and/or can be made to work for what I want to do, but the documentation is presenting a real obstacle so I have to look at the code itself - which I shouldn't have to do.

Robert Ramey
",Robert Ramey
6353,memory layout specifiers doc clarification,multi_array,Boost 1.48.0,To Be Determined,Support Requests,Ronald Garcia,new,2012-01-03T14:44:56Z,2012-01-03T14:44:56Z,"http://www.boost.org/doc/libs/1_48_0/libs/multi_array/doc/reference.html#memory_layout

Contains an ambiguous specification of storage ordering.  This lead me to
making the wrong assumption about the meaning as shown by the following
post:

http://article.gmane.org/gmane.comp.lib.boost.user/72160

As indicated in that post, *if* I had read the page:

http://www.boost.org/doc/libs/1_48_0/libs/multi_array/doc/user.html#sec_storage

the meaning or storage ordering would have been clear; however,
I thought reading the reference.html#memory_layout page would have
been the most unambiguous doc since it is the reference manual.

I think the following snippet of code, or something similar, on
the reference.html#memory_layout would make the meaning clearer:
{{{
  std::vector<unsigned>
strides_expected
  ( std::vector<unsigned> const& a_permut 
      //storage order(a permutaion 0..a_lengths.size()-1)
  , std::vector<unsigned> const& a_lengths
      //length of axes.
  )
{
    unsigned const n=a_lengths.size();
    std::vector<unsigned> strides(n);
    strides[permut_i[0]]=1;
    for( unsigned i=1; i<n; ++i) 
    {
        unsigned i_prev=permut_i[i-1];
        strides[permut_i[i]]=strides[i_prev]*a_lengths[i_prev];
    }
    return strides;//strides of the axes
}
}}}",cppljevans
6351,Better JSON parser,property_tree,Boost 1.49.0,To Be Determined,Feature Requests,Sebastian Redl,new,2012-01-03T08:58:50Z,2015-07-07T14:04:55Z,"JSON parser in property_tree doesn't parse numbers and bools as their type.
Instead it stores them as string.

property_tree for JSON could be defined in other way:

{{{
#!python
typedef boost::variant<int, long, std::string> base_json_type;
typedef boost::variant<
  base_json_type,
  std::vector<base_json_type>
> composite_json_type;

typedef boost::basic_ptree<std::string, composite_json_type> json_ptree;
}}}",nn-mail@…
6350,MINGW Build missing mingw.jam,build,Boost 1.48.0,Boost 1.49.0,Bugs,Vladimir Prus,new,2012-01-03T07:44:00Z,2012-12-17T06:46:45Z,"If I try to build boost on Windows7 with mingw-shell:

{{{
  ./bootstrap.sh --toolset=mingw
}}}

then b2 and bjam will be build successfully, but the call

{{{
  ./b2
}}}

fails with 

{{{
mingw.jam: No such file or directory
d:/extswrc/boost/tools/build/v2/build\toolset.jam:38: in toolset.using
rule mingw.init unknown in module toolset. Windows, these are static
d:/extswrc/boost/tools/build/v2/build\project.jam:888: in using
project-config.jam:12: in modules.loadsing shared runtime. On Linux, these
d:/extswrc/boost/tools/build/v2\build-system.jam:257: in load-config
d:/extswrc/boost/tools/build/v2\build-system.jam:423: in load-configuration-files
d:/extswrc/boost/tools/build/v2\build-system.jam:555: in load
d:\extswrc\boost\tools\build\v2/kernel\modules.jam:283: in import
d:\extswrc\boost\tools\build\v2\kernel\bootstrap.jam:142: in boost-build
d:\extswrc\boost\boost-build.jam:17: in module scopeg
}}}

if I copy the gcc.jam to mingw.jam and rename gcc into mingw in mingw.jam then I can build boost with b2. So I would suggest to add a mingw.jam file to tools/build/v2/tools.",anonymous
6348,unresolved symbols when kinking with gcc-3.4.6,date_time,Boost Development Trunk,To Be Determined,Support Requests,az_sw_dude,new,2012-01-02T21:38:23Z,2012-01-02T21:38:23Z,"
This tester is reporting some unresolved symbols at link time.

{{{
Test output: Sandia-gcc-3.4.6 - thread - test_condition_lib / gcc-3.4.6
Rev 76256 / Sun, 1 Jan 2012 14:31:22 +0000
Report Time: Mon, 2 Jan 2012 07:46:13 +0000
Compile [2012-01-01 15:09:10 UTC]: succeed
""/sierra/Sntools/extras/compilers/gcc-3.4.6/bin/g++""  -ftemplate-depth-128 -O0 -fno-inline -Wall -g -pthread -fPIC -m32  -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1  -I"".."" -c -o ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition.o"" ""../libs/thread/test/test_condition.cpp""
 
Link [2012-01-01 15:09:10 UTC]: fail
 
    ""/sierra/Sntools/extras/compilers/gcc-3.4.6/bin/g++""    -o ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition_lib"" -Wl,--start-group ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition.o"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/tss_null.o"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/test/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_unit_test_framework.a"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a""  -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread -m32
 
 
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
collect2: ld returned 1 exit status
}}}

Boost.Thread doesn't link with Boost.Date and doesn't have this issue on other platform/compilers. Is there something specific on this platform that makes the link mandatory, or there is something that can be done in Boost.Thread to don't need to link?",viboes
6327,Error in documentation of boost::numeric::ublas::triangular_matrix,uBLAS,Boost 1.48.0,To Be Determined,Bugs,Gunter,new,2011-12-28T11:26:10Z,2011-12-28T11:26:10Z,"The documentation under http://www.boost.org/doc/libs/1_48_0/libs/numeric/ublas/doc/triangular.htm#1TriangularMatrix says in Section 1.1:

''For a (n x n )-dimensional '''lower''' triangular matrix and 0 <= i < n,0 <= j < n holds ti, j = 0 , if i > j. If furthermore holds ti, i= 1 the matrix is called unit '''lower''' triangular. For a (n x n )-dimensional lower triangular matrix and 0 <= i < n,0 <= j < n holds ti, j = 0 , if i < j. If furthermore holds ti, i= 1 the matrix is called unit lower triangular.''

Based on the code example in Section 1.2, I think that the bolded occurrences of ""lower"" should be replaced with ""upper"", so that the above paragraph reads:

''For a (n x n )-dimensional '''upper''' triangular matrix and 0 <= i < n,0 <= j < n holds ti, j = 0 , if i > j. If furthermore holds ti, i= 1 the matrix is called unit '''upper''' triangular. For a (n x n )-dimensional lower triangular matrix and 0 <= i < n,0 <= j < n holds ti, j = 0 , if i < j. If furthermore holds ti, i= 1 the matrix is called unit lower triangular.''
",Roman Werpachowski <roman.werpachowski@…>
6325,InterlockedExchangeAdd improperly identified as managed code.,asio,Boost 1.48.0,To Be Determined,Support Requests,chris_kohlhoff,new,2011-12-27T21:44:57Z,2013-05-24T03:15:34Z,"There is a Microsoft C++ bug that causes InterlockedExchangeAdd to improperly be identified as managed code instead of native code. A workaround is mentioned here:
http://connect.microsoft.com/VisualStudio/feedback/details/629931/internal-compiler-error-c1001-when-compiling-opencv-2-1-2-2-with-c-cli-64-bit

This prevents programs from being compiled correctly in VS2010

The workaround is implemented below:

boost\asio\detail\win_thread.hpp:45

{{{
return (1?::InterlockedExchangeAdd(&terminate_threads_, 0) != 0: 0!= InterlockedExchangeAdd64((volatile LONG64 *)0,(LONG64) 0));

}}}

and

boost\asio\detail\impl\winsock_init.ipp:54
{{{
long result = (1?::InterlockedExchangeAdd(&d.result_, 0) : InterlockedExchangeAdd64((volatile LONG64 *)0,(LONG64) 0));
}}}

Implementing the above fix allows the programs to compile with a warning:
{{{
warning C4793: 'boost::asio::detail::win_thread_base<boost::asio::detail::win_thread>::terminate_threads' : function compiled as native :
1>  	Found an intrinsic not supported in managed code
}}}

and

{{{
warning C4793: 'boost::asio::detail::winsock_init_base::throw_on_error' : function compiled as native :
1>  	Found an intrinsic not supported in managed code
}}}


This is a workaround for a compiler bug, so I don't know how the boost development team wants to treat this.

Using VS2010 compiling for a 64-bit target (amd64)",filmorependrgn@…
6322,Improper string formatting in example,asio,Boost 1.48.0,To Be Determined,Patches,chris_kohlhoff,new,2011-12-24T22:26:51Z,2011-12-24T23:38:13Z,"doc/html/boost_asio/example/chat/chat_message.hpp has an improper string formatting that can cause compiler noisiness.
",filmorependrgn@…
6320,race condition in boost::filesystem::path leads to crash when used in multithreaded programs,filesystem,Boost 1.64.0,To Be Determined,Bugs,Beman Dawes,reopened,2011-12-24T00:44:29Z,2018-04-22T11:42:14Z,"following app crashes on VC10 (Windows 7) (multibyte and Unicode builds)
at point of creation of path (im working around the issue by
doing dummy string to wstring conversion)
[
 wstring r; std::copy(s.begin(),s.end(),r.begin()); 
]

{{{
#!c++
#include <boost/thread.hpp>
#include <boost/filesystem.hpp>


int main(void)
{
	std::string sPath(""c:\\Development"");
	
	boost::thread_group tg;

	for(int i = 0; i < 2; i++)
	{
		tg.create_thread([&sPath](){
			boost::this_thread::sleep(boost::posix_time::milliseconds(10));
			boost::filesystem::path p(sPath);

			boost::filesystem::directory_iterator di(p), end;
			while(di != end)
				std::cout << (*(di++)).path().string() << std::endl;
		});
	}

	tg.join_all();

	int a;
	std::cin >> a;

}
}}}
VC10 CallStack:
{{{
>	msvcp100d.dll!std::codecvt<wchar_t,char,int>::in(int & _State, const char * _First1, const char * _Last1, const char * & _Mid1, wchar_t * _First2, wchar_t * _Last2, wchar_t * & _Mid2)  Line 1521 + 0x1f bytes	C++
 	filesystem_crash.exe!`anonymous namespace'::convert_aux(const char * from, const char * from_end, wchar_t * to, wchar_t * to_end, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & target, const std::codecvt<wchar_t,char,int> & cvt)  Line 84 + 0x25 bytes	C++
 	filesystem_crash.exe!boost::filesystem3::path_traits::convert(const char * from, const char * from_end, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & to, const std::codecvt<wchar_t,char,int> & cvt)  Line 165 + 0x20 bytes	C++
 	filesystem_crash.exe!boost::filesystem3::path_traits::dispatch<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > >(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & c, std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & to, const std::codecvt<wchar_t,char,int> & cvt)  Line 174 + 0x7e bytes	C++
 	filesystem_crash.exe!boost::filesystem3::path::path<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & source, void * __formal)  Line 135 + 0x13 bytes	C++
 	filesystem_crash.exe!`anonymous namespace'::<lambda0>::operator()()  Line 15 + 0x10 bytes	C++
 	filesystem_crash.exe!boost::detail::thread_data<`anonymous namespace'::<lambda0> >::run()  Line 62	C++
 	filesystem_crash.exe!boost::`anonymous namespace'::thread_start_function(void * param)  Line 177	C++
 	msvcr100d.dll!_callthreadstartex()  Line 314 + 0xf bytes	C
 	msvcr100d.dll!_threadstartex(void * ptd)  Line 297	C
}}}
",aris.basic@…
6304,parsing ptime with set facet fails,date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2011-12-20T09:02:51Z,2012-01-23T06:12:37Z,"Hi,

when parsing a ptime with ""%Y-%m-%d"" facet, the parser ignores checking the intermediate characters: ""-"". This patches makes the parser check for intermediate characters.

Kind regards

Thomas Lemm
",Thomas.Lemm@…
6302,"int_adapter<T>::from_special(special_values) is not inlined, so duplicated",date_time,Boost 1.48.0,,Bugs,az_sw_dude,new,2011-12-19T23:12:17Z,2012-07-05T02:42:59Z,"It seems that this function 

{{{
template<typename int_type_>
class int_adapter {

  static int_adapter from_special(special_values sv)
  {
    switch (sv) {
    case not_a_date_time: return not_a_number();
    case neg_infin:       return neg_infinity();
    case pos_infin:       return pos_infinity();
    case max_date_time:   return (max)();
    case min_date_time:   return (min)();
    default:              return not_a_number();
    }
  }

}}}

is not been inlined with gcc 3.4.6 and so it is duplicated at link time.
See link error on regression test

{{{
Test output: Sandia-gcc-3.4.6 - thread - test_condition_lib / gcc-3.4.6
Rev 76061 / Mon, 19 Dec 2011 12:54:33 +0000
Report Time: Mon, 19 Dec 2011 21:30:12 +0000

Compile [2011-12-19 13:33:17 UTC]: succeed

""/sierra/Sntools/extras/compilers/gcc-3.4.6/bin/g++""  -ftemplate-depth-128 -O0 -fno-inline -Wall -g -pthread -fPIC -m32  -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1  -I"".."" -c -o ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition.o"" ""../libs/thread/test/test_condition.cpp""


Link [2011-12-19 13:33:17 UTC]: fail

    ""/sierra/Sntools/extras/compilers/gcc-3.4.6/bin/g++""    -o ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition_lib"" -Wl,--start-group ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/test_condition.o"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_condition_lib.test/gcc-3.4.6/debug/address-model-32/threading-multi/tss_null.o"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/test/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_unit_test_framework.a"" ""/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a""  -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread -m32 


`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
`.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' referenced in section `.rodata' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9date_time11int_adapterIxE12from_specialENS0_14special_valuesE' of /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-3.4.6/debug/address-model-32/link-static/threading-multi/libboost_thread.a(thread.o)
collect2: ld returned 1 exit status

}}}
",viboes
6300,c++11: Provide move semantic for tuple class and factory functions,fusion,Boost 1.48.0,To Be Determined,Feature Requests,Joel de Guzman,new,2011-12-19T18:19:49Z,2011-12-19T18:19:49Z,"Provide a c++11 move semantic compliant tuple class and factory functions on compilers supporting rvalue references. 

On C++03 compilers use the Boost.Move emulation. 

20.4.2	Class template tuple

{{{

template <class... UTypes>
explicit tuple(UTypes&&...);
tuple(tuple&&) = default;
template <class... UTypes> tuple(tuple<UTypes...>&&);
template <class U1, class U2>
tuple(pair<U1, U2>&&);
tuple& operator=(tuple&&) noexcept;
template <class... UTypes> tuple& operator=(tuple<UTypes...>&&);
template <class U1, class U2> tuple& operator=(pair<U1, U2>&&) noexcept;
}}}



",viboes
6299,c++11: Provide move semantic for bind function,phoenix,Boost 1.48.0,To Be Determined,Feature Requests,Thomas Heller,new,2011-12-19T18:08:51Z,2011-12-19T18:14:13Z,"Provide a c++11 compliant bind function on compilers supporting rvalue references.

20.8.9.1.2	Function template bind

template<class F, class... BoundArgs> unspecified bind(F&& f, BoundArgs&&... bound_args);

template<class R, class F, class... BoundArgs> unspecified bind(F&& f, BoundArgs&&... bound_args);",viboes
6297,Warning under VC,numeric,Boost 1.48.0,To Be Determined,Feature Requests,Douglas Gregor,new,2011-12-19T15:57:09Z,2011-12-19T15:57:09Z,"Warning text:[[BR]]
c:\test\boost\boost\numeric\conversion\detail\converter.hpp(166) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)
        c:\test\boost\boost\numeric\conversion\detail\converter.hpp(165) : while compiling class template member function 'boost::numeric::range_check_result boost::numeric::convdetail::GT_HiT<Traits>::apply(bool)'
        with
        [
            Traits=conv_traits
        ]
        c:\test\boost\boost\numeric\conversion\detail\converter.hpp(236) : see reference to class template instantiation 'boost::numeric::convdetail::GT_HiT<Traits>' being compiled
        with
        [
            Traits=conv_traits
        ]
        c:\test\boost\boost\numeric\conversion\detail\converter.hpp(288) : see reference to class template instantiation 'boost::numeric::convdetail::combine<PredA,PredB>' being compiled
        with
        [
            PredA=boost::numeric::convdetail::non_applicable,
            PredB=boost::numeric::convdetail::GT_HiT<conv_traits>
        ]
        c:\test\boost\boost\numeric\conversion\detail\converter.hpp(287) : while compiling class template member function 'boost::numeric::range_check_result boost::numeric::convdetail::generic_range_checker<Traits,IsNegOverflow,IsPosOverflow,OverflowHandler>::out_of_range(bool)'
        with
        [
            Traits=conv_traits,
            IsNegOverflow=boost::numeric::convdetail::non_applicable,
            IsPosOverflow=boost::numeric::convdetail::GT_HiT<conv_traits>,
            OverflowHandler=boost::numeric::numeric_cast_traits<int,bool>::overflow_policy
        ]
        c:\test\boost\boost\numeric\conversion\detail\converter.hpp(508) : see reference to class template instantiation 'boost::numeric::convdetail::generic_range_checker<Traits,IsNegOverflow,IsPosOverflow,OverflowHandler>' being compiled
        with
        [
            Traits=conv_traits,
            IsNegOverflow=boost::numeric::convdetail::non_applicable,
            IsPosOverflow=boost::numeric::convdetail::GT_HiT<conv_traits>,
            OverflowHandler=boost::numeric::numeric_cast_traits<int,bool>::overflow_policy
        ]
        c:\test\boost\boost\numeric\conversion\converter.hpp(35) : see reference to class template instantiation 'boost::numeric::convdetail::non_rounding_converter<Traits,RangeChecker,RawConverter>' being compiled
        with
        [
            Traits=conv_traits,
            RangeChecker=boost::numeric::convdetail::generic_range_checker<conv_traits,boost::numeric::convdetail::non_applicable,boost::numeric::convdetail::GT_HiT<conv_traits>,boost::numeric::numeric_cast_traits<int,bool>::overflow_policy>,
            RawConverter=boost::numeric::raw_converter<conv_traits>
        ]
        c:\test\boost\boost\numeric\conversion\cast.hpp(53) : see reference to class template instantiation 'boost::numeric::converter<T,S,Traits,OverflowHandler,Float2IntRounder,RawConverter,UserRangeChecker>' being compiled
        with
        [
            T=int,
            S=bool,
            Traits=conv_traits,
            OverflowHandler=boost::numeric::numeric_cast_traits<int,bool>::overflow_policy,
            Float2IntRounder=boost::numeric::Trunc<bool>,
            RawConverter=boost::numeric::raw_converter<conv_traits>,
            UserRangeChecker=boost::numeric::numeric_cast_traits<int,bool>::range_checking_policy
        ]

The code that may lead to warning is like this:
{{{
    int val = boost::numeric_cast<int>(true);
}}}

",Antony Polukhin
6296,wrong has_trivial_constructor value for custom class follows to programm fail,uBLAS,Boost 1.48.0,To Be Determined,Bugs,Gunter,new,2011-12-19T12:23:19Z,2012-01-23T07:20:03Z,"System:
 -- Windows Server 2008 R2 x64
 -- Visual Studio 2010

I use wrapper for MPFR (http://www.holoborodko.com/pavel/mpfr/) and custom std::complex type implementation for mpreal class (see attachment)

typedef mpfr::mpreal					number;
typedef std::complex<number>				complex;
typedef boost::numeric::ublas::matrix<complex>		cmatrix;

cmatrix m1 = E - J;
// E, J -- cmatrix

storege.hpp:
explicit BOOST_UBLAS_INLINE
        unbounded_array (size_type size, const ALLOC &a = ALLOC()):
            alloc_(a), size_ (size) {
          if (size_) {
              data_ = alloc_.allocate (size_);
		// has_trivial_constructor returns true for complex<number>,
		// but this is my custom class with implemented default construtor
              if (! detail::has_trivial_constructor<T>::value) {
                  for (pointer d = data_; d != data_ + size_; ++d)
                      alloc_.construct(d, value_type());
              }
          }
          else
              data_ = 0;
        }",azubanov@…
6295,Documentation Example Error,asio,Boost 1.48.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-12-19T11:06:05Z,2011-12-19T11:24:42Z,"In the example documentation for the multicast sender in the asio section (http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/example/multicast/sender.cpp), the code for sending the message in the handle_timeout( ... ) method instantiates a buffer by referencing directly the 'message_' member variable, which is a std::string.  This results in a 'string is not dereferanceable' exception being thrown (on Windows anyway).

If this is changed so that buffer is created using the 'message_.data()' method then all is well.
",anonymous
6285,fix type qualifiers ignored on function return type,ptr_container,Boost Development Trunk,To Be Determined,Patches,Thorsten Ottosen,new,2011-12-17T16:22:32Z,2012-01-07T18:58:08Z,,pedro.larroy.lists@…
6282,filter and other views transform the sequence type,mpl,Boost Release Branch,To Be Determined,Feature Requests,Joel Falcou,new,2011-12-16T22:34:45Z,2011-12-16T22:34:45Z,"code such as the following doesn't work.  That is, none of the views can produce a set type sequence.  Note this is diffferent from fusion so it is possible.  I also realize that this is non-trivial enhancement. Oh well.
{{{
    struct a {};
    struct b {};
    struct c {};
    struct d {};
    typedef boost::mpl::set<a, b, c> s1;
    BOOST_CONCEPT_ASSERT(( boost::mpl::AssociativeSequence<s1> ));
    typedef boost::mpl::set<c, d> s2;
    BOOST_CONCEPT_ASSERT(( boost::mpl::AssociativeSequence<s2> ));
    typedef boost::mpl::joint_view<s1, s2>::type sdiff;
    BOOST_CONCEPT_ASSERT(( boost::mpl::AssociativeSequence<sdiff> ));
}}}

I know it's correct as is - that is it works according to they it's described in the manual.  But it was hard to find my mistake.
",Robert Ramey
6281,Concepts for MPL,mpl,Boost 1.48.0,To Be Determined,Feature Requests,Joel Falcou,new,2011-12-16T22:25:25Z,2011-12-17T17:17:44Z,"Attached please find implementation of concepts for MPL sequences and iterators.  This includes some archtypes as well as some testing of the mpl implementations.  This isn't quite complete, but it does do enough to help me find some errors in my mpl usage.",Robert Ramey
6280,numeric_cast throws on exactly representable conversion,numeric,Boost 1.47.0,To Be Determined,Bugs,Douglas Gregor,new,2011-12-16T21:53:37Z,2016-06-06T19:21:07Z,"If a double or float representing the smallest possible value of int64_t is cast to int64_t using numeric_cast, an exception is thrown saying that a negative overflow has occured.

I would expect the cast to work, since the value is exactly representable in the target type. Since the absolute value is a power of two, there should not be any error in the floating point representation.

This is also reproducable in trunk, according to VeXocide. I found the problem in Boost 1.47.0 on Windows, using MinGW 4.5.2.",Simeon Maxein <smaxein@…>
6279,"asio needs ""poll"" with timeout",asio,Boost 1.48.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2011-12-16T16:51:19Z,2011-12-16T16:51:19Z,"There were much of discussion about synchronous operations in asio with timeouts, bug #2832 for example. The main argument against it was difficulties with composed operations. I propose a compromise: some form of ""poll"" with timeout (poll_read/poll_write or something like that). I mean synchronous version of async_read_some(null_buffers()). If it will be implemented, it will be easy to write sync read with timeout, using combination of poll_read/read_some. I'm sure this ""portable poll"" will be very useful.",Gennady Proskurin <gpr@…>
6278,mem_fn has a different result_type,bind,Boost 1.48.0,To Be Determined,Bugs,Peter Dimov,new,2011-12-16T10:54:46Z,2012-10-22T22:01:37Z,"The following code does not compile:

{{{
#!c++
/* 
<URL: file://localhost/usr/share/doc/packages/boost-1.44.0/libs/bind/mem_fn.html#Purpose >

   All function objects returned by mem_fn expose a result_type typedef
   that represents the return type of the member function. For data
   members, result_type is defined as the type of the member.

*/

typedef int type_of_the_member;

struct U { type_of_the_member m; };

template < class F > 
typename F ::result_type U_m (F const &t, U &u) 
{ typedef typename F:: result_type r; typedef type_of_the_member r;
typename F:: result_type r1; return t (u); }

U u; int x ((U_m (::boost ::mem_fn (&U ::m), u)));
}}}

[http://codepad.org/1op6p2Mc codepad] says: ''error: conflicting declaration 'typedef type_of_the_member r' ''",giecrilj@…
6250,allow sorting through an adaptor,iterator,Boost 1.48.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2011-12-10T22:15:54Z,2012-11-21T22:39:46Z,"The following code does not compile because the transform adaptor offers a proxy reference that cannot be modified:

{{{
#!c++
#include <iostream>
#include <boost/array.hpp>
#include <boost/range/algorithm/copy.hpp>
#include <boost/range/adaptor/transformed.hpp>
#include <boost/bind.hpp>
#include <boost/range/algorithm/sort.hpp>

struct underlying { int m_; }; 

int main (int, char *[]) { 
  enum LocalParam { BASE = 073, VALUE = 030 }; 
  typedef ::boost ::array < underlying, +BASE - 01 > mycont; mycont v;
  for 
    (::boost ::range_iterator < mycont >:: type p ((::boost ::begin (v))); 
p < ::boost ::end (v); ++p) 
    p -> m_ = p == ::boost ::begin (v)? +VALUE: p [-01] .m_ * VALUE % BASE;
  ::boost ::copy 
      (v 
| ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)), 
       ::std ::ostream_iterator 
< int, ::std ::istream ::char_type > 
       (::std:: cout, "" "")); ::std ::cout << '\n';
  ::boost ::sort 
      (v 
| ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)));   
::boost ::copy 
      (v 
| ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)), 
       ::std ::ostream_iterator 
< int, ::std ::istream ::char_type > 
       (::std:: cout, "" "")); 
  return (::std ::cout << '\n') .flush ()? +EXIT_SUCCESS: +EXIT_FAILURE; }

}}}

This is a deficiency because, when you have relational data packaged in a container, you often wish to create various indices based on various aspects of the data.  This is currently unsupported by Boost, except for Multi-Index, but Multi-Index does not allow you to create a detached index; instead, it insists on maintaining all indices dynamically all the time, which is not always necessary and it brings a performance penalty compared to sorting static data.

I have implemented the missing adaptor and called it '''shufflebase'''; when applied to an adaptor, it allows the sort algorithm to rearrange the ''original container'' based on ''the ordering of the adaptor''.

Here is the adaptor code; note that it does not carry any algorithm, only type juggling and general logistics:

{{{
#!c++
#include <boost/range/iterator_range.hpp>	/* boost:: iterator_range */

#ifndef BOOST_RANGE_ADAPTOR_SHUFFLEBASE_DEFINED
#if 1
namespace boost {
  /*
the following declarations are used in namespace adaptors;
they are here to keep the namespace in one piece */

#if 2
  namespace traits { template < class P_I > struct shufflebase; }
#endif    /* &boost.traits */

  template < class P_I > class shufflebase_iterator;

#if 2
namespace adaptors {
  /* a forward declaration for operator | */
  template < class P_R > struct shufflebase_range;

#if 3
  namespace detail
{ struct /* tag enabler for operator | */ shufflebase_forwarder {};
template < class P_R >
inline struct shufflebase_range < P_R const >
/* applies the shufflebase adaptor to a range */
operator | (P_R const &p_r, struct detail:: shufflebase_forwarder );
}
#endif    /* &boost.adaptors.detail */

#if 3
  namespace /* static */ {
    detail :: shufflebase_forwarder const
/* the formal parameter for operator | */
(&shufflebase) ((detail ::shufflebase_forwarder ())); }
#endif    /* &boost.adaptors.static */

#if 3
  namespace traits { template < class P_T > struct shufflebase_range; }
#endif    /* &boost.adaptors.traits & */

#if 3
  template < class P_R >
  /* applies shufflebase_iterator to the range */
struct shufflebase_range     
:public traits ::shufflebase_range < P_R > ::base {
public:
    inline shufflebase_range (P_R &p_r);
private: typedef traits ::shufflebase_range < P_R > traits;
private: typedef typename traits ::base base;
public: typedef typename traits ::iterator iterator; };
#endif    /* #boost.adaptors.shufflebase_range */

#if 3
  namespace traits {

#if 4
    template < class P_R >
/* typedefs for shufflebase_range proper */ struct shufflebase_range
{ typedef  
::boost :: shufflebase_iterator
< typename ::boost ::range_iterator < P_R > ::type > iterator;
typedef struct ::boost ::iterator_range < iterator > base; };
#endif    /* #boost.adaptors.traits.shufflebase_range */

 }
#endif    /* &boost.adaptors.traits */

}
#endif    /* &boost.adaptors */

#if 2
  template < class P_I >
/*
Behaves transparently when applied to an adapted iterator
except that assignments are possible and apply to the underlying base */
  class shufflebase_iterator  
    :public /* iterator faciade */ traits:: shufflebase < P_I >:: base_type
  {
public:
/* constructs from an adapted iterator */
inline shufflebase_iterator (P_I const &);
  public:
/* inherited */ typedef typename shufflebase_iterator ::reference reference;
  public: /* returns a proxy reference */
    inline
reference
/* safety net: exclude application of default operator = to temporary */ const
operator* () const;
  public:
/* inherited */ typedef typename shufflebase_iterator ::value_type value_type;
  public: /* assigns the value to the base element, bypassing the adaptor */
    inline void assign (value_type const &p_v) const;
  public:
/* bookkeeping */
typedef typename traits:: shufflebase < P_I >:: base_type inherited; };
#endif    /* #boost.shufflebase_iterator */

#if 2
  namespace detail { template < class P_I > class shufflebase_reference;

#if 3
    template < class P_I >
    /*
Stores a value of an iterator.  

This class plays a double duty:
it stores the base value for assigning to a reference
and it caches the adapted value for comparisons.  
This causes some memory overhead
that I believe is unavoidable
without knowing the details of the managed adaptor.  
Moreover, caching the adapted value may speed things up a bit.  

This class is necessary
because the sorting algorithm puts some values aside for later use.  */

    class shufflebase_value
    {
public: /* bookkeeping */ typedef P_I base_type;
public: /* construct from a reference */
  inline
  shufflebase_value (class shufflebase_reference < base_type > const &p_r);
    public: /* the adapted value type */
typedef typename ::std ::iterator_traits < base_type > ::value_type adapted;
    public: /* compares as adapted */
      inline operator adapted const &() const;
    private: /* the adapted value */ adapted m_adapted;
public: /* the base value type */
  typedef typename traits ::shufflebase < base_type > ::base_value base_value;
    private: /* the base value */ base_value m_base;
    public:
/*
returns the base value for assignment
(the adapter is meant to affect the base container, remember? */
inline base_value const &base () const; };
#endif    /* #boost.detail.shufflebase_value */

#if 3
    template < class P_I >

    /*
A proxy class serving as reference type for shufflebase_iterator.  

Implicitly converts to the adapted reference for comparisons.  
Assignment affects the base object instead.
    */

    class shufflebase_reference
    {
public: /* bookkeeping */ typedef P_I base_type;
public: /* the adapted reference type */ typedef
typename ::std ::iterator_traits < base_type > ::reference reference;
    public: /* compares as adapted */
      inline operator reference const () const;   
    public:
/* the adapted value type */
typedef class shufflebase_value < base_type > value_type;
    public: /* assigned value goes to base */
inline
    shufflebase_reference const
&operator= (value_type const &p_v) const;
public: /* constructor */ inline
      shufflebase_reference (shufflebase_iterator < base_type > const &);
    private:
/* the proxied iterator */
shufflebase_iterator < base_type > const &m_ref;
    public: /* extract the base value for assigning to a value object */
inline
typename
::std ::iterator_traits < typename base_type:: base_type > ::value_type const
&base () const;
    private:
/* references are not assignable */
void operator = (shufflebase_reference const &); };
#endif    /* #boost.detail.shufflebase_reference */

  }
#endif    /* &boost.detail */

#if 2
namespace traits {

#if 3
  template < class P_I >
/* contains typedefs for shufflebase_iterator */ struct shufflebase
  {
/* bookkeeping */ typedef P_I iterator;

/* the base type for shufflebase_iterator */
typedef ::boost ::iterator_adaptor
  <
    class shufflebase_iterator < iterator >, iterator,  
  class detail:: shufflebase_value < iterator >,
::boost:: use_default,
class detail:: shufflebase_reference < iterator >
  > base_type;

    /* the base value */ typedef
  typename
  ::std ::iterator_traits < typename iterator ::base_type >:: value_type
  base_value;     
/*
The proper place to define base_value would be class shufflebase_value;
however, this type is shared by other auxiliary classes;
they depend on each other, causing the compiler to fail.  */ };
#endif /* #boost.traits.shufflebase */

}
#endif    /* &boost.traits */

}
#endif /* &boost */

#define BOOST_RANGE_ADAPTOR_SHUFFLEBASE_DEFINED
#endif

#ifndef BOOST_RANGE_ADAPTOR_SHUFFLEBASE_IMPLEMENTED

#if 1
namespace boost {

#if 2
  namespace adaptors {

#if 3
    namespace detail {

#if 4
      template <class P_R >
      inline struct shufflebase_range < P_R const >
      operator | (P_R const &p_r, shufflebase_forwarder)
{  return shufflebase_range < P_R const > (p_r); }
#endif    /* !boost.adaptors.shufflebase_range.operator| */

}
#endif    /* &boost.adaptors.detail */

#if 3
    template < class P_R >
    inline shufflebase_range < P_R > ::shufflebase_range (P_R &p_r)  
:base (iterator (::boost ::begin (p_r)), iterator (::boost ::end (p_r))) {}
#endif    /* !boost.adaptors.shufflebase_range.shufflebase_range */
}
#endif    /* &boost.adaptors */

#if 2
  template < class P_I >
  inline typename shufflebase_iterator < P_I > ::reference const
  shufflebase_iterator < P_I > ::operator * () const { return *this; }
#endif    /* !boost.shufflebase_iterator.operator * */

#if 2
  namespace detail {

#if 3
    template < class P_I >
    inline shufflebase_reference < P_I > ::operator reference const () const
{ return *this -> m_ref. base (); }
#endif    /* !boost.detail.shufflebase_reference::reference */

#if 3
    template < class P_I >
    inline shufflebase_reference < P_I > const
    &shufflebase_reference < P_I > ::operator = (value_type const &p_v) const
{ this -> m_ref .assign (p_v); return *this; }
#endif    /* !boost.detail.shufflebase_reference::operator = */

#if 3
    template < class P_I >
    inline shufflebase_reference < P_I > ::shufflebase_reference
    (shufflebase_iterator < P_I > const &p_ref) :m_ref (p_ref) {}
#endif    /* !boost.detail.shufflebase_reference.shufflebase_reference */

#if 3
    template < class P_I >
inline shufflebase_value < P_I > ::shufflebase_value
    (class shufflebase_reference < P_I > const &p_r)      
:m_adapted (p_r), m_base (p_r. base ()) {}
#endif    /* !boost.detail.shufflebase_value.shufflebase_value */

#if 3
template < class P_I >
inline shufflebase_value < P_I >:: operator adapted const & () const
{ return this -> m_adapted; }
#endif    /* !boost.detail.shufflebase_value.adapted & */

#if 3
template < class P_I >
inline
typename ::std ::iterator_traits < typename P_I ::base_type > ::value_type
const
&shufflebase_reference < P_I > :: base () const
{ return *this -> m_ref .base () .base (); }
#endif    /* !boost.detail.shufflebase_reference.base */

#if 3
template < class P_I >
typename shufflebase_value < P_I > ::base_value const
&shufflebase_value < P_I > ::base () const { return this -> m_base; }
#endif    /* !boost.detail.shufflebase_value.base */

}
#endif    /* &boost.detail */

#if 2
template < class P_I >
inline shufflebase_iterator < P_I >:: shufflebase_iterator (P_I const &p_i)
:inherited (p_i) { }
#endif    /* !boost.shufflebase_iterator. */

#if 2
template < class P_I >
inline void shufflebase_iterator < P_I > ::assign (value_type const &p_v) const
{ *this -> base (). base () = p_v. base (); }
#endif    /* !boost.shufflebase_iterator.assign */

}
#endif    /* &boost */

#define BOOST_RANGE_ADAPTOR_SHUFFLEBASE_IMPLEMENTED
#endif
}}}

Having this, the following code becomes valid:

{{{
#!c++
#include <iostream>
#include <boost/array.hpp>
#include <boost/range/algorithm/copy.hpp>
#include <boost/range/adaptor/transformed.hpp>
#include <boost/bind.hpp>
#include <boost/range/algorithm/sort.hpp>

struct underlying { int m_; }; 

int main (int, char *[]) { 
  enum LocalParam { BASE = 073, VALUE = 030 }; 
  typedef ::boost ::array < underlying, +BASE - 01 > mycont; mycont v;
  for 
    (::boost ::range_iterator < mycont >:: type p ((::boost ::begin (v))); 
p < ::boost ::end (v); ++p) 
    p -> m_ = p == ::boost ::begin (v)? +VALUE: p [-01] .m_ * VALUE % BASE;
  ::boost ::copy 
      (v 
| ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)), 
       ::std ::ostream_iterator 
< int, ::std ::istream ::char_type > 
       (::std:: cout, "" "")); ::std ::cout << '\n';
  ::boost ::sort 
      (v 
| ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1))
| ::boost ::adaptors ::shufflebase);   
::boost ::copy 
      (v 
| ::boost ::adaptors ::transformed (::boost ::bind (&underlying ::m_, _1)), 
       ::std ::ostream_iterator 
< int, ::std ::istream ::char_type > 
       (::std:: cout, "" "")); 
  return (::std ::cout << '\n') .flush ()? +EXIT_SUCCESS: +EXIT_FAILURE; }

}}}

and it produces the following output:

24 45 18 19 43 29 47 7 50 20 8 15 6 26 34 49 55 22 56 46 42 5 2 48 31 36 38 27 58 35 14 41 40 16 30 12 52 9 39 51 44 53 33 25 10 4 37 3 13 17 54 57 11 28 23 21 32 1 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 


",giecrilj@…
6240,iterator_size,iterator,Boost 1.48.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2011-12-08T10:43:21Z,2012-11-21T22:20:44Z,"Could you add iterator_size to boost/iterator/iterator_traits.hpp?

It'd be size_t for pointers and, since std::iterator_traits does not yet define size_type, make_unsigned iterator_difference.

It'd be used for the size of a range as given by a valid pair of iterators. ",Olaf van der Spek <olafvdspek@…>
6236,code_converter does not allocate second buffer,iostreams,Boost 1.48.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-12-07T23:36:55Z,2011-12-07T23:40:04Z,"The code_converter will not allocate the second buffer for bidirectional devices.

The open method checks
   if (can_write::value && !is_double::value)
but it should be 
   if (can_write::value && is_double::value)
",Steve Clementi <sclementi2@…>
6216,Add an unwrap adaptor to Range,range,Boost 1.48.0,To Be Determined,Feature Requests,Neil Groves,new,2011-12-05T16:28:51Z,2011-12-05T16:28:51Z,"Iterator adaptors can be easily unwrapped by calling `iterator .base ()`; range adaptors should provide a similar functionality.

My implementation:

{{{
#!cpp
namespace boost 
{ 
  namespace adaptors 
  { 
    namespace detail 
{ struct unwrap_forwarder {}; 
template < class P_R > 
inline 
::boost:: iterator_range 
    < typename ::boost:: range_iterator < P_R >:: type:: base_type > 
operator | (P_R const &p_r, detail:: unwrap_forwarder const &) 
    { 
return 
::boost:: make_iterator_range 
  (::boost:: begin (p_r). base (), ::boost:: end (p_r). base ()); } 
      /* !boost.adaptors.|unwrapped X */ } /* &boost.adaptors.detail X */
    namespace 
{ 
detail:: unwrap_forwarder const 
(&unwrapped) ((detail:: unwrap_forwarder ())); } 
 } /* &boost.adaptors X */ } /* &boost X */
}}}

My test:

{{{
#!cpp
int main () 
{ ::boost:: iterator_range < ::std:: string:: const_iterator > 
      ((::boost:: equal_range 
	(::std:: string () 
| ::boost:: adaptors:: transformed (::std:: negate < int > ()), 0) 
	| ::boost:: adaptors:: unwrapped)); }
}}}",ne01026@…
6197,Maximum file name length for ODS-2 (OpenVMS) not mentioned in portability guide,filesystem,Boost 1.48.0,To Be Determined,Bugs,Beman Dawes,new,2011-12-02T10:40:43Z,2011-12-02T10:40:43Z,"In the ""Path Name Protablity Guide"" there is a list of length limits for names in paths for different operating systems.
There should also be mentioned that the standard OpenVMS file system (ODS-2) allows only 39 characters for the filename (and another 39 for the extension).

There is exactly one header file in the current boost distribution which has more than 39 characters in the filename (Ticket #6196).",cmatuszewski <c.matuszewski@…>
6188,boost directory_iterator construct throw segmentation fault,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,assigned,2011-12-01T04:13:41Z,2012-01-22T15:50:02Z,"Hi, if i view content of directory in ubuntu only i get a segmentation fault it allways happents in (/proc) directory.   ",anonymous
6180,"attributes string ascii escape ""&#nn;"" shouldn't throw exception",property_tree,Boost 1.48.0,To Be Determined,Patches,Sebastian Redl,new,2011-11-28T12:49:07Z,2011-11-28T12:49:07Z,"
In boost/property_tree/detail/rapidxml.hpp

At member function template 
{{{
template<class StopPred, class StopPredPure, int Flags>
static Ch *skip_and_expand_character_refs(Ch *&text)
}}}

It supports escape ""&amp;"", ""&quot;"", ""&gt;"", ""&lt;"" and ""&#nn;"". (nn is number, xnn is also supported. When the member function template find the charactor '&' it starts parsing. And if it couldn't find the correct match, escape string is ignore and just copy '&' verbatim. But in the case of ""&#nn"", the error below would occur. And this error throw the parse_error exception.
{{{
BOOST_PROPERTY_TREE_RAPIDXML_PARSE_ERROR(""expected ;"", src);
}}}

I expect just ignore instead of the error. This behavior is same as other escape string's manner.

I attached patch. Could you check it?


",kondo@…
6176,rolling_mean not as flexible as mean,accumulator,Boost 1.48.0,To Be Determined,Bugs,Eric Niebler,new,2011-11-27T08:39:44Z,2011-11-27T08:39:44Z,"The mean_impl struct has a SumFeature template parameters that allows it to be used to calculate the mean of weights and the mean of variates in addition to the standard mean.

There is no corresponding template parameter for rolling_mean_impl, so it is less flexible. If this were fixed, it would be possible to add new accumulators such as rolling_mean_of_weights, rolling_mean_of_variates, analogous to mean_of_weights, mean_of_variates.
",s.d.c.west@…
6160,support for (istream >> array < char >),array,Boost 1.44.0,To Be Determined,Feature Requests,Marshall Clow,assigned,2011-11-22T00:38:37Z,2011-11-28T17:17:25Z,"1. `array < T >` is a replacement for `T []`
1. the standard library provides the syntax `(istream >> char [])` and `(ostream << char const [])`
1. Currently, `(istream >> array < char >)` does not mean anything
1. this functionality cannot be simulated even with `std:: copy_n < istreambuf_iterator >` without manual termination and much verbosity

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

#include <boost/array.hpp>	/* for ::boost:: array */
#include <boost/version.hpp>

#if +BOOST_VERSION <= 0313720
#include <iomanip>	/* for ::std:: setw */
namespace boost 
{ 
/* helper classes to prevent ambiguity in matching array < char > */
namespace detail_
{ 
/* normally, other char for every character type is char */
  template < class P_C > class other_char { public: typedef char type; }; 
/* but other_char is undefined for char */
  template <> class other_char < char > {}; 
/* class same_stream fails for istream */
  template 
  < class P_S, 
    class P_C = typename other_char < typename P_S:: char_type >:: type >
class same_stream { public: typedef P_S stream; }; }
/* template input */
  template < class P_C, class P_T, ::std:: size_t P_N > 
  static inline ::std:: basic_istream < P_C, P_T >
&operator >> 
  (::std:: basic_istream < P_C, P_T > &p_s, ::boost:: array < P_C, P_N > &p_a) 
  { return p_s >> ::std:: setw (p_a. static_size) >> p_a. data (); } 
/* character input, disabled for type char to avoid ambiguity */
  template < class P_C, class P_T, ::std:: size_t P_N > 
  static inline typename
  detail_:: same_stream 
< ::std:: basic_istream < P_C, P_T > >:: stream
&operator >> 
  (::std:: basic_istream < P_C, P_T > &p_s, 
   ::boost:: array < char, P_N > &p_a) 
  { return p_s >> ::std:: setw (p_a. static_size) >> p_a. data (); } 
/* template output */
  template < class P_C, class P_T, ::std:: size_t P_N > 
  static inline ::std:: basic_ostream < P_C, P_T > 
  &operator << 
(::std:: basic_ostream < P_C, P_T > &p_s, 
 ::boost:: array < P_C, P_N > const &p_a) { return p_s << p_a. begin (); }
/* character output, disabled for type char */
  template < class P_C, class P_T, ::std:: size_t P_N > 
  static inline 
typename detail_:: same_stream < ::std:: basic_ostream < P_C, P_T > >:: stream
  &operator << 
(::std:: basic_ostream < P_C, P_T > &p_s, 
 ::boost:: array < char, P_N > const &p_a) 
{ return p_s << p_a. begin (); }}
#endif	/* BOOST_VERSION */

#include <cstdlib>	/* for EXIT_SUCCESS */
#include <cstdio>	/* for BUFSIZ */
#include <iostream>	/* for ::std:: cin */

int main () 
{ // char (&x) [+BOOST_VERSION] = 0;
#ifdef ARRAY_IN_NATIVE
/* native code */
char t [+BUFSIZ]; 
 return 
   ::std:: cin >> ::std:: setw (+BUFSIZ) >> t && ::std:: cout << t << '\n'? 
+EXIT_SUCCESS: +EXIT_FAILURE; 
#else /* ARRAY_IN_NATIVE */
/* equivalent Boost code */
 ::boost:: array < char, +BUFSIZ > t; 
/* check that character input compiles for wchar_t */
 (void) sizeof (std:: wcin >> t);
 return 
::std:: cin >> t && ::std:: cout << t << '\n'? +EXIT_SUCCESS: +EXIT_FAILURE;
#endif /* ARRAY_IN_NATIVE */
}

}}}

",giecrilj@…
6155,"VS2010 compile error in lambda, if posix_time.hpp is included.",date_time,Boost 1.48.0,To Be Determined,Bugs,az_sw_dude,new,2011-11-20T13:13:21Z,2011-11-20T13:35:39Z,"boost 1.46.1 compiles ok.[[BR]]
boost 1.48 gives:[[BR]]
""error C2663: 'std::vector<_Ty>::at' : 2 overloads have no legal conversion for 'this' pointer""

See annotations in attached testcase.

Compiler error?",fzuuzf@…
6150,[units] The Euro sign is not correctly encoded (in UTF8 or ISO-8859-1) in a source file,units,Boost 1.48.0,Boost 1.49.0,Bugs,Matthias Schabel,new,2011-11-19T19:35:54Z,2018-07-06T09:37:00Z,"An [http://svn.boost.org/svn/boost/trunk/libs/units/example/autoprefixes.cpp example source file]  contains the Euro currency symbol, but is encoded neither in UTF-8 nor in ISO-8859-x.
Could you replace that wrongly encoded symbol with a standard one, e.g., UTF8 (i.e., €)?

Among other things, that issue:
 * wrongly displays in Web browser (as seen [http://svn.boost.org/svn/boost/trunk/libs/units/example/autoprefixes.cpp here])
 * triggers errors when performing RPM packaging
",denis.arnaud_boost@…
6145,MinGW / GCC 4.6.1 warns about conflicts between Boost.Thread and Boost.InterProcess (Win32 C API),interprocess,Boost 1.48.0,To Be Determined,Bugs,Ion Gaztañaga,new,2011-11-18T18:28:21Z,2014-11-06T04:14:10Z,"I compile boost-1.48 with GCC 4.6.1 using MinGW-32 3.10 on Windows XP.

My compiling options are :
{{{
g++ -std=c++0x
}}}

I encounter the following conflicts :

{{{
~/boost-1.48/interprocess/detail/win32_api.hpp:808:116: warning: declaration of 'void* boost::interprocess::winapi::CreateMutexA(boost::interprocess::winapi::interprocess_security_attributes*, int, const char*)' with C language linkage [enabled by default]
~/boost-1.48/thread/win32/thread_primitives.hpp:119:55: warning: conflicts with previous declaration 'void* boost::detail::win32::CreateMutexA(boost::detail::win32::_SECURITY_ATTRIBUTES*, int, const char*)' [enabled by default]
}}}
{{{
~/boost-1.48/interprocess/detail/win32_api.hpp:813:127: warning: declaration of 'void* boost::interprocess::winapi::CreateSemaphoreA(boost::interprocess::winapi::interprocess_security_attributes*, long int, long int, const char*)' with C language linkage [enabled by default]
~/boost-1.48/thread/win32/thread_primitives.hpp:120:55: warning: conflicts with previous declaration 'void* boost::detail::win32::CreateSemaphoreA(boost::detail::win32::_SECURITY_ATTRIBUTES*, long int, long int, const char*)' [enabled by default]
}}}

The problem looks like closed tickets #4217 and #5030.

It looks like ""extern C"" modifier make the compiler to ignore namespace declarations, hence the conflicts.

For example, discarding namespaces, '''Boost.Thread''' declares CreateMutexA() like this :
{{{
extern ""C""
{
    struct _SECURITY_ATTRIBUTES;
    __declspec(dllimport) void* __stdcall CreateMutexA('''boost::detail::win32::_SECURITY_ATTRIBUTES'''*,int,char const*);
}
}}}
whereas '''Boost.Interprocess''' declares it like this :
{{{
struct interprocess_security_attributes
{
   unsigned long nLength;
   void *lpSecurityDescriptor;
   int bInheritHandle;
};
extern ""C"" __declspec(dllimport) void * __stdcall CreateMutexA('''boost::interprocess::winapi::interprocess_security_attributes'''*, int, const char *);
}}}

To avoid the compiler warnings, the same type should be used for the first parameter of CreateMutexA().",Cyril Othenin-Girard <cog@…>
6144,Boost::Pool doc needs a FAQ Q/A about thread-safety,pool,Boost 1.48.0,To Be Determined,Feature Requests,John Maddock,new,2011-11-18T14:00:06Z,2012-07-16T20:05:01Z,"See http://stackoverflow.com/questions/1663284/is-boostobject-pool-synchronized

Thread-safety is only mentioned in the singleton pool doc, not saying that all the remaining is not thread-safe. Thread-safety could be something wanted for memory alloc/dealloc, on boost::pool too (even if performance is one of its goals).",moala@…
6142,boost::mpl/has_xxx.hpp gives several errors,mpl,Boost 1.47.0,Boost 1.49.0,Bugs,Aleksey Gurtovoy,new,2011-11-18T13:04:39Z,2015-02-17T21:09:23Z,"when using boost 1.47.0 with gcc 4.1.2 and -Wundef -Werror,
it gives the following errors

{{{
boost/mpl/has_xxx.hpp:344:9: error: ""BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION"" is not defined
boost/mpl/has_xxx.hpp:357:9: error: ""BOOST_MPL_HAS_XXX_NO_WRAPPED_TYPES"" is not defined
mpl/has_xxx.hpp:386:9: error: ""BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION"" is not defined
boost/mpl/has_xxx.hpp:459:8: error: ""BOOST_MPL_HAS_XXX_NEEDS_TEMPLATE_SFINAE"" is not defined
}}}

This problem has been already addressed by bug report 4666, but apparently its part for MPL has been forgotten. Therefore I would like to resurrect this problem again.

Either the logic of defining these four #define's needs to be revisited in the header file, or their usage must be rewritten to check whether the #define is defined at all. For the latter case, I'm attaching a patch.

Should you need more information, just ping me.
Ivo Raisr",Ivo Raisr <ivosh@…>
6140,"error: ""MSVC_WORKAROUND_GUARD"" is not defined",parameter,Boost 1.47.0,Boost 1.49.0,Bugs,Daniel Wallin,new,2011-11-18T11:27:37Z,2012-02-05T04:33:03Z,"{{{
boost/parameter/aux_/unwrap_cv_reference.hpp:47:1: error: ""MSVC_WORKAROUND_GUARD"" is not defined
boost/parameter/aux_/unwrap_cv_reference.hpp:47:1: error: ""MSVC"" is not defined
}}}

There is a problem in boost/parameter/aux_/unwrap_cv_reference.hpp at line 47. It contains the following code:
{{{
#if BOOST_WORKAROUND(MSVC, == 1200)
}}}

but preprocessing fails with the errors above.
I checked all boost header files and even documentation for boost/detail/workaround.hpp says, that correct form must be:
{{{
#if BOOST_WORKAROUND(BOOST_MSVC, == 1200)
}}}

After this change, preprocessing is ok.
There are no other occurrences of this bug in boost 1.47.0.
This bug is present also in boost 1.48.0.

Should you need more information, just ping me.

Ivo Raisr

",Ivo Raisr <ivosh@…>
6135,Significant speed-up in gamma rng by switching from Knuth method to Marsaglia and Tsang (2000),random,Boost Development Trunk,To Be Determined,Patches,No-Maintainer,new,2011-11-17T18:59:40Z,2011-11-17T18:59:40Z,"When compared to the GNU Scientific Library (GSL), the generation of Gamma-distributed random numbers is very slow in Boost. A simple test, generating 100000000 random numbers, reveals

GSL   : 22.3233 MSamples/s[[BR]]
Boost : 5.41275 MSamples/s

where MSamples/s is million samples per second. The difference is due to Boost using the Knuth method, whereas the GSL implements a newer method by Marsaglia and Tsang (2000).

With the attached patch, which implements the newer method, the performance improves to

GSL   : 22.7472 MSamples/s[[BR]]
Boost : 14.5018 MSamples/s

The remaining difference between Boost and GSL can be traced back to GSL using Zigguraut rather than Box-Muller to generate Normal random numbers. At some point I might submit a patch for normal_distribution.hpp that implements the Zigguraut algorithm.

The attached patch exactly follows gsl_ran_gamma of GSL v1.15 (gsl-1.15/randdist/gamma.c)",Jan Drugowitsch <jdrugo@…>
6128,rolling_variance addition,accumulator,Boost 1.47.0,To Be Determined,Bugs,Eric Niebler,new,2011-11-16T16:50:52Z,2014-06-26T19:19:44Z,"LS,

I have just finished writing an implementation and test of a 
rolling_variance which I would be happy to contribute to the framework.

It includes a redone version of rolling_mean which avoids potential overflow and accuracy issues. The rolling_variance currently returns zero when there are less than 2 samples available.

I'd be happy to do assist to make this fit the accumulator framework better and I include a first draft of the code. Nothing spectacular, but I have not seen the 'rolling' version being published anywhere in the exact form needed, making this non-trivial to implement anyway.

- Pieter",Pieter Ober <jaapaap@…>
6122,split_unix() strips an empty quoted string.,program_options,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2011-11-13T15:38:25Z,2011-11-13T15:38:25Z,"the split_unix() strips any empty string from input, e.g.:

{{{
input = ""path_to_exec arg0 \""\"" arg1"";

result vector:
[0] = ""path_to_exec""
[1] = ""arg0""
[2] = ""arg1""
}}}
",pluto@…
6116,"In chain.hpp there is a variable named ""null""",iostreams,Boost 1.46.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-11-11T22:00:57Z,2011-11-11T22:00:57Z,"In boost/iostreams/chain.hpp on line 322 (of version 1.46 and others) there is a variable named ""null"".  While that is legal C++, it is unfortunately all too common for people to place something like ""#define null 0"" somewhere else in their code base.  It would be nice if that variable name could be made something like ""null_device"" which is less likely to cause a problem due to other code.",herod.scott at gmail.com
6109,Enable native typeof for IBMCPP,typeof,Boost 1.47.0,To Be Determined,Patches,Peder Holt,new,2011-11-09T22:31:30Z,2014-07-22T00:02:36Z,IBM XL C/C++ has native typeof support.,hstong@…
6106,New map[] directive to augment qi::symbols when doing binary parsing,spirit,Boost Release Branch,To Be Determined,Patches,Joel de Guzman,new,2011-11-08T19:16:22Z,2011-11-09T06:51:45Z,"qi::symbols is an exceptionally useful parser, but it is strongly tied to character strings as its input type. When doing binary parsing, one of the common tasks is de-serializing objects from the binary stream, an activity which can strongly benefit from Nabialek trick (http://boost-spirit.com/home/articles/qi-example/nabialek-trick/). Another common use case are extensible enum types, a feat which is somewhat cumbersome to handle with attribute transformations.

This is my first attempt at implementing a qi directive, so it's probably far from perfect. One of the immediate shortcomings I want to resolve is direct dependency on std::map which is also passed by value between instances.

The implementation and a short example demonstrating Nabialek trick is attached.",oakad@…
6101,overhead with creating multi_array_ref with GCC 3.4.6,multi_array,Boost 1.47.0,To Be Determined,Bugs,Ronald Garcia,new,2011-11-07T08:53:09Z,2011-11-07T08:53:09Z,"We spotted this with profiler and had to switch from boost::const_multi_array_ref to just std:pair of pointers.

GCC 3.4.6 generates huge code for this primitive function (to represent a raw pointer as a 1D-array), comparing to GCC 4.4.4:
{{{
boost::const_multi_array_ref<int,1>
make(const int* begin, const boost::array<int,1>& size)
{
  return boost::const_multi_array_ref<int,1>(begin, size);
}
}}}

The generated code and compilation options are attached.",Maxim Yanchenko <Maxim.Yanchenko@…>
6097,wrong filesystem::path::stem() and ..::extension() documentation,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-11-06T09:07:01Z,2012-08-15T20:13:21Z,"At [http://www.boost.org/doc/libs/1_47_0/libs/filesystem/v3/doc/reference.html] we can see that path::stem is declared as

{{{
path stem(const path& p) const;
}}}

while in reality it does not take any arguments. 

Same problem with extension().
",anonymous
6096,Consider __GNUC__ in and.hpp / or.hpp,mpl,Boost 1.37.0,To Be Determined,Feature Requests,Aleksey Gurtovoy,new,2011-11-04T22:36:59Z,2011-11-04T22:36:59Z,"In boost mpl header files - ""and.hpp"" and ""or.hpp"", we try to undef macros from is0646.h under Windows for processing boost headers. I see that we excluse GCCXML tool under this condition. Since we widely use mingw's 'cpp' to generate dependency files, can we also include __GNUC__ macro as part of this condition?

I am attaching the patch for this case.",Karthik Rajagopalan <karthik.rajagopalan@…>
6089,Non const & used in ptr_map::insert,ptr_container,Boost 1.48.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-11-03T18:24:57Z,2017-01-17T22:15:34Z,"The boost::ptr_map inserter takes a ""key_type &"" rather than a ""const key_type &."" This is annoying if you have a function that takes a const &. I've attached a patch which should fix the problem.",jdoliner@…
6088,Function boost::asio::buffer() doesn't support boost::container::vector.,asio,Boost 1.48.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2011-11-03T16:36:17Z,2011-11-03T16:36:17Z,Function boost::asio::buffer() isn't overloaded for containers from library Boost.container.,Vladislav <phprus@…>
6085,Make use of statvfs() for OpenBSD with Boost.Filesystem,filesystem,Boost Development Trunk,Boost 1.48.0,Patches,Beman Dawes,new,2011-11-03T11:27:58Z,2013-03-30T00:20:28Z,The attached patch makes use of statvfs() for OpenBSD with Boost.Filesystem which OpenBSD has had for many releases now.,brad@…
6075,Can we add policy based disabling of error checking inside math distributions?,math,Boost 1.47.0,To Be Determined,Feature Requests,John Maddock,new,2011-10-31T13:41:37Z,2011-10-31T13:41:37Z,"..from the boost dev  mailing list..

I wrote:
Would it be possible to move the detail::check_scale(d) etc into the Policy class? That way I could provide a different policy that get's eliminated compile time via an implementation like
""inline policy::check_scale(d){return;}""

John wrote:
I don't think we could move all the checks inside the policy class as each distribution is more or less different, but we could pass a compile time param to the checking functions to have the same effect.  In fact can you file a bug report so I don't forget?",thijs@…
6073,typed subarray from incompatible/raw memory,multi_array,Boost 1.47.0,To Be Determined,Feature Requests,Ronald Garcia,new,2011-10-31T09:28:39Z,2011-10-31T09:28:39Z,"Consider this example:
{{{
struct A { double x, y; };

struct B : A { double z; };
struct C { A a; double z; };
struct D { double z; A a; };
struct unknown { ...; A a; ....; };
}}}
Let's say I have in memory an n-dimensional array of B, or C, or D, or even unknown structure where I know only total size of the element and offset of A inside it, both in run-time (e.g. a binary file produced by NumPy.mmap).

What I need is a multi_array_view that could behave as an multi_array of A, given the sizeof of ""real"" element containing A, and offset of A inside it, like this:
{{{
void* p = mmap(...);
size_t el_size = size_of_element_in_p;
size_t offset  = offset_of_A_inside_element;

boost::multi_array::multi_array_typed_view<A, NumDims>
  my_view(p, extents, el_size, offset );
}}}

Strided view (boost::detail::multi_array::multi_array_view) could do the job in simple cases when size of ""real"" element is a multiple of sizeof(A), but not in the above case.",Maxim Yanchenko <Maxim.Yanchenko@…>
6072,Bad iterator difference for m.begin1() - m.end1() in ublas,uBLAS,Boost 1.47.0,To Be Determined,Bugs,Gunter,new,2011-10-30T12:20:23Z,2011-10-30T12:20:23Z,"In functional.hpp at a couple of places, for example:

         static
         BOOST_UBLAS_INLINE
         difference_type distance_i (difference_type k, size_type /* size_i */, size_type size_j) {
             return size_j != 0 ? k / size_j : 0;
         }

k [ / | % ] size_[ i | j ] is used, where k is difference_type (signed), size_i|j is size_type (unsigned). This results in promoting k to unsigned, and can yield very strange results when k is negative.

For example, m being a size 2x2 ublas::matrix, 
m.begin1() - m.end1() 
yields 2147483646 instead of -2. 

Putting a static_cast<difference_type>(size_i|j) in functional.hpp
seems to solve the problem.",Robin Palotai <palotai.robin@…>
6070,extends::operator() and operator= eagerly compute return type can result in hard error,proto,Boost 1.47.0,Boost 1.48.0,Bugs,Eric Niebler,new,2011-10-29T04:21:54Z,2011-10-29T04:21:54Z,"In the cases when unary operator() and operator= are invalid in a particular domain, the return types of extends::operator() and operator= should not be computed. (Well, ideally, those functions shouldn't exist at all, but we live in an imperfect world.) Trouble is, as soon as the extends template is instantiated, the return types for those functions are eagerly computed, causing the generator to operate on a type that it may not be able to handle. This can cause a hard error.

See http://lists.boost.org/proto/2011/10/0595.php for a full description of this issue.

The attached patch addresses the issue. It may have compile time implications, though.",Eric Niebler
6066,Getting back std::string from a utree string node throws std::bad_cast,spirit,Boost 1.47.0,To Be Determined,Bugs,Joel de Guzman,new,2011-10-27T13:50:21Z,2011-10-27T13:50:21Z,"When using:

std::string s1(""test"");
boost::spirit::utree u = s1;

Either of:
   std::string s2 = u.get<std::string>();
or
   std::string s2 = u.get<boost::spirit::utf8_string_type>();

fail with a ""std::bad_cast"" thrown.

Proceeding with:
    boost::spirit::utf8_string_range_type rt = u.get<spirit::utf8_string_range_type>();
    std::string s2(rt.begin(), rt.end());

works fine...

Please see attached file for a complete example.",Rémy Chibois <rchibois@…>
6065,Accessing Windows paths with non-ANSI characters fails with g++,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-10-27T13:20:17Z,2011-10-27T13:20:17Z,"For example, the tut5 example in Boost.Filesystem's tutorial does not work with g++ 4.4.1 (it fails to create the filenames with smileys), but that example does work with Visual C++ 10.0.

""ANSI"" here refers to the process' ""ANSI codepage"".

By default in a US or Western European Windows installation that's codepage 1252, Windows ANSI Western.

Cause: Boost.Filesystem uses extensions in the Dinkumware standard library implementation to provide general Unicode access to paths in Windows.  g++'s standard library lacks those extension as of version 4.4.1 (and probably up to and including the latest version). Extending the g++ standard library in a similar way as Dinkumware was discussed in June 2011, <url: http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html>, but as far as I know nothing more came of that.

Boost.Filesystem v2 worked around the g++ implementation by using Windows short filenames and the Windows API-funcion CreateFile for creation of files. One problem is that the user IN PRINCIPLE can turn off generation of short filenames as a marginal optimization. However, Windows uses short filenames in the registry, reportedly MSI (the Microsoft Installer) uses short filenames, etc., so it's a very unlikely scenario. In the unlikely event that a user does turn off short names, then programs using the v2 workaround will fail in the same way as if they didn't have the workaround, i.e. as currently.
",alf.p.steinbach@…
6063,resize does not offset rectangles (etc.) correctly or crashes,polygon,Boost 1.47.0,To Be Determined,Bugs,Andrii Sydorchuk,assigned,2011-10-26T21:18:46Z,2014-02-10T22:06:28Z,"When using the 'corner_fill_arc' parameter to polygon_set_concept<T>::resize(), a minkowski sum using a polygonalized circle is used to get the offset shape.

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

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

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

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


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

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

----

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

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


----

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

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

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

This would only affect corners, instead of the whole shape.
",dbfaken@…
6056,units/test_output: unqualified sqrt() fails to compile on SunCC/SunOS,units,Boost 1.47.0,To Be Determined,Bugs,Matthias Schabel,new,2011-10-25T10:59:36Z,2011-10-25T11:02:26Z,"Compiling Boost/units test_output on SunOS with SunCC:

{{{
] sunCC  -library=stlport4 -I../ ../libs/units/test/test_output.cpp
""../libs/units/test/test_output.cpp"", line 242: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 242: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 336: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 336: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 384: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 384: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 393: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 393: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 394: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 394: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 395: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 395: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 396: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 396: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 397: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 397: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 413: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 413: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 414: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 414: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 415: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 415: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 416: Error: The function ""pow"" must have a prototype.
""../libs/units/test/test_output.cpp"", line 416: Error: The function ""pow"" must have a prototype.
24 Error(s) detected.
}}}

The standard math header included here - '''<cmath>''' - does not inject math functions into the global namespace. The only standard way to use these functions (pow included) is via std:: namespace. 

All the uses of pow should be converted to std::pow, otherwise compilers with strictly conforming standard headers (like SunCC) will not be able to compile.

std::pow works fine with all the compilers I tried (SunCC, g++).

(suggested patch attached)
",Fedor Sergeev <Fedor.Sergeev@…>
6055,unqualified sqrt() fails to compile on SunCC/SunOS,uBLAS,Boost 1.47.0,To Be Determined,Bugs,Gunter,new,2011-10-25T10:34:51Z,2011-10-25T10:38:54Z,"Compiling uBlas' test_complex_norms on SunOS with SunCC:
{{{
]  sunCC -library=stlport4 -I../ ../libs/numeric/ublas/test/test_complex_norms.cpp
""../libs/numeric/ublas/test/test_complex_norms.cpp"", line 37: Error: The function ""sqrt"" must have a prototype.
""../libs/numeric/ublas/test/test_complex_norms.cpp"", line 37: Error: The function ""sqrt"" must have a prototype.
""../libs/numeric/ublas/test/test_complex_norms.cpp"", line 65: Error: The function ""sqrt"" must have a prototype.
""../libs/numeric/ublas/test/test_complex_norms.cpp"", line 65: Error: The function ""sqrt"" must have a prototype.
4 Error(s) detected.
}}}

The standard math header included here - <cmath> - does not inject math functions into the global namespace. The only standard way to use these functions (sqrt included) is via std:: namespace. 

All the uses of sqrt should be converted to std::sqrt, otherwise compilers with strictly conforming STLs (like SunCC -stlport4) will not be able to compile.

std::sqrt works fine with all the compilers I tried (SunCC, g++).

(suggested patch attached)",Fedor Sergeev <Fedor.Sergeev@…>
6047,functions round_cast and trunc_cast,math,Boost Development Trunk,To Be Determined,Feature Requests,John Maddock,new,2011-10-22T11:48:56Z,2011-10-22T11:48:56Z,"The functions are general versions of iround, and alike functions.
{{{
template < class R, class T, class Policy >
inline R round_cast( T const& x, Policy const& pol )
{
    BOOST_MATH_STD_USING
    T r = boost::math::round(x,pol);
    if( r > boost::integer_traits<R>::const_max || r < boost::integer_traits<R>::const_min )
       return static_cast<R>( boost::math::policies::raise_rounding_error(
               ""cz::ar::round_cast<target_type,%1%>(%1%)"", 0, x, pol ) );
    return static_cast<R>(r);
}

template < class R, class T >
inline R round_cast( T const& x )
{
    return round_cast<R>( x, boost::math::policies::policy<>() );
}
}}}

Analogically for trunc()...",1czajnik@…
6045,Date/Time: dst_calculator::local_is_dst doesn't deal with DST changeover at end of day,date_time,Boost 1.47.0,To Be Determined,Bugs,az_sw_dude,new,2011-10-20T23:26:32Z,2015-03-03T15:07:36Z,"Hello boosters,

dst_calculator::local_is_dst assumes that the hour lost in the ""forward"" DST changeover (in Spring, when DST begins) fully occurs within a single day.  If your time zone rule specifies that DST begins at 23:59:99.999 on October 15th, with a duration of an hour, and you attempt to create a ptime for 00:00:00.000 on October 16th, it will succeed even though it ought to return invalid_time_label.

I admit that this seems like an odd case, and personally I would expect all DST offsets to be in the 0h-3h range.  However if you are creating custom time zones based on the win32 time zone information, the GetTimeZoneInformation API returns a TIME_ZONE_INFORMATION struct with values returned a millisecond before midnight.  Specifically this happens with Brasilian standard/daylight time.

For now I am ""cleaning up"" these odd values returned from windows, but boost probably should do this calculation correctly to begin with.

I can provide a repro case if need be, although I think the behaviour of the code in question is pretty clear.

Thanks,

Matt Adam",Matt Adam <matt.adam@…>
6037,Errors at https://svn.boost.org/trac/,trac / subversion,Boost 1.47.0,To Be Determined,Bugs,Douglas Gregor,new,2011-10-19T22:51:12Z,2014-01-26T21:49:55Z,"bin: Error 
([Errno 2] No such file or directory: '/opt/trac/bin/VERSION')
Boost C++ Libraries
cache: Error 
([Errno 2] No such file or directory: '/opt/trac/cache/VERSION')
include: Error 
([Errno 2] No such file or directory: '/opt/trac/include/VERSION')
lib: Error 
([Errno 2] No such file or directory: '/opt/trac/lib/VERSION')
OSL Test trac
share: Error 
([Errno 2] No such file or directory: '/opt/trac/share/VERSION')
",Olaf van der Spek <olafvdspek@…>
6034,Problem of the split function in boost/date_time/time_parsing.hpp,date_time,Boost 1.47.0,To Be Determined,Bugs,az_sw_dude,new,2011-10-19T12:13:46Z,2011-10-19T12:21:07Z,"If we call the function '''split''' with the string ""2010-01-01"" and "" "" as delimiter then the function sets the variables '''first''' and '''second''' with ""2010-01-01""
Maybe we should write this piece of code to initialize the parameter '''second''' with the correct value.


{{{
bool 
  split(const std::string& s,
        char sep,
        std::string& first,
        std::string& second)
  {
    int sep_pos = static_cast<int>(s.find(sep));
    first = s.substr(0,sep_pos);
    second = sep_pos == -1 ? """" : s.substr(sep_pos+1);
    return true;
  }
}}}
",fbriol@…
6026,phoenix block statement tries to copy objects instead of references,phoenix,Boost 1.47.0,To Be Determined,Bugs,Kohei Takahashi,assigned,2011-10-14T16:17:15Z,2016-05-09T15:02:25Z,"Let's use a simplest class, that can't be copied:

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

A *pa = A::construct();
A &a = *pa;

}}}

The code which use this object one time normally works:
{{{ 
(boost::phoenix::ref(a) << boost::phoenix::placeholders::_1)(""aaa"");
}}}

But when I try to use this object two times, I get an error:
{{{
(
   boost::phoenix::ref(a) << boost::phoenix::placeholders::_1
   ,boost::phoenix::ref(a) << boost::phoenix::placeholders::_1
)(""aaa"");
}}}

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

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

Note: preprocessing directive ""BOOST_SPIRIT_USE_PHOENIX_V3"" was defined.",armagvvg@…
6024,Behaviour and documentation don't match,tokenizer,Boost 1.47.0,To Be Determined,Bugs,jsiek,new,2011-10-14T07:33:14Z,2011-10-14T07:33:14Z,"Hi,

> explicit char_separator()

Explicit? Doesn't explicit only apply to one argument constructors?

> The function std::isspace() is used to identify dropped delimiters and std::ispunct() is used to identify kept delimiters. In addition, empty tokens are dropped.

 std::string s(""[1][3][5][]9"");
 BOOST_FOREACH(auto i, boost::tokenizer<>(s))
   std::cout << i << std::endl;

This outputs only numbers. Shouldn't the brackets be included too?",Olaf van der Spek <olafvdspek@…>
6018,Add touch() and create_file() functions,filesystem,Boost 1.47.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2011-10-13T12:38:26Z,2011-10-13T12:38:51Z,"A function with the functionality of the POSIX touch utility would be a great convenience. It meets both the need to update times and the need to create a file.

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

Alternatively, both could return a bool, true if successful, and not consider it an error if the file, respectfully, already/doesn't exist.   ",Beman Dawes
6010,Linkage problems in assignment.hpp,uBLAS,Boost 1.47.0,Boost 1.48.0,Bugs,David Bellot,reopened,2011-10-11T18:03:01Z,2013-01-24T19:45:32Z,"Original report in uBlas mailing list:

{{{
Hi,

I started using ublas's ""<<="" assignment, and I'm starting to regret it.
First symptom: if I compile with the gcc flag -Wmissing-prototypes I get the following warnings:

In file included from /Users/devernay/Development/stereocam/surf/CameraMatrixP.hpp:16,
                 from /Users/devernay/Development/stereocam/surf/TriFocalTensor/Trifocaltensor.hpp:18,
                 from /Users/devernay/Development/stereocam/surf/TriFocalTensor/TrifocaltensorBundleAdjustement.cpp:20:
/opt/local/include/boost/numeric/ublas/assignment.hpp:454: warning: no previous prototype for 'boost::numeric::ublas::begin1_manip boost::numeric::ublas::begin1()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:498: warning: no previous prototype for 'boost::numeric::ublas::begin2_manip boost::numeric::ublas::begin2()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:543: warning: no previous prototype for 'boost::numeric::ublas::next_row_manip boost::numeric::ublas::next_row()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:587: warning: no previous prototype for 'boost::numeric::ublas::next_column_manip boost::numeric::ublas::next_column()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:888: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_row_policy<boost::numeric::ublas::traverse_policy::wrap> boost::numeric::ublas::traverse_policy::by_row()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:892: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_row_policy<boost::numeric::ublas::traverse_policy::wrap> boost::numeric::ublas::traverse_policy::by_row_wrap()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:896: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_row_policy<boost::numeric::ublas::traverse_policy::no_wrap> boost::numeric::ublas::traverse_policy::by_row_no_wrap()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:900: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_column_policy<boost::numeric::ublas::traverse_policy::wrap> boost::numeric::ublas::traverse_policy::by_column()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:904: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_column_policy<boost::numeric::ublas::traverse_policy::wrap> boost::numeric::ublas::traverse_policy::by_column_wrap()'
/opt/local/include/boost/numeric/ublas/assignment.hpp:908: warning: no previous prototype for 'boost::numeric::ublas::traverse_policy::by_column_policy<boost::numeric::ublas::traverse_policy::no_wrap> boost::numeric::ublas::traverse_policy::by_column_no_wrap()'

But the second symptom is more critical: Since these symbols are defined in EVERY file that includes them, I cannot link anything and I get tons of ""multiply defined symbols"".

Looking at the file, I found out that:
- begin1(), begin2(), and a few others are not inlined, but conditionally inlined, using BOOST_UBLAS_INLINE (which inlines only if NDEBUG is defined), and are NOT members of classes, thus the multiply defined symbols...
- boost::numeric::ublas::traverse_policy::by_row() and other are just defined, and not inlined.

So, really, what's the solution?
Here's what I think:

BOOST_UBLAS_INLINE should ONY be used for class members, NOT for functions, which should be simply declared ""inline"".

by_row() and friends should either be inlined or declared as static members of an empty class.

I tried putting the magic word ""inline"" in front of each of these, and it works.

fred
}}}",nasos_i@…
5997,Listening on multiple endpoints (doc / acceptor group),asio,Boost 1.47.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2011-10-08T11:11:44Z,2011-10-08T11:11:44Z,"Could you add an example of listening on multiple endpoints?
I assume this requires multiple acceptors. Those could be stored in a ptr container. Maybe an acceptor group (like thread group) might be useful?",Olaf van der Spek <olafvdspek@…>
5996,"Warnings when compiled with ""-Wshadow""",ptr_container,Boost 1.47.0,To Be Determined,Patches,Thorsten Ottosen,new,2011-10-08T10:30:46Z,2012-04-27T07:37:28Z,"g++ 4.4.5 reports warnings when compiles various components with ""-Wshadow"", files:

{{{
boost/ptr_container/exception.hpp
boost/ptr_container/detail/move.hpp
boost/ptr_container/detail/static_move_ptr.hpp
boost/ptr_container/detail/reversible_ptr_container.hpp
boost/unordered/detail/equivalent.hpp
boost/unordered/detail/buckets.hpp
boost/unordered/detail/emplace_args.hpp
boost/unordered/detail/unique.hpp
boost/concept_check.hpp
}}}

Similar tickets: #5439, #4362, #4365 .

Those warnings exists in both Boost 1.47.0 and svn trunk 74788, I attached a patch file against svn trunk 74788.",Shuo Chen <giantchen@…>
5992,opening wide character string paths in memory-mapped file,interprocess,Boost 1.47.0,To Be Determined,Feature Requests,Ion Gaztañaga,new,2011-10-07T15:08:11Z,2016-02-13T19:10:22Z,"Without support for wide character string paths, we cannot easily open files with Unicode paths in Windows. This makes interprocess/file_mapping practically unusable for Windows programming. A suggestion might be to abstract out the use of raw strings for paths by using filesystem.

Without the fix, we are using Win32 API to open memory-mapped files and forking the code for other platforms.",Jim Park <jim@…>
5988,boost::filesystem::absolute doesn't work with ../relative_path or ./relative_path,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-10-07T04:21:02Z,2011-10-07T07:09:20Z,"In boost filesystem v3, boost::filesystem::absolute only appends the relative path to base path. It should also remove ""./"" from relative paths and ""backtrack"" on base path if relative path contains ""../../"" etc.

For example, 
Input:
  ""d:\current\path""
  "".\..\relative\path""

Result obtained:
  ""d:\current\path\.\..\relative\path""

Desired result:
  ""d:\current\relative\path""
",Sachin Garg <schngrg@…>
5987,Error in boost-build/jam_src/build.bat,build,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2011-10-07T03:26:13Z,2011-10-07T03:26:13Z,"in :Start
if ""_%1_"" == ""__"" (
    call :Guess_Toolset
    if not errorlevel 1 goto Setup_Toolset
) else (
    call :Test_Option ""%1""
    if not errorlevel 1 ( <-- error here
        call :Guess_Toolset
        if not errorlevel 1 goto Setup_Toolset
    ) else (
        setlocal & endlocal
        set ""BOOST_JAM_TOOLSET=%1""
        shift
        goto Setup_Toolset
    )
)

is incorrect, will always ignore specified toolset, should be

if ""_%1_"" == ""__"" (
    call :Guess_Toolset
    if not errorlevel 1 goto Setup_Toolset
) else (
    call :Test_Option ""%1""
    if errorlevel 1 (
        call :Guess_Toolset
        if not errorlevel 1 goto Setup_Toolset
    ) else (
        setlocal & endlocal
        set ""BOOST_JAM_TOOLSET=%1""
        shift
        goto Setup_Toolset
    )
)
which then allows 
>build mingw 
to work correctly",multisitetracker@…
5985,Quickbook needs Users Guide documentation,quickbook,Boost 1.47.0,To Be Determined,Tasks,Daniel James,new,2011-10-06T11:24:47Z,2014-04-09T02:26:31Z,"Quickbook is currently a disaster to learn to use. The markup itself seems easy, and the ""Chapter 33. Quickbook 1.5"" docs are fine as far as they go. But without a Users Guide, a new user is left groping in the dark.

A Users Guide should answer the question ""How do I build my docs?"". It should begin with the simplest possible example .qbk and Jamfile, and then progress from there. It should include a description and examples of how to invoke bjam to build QB docs.

This ticket is a superset of #1205",Beman Dawes
5970,Support chaining,crc,Boost 1.47.0,To Be Determined,Feature Requests,Daryle Walker,new,2011-10-03T13:10:47Z,2011-10-03T13:10:47Z,"Could the process functions return *this such that chaining is possible?

For example: boost::crc_32_type().process_bytes(d, cb_d).get_checksum().
",Olaf van der Spek <olafvdspek@…>
5966,Cannot send std::map with more than 1 key/value pair,mpi,Boost 1.47.0,To Be Determined,Bugs,Matthias Troyer,new,2011-09-30T19:19:05Z,2013-01-01T11:33:11Z,"Sending a std::map (or std::set) of size greater than 1 causes an MPI_ERR_TRUNCATE error. The following code reproduces this error:


{{{
#include <boost/mpi.hpp>
#include <boost/serialization/map.hpp>

int
main( int argc, char * argv [] )
{
  boost::mpi::environment env(argc, argv);
  boost::mpi::communicator world;

  if(world.rank()==0){
      std::map<int,int> test;
      test[1]=50;
      test[2]=100;
      world.send(1, 1, boost::mpi::skeleton(test));
      world.send(1, 1, boost::mpi::get_content(test));
      std::cout << ""sent"" << std::endl;
  }
  else{
      std::map<int,int> test;
      world.recv(0,1,boost::mpi::skeleton(test));
      world.recv(0,1,boost::mpi::get_content(test));
      std::cout << test.size() << std::endl;
  }
}
}}}",Tim Jacobs <TimJacobs2@…>
5965,indirect_iterator conflicts with forward declaration,iterator,Boost 1.46.1,To Be Determined,Bugs,jeffrey.hellrung,new,2011-09-30T10:12:33Z,2012-11-21T20:30:44Z,"indirect_iterator, or more precisely its base class indirect_base, checks whether it can dereference its argument twice.  This ends in an error, if the target type is incomplete (from a forward declaration). The error occurs even if the dereferencing is not used in the affected code unit. (It is concept checking.)

/usr/include/boost/detail/is_incrementable.hpp:84: error: cannot increment a pointer to incomplete type ‘Derived’

indirect_iterator handles pointers. Pointers and forward declaration should complete each other well. So indirect_iterator should never try to dereference if it is not forced by using code. Concept checking does not work here satisfactorily.

I appended exemplary code which I compiled with GCC 4.4.3.

Best regards,

Simon",Simon <simon.siemens@…>
5963,Patch [Fixes #5961]: Disallow comparisons of differing iterator types in ptr_container,ptr_container,Boost 1.47.0,To Be Determined,Patches,Thorsten Ottosen,new,2011-09-29T14:10:28Z,2011-09-30T11:01:42Z,"Patch removes support for comparing differing iterator types from ptr_container's void_ptr_iterator. The comparators in question are == != < <= > >=.

Changes are:
- Add container type template parameter to void_ptr_iterator. This is what ensures compared iterators of differing types are still for the same referenced container type.

- Add self type as template argument to base class for containers ptr_array, ptr_circular_buffer, ptr_deque, ptr_list, ptr_set, ptr_multiset, ptr_unordered_set, ptr_unordered_multiset, and ptr_vector

- Pass container type template parameter from sequence_config and set_config to iterator typedefs, from ptr_sequence_adapter to reversible_ptr_container, and from ptr_set_adapter and ptr_multiset_adapter through ptr_set_adapter_base to associative_ptr_container",Rob Desbois <rob.desbois@…>
5961,ptr_container supports comparison of iterators of different types,ptr_container,Boost 1.47.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-09-29T10:11:47Z,2011-09-29T10:11:47Z,"The void_ptr_iterator, which handles much of the ptr_container iterator functionality, oddly supports comparison operations between iterators of differing types.

For example:
{{{
   ptr_vector<int>     vi;
   ptr_vector<string>  vs;
   bool eq = (vi.begin() == vs.begin());
}}}

The affected operators are: == != < <= > >=",Rob Desbois <rob.desbois@…>
5949,bootstrap.sh and -isysroot under MacOSX,Building Boost,Boost 1.47.0,To Be Determined,Feature Requests,,new,2011-09-27T16:05:26Z,2011-09-27T16:05:26Z,"bootstrap.sh (which needs to made executable) eventually calls tools/build/v2/engine/build.sh, which in turn calls 'cc'.  On the Mac to be able to run 'cc' without much fuss you need to pass the -isysroot option with th proper Developer SDK directory.  Alas, build.hs does not foresee the use such option.  I'd make much simpler the life on MacOSX circumventing Xcode.

Marco Antoniotti
",Marco Antoniotti <marco.antoniotti@…>
5948,"ptr_map_adapter::insert( key_type& key, mapped_type x ) should have const kex paramter",ptr_container,Boost 1.47.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-09-27T11:31:22Z,2011-09-27T11:31:22Z,"ptr_map_adapter::insert( key_type& key, mapped_type x )

should be

ptr_map_adapter::insert( '''const''' key_type& key, mapped_type x )

as the other insert methods are.",M.Mayer@…
5947,Use CLOCK_PROCESS_CPUTIME_ID on platform providing them,chrono,Boost 1.47.0,To Be Determined,Feature Requests,viboes,assigned,2011-09-27T11:30:41Z,2012-06-03T14:11:46Z,"The posix implementation of process real cpu clock uses the times() function. The resolution is better if we use 

  ::clock_gettime( CLOCK_PROCESS_CPUTIME_ID, &ts );

on platforms for which the CLOCK_PROCESS_CPUTIME_ID is supported.

",viboes
5945,Error in Connected Components Result,graph,Boost 1.47.0,To Be Determined,Bugs,ngedmond,new,2011-09-27T06:16:08Z,2011-09-27T17:30:41Z,"I've been using the connected components function from the parallel Boost graph library. The function has helped my coding and I'm grateful to the authors. I have tested the function on various graphs and verified its results. However, in one test case, the function leaves a vertex out of its rightful component when running with 16 processes. The problem does not occur when running with fewer processes. As the graph where the problem occurs is complicated, I would be unreasonable to ask for too much help in resolving the problem. However, any pointers would be greatly appreciated.

In the attached code, I build and run the connected components function on a graph. I build the graph from 16 attached files numbered 'a' to 'p'. The i-th file contains the number and owner-local pairs of adjacent vertices of consecutive vertices to be stored on the i-th process. After adding the vertices and edges between them, I first verify there is an edge between the problem vertex (0,20) and another vertex, then run the connected components function. Then printing the parent of problem vertex and its children shows the vertex is in a separate component from its neighbor.

It would be great if you could look over the code and point out any obvious errors. Thank you!",Lau Yang Hao <lauyh@…>
5943,clang++ on windows support (was: clang-linux-3.0 output path for clang++ on Windows),build,Boost Development Trunk,To Be Determined,Feature Requests,Vladimir Prus,new,2011-09-26T16:22:01Z,2014-05-06T08:14:36Z,"I'm doing some test builds on Windows 7 using LLVM and clang from their current SVN trunks.

I define the toolset in my user-config.jam:

{{{
# --------------------
# clang configuration.
# --------------------
using clang
    : # version
    3.0
    : # compiler
    g:/dev/llvm/_svn/build/bin/Release/clang++
    : # options
    <cxxflags>-Wno-mismatched-tags
    <cxxflags>-Wno-unused-variable
    ;
}}}

This is inspired by Jürgen Hunold's post in [http://lists.boost.org/Archives/boost/2011/09/186080.php  configuring the clang toolset].

Then I call bootstrap.bat, works well.

Finally, I try to run Boost.Array test getting this:

{{{
g:\dev\boost\_svn\trunk\libs\array\test>bjam
...patience...
...found 291 targets...
...updating 51 targets...
common.mkdir ..\..\..\bin.v2\libs\array
common.mkdir ..\..\..\bin.v2\libs\array\test
common.mkdir ..\..\..\bin.v2\libs\array\test\array0.test
common.mkdir ..\..\..\bin.v2\libs\array\test\array0.test\clang-linux-3.0
common.mkdir ..\..\..\bin.v2\libs\array\test\array0.test\clang-linux-3.0\debug
compile.c++.without-pth ..\..\..\bin.v2\libs\array\test\array0.test\clang-linux-3.0\debug\array0.obj
...
}}}

The process eventually stops due to compilation errors, but this is not relevant to this particular issue I'm reporting.

Given the system I'm using, the problem is with the output path specified by Boost.Build which is

{{{
...\clang-linux-3.0
}}}

Given that I use Windows, this path does not look right.",Mateusz Loskot
5937,Sun C++ 5.11 Linux compilation errors: operations.cpp,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,assigned,2011-09-24T12:46:46Z,2011-09-27T17:59:30Z,"CC: Sun C++ 5.11 Linux_i386 2010/08/13 usage: CC [ options ] files. Use 'CC -flags' for details 

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

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

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

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

4 Error(s) detected.

    ""CC"" -library=stlport4 -xO4 -mt -erroff=%none -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I""."" -c -o ""/home/pal/work/cpp/tmp/boost/bin.v2/libs/filesystem/build/sun/release/address-model-64/link-static/stdlib-sun-stlport/threading-multi/v3/src/operations.o"" ""libs/filesystem/v3/src/operations.cpp""",Peter Loibl <boost@…>
5925,"shared_array: size, begin, end, data?",smart_ptr,Boost 1.47.0,To Be Determined,Feature Requests,Peter Dimov,new,2011-09-21T21:09:23Z,2011-09-21T21:09:23Z,"Could the size, begin, end and data member functions be added to shared_array?
It'd be quite handy to have size() available.",olafvdspek@…
5918,Py3k MPI build failure,mpi,Boost Development Trunk,To Be Determined,Bugs,Douglas Gregor,new,2011-09-21T14:27:08Z,2011-09-21T19:29:10Z,"MPI building fails on a reference to PyInt_Type that no longer exists in py3k.

Attached patch does a PyInt_Type -> PyLong_Type (which is probably what it should have been in the first place since it uses long(0)).",Dan Eicher <dan@…>
5917,cc toolset broken,build,Boost 1.66.0,To Be Determined,Bugs,Vladimir Prus,new,2011-09-20T11:49:17Z,2018-04-05T07:39:47Z,"I want to build Boost using the '''cc''' toolset. It bootstraps fine, but the build system fails to find the toolset when I run b2.

{{{
$ export CC=gcc
$ ./bootstrap.sh --with-toolset=cc
-n Building Boost.Build engine with toolset cc... 
tools/build/v2/engine/bin.macosxx86_64/b2
-n Detecting Python version... 
2.7
-n Detecting Python root... 
/opt/local/Library/Frameworks/Python.framework/Versions/2.7
-n Unicode/ICU support for Boost.Regex?... 
not found.
Backing up existing Boost.Build configuration in project-config.jam.6
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/boost-build2/doc/html/index.html

$ ./b2
cc.jam: No such file or directory
tools/build/v2/build/toolset.jam:38: in toolset.using
rule cc.init unknown in module toolset.
tools/build/v2/build/project.jam:888: in using
project-config.jam:12: in modules.load
tools/build/v2/build-system.jam:257: in load-config
tools/build/v2/build-system.jam:423: in load-configuration-files
tools/build/v2/build-system.jam:555: in load
tools/build/v2/kernel/modules.jam:283: in import
tools/build/v2/kernel/bootstrap.jam:142: in boost-build
boost-build.jam:17: in module scope
}}}
",anonymous
5912,tools/build/v2/contrib/boost.jam update,build,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2011-09-19T05:54:05Z,2011-09-19T05:54:05Z,"Boost has introduced new built libraries `libboost_chrono*` and `libboost_exception*`, which is not supported by the current `boost.jam`.

I have attached a patch for this update.

Note: `libboost_exception*` only has static variants right now, so `BOOST_EXCEPTION_DYN_LINK` is not needed to be defined.
",Ai Azuma <ai.azuma@…>
5904,"Patch to suppress ""unreachable code"" warning from Visual Studio 2008/2010 (VC90/VC100)",iostreams,Boost 1.47.0,Boost 1.48.0,Patches,No-Maintainer,new,2011-09-16T11:20:18Z,2011-09-19T18:35:00Z,"Probably as a result of ticket #3311, Visual Studio correctly identifies unreachable code when instantiating a boost::iostreams::stream with a Device that doesn't support certain functionality (e.g. a write-only Sink). Since the relevant code is reachable for other kinds of Device, the simplest fix is to just suppress the warning. The equivalent warning for Borland is already suppressed in boost/iostreams/detail/config/disable_warnings.hpp.

Code:

{{{
#include <deque>
#include <boost/iostreams/stream.hpp>
#include <boost/iostreams/device/back_inserter.hpp>

boost::iostreams::stream< boost::iostreams::back_insert_device< std::deque< char > > > s;
}}}

Result (provided not /Od):
{{{
1>...\boost_1_47_0\boost\iostreams\detail\adapter\concept_adapter.hpp(77) : warning C4702: unreachable code
1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(259) : warning C4702: unreachable code
1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(260) : warning C4702: unreachable code
1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(261) : warning C4702: unreachable code
1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(263) : warning C4702: unreachable code
1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(266) : warning C4702: unreachable code
1>...\boost_1_47_0\boost\iostreams\detail\adapter\concept_adapter.hpp(95) : warning C4702: unreachable code
1>...\boost_1_47_0\boost\iostreams\detail\streambuf\indirect_streambuf.hpp(333) : warning C4702: unreachable code
}}}

Patch for boost/iostreams/detail/config/disable_warnings.hpp:
{{{
17a18
> # pragma warning(disable:4702)    // Unreachable code.
}}}

Please would someone apply this for Boost 1.48.0?
",gareth.sylvester-bradley@…
5902,Division by zero when requesting null sized buffers,pool,Boost 1.47.0,To Be Determined,Bugs,John Maddock,new,2011-09-16T10:06:40Z,2012-07-16T20:00:31Z,"The following code yields a division by zero in pool::malloc_need_resize() :

{{{
	boost::pool<> p(0, 1, 1);
	p.malloc();
}}}

The code above requests at most one buffer of size zero. The expected behavior would be one of (i) malloc fails, (ii) malloc returns a null sized buffer. 

Regards",Étienne Dupuis <e.dupuis@…>
5898,bzip2_decompressor still does not handle pbzip2-compressed files correctly,iostreams,Boost 1.47.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-09-14T00:39:57Z,2011-09-14T00:39:57Z,"This is an extension of ticket #3853. I believe that the bug was not
resolved correctly. In particular, there appears to be a subtle problem
which occurs when the boundary between two bz streams falls at precisely
the wrong place in the input buffer.

The attached piece of code illustrates the problem.  It may be
compiled with, say:

    g++ testpbzip2.cc -o testpbzip2 -lboost_iostreams -lbz2
    ./testpbzip2

The input file (which is inlined in the source file) was created
using the following commands:

dd if=/dev/zero of=file bs=1000 count=901
pbzip2 -9 file

The problem was initially found on a real file with the default
buffer size of 4096. The smallest example that I've found which
exercises the problem at this buffer size is 160kB, and hence
not attached to this ticket. It is available on request.",Andrew.Bromage@…
5896,Range directory iterators,filesystem,Boost 1.47.0,To Be Determined,Feature Requests,Beman Dawes,assigned,2011-09-13T22:42:39Z,2012-04-19T15:26:00Z,"With C++11 now finalized as a standard, and compilers being more compliant every day, it makes sense to have range-based versions of the directory_iterator classes. This would make it much easier to use the range-based for loop, as well as Boost.Range functionality.

Basically, it could just be a couple of helper functions that create a boost::iterator_range<bfs::directory_iterator> instance.",jmckesson@…
5889,Add way to get the path to the running executable,filesystem,Boost 1.47.0,To Be Determined,Feature Requests,Beman Dawes,new,2011-09-10T21:40:26Z,2016-04-20T15:13:33Z,"The filesystem component is missing a function to return the path to the currently running executable. 
This is useful for finding associated program files without resorting to e.g. environmental variables. 

A discussion of the current system-specific ways to do this: 
  http://stackoverflow.com/q/1023306 and http://stackoverflow.com/q/933850

An example of a similar function exists in the Qt library: 
QCoreApplication::applicationFilePath()",ergosys@…
5888,[Documentation] iterator_facade docs -- const correctness problem.,iterator,Boost 1.47.0,To Be Determined,Bugs,jeffrey.hellrung,new,2011-09-10T19:10:50Z,2012-11-21T22:17:18Z,"On this documentation page, second box: http://www.boost.org/doc/libs/1_47_0/libs/iterator/doc/iterator_facade.html#a-constant-node-iterator there is a problem with const-correctness on the dereference function.

For the const_node_iterator, Value = const node_base, thus yielding

{{{
const node_base& dereference() const {
   return *m_node;
}

const node_base* m_node;
}}}

However, for node_iterator, Value = node_base:

{{{
node_base& dereference() const {
   return *m_node; // Error: cannot convert const variable to non_const reference
}

node_iterator* m_node;
}}}

Correct would be to const-overload dereference:

{{{
typedef boost::iterator_facade<
        node_iter<Value>
      , Value
      , boost::forward_traversal_tag
    > super;

typename super::reference dereference() {
    return *m_node;
}
const typename super::reference dereference() const {
    return *m_node;
}
}}}
",Frank Erens <seysayux@…>
5883,Neither <dependency> nor <use> works on prebuilt library targets,build,Boost 1.47.0,To Be Determined,Bugs,Vladimir Prus,new,2011-09-09T18:11:25Z,2012-08-10T06:04:45Z,"For example, suppose I have a jamroot file as follows;

{{{
run test.cpp : : : : test.run ;
explicit test.run ;

lib gmp : : <dependency>test.run ;
explicit gmp ;

exe main.exe : gmp main.cpp ;
explicit main.exe ;
}}}

Here, I just expect that `<dependency>` feature on the `lib` target introduces a dependency on the `test.run` target. However, command line invocation like
{{{
bjam main.exe
}}}
pulls neither the build nor run of `test.run` at all, and only `main.exe` is built.
",anonymous
5882,Add <define>_GLIBCXX_DEBUG for <runtime-debugging>on in gcc.jam,build,Boost 1.47.0,To Be Determined,Feature Requests,Vladimir Prus,new,2011-09-09T17:12:40Z,2012-08-09T07:39:24Z,"Right now runtime-debugging does zilch for GCC, which is pretty nonsensical. I'd like to see:

toolset.flags gcc.compile OPTIONS <runtime-debugging>on : <define>_GLIBCXX_DEBUG ;",matt.chambers42@…
5877,Ambiguous call building Boost.Python quickstart example,python USE GITHUB,Boost 1.47.0,To Be Determined,Bugs,Stefan Seefeld,new,2011-09-08T13:12:59Z,2012-12-07T22:37:16Z,"If I use .\b2 to do a build of plain vanilla Boost 1.47 on 32-bit Windows 7 using Python 3.2 and MSVC 10.0 SP1, it completes without error. I then add the lib= and include= environment variables as instructed at the end of the build, and CD to the python quickstart example.

When I then use b2 to build the quickstart example, it fails with:

{{{
embedding.cpp
embedding.cpp(39) : error C2668: 'std::basic_string<_Elem,_Traits,_Ax>::basic_st
ring' : ambiguous call to overloaded function
        with
        [
            _Elem=char,
            _Traits=std::char_traits<char>,
            _Ax=std::allocator<char>
        ]
        c:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\xstring(700): c
ould be 'std::basic_string<_Elem,_Traits,_Ax>::basic_string(std::basic_string<_E
lem,_Traits,_Ax> &&)'
        with
        [
            _Elem=char,
            _Traits=std::char_traits<char>,
            _Ax=std::allocator<char>
        ]
        c:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\xstring(590): o
r       'std::basic_string<_Elem,_Traits,_Ax>::basic_string(const _Elem *)'
        with
        [
            _Elem=char,
            _Traits=std::char_traits<char>,
            _Ax=std::allocator<char>
        ]
        while trying to match the argument list '(boost::python::detail::method_
result)'
}}}
and

{{{
embedding.cpp(56) : error C2065: 'initembedded_hello' : undeclared identifier
}}}

Of course, the second error may be caused by the first.

See http://mail.python.org/pipermail/cplusplus-sig/2011-September/016147.html for a more complete history and console listing.",paul@…
5876,Serialization - tracking of non-versioned classes,serialization,Boost 1.47.0,To Be Determined,Bugs,Robert Ramey,assigned,2011-09-08T09:42:18Z,2016-04-05T10:51:57Z,"I quote a case from my workplace. The issue came up for std::vector<int>, but I use a simple struct X to reproduce the problem. See the attached file for detailed instructions.

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

The following code:

{{{
    struct X { ... };

    X x2;
    BoostLoad(""SerializationBug.dat"", x2);

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

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

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

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

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

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

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

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

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

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

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

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

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

Revised Yakov Galka's 8:53 AM entry from 9/8/2011",ybungalobill@…
5864,unable to compile boost::mpi under Windows using msvc-2008-compiller,mpi,Boost 1.47.0,To Be Determined,Bugs,Douglas Gregor,new,2011-09-05T06:27:08Z,2013-08-03T23:32:39Z,"My steps to reproduce:

1. Setup environment for msvc-2008 compiler using bat-file for Visual Studio 2008 command line environment.
2. Compile library openmpi-1.4.3 using cmake (as specified in its documentation) and install it to ""d:\Libs\mpi-1.4.3\Release"".
3. Add path to ""d:\Libs\mpi-1.4.3\Release\bin"" to my PATH environment.
4. Check, that mpic++ works good:
{{{
> mpic++ --showme
cl.exe /I""d:/Libs/mpi-1.4.3/Release/include"" /TP /EHsc /D ""OMPI_IMPORTS"" /D ""OPAL_IMPORTS"" /D ""ORTE_IMPORTS"" /link /LIBPATH:""d:/Libs/mpi-1.4.3/Release/lib"" libmpi.lib libopen-pal.lib libopenrte.lib libmpi_cxx.lib libmpi.lib libopen-pal.lib libopen-rte.lib advapi32.lib Ws2_32.lib shlwapi.lib
}}}
5. Add string 'using mpi ;' to my <boost_dir>\tools\build\v2\user-config.jam file.
6. Try to compile boost::mpi:
{{{
> bjam.exe --prefix=d:\Programming\mpi-work\boost-mpi\installed --build-dir=d:\Programming\mpi-work\boost-mpi\bld --with-mpi install
}}}
As a result I got the error:
{{{
Системе не удается найти указанный путь.
Системе не удается найти указанный путь.
Системе не удается найти указанный путь.
Системе не удается найти указанный путь.
MPI auto-detection failed: unknown wrapper compiler mpic++
Please report this error to the Boost mailing list: http://www.boost.org
You will need to manually configure MPI support.
}}}
('Системе не удается найти указанный путь.' - means 'System can't find specified path')

The same result I got using b2.exe instead of bjam.exe.

I tried to read the documentation to setup exact paths to openmpi for mpi module in the user-config.jam. But I couldn't understand, where should I put include- and library-paths in it.

My environment - Windows XP SP2 x32, Visual Studio 2008 with compiler version 15.00.21022.08. I have attached partial command line environment as file to the bug report.",Slav Grig <armagvvg@…>
5863,Warnings when including boost/mpi/skeleton_and_content.hpp,mpi,Boost 1.47.0,To Be Determined,Bugs,Matthias Troyer,new,2011-09-04T19:56:09Z,2013-01-01T11:35:43Z,"Unused identifiers at boost/mpi/detail/ignore_iprimitive.hpp line 55; boost/mpi/detail/ignore_oprimitive.hpp line 47;

Just comment out or remove it. ;-)

Regards,
Júlio.",Júlio Hoffimann Mendes <julio.hoffimann@…>
5862,"broken links in ""New Iterator Concepts""",iterator,Boost 1.47.0,To Be Determined,Patches,jeffrey.hellrung,new,2011-09-03T16:50:29Z,2012-11-21T22:14:14Z,"In [http://www.boost.org/doc/libs/1_47_0/libs/iterator/doc/new-iter-concepts.html New Iterator Concepts]:

 is:: [http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#200 issue 200]
 let:: [http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200 issue 200]

 is:: once [http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#299 issue 299] is resolved
 let:: since [http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#299 issue 299] has been resolved",Christopher Yeleighton <giecrilj@…>
5861,Iterators documentation is invalid,iterator,Boost 1.47.0,To Be Determined,Bugs,jeffrey.hellrung,new,2011-09-03T15:36:19Z,2012-11-21T22:10:47Z,"under /doc/libs/1_47_0/libs/iterator/:

… href=""/favicon.ico"" type=""image/ico""><link rel=""stylesheet"" 
type=""text/css"" h…

(unclosed link element in [http://www.w3.org/TR/xhtml1 XHTML] mode)",Christopher Yeleighton <giecrilj@…>
5858,"Issue to compile in VS 2008, VC 9.0.30729.1 SP without Microsoft extensions",iterator,Boost 1.35.0,To Be Determined,Bugs,jeffrey.hellrung,new,2011-09-02T18:03:25Z,2012-11-21T20:03:45Z,"The issue appears first in 1.35.0 version. The version 1.34.1 is still OK.
It is only appears when microsoft extentions are disabled.
The library is ""Iterator"".
For version 1.35.1: the file is iterator_concepts.hpp, line nuber is 136:
{{{
BOOST_concept(SinglePassIterator, (Iterator))
    : IncrementableIterator <Iterator>
    , boost::EqualityComparable <Iterator>

  {
--->>>      BOOST_CONCEPT_ASSERT((
          boost::Convertible<
             BOOST_DEDUCED_TYPENAME SinglePassIterator::traversal_category
           , boost::single_pass_traversal_tag
          > ));
  };
}}}

The first line of error message is \boost\include\boost-1_35_0\boost/iterator/iterator_concepts.hpp(136) : error C2146: syntax error : missing ',' before identifier 'traversal_category'
",Dr. Sergey Kiselev <SergK13@…>
5853,Predefined macro __ppc not checked by various boost headers,numeric,Boost Development Trunk,To Be Determined,Bugs,Douglas Gregor,new,2011-09-01T16:52:12Z,2011-12-12T22:46:15Z,"Various boost headers implement variant definitions and logic depending on the processor defined for the compilation. There are variations taking into account compilation on the powerpc family of processors but some of the headers in question do not include checking for powerpc compilation via presence of the !__ppc predefined macro (they check against other predefineds: !__ppc!__, !__powerpc!__, etc, but the !WindRiver vxworks gnu compiler for powerpc only defines !__ppc).

Boost headers in question:

boost/detail/endian.hpp[[BR]]
boost/interprocess/detail/atomic.hpp[[BR]]
boost/numeric/interval/hw_rounding.hpp[[BR]]
boost/numeric/interval/detail/ppc_rounding_control.hpp

The trunk was checked to be certain that fixes had not yet been applied. No other related bug reports found either.

",gshapiro@…
5850,last_write_time on Windows may not work on SMB2-network-mounted drive,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,assigned,2011-08-31T15:22:13Z,2011-10-11T12:21:05Z,"Consider the following logical operation against a file on a network-mounted drive served over SMB2:

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

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

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

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

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

Please feel free to contact me for follow up.
Thanks,
-Ken",Ken Harris <kharris@…>
5849,all_to_all() passes invalid args to allocate when sending lots of data,mpi,Boost 1.47.0,To Be Determined,Bugs,Matthias Troyer,new,2011-08-31T09:10:52Z,2013-01-01T11:39:18Z,"For boost 1.47.0 code of the following form fails...
{{{
#!div style=""font-size: 80%""
  {{{#!c++
boost::mpi::communicator communicator;
std::vector< std::list<Thing*> > in_values(communicator.size());
std::vector< std::list<Thing*> > out_values(communicator.size());
// Point the lists in in_values to more than numeric_limits<int>::max() bytes of data
boost::mpi::all_to_all(communicator,in_values,out_values);
  }}}
}}}
Such code ends up passing the allocator, using openmpi-1.4.3, an invalid argument.

Looking at all_to_all.hpp and the method...
{{{
#!div style=""font-size: 80%""
  {{{#!c++
  template<typename T>
  void
  all_to_all_impl(const communicator& comm, const T* in_values, int n,
                  T* out_values, mpl::false_)
  {
      ...
  }
  }}}
}}}
I think I see why this happens. The method begins as follows...
{{{
#!div style=""font-size: 80%""
  {{{#!c++
    std::vector<int> send_sizes(size);

    // The displacements for each outgoing value.
    std::vector<int> send_disps(size);

    // The buffer that will store all of the outgoing values
    std::vector<char, allocator<char> > outgoing;

    // Pack the buffer with all of the outgoing values.
    for (int dest = 0; dest < size; ++dest) {
      // Keep track of the displacements
      send_disps[dest] = outgoing.size();

      // Our own value will never be transmitted, so don't pack it.
      if (dest != rank) {
        packed_oarchive oa(comm, outgoing);
        for (int i = 0; i < n; ++i)
          oa << in_values[dest * n + i];
      }

      // Keep track of the sizes
      send_sizes[dest] = outgoing.size() - send_disps[dest];
    }
  }}}
}}}
If outgoing.size() or (outgoing.size() - send_disps[dest]) is greater than
numeric_limits<int>::max(), then send_disps[dest]  or send_sizes[dest]
flips over to negative values or is simply junk. After that happens the rest
of the code in all_to_all_impl() doesn't really make any sense.

My guess is that instead of using int here...
{{{
#!div style=""font-size: 80%""
  {{{#!c++
  std::vector<int> send_sizes(size);
  std::vector<int> send_disps(size);
  std::vector<int> recv_sizes(size);
  ...
  }}}
}}}
you should use allocator::size_type.",Kelly Davis <kdavis@…>
5821,not able to handle linux path starting with ~/,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-08-29T11:36:10Z,2011-08-29T11:36:10Z,"Hi,
  I had a complete path like ~/test/test1.
  but when I was using the path with is_complete fucntion, it gives wrong result.",vivek_kumar@…
5819,error in solaris_fenced_block.hpp in solaris 10 sun c++ 5.8,asio,Boost 1.47.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-08-28T21:20:41Z,2013-02-15T11:42:13Z,"""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/asio/detail/solaris_fenced_block.hpp"", line 37: Error: The function ""membar_consumer"" must have a prototype.
""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/asio/detail/solaris_fenced_block.hpp"", line 43: Error: The function ""membar_producer"" must have a prototype.
""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/asio/detail/impl/socket_ops.ipp"", line 952: Error: msg_flags is not a member of msghdr.
""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/bind/bind.hpp"", line 69: Error: boost::_bi::F is not a namespace or class name.
""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/bind/bind_template.hpp"", line 15:     Where: While specializing ""boost::_bi::result_traits<boost::_bi::unspecified, void(QuickFAST::Communication::MulticastReceiver::*)(const boost::system::error_code&,QuickFAST::Communication::LinkedBuffer*,unsigned long)>"".
""/sr/gldev/wfpvcs/tunis/bbouzayani/QuickFast_SOL10/boost_1_47_0/stage/include/./boost/bind/bind_template.hpp"", line 15:     Where: Specialized in boost::_bi::bind_t<boost::_bi::unspecified, void(QuickFAST::Communication::MulticastReceiver::*)(const boost::system::error_code&,QuickFAST::Communication::LinkedBuffer*,unsigned long), boost::_bi::list4<boost::_bi::value<QuickFAST::Communication::MulticastReceiver*>, boost::arg<1>, boost::_bi::value<QuickFAST::Communication::Linked",bouzayanibilel@…
5815,booast asio crash in io_service run,asio,Boost 1.47.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-08-26T17:45:14Z,2011-10-16T18:00:21Z,"Boost Asio crashes on slackware linux with g++ (GCC) 4.5.2
I made a simple http server startig from the examples on the website. When I add a deadline timer to shutdown the connection, only adding it in the connection class and and initializing it with the io_service makes the program to seg fault in io_service run.
",mileandrei@…
5811,indirected range adaptor not satisfied with unary dereference operator,range,Boost Development Trunk,To Be Determined,Bugs,Neil Groves,reopened,2011-08-25T19:17:26Z,2017-10-24T11:58:04Z,"The documentation for Range's indirected adaptor claims that it is usable with anything that has an unary operator*().

When using it with a range of optional<int>, it seems to require an element_type inner type, which optional doesn't expose and the docs does not require.

The following testcase fails to compile with VC10 and GCC 4.2.3:

{{{#!c++
#include <boost/optional.hpp>
#include <boost/range/adaptors.hpp>
#include <vector>

int main(int argc, char* argv[])
{
	std::vector<boost::optional<int> > v;
	v | boost::adaptors::indirected;
}
}}}",Lars Viklund <zao@…>
5806,Property tree supporting custom allocators such as the boost pool ones,property_tree,Boost 1.47.0,To Be Determined,Feature Requests,Sebastian Redl,new,2011-08-23T10:15:35Z,2015-01-21T13:14:19Z,"I'm currently working on a c++ extension based on custom allocators and i wanted to use property_tree in my serialization section as it seems very well designed, but i'm stuck with the fact that basic_ptree doesn't allow an allocator type to be passed as argument. It would be very nice to add custom allocation to property_tree so that we can : first customize internal ptree allocations and then use customized version of STL with it.
regards.
",vivien.millet@…
5804,Anonymous SVN inaccessible,trac / subversion,Boost Release Branch,To Be Determined,Bugs,Douglas Gregor,new,2011-08-22T18:08:11Z,2011-10-04T20:09:48Z,The SVN checkout URL on the Downloads page asks for a username and password and none is given for anonymous access.,mathstuf@…
5786,Section 5.2 in Getting Started Guide is misleading,Getting Started Guide,Boost 1.47.0,To Be Determined,Bugs,Dave Abrahams,new,2011-08-16T11:19:14Z,2011-08-16T11:19:14Z,"Section 5.2 of the Getting Started Guide: ""Or, Simplified Build From Source"" says to run:

bootstrap

.\b2

This does work (except when it gets the toolchain wrong) and successfully builds boost, and the output does correctly list the include and library paths.

However, it leaves boost in a state inconsistent with the instructions in Section 6.1 and 6.2. These have examples which assume the libraries are in the lib subdirectory of the boost root (which it looks like they are for pre-compiled builds), whereas the instructions in 5.2 leave them in the stage/lib subdirectory.

There is an ""install"" option which puts the libraries in another location, but this isn't mentioned in the Getting Started Guide.

Section 5.4 also doesn't mention that the paths are listed in the expected build output, so this is easy to miss if you are not specifically looking for it.

This means that following the instructions for building from source in the Getting Started Guide doesn't work, as Section 6.4 will fail with link errors.
",john.reynolds@…
5785,regression in parsing a list of lists,spirit,Boost 1.47.0,To Be Determined,Bugs,Joel de Guzman,new,2011-08-15T16:54:36Z,2011-08-15T16:54:36Z,"The following code doesn't compile in boost-1.47.0, but compiles fine in boost-1.44.0:

{{{
#include <boost/spirit/include/qi.hpp>
#include <boost/fusion/include/std_pair.hpp>

int main ()
{
  std::string str (""0.1:1.5,0.2:4,-1.2:5.5;1:2,3:4,5:6;10:20,20:30,30:40"");

  using namespace boost::spirit::qi;
  
  std::vector<std::vector<std::pair<double, double> > > v;
  phrase_parse (str.begin(), str.end (),
                ((double_ >> ':' >> double_) % ',') % ';',
                space, v);

  return 0;
}

}}}

The (final) error message is:

{{{
include/boost/spirit/home/support/container.hpp:278: error: no matching function for call to ‘std::vector<std::pair<double, double>, std::allocator<std::pair<double, double> > >::insert(__gnu_cxx::__normal_iterator<std::pair<double, double>*, std::vector<std::pair<double, double>, std::allocator<std::pair<double, double> > > >, const double&)’
}}}
",matt@…
5769,"fstream.hpp facilities not usable for paths containing characters outside of the current Windows (""ANSI"") code page on GCC (mingw/mingw-w64)",filesystem,Boost 1.46.1,To Be Determined,Bugs,Beman Dawes,new,2011-08-10T13:25:49Z,2017-10-06T07:58:24Z,"GCC's libstdc++ does not follow MS VC++'s lead in extending std::fstream and std::filebuf to take paths made up of wchar_t strings.

boost::filesystem::filebuf and {i,o,}fstream rely on this functionality. In its absence, they fall back to converting the path's wchar_t representation into a char string in the Windows (""ANSI"") code page of the current system locale (actually, they incorrectly use the current thread codepage, see #5592).

The fstream facilities are therefore unusable with GCC when you build a Windows program that manipulates paths containing characters that are not representable in the current Windows code page.

When compiled with the GCC from mingw-w64, the attached test will fail to create a file. Examination with Process Monitor reveals that the program tries to create a file with the name of ""umbre??a"", because the ☂ character is not representable in any Windows code page.

GCC provides a __gnu_cxx::stdio_filebuf, which may be constructed from a FILE* or file descriptor; this could be used in concert with MSVCRT's _wfopen or _wopen functions, by boost::filesystem::{i,o,}fstream to provide the missing functionality.",sam@…
5766,Uninitialized variable warnings with GCC 4.4.5-6,geometry,Boost 1.47.0,To Be Determined,Support Requests,Barend Gehrels,new,2011-08-09T12:41:52Z,2013-04-05T21:16:03Z,"Uninitialized variable warnings with Redhat GCC 4.4.5-6 (x86-64), Boost r73613:

In file included from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/overlay.hpp:21,
                 from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/intersection_insert.hpp:27,
                 from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/difference.hpp:14,
                 from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/geometry.hpp:47,
                 from /shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry.hpp:17,
                 from /home/wash/hpx/examples/geometry/point_geometry/server/point.cpp:16:
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp: In member function ‘bool boost::geometry::detail::overlay::sort_on_segment_and_distance<TurnPoints, Indexed, Geometry1, Geometry2, Reverse1, Reverse2, Strategy>::operator()(const Indexed&, const Indexed&) const [with TurnPoints = std::deque<boost::geometry::detail::overlay::traversal_turn_info<boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian> >, std::allocator<boost::geometry::detail::overlay::traversal_turn_info<boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian> > > >, Indexed = boost::geometry::detail::overlay::indexed_turn_operation<boost::geometry::detail::overlay::traversal_turn_operation<boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian> > >, Geometry1 = boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>, true, true, std::vector, std::vector, std::allocator, std::allocator>, Geometry2 = boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>, true, true, std::vector, std::vector, std::allocator, std::allocator>, bool Reverse1 = false, bool Reverse2 = false, Strategy = boost::geometry::strategy::side::side_by_triangle<void>]’:
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: warning: ‘pi.boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>::<anonymous>.boost::geometry::model::point<double, 2ul, boost::geometry::cs::cartesian>::m_values[1ul]’ may be used uninitialized in this function [-Wuninitialized]
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: note: ‘pi.boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>::<anonymous>.boost::geometry::model::point<double, 2ul, boost::geometry::cs::cartesian>::m_values[1ul]’ was declared here
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: warning: ‘pi.boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>::<anonymous>.boost::geometry::model::point<double, 2ul, boost::geometry::cs::cartesian>::m_values[0ul]’ may be used uninitialized in this function [-Wuninitialized]
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: note: ‘pi.boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>::<anonymous>.boost::geometry::model::point<double, 2ul, boost::geometry::cs::cartesian>::m_values[0ul]’ was declared here
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: warning: ‘pj.boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>::<anonymous>.boost::geometry::model::point<double, 2ul, boost::geometry::cs::cartesian>::m_values[1ul]’ may be used uninitialized in this function [-Wuninitialized]
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: note: ‘pj.boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>::<anonymous>.boost::geometry::model::point<double, 2ul, boost::geometry::cs::cartesian>::m_values[1ul]’ was declared here
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: warning: ‘pj.boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>::<anonymous>.boost::geometry::model::point<double, 2ul, boost::geometry::cs::cartesian>::m_values[0ul]’ may be used uninitialized in this function [-Wuninitialized]
/shared/boost/trunk/stage/gcc-4.4.5-release/include/boost/geometry/algorithms/detail/overlay/enrich_intersection_points.hpp:114: note: ‘pj.boost::geometry::model::d2::point_xy<double, boost::geometry::cs::cartesian>::<anonymous>.boost::geometry::model::point<double, 2ul, boost::geometry::cs::cartesian>::m_values[0ul]’ was declared here
",Bryce Adelstein Lelbach
5765,Container Device/Sink bug,iostreams,Boost 1.47.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-08-09T11:49:15Z,2011-08-09T11:49:15Z,"i think write should be like this, otherwise if one seeks back (after writing to overwrite replace some data, number of bytes seeked back will be duplicated on the next write.
(original line changed/replaced is commented out in code)

{{{
#!c++
    std::streamsize write(const char_type* s, std::streamsize n)
    {
        using namespace std;
        std::streamsize result = 0;
        if (pos_ != container_.size()) {
            std::streamsize amt =
                static_cast<std::streamsize>(container_.size() - pos_);
            result = (min)(n, amt);
            std::copy(s, s + result, container_.begin() + pos_);
            pos_ += result;
        }
        if (result < n) {
            container_.insert(container_.end(), s + result, s + n);
            //container_.insert(container_.end(), s, s + n);
            pos_ = container_.size();
        }
        return n;
    }

}}}",aris.basic@…
5745,Use native typeof support for Oracle Solaris Studio C++ compiler,typeof,Boost 1.47.0,Boost 1.48.0,Feature Requests,Peder Holt,assigned,2011-08-01T14:51:58Z,2011-08-09T09:50:47Z,"Oracle Solaris Studio (former !SunStudio) C++ compiler supports native typeof since version 5.9. At the same time, support for typeof emulation is not so good (many compilation errors). It would be beneficial for Boost users if Boost used native typeof instead of emulation.

Here is proposed patch:
{{{
*** boost/typeof/typeof.hpp	2011-08-01 18:46:33.411406362 +0400
--- boost/typeof/typeof.hpp.new	2011-08-01 18:46:43.680746049 +0400
***************
*** 155,160 ****
--- 155,176 ----
  #   else
  #       error native typeof is not supported
  #   endif
+ #elif defined(__SUNPRO_CC)
+ #   if (__SUNPRO_CC < 0x590 )
+ #	ifdef BOOST_TYPEOF_NATIVE
+ #	    error native typeof is not supported
+ #	endif
+ #	ifndef BOOST_TYPEOF_EMULATION
+ #	    define BOOST_TYPEOF_EMULATION
+ #	endif
+ #   else
+ #	ifndef BOOST_TYPEOF_EMULATION
+ #	    ifndef BOOST_TYPEOF_NATIVE
+ #		define BOOST_TYPEOF_NATIVE
+ #	    endif
+ #	    define BOOST_TYPEOF_KEYWORD __typeof__
+ #	endif
+ #   endif
  #else //unknown compiler
  #   ifndef BOOST_TYPEOF_NATIVE
  #       ifndef BOOST_TYPEOF_EMULATION
}}}",Maxim Kartashev <maxim.kartashev@…>
5743,Serializable boost::multi_array class,multi_array,Boost 1.47.0,To Be Determined,Feature Requests,Ronald Garcia,new,2011-07-30T14:02:58Z,2012-11-17T22:04:26Z,"An interface for Boost.Serialization library. I tried to make it myself, but as an external user is difficulty to understand safely the concepts and relevant attributes to serialize.

Thank you.",Júlio Hoffimann <julio.hoffimann@…>
5734,possible handle leak in posix implementation copy_file_api,filesystem,Boost 1.47.0,Boost 1.48.0,Bugs,Beman Dawes,assigned,2011-07-26T04:04:07Z,2011-07-26T14:49:21Z,"There is possible handle leak in POSIX implementation of function '''copy_file_api'''.


{{{
...
    if ((infile = ::open(from_p.c_str(), O_RDONLY))< 0)
      { return false; }

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

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


This problem exists both in '''v3''' and '''v2''' implementations of filesystem. Also this problem exists in previous releases.
",alexey.kutumov@…
5721,Modulo operation for boost::rational,rational,Boost Development Trunk,To Be Determined,Patches,Jonathan Turkanis,new,2011-07-19T20:41:10Z,2011-07-19T20:41:10Z,"boost::rational currently omits to define modulo on rational numbers.
The attached patches adds operator%= to boost::rational and therefore allows it
to use ordered_euclidian_ring_operators.",mlang@…
5712,terminate called recursively with filesystem header,filesystem,Boost 1.47.0,,Bugs,Beman Dawes,new,2011-07-18T22:15:37Z,2011-07-18T22:15:37Z,"Hello,

I'm using boost::filesystem within my project (boost 1.47.0). I have compiled the boost under cygwin with bjam. I have some problems with exception throws / catches:
The following example shows the problem:

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

int main(int argc, char* argv[]) {
    throw std::runtime_error(""xxx"");
    return 0;
}

If I compile this code under Cygwin and link cygboost_filesystem, cygboost_system and libbost_exception, the programs terminates with this messages:
terminate called after throwing an instance of 'std::runtime_error'
terminate called recursively

If I remove the boost/filesystem include the program produce the correct message:
terminate called after throwing an instance of 'std::runtime_error'
  what():  xxx


If I change the program to:

int main(int argc, char* argv[]) {
	try {
		throw std::runtime_error(""xxx"");
	} catch (...) {}
	return 0;
}

the program breaks down with the filesystem include:
terminate called after throwing an instance of 'std::runtime_error'
terminate called recursively

without the include always works fine.


Thanks a lot
",philipp.kraus@…
5706,Gcc 4.6 warnings for Boost Graph,graph,Boost Development Trunk,Boost 1.56.0,Feature Requests,Andrew Sutton,reopened,2011-07-17T11:07:20Z,2017-01-24T20:26:11Z,"Dear authors,

Compiling our applications with newest gcc-4.6- some warnings regarding boost graph are displayed. We would appreciate if you could silence them.

Please find below gcc output

Ubuntu oneiric 64  bits boost 1.47/ trunk , gcc Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu


{{{

/adnet/boost-1.47.0/include/boost/graph/detail/adj_list_edge_iterator.hpp: In member function ‘void boost::vec_adj_list_impl<Graph, Config, Base>::copy_impl(const boost::vec_adj_list_impl<Graph, Config, Base>&) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, Config = boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_bundle_t, pce::te::node_te_attributes, boost::no_property>, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property>, pce::te::graph_te_attributes, boost::listS>::config, Base = boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_bundle_t, pce::te::node_te_attributes, boost::no_property>, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property>, pce::te::graph_te_attributes, boost::listS>::config>, boost::vec_adj_list_impl<Graph, Config, Base> = boost::vec_adj_list_impl<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_bundle_t, pce::te::node_te_attributes, boost::no_property>, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property>, pce::te::graph_te_attributes, boost::listS>::config, boost::directed_graph_helper<boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, pce::te::node_te_attributes, pce::te::link_te_attributes, pce::te::graph_te_attributes, boost::listS>, boost::vecS, boost::vecS, boost::directedS, boost::property<boost::vertex_bundle_t, pce::te::node_te_attributes, boost::no_property>, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property>, pce::te::graph_te_attributes, boost::listS>::config> >]’:
/adnet/boost-1.47.0/include/boost/graph/detail/adj_list_edge_iterator.hpp:95:84: warning: ‘*((void*)& ei_end +32)’ may be used uninitialized in this function [-Wuninitialized]
/adnet/boost-1.47.0/include/boost/graph/detail/adjacency_list.hpp:2128:27: note: ‘*((void*)& ei_end +32)’ was declared here
/adnet/boost-1.47.0/include/boost/graph/detail/adj_list_edge_iterator.hpp:70:9: warning: ‘*((void*)(& ei)+48).__gnu_cxx::__normal_iterator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >*, std::vector<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >, std::allocator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> > > > >::_M_current’ may be used uninitialized in this function [-Wuninitialized]
/adnet/boost-1.47.0/include/boost/graph/detail/adjacency_list.hpp:2128:23: note: ‘*((void*)(& ei)+48).__gnu_cxx::__normal_iterator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >*, std::vector<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >, std::allocator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> > > > >::_M_current’ was declared here
/adnet/boost-1.47.0/include/boost/graph/detail/adjacency_list.hpp:2117:19: warning: ‘*((void*)(& ei)+32).__gnu_cxx::__normal_iterator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >*, std::vector<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> >, std::allocator<boost::detail::sep_<long unsigned int, boost::property<boost::edge_bundle_t, pce::te::link_te_attributes, boost::no_property> > > > >::_M_current’ may be used uninitialized in this function [-Wuninitialized]
}}}

Thank you in advance and best regards

R.
",ramon.casellas@…
5702,Filename is returned within quotes instead without,filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-07-16T09:30:02Z,2011-07-19T07:31:08Z,"In the reference (http://www.boost.org/doc/libs/1_47_0/libs/filesystem/v3/doc/reference.html#path-decomposition) it is said that for example the filename returned by filename() will be without the quotes:
{{{#!c++
std::cout << path(""/foo/bar.txt"").filename(); // outputs ""bar.txt"" (without the quotes)
}}}
But actually I'm getting an output with the filename enclosed in quotes like:
{{{
""bar.txt""
}}}

I'm using Windows Vista.",moritz@…
5698,Contains parameter,parameter,Boost 1.47.0,To Be Determined,Feature Requests,Daniel Wallin,new,2011-07-14T14:52:50Z,2011-07-14T14:52:50Z,"I tested this

{{{

    template<typename Args, typename Tag>
    struct contains_parameter
        : mpl::not_<
            typename boost::is_void<
                typename parameter::binding<
                    Args, 
                    Tag, 
                    void
                >::type
            >::type
        >
    {};

}}}

which first appeared here:

http://boost.2283326.n4.nabble.com/boost-users-Boost-Parameter-ArgumentPack-is-type-contained-td3415943.html

and would like to suggest it as an addition.",er.ci.2020@…
5687,some evaluation functions do not work with BOOST_RESULT_OF_USE_DECLTYPE,phoenix,Boost 1.47.0,To Be Determined,Bugs,Thomas Heller,reopened,2011-07-12T11:45:37Z,2012-08-28T01:43:00Z,"Codes using `phoenix::construct` fail to compile in C++0x with `BOOST_RESULT_OF_USE_DECLTYPE` (Tested on gcc 4.6.1 and clang TOT).
Here is a minimal test code: 
{{{
#define BOOST_RESULT_OF_USE_DECLTYPE

#include <boost/phoenix/core.hpp>
#include <boost/phoenix/object/construct.hpp>

int main (int argc, char* argv[])
{
    boost::phoenix::construct<int>()();
    
    return 0;
}
}}}
Also, you can get the compile error by compiling `libs/phoenix/test/object/new_delete_tests.cpp` with `BOOST_RESULT_OF_USE_DECLTYPE`. 
",Michel MORIN <mimomorin@…>
5680,"bootstrap Boost.Build fails with MinGW 20110530: missing sys/wait.h, sys/resource.h, ar.h",Building Boost,Boost 1.46.1,To Be Determined,Bugs,,new,2011-07-08T18:32:13Z,2015-04-19T20:40:33Z,"My OS is Windows XP Pro. 

To reproduce: 
* Install MinGW 20110530.
* Download and uncompress boost_1_46_1.tar.bz2.
* Launch MinGW Shell from Start menu.
* Verify path:

{{{
$ printenv PATH
.:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem
}}}

* cd and run bootstrap:

{{{
$ cd boost_1_46_1/tools/build/v2
$ sh bootstrap.sh
Bootstrapping the build engine with toolset gcc...
Failed to bootstrap the build engine
Consult 'bootstrap.log' for more details
$ cat bootstrap.log
###
### Using 'gcc' toolset.
###
rm -rf bootstrap
mkdir bootstrap
gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c
builtins.c:32:23: fatal error: sys/wait.h: No such file or directory
compilation terminated.
execunix.c:17:26: fatal error: sys/resource.h: No such file or directory
compilation terminated.
fileunix.c:97:17: fatal error: ar.h: No such file or directory
compilation terminated.
}}}

Surrounding the above failed includes with #ifndef {{{__}}}MINGW32{{{__}}} ... #endif did not fix the problem.
",Alex Millian Hankins <lx_boost@…>
5677,Bootstrap fails with python versions 3.1 and up,Building Boost,Boost Release Branch,To Be Determined,Patches,,new,2011-07-07T21:15:11Z,2017-10-26T13:56:07Z,"Using bootstrap.sh to build boost with python versions 3.1 and up generates output similar to the following and the subsequent build fails for boost.python:

Detecting Python version... 3.2
Detecting Python root...   File ""<string>"", line 1
    import sys; print sys.prefix
                        ^
SyntaxError: invalid syntax

This appears to be caused by the code checking for the python root using a form of the 'print' function that is no longer valid in later versions of python. Attached is a patch that fixes this issue.",Eric Barr <eric.barr@…>
5673,Quick allocator error in multi thread,smart_ptr,Boost 1.44.0,To Be Determined,Bugs,Peter Dimov,new,2011-07-06T12:48:01Z,2011-10-25T16:16:17Z,"Compiler: '''MSVS 2008''' 
use macros '''BOOST_SP_USE_QUICK_ALLOCATOR'''

Exception (Access vialation by reading address) occured by constructor of '''shared_ptr'''.

Cause of exception is multi thread creation of static mutex in quick allocator.

shared_ptr call quick allocator.
quick allocator use next code:
{{{
lightweight_mutex::scoped_lock lock( mutex() );
}}}

function '''mutex()''' return internal static variable:
{{{
boost_1_44_0\boost\smart_ptr\detail\quick_allocator.hpp
template<unsigned size, unsigned align_> struct allocator_impl
{
... 

     static lightweight_mutex & mutex()
     {
         static freeblock< sizeof( lightweight_mutex ), boost::alignment_of< lightweight_mutex >::value > fbm;
         static lightweight_mutex * pm = new( &fbm ) lightweight_mutex;
         return *pm;
     }
 
...
}
}}}
2 thread call mutex() (first time for this instantiation of template class allocator_impl). One start init '''pm''' and go to sleep. Other check that '''pm''' is initialized and return its value (in my case NULL) and raise exception.
[[BR]]
Initialization of static variable in C++ is not safe for multi thread. This code is incorrect. In dependence from realization of static variable you will be have access vialation or memory leak - flag of static variable initialization (construction) set before or after initialization.
[[BR]]
In MSVS 2008 flag set before and you take access vialation.
[[BR]][[BR]]
'''Decision''' [[BR]]
Not resolve, but minimize problem. [[BR]]
Idea:[[BR]]
As I understand, This problem can appear in first initialization of __every__ instantiation of shared_ptr - first use __every__ instantiation of allocator_impl.
[[BR]]
If you synchronize of initialization '''pm''' then problem can appear only first initialization of __any__ instantiation of shared_ptr. And I can create first fictive shared_ptr in non-multi thread and then normal use shared_ptr in multi thread.
[[BR]]
Realization:[[BR]]
{{{
boost_1_44_0\boost\smart_ptr\detail\quick_allocator.hpp

lightweight_mutex & global_mutex()
{
   static freeblock< sizeof( lightweight_mutex ), boost::alignment_of< lightweight_mutex >::value > fbm;
    static lightweight_mutex * pm = new( &fbm ) lightweight_mutex;
         return *pm;
}



template<unsigned size, unsigned align_> struct allocator_impl
{
     static lightweight_mutex & mutex()
     {
         static freeblock< sizeof( lightweight_mutex ), boost::alignment_of< lightweight_mutex >::value > fbm;
         static lightweight_mutex * pm = NULL;
         if(pm == NULL)
         {
            lightweight_mutex::scoped_lock lock( global_mutex() );
            if(pm == NULL)
            {
                pm = new( &fbm ) lightweight_mutex;
            }
         }
         return *pm;
     }
}
}}}
",Yury Podpruzhnikov <QWERTYura@…>
5672,Intel compiler failure with BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF,mpl,Boost Development Trunk,To Be Determined,Bugs,Joel Falcou,new,2011-07-05T17:27:54Z,2011-07-05T17:27:54Z,"Attempting to use the Intel 11.1 or 12.0 compiler to test the existence of a nested template using the macro BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF results in a compiler error. When running the has_xxx.cpp MPL test against Intel 12.0, the error message is:

""has_xxx.cpp(20): error: more than one instance of overloaded function ""has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]"" matches the argument list:
            function template ""boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute0<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]""
            function template ""boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute1<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]""
            function template ""boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute2<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]""
            function template ""boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute3<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]""
            function template ""boost::mpl::aux::yes_tag has_xxx_template<T, fallback_>::has_xxx_template_introspect<U>::has_xxx_template_test(const volatile boost::mpl::aux::type_wrapper<V> *, has_xxx_template<a5, boost::mpl::bool_<false>>::has_xxx_template_introspect<a5>::has_xxx_template_substitute4<V::xxx> *) [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]""
            argument types are: (int)
  BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF(has_xxx_template, xxx, false)
  ^
          detected during:
            instantiation of class ""has_xxx_template<T, fallback_>::has_xxx_template_introspect<U> [with T=a5, fallback_=boost::mpl::bool_<false>, U=a5]"" at line 20
            instantiation of class ""has_xxx_template<T, fallback_> [with T=a5, fallback_=boost::mpl::bool_<false>]"" at line 148 of ""../../../boost/mpl/assert.hpp""
            instantiation of class ""boost::mpl::assert_arg_pred_not<P> [with P=has_xxx_template<a5, boost::mpl::bool_<false>>]"" at line 82""

The Intel 11.1 compiler has the same error.

John Maddock has reported this to Intel as Intel support ID #635997.
",anonymous
5658,how to get  rid of nasty compiler warning in boost/property_tree/detail/rapidxml.hpp,property_tree,Boost 1.46.1,To Be Determined,Tasks,Sebastian Redl,assigned,2011-06-29T07:39:25Z,2014-02-14T15:10:46Z,"compiling e.g libs/graph/src/graphml.cpp warns ...

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

Caused by the template:

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

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

{{{ 
        inline size_t get_index(const char c)
        {
            return c;
        }

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

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

{{{
14972c14972
<       cmpq    (%r15), %rdi
---
>       cmpq    %rdi, (%r15)
14974c14974
<       jae     .L3637
---
>       jbe     .L3637
15002c15002
<       cmpq    -16(%rsi), %rdi
---
>       cmpq    %rdi, -16(%rsi)
15004c15004
<       jae     .L3643
---
>       jbe     .L3643
15017c15017
<       cmpq    -16(%rdx), %rdi
---
>       cmpq    %rdi, -16(%rdx)
15019c15019
<       jb      .L3796
---
>       ja      .L3796
15487c15487
---
}}}",Dieter Stach <Dieter.Stach@…>
5656,Support options without '=',program_options,Boost 1.46.1,Boost 1.48.0,Feature Requests,Vladimir Prus,new,2011-06-28T14:21:25Z,2013-03-05T20:19:02Z,"parse_config_file throws invalid_syntax when a line doesn't contain '='
But for bool options, a '=' should not be required.",olafvdspek@…
5655,parse_config_file option to not throw if file can't be opened,program_options,Boost 1.46.1,Boost 1.48.0,Feature Requests,Vladimir Prus,new,2011-06-28T14:06:34Z,2011-10-16T18:11:36Z,Could you add an option to parse_config_file to not throw when the file can't be opened?,olafvdspek@…
5654,Example parse_config_file missing template parameter,program_options,Boost 1.46.1,Boost 1.48.0,Bugs,Vladimir Prus,new,2011-06-28T13:40:15Z,2012-08-12T20:33:54Z,"{{{
store(parse_config_file(""example.cfg"", desc), vm);
}}}
parse_config_file needs a template parameter in this case.

http://www.boost.org/doc/libs/1_46_1/doc/html/program_options/overview.html#id2218686",olafvdspek@…
5651,Improvements to to_[lower/upper]_copy,algorithm,Boost 1.46.1,To Be Determined,Patches,Marshall Clow,new,2011-06-28T11:40:12Z,2011-12-28T18:56:50Z,"to_[lower/upper]_copy implicitly deduces the return type from the input type unless you supply the output as a second parameter. This is not always possible, consider for example: const std::string example = to_lower_copy< std::string >(""foo"") + to_upper_copy< std::string >(""bar""); . To achieve the same we currently need to construct an additional unnecessary temporary which only purpose is to inform the algorithm of the return type. The attached case_conv.hpp introduces 1 new overload for each variant which shouldn't break any existing code. Discussion can be found at: http://lists.boost.org/Archives/boost/2011/06/183031.php .",sairony@…
5649,create_directories() fails with NTFS mounted volumes,filesystem,Boost 1.46.1,To Be Determined,Bugs,Beman Dawes,new,2011-06-28T09:49:49Z,2013-09-06T20:05:40Z,"When there is an NTFS mounted volume at some level in the path which is passed to `create_directories`. The function fails because of the first two checks:
{{{
#!div style=""font-size: 80%""
  {{{#!c++
  BOOST_FILESYSTEM_DECL
  bool create_directories(const path& p, system::error_code* ec)
  {
    if (p.empty() || exists(p))
    {
      if (!p.empty() && !is_directory(p))
      {
        ...throws/returns an error...
  }}}
}}}
For a mounted volume path p is not `empty`, it `exists`, but `is_directory(p)` fails. This happens because a mounted volume directory is reported by `status(p)` as `file_type::reparse_file`.

Probably `is_directory()` should be changed to accept existing NTFS mounted volumes as already existing directories along the path which is to be created.

Windows 7 64bit, Boost 1.46.1, filesystem v3, MSVC 9",Tomas Kazmar <tomash.kazmar@…>
5647,Should Wave filesystem_compatibility.hpp be absorbed into Filesystem?,filesystem,Boost 1.46.1,Boost 1.48.0,Bugs,Beman Dawes,new,2011-06-27T14:56:37Z,2011-06-27T14:56:37Z,"Should Wave filesystem_compatibility.hpp be absorbed into Filesystem?

If so, how?

* As a separate header?

* As changes to existing headers>",Beman Dawes
5646,Test needed for Boost libraries dependent on Filesystem,filesystem,Boost 1.46.1,To Be Determined,Feature Requests,Beman Dawes,new,2011-06-27T14:36:56Z,2011-06-27T14:36:56Z,"A (local) test script needs to be developed that tests Boost libraries that are dependent on Filesystem both before and after a set of changes, and reports any differences in outcome.

Although the immediate motivation is to better test that Boost.Filesystem changes do not break Boost libraries dependent on Filesystem, such a script would be useful for other libraries. Thus it should not be specific to Boost.Filesystem.",Beman Dawes
5640,serialization vector backward compatibility problem,serialization,Boost 1.46.1,To Be Determined,Bugs,Robert Ramey,new,2011-06-24T21:17:06Z,2012-02-07T17:38:25Z,"We've recently upgraded from 1.40.0 to 1.46.1 and uncovered the following problem with vector serialization.

In 1.40.0, the code to load a vector is:

{{{
#ifndef BOOST_SERIALIZATION_VECTOR_VERSION
#define BOOST_SERIALIZATION_VECTOR_VERSION 4
#endif
...
template<class Archive, class U, class Allocator>
inline void load(
    Archive & ar,
    std::vector<U, Allocator> &t,
    const unsigned int /* file_version */,
    mpl::true_
){
    collection_size_type count(t.size());
    ar >> BOOST_SERIALIZATION_NVP(count);
    t.resize(count);
    unsigned int item_version=0;
    if(BOOST_SERIALIZATION_VECTOR_VERSION < ar.get_library_version())
        ar >> BOOST_SERIALIZATION_NVP(item_version);
    if (!t.empty())
        ar >> make_array(detail::get_data(t),t.size());
  }
}}}

In 1.46.1, the same method is

{{{
#ifndef BOOST_SERIALIZATION_VECTOR_VERSIONED
#define BOOST_SERIALIZATION_VECTOR_VERSIONED(V) (V==4 || V==5)
#endif
...
template<class Archive, class U, class Allocator>
inline void load(
    Archive & ar,
    std::vector<U, Allocator> &t,
    const unsigned int /* file_version */,
    mpl::true_
){
    collection_size_type count(t.size());
    ar >> BOOST_SERIALIZATION_NVP(count);
    t.resize(count);
    unsigned int item_version=0;
    if(BOOST_SERIALIZATION_VECTOR_VERSIONED(ar.get_library_version())) {
        ar >> BOOST_SERIALIZATION_NVP(item_version);
    }
    if (!t.empty())
        ar >> make_array(detail::get_data(t),t.size());
  }
}}}

Look at the difference when reading in a vector from serialization library version 4.  In 1.40.0, the logic assumes that versions greater than 4 should read in item_version.  In 1.46.1, the logic assumes that versions equal to 4 or 5 should read in item_version.  So, if restoring a file saved with version 4, 1.40.0 will not ready in item_version but 1.46.1 will.

We are working around this issue with a trick similar to the header vector_135.hpp, but would like to see this fixed in an upcoming release.

After some research, I found this change was made with changeset 55415 for ticket 2271.
",jfaust@…
5638,greg_month::get_month_map_ptr is not thread safe,date_time,Boost 1.46.1,To Be Determined,Bugs,az_sw_dude,assigned,2011-06-24T08:06:03Z,2015-03-17T16:16:58Z,"We recently have found a crash issue related to this function in greg_month.cpp. 

the block from line 39 is not thread safe. If multiple threads call this function simultaneously, it will lead to a crash. As one thread is  populating the map while the other thread may start using the map, or even worse two threads populate the map at the same time. ",fatbone <fatbone@…>
5637,use of mpl::print imposes default constructible requirement on argument,mpl,Boost 1.46.1,To Be Determined,Tasks,Aleksey Gurtovoy,new,2011-06-24T01:00:34Z,2015-09-15T14:44:48Z,"I'm using the following to debug some TMP code that looks like the following.
{{{
#include <boost/mpl/print.hpp>
struct X {
    X(int);
};

boost::mpl::print< 
    X 
>::type x;

boost::mpl::print< 
    X 
>::type y;
}}}

I get an error message that the type X is not default constructible.  A little investigation yields the definition of mpl::print (simplified for exposition)

{{{
template <class T>
struct print : identity<T>
{
    enum { n = sizeof(T) + -1 };
};
}}}

So invoking the print creates an instance with the default constructor
which provokes the error in this case.  For my purposes, I made the following change which seems to address the problem:

{{{
template <class T>
struct print : identity<T *>
{
    enum { n = sizeof(T) + -1 };
};
}}}

I'm using MSVC 9.0.

A couple of misceleanous issues besides this:

On my current version of GCC - 4.3.4 I get no warning at all.

If the same type is printed more than once, I only get the warning on the first instance.  

Robert Ramey

",Robert Ramey
5636,BGL isomorphism vertex invariant interface change,graph,Boost 1.46.1,To Be Determined,Feature Requests,Jeremiah Willcock,assigned,2011-06-23T22:48:35Z,2011-07-29T02:26:06Z,"(This is the last isomorphism ticket I think. :-))

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

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

(The benefit of this would be it becomes easier to impose extra conditions on the isomorphism. Instead of figuring out how to encode everything into an integer -- and worrying about the fact that you make an array of size `vertex_max_invariant`, so you can't even use all that much of that size -- you can just test it directly.)",Evan Driscoll <driscoll@…>
5634,BGL isomorphism edge invariants,graph,Boost 1.46.1,To Be Determined,Feature Requests,Andrew Sutton,new,2011-06-23T22:19:14Z,2012-08-22T20:38:06Z,"Can you add a feature that would allow the user to specify edge invariants in a similar way to how it is presently possible to specify vertex invariants? (I.e. an isomorphism is only considered if some functor says that two edges are somehow equivalent.)

The motivation for this is I'd like to test isomorphism between finite automata from another library, for testing purposes. I'm considering converting the transition graph to a BGL graph and using the isomorphism function, but I'm not sure that's possible as I can't require that corresponding edges are labeled with the same symbol.

(In the meantime I think I may know where to slip it into the code, so I may make my own copy of invariant.hpp and make that change. If I can get it to seemingly work, I'll report back with the patch.)

Alternately, it may be possible with something I'm missing; I'm a newbie to the BGL. But I don't know where it'd show up.",Evan Driscoll <driscoll@…>
5629,base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator,serialization,Boost 1.45.0,To Be Determined,Bugs,Robert Ramey,assigned,2011-06-22T13:29:41Z,2014-02-19T21:27:41Z,"MSVS 2008
The code:
{{{
#include ""boost/archive/iterators/base64_from_binary.hpp""
#include ""boost/archive/iterators/binary_from_base64.hpp""
#include ""boost/archive/iterators/transform_width.hpp""

//typedefs
typedef  std::istreambuf_iterator<char>    my_istream_iterator;
typedef  std::ostreambuf_iterator<char>    my_ostream_iterator;

typedef boost::archive::iterators::base64_from_binary<
          boost::archive::iterators::transform_width< my_istream_iterator, 6, 8>
> bin_to_base64;

typedef boost::archive::iterators::transform_width<
    boost::archive::iterators::binary_from_base64< my_istream_iterator >, 8, 6
> base64_to_bin;

void test()
{
   {
        //INPUT FILE!!!
    std::ifstream ifs(""test.zip"", std::ios_base::in|std::ios_base::binary);
    std::ofstream ofs(""test.arc"", std::ios_base::out|std::ios_base::binary);

    std::copy(
        bin_to_base64( my_istream_iterator(ifs >> std::noskipws) ),
        bin_to_base64( my_istream_iterator() ),
        my_ostream_iterator(ofs)
    );
  }

  {
    std::ifstream ifs(""test.arc"", std::ios_base::in|std::ios_base::binary);
    std::ofstream ofs(""test.rez"", std::ios_base::out|std::ios_base::binary);

    std::copy(
        base64_to_bin( my_istream_iterator(ifs >> std::noskipws) ),
        base64_to_bin( my_istream_iterator() ),
        my_ostream_iterator(ofs)
    );
  }
}
}}}

Result:
1) If the INPUT FILE will be any of ZIP-file format. The result was:
   a) _DEBUG_ERROR(""istreambuf_iterator is not dereferencable""); //it can be disabled or ignored
   b) The encoded file ""test.rez"" will have one superfluous byte than INPUT FILE

2) If the INPUT FILE will any other file (binary or text) all will be OK.
",nen777w@…
5625,sp_counted_base implementation using boost.atomic,smart_ptr,,To Be Determined,Patches,Peter Dimov,new,2011-06-21T14:21:29Z,2011-06-21T14:21:29Z,"I've had this code hanging around waiting for Boost.Atomic to make some progress towards submission, review and acceptance.  When that happens, or when people have some other C++0x atomics library, this uses it to implement sp_counted_base in a nice simple fashion without the need for all the current platform-specific code.  For now, perhaps it might be useful to a few people who are using the out-of-tree Boost.Atomic.
",Phil Endecott
5623,property tree bug,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-06-21T12:55:38Z,2015-01-21T13:13:18Z,"If the xml contains Chinese characters, rapidxml can not be resolved correctly, the problem is rapidxml the ""get_index"",
 Revised ""static_cast <unsigned char> (ch)"" can solve this problem",chenlitao1@…
5621,Adding custom allocator support in Boost file-system,filesystem,Boost 1.46.1,To Be Determined,Feature Requests,Beman Dawes,new,2011-06-20T06:49:38Z,2011-06-20T06:49:38Z,Please provide the custom allocator support for the string inside the Boost File-system.,gokul007@…
5619,zlib: Add support for additional flush mode,iostreams,Boost Development Trunk,To Be Determined,Feature Requests,Jonathan Turkanis,new,2011-06-18T07:15:11Z,2011-06-18T07:15:11Z,"The zlib filter uses Z_SYNC_FLUSH which is the most widely used flush mode. However SSH requires Z_PARTIAL_FLUSH. For further information please see the ""Partial Flush"" paragraph at: www.bolet.org/~pornin/deflate-flush.html

It would be trivial to add the new flush mode:[[BR]]

'''File: zlib.hpp'''[[BR]]

Add [[BR]]
BOOST_IOSTREAMS_DECL extern const int partial_flush;[[BR]]

Add additional argument to zlib_params:[[BR]]

 zlib_params( [[BR]]

    int flush_mode = zlib::default_flush_mode[[BR]]


add int flush_mode_ member to zlib_base[[BR]]


init flush_mode_ member in zlib_base::do_init[[BR]]

flush_mode_ = p.flush_mode;[[BR]]


and in the filter function change the xinflate to:[[BR]]

    int result = xinflate(flush_mode_);[[BR]]


'''File: zlib.cpp'''[[BR]]

const int partial_flush  = Z_PARTIAL_FLUSH;[[BR]]

const int default_flush_mode  = sync_flush;[[BR]]

[[BR]]

Please let me know if there is an interest for the diff files.",mb@…
5616,No output when using a filtering_ostream pointer,iostreams,Boost 1.46.1,To Be Determined,Bugs,Jonathan Turkanis,new,2011-06-16T18:35:32Z,2011-06-16T18:35:32Z,"When creating a filtering_ostream on the heap, the output is empty.

Following code works:
	
{{{
	boost::regex pattern(""..."");
	boost::iostreams::regex_filter filter(pattern,""..."");
	boost::iostreams::filtering_ostream out;
	out.push(filter);
	out.push(std::cout);
	out<<""I am written to std::cout""<<endl;
}}}


However, following code does not. Nothing is printed on the standard output:

{{{
	boost::regex pattern(""..."");
	boost::iostreams::regex_filter filter(pattern,""..."");
	boost::iostreams::filtering_ostream &out = *new boost::iostreams::filtering_ostream();
	out.push(filter);
	out.push(std::cout);
	out<<""I am not written to std::cout!""<<endl;
}}}


",anonymous
5611,bjam: define the right OS name on Hurd,xpressive,Boost.Build-M3,Website 1.X,Library Submissions,Eric Niebler,new,2011-06-16T01:55:31Z,2014-07-15T23:08:21Z,"Report from Pino Toscano (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630652):

Currently bjam does not identify Hurd when using e.g. os.name in jam scripts:
{{{
  $ bjam -v | head -n1
  Boost.Jam  Version 3.1.19. OS=UNKNOWN.
}}}

The attached patch (which should be suitable for upstream inclusion) sets the
correct #define's for Hurd in bjam, adding also the path detection for the
bjam test suite.
{{{
  $ bjam -v | head -n1
  Boost.Jam  Version 3.1.19. OS=HURD.
}}}
",smr@…
5609,Failed to build Boost.Jam with toolset pathscale,Building Boost,Boost 1.46.1,To Be Determined,Bugs,,new,2011-06-14T11:48:02Z,2011-07-02T20:37:52Z,"Hi, since PathScale released their compiler (4.0.10) to the open source community, I wanted to give it a try and aimed at compiling boost. Unfortunately, the bootstrap step fails.

$ pathcc --version

PathScale (tm) Compiler Suite: Version 4.0.10
Built on: 
Thread model: posix
GNU gcc version  (PathScale 4.0.10 driver)

Copyright PathScale Inc and others.  All Rights Reserved.
You can find complete copyright, patent and legal notices in the corresponding documentation.
",anonymous
5606,"Graph depends on xpressive, but xpressive doesn't work with Sun's compiler",graph,Boost 1.46.1,To Be Determined,Bugs,Andrew Sutton,new,2011-06-12T22:38:31Z,2012-04-16T19:11:12Z,"Graph depends on a library does not work with Sun's compiler. The people from xpressive have declared that they will not attempt to fix the problem. Therefore, the Boost build will forever fail when the sun tool set is used, because graph depends on xpressive.

It seems like the rational thing to do would be for graph to realize that attempting to build with Sun's compiler was not going to work, and for it to remove itself from the Boost build automatically with a warning.

At the very least, this extremely predictable failure should be documented, especially since it is going to occur from now until the end of time.

This behavior has occurred since Boost version 1.44.",willchido@…
5602,MPI-autodetection on Windows does not work with openmpi,Building Boost,Boost 1.46.1,To Be Determined,Bugs,doug_gregor,new,2011-06-11T17:32:39Z,2011-06-11T18:45:22Z,"The mpi.jam file has no if test for the openmpi implementation.

openmpi supports the mpic++ wrapper compiler and all the options to print the flags and library paths where the libraries to link against are.

I have tried but failed to change the mpi.jam script to recognize the openmpi installation.

A proper fix is welcome but indications on how to tweak the .jam file are appreciated,",finjulhich@…
5598,boost/property_tree/detail/json_parser_write.hpp:35: warning: comparison is always true due to limited range of data type,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-06-07T17:11:38Z,2017-07-04T03:44:34Z,"Here is the relevant output:
{{{
cc1plus: warnings being treated as errors
gcc41_64/include/boost/property_tree/detail/json_parser_write.hpp: In function 'std::basic_string<_CharT, std::char_traits<_CharT>, std::allocator<_CharT> > boost::property_tree::json_parser::create_escapes(const std::basic_string<_CharT, std::char_traits<_CharT>, std::allocator<_CharT> >&) [with Ch = char]':
gcc41_64/include/boost/property_tree/detail/json_parser_write.hpp:78:   instantiated from 'void boost::property_tree::json_parser::write_json_helper(std::basic_ostream<typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, const Ptree&, int, bool) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >]'
gcc41_64/include/boost/property_tree/detail/json_parser_write.hpp:162:   instantiated from 'void boost::property_tree::json_parser::write_json_internal(std::basic_ostream<typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, const Ptree&, const std::string&, bool) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >]'
gcc41_64/include/boost/property_tree/json_parser.hpp:98:   instantiated from 'void boost::property_tree::json_parser::write_json(std::basic_ostream<typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type::value_type> >&, const Ptree&, bool) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >]'
json.cc:36:   instantiated from here
gcc41_64/include/boost/property_tree/detail/json_parser_write.hpp:35: warning: comparison is always true due to limited range of data type
make: *** [json.o] Error 1
}}}

In the big if() statement, *b (of type Ch, which is char) is being compared with 0xFF.",benoit@…
5595,Windows: Cannot write to files which have been mapped to memory in other threads/processes,iostreams,Boost 1.43.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-06-06T10:01:54Z,2017-09-21T14:00:45Z,"Windows:
If I try to open a file for writing which has been memory mapped by using boost::iostreams::mapped_file_source, I get an ""Permission denied"".

Under Linux (e.g. Ubuntu, openSUSE) there is no problem.

The cause of this behavior seems to be, that mapped_file_impl::open_file uses CreateFile WIN32 API with the parameter FILE_SHARE_READ instead of FILE_SHARE_WRITE.

Is this supposed to be like this?
",Armin Pies <armin.pies@…>
5591,Inherited attributes and copy() function,spirit,Boost 1.46.1,To Be Determined,Bugs,Joel de Guzman,new,2011-06-03T06:00:13Z,2013-04-16T06:45:24Z,"rule::copy() and rule::alias() functions doesn't work when used on rules with inherited
attributes.

  using namespace boost::spirit::qi;
 
  typedef std::string::iterator iter;
 
  rule<iter, int()> a;
  rule<iter, int()> a_cp;
  a_cp = a;           //compiles       
  a_cp = a.copy();    //compiles
  a_cp = a.alias();   //compiles
 
  rule<iter, int(int)> b;
  rule<iter, int(int)> b_cp;
  b_cp = b;           //compiles
  b_cp = b.copy();    //fails to compile
  b_cp = b.alias();   //fails to compile",Öyvind Strand <oyvind.strand@…>
5588,property_tree INFO include directive,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-06-01T20:40:29Z,2011-12-01T23:02:43Z,"When you use #include in C/C++ programs, preprocessor uses path relative to file, where you used '#include'. But in read_info realization '#include' finds file using path, relative to current work directory. So, when you create some complex config structure, you have to you absolute pathes or change current work directory to config file.",sarum9in@…
5584,gzip_decompressor sometimes truncates data,iostreams,Boost 1.41.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-05-31T18:57:14Z,2011-10-16T18:21:49Z,"Th following trivial sample program `boost_gunzip.cc` only decompresses files partially.  This issue only appears for a minority of the files.
{{{
#include <boost/iostreams/device/file.hpp>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/filter/gzip.hpp>

#include <iostream>
#include <ios>

int main(int argc, const char *argv[]) {
    if (argc != 2) {
        std::cerr << ""need exactly one argument"" << std::endl;
        return 1;
    }

    boost::iostreams::filtering_istream in;
    in.push(boost::iostreams::gzip_decompressor());
    in.push(boost::iostreams::file_source(argv[1],
      std::ios_base::in | std::ios_base::binary));

    while (in.good()) {
        char c = in.get();
        if (in.good()) std::cout << c;
    }
};
}}}

In the following example, `gzip_decompressor` misses 113 bytes:
{{{
~$ cat <(for i in `seq 0 100`; do echo 'Mon May 30 23:17:43 EDT 2011'; done) > /tmp/a
~$ md5sum /tmp/a
040fce9cef21c343fd9ab2aecf1515e3  /tmp/a
~$ wc -c /tmp/a
2929 /tmp/a
~$ gzip /tmp/a
~$ md5sum /tmp/a.gz
46bd5683f86075e30124c5a6a1d2f83d  /tmp/a.gz

~$ zcat /tmp/a.gz | wc -c
2929
~$ ./boost_gunzip /tmp/a.gz | wc -c
2816
}}}

This is on a RHEL 6.1 64bit system, i.e., using `boost-iostreams-1.41.0-11.el6.x86_64`.
",Hans-Andreas Engel <engel@…>
5579,1_40_0 serialization break.,serialization,Boost 1.46.1,To Be Determined,Bugs,Robert Ramey,new,2011-05-29T16:42:42Z,2013-03-13T21:41:07Z,"If you compare 1_39 and 1_40 here, you can see one 1_39 compares the addresses of functions to get type information. Which in 1_40 was 'fixed' so that types across DLL's would be matched.

However this of course breaks archive compatibility with 1_39 as the two dll's will have serialized out the CO info twice, and now in 1_40 and beyond it'll only try to read it once.. Leaving the file corrupted.

http://www.boost.org/doc/libs/1_39_0/boost/archive/detail/basic_serializer.hpp
http://www.boost.org/doc/libs/1_40_0/boost/archive/detail/basic_serializer.hpp

I'm not even sure how this can be fixed short of storing a flag to determine how cobject's compare thats based on archive version where the comparison starts... 
",Phil Hartmann <phil.hartmann82@…>
5567,boost serialization 1_46_1 incompatible with prior versions due to backwards comparison,serialization,Boost 1.46.1,Boost 1.47.0,Bugs,Robert Ramey,new,2011-05-26T11:33:41Z,2013-11-09T08:24:11Z,"Archive's writing class_id_type between 1_41 <and prior> and being read back in 1_46 will fail.

basic_binary_iarchive.hpp line 104 in 1_46 is ""if(boost::archive::library_version_type(6) < lvt){""

Or 6 < lvt which is lvt >= 7, and because the if before it is 7 < lvt, its essentially lvt == 7. 

So if the version is 7 serialize in a 16 bit integer, else versions 1 through 6 serialize in a 32 bit integer.

The problem here is this is backwards. Version 1-6 are 16 bit, 7 might have been 32bit (because of issues in 1_42/1_43). 

The code needs to be swapped (assuming consistency throughout the file is to remain). 


tracking_type also appears to have the same issue (although it seems to be ok)

version_type I don't get at all, going back through the basic_binary_iarchive.hpp's I don't see how the code is right at all. Anything less than version 7 should be serializing a 8 bit int from what I can tell. 


Prior versions can be viewed at:
http://www.boost.org/doc/libs/1_44_0/libs/serialization/src/basic_archive.cpp
http://www.boost.org/doc/libs/1_41_0/libs/serialization/src/basic_archive.cpp
http://www.boost.org/doc/libs/1_40_0/libs/serialization/src/basic_archive.cpp
...

Library versions can be viewed at:
http://www.boost.org/doc/libs/1_44_0/boost/archive/basic_binary_iarchive.hpp
http://www.boost.org/doc/libs/1_41_0/boost/archive/basic_binary_iarchive.hpp
http://www.boost.org/doc/libs/1_40_0/boost/archive/basic_binary_iarchive.hpp
...

Side Note:
IMHO writing code such as 6 < lvt is extremely unintuitive and backwards of how most people think.",Phil Hartmann <phil.hartmann82@…>
5558,Phoenix bind doesn't support bind<type> construct,phoenix,Boost 1.46.1,To Be Determined,Bugs,Thomas Heller,assigned,2011-05-23T15:37:50Z,2016-05-09T14:07:41Z,"boost::bind uses bind<type> in situations where it cannot determine the return type. This is useful for situations where you are binding to a method with a variable argument list such as printf.

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

Using boost::bind --

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

Using phoenix::bind --

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

results in compilation error.

",Michael Caisse
5555,wave slex parser identifier + ? adds extra ? to identifier token value,wave,Boost 1.46.1,To Be Determined,Bugs,Hartmut Kaiser,new,2011-05-20T00:48:05Z,2011-05-20T00:48:05Z,Running cpp_tokens on the attached file produces an invalid token for the 'z' identifier.,József Mihalicza <jmihalicza@…>
5545,ptr_container: unused parameter warnings if exceptions and asserts disabled,ptr_container,Boost 1.39.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-05-16T12:02:38Z,2011-05-16T12:02:38Z,"With exceptions and asserts both disabled, `ptr_container_detail::reversible_ptr_container<>::enforce_null_policy()` generates unused-parameter warnings. Both its parameters are used only within an invocation of `BOOST_PTR_CONTAINER_THROW_EXCEPTION()`; with exceptions disabled, that expands to a `BOOST_ASSERT()`; with asserts disabled, that in turn becomes just `(void)0` (or equivalent).

One way to fix this would be to make `BOOST_PTR_CONTAINER_THROW_EXCEPTION` expand to `BOOST_VERIFY` instead of `BOOST_ASSERT`, so that the parameters are still evaluated even when exceptions and asserts are disabled. This should make no difference when exceptions are enabled, or when exceptions are disabled but asserts are enabled.

Minimal example:

{{{
$ cat test.cpp
#include <boost/ptr_container/ptr_vector.hpp>

void foo(int *p)
{
    boost::ptr_vector<int>().push_back(p);
}
$ g++ -W -Wall -fno-exceptions -Iboost -DNDEBUG -c test.cpp
In file included from boost/boost/ptr_container/ptr_sequence_adapter.hpp:20,
                 from boost/boost/ptr_container/ptr_vector.hpp:20,
                 from test.cpp:1:
boost/boost/ptr_container/detail/reversible_ptr_container.hpp: In instantiation of 'static void boost::ptr_container_detail::reversible_ptr_container<Config, CloneAllocator>::enforce_null_policy(const typename Config::value_type*, const char*) [with Config = boost::ptr_container_detail::sequence_config<int, std::vector<void*, std::allocator<void*> > >, CloneAllocator = boost::heap_clone_allocator]':
boost/boost/ptr_container/ptr_sequence_adapter.hpp:246:   instantiated from 'void boost::ptr_sequence_adapter<T, VoidPtrSeq, CloneAllocator>::push_back(typename boost::ptr_container_detail::reversible_ptr_container<boost::ptr_container_detail::sequence_config<T, VoidPtrSeq>, CloneAllocator>::value_type) [with T = int, VoidPtrSeq = std::vector<void*, std::allocator<void*> >, CloneAllocator = boost::heap_clone_allocator]'
test.cpp:5:   instantiated from here
boost/boost/ptr_container/detail/reversible_ptr_container.hpp:260: warning: unused parameter 'x'
boost/boost/ptr_container/detail/reversible_ptr_container.hpp:260: warning: unused parameter 'msg'
}}}

(g++ will not emit the warnings if the boost headers are found in the system include directories.)",timb@…
5541,Partial function application,phoenix,Boost Development Trunk,To Be Determined,Feature Requests,Thomas Heller,new,2011-05-13T10:35:10Z,2011-05-16T14:32:26Z,"In functional languages, it's common to partially apply a function to some arguments in order to produce a function accepting only the remaining arguments.

This can be approximated in C++ through use of our bind and its placeholders, but this requires knowledge of the number of placeholders to use to match the number of remaining parameters.

Is it possible to construct Phoenix functions that when invoked with fewer arguments than its arity indicates will produce a function taking the remaining arguments?",Lars Viklund <zao@…>
5538,boost.mpi miscompiles with gcc4.6 and option -std=c++0x,mpi,Boost 1.46.1,To Be Determined,Bugs,Matthias Troyer,new,2011-05-13T08:24:36Z,2013-01-01T11:43:46Z,"Hello

boost.mpi with gcc-4.6 and the option -std=c++0x don't get well together
here is a very simple example

----- t.cpp
#include <boost/mpi.hpp>
------ end of t.cpp

 the issue arises with the use of the -std=c++0x flag to use
the new c++ standard. It use to work properly with previous g++ version

compile without -std=c++0x
g++ -I/usr/include/mpi  -c t.cpp
no errors

try compiling with -std=c++0x
 g++ -I/usr/include/mpi -std=c++0x -c t.cpp

                                              2011-05-12 22:40:17
prudhomm pts/28
In file included from /usr/include/c++/4.6/memory:67:0,
                from /usr/include/boost/mpi/allocator.hpp:18,
                from /usr/include/boost/mpi.hpp:22,
                from t.cpp:3:
/usr/include/c++/4.6/bits/stl_uninitialized.h: In function ‘void
std::__uninitialized_default_n_a(_ForwardIterator, _Size, _Allocator&)
[with _ForwardIterator = char*, _Size = long unsigned int, _Allocator
= boost::mpi::allocator<char>]’:
/usr/include/c++/4.6/bits/vector.tcc:474:8:   instantiated from ‘void
std::vector<_Tp, _Alloc>::_M_default_append(std::vector<_Tp,
_Alloc>::size_type) [with _Tp = char, _Alloc =
boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type =
long unsigned int]’
/usr/include/c++/4.6/bits/stl_vector.h:592:4:   instantiated from
‘void std::vector<_Tp, _Alloc>::resize(std::vector<_Tp,
_Alloc>::size_type) [with _Tp = char, _Alloc =
boost::mpi::allocator<char>, std::vector<_Tp, _Alloc>::size_type =
long unsigned int]’
/usr/include/boost/mpi/detail/packed_oprimitive.hpp:96:46:
instantiated from here
/usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: error: no
matching function for call to
‘boost::mpi::allocator<char>::construct(char*)’
/usr/include/c++/4.6/bits/stl_uninitialized.h:576:6: note: candidate is:
/usr/include/boost/mpi/allocator.hpp:168:8: note: void
boost::mpi::allocator<T>::construct(boost::mpi::allocator<T>::pointer,
const T&) [with T = char, boost::mpi::allocator<T>::pointer = char*]
/usr/include/boost/mpi/allocator.hpp:168:8: note:   candidate expects
2 arguments, 1 provided
",christophe.prudhomme@…
5532,qt4 MOCCABLE_H 's target type is wrong,build,Boost 1.46.1,To Be Determined,Bugs,Vladimir Prus,new,2011-05-12T10:30:32Z,2011-10-16T18:29:10Z,"At qt4.jam:224 , which reads 

        generators.register [ new moc-inc-generator
            qt4.moc.inc : MOCCABLE_H : OBJ : <allow>qt4 ] ;
has a wrong target type OBJ.It should be CPP.
When I use moccable_h like this the compiler will ignore the generated cpp source:
exe my-project : [ cast _ moccable-h : xxx.h ] main.cpp  ;",manjian2006@…
5531,MPI-autodetection on Windows does not support MS-MPI v2,mpi,Boost 1.46.1,To Be Determined,Bugs,Douglas Gregor,new,2011-05-11T19:38:12Z,2012-02-03T18:09:07Z,"Hi there. MPI-autodetection (in mpi.jam) on Windows only looks for MS-MPI v1 (to be found in ""C:\\Program Files\\Microsoft Compute Cluster Pack"", as the product v1 was named Compute Cluster Pack), it overlooks MS-MPI v1 (to be found in ""C:\\Program Files\\Microsoft HPC Pack 2008 SDK"" or ""C:\\Program Files\\Microsoft HPC Pack 2008 R2 SDK"").

Simple workaround: Extend mpi.jam to search in all three paths (as in the one attached). Actually, this is the behavior I would like to see by default).


Kind regards, Christian.",Christian Terboven <christian@…>
5525,Flushing problem with gzip and filtering_wostreambuf,iostreams,Boost 1.46.1,To Be Determined,Bugs,Jonathan Turkanis,new,2011-05-06T21:02:42Z,2011-05-06T21:02:42Z,"I have attached a small example which produces a invalid gz file on both windows 64 bit and linux 32 bit (most likely others, but not testet). The code worked with previous versions of boost.",jensen.bo@…
5524,Ptree walk_path can fail to locate desired path,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-05-06T15:56:33Z,2011-05-06T15:56:33Z,"Take a situation with child structure as follows:[[BR]]
a.b[[BR]]
a.b.c

If get_child is used and it calls walk_path to navigate this to locate a.b.c it will fail with an exception. I'd argue it should explore other children (besides only 1st) if present before giving up and throwing the exception. In that case the recursion pops from the 1st 'b' and also tries the 2nd 'b' path (or any other 'b') and then finds a match on 'c' which is returned. Currently have to manually walk the XML represented tree and never use the path accessors because of this issue.",anonymous
5517,ptr_map::replace with key,ptr_container,Boost 1.46.1,To Be Determined,Feature Requests,Thorsten Ottosen,new,2011-05-04T14:03:51Z,2011-05-04T14:03:51Z,"Could you add a ptr_map::replace() variant that takes a key?
This is handy when you want to replace a value that might or might not exist.",olafvdspek@…
5512,jam0.exe is not a valid win32 application,Building Boost,Boost 1.44.0,To Be Determined,Bugs,,new,2011-04-29T18:10:31Z,2011-04-29T18:10:31Z,"hi,

My OS is windows XP. i installed VS 2008 ,VS90SP1-KB957912-x86.exe
,VS90SP1-KB960075-v2-x86.exe,VS90SP1-KB967631-x86.exe,VS90SP1-KB971092-x86.exe,VS90sp1-KB945140-ENU.exe and then installed windows7 sdk.

but when i try to build boost library , then error came like this : jam0.exe is not a valid win32 application

bjam.log file


###
### Using 'vc9' toolset.
###

E:\boost\boost_1_44_0\tools\jam\src>if exist bootstrap rd /S /Q bootstrap 

E:\boost\boost_1_44_0\tools\jam\src>md bootstrap 

E:\boost\boost_1_44_0\tools\jam\src>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0  command.c compile.c debug.c execnt.c expand.c filent.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.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 pwd.c class.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
debug.c
execnt.c
expand.c
filent.c
glob.c
hash.c
hdrmacro.c
headers.c
jam.c
jambase.c
jamgram.c
lists.c
make.c
make1.c
newstr.c
option.c
output.c
parse.c
Generating Code...
Compiling...
pathunix.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
pwd.c
class.c
w32_getreg.c
native.c
set.c
path.c
regex.c
Generating Code...
Compiling...
property-set.c
sequence.c
order.c
Generating Code...

E:\boost\boost_1_44_0\tools\jam\src>.\bootstrap\jam0 -f build.jam --toolset=vc9 ""--toolset-root=C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\..\..\VC\ "" clean 

E:\boost\boost_1_44_0\tools\jam\src>.\bootstrap\jam0 -f build.jam --toolset=vc9 ""--toolset-root=C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\..\..\VC\ ""  
",sharifr2002@…
5511,Documentation needs some improvement,circular_buffer,Boost 1.46.1,To Be Determined,Feature Requests,No-Maintainer,new,2011-04-28T23:17:15Z,2013-10-24T21:33:59Z,"Basically the whole library is quite good.  But I have a couple of minor complaints.

a) The documentation contains sentences like:


{{{
""iterator begin();

Get the iterator pointing to the beginning of the circular_buffer. 
}}}

I ''think'' the refers to the current front of the queue - where ever that falls in the underlying storage.  This I could use this iterator to iterate from the oldest item to the most recent item.  Naturally the value returned by this function call would change as items are popped of the queue.  But it could also refer to the begin (and end) of underlying storage.  I don't think it does this - but it's not clear from the documentation.

b) I would also like to have a constructor which allows me to pass any pair of random access iterators (ie. a range) and have the circular buffer use that rather than allocating it's own storage.  This would make the package more useful to me and i would hope others as well.

Robert Ramey
",Robert Ramey
5500,memory leak in async_write,asio,Boost 1.45.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-04-25T08:37:06Z,2011-04-25T08:37:06Z,"First, call the function ""async_write"", when the callback function ""HandleWriteRequest"" is called, Then, close the socket.

Repeat the above operation, the memory will continue to increase.

In the attachment, you will see the demo.
This program is running in the windows, the IDE is Microsoft visual studio 2008.
Boost version is 1.45.0

Best regards.",DengrongWu <jeffreywu@…>
5499,Serialization backward compatability,serialization,Boost 1.46.1,To Be Determined,Bugs,Robert Ramey,new,2011-04-24T08:01:19Z,2012-01-26T10:59:51Z,"Boost 1.33.1 serializes class_id_type as int_least16_t (archive version 3). Current boost tries to load it as int for archive of version 6 and earlier. On my platform (VS2005) int is 32 bits, hence the deserialization fails.

The attached code creates and successfully loads 'out.boost103301.dat' when compiling with boost 1.33.1 and crashes due to failed assert in class_id_type constructor when loading with boost 1.46.1.

I'm upgrading from 1.33.1 to boost 1.46.1 now, so I mark it as 'Showstopper'.
",ybungalobill@…
5498,Issues with the Interval Library,interval,Boost 1.46.0,Boost 1.46.0,Bugs,Boris Gubenko,new,2011-04-23T09:11:20Z,2015-11-03T21:50:32Z,"I am trying to compile some examples; in particular, the trigonometric, hyperbolic trig and transendental (exp, log!!)functions don't compile with default roudning policy (see file I included). It's a kind of show-stopper.

Some user requests as well are:

1. Instead of bool when comparing interval, use TriBool (a result can be _indeterminate_)

2. Interval is missing midpoint() (same as median()).

3. Interval analysis is highly specialised; more user examples would be very welcome.
I have the books by R.E. Moore but it takes some time to map his results to Interval.

best regards

Daniel


// Code

// TestInterval101.cpp
//
// Tests for Interval arithmetic.
//
// (C) Datasim Education BV 2009-2011

#include <boost/numeric/interval.hpp>


template<class T, class Policies>
std::ostream &operator<<(std::ostream &os,
                         const boost::numeric::interval<T, Policies> &x) {
  os << ""["" << x.lower() << "", "" << x.upper() << ""]"";
  return os;
}

typedef boost::numeric::interval<double> Range;



int main()
{

	using namespace boost::numeric;
 
	// Create and manipulate some numbers.
	Range r1(0.0, 1,0);

	Range r2(-10.0, 20.0); 
	Range r3(20.8, 44.9);

	double t = 2.0;
	r1 += t; r1 -= t; r1 *= t; r1 /= t;

	Range rTmp(2.0, 3.0);
	r1 += rTmp; r1 -= rTmp; r1 *= rTmp; r1 /= rTmp;

	// Numeric operations.
	Range r4 = r1 + r2;
	Range r5 = r1 - r2;
	Range r6 = r1 * r2;
	Range r7 = r1 / r2;

	// More numeric operations.
	t = 3.0;
	r4 = r1 + t;
	r5 = r1 - t;
	r6 = r1 * t;
	r7 = r1 / t;

	// Algebraic functions.
	r4 = abs(r1);
	r5 = sqrt(r2);
	r6 = square(r3);
	r7 = pow(r1, 2);	// r1^2
	Range r8 = nth_root(r1, 4);

	// NONE COMPILES
	// Transcendental functions
//	r4 = exp(r1); 
//	boost::numeric::interval<double, boost::numeric::interval_lib::default_policies<double> > myI;
//	myI = boost::numeric::exp(myI);
	//r5 = log(r2);

	// Trigonometric functions
/*	r4 = sin(r1);
	r5 = cos(r1);
	r6 = tan(r1);
	r7 = asin(r2);
	r7 = acos(r2);
	r7 = atan(r2);

	// Hyperbolic trigonometric functions
	r4 = sinh(r1);
	r5 = cosh(r1);
	r6 = tanh(r1);
	r7 = asinh(r2);
	r8 = acosh(r2);
	r6 = atanh(r2);*/


	

	return 0;
}
",dduffy@…
5496,Add API for detection of exception,exception,Boost 1.45.0,To Be Determined,Feature Requests,Emil Dotchevski,new,2011-04-22T12:34:20Z,2012-06-19T23:41:28Z,"Purpose: detect if it's possible to call boost::current_exception() when writing generic code.

Solution: add BOOST_CATCH_EXCEPTION() macro or boost::catch_exception() function and boost::has_current_exception() function.",anberlin.myplace@…
5492,property_treee : now requires locale,property_tree,Boost 1.46.1,To Be Determined,Bugs,Sebastian Redl,new,2011-04-20T10:24:29Z,2011-04-20T10:24:29Z,"basic_ptree requires std::locale and imbue.
locale not provide by special environment(ex : Windows CE).
Boost.Config has BOOST_NO_STD_LOCALE, and needs this workaround.",Akira Takahashi <faithandbrave@…>
5483,"value_init: Assignment to 'value_initialized', 'initialized' objects doesn't work automatically",utility,Boost 1.46.1,To Be Determined,Feature Requests,No-Maintainer,new,2011-04-16T03:25:30Z,2013-02-04T22:16:09Z,"Objects of the 'initialized<T>' class (and presumably 'value_initialized<T>' too) do not automatically convert to assignment lvalues and do not provide proper assignment operator methods either. Assignments therefore do not automatically work, for example, declaring 'initialized<int> i;' then writing 'i = 1;'.

Tested on Windows XP SP3 with MinGW g++ 4.4.1, as well as the (VS 2008) Visual C++ 9.0 compiler. Both compilers report that no match for operator= can be found in that assignment, and that the method 'initialized<int>& initialized<int>::operator=(initialized<int> const&)' is considered as 'candidate' that would fit with a conversion inbetween (from 'int' to 'initialized<int>'), but it's not being used. Conversion operators such as the one defined as 'initialized<int>::operator int&()' apparently do not automatically qualify for lvalues either.

Workarounds specify the necessary conversion or operator method, for example, 'i.operator int&() = 1;' and 'get(i) = 1;' both work.

The attached file contains some tests as well as a class implementing a simplified version of the interface of 'initialized<T>' with a fix. The file also contains the error message from g++. I omitted the one from Visual C++ (because I would have to translate it into English) but it essentially says the same.",Christian Masloch <cm@…>
5481,undesired warnings,tokenizer,Boost 1.45.0,To Be Determined,Bugs,jsiek,new,2011-04-16T01:18:10Z,2011-12-18T00:30:50Z,"Hi,

I am building a simple test program (see attachment test_thread.cpp) using Microsoft Visual Studio 2010 with /W4 and /WX options and I am getting errors (see attachment test_thread.err).

Yes, I could disable the specific warnings but I prefer that the library not generate such warnings.

Regards,

Leo
",Leo Carreon <lcarreon@…>
5479,Doxygen: Support for C++0x scoped enums,Documentation,Boost 1.46.1,To Be Determined,Feature Requests,Steven Watanabe,new,2011-04-15T16:20:36Z,2011-10-16T22:37:38Z,"While generating the doc with doxygen, scoped enums are not documented 

enum class {E1, E2, E3};
     ^^^^
gives

enum class {E1, E2, E3};

Could this be managed?",viboes
5477,xlC 6.0 - ptr_vector  error,ptr_container,Boost 1.40.0,To Be Determined,Bugs,Thorsten Ottosen,new,2011-04-15T11:39:19Z,2011-04-15T11:39:19Z,"Hi,

The attached testcase fails on xlC 6.0 but compiles well on xlC 9.0

xlC 6.0
% xlC -qversion
C for AIX version 6.0.0.0
% xlC -q64 -I../3rd_party/boost/1_40_0 boost_ptr_vec.cpp 
""boost_ptr_vec.cpp"", line 5.16: 1540-0198 (W) The omitted keyword ""private"" is assumed for base class ""boost::noncopyable"".
""../3rd_party/boost/1_40_0/boost/ptr_container/ptr_vector.hpp"", line 45.9: 1540-0400 (S) ""boost::ptr_vector::release"" has a conflicting declaration.
""../3rd_party/boost/1_40_0/boost/ptr_container/ptr_vector.hpp"", line 45.9: 1540-0425 (I) ""release"" is defined on line 45 of ""../3rd_party/boost/1_40_0/boost/ptr_container/ptr_vector.hpp"".

xlC 9.0:
% xlC -qversion
IBM XL C/C++ Enterprise Edition for AIX, V9.0
Version: 09.00.0000.0012
xlC -q64 -I/remote/sesnightly/p4/depot/cats/31/3rd_party/boost/1_40_0 boost_ptr_vec.cpp 
""boost_ptr_vec.cpp"", line 5.16: 1540-0198 (W) The omitted keyword ""private"" is assumed for base class ""boost::noncopyable"".

Is there any patch to make it work on xlC 6.0?

Thanks,
Radha",radha.nitt@…
5468,ASIO does not use the standard BOOST ABI mechanism,asio,Boost 1.46.1,To Be Determined,Bugs,chris_kohlhoff,new,2011-04-13T19:45:25Z,2011-04-18T06:36:39Z,"BOOST libraries should all use the ABI support that is built into boost.  For other boost libraries, in the boost/config/user.hpp you can point to your own header files where you can insert the #pragma pack statement.  ASIO does not use this mechanism, it has its own headers in asio/detail/push_options.hpp.",brian@…
5465,"MPI auto-detection failed: unknown wrapper compiler mpic++, please report",mpi,Boost 1.46.1,To Be Determined,Bugs,Douglas Gregor,new,2011-04-13T02:23:42Z,2018-06-05T15:39:24Z,"I added using mpi ; to user-config.jam.  I am using gcc.

C:\prj\boost\boost_1_46_1>set PATH=c:\mingw-w64-bin_i686-mingw_20110402\bin;c:\mingw-w32-bin_i686-mingw_20110402\bin;c:\mingw-w64-bi
n_i686-mingw_20110402\bin;c:\mingw-w32-bin_i686-mingw_20110402\bin;c:\mingw-w64-bin_i686-mingw_20110402\bin;c:\mingw-w32-bin_i686-mi
ngw_20110402\bin;c:\mingw-w64-bin_i686-mingw_20110402\bin;c:\mingw-w32-bin_i686-mingw_20110402\bin;c:\mingw-w64-bin_i686-mingw_20110
402\bin;c:\mingw-w32-bin_i686-mingw_20110402\bin;c:\prj\boost\boost_1_46_1\tools\build\v2\engine\src\bin.ntx86.debug;C:\gnuwin32\Get
GnuWin32\bin;C:\gnuwin32\GetGnuWin32\gnuwin32\sbin;C:\gnuwin32\GetGnuWin32\gnuwin32\bin;C:\Perl\site\bin;C:\Perl\bin;C:\WINDOWS\syst
em32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program Files\PHP\;C:\Program Files\PHP;c:\u;c:\x;c:\program files\7-zip;c:\bin;C:\Progr
am Files\Csound\bin;C:\Program Files\Common Files\Roxio Shared\9.0\DLLShared\;C:\Program Files\CMake 2.8\bin;C:\Program Files\Common
 Files\HP\Digital Imaging\bin;C:\Program Files\HP\Digital Imaging\bin\;C:\Program Files\HP\Digital Imaging\bin\Qt\Qt 4.3.3;C:\Progra
m Files\WinMerge;C:\Program Files\OpenAxiom\bin;C:\Program Files\Notepad++\;c:\tsepro

C:\prj\boost\boost_1_46_1>c:\prj\boost\boost_1_46_1\tools\build\v2\engine\src\bin.ntx86.debug\bjam.exe toolset=gcc address-model=64
stage clean --without-python --prefix=c:\prj\boost\boost64\
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
MPI auto-detection failed: unknown wrapper compiler mpic++
Please report this error to the Boost mailing list: http://www.boost.org
You will need to manually configure MPI support.
Performing configuration checks

    - has_icu builds           : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add ""using mpi ;"" to your user-config.jam
    - ../config//has_gcc_visibility builds : yes
    - ../config//has_long_double_support builds : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add ""using mpi ;"" to user-config.jam.
note: to suppress this message, pass ""--without-mpi"" to bjam.
note: otherwise, you can safely ignore this message.
warning: Unable to construct ./stage-unversioned
warning: Unable to construct ./stage-unversioned
...found 1 target...
...updating 1 target...
...updated 1 target...
",jmichae3@…
5454,different behavior to report one kind of errors,program_options,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-04-11T07:30:54Z,2011-04-11T07:30:54Z,"If 'configuration file' has option wich not presented in 'options_description', then 'parse_config_file' throws 'logic_error'.

If 'options_description' has option wich not presented in 'configuration file', then 'variablesMap[ ""option"" ].as<...>()' throws 'bad_cast'.

It's will be good to have one type of error reporting: exception from 'parse_config_file'.",anberlin.myplace@…
5452,boost::mpl::plus changes type,mpl,Boost 1.47.0,To Be Determined,Feature Requests,Joel Falcou,new,2011-04-10T21:35:08Z,2011-04-10T21:35:08Z,"The return type of boost::mpl::plus seems to be always integral_c
independent of the input types.

This is very unconvenient.


please make 


plus<long_<1>, long_<1> >::type

return 

long_<2>
",Peter Foelsche <foelsche@…>
5451,More slice adaptors,range,Boost 1.46.1,To Be Determined,Feature Requests,Neil Groves,new,2011-04-10T08:39:36Z,2011-04-10T08:39:36Z,"It would be very useful to have a slice adaptor which takes only a start index and returns a range running till the end of the orignal range.

A slice adaptor which can take negative indexes to mean a distance from the end could also be useful, but might require more overhead on constuction.
",Yechezkel Mett <ymett.on.boost@…>
5448,"Windows ""\\\\?\\"", ""\\\\?\\UNC\\"", and ""\\\\.\\"" path meta characters",filesystem,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-04-09T14:34:04Z,2011-04-10T02:00:38Z,"Windows treats ""\\\\?\\"", ""\\\\?\\UNC\\"", and ""\\\\.\\"" at the start of a path as meta characters signaling special handling of the remainder of the path. So, for example, ""\\\\?\\"" should be treated as an empty path!

See ""Naming Files, Paths, and Namespaces"", http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx

Ticket 5405 supplied a patch that allows class path to handle a portion of what this implies, but does not deal with the general problem.

A few test cases have been added to path_test.cpp, but they are currently commented out.",Beman Dawes
5446,"Exception thrown by tz_database::load_from_file() on linux 2.6.37, boost1.46.1,gcc4.5.2",date_time,Boost 1.46.1,To Be Determined,Bugs,az_sw_dude,new,2011-04-09T07:38:39Z,2015-11-20T15:13:57Z,"Hi, I tried to run the Flight Time Example in boost_1_46_1/doc/html/date_time/examples.html#date_time.examples.simple_time_zone, and an exception was thrown with error message:
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >'
  what():  bad lexical cast: source type value could not be interpreted as target
When I debug with step into, I found it happened on line ""Africa/Cairo"" of the date_time_zonespec.csv, because this is the first timezone which needs to call dst_adjustment_offsets(), and there was a '\r' at the end of the line, then when str_from_delimited_time_duration() called boost::lexical_cast<unsigned short>(*beg) the '\r' made the exception being raised. 
On linux, std::getline(ifs, buff) in load_from_file() will leave the '\r' in buff, which caused the exception. On win32 this would not happen. So the line ends '\r' needs to be removed in load_from_file() or at the beginning of parse_string().     ",frankrq2009@…
5443,Building multithreading (-mt) libs on Mac OS X 10.6,Getting Started Guide,Boost 1.47.0,To Be Determined,Support Requests,Dave Abrahams,new,2011-04-08T18:00:33Z,2011-04-09T23:24:00Z,"The docu (http://www.boost.org/doc/libs/1_46_1/more/getting_started/unix-variants.html) states that mutli-threading libs will have the ""-mt"" suffix, but I cannot get such libs to build on my Mac OS X 10.6 (Intel Core 2 Duo).  The build process seems to build multi-threaded libs because the directory it creates for itself is, for example:

/tmp/boost/bin.v2/libs/regex/build/darwin-4.2.1/release/threading-multi/

But the only resulting binary in that dir is libboost_regex.dylib.

Am I building the libs wrong, or is the docu wrong about the -mt suffix, or is this a Mac problem?",daniel@…
5442,Create CSR graph from GraphViz file,graph,Boost 1.42.0,To Be Determined,Feature Requests,Andrew Sutton,new,2011-04-08T15:40:57Z,2012-03-04T20:21:24Z,"From the 3 graph classes available so far in the BGL (adjacency_list, adjacency_matrix and compressed_sparse_row_graph), CSR is the only one that cannot be created with read_graphviz, which requires a MutableGraph).

However, it will be great to have such a possibility, even by using a different function.",Johan Oudinet <johan.oudinet@…>
5428,No <ctime> function in Windows CE 6.0,date_time,Boost 1.46.1,To Be Determined,Bugs,az_sw_dude,new,2011-04-06T10:12:50Z,2012-02-03T11:26:15Z,"Windows CE platform is nothing <ctime> function.
example std::localtime, std::gmtime, etc...

boost/date_time/c_time.hpp is direct use ""std::localtime"", ""std::gmtime"".
this problem solution is make alternative implementation.

Windows CE platform <ctime> sample implementation is there: OpenTimeCE.
(I cant paste URL, as spam...)",Akira Takahashi <faithandbrave@…>
5427,endpoint compile error in Windows CE 6.0,asio,Boost 1.46.1,To Be Determined,Bugs,chris_kohlhoff,new,2011-04-06T09:55:02Z,2011-04-06T09:55:02Z,"Windows CE is no locale. and no ostringstream::imbue.
Windows CE platform needs follow:
{{{
// boost/asio/ip/detail/impl/endpoint.ipp
#if !defined(BOOST_NO_IOSTREAM) && !defined(_WIN32_WCE)
std::string endpoint::to_string(boost::system::error_code& ec) const
...
#endif // !defined(BOOST_NO_IOSTREAM) && !defined(_WIN32_WCE)
}}}",Akira Takahashi <faithandbrave@…>
5402,bind.hpp generates declared but never referenced warnings for placeholders with armcc,bind,Boost 1.47.0,To Be Determined,Bugs,Peter Dimov,new,2011-03-31T01:03:57Z,2011-04-05T22:33:28Z,"generates spurious variable defined but never referenced under armcc (check for __ARMCC_VERSION)


""../../boost/bind/placeholders.hpp"", line 55: Warning:  #177-D: variable ""<unnamed>::_1"" was declared but never referenced
  boost::arg<1> _1;
                ^
""../../boost/bind/placeholders.hpp"", line 56: Warning:  #177-D: variable ""<unnamed>::_2"" was declared but never referenced
  boost::arg<2> _2;
                ^
""../../boost/bind/placeholders.hpp"", line 57: Warning:  #177-D: variable ""<unnamed>::_3"" was declared but never referenced
  boost::arg<3> _3;
                ^
""../../boost/bind/placeholders.hpp"", line 58: Warning:  #177-D: variable ""<unnamed>::_4"" was declared but never referenced
  boost::arg<4> _4;
                ^
""../../boost/bind/placeholders.hpp"", line 59: Warning:  #177-D: variable ""<unnamed>::_5"" was declared but never referenced
  boost::arg<5> _5;
                ^
""../../boost/bind/placeholders.hpp"", line 60: Warning:  #177-D: variable ""<unnamed>::_6"" was declared but never referenced
  boost::arg<6> _6;
                ^
""../../boost/bind/placeholders.hpp"", line 61: Warning:  #177-D: variable ""<unnamed>::_7"" was declared but never referenced
  boost::arg<7> _7;
                ^
""../../boost/bind/placeholders.hpp"", line 62: Warning:  #177-D: variable ""<unnamed>::_8"" was declared but never referenced
  boost::arg<8> _8;
                ^
""../../boost/bind/placeholders.hpp"", line 63: Warning:  #177-D: variable ""<unnamed>::_9"" was declared but never referenced
  boost::arg<9> _9;
                ^
",anonymous
5400,token_functions.hpp does not compile with exceptions off,tokenizer,Boost 1.47.0,To Be Determined,Bugs,jsiek,new,2011-03-31T00:50:22Z,2015-02-07T03:39:48Z,"uses throw (instead of boost::throw_exception as it should)

with exceptions off, you cannot use throw(), try, catch, etc., hence BOOST_TRY, BOOST_CATCH, BOOST_RETHROW",anonymous
5398,progress.hpp does not compile with exceptions off,timer,Boost 1.47.0,To Be Determined,Bugs,Beman Dawes,new,2011-03-31T00:41:12Z,2011-03-31T07:23:24Z,"uses try/catch instead of BOOST_TRY/BOOST_CATCH

with exceptions off, you cannot use throw(), try, catch, etc., hence boost::throw_exception(), BOOST_TRY, BOOST_CATCH, BOOST_RETHROW
",anonymous
5391,Rework BBv2 documentation,build,Boost Development Trunk,To Be Determined,Feature Requests,Vladimir Prus,new,2011-03-30T21:54:15Z,2013-10-25T18:57:07Z,"There's lots of complaints about the BBv2 documentation Artyom had the good recommendation to structure it as:

1. General Concepts:
 a. Syntax
 b. Rules
 c. etc.

2. Tutorial How to do common stuff:
 a. Build a program
 b. Build a library
 c. Build a test
 d. Configure things conditionally
 e. Create extensions
 f. And so on.

   Pass on common features of Autotools, CMake, SCons
   and make sure users can easily figure out how to do.

3. **Full** reference documentation:
 a. Properties
 b. Modules
 c. Rules

   And so on. This is even more important
   then tutorial because user and search
   for specific functions rules if they documented
   but he can't if there is no docs.

   As example I can provide ICU, their tutorials
   are very poor and basic but their reference docs
   are really great.
",René Rivera
5390,Add a rule to Boost Build to just run the C++ preprocessor,build,Boost 1.47.0,To Be Determined,Feature Requests,Vladimir Prus,new,2011-03-30T21:03:45Z,2011-04-07T23:41:22Z,There is no rule to run the C++ preprocessor in Boost Build I suggest a rule to do this should be added.,eldiener@…
5380,Windows has triggered a breakpoint in my code,asio,Boost Release Branch,To Be Determined,Bugs,chris_kohlhoff,new,2011-03-28T03:52:20Z,2011-04-02T04:37:07Z,"this is the code i used to test (from your website's examples)
'''http://www.boost.org/doc/libs/1_46_0/doc/html/boost_asio/example/echo/async_tcp_echo_server.cpp'''


When i used ""step into"" to debug, i got the following error message:
'''HEAP[test.exe]: HEAP: Free Heap block c46ce8 modified at c46de0 after it was freed
Windows has triggered a breakpoint in test.exe.

This may be due to a corruption of the heap, which indicates a bug in test.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while test.exe has focus.

The output window may have more diagnostic information.
'''


''This is the file it stopped:''
'''\boost\asio\detail\impl\win_iocp_socket_service_base.ipp'''
''line stopped: 334''



''line 334 is in  function: ''
'''void win_iocp_socket_service_base::start_receive_op(
    win_iocp_socket_service_base::base_implementation_type& impl,
    WSABUF* buffers, std::size_t buffer_count,
    socket_base::message_flags flags, bool noop, operation* op)'''


''This is line 334:''
'''int result = ::WSARecv(impl.socket_, buffers,
        static_cast<DWORD>(buffer_count),
        &bytes_transferred, &recv_flags, op, 0);'''



This problem occurs while i send a simple message to the test server, 128 bytes in each request.


Version of Boost: 1.46.1
",greatstar00@…
5377,Use strerror_s to resolve error messages on Windows when possible,system,Boost 1.46.0,To Be Determined,Feature Requests,Beman Dawes,new,2011-03-27T03:39:11Z,2011-03-27T03:39:11Z,"In error_code.cpp, conditional macros choose the system call used to resolve error code values to strings (~line 81). The inline documentation mentions that strerror_r is used to provide thread-safety on platforms that expose that call.

However, for Windows, the strerror call is always used, which is not thread-safe.

Since VS2005, the Windows API has provided strerror_s, a thread-safe alternative to strerror that is similar to strerror_r.

If possible, the strerror_s call should be used on Windows platforms that provide it.

I am not an expert on the Boost way to select on Windows API versions internally so I hesitate to propose a patch but the form would be similar to that used for the strerror_r calls in that same area of the code.
",Greg Wiley <a507@…>
5364,BOOST_PARAMETER_CONSTRUCTOR vs. static member function as parameter,parameter,Boost 1.46.0,To Be Determined,Bugs,Daniel Wallin,new,2011-03-23T21:04:05Z,2011-03-23T21:04:05Z,"If the patch associated with [https://svn.boost.org/trac/boost/ticket/2793 Ticket 2793] is applied, then Boost.Parameter-enabled constructors will work fine when taking in free functions, but not when taking in static member functions that ordinarily have the same signatures as the free functions.",expaler
5357,system::error_code::operator unspecified_bool_type() should not assume 0 == success.,system,Boost 1.45.0,To Be Determined,Feature Requests,Beman Dawes,new,2011-03-23T00:37:22Z,2012-09-09T23:12:50Z,"[The following was submitted for discussion to boost@lists.boost.org on 2011-03-10.  It received only one response, which was supportive.]

I've found boost.system to be very useful for wrapping return codes from 3rd party libraries (e.g. libcurl).  However, one problem I've encountered is that error_code's operator for boolean tests assumes that an error value of 0 == success.  While this is often true, it is not universally so and precludes use of boost.system for such tasks as wrapping HTTP status codes (several of which are merely informative and don't indicate an error).

I've found it puzzling that the logic for determining whether an error value represents an error doesn't reside in the error_category, where it can be customized as needed.  For instance, boolean tests could chain to a is_error() virtual method in the error_category, the default implementation of which preserves the current behavior:

{{{#!C++
  namespace boost
  {
    namespace system
    {
      class error_category : public noncopyable
      {
      public:

        // ...

        virtual bool is_error( int ev ) const
        {
          return ev != 0;
        }

        // ...

      };


      class error_code
      {
      public:

        // ...

        operator unspecified_bool_type() const
        {
          return m_cat->is_error( m_val ) ? unspecified_bool_true : 0;
        }

        // ...

      };
    }
  }
}}}",mgruenke@…
5348,"""imperceptible"" link in getting started",Getting Started Guide,Boost 1.45.0,To Be Determined,Bugs,Dave Abrahams,new,2011-03-21T12:36:49Z,2011-03-21T12:38:09Z,"http://www.boost.org/doc/libs/1_46_1/more/getting_started/

I read getting started guide first time.

After words

{{{
  Ready?
  Let's go!
}}}

I can't find where to click to go to next page for a long time.

I suggest to make these two links left aligned and don't separate them with horizontal line.
",sorokin@…
5342,find_ptr (find wrapper),ptr_container,Boost 1.46.0,Boost 1.47.0,Feature Requests,Thorsten Ottosen,new,2011-03-19T17:12:50Z,2012-03-14T14:02:07Z,"Could you add a find wrapper to ptr (unordered) map that returns mapped_type* instead of an iterator (and NULL if not found)?

The same could be provided for the other containers, but there it's less useful.",olafvdspek@…
5341,Patch to improve shared library behavior with serialization,serialization,Boost 1.47.0,To Be Determined,Patches,Robert Ramey,reopened,2011-03-19T00:34:50Z,2014-07-17T08:13:21Z,"There are some issues that I have come across when using serialization with objects across shared libraries. I have made a patch that resolves the issues I have encountered, and will hopefully make serialization finally be friendly across multiple shared libraries.

The primary issue that I had was if there is a serializer created for an object, there can be some shared libraries that have a pointer serializer registered, and others that don't. This is actually quite common if you have the base class of an object declared in a separate library, since serializng a base class with base_object doesn't instanciate a pointer serializer.

Here is one case where this would prove to be an issue. Let's say the first time you wrote out a type it had no pointer serializer registered. It would write in the type info that tracking is not required and write out the object. Later, an object of the same type is written out from another shared library, but in this library a pointer serializer is registered. In this case, it will write out the object id, followed by the object itself. When that file is read in, it will read that the type has tracking disabled with the type information, and read the first instance just fine. However, on the second instance it still thinks that tracking is disabled, and will fail to read in the object id, even though it was written out.

I solved this issue by re-writing the archive serializer map to manage both pointer and non-pointer serializers. The map itself stores the non-pointer serializers in a multiset, so the serializers for all shared libraries are stored. When a iserializer/oserializer is constructed it is registered for that object type, and when it is destructed it is unregistered. pointer_iserializer/pointer_oserializer also register and unregister themselves with the map, but the behavior is different. What it will do is look at all non-pointer serializers of the proper type currently registered, and for any that don't have any pointer serializer registered for them it will use the pointer serializer currently being registered. When a pointer serializer is unregistered, it will search for an equivalent pointer serialier registered for another serializer for the same type (that was instanciated in a different library), or NULL if there is no such pointer serializer, and replace all instances of the pointer serializer being unregistered with that. Additionally, if a non-pointer serializer is being registered, it will look for an existing pointer serializer for that type to use. (it will quickly be replaced if there is a pointer serializer for that type instanciated in that library)

The effect at the end of the day is that for any given serializer, either all libraries or no libraries will have a pointer serializer registered for the corresponding non-pointer serializer. Since unregistration of pointer serializers tries to look for an equivalent to take its place, it should handle dynamic loading and unloading of libraries properly. Also, it should add no runtime cost during the actual usage of the serializers, only during the registration and unregistration.

The other issue I was having was I needed to create my own archive, but there was no way to export the archive serializer map symbols unless I put it in the boost serialization library, since it used the BOOST_ARCHIVE_OR_WARCHIVE_DECL() to generate the dllexport/dllimport declspecs. I changed it to use a technique described here. (http://support.microsoft.com/kb/168958) This allows customization for whether the symbols are imported and exported for each instantioation of archive_serializer_map. I also had to change all of the current archives to use this new method to register the archive serializer map.

I tried to keep consistent with your coding style and techniques. Since both this patch and the concrete to abstract patch I submitted earlier modify iserializer.hpp, I have also attached a combined patch that applies both.",Aaron Barany <akb825@…>
5340,Patch to support concrete base classes becomming abstract classes,serialization,Boost 1.47.0,To Be Determined,Patches,Robert Ramey,new,2011-03-19T00:26:28Z,2014-08-13T12:24:35Z,"If you are serializing a pointer to a polymorphic object as a pointer to its base class, and that base class is concrete, it will fail to load if that base class later becomes abstract. That is because the serializer for the base class is automatically registered if it is concrete, but not if it is abstract, making a mismatch in the class id for the object. I have attached a patch that detects this case and registers the serializer for the abstract class if it occurs.

This patch contains multiple pieces. Fist, basic_iarchive.cpp is patched in load_pointer() to detect that mismatch in class ids and register the serializer. Second, iserializer.hpp is patched so that register_type() for abstract classes returns the proper pointer serializer. (though it isn't directly registered) Third, pointer_iserializer::load_object_pointer() now uses templates to split into two implementations: one for abstract and one for non-abstract classes. The abstract implementation throws an archive_exception, to which an abstract_class_error field has been added.

This patch does not handle going from an abstract base class to a concrete base class, as that would break backwards compatibility. However, it should be more common to go from concrete to abstract than the other way around, and having this support can solve a lot of debugging headaches when it comes up. (headaches that prompted me adding this support)

I have tried to keep consistent with your coding style and techniques to make it as seamless to patch as possible.",Aaron Barany <akb825@…>
5339,asio async_read throws boost::asio::error::invalid_argument on mac OS X,asio,Boost 1.45.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-03-19T00:05:20Z,2012-11-24T07:31:17Z,"I am trying to write a serial library using Boost's asio, but on mac OS X the async_read throws boost::asio::error::invalid_argument.  I have created a custom completion condition to ignore the invalid_argument exceptions, but this causes a busy wait (using a lot of cpu time) yet does not prevent data from being read.

I have attached source code and output from both linux and os x.

Linux: Ubuntu 10.10 i386 - Boost 1.42.0
Mac OS X: 10.6.6 - Boost 1.45.0",wjwwood@…
5318,Path replace_stem() request,filesystem,Boost 1.46.0,To Be Determined,Feature Requests,Beman Dawes,new,2011-03-16T12:57:37Z,2011-03-16T12:57:37Z,"There has been a request for a path replace_stem() function to complement replace_extension().

It might make sense to revisit remove_filename(). It should probably have been replace_filename(const path& new_filename=path());

Ticket #5317 should be cleared before addressing these issues.
",Beman Dawes
5317,"Path filename(), stem(), and extension() problems",filesystem,Boost 1.46.0,To Be Determined,Bugs,Beman Dawes,new,2011-03-16T12:42:49Z,2011-03-16T12:42:49Z,"Problem: filename() is specified in terms of *--end(), but path_test.cpp does not actually test this. Since the actual implementation of filename() does not use iteration, such a test should be performed.

Resolution: Add something like BOOST_TEST_EQ(p.filename(), *--p.end()); to the decomposition tests.

Problem: stem() + extension() should == filename(), but path_test.cpp does not actually test this.

Resolution: Add something like BOOST_TEST_EQ(p.filename(), path(p.stem().native() + p.extension().native()));); to the decomposition tests.

Problem: path("".foo"") should be a stem, not an extension.

Resolution: Fix specification, implementation, and add test cases.

Problem: Design of Path iterator, and as a consequence, filename(), is too inventive in adding ""."" KISS. Note that POSIX has similar problems. POSIX dirname() and basename() are not good models; they (1) modify their arguments, and (2) return counter-intuitive results. basename(""/foo/"") returns ""foo"", not """" or "".""

Resolution: Simplify specification, change implementation and test cases accordingly.
",Beman Dawes
5309,Multiple unused parameter warnings in boost/parameter/aux_/tagged_argument.hpp,parameter,Boost 1.45.0,To Be Determined,Bugs,Daniel Wallin,new,2011-03-15T15:16:18Z,2011-03-15T15:16:18Z,"Ticket #4954 has pointed out one of these warnings already (line 123) however there is one more on line 135 (and possibly others?).

Line 123 and line 135 both have the same problem where there is an unused parameter which generates a compiler warning (GCC 4.1.2 on Red Hat Enterprise Linux Server release 5.2).

The attached patch fixes both of these.",Colin Powers <colin.powers@…>
5305,Compiling boost 1.46.1 with bjam under Windows 7 using MSVC 2010 and Intel Compiler XE 2011.0.154,Building Boost,Boost 1.46.0,To Be Determined,Bugs,,new,2011-03-14T09:24:15Z,2012-02-15T11:30:57Z,"I noticed an issue with bjam when trying to compile boost 1.46.1 using MSVC 2010 and Intel Compiler XE 2011. Bjam is trying to execute ""C:\Program Files\Intel\ComposerXE-2011\bin\ia21!//iclvars.bat"" when iclvars.bat is actually located in """"C:\Program Files\Intel\ComposerXE-2011\bin"". According to Intel's release notes ([http://software.intel.com/file/31856]), the build environment command script has been changed (Section 3.4.1) which I have copied/pasted for convenience.

> 3.4.1 Build Environment Command Script Change
> The command window script used to establish the build environment allows the optional specification of the version of Microsoft Visual Studio to use. If you are not using the predefined Start menu shortcut to open a build environment window, use the following command to establish the proper environment:
> ""<install-dir>\bin\compilervars.bat"" arch [vs]
> Where arch is one of followings as appropriate for the target architecture you want to build for:

>        * ia32
>        * ia32_intel64
>        * intel64

> vs is optional and can be one of followings. If vs is not specified, the version of Visual Studio specified at installation time for command-line integration is used by default.

>        * vs2010
>        * vs2008
>        * vs2005

> If you also have Intel® Visual Fortran Composer XE 2011 installed, this command will also establish the environment for using that compiler.
> The script file names iclvars.bat and ifortvars.bat have been retained for compatibility with previous releases.

The workaround is to use the predefined start menu shortcut to open a build window for building boost.",Edward Rankin <erankin@…>
5302,"[accumulator] Generalise type arithmetics, e.g. make it play well with boost.units.",accumulator,Boost 1.45.0,To Be Determined,Bugs,Eric Niebler,new,2011-03-14T05:34:46Z,2011-03-14T05:34:46Z,"Accumulators library assumes that for an accumulated type T*T is also of type T. This makes it difficult to play it well with boost.unit for example; specially for the variance accumulator.

Based on http://groups.google.com/group/boostusers/msg/86ebe100e3a86794
Below is the goal code:

#include<boost/accumulators/accumulators.hpp>
#include <boost/accumulators/statistics/variance.hpp>
#include<boost/units/systems/si.hpp>
#include<boost/units/io.hpp>

using namespace boost::accumulators;
using namespace boost::units;
int main(){
	accumulator_set<
		quantity<si::time>, 
		features<
			tag::variance, 
		> 
	> a;
	a(1.0*si::second);
	a(2.0*si::second);
	a(3.0*si::second);
	std::cout 
		<< extract::variance(a)
	;
	return 0;
}
",alfredo.correa@…
5301,Boost.Filesystem V3 interface inconsistency,filesystem,Boost 1.46.0,To Be Determined,Bugs,Beman Dawes,new,2011-03-13T21:03:22Z,2011-03-13T21:03:22Z,"I came across the following interface inconsistency in Boost.Filesystem V3 (Boost 1.46.0) in boost::filesystem::path

Windows:

const std::string string()
const std::wstring&  wstring()

Linux:

const std::string&  string()
const std::wstring  wstring()


We converted V2 code looking like this (necessary since filename() in V3 returns a path instead of a string):

const std::string& filename=path.filename();

The converted V3 code:

const std::string& filename=path.filename().string();


Obviously this code crashes in Linux since filename() returns a temporary object and string() returns a reference to one of its members.

However this code works in Windows due to the different return types.

My question:

Wouldn't it make sense for all methods to return a value instead of a reference?

It would ease the transition from V2 to V3 and avoid subtle programming errors.",Peter Klotz <peter.klotz@…>
5299,Serialization throws an exception for loading binary archive on windows,serialization,Boost 1.46.0,To Be Determined,Bugs,Robert Ramey,new,2011-03-13T14:31:01Z,2013-06-20T11:45:53Z,"Serialization throws an exception for loading binary archive on windows. THere is no error when using text or xml archive. No error on Ubuntu when using binary, text or xml archive.

I have tested the cpp file on both Window XP-x86 and Window 7-x64. The errors are the same.

A minimal and complete example is the following:
(in s11n_bug.cpp):

{{{
#include <fstream>

#include <boost/archive/binary_iarchive.hpp>
#include <boost/archive/binary_oarchive.hpp>
#include <boost/serialization/vector.hpp>
#include <boost/serialization/shared_ptr.hpp>
#include <boost/serialization/nvp.hpp>

typedef std::vector<int> B;

class A;

typedef boost::shared_ptr<A> a_ptr;
typedef boost::shared_ptr<B> b_ptr;

class A{
public:
	A(){}
	A(b_ptr b) : b_(b){}
  virtual ~A(){}
  b_ptr b_;

  friend class boost::serialization::access;
  template<class Archive>
  void serialize(Archive & ar, const unsigned int version){
    ar & BOOST_SERIALIZATION_NVP(b_);
  }
};

class DA : public A{
public:
	DA(){}
	DA(b_ptr b) : A(b){}
	template<class Archive>
  void serialize(Archive & ar, const unsigned int version){
		ar & boost::serialization::make_nvp(""base"", boost::serialization::base_object<A>(*this));
  }
};

typedef std::vector<a_ptr> VA;
typedef boost::shared_ptr<VA> va_ptr;

typedef std::vector<va_ptr> VVA;
typedef boost::shared_ptr<VVA> vva_ptr;

template <typename Archive>
void register_types(Archive& ar){
  ar.template register_type<DA>();
}

b_ptr make_b(){
	return b_ptr(new B);
}

a_ptr make_a(){
	return a_ptr(new DA(make_b()));
}

va_ptr make_va(){
	VA va;
	va.push_back(make_a());
	va.push_back(make_a());
	return va_ptr(new VA(va));
}

vva_ptr make_vva(){
	VVA vva;
	vva.push_back(make_va());
	vva.push_back(make_va());
	return vva_ptr(new VVA(vva));
}

int main(){
	std::string filename = ""tmp"";
	std::vector<vva_ptr> thing;
	thing.push_back(make_vva());
	thing.push_back(make_vva());
	{
		std::ofstream ofs(filename.c_str());
		boost::archive::binary_oarchive oa(ofs);
		register_types(oa);
		oa << BOOST_SERIALIZATION_NVP(thing);
	}
	{
		std::ifstream ifs(filename.c_str());
		boost::archive::binary_iarchive ia(ifs);
		register_types(ia);
		ia >> BOOST_SERIALIZATION_NVP(thing);
	}
	return 0;
}
}}}",Wang Peng <wangp.thu@…>
5297,boost 1.46.1 bootstrap problem with visual studio 2010 sp1,Building Boost,Boost Release Branch,To Be Determined,Bugs,,new,2011-03-12T21:57:02Z,2011-05-05T14:42:54Z,"when executing bootstap.exe for boost-1.46.1, the process failed. see attached bjam.log for detail. ",lto@…
5293,support exception-handling feature in gcc,build,Boost 1.46.0,To Be Determined,Patches,Vladimir Prus,new,2011-03-12T19:01:16Z,2011-03-12T19:01:16Z,"It's not clear to me if the exception-handling is deliberately excluded from the gcc toolset or not, given how small this change is, it almost seems like it. Anyway, I can't see a reason not to support this feature for GCC. Appending this at the end of build/v2/tools/gcc.jam makes it work for me (on darwin).

{{{
toolset.flags gcc OPTIONS <exception-handling>off : -fno-exceptions ;
toolset.flags gcc OPTIONS <exception-handling>on : -fexceptions ;
}}}",arvid@…
5292,boost::mpi::scatterv and boost::mpi::gatherv added,mpi,Boost 1.45.0,To Be Determined,Patches,Matthias Troyer,new,2011-03-11T16:04:58Z,2014-04-09T17:19:48Z,"Two more collective operations for Boost.MPI. I made the headers completely based on the existent one: scatter.hpp and gather.hpp

""common use versions"" was added too, for those cases where the great buffer is stored contiguously at the root process.

The ""common use version"" of gatherv needs a warning in the docs: Since the process send it's own buffer size and nothing more, all sizes will be gathered before the real call. I don't know if this is tolerable, you have the decision.

Other doubt about gatherv implementation: I did switch to the packed_archive_send() / packed_archive_recv() communication, i tried to figure out the difference in send an archive or send using communicator::send when dealing with non-MPI types, but without success. boost::mpi::scatter uses the first and boost::mpi::gather uses the second. Anyway,the snippet of code is commented if you want to switch back.

I'm sending a Main.cpp file with the simple tests i made, comment or uncomment the prototypes in pairs: scatterv / gatherv.

To see the results in a separate terminal for each process, this is a possible way:


'''mpicxx Main.cpp -o test &&
echo 107 > input.txt &&
mpirun -np 4 xterm -e ./test'''
",Júlio Hoffimann <julio.hoffimann@…>
5291,bzip2_decompressor does not work properly with a filtering_streambuf,iostreams,Boost 1.45.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-03-11T15:12:00Z,2013-07-01T00:20:27Z,"The revision 63057 of boost/iostreams/filter/bzip2.hpp seems to have broken the ability to use the bzip2 decompressor in a filtering streambuf.  When I pass a stream into the buffer it throws data_error_magic. Stepping through the code I can see it correctly decode the zipped data, but then it continues to attempt to decode data even after eof is reached.  

Looking at the changes to bzip2_decompressor_impl I see the following issues:
1.) The function returns true even if _eof is set to true.  This causes the ""done"" flag in the ""Read"" function in symmetric.hpp to be set to false, which causes the bzip2_decompressor_impl function to execute again, after EOL.
2.) On the second execution when _eof is set, the ""close"" function resets _eof to  false, which can cause the function to throw the exception.

In the specific instance I am using, my bzip compressed section is embedded in the middle of the stream, so src_begin won't equal src_end.",Chris Steenwyk <chris.steenwyk@…>
5284,gcc-4.4.3 compiler warnings with Interprocess+Intrusive,intrusive,Boost 1.46.0,To Be Determined,Bugs,Ion Gaztañaga,new,2011-03-08T22:38:21Z,2012-08-22T17:24:12Z,"I've been using Boost Interprocess managed_shared_memory for
a short time.  My project was previously using a cross compiler
environment based on gcc-4.4.0/glibc-2.3.6 but is moving to
gcc-4.4.3/glibc-2.11.1.  gcc-4.4.3 with -O2 is started generating
compiler warnings in the Intrusive library when I attempt to
execute the construct() method on managed_shared_memory object.
-O0 and -O1 are still happy.  I'm wondering if anyone else has
seen similar, has suggestions on debug/fix, or does this appear
to be compiler issue?

Program snippet:
#include ""boost/interprocess/managed_shared_memory.hpp""
#include <cstdlib> //std::system
#include <cstddef>

int main(int argc, char *argv[])
{
  using namespace boost::interprocess;
  typedef std::pair<double, int> MyType;

  //Construct managed shared memory
  managed_shared_memory segment(create_only, ""MySharedMemory"", 65536);

  //Create an object of MyType initialized to {0.0, 0}
  MyType *instance = segment.construct<MyType>
      (""MyType instance"")  //name of the object
      (0.0, 0);            //ctor first argument
  return 0;
}

Compiler output:
gcc-4.4.3-glibc-2.11.1-grte/x86/bin/g++ -ld -MD -MP -g -O2 -Wall -Werror
  -fno-omit-frame-pointer -Wno-error -Wno-deprecated -fpic
  -I/home/mitzel/src/boost_1_46_0 -c -o test.o test.cc
In file included from /home/mitzel/src/boost_1_46_0/boost/intrusive/rbtree_algorithms.hpp:58,
                 from /home/mitzel/src/boost_1_46_0/boost/intrusive/detail/rbtree_node.hpp:20,
                 from /home/mitzel/src/boost_1_46_0/boost/intrusive/set_hook.hpp:20,
                 from /home/mitzel/src/boost_1_46_0/boost/intrusive/rbtree.hpp:25,
                 from /home/mitzel/src/boost_1_46_0/boost/intrusive/set.hpp:19,
                 from /home/mitzel/src/boost_1_46_0/boost/interprocess/mem_algo/rbtree_best_fit.hpp:47,
                 from /home/mitzel/src/boost_1_46_0/boost/interprocess/detail/managed_memory_impl.hpp:22,
                 from /home/mitzel/src/boost_1_46_0/boost/interprocess/managed_shared_memory.hpp:21,
                 from test.cc:1:
/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp:
  In static member function 'static typename NodeTraits::node_ptr
  boost::intrusive::detail::tree_algorithms<NodeTraits>::minimum(typename NodeTraits::node_ptr)
  [with NodeTraits = boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>]':
/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp:490:
  warning: '<anonymous>' may be used uninitialized in this function
/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp:
  In static member function 'static typename
  NodeTraits::node_ptr boost::intrusive::detail::tree_algorithms<NodeTraits>::maximum(typename NodeTraits::node_ptr)
  [with NodeTraits = boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>]':
/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/tree_algorithms.hpp:507:
  warning: '<anonymous>' may be used uninitialized in this function
/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/utilities.hpp:
  In static member function 'static void
  boost::intrusive::detail::tree_algorithms<NodeTraits>::insert_equal_check_impl(
  bool, typename NodeTraits::node_ptr, typename NodeTraits::node_ptr, NodePtrCompare,
  boost::intrusive::detail::tree_algorithms<NodeTraits>::insert_commit_data&, size_t*)
  [with NodePtrCompare = boost::intrusive::detail::key_nodeptr_comp<std::less<
  boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>::block_ctrl>,
  boost::intrusive::rbtree_impl<boost::intrusive::setopt<boost::intrusive::detail::base_hook_traits<
  boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>::block_ctrl,
  boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>,
  (boost::intrusive::link_mode_type)0u, boost::intrusive::default_tag, 3>,
  std::less<boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family>::block_ctrl>,
  long unsigned int, true> > >, NodeTraits = boost::intrusive::rbtree_node_traits<boost::interprocess::offset_ptr<void>, true>]':
/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/utilities.hpp:234: warning: '<anonymous>' may be used uninitialized in this function
/home/mitzel/src/boost_1_46_0/boost/intrusive/detail/utilities.hpp:234: note: '<anonymous>' was declared here


thanks for your time and any suggestions.
danny <mitzel@acm.org>",Danny Mitzel <mitzel@…>
5277,QNX 6.5.0 compilation,Building Boost,Boost 1.46.0,To Be Determined,Bugs,,new,2011-03-07T21:14:47Z,2011-03-14T00:55:00Z,"Hi,

I am compiling boost on QNX 6.5.0 and there are some changes necessary to the source in order to successfully complete the build.

Regarding ticket #3133 https://svn.boost.org/trac/boost/ticket/3133 it seems that va_list is now in std namespace so this workaround actually causes an error.

In order to fix this on my machine I commented out the test for __QNXNTO__ in boost/serialization/factory.hpp as follows

{{{
namespace std{
    #if defined(__LIBCOMO__) //|| defined(__QNXNTO__)
        using ::va_list;
    #endif
} // namespace std
}}}


In addition there is an issue with the rename function included from cstdio.  By adding <stdio.h>  to the includes in libs/filesystem/v3/src/operations.cpp I was able to get it to work.  e.g.,

{{{
#include <cstdio>      // for remove, rename
#include <cerrno>
#include <cassert>
// #include <iostream>    // for debugging only; comment out when not in use

#if defined(__QNXNTO__)
#include <stdio.h>
#endif
}}}

finally, I added std::va_list to boost/test/impl/execution_monitor.ipp

{{{
#if defined(__QNXNTO__) 
#  include <stdio.h> 
using std::va_list;
#endif
}}}

These changes allow the build to complete successfully, however I don't know if this means the library has been built problem, and I'm sure there is a better way to integrate these changes.
",godbolt@…
5268,mpl::int_<INT_MIN> fails to compile under g++-4.6 although g++-4.5 works.,mpl,Boost 1.46.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2011-03-05T17:31:28Z,2011-03-07T17:21:25Z,"Under Debian Sid with a 2.6.36 AMD_64 kernel, and g++-4.6, the following code:

{{{
#include <climits>
#include <boost/mpl/int.hpp>

boost::mpl::int_<INT_MIN> foo;
}}}

Produces the errors:

{{{
/usr/local/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of ‘mpl_::int_<-0x00000000080000000>’:
test_test.cpp:8:27:   instantiated from here
/usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: ‘2147483647’ is not a valid template argument for type ‘int’ because it is a non-constant expression
/usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: overflow in constant expression [-fpermissive]
}}}",Stirling Westrup <swestrup@…>
5263,Undefined symbols in libboost_python,python USE GITHUB,Boost 1.46.0,To Be Determined,Bugs,Dave Abrahams,new,2011-03-04T14:23:00Z,2011-03-18T01:10:56Z,"When building and running pythonmagick (imagemagick python bindings dependent on boost), importing python-boost libraries fails with the following error:

ImportError: /usr/lib/libboost_python.so.1.46.0: undefined symbol: PyClass_Type

This happens although boost was compiled with python3 support and pythonmagick was linked to libboost_python and all python3 libraries in `python-config --libs`.

Checking libboost_python with ldd yields a whole list of undefined symbols [1].

This was originally filed as a bugreport for the ArchLinux distribution but the maintainer suggested an upstream problem [2].


[1] ldd -r /usr/lib/libboost_python.so.1.46.0 ; output: see [2]
[2] https://bugs.archlinux.org/task/23130",mschu.dev+boost@…
5245,ssend/issend support in Boost.MPI,mpi,Boost 1.45.0,To Be Determined,Feature Requests,Matthias Troyer,new,2011-03-01T10:50:20Z,2013-01-01T11:13:26Z,"I have code that depends on the use of MPI ssend/issend (synchronous send), so I would like to see Boost.MPI support it.

I'm attaching a patch to this extent; it applies cleanly to Boost 1.45.0 and 1.46.0.

The patched code sometimes fails the ""nonblocking"" test, seemingly at random and I'm not able to debug it.  On the other hand, I have been using the patched Boost.MPI in production runs of my code for months now without any issue so I'm quite confident in it.
",Riccardo Murri <riccardo.murri@…>
5244,<methodname> and <classname> clash with docbook,Documentation,Boost 1.45.0,To Be Determined,Bugs,No-Maintainer,new,2011-02-28T22:56:31Z,2012-11-08T11:24:52Z,"This is the remaining issue from #2153. Boostbook has `<methodname>` and `<classname>` elements with different semantics to the the docbook elements with the same name. They're not in the dtd for this reason, and not documented. Should possibly rename the `<*name>` elements to something more sensible.",Daniel James
5243,Support doxygen <ref> elements in passthrough mode.,Documentation,Boost 1.45.0,To Be Determined,Feature Requests,Steven Watanabe,new,2011-02-28T22:47:06Z,2011-06-18T10:59:33Z,"A patch for this was attached to #3309, but I didn't apply it because doxygen seems to automatically mark words as `<ref>` and often gets it wrong. The change might be appropriate if that can be suppressed.",Daniel James
5241,Ublas still links to the old CVS repository,uBLAS,Boost 1.45.0,To Be Determined,Bugs,Gunter,new,2011-02-27T12:45:21Z,2011-02-27T12:45:21Z,The attached patch updates it.,Daniel James
5239,Outdated Boost build instructions in the python tutorial,python USE GITHUB,Boost 1.45.0,To Be Determined,Bugs,Dave Abrahams,new,2011-02-27T12:30:28Z,2011-02-27T12:30:28Z,"Since bjam is now part of boost build, the python tutorial is out of date. The attached patch is a quick fix, although it might be best to rewrite some of it.",Daniel James
5238,Outdated repository details for cctbx,python USE GITHUB,Boost 1.46.0,To Be Determined,Bugs,Dave Abrahams,new,2011-02-27T11:20:04Z,2011-02-27T11:20:04Z,"In the [http://www.boost.org/doc/libs/1_46_0/libs/python/doc/v2/faq.html#question2 python FAQ], CVS is used to access the ""scitbx"" files. They seem to be using subversion now.",Daniel James
5234,Boost 1.46 doesn't build on FreeBSD 7.1-RELEASE,build,Boost 1.46.0,To Be Determined,Bugs,Vladimir Prus,new,2011-02-26T10:51:05Z,2014-10-09T06:08:07Z,"{{{
kvs@tishina boost_1_46_0:> ./bootstrap.sh 
Building Boost.Jam with toolset gcc... 
Failed to build Boost.Jam
Consult 'bootstrap.log' for more details
kvs@tishina boost_1_46_0:> cat bootstrap.log 
###
### Using 'gcc' toolset.
###
rm -rf bootstrap
mkdir bootstrap
gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c
jam.c: In function 'executable_path':
jam.c:615: warning: incompatible implicit declaration of built-in function 'strndup'
/var/tmp//ccApIIrd.o(.text+0xc48): In function `executable_path':
: undefined reference to `strndup'
}}}

I seems that FreeBSD 7.1 doesn't have strndup() function.",kvs@…
5230,Interprocess shared memory between 32 and 64 bit processes,interprocess,Boost Development Trunk,To Be Determined,Feature Requests,Ion Gaztañaga,reopened,2011-02-25T13:42:37Z,2017-08-30T12:25:51Z,"For sharing memory between 32 and 64 bit processes, all structures in shared memory must have the same binary layout with matching size_type and difference_type. In addition, offset_ptr must be 64bit in this case. 

This is a patch that parameterizes offset_ptr to explicitly accept its difference_type along with its internal offset_type. This difference_type (and the according size_type) is propagated to all other affected structures (memory algorithms, allocators, containers, ...). In 32/64 bit shared environments, difference_type should be set to {{{int}}} and offset_type to {{{unsigned __int64}}}. The default values are {{{ptrdiff_t}}} and {{{size_t}}}. 

Note: rbtree_best_fit also uses offset_type to store its internal block sizes, because these need to wrap-around correctly on 64bit machines.",tgermer@…
5227,find_ptr wrapper for map::find,algorithm,Boost 1.46.0,Boost 1.52.0,Feature Requests,Marshall Clow,new,2011-02-24T16:44:08Z,2013-01-09T14:28:56Z,"Hi,

Would it be possible to include this handy wrapper for (unordered) map::find?

{{{
#include <boost/unordered_map.hpp>
#include <iostream>
#include <string>

using namespace std;

template <class T, class U>
typename T::mapped_type* find_ptr(T& c, U v)
{
	typename T::iterator i = c.find(v);
	return i == c.end() ? NULL : &i->second;
}

template <class T, class U>
const typename T::mapped_type* find_ptr(const T& c, U v)
{
	typename T::const_iterator i = c.find(v);
	return i == c.end() ? NULL : &i->second;
}

int main()
{
  typedef boost::unordered_map<int, string> very_long_type_name_t;

  very_long_type_name_t very_long_name;
  very_long_name[1] = ""one"";
  very_long_type_name_t::iterator i = very_long_name.find(1);
  if (i != very_long_name.end())
    cout << i->second << ""\n"";

  if (very_long_type_name_t::mapped_type* i = find_ptr(very_long_name, 1))
    cout << *i << ""\n"";

  /*
  very_long_type_name_t::iterator i = very_long_name.find(1); if (i != very_long_name.end()) cout << i->second << ""\n"";
  if (very_long_type_name_t::mapped_type* i = find_ptr(very_long_name, 1)) cout << *i << ""\n"";

  auto i = very_long_name.find(1); if (i != very_long_name.end()) cout << i->second << ""\n"";
  if (auto i = find_ptr(very_long_name, 1)) cout << *i << ""\n"";
  */
}
}}}",olafvdspek@…
5224,Non-type class template parameters support.,parameter,Boost 1.45.0,To Be Determined,Feature Requests,Daniel Wallin,new,2011-02-24T11:40:51Z,2011-02-24T11:40:51Z,,Domagoj Šarić
5201,Negative numbers as options and values not parsed correctly,program_options,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2011-02-18T21:42:32Z,2014-01-19T17:58:39Z,"This issue has been reported initially on StackOverflow in question [http://stackoverflow.com/questions/4107087/accepting-negative-doubles-with-boostprogram-options Accepting negative doubles with boost::program_options] and later reminded on the mailing list in thread [http://lists.boost.org/Archives/boost/2011/02/176604.php program_options negative numbers]. Not sure if it is a bug or lack of feature, but seems it would be reasonable to have it solved.

Simply, program_options can not parse negative numbers as values of options. For example:

{{{
mycommand --extent -1.0 -2.0 -3.0 1.0 2.0 3.0 --some-other-argument somevalue
}}}

I discussed this issue with Volodya on IRC and there seems to be possible and not difficult to implement solution. Here is the chat script:

{{{
Nov 10 17:04:17 <mloskot>    volodya: I think it's feasible to refactor the loops in the cmdline parser to handle multitoken options with negative numbers as values. I have an idea to add ::multitoken(int exact_tokens_num) and make parser consuming as much values as the exact number of tokens specified, regardless how the options look like
Nov 10 17:04:26 <mloskot>    volodya: what you think about this idea?
Nov 10 17:04:28 <spitzi>    The question is - supposed that I want to make some quick-and-dirty struct for the sake of having related, named fields tied together, but without going through writing c'tors and operators. Can a list of such structs be initialized with boost::assign::list_of ?
Nov 10 17:05:30 <volodya>    mloskot: well, I think that if that translates into min and max number of tokesn of the option being equal to that value, it seems sane
Nov 10 17:05:53 <mloskot>    volodya: yes, basically that would be the thing
Nov 10 17:05:55 <volodya>    and of course, when min=max, there's no need to guessing.
Nov 10 17:05:59 <volodya>    ok, sounds good.
}}}
",Mateusz Loskot
5195,time_duration visualizer works incorrectly with negative duration,date_time,Boost 1.46.0,To Be Determined,Bugs,fkonvick,new,2011-02-16T13:29:20Z,2011-02-16T13:29:20Z,"86400000000 unsigned 64 bit integer is mixed with signed integers.
The fix is to use 86400000000I64 instead, as follows:

;------------------------------------------------------------------------------
;  boost::posix_time::time_duration visualizer
;  only works with microseconds resolution
;------------------------------------------------------------------------------

boost::posix_time::time_duration{
	preview
	( 
		#( 
			$c.ticks_.value_/86400000000I64,
			""d "",
			($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64))/3600000000,
			""h "",
			($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64)-3600000000*(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64))/3600000000))/60000000,
			""m "",
			(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64)-3600000000*(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64))/3600000000))-60000000*(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64) - 3600000000*(($c.ticks_.value_-86400000000I64*($c.ticks_.value_/86400000000I64))/3600000000))/60000000))/1000000,
			""s "",
			($c.ticks_.value_%1000000)/1000,
			""ms "",
			$c.ticks_.value_%1000,
			""us""
		 )
	)		
}
",Igor R. <boost.lists@…>
5192,Serialization of Boost.Filesystem path,serialization,Boost 1.45.0,To Be Determined,Feature Requests,Robert Ramey,reopened,2011-02-14T22:41:00Z,2017-11-01T05:05:25Z,"I came across Johan Rade's post about serialization of a filesystem path (see http://lists.boost.org/Archives/boost/2008/09/142550.php). 

However I couldn't spot it in the source code. Maybe a suggestion? Ofc the C4127 should be addressed then.

Note: the mail thread is also about in which library the solution should be placed. My suggestion is to put it in serialization library, with the rationale that 'path' is a more basic concept (comparable to string, vector etc.) than serialization is. It would be more natural for serialization to use the filesystem library than the other way around.
",gast128@…
5176,test_assignment assumes fabs(float),uBLAS,Boost 1.45.0,To Be Determined,Bugs,Gunter,new,2011-02-10T20:39:38Z,2012-09-19T19:48:53Z,"As per [lib.c.math] paragraphs 5 and 6, there are float and long double overloads for fabs():

{{{
  float fabs (float);
  long double fabs (long double);
}}}

libstdc++ apparently does not have the required overloads and is seems
  libs/numeric/ublas/test/test_assignment.cpp
relies on this.

Patch provided.
",hstong@…
5174,Patch to make code_converter flushable,iostreams,Boost 1.45.0,To Be Determined,Patches,Jonathan Turkanis,new,2011-02-10T03:15:16Z,2012-03-24T03:25:36Z,"I've attached a little patch that makes iostreams::code_converter
flushable. It seems like it really should be. Is there any chance
someone could look at this? I've included some test code as well that
outputs the following.

The reason I need this functionality is because I am converting the
[http://savannah.nongnu.org/projects/fastcgipp fastcgi++] library
over to use boost iostreams for filtering capabilities. Unfortunately
if the code_converter can not flush it is useless.

********** OUTPUT BEFORE PATCH **********

main(): Sending 24 characters of data to output stream
SinkDev::write(): Recieved 16 characters.
main(): Calling a sync on the output stream
main(): Sending 21 characters of data to output stream
SinkDev::write(): Recieved 16 characters.

main(): Asking for 24 characters of data from input stream
SourceDev::read(): Sending 16 characters.
SourceDev::read(): Sending 16 characters.
main(): Calling a sync on the input stream
main(): Asking for 9 characters of data from input stream
SourceDev::read(): Sending 16 characters.

main(): At end of test case
SinkDev::write(): Recieved 13 characters.

********** OUTPUT AFTER PATCH **********

main(): Sending 24 characters of data to output stream
SinkDev::write(): Recieved 16 characters.
main(): Calling a sync on the output stream
SinkDev::write(): Recieved 8 characters.
main(): Sending 21 characters of data to output stream
SinkDev::write(): Recieved 16 characters.

main(): Asking for 24 characters of data from input stream
SourceDev::read(): Sending 16 characters.
SourceDev::read(): Sending 16 characters.
main(): Calling a sync on the input stream
main(): Asking for 9 characters of data from input stream
SourceDev::read(): Sending 16 characters.

main(): At end of test case
SinkDev::write(): Recieved 5 characters.
SinkDev::write(): Recieved 0 characters.
SinkDev::write(): Recieved 0 characters.
SinkDev::write(): Recieved 0 characters.

********** END **********

Notice that input functionality doesn't change but the output
functionality does. The one cause for concern to me is that for some
reason upon deconstruction the new flush() function is called a bunch of
extras times. I'm not entirely sure why this is happening.
--
    Eddie Carle",eddie@…
5169,documentation on split_winmain() is missing,program_options,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-02-08T06:23:01Z,2011-02-08T06:23:01Z,"It is present in the program_options/parsers.hpp, and I except to see it in the generated docs:
http://www.boost.org/doc/libs/1_45_0/doc/html/program_options/reference.html#header.boost.program_options.parsers_hpp",ilyasokol@…
5163,Support tilde paths when installing.,build,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2011-02-05T14:36:08Z,2011-03-19T09:45:41Z,"On linux, installing boost build using `bjam install --prefix=~/boost/env` installs to a subdirectory called `~`, typically `boost/tools/build/v2/~`. I guess that normally such paths are expanded by the shell so bjam doesn't have to deal with them, but because '--prefix=~/boost/env' appears to be a single argument that didn't happen. Would it be possible to support this?",Daniel James
5158,speed up lowest_bit() for gcc 4.x compatibles,dynamic_bitset,,,Feature Requests,"James E. King, III",new,2011-02-04T00:36:32Z,2019-06-06T13:57:27Z,"The patch provides specialization of lowest_bit() template that utilizes  __builtin_ctz[l][l]() function, available for gcc 4.x-compatible compilers, instead of calculation-intensive path that makes use of integer_log2().

Since lowest_bit() is used in dynamic_bitset::find_first()/find_next(), the patch leads to significant speed up for bitset traversal.

The patch was tested on gcc 4.5.2 x86_64 and icc 11.1 x86_64.

Currently, the patch provides no checks, if __builting_ctz is available for current toolset. I can try to add this, given the overall positive feedback.
",astukalov@…
5157,Assign native socket problem,asio,Boost 1.45.0,,Bugs,chris_kohlhoff,new,2011-02-03T23:25:44Z,2011-03-17T17:05:58Z,"Hi

I'm trying to duplicate accepted/opened socket and pass them to other process.
It works fine under linux. But under Windows I can't assign
this native socket to boost::asio::ip::tcp::socket.
When I try to assign opened native socket to boost socket object
s.assign(boost::asio::ip::tcp::v4(), socketDup)
throws me exception: ""The parameter is incorrect"".
Even if I try to duplicate socket and use them in the same process.
I still got this exception.

The line inside boost throws this exception:
boost_1_45_0\boost\asio\detail\impl\win_iocp_io_service.ipp:

{{{
boost::system::error_code win_iocp_io_service::register_handle(
    HANDLE handle, boost::system::error_code& ec)
{
  if (::CreateIoCompletionPort(handle, iocp_.handle, 0, 0) == 0)	//this function failed
  {
    DWORD last_error = ::GetLastError();
    ec = boost::system::error_code(last_error,
        boost::asio::error::get_system_category());
  }
  else
  {
    ec = boost::system::error_code();
  }
  return ec;
}

}}}

I'm using: VC++ 2008 / Win7

What am I doing wrong?
How can I resolve this problem?
Thanks for help.




Example code:



{{{
boost::asio::io_service io_service;
tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), m_nPort));

std::cout << ""Waiting for connection..."" << std::endl;

tcp::socket socket(io_service);
acceptor.accept(socket);
std::cout << ""connection accepted"" << std::endl;

#ifdef _WIN32
WSAPROTOCOL_INFO pi;
WSADuplicateSocket(socket.native(), get_current_process_id(), &pi);
SOCKET socketDup = WSASocket(pi.iAddressFamily/*AF_INET*/, pi.iSocketType/*SOCK_STREAM*/,
pi.iProtocol/*IPPROTO_TCP*/, &pi, 0, 0);
char sText[] = ""I can use my duplicated socket via WinApi!\r\n"";
int nRet = send(socketDup, sText, strlen(sText), 0);
#else
	//linux
	int socketDup = dup(socket.native());
#endif

try
{
	tcp::socket s(io_service);
	s.assign(boost::asio::ip::tcp::v4(), socketDup); //this throws exception under Windows
	//I can't use my socket via boost lib
	s.send(boost::asio::buffer(""Not work\r\n""));
}
catch(std::exception &e)
{
	std::cerr << e.what() << std::endl; //""The parameter is incorrect"" exception
}
}}}
",a.pacek@…
5156,copying opened socket between processes (Microsoft Windows),asio,Boost 1.45.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-02-03T14:55:05Z,2011-02-19T06:52:44Z,"Hello,
I use WSADuplicateSocket to copy opened socket from one process to another. I try to attach received socket:

boost::asio::io_service io_service;
tcp::socket s1(io_service);
... here I'v got opened socket (receivedSocket) through shared memory from other process
... using WSADuplicateSocket
char sText[] = ""Open socket received !\r\n"";
int nRet = send(receivedSocket, sText, strlen(sText), 0); // this works fine

s1.assign(boost::asio::ip::tcp::v4(), receivedSocket); // here is an error: nr=87 msg=Invalid Parameter
I tried debug and it lead me to call 
CreateIoCompletionPort

What is wrong ? Is it a bug ? Or my misunderstanding ?

Regards, Irek Olchawski.
",irol@…
5155,Boost build can exceed Windows max path length limit,build,Boost 1.44.0,To Be Determined,Bugs,Vladimir Prus,new,2011-02-03T09:49:08Z,2016-06-21T17:15:08Z,"I have been building boost successfully on Windows since 1.33. I usually extract boost do a directory such as:

d:\boost_1_44_0

With 1.44, for the first time I noticed that some binaries were (silently) failing to appear in the build directory. Viewing the build directories, I suspected we were exceeding the windows path limit (256?).

When I renamed to root folder to d:\b, the build suceeded.

I'm afraid I didn't keep the build log, but kept the build command:

bjam toolset=msvc-10.0 link=static runtime-link=static,shared variant=""debug,release"" threading=""multi"" define=""_SECURE_SCL=0"" debug-symbols=""on"" debug-store=database address-model=64 pch=off

I suspect its the long list of options that have extended the path length.

Platform: Windows 7 x64 Enterprise.
",anonymous
5154,1.45.0 python OS X 10.6 test_extending.py hangs,python USE GITHUB,Boost 1.46.1,To Be Determined,Bugs,Dave Abrahams,new,2011-02-03T00:07:00Z,2013-02-19T23:14:56Z,"The following quickstart hangs on system python and EPD 32 6.2.3 32 bit this log for ootb system python.
I'll try this out on svn trunk...
{{{
/usr/local/src/boost_1_45_0/libs/python/example/quickstart
chi:quickstart ix$ sudo /usr/local/src/boost_1_45_0/bjam toolset=darwin  --debug-configuration --verbose-test test
notice: found boost-build.jam at /usr/local/src/boost_1_45_0/libs/python/example/quickstart/boost-build.jam
notice: loading Boost.Build from /usr/local/src/boost_1_45_0/tools/build/v2
notice: Searching /etc /Users/ix /usr/local/src/boost_1_45_0/libs/python/example/quickstart/../../../../tools/build/v2 /usr/share/boost-build /usr/local/src/boost_1_45_0/tools/build/v2/kernel /usr/local/src/boost_1_45_0/tools/build/v2/util /usr/local/src/boost_1_45_0/tools/build/v2/build /usr/local/src/boost_1_45_0/tools/build/v2/tools /usr/local/src/boost_1_45_0/tools/build/v2/contrib /usr/local/src/boost_1_45_0/tools/build/v2/. for site-config configuration file site-config.jam .
notice: Loading site-config configuration file site-config.jam from /usr/local/src/boost_1_45_0/tools/build/v2/site-config.jam .
notice: Searching /Users/ix /usr/local/src/boost_1_45_0/libs/python/example/quickstart/../../../../tools/build/v2 /usr/share/boost-build /usr/local/src/boost_1_45_0/tools/build/v2/kernel /usr/local/src/boost_1_45_0/tools/build/v2/util /usr/local/src/boost_1_45_0/tools/build/v2/build /usr/local/src/boost_1_45_0/tools/build/v2/tools /usr/local/src/boost_1_45_0/tools/build/v2/contrib /usr/local/src/boost_1_45_0/tools/build/v2/. for user-config configuration file user-config.jam .
notice: Loading user-config configuration file user-config.jam from /usr/local/src/boost_1_45_0/tools/build/v2/user-config.jam .
notice: Searching ../../../.. for project-config configuration file project-config.jam .
notice: Loading project-config configuration file project-config.jam from ../../../../project-config.jam .
notice: OSX version on this machine is 10.6.6
notice: will use 'g++' for darwin, condition <toolset>darwin-4.2.1
notice: using strip for <toolset>darwin-4.2.1 at /usr/bin/strip
notice: using archiver for <toolset>darwin-4.2.1 at /usr/bin/libtool
notice: available sdk for <toolset>darwin-4.2.1/<macosx-version>10.5 at /Developer/SDKs/MacOSX10.5.sdk
notice: available sdk for <toolset>darwin-4.2.1/<macosx-version>10.6 at /Developer/SDKs/MacOSX10.6.sdk
notice: [python-cfg] Configuring python...
notice: [python-cfg]   user-specified version: ""2.6""
notice: [python-cfg]   user-specified cmd-or-prefix: ""/System/Library/Frameworks/Python.framework/Versions/2.6""
notice: [python-cfg] Checking interpreter command ""/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python""...
notice: [python-cfg] running command '""/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" 2>&1'
notice: [python-cfg] ...requested configuration matched!
notice: [python-cfg] Details of this Python configuration:
notice: [python-cfg]   interpreter command: ""/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python""
notice: [python-cfg]   include path: ""/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6""
notice: [python-cfg]   library path: ""/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" ""/System/Library/Frameworks/Python.framework/Versions/2.6/lib""
notice: [python-cfg] framework directory is ""/System/Library/Frameworks/Python.framework""
notice: [cmdline-cfg] Detected command-line request for darwin: toolset= darwin version=
notice: [cmdline-cfg] toolset darwin already configured
notice: iostreams: using prebuilt zlib
notice: iostreams: using prebuilt bzip2
...patience...
...patience...
...found 1605 targets...
...updating 9 targets...
darwin.compile.c++ bin/darwin-4.2.1/debug/extending.o
darwin.link.dll ../../../../bin.v2/libs/python/build/darwin-4.2.1/debug/libboost_python.dylib
darwin.link.dll bin/darwin-4.2.1/debug/extending.so
^C
}}}",seb@…
5133,Iostreams code_converter buffer,iostreams,Boost 1.45.0,To Be Determined,Bugs,Jonathan Turkanis,new,2011-01-27T19:29:13Z,2011-01-27T19:29:55Z,"I've been working on converting a the fastcgi++ library over to using 
boost::iostreams from std::iostreams and I've noticed some peculiarities 
that I can't seem to work passed.

For one, how do you change the buffer size of the code_converter adaptor? 
The built in facilities don't seem to actually do anything. I am adding 
to a filtering_stream and have noticed that for the following 
statements...

stream.push(code_converter<MyDevice>(myDevice), 8192);
stream.push(code_converter<MyDevice>(myDevice, 8192));
stream.push(code_converter<MyDevice>(myDevice, 8192), 8192);

All result in a buffer of 128 bytes. I can't figure out a way to actually 
change it. I've been monitoring what is going in the myDevice and it is 
always 128 byte chunks (or less). If I remove the code_converter from the 
stream and go directly in myDevice as per

stream.push(myDevice, 8192);

the buffer is sized as I want it to be and myDevice receives chunks of 
data maxing at 8192 bytes.

Secondly, when using the statement

stream.push(code_converter<MyDevice>(myDevice, 8192));

code_converter calls not MyDevice(const MyDevice&) for copying 
constructing the object but for some reason MyDevice(const MyDevice&, 
const long int&). What is that? Why is code_converter looking for such a 
constructor when I specify a buffer size for the code converter?

Thirdly, I can not for the life of me make the code converter flush it's 
data. If I call a stream.strict_sync() should the code_converter not get 
flushed as well? It doesn't. Everything else in the chain does but the 
code_converter won't fully flush until destruction.",eddie@…
5131,Unified diff rejected by submission system for ticket 5130,trac / subversion,Boost Development Trunk,To Be Determined,Bugs,Douglas Gregor,new,2011-01-27T16:35:10Z,2011-01-27T16:35:10Z,"Unified diff version of the submitted patch was rejected by the submission system as spam. Please investigate.

Ticket URL: <https://svn.boost.org/trac/boost/ticket/5130#comment:1>
",hstong@…
5122,doc/html/mpi/python.html contains dead link,mpi,Boost 1.45.0,To Be Determined,Bugs,Matthias Troyer,new,2011-01-26T11:18:07Z,2013-09-01T09:36:41Z,"http://www.boost.org/doc/libs/1_45_0/doc/html/mpi/python.html has a dead link in the ""Reference"" section.",anonymous
5115,iostreams non_blocking_adapter read bug,iostreams,Boost Development Trunk,To Be Determined,Patches,Jonathan Turkanis,new,2011-01-24T18:31:19Z,2012-03-13T17:09:04Z,"When reading from device resulting amount of read bytes is ignored.

line 31. of boost/iostreams/detail/adapter/non_blocking_adapter.hpp
{{{
     explicit non_blocking_adapter(Device& dev) : device_(dev) { }
     std::streamsize read(char_type* s, std::streamsize n)
     { 
         std::streamsize result = 0;
         while (result < n) {
-            std::streamsize amt = iostreams::read(device_, s, n);
+            std::streamsize amt = iostreams::read(device_, s, n - result);
             if (amt == -1)
                 break;
             result += amt;
         }
         return result != 0 ? result : -1;
     }
}}}
",Mario Suvajac <msuvajac@…>
5114,Unexpected exception from tcp::socket::async_connect,asio,Boost 1.45.0,To Be Determined,Bugs,chris_kohlhoff,new,2011-01-24T09:18:55Z,2015-11-12T09:27:04Z,"ASIO uses two sockets connected to each other through loopback interface (in select_reactor). If, for example, access to loopback is blocked by firewall, then async_connect throws exception, instead of calling given handler with appropriate error code.
",pavel@…
5109,assignment operator could not be generated VC 2008,scope_exit,Boost 1.45.0,To Be Determined,Bugs,nasonov,new,2011-01-22T09:11:28Z,2014-09-16T08:54:44Z,"I get the folowing warnings when using BOOST_SCOPE_EXIT from boost/scope_exit.hpp in VC 2008 SP1


{{{
1>D:\Programming\boost_1_45_0\boost/scope_exit.hpp(84) : warning C4512: 'boost::scope_exit::aux::member<T,Tag>' : assignment operator could not be generated
1>        with
1>        [
1>            T=test::boost_se_params_t_0::boost_se_param_t_0_0,
1>            Tag=boost_se_tag_0_0
1>        ]
1>        .\test.cpp(7) : see reference to class template instantiation 'boost::scope_exit::aux::member<T,Tag>' being compiled
1>        with
1>        [
1>            T=test::boost_se_params_t_0::boost_se_param_t_0_0,
1>            Tag=boost_se_tag_0_0
1>        ]
1>.\test.cpp(7) : warning C4512: 'test::boost_se_params_t_0' : assignment operator could not be generated
1>        .\test.cpp(7) : see declaration of 'test::boost_se_params_t_0'
}}}

This happens under boost 1.45.",borisarb@…
5103,Boost Polygon: The union of these two polygon return an empty result.,polygon,Boost 1.53.0,To Be Determined,Bugs,Andrii Sydorchuk,new,2011-01-20T21:09:57Z,2015-07-02T14:04:08Z,"main.cpp
{{{
#include <boost/polygon/polygon.hpp>
#include <iostream>
namespace gtl = boost::polygon;
using namespace boost::polygon::operators;

// points_array_A_1 (-92810838,3618230) (-94606872,1822196) (-94999302,2214626) (-93203268,4010660) (-92810838,3618230) 
int points_array_A_1[] = {-92810838,3618230,-94606872,1822196,-94999302,2214626,-93203268,4010660,-92810838,3618230};
int points_array_A_1_size =5;

// points_array_B_1 (-95269304,222758) (-95260668,419862) (-95234760,615696) (-95192088,808228) (-95132906,996442) (-95057214,1178814) (-94966028,1354074) (-94860110,1520444) (-94739968,1676908) (-94606618,1822450) (-94999048,2214880) (-95165164,2033778) (-95314770,1838706) (-95446850,1631442) (-95560388,1413510) (-95654368,1186434) (-95728282,951992) (-95781368,711962) (-95813626,468376) (-95824294,222758) (-95269304,222758) 
int points_array_B_1[] = {-95269304,222758,-95260668,419862,-95234760,615696,-95192088,808228,-95132906,996442,-95057214,1178814,-94966028,1354074,-94860110,1520444,-94739968,1676908,-94606618,1822450,-94999048,2214880,-95165164,2033778,-95314770,1838706,-95446850,1631442,-95560388,1413510,-95654368,1186434,-95728282,951992,-95781368,711962,-95813626,468376,-95824294,222758,-95269304,222758};
int points_array_B_1_size =21;


namespace{
	class Output //for printing debug info
	{
	public:
		template<class T>
		static void Print(const gtl::polygon_data<T>& polyData)
		{
			gtl::polygon_data<T>::iterator_type pit = polyData.begin();
			gtl::polygon_data<T>::iterator_type pit_end = polyData.end();
			while(pit!=pit_end)
			{
				gtl::point_data<T> p = (*pit++);
				std::cout<<""(""<<p.x()<<"",""<<p.y()<<"")"";
				std::cout<<"" "";
			}
		}

		template<class T>
		static void Print(std::vector<gtl::polygon_data<T> >& polygonVec)
		{
			int size = polygonVec.size();
			for(int i=0;i<size;i++)
			{
				gtl::polygon_data<T>& poly = polygonVec[i];
				std::cout<<""Polygon ""<<i+1<<"": "";
				Output::Print(poly);
				std::cout<<std::endl;
			}
		}
	};
}

static void AddPolygonData(std::vector<gtl::polygon_data<int> >& group, int* points_array, int size)
{
	//convert c array to boost polygon data
	if(size>0)
	{
		gtl::polygon_data<int> poly_data;
		std::vector<gtl::point_data<int> > poly_points(size);
		int pi=0;
		for(int i=0;i<size;i++)
		{
			int i1 = i*2;
			int i2 = i1+1;
			poly_points[i]=gtl::point_data<int>(points_array[i1],points_array[i2]);
		}
		poly_data.set(poly_points.begin(),poly_points.end());
		group.push_back(poly_data);
	}
}

void testBooleanOps()
{
	//lets declare ourselves a polygon set
	using namespace gtl; //because of operators
	typedef std::vector<polygon_data<int> > PolygonVec;
	PolygonVec group_A;
	PolygonVec group_B;
	PolygonVec group_U;

	//load group A;
	AddPolygonData(group_A,points_array_A_1,points_array_A_1_size);

	//load group B;
	AddPolygonData(group_B,points_array_B_1,points_array_B_1_size);

	
	std::cout<<""union\n"";
	//the result of the union is tore in group U;
	assign(group_U, group_A + group_B);
	Output::Print(group_U);
}

int main() {
 
	testBooleanOps();
    return 0;
}
}}}
",thai@…
5094,Build problem of boost.mpi on non-English Windows systems,build,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-01-19T08:06:04Z,2011-01-19T08:06:04Z,"Autodetection/Build of MPI fails on non-English systems because mpi.jam looks for the Microsoft Compute Cluster Package only in ""C:\Program Files"", but this folder has different names on non-English systems (e.g. ""C:\Programme"" on my German system).
Details are in the mail list thread on build-boost from 2011-01-17 http://lists.boost.org/boost-build/2011/01/24512.php.

Suggested fix is to use an environment variable for the program folder, as suggested by Moritz Hassert in the above mentioned thread. I am just not technically knowledgable enough concerning the Windows OS, the intended locations for the Compute Pack on different systems (32 bit, 64 bit etc.) and the patching process; else I would submit a patch by myself.",frese@…
5092,Modify mpi.jam to use thread safe invocation of IBM compiler,build,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-01-18T23:40:37Z,2011-04-28T08:55:59Z,"IBM POE wrapper, `mpCC`, invokes the thread safe invocation of the IBM compiler, `xlC_r`. This patch achieves the same for Boost MPI configuration.
",hstong@…
5089,Define BOOST_PYTHON_TYPE_ID_NAME for Linux IBM compiler,python USE GITHUB,Boost 1.45.0,To Be Determined,Patches,Dave Abrahams,new,2011-01-18T22:39:07Z,2012-03-06T19:53:24Z,,hstong@…
5086,Fix for possible assertion failure in MSVC isctype.c,tokenizer,Boost Development Trunk,To Be Determined,Patches,jsiek,new,2011-01-18T18:27:00Z,2011-01-27T16:39:13Z,"Ticket #4791 about warning C6328 was closed as fixed. But in fact, the
fix (r66855) only silenced the warning, not addressing the real problem
indicated by the warning.

The problem is explained [http://msdn.microsoft.com/en-us/library/ms245348.aspx here].
In short: (for character classification functions in <cctype>)
> the valid range of values for its input argument is:
>   0 <= c <= 255, plus the special value EOF.
Otherwise, the behavior is undefined. Thus, passing an user provided
value of char (may be signed) can cause UB. The existing comment just
above struct traits_extension addresses the same issue.

Nothing was changed by the static_cast<int> introduced by the fix. It
just expressed what the compiler implicitly does (integral promotion).

Here is the patch to fix the real problem, including a test about the
problem.",Kazutoshi Satoda <k_satoda@…>
5083,"Snow Leopard, Xcode 3.2.x - i) Address-model seeming not to work ii) user-config.jam + build.sh, and iii) insufficient documentation for Boost.build - Jan. 18, 2011",build,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2011-01-18T09:41:02Z,2011-03-31T01:00:48Z,"Preliminary:
- platform: Mac mini Intel Core 2 Duo
- OS: Mac OS X 10.6.x (Snow Leopard)
- IDE and related development tools: Xcode 3.2.5
- BOOST versions: 1.43.0 .. 1.45.0

PART I: multi-architecture

Unable to build multi-architecture, even though using the address-model option for bjam, according your Boost.build V2 documentation. Results are as follows, with Boost v. 1.45.0 (similar results with previous versions):
1. the address-model option is not given to bjam. The standard gcc (g++) compiler is used:
size of the build folder: 186.3 MB. Architecture build (found with the ""lipo -i"" command): x86_64
2. address-model set to 32:
size of the build folder: 184.1 MB. Architecture build (found with the ""lipo -i"" command): x86_64
3. address-model set to 32_64:
size of the build folder: 184.1 MB. Architecture build (found with the ""lipo -i"" command): x86_64

In consequence: it seems that the address-model option remains uneffective. Unable to build multi-architecture. Besides, the 32-bit architecture lonely cannot be build too.

#================================

PART II: user-config.jam, build.sh

In my attempt to build multi-architecture BOOST libraries for Mac OS X, I tried several BOOST initial configurations through user-config.jam and build.sh located in /tolls/jam/src for the 1.45.0 version (located elsewhere for previuous versions - TBV, namely to be verified ... again). Please find below my results and, in my own opinions, tehy likely are unsecure in terms of quality of sofware development (kindly see the EIFFEL - MEYER or MAYER - handbook for this topics) :
1. user-config-jam:
According to the BOOST.Build V2 documentation, I set ""using gcc"" with g++. It seems that it has an influence upon the build libraries (sizes different) compared to let this option not seen by bjam (in other words, keeping: #using gcc : : ;)
2. user-config.jam, build.sh
After having looked at the build.sh file (TBV) and ahving seen that darwin is used to set the compiler to : cc (NB the ""basic"" C compiler), and even it is not indicated in teh Boost.build documentation, I tried to use the following rule:

using darwin : : g++;
It seems this has an influence, but I am not sure. Besdes, I am not sure that this is correct, because teh documentation remains unsufficient on this point in particular, on Apple generally.


#================================

PART III: BOOST.build V2 documentation
Unsufficient. A fairly big lack of real examples, in particular for the bjam section. Very useful but lacking: a summary of EVERY option of bjam in the command-line context. Etc.



#================================

PART IV: miscellaneous
1. No check nor install check seeming to be present or allowed for BOOST. Expected a good new feature
2. IMPORTANT
No possibility to see, for example before compilation, he complete or even partial set of configuration parameters used, such as: CC, CXX, CFLAGS, CXXFLAGS, LDFLAGS, etc ... very welcome for debugging 
3. IMPORTANT
CPP and CXXCPP seem not to be allowed to be set. How to fix that ? GNU compilers need thsi, because, according to their manuals, multi-architecture building needs : CPP""gcc -E"", CXXCPP=""g++ -E"", with : CC=""gcc -arch i386 -arch x86_64"", and CXX=""g++ -arch i386 -arch x86_64"" for example.
",doc0.delphin@…
5065,Valgrind complaint when using Boost MPI,mpi,Boost 1.45.0,To Be Determined,Patches,Douglas Gregor,new,2011-01-13T02:54:13Z,2013-01-01T11:12:48Z,"I am using the latest Boost library (version 1.45.0) on Ubuntu. I have built
Boost from the source using the bjam.

boost::mpi::all_reduce uses boost::mpi::broadcast which seems to generate
annoying invalid write errors under valgrind. The problem points to the
line 47 in boost/mpi/detail/packed_oprimitive.hpp in const std::size_t &size() const
function. I changed the function to:

    const std::size_t& size() const
    {
      const_cast<std::size_t &>(size_) = buffer_.size();
      return size_;
    }

and the valgrind complaint seems to be gone. Const_cast seems less than ideal, but
it fixes the problem.",dongryel@…
5027,Extension of Boost.Range algorithms,algorithm,Boost 1.45.0,To Be Determined,Feature Requests,Marshall Clow,new,2011-01-01T12:21:35Z,2014-06-05T18:20:27Z,"Maybe an idea to extend Boost.Range algorithms:

- copy_if
- for_each_if
- transform_if
- contains (/contains_if, shortcut for std::find(...) != end)
- all (/all_if)
- none(/none_if, shortcut for std::find(...) == end))
- bsearch (Austern 13.2.1.2)

Some of them are listed in STLAlgorithmExtensions.
",gast128 <gast128@…>
5024,Boost NVCC/CUDA fixes (MPL+concepts),mpl,Boost 1.45.0,To Be Determined,Patches,Aleksey Gurtovoy,new,2010-12-30T18:01:48Z,2011-11-11T02:29:26Z,"Fix traits, MPL problems for gcc+nvcc compiles.
BOOST_DEDUCED_TYPENAME doesnt work for nvcc because EDG and GCC treat them differently.
That was fixed manually. 

",anonymous
5023,Can not build Boost.Python,build,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,new,2010-12-29T14:28:47Z,2010-12-30T15:09:59Z,"I have installed Python 2.6
when i runing ""bjam"" i have messages:


{{{
warning: No python installation configured and autoconfiguration
note: failed.  See http://www.boost.org/libs/python/doc/building.html
note: for configuration instructions or pass --without-python to
note: suppress this message and silently skip all Boost.Python targets
}}}

After I add add line ""using python : 2.6 ; "" to ""project-config.jam"" I have this warning message again.

Then I add absolute path to python in ""project-config.jam"". This is not working too.

I run bjam with ""--debug-configuration"" option and have messages:

{{{
notice: [python-cfg] running command '""C:\Python26\python.exe"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" 2>&1'
notice: [python-cfg] ...does not invoke a working interpreter
notice: [python-cfg] No working Python interpreter found.
}}}

But when I run
{{{
""C:\Python26\python.exe"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))""
}}}
manualy, I have correct results.

Ok. Next I modify ""tools\build\v2\tools\python.jam""

{{{
local rule shell-cmd ( cmd )
{
    debug-message running command '$(cmd)"" 2>&1""' ;
    x = [ SHELL $(cmd)"" 2>&1"" : exit-status ] ;
    
    debug-message CMD ""$(cmd)"" ; <<<<<<< add this string	
    debug-message RESULT ""$(x)"" ;  <<<<<<< add this string
	
	if $(x[2]) = 0
    {
        return $(x[1]) ;
    }
    else
    {
        return ;
    }
}
}}}

and run ""bjam --debug-configuration"" again

Result:

{{{
notice: [python-cfg] running command '""C:\Python26\python.exe"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' %(version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" 2>&1'
notice: [python-cfg] CMD ""C:\Python26\python.exe"" -c ""from sys import *; print('
version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))""
notice: [python-cfg] RESULT ""C:\Python26\python.exe"" -c ""from"" <<<< (here is error text at Russian. He said what this is not correct path and shell can not execute this command)
notice: [python-cfg] ...does not invoke a working interpreter
notice: [python-cfg] No working Python interpreter found.
}}}

I don't know why he is trim command.
",hacenator@…
5020,build.bat selects incorrect toolset,Building Boost,Boost 1.45.0,To Be Determined,Bugs,,new,2010-12-24T13:21:48Z,2010-12-24T13:21:48Z,"Building on Win7 64-bit.  In function ''':Test_Path''', statement ''set test=%~$PATH:1'' is not getting errorlevel 1 when the file is not found (win7 bug?).  This results in msvc being selected as the toolset.  As a workaround, I changed the line (in Test_PATH):[[BR]]

''if not errorlevel 1 set FOUND_PATH=%~dp$PATH:1''
[[BR]]to:[[BR]]
''if not errorlevel 1 if _%test% NEQ _ set FOUND_PATH=%~dp$PATH:1''


All callers of Test_Path were also changed to test FOUND_PATH for a value.  A cleaner solution may be able to remove the errorlevel 1 tests.

...chris.",webstech@…
5001,Failure to compile boost_1_45 and boost-trunk on ia64 (itanium2) with toolset intel-linux,build,Boost 1.45.0,Boost 1.49.0,Bugs,Vladimir Prus,new,2010-12-18T20:19:23Z,2013-04-12T14:52:21Z,"Hi all,

I have tried to compile boost_1_45_0 using the Intel compiler on an Itanium machine, but it seems to fail with a segfault:

{{{
xxx@cn002:~/src/boost_1_45_0> ./bootstrap.sh --with-toolset=intel-linux --show-libraries --prefix=$HOME
Building Boost.Jam with toolset intel-linux... 
Failed to build Boost.Jam
Consult 'bootstrap.log' for more details
xxx@cn002:~/src/boost_1_45_0> cat bootstrap.log 
###
### Using 'intel-linux' toolset.
###
rm -rf bootstrap
mkdir bootstrap
icc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c
expand.c(85): warning #181: argument is incompatible with corresponding format string conversion
          printf( ""expand '%.*s'\n"", end - in, in );
                                     ^

./bootstrap/jam0 -f build.jam --toolset=intel-linux --toolset-root= clean
...found 1 target...
...updating 1 target...
[DELETE] clean
./build.sh: line 13: 27407 Segmentation fault      (core dumped) $@
}}}

So far, I have gathered the following information:
* I've done this on two different Itanium machines I've got access to. It fails with the same error message on both machines.
* I have used Intel compilers 11.1, 11.0, 10.1. Same error message with all of them.
* Compiling on x86_64 with the above compilers works as expected.

Next, I have checked out the boost trunk from the subversion rep. Here, it does not offer any libraries to compile:

{{{
xxx@cn002:~/src/boost-trunk> ./bootstrap.sh --with-toolset=intel-linux --show-libraries
Building Boost.Jam with toolset intel-linux... tools/build/v2/engine/src/bin.linuxia64/bjam

The following Boost libraries have portions that require a separate build
and installation step. Any library not listed here can be used by including
the headers only.

The Boost libraries requiring separate building and installation are:
xxx@cn002:~/src/boost-trunk> 
}}}

I decided to still give it a go:

{{{
xxx@cn002:~/src/boost-trunk> ./bootstrap.sh --with-toolset=intel-linux --with-libraries=iostreams,mpi,serialization
Building Boost.Jam with toolset intel-linux... tools/build/v2/engine/src/bin.linuxia64/bjam
Unicode/ICU support for Boost.Regex?... not found.
Generating Boost.Build configuration in project-config.jam...

Bootstrapping is done. To build, run:

    ./bjam
    
To adjust configuration, edit 'project-config.jam'.
Further information:

   - Command line help:
     ./bjam --help
     
   - Getting started guide: 
     http://www.boost.org/more/getting_started/unix-variants.html
     
   - Boost.Build documentation:
     http://www.boost.org/boost-build2/doc/html/index.html

xxx@cn002:~/src/boost-trunk> ./bjam
Segmentation fault (core dumped)
}}}

No luck either :(

At this point, I'm running out of ideas - anything else I could try? 

Cheers,
Stefan
",Stefan Janecek <stejanecek@…>
4988,[units] improve error messages when quantities are not convertible into one another.,units,Boost 1.46.0,To Be Determined,Feature Requests,Steven Watanabe,new,2010-12-15T18:56:28Z,2011-07-14T23:06:43Z,"Currently, if the quantities are not convertible one into the other (which depends on the included header, etc), the error message is pretty long and unreadable.
Specifically in terms of what conversion is being attempted. I suggest the authors consider an improved compiler error message.
",Alfredo Correa <alfredo.correa@…>
4976,boost-jam 3.1.18 + mingw-w64,build,Boost.Jam 3.1.18,To Be Determined,Bugs,Vladimir Prus,new,2010-12-13T10:22:04Z,2011-03-31T00:59:41Z,"my boost-jam 3.1.18 doesn't work with mingw-w64 gcc where my boost-jam 3.1.17 does (using ""build.bat gcc"")

Error is :
C:\devenv\src\boost-jam\3.1.18>build.bat gcc
###
### ""Could not find a suitable toolset.""
###
### You can specify the toolset as the argument, i.e.:
###     .\build.bat msvc
###
### Toolsets supported by this script are: borland, como, gcc, gcc-nocygwin,
###     intel-win32, metrowerks, mingw, msvc, vc7, vc8, vc9, vc10
###
###
### ""Could not find a suitable toolset.""
###

To reproduce:
** Download a mingw-w64 toolchain from mingw-w64 at sourceforge.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/sezero_4.5_20101002/mingw-w32-bin_i686-mingw_20101002_4.5_sezero.zip/download
** extract somewhere,
** Add the bin directory in the download to your path
** change to the boost-jam 3.1.18 src directory
** execute ""build.bat gcc""

To see expected result, use boost-jam 3.1.17 instead.

",Jarrod Chesney <jarrod.chesney@…>
4969,transform_iterator won't work with non-const operator() call for function object,iterator,Boost 1.45.0,To Be Determined,Bugs,jeffrey.hellrung,new,2010-12-09T01:56:02Z,2014-02-23T16:18:00Z,"transform_iterator declare it's copied function object as:
{{{#!c++
    UnaryFunc m_f;
}}}

And it's dereference function as:
{{{#!c++
    typename super_t::reference dereference() const
    { return m_f(*this->base()); }
}}}
which makes it impossible to cooperate with function object with non-const operator() overloading, and and it will also make transformed adaptor in boost::range not work:
{{{#!c++
struct Fun
{
    typedef bool result_type;
    
    bool operator()(int a)
    {
        return a != 1;
    }
};
    Fun f;
    boost::find(all|boost::adaptors::transformed(f), true);
}}}

A boost::ref won't work here since the result has no result_type defined

And the only solution would be using a boost::function to hold the original function object, however, doing so will give unnecessary run time cost.

I suggest change the UnaryFunc m_f; definition to mutable, so that it will work with non-const functor.
{{{#!c++
    UnaryFunc mutable m_f;
}}}
",zhuo.qiang@…
4954,Unused parameter warning in boost/parameter/aux_/tagged_argument.hpp,parameter,Boost 1.44.0,To Be Determined,Patches,Daniel Wallin,new,2010-12-07T20:31:47Z,2010-12-07T20:31:47Z,There is an unused parameter warning on line 123 of tagged_argument.hpp with GCC 4.3.0 on Mac OS 10.6.4. The attached patch fixes it.,Rich McKeever <richmckeever@…>
4951,Boost.Tuple: implement set_open(const char *),tuple,Boost 1.45.0,To Be Determined,Feature Requests,Joel de Guzman,new,2010-12-07T20:14:57Z,2010-12-08T17:33:41Z,"Current implementation of Boost.Tuple IO manipulators allows define only single character for start of tuple, delimiter of items and for end of tuple.

1. Sometimes it is convenient to have no character before and after tuple data.
2. Sometimes it is convenient to wrap tuple in more that single character.

For example output tuple as HTML table row: with open string ""<tr><td>"", delimiter ""</td><td>"" and end string ""</td></tr>"", so (1 2 3) will be outputted as correct HTML table row ""<tr><td>1</td><td>2</td><td>3</td></tr>"".
",Vladimir Rutsky <altsysrq@…>
4944,Summary of failed unit tests,build,Boost 1.45.0,To Be Determined,Feature Requests,Vladimir Prus,new,2010-12-07T09:19:47Z,2010-12-08T09:35:25Z,"While unit testing your component, you want to see if all pass, or if something fails.[[BR]]
Currently, bjam only gives a statement how many tests fail at the end. Not which tests.[[BR]]
It would be nice to have a summary listing of the failed tests at the end.[[BR]]
The -q option is not applicable here, because you eventually want to see the current status of all unit tests.",Thomas Heller
4942,Searching for boost-build.jam,build,Boost 1.45.0,To Be Determined,Feature Requests,Vladimir Prus,new,2010-12-06T15:44:37Z,2011-03-31T00:58:38Z,"Upon invocation bjam should also look for boost-build.jam in the Boost tree specified by the --boost=/path/to/Boost option if it can not find it anywhere else in its normal search path.

This would allow any Boost-like library, using the directory structure suggested by the sandbox, to have its jamfiles execute properly even if it were not located within a Boost tree or beneath a top-level directory with its own boost-build.jam, as long as the bjam command had a --boost/path/to/Boost option pointing to a Boost distribution.",Edward Diener
4917,uBLAS element-wise power function,uBLAS,Boost Development Trunk,To Be Determined,Patches,Gunter,new,2010-12-01T17:27:10Z,2011-10-28T06:14:50Z,"I would like to introduce element-wise power function. There are four functions in the patch:
* `pow( vector_expression, scalar )`
* `pow( matrix_expression, scalar )`
* `element_pow( vector_expression, vector_expression )`
* `element_pow( matrix_expression, matrix_expression )`

== Synopsis ==

These functions behave naturally. Let `v` is a vector, `m` is a matrix, `p` is a scalar then 
`pow( v, p )` and `pow( m, p )` just raise each element to the power `p`. `element_pow( v1, v2)` is `v1[i] ^ v2[i]`. `element_pow( m1, m2)` works similarly.

== Rationalize ==

http://ublas.sourceforge.net mentions ""...elements wise basic functions (sin,cos,log,exp,abs,max,min,etc...)""

== Patch ==

The patch contains implementation and also simple test routines.
",matwey.kornilov@…
4915,Iterator documentation does not list header files,iterator,Boost 1.45.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2010-11-30T20:30:05Z,2012-11-21T19:44:45Z,"The documentation of the iterator library does not list header files that need to be included to use all of its components. For example:

http://www.boost.org/doc/libs/1_45_0/libs/iterator/doc/iterator_adaptor.html

There is no information there about which files are necessary to get access to the class described in the documentation.

",marcin.zalewski@…
4913,file_descriptor_impl::read doesn't handle EINTR,iostreams,Boost 1.39.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-11-30T16:11:53Z,2010-11-30T16:22:46Z,"when using boost::iostreams::stream_buffer<boost::iostreams::file_descriptor_source>, reads from the stream may unnecessarily set the badbit flag. the reason is that in the underlying call to read() the EINTR condition is not handled. the read() should be restarted in this case.

i'm attaching a non tested patch. it does the same thing that libstdc++ does (function __basic_file<char>::xsgetn).

this is easy to reproduce in gdb. here's why: http://sourceware.org/gdb/onlinedocs/gdb/Interrupted-System-Calls.html",Todor Buyukliev <todor@…>
4908,Bug in program_options,program_options,Boost 1.45.0,To Be Determined,Bugs,Vladimir Prus,reopened,2010-11-29T22:03:34Z,2014-05-02T12:32:01Z,"In a simple example, I get  errors

OS Linux x64 (Kubuntu 10.10)
g++ 4.5  
Example (boost/libs/program_options/example/first.cpp)

#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<int>(), ""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 1;
        }

        if (vm.count(""compression"")) {
            cout << ""Compression level was set to ""
                 << vm[""compression""].as<int>() << "".\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;
}

I have[[BR]]
/home/dix/Projects/Test/CppApplication_1/main.cpp:13: undefined reference to `boost::program_options::options_description::m_default_line_length'
/home/dix/Projects/Test/CppApplication_1/main.cpp:13: undefined reference to `boost::program_options::options_description::m_default_line_length'
/home/dix/Projects/Test/CppApplication_1/main.cpp:13: undefined reference to `boost::program_options::options_description::options_description(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, unsigned int)'
/home/dix/Projects/Test/CppApplication_1/main.cpp:15: undefined reference to `boost::program_options::options_description::add_options()'
/home/dix/Projects/Test/CppApplication_1/main.cpp:15: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)'
/home/dix/Projects/Test/CppApplication_1/main.cpp:17: undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, boost::program_options::value_semantic const*, char const*)'
/home/dix/Projects/Test/CppApplication_1/main.cpp:19: undefined reference to `boost::program_options::variables_map::variables_map()'
/home/dix/Projects/Test/CppApplication_1/main.cpp:20: undefined reference to `boost::program_options::store(boost::program_options::basic_parsed_options<char> const&, boost::program_options::variables_map&, bool)'
/home/dix/Projects/Test/CppApplication_1/main.cpp:21: undefined reference to `boost::program_options::notify(boost::program_options::variables_map&)'
/home/dix/Projects/Test/CppApplication_1/main.cpp:24: undefined reference to `boost::program_options::operator<<(std::basic_ostream<char, std::char_traits<char> >&, boost::program_options::options_description const&)'
build/Debug/GNU-Linux-x86/main.o: In function `~validation_error':
/usr/local/include/boost/program_options/errors.hpp:153: undefined reference to `vtable for boost::program_options::validation_error'
build/Debug/GNU-Linux-x86/main.o: In function `value_semantic_codecvt_helper':
/usr/local/include/boost/program_options/value_semantic.hpp:91: undefined reference to `vtable for boost::program_options::value_semantic_codecvt_helper<char>'
build/Debug/GNU-Linux-x86/main.o: In function `~value_semantic_codecvt_helper':
/usr/local/include/boost/program_options/value_semantic.hpp:91: undefined reference to `vtable for boost::program_options::value_semantic_codecvt_helper<char>'
build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::variables_map::operator[](std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const':
/usr/local/include/boost/program_options/variables_map.hpp:150: undefined reference to `boost::program_options::abstract_variables_map::operator[](std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const'
build/Debug/GNU-Linux-x86/main.o: In function `~variables_map':
/usr/local/include/boost/program_options/variables_map.hpp:143: undefined reference to `vtable for boost::program_options::variables_map'
build/Debug/GNU-Linux-x86/main.o: In function `basic_command_line_parser':
/usr/local/include/boost/program_options/detail/parsers.hpp:43: undefined reference to `boost::program_options::detail::cmdline::cmdline(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)'
build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser<char>::options(boost::program_options::options_description const&)':
/usr/local/include/boost/program_options/detail/parsers.hpp:51: undefined reference to `boost::program_options::detail::cmdline::set_options_description(boost::program_options::options_description const&)'
build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser<char>::style(int)':
/usr/local/include/boost/program_options/detail/parsers.hpp:69: undefined reference to `boost::program_options::detail::cmdline::style(int)'
build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser<char>::extra_parser(boost::function1<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&>)':
/usr/local/include/boost/program_options/detail/parsers.hpp:77: undefined reference to `boost::program_options::detail::cmdline::set_additional_parser(boost::function1<std::pair<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&>)'
build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::basic_command_line_parser<char>::run()':
/usr/local/include/boost/program_options/detail/parsers.hpp:104: undefined reference to `boost::program_options::detail::cmdline::run()'
build/Debug/GNU-Linux-x86/main.o: In function `std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > boost::program_options::to_internal<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)':
/usr/local/include/boost/program_options/detail/convert.hpp:79: undefined reference to `boost::program_options::to_internal(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
build/Debug/GNU-Linux-x86/main.o:(.rodata._ZTVN5boost15program_options11typed_valueIicEE[vtable for boost::program_options::typed_value<int, char>]+0x38): undefined reference to `boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool) const'
build/Debug/GNU-Linux-x86/main.o:(.rodata._ZTVN5boost15program_options20invalid_option_valueE[vtable for boost::program_options::invalid_option_value]+0x20): undefined reference to `boost::program_options::validation_error::what() const'
build/Debug/GNU-Linux-x86/main.o:(.rodata._ZTIN5boost15program_options11typed_valueIicEE[typeinfo for boost::program_options::typed_value<int, char>]+0x18): undefined reference to `typeinfo for boost::program_options::value_semantic_codecvt_helper<char>'
build/Debug/GNU-Linux-x86/main.o: In function `boost::program_options::typed_value<int, char>::name() const':
/usr/local/include/boost/program_options/detail/value_semantic.hpp:26: undefined reference to `boost::program_options::arg'
/usr/local/include/boost/program_options/detail/value_semantic.hpp:28: undefined reference to `boost::program_options::arg'
build/Debug/GNU-Linux-x86/main.o: In function `void boost::program_options::validate<int, char>(boost::any&, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, int*, long)':
/usr/local/include/boost/program_options/detail/value_semantic.hpp:85: undefined reference to `boost::program_options::validators::check_first_occurrence(boost::any const&)'
/usr/local/include/boost/program_options/detail/value_semantic.hpp:91: undefined reference to `boost::program_options::invalid_option_value::invalid_option_value(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
build/Debug/GNU-Linux-x86/main.o: In function `std::basic_string<char, std::char_traits<char>, std::allocator<char> > const& boost::program_options::validators::get_single_string<char>(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool)':
/usr/local/include/boost/program_options/detail/value_semantic.hpp:58: undefined reference to `boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
/usr/local/include/boost/program_options/detail/value_semantic.hpp:62: undefined reference to `boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
build/Debug/GNU-Linux-x86/main.o: In function `validation_error':
/usr/local/include/boost/program_options/errors.hpp:139: undefined reference to `vtable for boost::program_options::validation_error'",dix75@…
4903,Serialization library in Boost 1.45 is unable to read archive created with Boost 1.39,serialization,Boost 1.46.0,To Be Determined,Bugs,Robert Ramey,new,2010-11-29T09:38:23Z,2011-11-17T12:38:58Z,"The way the serialization library is handling object version and property information has obviously changed so that an attempt to read an archive with a simple object fails with version 1.45.

The archive header is correctly read in (as opposed to 1.44) but an attempt to read a simple object fails because the version 1.45 is reading too much data.",Rüdiger Brünner <rbruenner@…>
4899,Parallel graphs don't work with named vertices,graph,Boost 1.45.0,To Be Determined,Bugs,ngedmond,new,2010-11-27T16:43:16Z,2012-04-16T17:56:49Z,"`brandes_betweenness_centrality` doesn't work with named vertices.

Here are two reproducible examples: https://gist.github.com/f02f18f30f0eef146a58

This is probably caused by the lack of a `local()` function in the `hashed_distribution` declared in `named_graph.hpp`.

See also this discussion on the mailing list: http://lists.boost.org/boost-users/2010/11/64489.php",cpaolino@…
4896,Bjam doesn't build correctly with Intel compiler when both vc8 and vc9 are installed on the same machine.,Building Boost,Boost 1.45.0,To Be Determined,Bugs,,new,2010-11-25T11:06:16Z,2010-11-25T11:06:16Z,"== Setup ==
With the following machine setup:
* Windows 7
* Intel Pro C++ compiler for windows 11.1.067
* Visual studio 2005 and Visual studio 2008

== Command ==
{{{#!sh
""C:\Program Files (x86)\Intel\Compiler\11.1\067\bin\iclvars.bat"" intel64 vs2005

bjam --toolset=""intel-11.1.067"" ""-sINTEL_PATH= C:\Program Files (x86)\Intel\Compiler\11.1\067\bin\intel64"" ""-sINTEL_BASE_MSVC_TOOLSET=vc8"" ""-sINTEL_VERSION=11"" --build-type=complete
}}}
== Problem ==

This builds and creates dlls. However, upon inspection with dependency walker, the dlls are linking with vc9 rather than vc8.

== Workaround ==
Renaming the visual studio 2008 directory to something different, and rebuilding boost. The dlls then correctly link with visual studio 2005.",Matt <MBond@…>
4888,codecvt_error_category is not thread-safe,filesystem,Boost 1.45.0,To Be Determined,Bugs,Beman Dawes,new,2010-11-24T08:13:04Z,2010-11-24T08:13:04Z,"The boost::filesystem3::codecvt_error_category uses unprotected function-local static variable of type codecvt_error_cat, which is not POD. One thread may half-initialize this value when the other thread will acquire and use a reference to the not yet constructed error category. The object must be protected with call_once or a similar technique.",Andrey Semashev
4886,options_description clear() method,program_options,Boost 1.45.0,To Be Determined,Feature Requests,Vladimir Prus,new,2010-11-23T20:27:58Z,2010-11-27T14:13:07Z,"For a project I'm working on, I consistently add the following public clear() method to the boost/program_options/options_description.hpp header file.  It's possible that others may find this clear() method useful as well.

     void clear() 
     {
         m_options.clear();
         belong_to_group.clear();
         groups.clear();
     }
",mid9090@…
4874,multi_array compile errors using Visual C++ 2010 in debug mode,multi_array,Boost 1.58.0,To Be Determined,Bugs,Ronald Garcia,reopened,2010-11-21T14:06:41Z,2017-08-15T12:59:46Z,"This is a long standing problem and it should have been fixes already [1], but in boost release 1.45 it still exists.

When using a multi_array and engaging the copy constructor or assignment operator of a multi_array in debug mode on Visual C++ 2010 the following errors are generated. This was done using the boost 1.45 release on Visual C++ 2010 on Windows 7 x64 targeting a x64 build:

{{{
1>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2216): error C2665: 'std::_Copy_impl' : none of the 2 overloads could convert all the argument types
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2182): could be '_OutIt std::_Copy_impl<_InIt,_OutIt>(_InIt,_InIt,_OutIt,std::input_iterator_tag,std::output_iterator_tag)'
1>          with
1>          [
1>              _OutIt=boost::detail::multi_array::array_iterator<char,char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::sub_array<char,0x01>>,
1>              _InIt=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>
1>          ]
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2191): or       '_OutIt std::_Copy_impl<_InIt,_OutIt>(_InIt,_InIt,_OutIt,std::random_access_iterator_tag,std::random_access_iterator_tag)'
1>          with
1>          [
1>              _OutIt=boost::detail::multi_array::array_iterator<char,char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::sub_array<char,0x01>>,
1>              _InIt=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>
1>          ]
1>          while trying to match the argument list '(boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>, boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>, boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>, boost::detail::iterator_category_with_traversal<Category,Traversal>, boost::detail::iterator_category_with_traversal<Category,Traversal>)'
1>          with
1>          [
1>              T=char,
1>              TPtr=const char *,
1>              NumDims=boost::mpl::size_t<0x02>,
1>              Reference=boost::detail::multi_array::const_sub_array<char,0x01>
1>          ]
1>          and
1>          [
1>              T=char,
1>              TPtr=const char *,
1>              NumDims=boost::mpl::size_t<0x02>,
1>              Reference=boost::detail::multi_array::const_sub_array<char,0x01>
1>          ]
1>          and
1>          [
1>              T=char,
1>              TPtr=char *,
1>              NumDims=boost::mpl::size_t<0x02>,
1>              Reference=boost::detail::multi_array::sub_array<char,0x01>
1>          ]
1>          and
1>          [
1>              Category=std::input_iterator_tag,
1>              Traversal=boost::random_access_traversal_tag
1>          ]
1>          and
1>          [
1>              Category=std::input_iterator_tag,
1>              Traversal=boost::random_access_traversal_tag
1>          ]
1>          C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\xutility(2227) : see reference to function template instantiation '_OutIt std::_Copy_impl<_Iter,_OutIt>(_InIt,_InIt,_OutIt,std::tr1::false_type)' being compiled
1>          with
1>          [
1>              _OutIt=boost::detail::multi_array::array_iterator<char,char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::sub_array<char,0x01>>,
1>              _Iter=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>,
1>              _InIt=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>
1>          ]
1>          E:\working_copies\schism_x64\externals_vc100\inc\boost\boost/multi_array/multi_array_ref.hpp(489) : see reference to function template instantiation '_OutIt std::copy<boost::detail::multi_array::array_iterator<T,TPtr,NumDims,Reference>,boost::detail::multi_array::array_iterator<T,T *,NumDims,boost::detail::multi_array::sub_array<T,0x01>>>(_InIt,_InIt,_OutIt)' being compiled
1>          with
1>          [
1>              _OutIt=boost::detail::multi_array::array_iterator<char,char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::sub_array<char,0x01>>,
1>              T=char,
1>              TPtr=const char *,
1>              NumDims=boost::mpl::size_t<0x02>,
1>              Reference=boost::detail::multi_array::const_sub_array<char,0x01>,
1>              _InIt=boost::detail::multi_array::array_iterator<char,const char *,boost::mpl::size_t<0x02>,boost::detail::multi_array::const_sub_array<char,0x01>>
1>          ]
1>          E:\working_copies\schism_x64\externals_vc100\inc\boost\boost/multi_array.hpp(377) : see reference to function template instantiation 'boost::multi_array_ref<T,NumDims> &boost::multi_array_ref<T,NumDims>::operator =<boost::multi_array<T,0x02>>(const ConstMultiArray &)' being compiled
1>          with
1>          [
1>              T=char,
1>              NumDims=0x02,
1>              ConstMultiArray=boost::multi_array<char,0x02>
1>          ]
1>          E:\working_copies\schism_x64\externals_vc100\inc\boost\boost/multi_array.hpp(375) : while compiling class template member function 'boost::multi_array<T,NumDims> &boost::multi_array<T,NumDims>::operator =(const boost::multi_array<T,NumDims> &)'
1>          with
1>          [
1>              T=char,
1>              NumDims=0x02
1>          ]
1>          e:\working_copies\schism_x64\schism\scm_gl_util\src\scm\gl_util\font\font_face.h(60) : see reference to class template instantiation 'boost::multi_array<T,NumDims>' being compiled
1>          with
1>          [
1>              T=char,
1>              NumDims=0x02
1>          ]
}}}

[1] https://svn.boost.org/trac/boost/ticket/4539",chrislu
4870,ISO Timestamp Parsing Bug,date_time,Boost 1.44.0,To Be Determined,Patches,az_sw_dude,new,2010-11-19T14:57:38Z,2011-04-11T18:22:22Z,"boost::posix_time::from_iso_string() converts ""20100713"" into ""20100713T201007.300000"" which is obviously wrong.

The error is caused by boost::date_time::split().

The attached patch corrects split() so that an exception is thrown later in parse_delimited_time_duration().

The problem is reproducible in Boost 1.42.0 and 1.44.0.

This simple example demonstrates the issue:

const boost::posix_time::ptime time=boost::posix_time::from_iso_string(""20100713"");
std::cout << ""Converted: "" << boost::posix_time::to_iso_string(time) << std::endl;

Converted: 20100713T201007.300000

Maybe someone can apply this patch.",peter.klotz@…
4866,Tests don't account for locally-built bzip2 library,iostreams,Boost 1.44.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-11-17T19:48:19Z,2014-03-12T02:43:17Z,"I am building the iostreams library with {{{-sBZIP2_SOURCE=c:/work/bzip2-1.0.6}}}, so the build system creates its own bzip2 library in {{{bin.v2/libs/iostreams/build/bzip2/.../threading-multi/boost_bzip2-vc100-mt-gd-1_44.dll}}}.  However, when I try to run the tests through {{{bjam}}} from the command prompt, I see the tests fail.  So I prepared the same environment used by the tests, and find myself facing a dialog that complains that it can't find {{{LIBBZ2.DLL}}}.  It seems like Boost.Build is confused about the name of the DLL on which it depends.",Dave Abrahams
4864,Support for 64-bit ICU,build,Boost 1.44.0,To Be Determined,Bugs,Vladimir Prus,new,2010-11-17T17:21:50Z,2012-09-18T12:37:25Z,"On windows, anyway, ICU's 64-bit binaries tend to appear in a subdirectory called {{{lib64/}}}, but the Jamfile seems to assume that ICU will be in {{{lib/}}}.",Dave Abrahams
4860,Rational does not play well with uBlas,uBLAS,Boost 1.44.0,To Be Determined,Bugs,Gunter,new,2010-11-16T20:00:54Z,2010-11-16T20:00:54Z,"I'm trying to solve a rational linear system using boost/rational + uBlas. I've tried to copy many examples on the web that all follow the same line:

{{{
	typedef permutation_matrix<rational_t> pmatrix;
	pmatrix pm(a.size1());
	matrix_t inverse(a.size1(), a.size2());
	lu_factorize(a, pm);

	inverse.assign(identity_matrix<rational_t>(a.size1()));
	lu_substitute(a, pm, inverse);
}}}

a is of type matrix_t, which is defined as follows:
{{{
typedef rational<long long int> rational_t;
typedef matrix<rational_t> matrix_t;
}}}

Compilation fails on the lu_factorize function call with the following error messages:
{{{
In file included from interpolator.cpp:5:
/usr/local/include/boost/numeric/ublas/lu.hpp: In function ‘void boost::numeric::ublas::swap_rows(const PM&, MV&, boost::numeric::ublas::matrix_tag) [with PM = boost::numeric::ublas::permutation_matrix<boost::rational<long long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >, MV = boost::numeric::ublas::matrix<boost::rational<long long int>, boost::numeric::ublas::basic_row_major<long unsigned int, long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >]’:
/usr/local/include/boost/numeric/ublas/lu.hpp:90:   instantiated from ‘void boost::numeric::ublas::swap_rows(const PM&, MV&) [with PM = boost::numeric::ublas::permutation_matrix<boost::rational<long long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >, MV = boost::numeric::ublas::lu_factorize(M&, PM&) [with M = matrix_t, PM = main()::pmatrix]::matrix_type]’
/usr/local/include/boost/numeric/ublas/lu.hpp:165:   instantiated from ‘typename M::size_type boost::numeric::ublas::lu_factorize(M&, PM&) [with M = matrix_t, PM = main()::pmatrix]’
interpolator.cpp:122:   instantiated from here
/usr/local/include/boost/numeric/ublas/lu.hpp:83: error: no matching function for call to ‘row(boost::numeric::ublas::matrix<boost::rational<long long int>, boost::numeric::ublas::basic_row_major<long unsigned int, long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >&, const boost::rational<long long int>&)’
/usr/local/include/boost/numeric/ublas/matrix_proxy.hpp:466: note: candidates are: boost::numeric::ublas::matrix_row<M> boost::numeric::ublas::row(M&, typename M::size_type) [with M = boost::numeric::ublas::matrix<boost::rational<long long int>, boost::numeric::ublas::basic_row_major<long unsigned int, long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >]
/usr/local/include/boost/numeric/ublas/matrix_proxy.hpp:471: note:                 const boost::numeric::ublas::matrix_row<const M> boost::numeric::ublas::row(const M&, typename M::size_type) [with M = boost::numeric::ublas::matrix<boost::rational<long long int>, boost::numeric::ublas::basic_row_major<long unsigned int, long int>, boost::numeric::ublas::unbounded_array<boost::rational<long long int>, std::allocator<boost::rational<long long int> > > >]
}}}

It looks like the two libraries do not play well together, which means that Boost is basically useless for what I'm trying to do :-/
",pierluigi.rolando@…
4857,Boost.Parameter Constructor in Templates Not Supported?,parameter,Boost Development Trunk,To Be Determined,Bugs,Daniel Wallin,new,2010-11-16T09:13:00Z,2010-11-16T09:58:59Z,"If I try to create a Boost.Parameter Constructor as shown in the following code listing, I get a handful of errors in the preprocessor code used by `BOOST_PARAMETER_CONSTRUCTOR`:

{{{
    #include <boost/parameter.hpp>

    namespace foo {

        BOOST_PARAMETER_NAME(arg1)
        BOOST_PARAMETER_NAME(arg2)

        template <class Tag>
        struct base {
            template <class ArgPack>
            base(ArgPack const & args)
            : val1(args[_arg1])
            , val2(args[_arg2])
            {}

            int val1,val2;
        };

        template <class Tag>
        struct derived : base<Tag> {
            BOOST_PARAMETER_CONSTRUCTOR(
                derived, (base<Tag>), tag,
                (optional (arg1,int,1) (arg2,int,2)))
        };

    } /* foo */

    struct default_ {};

    int main(int argc, char * arg[]) {
        foo::derived<default_> instance();
        return 0;
    }
}}}

With GCC 4.4 on Ubuntu Linux I get the following errors:

{{{
dean@dean-desktop:~/Source/spike$ g++ -o boost_parameter_template boost_parameter_template.cpp -I~/boost/
boost_parameter_template.cpp:24: error: macro ""BOOST_PARAMETER_FOR_EACH_pred_aux2"" passed 3 arguments, but takes just 2
boost_parameter_template.cpp:24: error: macro ""BOOST_PP_SPLIT_0"" requires 2 arguments, but only 1 given
boost_parameter_template.cpp:24: error: macro ""BOOST_PP_SEQ_ELEM_III"" requires 2 arguments, but only 1 given
boost_parameter_template.cpp:24: error: macro ""BOOST_PP_SEQ_ELEM_III"" requires 2 arguments, but only 1 given
boost_parameter_template.cpp:24: error: ‘BOOST_PP_IIF_0’ was not declared in this scope
boost_parameter_template.cpp:24: error: template argument 1 is invalid
boost_parameter_template.cpp:24: error: ‘BOOST_PP_REPEAT_1_BOOST_PP_TUPLE_ELEM_2_0’ does not name a type
}}}
",Dean Michael Berris
4856,compilation error: boost::local_time::local_microsec_clock::local_time(),date_time,Boost 1.42.0,To Be Determined,Bugs,az_sw_dude,new,2010-11-15T13:11:55Z,2011-07-01T10:53:52Z,"just simple call:
boost::local_time::local_microsec_clock::local_time()

produces compilation error:

/usr/include/boost/date_time/microsec_time_clock.hpp:116:

error: no matching function for call to

'boost::local_time::local_date_time_base<boost::posix_time::ptime, 
boost::date_time::time_zone_base<boost::posix_time::ptime, char> 
 >::local_date_time_base(boost::gregorian::date&, boost::posix_time::time_duration&)'
------------------------------------------
platform ubuntu linux 10.10 x64
compiler: gcc 4.4.5
boost ver: 1.42

I have information from other party that the same problem occurs under MS Windows, with visual studio and boost 1.44

",dobrov0@…
4846,streaming gregorian::date objects to std::cout leaks memory,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-11-12T13:07:29Z,2010-11-27T18:08:59Z,"there seems to be a problem streaming boost::gregorian::date objects to std::cout, but not to std::ostringstream / whilst noting that this could be a valgrind issue

consider the following code

{{{
// build    : $ g++ -ggdb -Wall -pedantic -Weffc++ test.cc -o test
// run      : $ valgrind ./test
// compiler : g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
// library  : Boost 1.44.0

#include <iostream>           // standard io
#include <sstream>            // string-streams
#include <boost/date_time/gregorian/gregorian.hpp>

int
main()
{
  namespace bg = boost::gregorian;                // namespace alias
  const bg::date today(2010, bg::Nov, 12);        // 'const' not significant
  std::ostringstream oss;
  oss << today;
  std::cout << ""today (1) : "" << oss.str() << std::endl;  // okay
  std::cout << ""today (2) : "" << today     << std::endl;  // faulty
}
}}}

valgrind output

{{{
==15924== Memcheck, a memory error detector
==15924== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==15924== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==15924== Command: ./test
==15924==
today (1) : 2010-Nov-12
today (2) : 2010-Nov-12
==15924==
==15924== HEAP SUMMARY:
==15924==     in use at exit: 1,544 bytes in 26 blocks
==15924==   total heap usage: 64 allocs, 38 frees, 4,609 bytes allocated
==15924==
==15924== LEAK SUMMARY:
==15924==    definitely lost: 0 bytes in 0 blocks
==15924==    indirectly lost: 0 bytes in 0 blocks
==15924==      possibly lost: 568 bytes in 19 blocks
==15924==    still reachable: 976 bytes in 7 blocks
==15924==         suppressed: 0 bytes in 0 blocks
==15924== Rerun with --leak-check=full to see details of leaked memory
==15924==
==15924== For counts of detected and suppressed errors, rerun with: -v
==15924== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
}}}
",robbie@…
4833,MinGW/test_tss_lib: Support of automatic tss cleanup for native threading API not available,thread,Boost Development Trunk,To Be Determined,Bugs,Anthony Williams,new,2010-11-10T12:41:48Z,2018-09-11T21:27:38Z,"MinGW test fails with the following error ([http://www.boost.org/development/tests/trunk/developer/output/MinGW-32%20jc-bell-com-boost-bin-v2-libs-thread-test-test_tss_lib-test-gcc-mingw-4-3-3-debug-threading-multi.html test log] as of 2010-11-10):

----

Run [2010-11-09 18:13:26 UTC]: fail


Running 6 test cases...
tss_instances = 0; tss_total = 5
tss_instances = 5; tss_total = 5
../libs/thread/test/test_tss.cpp(181): error in ""test_tss"": Support of automatic tss cleanup for native threading API not available

*** 1 failure detected in test suite ""Master Test Suite""
 
EXIT STATUS: 201 

----

MinGW uses the native MSVC libraries, and those platforms pass this test. Further, it seems gcc-4.5.x also passes. So shouldn't there be a way to triangulate and make all gcc-4.x work?

",Jim Bell <jim@…>
4831,request for function object equivalents of all Fusion algorithms,fusion,Boost 1.44.0,To Be Determined,Feature Requests,Joel de Guzman,new,2010-11-10T00:45:08Z,2010-11-10T00:45:08Z,"Sure would be nice if there were a {{{fusion::functional}}} namespace containing function object equivalents of all Fusion algorithms (e.g. {{{push_front}}}, {{{pop_front}}}, etc). (They could be used in Proto transforms!) There are already a few in {{{boost/proto/fusion.hpp}}}, but they rightfully belong in Fusion, and there should be a complete set.",Eric Niebler
4830,generalize fusion::as_map and fusion::pair,fusion,Boost 1.44.0,To Be Determined,Feature Requests,Joel de Guzman,new,2010-11-10T00:35:16Z,2010-11-10T00:35:16Z,"Given an {{{mpl::vector}}} of keys, and a {{{fusion::vector}}} of values, what's the easiest way to create a fusion::map?

The obvious solution of just zipping the two sequences and passing the result to {{{fusion::as_map}}} doesn't work because {{{as_map}}} (somewhat narrowly) requires all elements to be {{{fusion::pair}}}, and Fusion's zip algorithm produces sequences of {{{vector2}}}. I'd like to see this generalized so that (a) {{{as_map}}} only requires sequences of 2-tuples and (b) {{{fusion::pair}}} meets the requirements for 2-tuples.
",Eric Niebler
4829,select_holder test failing across many platforms on release,python USE GITHUB,Boost 1.44.0,To Be Determined,Bugs,Dave Abrahams,new,2010-11-10T00:27:25Z,2010-11-16T03:30:37Z,"The python ""select_holder"" test is failing across a large number of platforms on the release branch including all clang and gcc compilers.
",Eric Niebler
4816,[BOOST::ASIO] Under Cygwin <boost/asio.hpp> doesn't compile,asio,Boost 1.43.0,To Be Determined,Bugs,chris_kohlhoff,new,2010-11-05T16:22:42Z,2010-11-05T16:22:42Z,"Environment: Cygwin

Compiler: gcc

== 1st issue
boost/asio.hpp includes another header making references to the 'pipe_select_interrupter' but fails to include:
boost/asio/detail/pipe_select_interrupter.hpp
Where it is effectively defined

== 2nd issue
The C function 'cfgetospeed' is referenced by:
boost/asio/impl/serial_port_base.ipp

But the inclusion of <termios.h> is not done under Cygwin and more, 
the cfgetospeed function is a macro, hence the statement on line 135 fails:

{{{
 speed_t baud = ::cfgetospeed(&storage);
}}}

== 3rd issue
boost/asio/detail/buffer_sequence_adapter.hpp

Makes references to the WSABUF structure when under Cygwin, but this structure exists only under the WIN32 environment. To compile I have to undefine the {{{__CYGWIN__}}} macro before including this header.

== How to reproduce
The following program doesn't compile:
{{{
/// gcc -c bug.cpp doesn't compile
#include <cstdlib>
#include <cstring>
#include <iostream>

#include <boost/asio.hpp>

int main(int argc, char* argv[])
{
	return 0;
}
}}}

=== User fix
I fix these issue in my programs by adding the following code BEFORE including <boost/asio.hpp>

{{{
/// 1st issue
#include <boost/asio/detail/pipe_select_interrupter.hpp>

/// 2nd issue
#ifdef __CYGWIN__
#include <termios.h>
#ifdef cfgetospeed
#define __cfgetospeed__impl(tp) cfgetospeed(tp)
#undef cfgetospeed
inline speed_t cfgetospeed(const struct termios *tp)
{
	return __cfgetospeed__impl(tp);
}
#undef __cfgetospeed__impl
#endif /// cfgetospeed is a macro

/// 3rd issue
#undef __CYGWIN__ 
#include <boost/asio/detail/buffer_sequence_adapter.hpp>
#define __CYGWIN__
#endif
}}}",frederic.jardon@…
4807,"Sink devices ""leacks"" exception out of the stream",iostreams,Boost 1.44.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-11-02T08:07:10Z,2010-11-02T08:07:10Z,"I implement the sink device that sometimes may fail on writes.
When Sink is implemented it should throw an exception on fault
to notify the stream on error.

However it is not always works this way.
I've got the exception to ""leak"" to the
main program when I combine in the
filter gzip_comressor() filter that writes
to output device that its Sink is full. 
When I call reset on the filter
the exception in leaking to the 
program instead of being caught.

On the other hand, if I don't throw but rather return 0,
I get into infinite loop
in the boost::iostreams::non_blocking_adapter::write 
when I call filter.reset().

In following example the exception is caught
when filter.reset() is called, when it shouldn't.


{{{
    #include <boost/iostreams/stream.hpp>
    #include <boost/iostreams/filtering_stream.hpp>
    #include <boost/iostreams/filter/gzip.hpp>
    #include <boost/iostreams/tee.hpp>
    #include <iostream>

    class my_small_device : public boost::iostreams::sink
    {
        int count;
    public:
        my_small_device() : count(1000) {}
        std::streamsize write(char const *d,std::streamsize n)
        {
            if(count < n)
                throw std::runtime_error(""Device is full"");
            count-=n;
            return n;
        }
    };

    int main()
    {
        try {
            using namespace boost::iostreams;
            boost::iostreams::stream<my_small_device> output(my_small_device(),10);
            {
                boost::iostreams::filtering_ostream filter;
                filter.push(gzip_compressor());
                filter.push(output);
                for(int i=0;i<10000000;i++) {
                    if(!(filter << i << '\n')) {
                        std::cerr << ""Fail!"" << std::endl;
                        break;
                    }
                }
                std::cout << ""Closing filter"" << std::endl;
                filter.reset();
            }

            std::cout << ""ok"" << std::endl;
            return 0;
        }catch(std::exception const &e) {
            std::cerr << ""Catched "" << e.what() << std::endl;
            return 1;
        }
    }
}}}
",artyomtnk@…
4805,Fix exec and exec-dynamic tests for MSVC10,python USE GITHUB,Boost Development Trunk,To Be Determined,Patches,Dave Abrahams,new,2010-10-31T10:56:22Z,2010-10-31T10:56:22Z,"Both of these tests fail due to an ambiguous call to std::string's constructor which could be ""std::string &&"" or ""char const*"".

The fix is just to cast the result to a char const* before returning.",Matthew Bradbury <matt-bradbury@…>
4803,"[function][patch] use a static ""empty"" target",function,Boost 1.44.0,To Be Determined,Feature Requests,Douglas Gregor,new,2010-10-29T19:38:21Z,2010-10-29T19:38:21Z,"boost::function throws bad_function_call if invoked when empty. Currently, this is implemented by performing a pointer comparison at runtime. Alternatively, boost::function's empty state could be represented by a static vtable object targeting an ""empty"" function which throws bad_function_call when invoked. There has been a lot of interest in this alternative scheme, which would trade the time overhead of a pointer comparison for an increase in space overhead in the initialized static variable section of the executable's data segment. The degree to which this trade-off will improve performance depends on compiler optimization. The attached patch implements a configuration macro, BOOST_FUNCTION_USE_STATIC_EMPTY, which allows the user to make this trade-off. The patch includes updated documentation and tests. I verified that the updated test suite passes on gcc 4.2, 4.5 and msvc 7.1, 10.",Daniel Walker
4800,Dramatic performance improvements may be available for Trac,trac / subversion,,,Feature Requests,Douglas Gregor,new,2010-10-29T13:50:15Z,2010-11-08T03:57:11Z,"Trac's performance seems very slow, as mentioned on the [http://lists.boost.org/Archives/boost/2010/10/172449.php mail list].

From [http://trac.edgewall.org/wiki/TracFaq#Tracseemstorunveryslowly the TracFaq]:
----
'''Trac seems to run very slowly'''

Despite its name, the ""Fast CGI"" solution is often quite a bit slower than mod_python or mod_wsgi. Try the TracModPython or TracModWSGI installation. Changing from fcgi to mod_python/mod_wsgi can easily give an order of magnitude (n*10) increase in performance. 
----

Seems to apply to us. Is it an easy thing to try?",Jim Bell <jim@…>
4795,Chapter 3.11 Buffering continuously not updated,iostreams,Boost 1.44.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-10-27T10:23:01Z,2014-01-13T22:30:52Z,"I have noticed chapter [http://www.boost.org/doc/libs/1_44_0/libs/iostreams/doc/guide/buffering.html 3.11 Buffers] in the Boost.IOStreams User's Guide is empty. It seems it has been market as ''To be supplied in the next release'' for a few years now.

Perhaps it's worth to consider updating or removing it.",Mateusz Loskot
4790,Suggest improvement to mpl::string documentation,mpl,Boost 1.40.0,To Be Determined,Tasks,Aleksey Gurtovoy,new,2010-10-26T03:31:27Z,2010-10-26T03:34:05Z,"
I suggest adding a warning to the documentation for mpl::string regarding multi-byte character types.

Specifically, I was unable to compile the example:

  typedef mpl::string<'hell','o wo','rld'> hello;
  typedef mpl::push_back<hello, mpl::char_<'!'> >::type hello2;
  BOOST_ASSERT(0 == std::strcmp(mpl::c_str<hello2>::value, ""hello world!""));

Using g++ 4.4.3 I got:

  error: multi-character character constant

Comprehending the problem involved investigating/learning the following points:

  what is a multi-character literal
  the warning in g++ can be disabled with -Wno-multichar (I always use -Werror, hence all warnings generate errors)
  the maximum length of a multi-character literal on my system is 4 characters

The latter two points are OS specific and therefore don't seem appropriate for the mpl::string documentation, and the first point may I guess be regarded as expected prior knowledge (though a one sentence summary would save a lot of time since they appear to be not so widely known).

But I do recommend adding a caveat beside the example code regarding possible problems compiling multi-character literals, and the alternative equivalent example with the characters independently ('h','e','l', ...).

I also recommend including a warning regarding their implementation-dependent nature (based on what the g++ manual has to say; copied below) since they appear likely to propagate portability problems.

-Wno-multichar
           Do not warn if a multicharacter constant ('FOOF') is used.  Usually they indicate a typo in the user's code, as they have implementation-defined values, and should not be used in portable code.

I hope this comment is useful. I am repeatedly awed by the cunning majesty of all the boost libraries I have explored and the MPL may be, for me, at the peak in that respect.
",Joshua Hale <jgh.emc@…>
4787,ASIO - adding support for accessing UDP control headers,asio,Boost 1.44.0,To Be Determined,Patches,chris_kohlhoff,new,2010-10-25T18:31:22Z,2015-11-13T11:35:13Z,"Attached patch implements ASIO support for accessing optional UDP control headers such as the timestamp information set with SO_TIMESTAMP.

Here are two ways of getting timestamp information using the new feature of the patch.  Note that it works in synchronous and asynchronous mode.

ip::udp::socket sock;
...
sock.set_option(ip::unicast::timestamp(true));
...
ip::udp::endpoint ep;
sock.receive_from(buf, ep, bytes_transferred);

boost::asio::detail::io_control::siocgstamp tv1;

for (const cmsghdr* cmsg = ep.control_header_first();
     cmsg;
    cmsg = ep.control_header_next(cmsg)) {
    printf(""   cmsg_len %zu: "", cmsg->cmsg_len);
    switch (cmsg->cmsg_level) {
        case SOL_SOCKET:
            switch (cmsg->cmsg_type) {
                case SO_TIMESTAMP: {
                    const timeval *stamp =
                        ep.control_msg_data<const timeval*>(cmsg);
                    printf(""SO_TIMESTAMP %ld.%06ld"",
                        (long)stamp->tv_sec,
                        (long)stamp->tv_usec);
                    tv1.set(*stamp);
                    break;
                }
                case SO_TIMESTAMPNS: {
                    const timespec* stamp =
                        ep.control_msg_data<const timespec*>(cmsg);
                    ...
                    break;
                }
                default:
                    printf(""type %d"", cmsg->cmsg_type);
                    break;
                }
                break;
            }
        default:
            printf(""Level %d, Type %d"", cmsg->cmsg_level,
                cmsg->cmsg_type);
            break;
    }
}

// Alternative way of getting the last datagram's kernel timestamp
boost::asio::detail::io_control::siocgstamp tv;
boost::system::error_code ec;
boost::asio::detail::socket_ops::state_type client_state = 0;
boost::asio::detail::socket_ops::ioctl(
    a_sock.native(), client_state, tv.name(), tv.data(), ec);

Hope it can be included in the release.

Regards,

Serge",anonymous
4786,custom property_tree,property_tree,Boost 1.44.0,To Be Determined,Feature Requests,Sebastian Redl,new,2010-10-25T18:21:28Z,2012-04-27T06:23:37Z,"When creating custom property_trees by using a data type different from std::string, property_tree has errors.  Attached is a patch along with an implementation of a tree containing variant data type.",anonymous
4784,numeric/interval/hw_rounding for __amd64__,interval,Boost Development Trunk,To Be Determined,Tasks,Boris Gubenko,new,2010-10-25T02:51:00Z,2010-11-04T21:49:04Z,"Interval fails regression tests requiring numeric/interval/hw_rounding.hpp. It gives 
{{{
../boost/numeric/interval/hw_rounding.hpp:40:4: error: #error Boost.Numeric.Interval: Please specify rounding control mechanism.
}}}

My compiler defines __amd64__ (note the double underscores before and after).  How do I determine the hardware rounding control mechanism?

Here's [http://support.amd.com/us/Processor_TechDocs/24592.pdf the AMD64 manual (pdf)], but I don't understand things well enough to say which mechanism it uses.

",Jim Bell <jim@…>
4772,binary_buffer_iprimitive fails on vector access when reading in zero length item at end of buffer_,mpi,Boost 1.47.0,Boost 1.46.0,Bugs,Matthias Troyer,reopened,2010-10-22T19:37:11Z,2011-09-21T18:03:39Z,"When binary_buffer_iprimitive's position == buffer_.size() and
binary_buffer_iprimitive::load_impl is called with l = 0, the bracket operator on buffer_ will attempt an out of bounds access. The assertion in load_impl suggests the author was aware these conditions are normal since the assertion evaluates to true. However, the parameters for the call to std::memcpy cannot be evaluated because an assertion within buffer_ fails. Changing load_impl to look like this fixes the problem:

void load_impl(void * p, int l)
{
  assert(position+l<=static_cast<int>(buffer_.size()));
  if (l)
  {
	  std::memcpy(p,&buffer_[position],l);
	  position += l;
  }
}

It looks like the bug should also exist in Boost's trunk, but I cannot get the software I'm working on to build with Boost 1.44 and newer, but that is another issue.",Jeff Jackowski <jeff.jackowski@…>
4771,DST calculation inconsistencies,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-10-22T15:46:10Z,2016-03-19T18:20:16Z,"One local_date_time constructor takes as argument a date and a time duration. However, its behaviour is not consistent. First, define a date prior to a DST change in the spring (one day prior is sufficient). Then assume you have to skip N minutes into the future, where N is large enough to get past the DST change.

a) If you add floor(N/(24*60)) days to the date, and then construct a new local_date_time with the new date and N%(24*60) minutes, you get one result.

b) If you construct a local_date_time with the original date and the N minutes (>24*60) you get a second result.

The results are different by one hour for regular EU DST rules. It seems like the constructor will not inspect DST rules unless the input date coincides with the DST change date.

The effect:

Instead of looping with one origin time + advancing time_duration, we have to advance the date whenever the number of minutes exceeds 24*60 and take modulo 24*60 for the duration in minutes. This produces the correct behaviour for our application.
",mika.heiskanen@…
4770,trac custom query needs single option for muliple field search,trac / subversion,,Website 1.X,Feature Requests,Douglas Gregor,new,2010-10-22T12:54:03Z,2010-10-22T12:54:03Z,"The trac custom query page needs a single option to allow searching across multiple fields, particularly Summary, Description and Keywords.

Right now, to query 'xyz' in either Summary, Description or Keywords for a single Component, you have to set up an OR search for each field, and duplicate the Component for each OR-part.

For instance, the current scheme requires this duplication:

(Component is 'c' AND Summary contains 'xyz') OR (Component is 'c' AND Description contains 'xyz') OR (Component is 'c' AND Keywords contains 'xyz')

",Jim Bell <jim@…>
4766,MinGW: ip_tcp test hangs on io_service::run() after tcp::socket::cancel(),asio,Boost 1.44.0,Boost 1.45.0,Bugs,chris_kohlhoff,new,2010-10-22T02:13:23Z,2010-10-22T10:58:35Z,"The MinGW-32 [http://www.boost.org/development/tests/trunk/developer/MinGW-32%20jc-bell-com-asio-gcc-mingw-4-4-0-ip_tcp-variants_.html trunk regression test] (current as of 2010/10/21) simply says:
{{{
Run [2010-10-21 16:24:46 UTC]: fail
}}}
bjam.log says:
{{{
300 second time limit exceeded
}}}
Running it in gdb verifies that it seems hung indefinitely, and breaking shows this stack trace:
{{{
#0  0x7c90e514 in ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c90da4a in ntdll!ZwRemoveIoCompletion ()
   from C:\WINDOWS\system32\ntdll.dll
#2  0x7c80a7e6 in KERNEL32!GetQueuedCompletionStatus ()
   from C:\WINDOWS\system32\kernel32.dll
#3  0x00443dfb in boost::asio::detail::win_iocp_io_service::do_one (
    this=0x3e8f8, block=true, ec=@0x23f314)
    at ../boost/asio/detail/impl/win_iocp_io_service.ipp:349
#4  0x00443954 in boost::asio::detail::win_iocp_io_service::run (
    this=0x3e8f8, ec=@0x23f314)
    at ../boost/asio/detail/impl/win_iocp_io_service.ipp:160
#5  0x00438cee in boost::asio::io_service::run (this=0x23f61c)
    at ../boost/asio/impl/io_service.ipp:57
#6  0x004061c1 in ip_tcp_socket_runtime::test ()
    at ..\libs\asio\test\ip\tcp.cpp:453
#7  0x0046873a in boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()> (this=0x23f93f, f=@0x386cc)
    at ../boost/test/utils/callback.hpp:56
#8  0x00466a63 in boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke (this=0x386c8)
    at ../boost/test/utils/callback.hpp:89
#9  0x00473065 in boost::unit_test::callback0<boost::unit_test::ut_detail::unused>::operator() (this=0x38aac) at ../boost/test/utils/callback.hpp:118
#10 0x004214c1 in operator() (this=0x34dac)
    at ../boost/test/impl/unit_test_monitor.ipp:41
#11 0x004214ab in invoke<boost::unit_test::<unnamed>::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > > (
    this=0x23f9cf, f=@0x34dac) at ../boost/test/utils/callback.hpp:42
#12 0x00421497 in invoke (this=0x34da8) at ../boost/test/utils/callback.hpp:89
#13 0x00473085 in boost::unit_test::callback0<int>::operator() (this=0x23fad4)
    at ../boost/test/utils/callback.hpp:118
#14 0x004500ad in boost::detail::do_invoke<boost::shared_ptr<boost::detail::translator_holder_base>, boost::unit_test::callback0<int> > (tr=@0x4e6540,
    F=@0x23fad4) at ../boost/test/impl/execution_monitor.ipp:253
#15 0x004204cb in boost::execution_monitor::catch_signals (this=0x4e6530,
    F=@0x23fad4) at ../boost/test/impl/execution_monitor.ipp:1129
#16 0x0042064d in boost::execution_monitor::execute (this=0x4e6530,
    F=@0x23fad4) at ../boost/test/impl/execution_monitor.ipp:1160
#17 0x004210b6 in boost::unit_test::unit_test_monitor_t::execute_and_translate
    (this=0x4e6530, tc=@0x38a80)
    at ../boost/test/impl/unit_test_monitor.ipp:69
#18 0x00460d53 in boost::unit_test::framework_impl::visit (this=0x5233c8,
    tc=@0x38a80) at ../boost/test/impl/framework.ipp:156
#19 0x00409e33 in boost::unit_test::traverse_test_tree (tc=@0x38a80,
    V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:193
#20 0x0040a267 in boost::unit_test::traverse_test_tree (id=65539, V=@0x5233c8)
    at ../boost/test/impl/unit_test_suite.ipp:232
#21 0x00409f70 in boost::unit_test::traverse_test_tree (suite=@0x385c8,
    V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:207
#22 0x0040a283 in boost::unit_test::traverse_test_tree (id=2, V=@0x5233c8)
    at ../boost/test/impl/unit_test_suite.ipp:234
#23 0x00409f70 in boost::unit_test::traverse_test_tree (suite=@0x384d8,
    V=@0x5233c8) at ../boost/test/impl/unit_test_suite.ipp:207
#24 0x0040a283 in boost::unit_test::traverse_test_tree (id=1, V=@0x5233c8)
    at ../boost/test/impl/unit_test_suite.ipp:234
#25 0x0040d9d1 in boost::unit_test::framework::run (id=1, continue_test=true)
    at ../boost/test/impl/framework.ipp:442
#26 0x00407ddd in boost::unit_test::unit_test_main (
    init_func=0x407695 <init_unit_test_suite(int, char**)>, argc=1,
    argv=0x32f08) at ../boost/test/impl/unit_test_main.ipp:185
#27 0x00407fd1 in main (argc=1, argv=0x32f08)
    at ../boost/test/impl/unit_test_main.ipp:237
}}}

Key line: ..\libs\asio\test\ip\tcp.cpp:453; The io_service::run() call after tcp::socket::cancel().

",Jim Bell <jim@…>
4742,Karma produces not the supposed output for a real number generator in scientific mode,spirit,Boost 1.44.0,To Be Determined,Bugs,Hartmut Kaiser,new,2010-10-15T11:37:05Z,2014-04-09T02:12:11Z,"Hi,

I've tried to compile a simple test example using karma real number generator example from this page: [http://www.boost.org/doc/libs/1_44_0/libs/spirit/doc/html/spirit/karma/reference/numeric/real_number.html]

When I run the code in which I pass the value '0.1' to the generator it produces 10.0e-02 instead of 1.0e-01 which, actually, is what I want.

Please find my simple test-code in the attachment:

Sincerely
  Lars Kielhorn
 ",lars.kielhorn@…
4738,property_tree parsers fail when top node has data(),property_tree,Boost 1.43.0,To Be Determined,Bugs,Sebastian Redl,new,2010-10-14T16:43:20Z,2011-05-16T18:55:50Z,"
{{{
ptree tree( ""DATA"" );
write_xml( ""test.xml"", tree );  // writes out DATA with no tag
read_xml( ""test.xml"", tree );   // fails since cannot read DATA without a tag.
}}}


{{{
ptree pt1( ""DATA"" );
write_info( ""test.info"", tree );  // does not write DATA at all
ptree pt2;
read_info( ""test.info"", pt2 );    // reads in empty ptree
BOOST_CHECK( pt1 == pt2 );        // fails since the node has no data
}}}


--------------------
These could be easy fixes but some convention will have to be adopted.  The info parser could be modified to write out the top level data when indent==-1 but the reader would then have to interpret an initial string with no following data or children to as data().  Alternatively there could be a null key represented by """" or some special character.

The XML is trickier because the DATA either needs to be an attribute or needs some sort of tag, or it cannot be parsed as XML.

I only checked this on the 1.43.0 that I have installed but it does not appear that the problem has been fixed in 1.44.0 or in subversion.",Jess <jess@…>
4735,MinGW version 'mingw-x.y.z' requested but 'g++-mingw-x.y.z' not found and version 'x.y.z' of default 'g++' does not match,build,Boost Development Trunk,Boost 1.46.0,Patches,Vladimir Prus,new,2010-10-14T09:50:32Z,2010-12-10T16:56:03Z,"MinGW's version '''''may''''' be prefixed with 'g++-', and failing to match this variation causes many tests to fail.
{{{
.../trunk/boost/tools/build/v2/tools\gcc.jam:106: in gcc.init from module gcc
error: toolset gcc initialization:
error: version 'mingw-4.3.3' requested but 'g++-mingw-4.3.3' not found
   and version '4.3.3' of default 'g++' does not match
}}}
",Jim Bell <jim@…>
4734,"please improve ""Trac Akismet SPAM"" error message",trac / subversion,,To Be Determined,Feature Requests,Douglas Gregor,new,2010-10-14T06:53:03Z,2010-10-14T06:53:03Z,"I just wasted about 1 hour figuring out how to report a new ticket s.t. it is not rejected by the spam filter of the boost trac.

Please add to the message that the reason is that in the ""Preferences"" one has to set the username and email address.

Please also provide some information on how to get an account, or which persons are eligible to get accounts.

Reporting issues is a very bad experience with this uninformative spam error message.

(I already had a session once with username and so on, restoring that session did not work so I had to enter it again.)",Peter Schüller <schueller.p@…>
4732,Event Ports for Solaris,asio,Boost Development Trunk,To Be Determined,Feature Requests,chris_kohlhoff,new,2010-10-13T21:37:14Z,2010-10-16T08:19:57Z,"Hi,

Is it possible to add support for event ports on the Solaris platform? I've written an application that uses the thread-pool strategy from the HTTP Server 2 example. As I understand, the /dev/poll method on Solaris needs lots of synchronization between threads. 

I've noticed that my application does not nearly scale linearly with an increase in threads. Highest throughput is obtained at approximately 7 threads, after which I get diminishing returns.  I think this could be due to the inter-thread synchronization needed to access /dev/poll? Please find 2 links detailing event ports and/or comparison with /dev/poll.

Jacques



==  http://blogs.sun.com/dap/entry/event_ports_and_performance ==
== http://developers.sun.com/solaris/articles/event_completion.html ==

",jacquesg@…
4728,"""iostreams::detail::mode_adapter<>"" is never ""flushable"": flushing a filtering_ostream will not flush the ""std::ostream"" target --- patch included.",iostreams,Boost Development Trunk,To Be Determined,Bugs,Jonathan Turkanis,new,2010-10-12T21:52:24Z,2012-05-09T20:48:53Z,"I have found a problem with Boost.Iostreams.
 * I'm using Boost v1.43.0 on Gentoo Linux with `gcc-4.3.4`.
  * I've reproduced it with `gcc-4.4.3`.
  * I've reproduced it with Boost v1.44.0 (from the website tarball).
  * Let me know if you need to know anything else about my environment.
 * A simple testcases attached at [attachment:boost_iostreams_filtering_std_ostream.cpp].
 * A patch to fix the problem is attached at [attachment:boost_iostreams-mode_adaptor-flushable.patch].
 * This is a different problem from #4590.

=== Details ===

I'm going to use `io` as a synonym for the `boost::iostreams` namespace.

I have come across a problem with `io::detail::mode_adapter<Mode, T>`, where `T` is a `std::ostream` or a `std::streambuf`.  I came across the problem in `io::filtering_ostream`, but perhaps this class is used elsewhere also.
 * `io::detail::mode_adapter<>::category` is not convertible to any of `io::flushable_tag`, `io::ostream_tag`, or `io::streambuf_tag`.
 * `io::flush()` will use `io::detail::flush_device_impl<io::any_tag>::flush()` for `mode_adapter<, T>` even when `T::catagory` is convertible `flushable_tag`, `ostream_tag` or `streambuf_tag`.
 * As a result, `io::filtering_ostream` will not flush correctly when the device at the end of the chain is a non-boost `std::ostream` or a `std::streambuf`.
   * I expect, also, that any filters in the chain that inherit from `flushable_tag` also do not get flushed correctly.
 * In particular the following methods from the STL `std::ostream` interface will ''not'' flush the stream to the device:
 {{{
#!cpp
std::ostream stream(&someBuffer);

io::filtering_ostream out;
out.push(stream);

// These STL methods of flushing a stream will NOT flush ""stream"".
out << std::endl;
out.flush();
}}}
 * My solution is to have `mode_adapter<>::category` inherit from `flushable_tag` when appropriate, and to implement `::flush()` methods:
 {{{
#!cpp
}}}",Duncan Exon Smith <duncanphilipnorman@…>
4726,Bugs when using named args.,python USE GITHUB,Boost 1.44.0,To Be Determined,Bugs,Dave Abrahams,new,2010-10-11T11:39:51Z,2010-10-13T07:47:22Z,"There seem to be issues when naming function arguments. Same thing happens for class_ defs and init<> functions.

Using non-named args {{{f(1,2,3)}}} works fine in all cases below but using named args {{{f(1,2,z=3)}}} works or fails depending on boost python definition.

The first two of the following defs fail when using named args. The first one crashes python and the second raises ""did not match C++ signature"" exception. The third version works as expected.
{{{#!cpp
#include <boost/python/module.hpp>
#include <boost/python/def.hpp>

int f(int x, int y, int z) { return x*y*z;}

BOOST_PYTHON_MODULE(_pylib)
{
	namespace bp = boost::python;
	// Bug
	bp::def(""bug1"", &f, (""x"", ""y"", bp::arg(""z"")));
	bp::def(""bug2"", &f, (""x"", ""y"", ""z""));
	// Works	
	bp::def(""works_fine"", &f, (bp::arg(""x""), bp::arg(""y""), bp::arg(""z"")));
}
}}}

Running {{{ bug1(x=1, y=2, z=3) }}} crashes python and {{{bug2(1, 2, z=3)}}} gives an {{{ArgumentError}}}
{{{
Boost.Python.ArgumentError: Python argument types in
    _pylib.bug2(int, int)
did not match C++ signature:
    bug2(int, int, int)
}}}

Summary of errors:
{{{#!python
from _pylib import *

works_fine(1,2,3) # OK
bug1(1,2,3) # OK
bug2(1,2,3) # OK

works_fine(1, 2, z=3) # OK
bug1(1, 2, z=3) # OK
bug2(1, 2, z=3) # Error: did not match C++ signature


works_fine(x=1, y=2, z=3) # OK
bug1(x=1, y=2, z=3) # Error: Python crashes and exits abnormally
bug2(x=1, y=2, z=3) # Error: did not match C++ signature
}}}


I'm using:
* boost 1.44. {{{BoostPro}}} Windows pre-built binary for VC++ 2008. 
* Python 2.6 
  * {{{sys.version =  '2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)]')}}}
* Microsoft VC++ 2008",Albin Thoren <thorena@…>
4722,Locale problem in date_input_facet,date_time,Boost 1.43.0,To Be Determined,Bugs,az_sw_dude,new,2010-10-08T19:13:20Z,2010-10-08T19:13:20Z,"I was adapting my code to work inputs from strings and outputs for strings with the local_datetime class for different languages, and came across a problem in local_time_input_facet.
Even when I change the global locale the code was just accepting the strings in English.
Analyzing the code of the class I realized that the parent class date_input_facet always defined the internal parser to locale:: classic () (date_facet.hpp line 451 and 462  m_parser(m_format, std::locale::classic())).
I changed the definition for std::locale() and the program now work correctly (m_parser(m_format, std::locale())).
This is a bug, or is there any reason to be this way?
I am developing on Windows XP with Visual Studio Express 10.",Alex Sobral de Freitas <alexsobral@…>
4720,[function][patch] function wrapper with no exception safety guarantee,function,Boost 1.44.0,To Be Determined,Feature Requests,Douglas Gregor,new,2010-10-07T19:11:55Z,2010-10-08T08:14:23Z,"boost::function provides a strong exception safety guarantee. However, in certain circumstances, such as some embedded systems, no exception safety guarantee is desirable. I request that function object wrappers with no exception safety guarantee be added to the Boost.Function family. The attached patch implements boost::unsafe_function (with both preferred syntax and portable syntax), which has no exception safety guarantee when invoked with no target and has no dependency on boost::throw_exception. The patch includes tests and documentation updates. It addresses the same issue identified in #4646.",Daniel Walker
4718,date::day_of_week documentation is unhelpful,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-10-07T16:56:12Z,2012-04-19T12:09:22Z,"The Gregorian date documentation for the day_of_week method is unhelpful.  It's not clear what the return type of the method is; it's not immediately obvious what a greg_day_of_week is.  The example does not help, since it does not use the method at all.  It turns out that the method returns an integer, but there is no documentation as to which day corresponds to which integer return value.

http://www.boost.org/doc/libs/1_43_0/doc/html/date_time/gregorian.html#date_time.gregorian.date_class",russell.silva@…
4714,boost::tokenizer_detail::traits_extension does not expose correctly std::_Secure_char_traits_tag on VC9,tokenizer,Boost 1.44.0,To Be Determined,Bugs,jsiek,new,2010-10-05T12:35:51Z,2010-10-05T12:53:49Z,"This issues warning C4996: 'std::char_traits<char>::[various] ': Function call with parameters that may be unsafe because VC STL relies on a tag to chose the safe/unsafe version of the function.
{{{
 typedef std::basic_string<char>::traits_type Tr;
 typedef boost::tokenizer_detail::traits_extension<Tr> Traits;
 cout << typeid(std::_Char_traits_category_helper<Tr,true>::_Secure_char_traits).name() << endl;
 cout << typeid(std::_Char_traits_category_helper<Traits,true>::_Secure_char_traits).name() << endl;
}}}

prints 
{{{
 _Secure_char_traits_tag
 _Unsecure_char_traits_tag
}}}
because _Char_traits_category_helper is defined as
{{{
template <class _Traits>
class _Char_traits_category_helper<_Traits, true>
 {
  public:
  typedef typename _Traits::_Secure_char_traits _Secure_char_traits;
 };
}}}

so it defers to a typedef of _Secure_char_traits inside the trait. By default it is defined to _Unsecure_char_traits_tag.

This affects builds with /WX (treat warnings as errors) and generally causes a lot of warnings for otherwise harmless code (for example date_time relies on tokenizer to parse strings)",emilm@…
4704,Support for multicapture and balancing groups,xpressive,Boost 1.44.0,To Be Determined,Feature Requests,Eric Niebler,assigned,2010-10-03T09:05:25Z,2017-06-29T18:58:58Z,"Feature request ticked to jog Eric Nieblers memory to take a look at some code.

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

Syntax for pop capture:
  dynamic: (?P<-name>stuff)[[BR]]
  static: (name -= stuff)

Syntax for capture conditional:
  dynamic: (?P(name)stuff)[[BR]]
  static: (name &= stuff)

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

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

Erik Rydgren
",erik@…
4697,[fusion]fold with join functor fails compile in category_of.hpp,fusion,Boost 1.44.0,To Be Determined,Feature Requests,Joel de Guzman,new,2010-09-29T17:55:56Z,2010-10-06T19:12:09Z,"when the attached fold_join is compiled, it produces a compile error
shown in the attached fold_join.compile.

However, when http://svn.boost.org/svn/boost/sandbox/SOC/2009/fusion/
in in the include path, it compiles and runs OK producing output:

v1=(tu<1>(100) tu<1>(b) tu<1>(300.1))
v2=(tu<2>(100) tu<2>(b) tu<2>(300.1))
v3=(tu<3>(100) tu<3>(b) tu<3>(300.1))
fold(vv,state0,join_ftor())=(tu<1>(100) tu<1>(b) tu<1>(300.1) tu<2>(100) tu<2>(b) tu<2>(300.1) tu<3>(100) tu<3>(b) tu<3>(300.1))

The non-variadic fusion should produce the same
output since no variadic templates are being used.
",Larry Evans
4692,conversion from string literal to 'char *' is deprecated,python USE GITHUB,Boost Development Trunk,To Be Determined,Patches,Dave Abrahams,new,2010-09-29T09:23:48Z,2010-10-30T12:45:21Z,"Boost svn trunk rev 64876.

{{{
clang++ -o boost/libs/python/src/object/stl_iterator.o -c -DBOOST_ALL_NO_LIB -DBOOST_DISABLE_THREADS -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_BOOL_INT_STRICT -I/Users/luc/Developer/cctbx/boost -fPIC -fno-strict-aliasing -DNDEBUG -O3 -ffast-math -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 /Users/luc/Developer/cctbx/boost/libs/python/src/object/stl_iterator.cpp
/Users/luc/Developer/cctbx/boost/libs/python/src/object/class.cpp:79:32: warning: conversion from string literal to 'char *' is deprecated [-Wdeprecated]
      static char *kwlist[] = {""fget"", ""fset"", ""fdel"", ""doc"", 0};
                               ^
/Users/luc/Developer/cctbx/boost/libs/python/src/object/class.cpp:79:40: warning: conversion from string literal to 'char *' is deprecated [-Wdeprecated]
      static char *kwlist[] = {""fget"", ""fset"", ""fdel"", ""doc"", 0};
                                       ^
/Users/luc/Developer/cctbx/boost/libs/python/src/object/class.cpp:79:48: warning: conversion from string literal to 'char *' is deprecated [-Wdeprecated]
      static char *kwlist[] = {""fget"", ""fset"", ""fdel"", ""doc"", 0};
                                               ^
/Users/luc/Developer/cctbx/boost/libs/python/src/object/class.cpp:79:56: warning: conversion from string literal to 'char *' is deprecated [-Wdeprecated]
      static char *kwlist[] = {""fget"", ""fset"", ""fdel"", ""doc"", 0};
                                                       ^
}}}

",luc_j_bourhis@…
4686,MSVC warning C4512 at /W4 (operator= can't be created),bimap,Boost 1.44.0,To Be Determined,Bugs,Matias Capeletto,new,2010-09-26T20:18:19Z,2013-03-06T18:10:15Z,"At /W4 msvc10 warns about not being able to generate the assignment operator for 4 classes.


Example code that generates the warnings:

{{{
#include <boost/bimap.hpp>
int main(){
	boost::bimap< int, char > bm;
}
}}}
As the boost warnings guidelines[https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines] state ""Adding the declaration (not the definition) of the appropriate operator=() as a private member does the trick as well."" (disabling the warning by pragma would have to still be active at the point of bimap instantiation and thus disable the warning in user code)
",Stefan van Kessel <van_kessel@…>
4668,Conditions for operator overload in Proto (documentation),proto,Boost 1.44.0,To Be Determined,Tasks,Eric Niebler,assigned,2010-09-21T20:00:16Z,2010-10-06T18:18:11Z,"Taken from this thread in boost-users: http://lists.boost.org/boost-users/2010/09/62747.php

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

{{{
In order for a proto overload to be created the following conditions must be 
true:

1) the operands must be in a compatible domain
2) the left hand operand and the right hand operand must match the grammar 
specified in the domain
3) the resulting expression must match the grammar specified in the domain.
}}}

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

This grammar
 

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


used in a domain would not allow


{{{
i + i;
}}}


with i being an int-terminal.



",Roland Bock <rbock@…>
4666,boost::variant gives several warnings (fix suggestions included),mpl,Boost 1.44.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2010-09-21T09:57:38Z,2011-04-07T15:38:34Z,"I am using several compiler options with gcc to increase the warning level.
Especially 3 of them are raising warnings : 

1) -Wshadow
Too warn when a variable is shadowing/hiding another variable/method
This occurs in boostvariant/variant.hpp

{{{
void indicate_which(int which)
    {
        which_ = static_cast<which_t>( which );
    }

    void indicate_backup_which(int which)
    {
        which_ = static_cast<which_t>( -(which + 1) );
    }
}}}
the local which is shadowing the member method which.

My suggestion to fix would be : 


{{{
    void indicate_which(int which_in)
    {
        which_ = static_cast<which_t>( which_in );
    }

    void indicate_backup_which(int which_in)
    {
        which_ = static_cast<which_t>( -(which_in + 1) );
    }

}}}

So I just renamed to local to which_in

2) -Wswitch-default
warn when a switch statement doesn't have a default case.
This occurs at : boost/variant/detail/visitation_impl.hpp

{{{
    // ...switch on the target which-index value...
    switch (logical_which)
    {

    // ...applying the appropriate case:
#   define BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE(z, N, _) \
    case (Which::value + (N)): \
        return visitation_impl_invoke( \
              internal_which, visitor, storage \
            , static_cast<BOOST_PP_CAT(T,N)*>(0) \
            , no_backup_flag, 1L \
            ); \
    /**/

    BOOST_PP_REPEAT(
          BOOST_VARIANT_VISITATION_UNROLLING_LIMIT
        , BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE
        , _
        )

#   undef BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE

    }

}}}

My suggestion is to add the following just in front of the end brace of the switch :

{{{
    default: break;
}}}

3) -Wundef
warns if an undefined identifier is evaluated in an #if directive
This occurs at : boost/mpl/has_xxx.hpp
It occurs 4 times (that I ran into, within all the ifdef stuff it might occur a few times more).

{{{
#   if !BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION
#     define BOOST_MPL_HAS_MEMBER_REJECT(args, member_macro) \
        template< typename V > \
        static boost::mpl::aux::no_tag \
        BOOST_MPL_HAS_MEMBER_INTROSPECTION_TEST_NAME(args)(...); \
      /**/
#   else
#     define BOOST_MPL_HAS_MEMBER_REJECT(args, member_macro) \
        static boost::mpl::aux::no_tag \
        BOOST_MPL_HAS_MEMBER_INTROSPECTION_TEST_NAME(args)(...); \
      /**/
#   endif

}}}
The question is : BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION, does it need to have a special value (for example : not 0), or is it just a matter of beind defined or not.
In the latter case, this are my suggestions on how to fix : 

line 344 --> #   if not defined (BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION)
line 357 --> #   if not defined (BOOST_MPL_HAS_XXX_NO_WRAPPED_TYPES)
line 386 --> #   if not defined (BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION)
line 458 --> #  if defined (BOOST_MPL_HAS_XXX_NEEDS_TEMPLATE_SFINAE)


What do you think ?

kind regards,
Lieven
",Lieven de Cock <killerbot@…>
4664,"libboost_zlib + libboost_iostreams - link error (XCode, MacOSX)",iostreams,Boost 1.44.0,To Be Determined,Bugs,Jonathan Turkanis,new,2010-09-20T14:19:48Z,2011-01-30T17:14:17Z,"
String for build boost:

sudo bjam toolset=darwin architecture=combined address-model=32 threading=multi link=static runtime-link=static -sNO_COMPRESSION=0 -sNO_ZLIB=0 -sZLIB_SOURCE=""../../../../../zlib123"" stage

After building I linking this libraries into my application:
libboost_iostreams.a
libboost_zlib.a

But linker say:

Undefined symbols:
""std::bad_alloc::what() const"", referenced from:
vtable for boost::exception_detail::error_info_injector<std::bad_alloc>in libboost_iostreams.a(zlib.o)
vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::bad_alloc> >in libboost_iostreams.a(zlib.o)",nen777w@…
4660,"Error read binary archive, created  by old boost version",serialization,Boost 1.45.0,Boost 1.45.0,Bugs,Robert Ramey,reopened,2010-09-20T08:49:21Z,2014-03-10T21:09:13Z,"I have some binary archive files, which was created by old version of boost::serialization. New (1.44) version does not read these files. Program throws exception “unsupported_version”

I have done some small investigation. The pproblem is:

Old code writes library_version as 1 byte, but new code (1.44)  writes library_version as unsigned short!!!

You can see in attachment  2 files, which was created boost_1_44_0\libs\serialization\example\demo.cpp. I modify this program for work with binary archive. First file demofile.dat was created with boost 1.43. Second file demofile_1_44.dat. Was created with boost 1.44.

I think it is very serious bug, as archive compatibility was ruined.
",serge-voropaev@…
4657,Boost.MPI Compile failure with Python 3,mpi,Boost 1.44.0,To Be Determined,Bugs,Matthias Troyer,assigned,2010-09-18T18:04:50Z,2013-12-03T09:18:26Z,"Boost 1.44 configured to use Python 3.1 fails on two Boost.MPI files.  The two fatal error messages are reproduced below, edited (see http://lists.boost.org/Archives/boost/2010/09/170659.php for the full error output).

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

-Steve

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


libs/mpi/src/python/datatypes.cpp: In function ‘void boost::mpi::python::export_datatypes()’:
libs/mpi/src/python/datatypes.cpp:20: error: ‘PyInt_Type’ was not declared in this scope
In file included from ./boost/function/detail/prologue.hpp:17,
                 from ./boost/function/function_template.hpp:13,
                 from ./boost/function/detail/maybe_include.hpp:13,
                 from ./boost/function/function0.hpp:11,
                 from ./boost/python/errors.hpp:13,
                 from ./boost/python/handle.hpp:11,
                 from ./boost/python/converter/arg_to_python_base.hpp:7,
                 from ./boost/python/converter/arg_to_python.hpp:14,
                 from ./boost/python/call.hpp:15,
                 from ./boost/python/object_core.hpp:14,
                 from ./boost/python/object.hpp:9,
                 from ./boost/mpi/python/serialize.hpp:25,
                 from libs/mpi/src/python/datatypes.cpp:13:

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

and

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

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


",smr@…
4654,restricted_filter doesn't seek with the correct offset,iostreams,Boost Development Trunk,To Be Determined,Patches,Jonathan Turkanis,new,2010-09-17T00:11:59Z,2011-01-19T19:28:12Z,"The class restricted_filter defined in detail/restrict_impl.hpp fails to seek properly due to a small, but significant, error in its seek member function. 

The patch fixes this bug by changing the offset argument to the seek function of the underlying filter from
{{{
next
}}}
to
{{{
next - pos_
}}}
as the seek direction is BOOST_IOS::cur and not BOOST_IOS::beg.

In other words, the bug causes restricted filters to seek relative to the current pointer using offsets relative to the beginning. If you want to seek forward by 10 byte at position 5000, it'll seek forward by 5010 instead of 10.",la06@…
4651,storage.hpp & borland,uBLAS,Boost 1.44.0,To Be Determined,Bugs,Gunter,new,2010-09-15T07:00:47Z,2010-09-16T15:20:21Z,"storage.hpp & borland when using lu.hpp
Hello!
I've found two incompatibilities when use boost-1.44.0 lu.hpp and Boland C++ Builder 2009 (Update 4).
Borland compiler messages are below.
[BCC32 Error] storage.hpp(1061): E2102 Cannot use template 'basic_range<Z,D>' without specifying specialization parameters
[BCC32 Error] storage.hpp(1076): E2034 Cannot convert 'int' to 'range'
It works after 2 replaces:
storage.hpp(1061)
-return basic_range (NULL, size);
+return basic_range<Z,D> (NULL, size);
storage.hpp(1076)
-const basic_range<Z,D> basic_range<Z,D>::all_ (0, size_type (-1));
+const basic_range<Z,D> basic_range<Z,D>::all_ (basic_range<Z,D>(),size_type(-1));// (0, size_type (-1));
",Kolan Sh <mecareful@…>
4646,[function][patch] adding an unchecked_invoke method to function objects,function,Boost 1.44.0,To Be Determined,Feature Requests,Douglas Gregor,new,2010-09-13T15:56:10Z,2010-10-07T19:14:30Z,"A common idiom for using boost::function objects is as follows :

{{{
boost::function<...> func1;

...

if( !func1.empty() )
{
   func1();
}
}}}

Internally to boost::function::operator()(...) there is then a subsequent call to empty(), which if fails calls a boost::throw_exception. 

In developing a library that makes use of boost::function, and calling the contained function I am forced to define boost::throw_exception, OR require my users to do so. The library in question is for an embedded platform (without exception support), and so I have also defined BOOST_NO_EXCEPTION and BOOST_EXCEPTION_DISABLE, it therefore becomes imperative that I check the function is valid prior to calling it, because I have no exception support. The current implementation of boost::function however does not allow me to work around this call, and requres me to defnie a function that will never be called, and conflict with my library users should they wish to define an alternative boost::throw_exception for the aspects of boost they may use.

I am proposing the addition of ''unchecked_invoke(...)'' that allows users of boost::function to call a function object without this checking on every call. This will not only allow my scenario to work, but also allow the common test before use to benefit, especially in the case where a function object is called within a loop.

As reference this topic was discussed in this thread :

[http://lists.boost.org/Archives/boost/2010/09/170486.php]


and the proposed patch is for function_template.hpp :

Insert around line 767
{{{

#if BOOST_WORKAROUND(BOOST_MSVC, < 1300)
    // MSVC 6.0 and prior require all definitions to be inline, but
    // these definitions can become very costly.
    result_type unchecked_invoke(BOOST_FUNCTION_PARMS) const
    {
      return get_vtable()->invoker
               (this->functor BOOST_FUNCTION_COMMA BOOST_FUNCTION_ARGS);
    }
#else
    result_type unchecked_invoke(BOOST_FUNCTION_PARMS) const;
#endif

}}}

and later around line 1015

{{{
#if !BOOST_WORKAROUND(BOOST_MSVC, < 1300)
  template<typename R BOOST_FUNCTION_COMMA BOOST_FUNCTION_TEMPLATE_PARMS>
  typename BOOST_FUNCTION_FUNCTION<
      R BOOST_FUNCTION_COMMA BOOST_FUNCTION_TEMPLATE_ARGS>::result_type
  inline 
  BOOST_FUNCTION_FUNCTION<R BOOST_FUNCTION_COMMA BOOST_FUNCTION_TEMPLATE_ARGS>
  ::unchecked_invoke(BOOST_FUNCTION_PARMS) const
  {
    return get_vtable()->invoker
             (this->functor BOOST_FUNCTION_COMMA BOOST_FUNCTION_ARGS);
  }
#endif
}}}




}}}",peter.myerscough-jackopson@…
4637,"An extra scoped_array(n) constructor, please!",smart_ptr,Boost 1.44.0,To Be Determined,Feature Requests,Peter Dimov,new,2010-09-08T09:37:22Z,2011-11-05T13:12:29Z,"When I construct a non-empty ''scoped_array<my_type>'', I currently need to specify the type ''my_type'' twice:
{{{
  boost::scoped_array<my_type> a( new my_type[n]() );
}}}  

Please consider supporting the following as an equivalent:
{{{
  boost::scoped_array<my_type> a(n);
}}}

A patch to the trunk (scoped_array.hpp + smart_ptr_test.cpp) is hereby attached.",niels_dekker
4635,segmentation fault in text_oarchive::save_binary(),serialization,Boost 1.43.0,To Be Determined,Bugs,Robert Ramey,new,2010-09-08T00:42:04Z,2012-03-21T06:39:53Z,"It appears that text_oarchive::save_binary() reads one byte too many. In other words, save_binary(addr,len) appears to read byte addr+len. The attached program, which runs on Linux, allocates a page of zeroes with mmap(2) and then serializes the last few bytes of the page with text_oarchive::save_binary(). The result is a segmentation fault. ",Mark Heuser <mlheuser@…>
4633,"boost/ptr_container/ptr_sequence_adapter.hpp:671: unreferenced parameters 'first', 'last' when compiled with no assertions",ptr_container,Boost 1.44.0,To Be Determined,Bugs,Thorsten Ottosen,new,2010-09-07T19:33:54Z,2010-09-07T19:33:54Z,"As of r65343 file boost/ptr_container/ptr_sequence_adapter.hpp at function range_check_impl (std::random_access_iterator_tag version), the parameters 'first' and 'last' are referenced only inside a BOOST_ASSERT call.  When assertions are compiled out, these parameters become unreferenced.  This causes warning C4100 from Microsoft Visual Studio 9.  It would be nice to mark the parameters as intentionally unused so that this warning is not generated.  The simplest way to do this is to add ""(void)first; (void)last;"" in the function body.  Other more elaborate mechanisms exist, but as far as I know, casting to void is a simple and portable way to prevent the warning without disrupting the debug code's access to these variables.",anonymous
4626,The ckeck for ICU in regex library is detected as a build error in Visual Studio,Building Boost,Boost 1.44.0,To Be Determined,Bugs,,new,2010-09-03T22:22:56Z,2010-09-05T09:12:54Z,"When building with a Makefile under Visual Studio (as a project pre-build event that compiles boost as a dependency, before the project) cl.exe compiler sees the VS_UNICODE_OUTPUT environment variable and sends the error message directly into the Visual Studio output window, even if it is just a test to check for ICU presence and the compiler outputs are otherwise redirected.

Even if boost build completes successfully, Visual Studio sees the output error message, considers the build as failed, and stops further compilation.

Unsetting VS_UNICODE_OUTPUT in the Makefile before building boost prevents the entire boost compilation process.
",terminatorul@…
4618,local_time_period not defined in local_time_io.hpp,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-09-01T18:05:05Z,2011-08-02T05:12:54Z,"In \boost\date_time\local_time\local_time_io.hpp line 123, type const boost::local_time::local_time_period is not defined.  Maybe local_time_io.hpp forgets to include local_time_types.hpp.",wangxiaohan@…
4617,Use of stringstreams in numeric/ublas/io,uBLAS,Boost 1.44.0,To Be Determined,Bugs,Gunter,new,2010-09-01T14:18:13Z,2010-09-01T16:41:38Z,"Not 100% sure it is a bug, but use of additional string streams seems a bit odd.

{{{
    template<class E, class T, class ME>
    // BOOST_UBLAS_INLINE This function seems to be big. So we do not let the compiler inline it.
    std::basic_ostream<E, T> &operator << (std::basic_ostream<E, T> &os,
                                           const matrix_expression<ME> &m) {
        typedef typename ME::size_type size_type;
        size_type size1 = m ().size1 ();
        size_type size2 = m ().size2 ();
        std::basic_ostringstream<E, T, std::allocator<E> > s;
        s.flags (os.flags ());
        s.imbue (os.getloc ());
        s.precision (os.precision ());
        s << '[' << size1 << ',' << size2 << ""]("";
        if (size1 > 0) {
            s << '(' ;
            if (size2 > 0)
                s << m () (0, 0);
            for (size_type j = 1; j < size2; ++ j)
                s << ',' << m () (0, j);
            s << ')';
        }
        for (size_type i = 1; i < size1; ++ i) {
            s << "",("" ;
            if (size2 > 0)
                s << m () (i, 0);
            for (size_type j = 1; j < size2; ++ j)
                s << ',' << m () (i, j);
            s << ')';
        }
        s << ')';
        return os << s.str ().c_str ();
    }
}}}

why do we create stringstream 's' and serialize everything in memory and only then pump it to 'os'?",Kostya <seraphym@…>
4613,Default value for optional Boolean type not being created.,parameter,Boost 1.38.0,To Be Determined,Bugs,Daniel Wallin,new,2010-08-30T05:32:06Z,2010-08-30T05:32:06Z,"If a default Boolean value isn't used in extracting the value from the ArgumentPack a compile error occurs.  That means that this code compiles ""m_name(args[_name | false])"" but ""m_name(args[_name])"" doesn't.  A code example can be found in this boost thread.

http://old.nabble.com/-parameter--Weird-behavior-with-bools-td29539068.html",Ryan McConnehey <mccorywork@…>
4612,Boolean type restriction not working,parameter,Boost 1.38.0,To Be Determined,Bugs,Daniel Wallin,new,2010-08-30T04:18:39Z,2010-08-30T14:38:07Z,"The type restriction isn't being enforced for Boolean variables.  A code example can be found in this boost thread.

http://old.nabble.com/-parameter--Weird-behavior-with-bools-td29539068.html",Ryan McConnehey <mccorywork@…>
4607,Build errors when Python installation is explicitly specified,build,Boost 1.44.0,To Be Determined,Bugs,Vladimir Prus,new,2010-08-29T00:31:38Z,2010-09-27T16:35:48Z,"Attempts to build 32-bits target libraries/dll of Boost.Python with MSVC running under Windows 7 x64 ends with errors. The 6 *.lib & *.dll of the form boost_python-vc*-mt* are not built.

No problems is experienced if MSVC is running under 32-bits version of Windows (XP Pro SP3 & 7 Ultimate tested), or the target is 64-bits libraries even when running under Win7 x64.

The below errors was produced with Windows 7 Ultimate x64, Visual Studio (2008 Pro & 2010 Ultimate tested), and ActiveState ActivePython (2.6 & 2.7 tested).

msvc.link.dll x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.dll
   Creating library x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.lib and object x86\boost\bin.v2\libs\python\build\msvc-10.0\debug\threading-multi\boost_python-vc100-mt-gd-1_44.exp
function.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format
numeric.obj : error LNK2019: unresolved external symbol __imp__PyErr_Format referenced in function ""void __cdecl boost::python::numeric::`anonymous namespace'::throw_load_failure(void)"" (?throw_load_failure@?A0x9a30ad83@numeric@python@boost@@YAXXZ)
from_python.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format
registry.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format
class.obj : error LNK2001: unresolved external symbol __imp__PyErr_Format
numeric.obj : error LNK2001: unresolved external symbol __imp__PyExc_ImportError
numeric.obj : error LNK2019: unresolved external symbol __imp__PyErr_Clear referenced in function ""bool __cdecl boost::python::numeric::`anonymous namespace'::load(bool)"" (?load@?A0x9a30ad83@numeric@python@boost@@YA_N_N@Z)
class.obj : error LNK2001: unresolved external symbol __imp__PyErr_Clear
<snip>",Katie Chan
4599,template argument identifiers,uBLAS,Boost 1.44.0,To Be Determined,Feature Requests,Gunter,new,2010-08-26T13:04:52Z,2010-08-26T13:04:52Z,"Hi,

it would be helpful if template argument identifiers like '''MATRIX''' in /boost/numeric/ublas/traits.hpp

template < class '''MATRIX''' >
struct mutable_matrix_traits
    : mutable_container_traits <'''MATRIX'''> {

    typedef typename '''MATRIX'''::iterator1  iterator1;
    typedef typename '''MATRIX'''::iterator2  iterator2;
};

would follow well-established c/c++ variable name conventions instead of that of the c preprocessor because of conflicts with exactly that. I'd suggest something like the following instead and would provide patches if favored.

template < class '''matrix_type''' >
struct mutable_matrix_traits
    : mutable_container_traits <'''matrix_type'''> {

    typedef typename '''matrix_type'''::iterator1  iterator1;
    typedef typename '''matrix_type'''::iterator2  iterator2;
};

Thanks, Jan.
",jan.boehme@…
4597,options_description should be defined as noncopyable,program_options,Boost Development Trunk,To Be Determined,Bugs,Vladimir Prus,new,2010-08-25T23:57:50Z,2010-08-25T23:57:50Z,"The [source:trunk/boost/program_options/options_description.hpp@62236#L226 options_description] class in program_options library conceptually seems to be noncopyable. It consists of const members. Thus, the definition should state it's noncopyable type as well and declare private copy ctor/op.",Mateusz Loskot
4596,Squash 64 bit warnings,python USE GITHUB,Boost 1.44.0,To Be Determined,Patches,Dave Abrahams,new,2010-08-25T20:11:45Z,2015-05-12T18:07:56Z,When using 64 bit Boost Python I get plenty of warnings when compiling my programs. Most of them involving `Py_ssize to unsigned` or `size_t to long`. The attached path just hides these warnings.,Matthew Bradbury <matt-bradbury@…>
4591,Missing preprocessor guard in mpl::for_each,mpl,Boost 1.44.0,To Be Determined,Bugs,Aleksey Gurtovoy,new,2010-08-25T10:48:13Z,2011-04-10T10:55:26Z,"Implementation has assert

BOOST_MPL_ASSERT(( is_sequence<Sequence> ));

witch must be guarded:

#if !defined(BOOST_MPL_CFG_NO_HAS_XXX)

BOOST_MPL_ASSERT(( is_sequence<Sequence> ));

#endif

for working with old compilers.",Iakov Minochkin <anberlin_myplace@…>
4589,<runtime-debugging>on does nothing for libstdc++...,build,Boost 1.43.0,To Be Determined,Bugs,Vladimir Prus,new,2010-08-24T17:49:31Z,2012-08-09T13:20:57Z,...but should at least <define>_GLIBCXX_DEBUG to enable libstdc++ debug mode.,pluto@…
4586,OperationalError: database is locked,trac / subversion,Boost 1.44.0,To Be Determined,Bugs,Douglas Gregor,new,2010-08-24T06:56:23Z,2010-11-30T16:55:00Z,"==== How to Reproduce ====

While doing a POST operation on `/ticket/4258`, Trac issued an internal error.

''(please provide additional details here)''

Request parameters:
{{{
{'__FORM_TOKEN': u'df472745600ad46e730920bd',
 'action': u'leave',
 'author': u'anonymous',
 'cnum': u'5',
 'comment': u""When adding some preprocessor checks in tss_pe.cpp that prevent the declaration _tls_used for MinGW, I've been able to fix this problem! All I did was to wrap it with \r\n\r\n#if !defined(__MINGW__)\r\n...\r\n#endif"",
 'field_component': u'thread',
 'field_keywords': u'',
 'field_milestone': u'Boost 1.43.0',
 'field_severity': u'Problem',
 'field_summary': u'Linking with boost thread does not work on mingw/gcc 4.5',
 'field_type': u'Bugs',
 'field_version': u'Boost 1.44.0',
 'id': u'4258',
 'replyto': u'4',
 'submit': u'Submit changes',
 'ts': u'2010-06-07 06:50:49+00:00'}
}}}

User agent: `Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8`

==== System Information ====
''System information not available''

==== Enabled Plugins ====
''Plugin information not available''

==== Python Traceback ====
{{{
Traceback (most recent call last):
  File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 513, in _dispatch_request
    dispatcher.dispatch(req)
  File ""build/bdist.linux-i686/egg/trac/web/main.py"", line 235, in dispatch
    resp = chosen_handler.process_request(req)
  File ""build/bdist.linux-i686/egg/trac/ticket/web_ui.py"", line 169, in process_request
    return self._process_ticket_request(req)
  File ""build/bdist.linux-i686/egg/trac/ticket/web_ui.py"", line 534, in _process_ticket_request
    valid = self._validate_ticket(req, ticket, not valid) and valid
  File ""build/bdist.linux-i686/egg/trac/ticket/web_ui.py"", line 1179, in _validate_ticket
    for field, message in manipulator.validate_ticket(req, ticket):
  File ""build/bdist.linux-i686/egg/tracspamfilter/adapters.py"", line 67, in validate_ticket
    FilterSystem(self.env).test(req, author, changes)
  File ""build/bdist.linux-i686/egg/tracspamfilter/api.py"", line 133, in test
    score, ['%s (%d): %s' % r for r in reasons]).insert()
  File ""build/bdist.linux-i686/egg/tracspamfilter/model.py"", line 138, in insert
    '\n'.join(self.reasons)))
  File ""build/bdist.linux-i686/egg/trac/db/util.py"", line 65, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 78, in execute
    result = PyFormatCursor.execute(self, *args)
  File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 56, in execute
    args or [])
  File ""build/bdist.linux-i686/egg/trac/db/sqlite_backend.py"", line 48, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: database is locked
}}}",anonymous
4577,invoke() uses invalid boost::result_of<>,fusion,Boost Development Trunk,To Be Determined,Bugs,t_schwinger,new,2010-08-20T12:22:21Z,2015-01-05T14:57:39Z,"{{{
struct F{
  template<typename Sig>
  struct result;
};

vector<int> const vec(5);
invoke(F(),vec); // (1)

int t(int i){ return i; }
invoke(F(),transform(vec,&t)); // (2)

}}}

(1) uses F::result<F(int const &)>, while (2) uses F::result<F(int)>.
I believe it should be (1) in both cases.

attaching test case and patch, which converts each argument type using fusion::detail::call_param
",anonymous
4569,[patch] fusion::unfused reusability / perfect forwarding,fusion,Boost 1.44.0,To Be Determined,Patches,t_schwinger,new,2010-08-19T11:29:35Z,2011-01-21T07:58:37Z,"attached is a patch to unfused.hpp, used by fusion::make_unfused.

what it does:
 * ""fused"" currently forces you to store a function object in order to use the ""unfusing"" interface. this patch makes the interface of unfused reusable by other classes, by introducing a CRTP class ""unfuse_interface"", that is used by unfused.
simplified example:

{{{

class unfused : unfused_interface<unfused,...>{
private:
  friend class unfused_interface;
  result call(Args &args){
    //unfused::operator()(...) was called. args is a sequence
    //of the passed arguments
    return stored_fused_functor(args);
  }
  Function stored_fused_functor;
};

}}}

 * perfect forwarding:

""unfused"" only takes non-const references as arguments.
this patch changes that to the compromise of boost::bind():
perfect forwarding for up to 2 arguments, beyond that either all arguments are const refs, or all arguments are non-const refs.
",anonymous
4564,Boost.Python import function raises boost::python::error_already_set,python USE GITHUB,Boost 1.44.0,To Be Determined,Patches,Dave Abrahams,new,2010-08-18T14:23:39Z,2010-08-18T17:58:19Z,Should never try to extract a pointer to non-const char from a str.,brianhray@…
4559,Need baud rate workaround in asio for bug in glibc,asio,Boost 1.44.0,To Be Determined,Bugs,chris_kohlhoff,new,2010-08-17T22:47:18Z,2015-12-22T09:55:24Z,"In glibc 2.12.1 (the current version), and all previous versions, there are bugs in the Linux implementations of the tcsetattr and tcgetattr functions so that the c_ispeed and c_ospeed fields of the termios data structure are not correctly passed to and from the kernel.  More specifically, the implementations of these functions use ioctl commands TCSETS and TCGETS when they should use TCSETS2 and TCGETS2 (for Linux).  Because of this, it is currently not possible to set/get an arbitrary baud rate on Linux through the tcsetattr and tcgetattr library functions.  Because Boost asio currently uses tcsetattr and tcgetattr, its baud rate setting functions can not currently handle anything but the standard Posix baud rates.  To work around this bug in glibc (which was reported a long time ago and never fixed), I think asio should call ioctl directly on Linux rather than using tcgetattr and tcsetattr (in the file boost/asio/detail/impl/reactive_serial_port_service.ipp).  I consider this a bug in asio because whether or not it is ever fixed in glibc, old versions of glibc that have the bug will continue to be used for years to come.  I feel that Boost should work around bugs in individual operating systems whenever it is trivial to do so (which it is in this case).
",Steve Soule <sts11dbxr@…>
4558,"The ""BOTHER"" baud rate constant is not handled properly in asio",asio,Boost 1.44.0,To Be Determined,Bugs,chris_kohlhoff,new,2010-08-17T22:35:15Z,2010-08-17T22:35:15Z,"In the file boost/asio/impl/serial_port_base.ipp, in the functions boost::asio::serial_port_base::baud_rate::store and boost::asio::serial_port_base::baud_rate::load, the baud rate constant ""BOTHER"" is not handled in either switch statement.  As far as I know, this constant, along with the termios fields c_ispeed and c_ospeed, are the only way to set and get an arbitrary baud rate (rather than one of the Posix baud rate constants like B9600) on Linux.  So if the user requests a baud rate not listed, such as 250000 baud, the store functions incorrectly rejects it; and if the currently set baud rate is not one of the ones listed, the load function incorrectly fails to return it.",Steve Soule <sts11dbxr@…>
4549,vector/matrix_assign do not work for integral types,uBLAS,Boost Development Trunk,To Be Determined,Bugs,Gunter,new,2010-08-17T09:10:07Z,2018-05-23T06:20:47Z,"I have found a possible problem in `vector_assign` and `matrix_assign` functions when vector and matrix values have integral type.

For instance, when you try to assign two integral vectors (e.g., `ublas::vector<int>`), you'll end up with the following runtime assertion:

{{{
Check failed in file
boost-trunk/boost/numeric/ublas/detail/vector_assign.hpp
at line 370:
detail::expression_type_check (v, cv)
terminate called after throwing an instance of
'boost::numeric::ublas::external_logic'
 what():  external logic or bad condition of inputs
Aborted (core dumped)
}}}

Similar exception will be thrown for integral matrices.

I have identified two possible issues:
1. In ''detail/vector_assign.hpp'' and ''detail/matrix_assign.hpp'', the check in function `detail::equals` should use `<=` instead of `<`.

2. In ''detail/config.hpp'', macro `BOOST_UBLAS_TYPE_CHECK_MIN` should get zero for integral types.",Marco Guazzone <marco.guazzone@…>
4547,Documentation enhancement,parameter,Boost 1.44.0,To Be Determined,Patches,Daniel Wallin,new,2010-08-16T22:52:45Z,2010-08-16T22:52:45Z,"David Abrahams suggested that I write up an update to the Boost.Parameter documentation. I did so, and he asked me to post a ticket about it so he wouldn't forget.

The update can be found in this Boost-Dev message:

    http://lists.boost.org/Archives/boost/2010/06/168418.php

Let me know if you need any further information on it.",chadnelson
4545,Invalid posix timezone format,date_time,Boost 1.44.0,To Be Determined,Bugs,az_sw_dude,new,2010-08-16T16:27:59Z,2018-03-12T20:05:49Z,"Hi,

I think that posix_time_zone in Boost.DateTime is using the wrong sign for offsets from GMT:

According to the documentation, posix_time_zone is modeled after IEEE Std 1003.1. The documentation gives several examples, for instance




   ''""MST-7""''

   ''This zone is as simple as it gets. This zone lies seven hours west of GMT and has no daylight savings.''




But all other sources for IEEE Std 1003.1 I found so far say that negative offsets indicate '''east''' of GMT, see for instance:

http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

   ''If preceded by a '-' , the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+').''

http://tools.ietf.org/html/draft-ietf-dhc-timezone-01

   ''The format of the IEEE 1003.1 POSIX timezone specification is defined as follows:[...]If preceded by a '-', the timezone is east of the Prime Meridian, otherwise it is west ('+' is optional)''


http://www.twinsun.com/tz/tz-link.htm

  ''Numeric time zone abbreviations typically count hours east of UTC, e.g., +09 for Japan and -10 for Hawaii. However, the POSIX TZ environment variable uses the opposite convention. For example, one might use TZ=""JST-9"" and TZ=""HST10"" for Japan and Hawaii, respectively.''


----


IMO, the implementation and/or the documentation should be changed. Personally, I'd prefer a change in the implementation, even though this would be a rather nasty breaking change.


Regards,

Roland
",Roland Bock <rbock@…>
4542,bind() should use boost::result_of,bind,Boost 1.44.0,Boost 1.44.0,Bugs,Peter Dimov,new,2010-08-14T20:25:37Z,2010-08-14T20:25:37Z,"if at all possible boost::bind(F(),...) should use boost::result_of<F(...)> instead of directly accessing F::result_type.

this way functors whose result type depends on the argument types could be used in bind(), for example:

{{{
#include <boost/bind.hpp>
#include <boost/utility/result_of.hpp>

using namespace boost;

struct F{
  template<typename Args>
  struct result;
  template<typename T>
  T operator()(T const &t) const{ return t; }
};

template<typename T>
struct F::result<F(T const &)>{
  typedef T type;
};

template<typename F>
void g(F const &f){
  typename boost::result_of<F()>::type res=f();
}

int main(){
  f(bind(F(),4)); //error. no result_type in F
}

}}}",anonymous
4540,fold<Sequence>() instantiates result_of::fold<Sequence const>,result_of,Boost Development Trunk,Boost 1.44.0,Feature Requests,Douglas Gregor,new,2010-08-13T15:34:38Z,2013-04-13T16:50:35Z,"Hi,

this is a complicated one, I'll try my best:

there is a problem with fold() and maybe other fusion functions whose result is computed from the result type of user functors.

in iteration/detail/fold.hpp, there are two fold()'s, the default one and a specialization for const sequences:
{{{
    inline typename result_of::fold<Seq const,State const,F>::type
    BOOST_FUSION_FOLD_NAME(Seq const& seq,State const& state,F f)
}}}
I'm not sure why it is there since there isn't any difference to the non-const fold().
but the fact that it is there causes problems when using fold() with a non-const sequence:

{{{
    fusion::vector<int> vec;
    fusion::fold(vec,0,F());
}}}
even though the sequence is not const, at least MSVC (and I vaguely remember something about that in the C++ standard) instantiates all result types of the function overload set, before the arguments are matched to the non-const fold().

==> fusion::result_of::fold<Sequence '''const''',State,F> is instantiated.

under normal circumstances this only constitutes an unnecessary instantiation, but when the result type depends on user functors it can cause instantiatiation of undefined types.

for example:
{{{
struct F{
    template<typename Args>
    struct result;
    int operator()(int state,int &element) const{
        return state;
    }
};

template<typename State>
struct F::result<F(State,int &)>{
    typedef int type;
};

int main(){
    fusion::vector<int> vec;
    fusion::fold(vec,0,F());
}
}}}

the result type of F is only defined for argument type ""int &"", which is enough for this fold. but the call to fold() instantiates the ''const'' specialization of fold(), and therefore instantiates result_of::fold<vector '''const'''>, which instantiates the result type of F(State,int const &) ==> compiler error

when the following code snippet is added as a workaround, it works:

{{{
template<typename State>
struct F::result<F(State,int const &)>{
    typedef int type;
};
}}}

bottom line - the const specialization of fold() probably shouldn't be there.
",anonymous
4534,"Wrong URL in upper-left, http://lists.boost.org/boost-testing/",website,Boost 1.44.0,Boost 1.44.0,Bugs,René Rivera,new,2010-08-12T13:58:04Z,2010-08-12T13:58:04Z,"The URL under the .png in the upper-left corner of http://lists.boost.org/boost-testing/  and all sub-pages takes you to boost.com, not boost.org. Wrong site.

",Jim Bell <jim@…>
4529,Failing to set TTL on ICMP packets on Windows Vista with MinGW.,asio,Boost 1.43.0,To Be Determined,Bugs,chris_kohlhoff,new,2010-08-11T19:24:14Z,2011-06-16T23:10:57Z,"Hi,

Using the program attached, I have tried to set the TTL on outgoing ICMP packets on a Windows Vista machine using MinGW. It does not have any effect. Using the same program on Ubuntu works just fine.

Can this be caught in the regression testing of Boost::Asio?

Best regards,
Peter Jansson",webmaster@…
4528,Reference to stack memory associated with local variable 'x' returned,parameter,Boost 1.44.0,Boost 1.44.0,Bugs,Daniel Wallin,new,2010-08-11T18:58:03Z,2010-08-11T19:00:58Z,"It looks like x is not being passed in by reference.  Because of this a copy is made on the stack.  The operator returns x.value as a reference which is dangerous since x will go out of scope. 

This bug occurred with Xcode 4 beta 2, and with the latest version of clang/llvm from the open source project.

CompileC /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/Objects-normal/i386/TopoSort.o /Users/bdoig/Dropbox/WData/TopoSort.mm normal i386 objective-c++ com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/bdoig/Dropbox/WDStoreTest
    setenv LANG en_US.US-ASCII
    setenv PATH ""/Xcode4/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Xcode4/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin""
    /Xcode4/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang -x objective-c++ -arch i386 -fmessage-length=0 -pipe -fdiagnostics-print-source-range-info -fdiagnostics-show-category=id -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wunused-variable -D__IPHONE_OS_VERSION_MIN_REQUIRED=30200 -isysroot /Xcode4/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.0.sdk -fasm-blocks -mmacosx-version-min=10.6 -gdwarf-2 -fvisibility=hidden -fobjc-abi-version=2 -fobjc-legacy-dispatch -iquote /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/WDStoreTest-generated-files.hmap -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/WDStoreTest-own-target-headers.hmap -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/WDStoreTest-all-target-headers.hmap -iquote /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/WDStoreTest-project-headers.hmap -F/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Products/Debug-iphonesimulator -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Products/Debug-iphonesimulator/include -I/Users/bdoig/Documents/Projects/boost_1_43_0 -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/DerivedSources/i386 -I/Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/DerivedSources -include /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/PrecompiledHeaders/WDStoreTest_Prefix-bwcwseswayysywfpkcwdmibmtjef/WDStoreTest_Prefix.pch -c /Users/bdoig/Dropbox/WData/TopoSort.mm -o /Users/bdoig/Library/Developer/Xcode/DerivedData/WDStoreTest-dbsxxdunpvzihagbzjvgylinzzaf/Build/Intermediates/WDStoreTest.build/Debug-iphonesimulator/WDStoreTest.build/Objects-normal/i386/TopoSort.o

In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:15:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/name.hpp:8:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/keyword.hpp:10:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tag.hpp:8:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tagged_argument.hpp:10:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/arg_list.hpp:127:16:{127:16-127:23}: warning: reference to stack memory associated with local variable 'x' returned [2]
         return x.value;
                ^~~~~~~
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:408:19: note: in instantiation of function template specialization 'boost::parameter::aux::empty_arg_list::operator[]<boost::graph::keywords::tag::vertex_index_map, int const>' requested here [2]
            >()(g, ap[t | 0]);
                   ^
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:472:18: note: in instantiation of function template specialization 'boost::detail::override_const_property<boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > > const>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer, int const>, boost::parameter::aux::empty_arg_list> >, boost::graph::keywords::tag::vertex_index_map, boost::vertex_index_t, boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS> >' requested here [2]
                  override_const_property(
                  ^
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:496:24: note: in instantiation of member function 'boost::detail::color_map_maker_helper<0, boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > > const>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer, int const>, boost::parameter::aux::empty_arg_list> >, boost::default_color_type, int>::make_map' requested here [2]
         return helper::make_map(g, white_color, ap[boost::graph::keywords::_color_map | 0], ap);
                        ^
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:300:72: note: in instantiation of member function 'boost::detail::color_map_maker<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > > const>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer, int const>, boost::parameter::aux::empty_arg_list> > >::make_map' requested here [2]
        boost::detail::color_map_maker<VertexListGraph, arg_pack_type>::make_map(g, arg_pack),
                                                                        ^
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:65:5: note: in instantiation of function template specialization 'boost::depth_first_search<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > >, boost::graph_visitor_t, boost::bgl_named_params<int, boost::buffer_param_t, boost::no_property> >' requested here [2]
     depth_first_search(g, params.visitor(TopoVisitor(result)));
     ^
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:71:5: note: in instantiation of function template specialization 'boost::topological_sort<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, std::front_insert_iterator<std::deque<int, std::allocator<int> > >, int, boost::buffer_param_t, boost::no_property>' requested here [2]
     topological_sort(g, result, 
     ^
/Users/bdoig/Dropbox/WData/TopoSort.mm:20:3: note: in instantiation of function template specialization 'boost::topological_sort<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, std::front_insert_iterator<std::deque<int, std::allocator<int> > > >' requested here [2]
                 boost::topological_sort(vectorList, std::front_inserter(topo_order));
                 ^
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:15:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/name.hpp:8:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/keyword.hpp:10:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tag.hpp:8:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tagged_argument.hpp:10:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/arg_list.hpp:127:16:{127:16-127:23}: warning: reference to stack memory associated with local variable 'x' returned [2]
         return x.value;
                ^~~~~~~
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:496:49: note: in instantiation of function template specialization 'boost::parameter::aux::empty_arg_list::operator[]<boost::graph::keywords::tag::color_map, int const>' requested here [2]
         return helper::make_map(g, white_color, ap[boost::graph::keywords::_color_map | 0], ap);
                                                 ^
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:300:72: note: in instantiation of member function 'boost::detail::color_map_maker<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::visitor, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > > const>, boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::graph::keywords::tag::buffer, int const>, boost::parameter::aux::empty_arg_list> > >::make_map' requested here [2]
        boost::detail::color_map_maker<VertexListGraph, arg_pack_type>::make_map(g, arg_pack),
                                                                        ^
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:65:5: note: in instantiation of function template specialization 'boost::depth_first_search<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > >, boost::graph_visitor_t, boost::bgl_named_params<int, boost::buffer_param_t, boost::no_property> >' requested here [2]
     depth_first_search(g, params.visitor(TopoVisitor(result)));
     ^
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:71:5: note: in instantiation of function template specialization 'boost::topological_sort<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, std::front_insert_iterator<std::deque<int, std::allocator<int> > >, int, boost::buffer_param_t, boost::no_property>' requested here [2]
     topological_sort(g, result, 
     ^
/Users/bdoig/Dropbox/WData/TopoSort.mm:20:3: note: in instantiation of function template specialization 'boost::topological_sort<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, std::front_insert_iterator<std::deque<int, std::allocator<int> > > >' requested here [2]
                 boost::topological_sort(vectorList, std::front_inserter(topo_order));
                 ^
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:21:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/named_function_params.hpp:15:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/name.hpp:8:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/keyword.hpp:10:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tag.hpp:8:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/tagged_argument.hpp:10:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/parameter/aux_/arg_list.hpp:127:16:{127:16-127:23}: warning: reference to stack memory associated with local variable 'x' returned [2]
         return x.value;
                ^~~~~~~
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
In file included from /Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:16:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/depth_first_search.hpp:301:8: note: in instantiation of function template specialization 'boost::parameter::aux::empty_arg_list::operator[]<boost::graph::keywords::tag::root_vertex, unsigned long const>' requested here [2]
        arg_pack[_root_vertex | *vertices(g).first]
        ^
In file included from /Users/bdoig/Dropbox/WData/TopoSort.mm:11:
In file included from /Users/bdoig/Dropbox/WData/TopoSort.h:20:
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:65:5: note: in instantiation of function template specialization 'boost::depth_first_search<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, boost::topo_sort_visitor<std::front_insert_iterator<std::deque<int, std::allocator<int> > > >, boost::graph_visitor_t, boost::bgl_named_params<int, boost::buffer_param_t, boost::no_property> >' requested here [2]
     depth_first_search(g, params.visitor(TopoVisitor(result)));
     ^
/Users/bdoig/Documents/Projects/boost_1_43_0/boost/graph/topological_sort.hpp:71:5: note: in instantiation of function template specialization 'boost::topological_sort<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, std::front_insert_iterator<std::deque<int, std::allocator<int> > >, int, boost::buffer_param_t, boost::no_property>' requested here [2]
     topological_sort(g, result, 
     ^
/Users/bdoig/Dropbox/WData/TopoSort.mm:20:3: note: in instantiation of function template specialization 'boost::topological_sort<boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, TopoVertexProperty, boost::no_property, boost::no_property, boost::listS>, std::front_insert_iterator<std::deque<int, std::allocator<int> > > >' requested here [2]
                 boost::topological_sort(vectorList, std::front_inserter(topo_order));
                 ^
3 warnings generated.",brian.doig@…
4526,[MSVC 10 & 9 & 8] forward declarations of concept checked function templates don't work (compiler bug?),concept_check,Boost 1.43.0,Boost 1.44.0,Bugs,jsiek,new,2010-08-11T06:21:06Z,2010-08-11T06:21:06Z,"As posted by Lorenzo Caminiti to comp.lib.boost.devel (8/9/2010) forward declarations of concept checked function templates lead to ambiguity errors even though the function signatures are identical when compiled with MSVC (I tested MSVC 10 & MSVC9, Caminit MSVC8)

I believe it boils down to a compiler error where MSVC fails to recognize that signatures are identical when the return type depends on fairly complex expressions that include non type template arguments. I've got a patch that seems to work for MSVC10. Since I used decltype it doesn't help for the older versions though. I haven't tested it much and I'm sure I'm breaking all kinds of boost coding guidelines but maybe it's of help anyway.


",Stefan van Kessel <van_kessel@…>
4525,Undocumented rolling_window_plus1accumulator,accumulator,Boost 1.43.0,Boost 1.44.0,Bugs,Eric Niebler,new,2010-08-10T23:35:38Z,2010-08-10T23:35:38Z,"rolling_count depends on rolling_window_plus1which is not documented. 

rolling_count 
The rolling count is the current number of elements in the rolling window. 
Result Type
std::size_t
Depends On
rolling_window_plus1 

The same applies to rolling_sum.

Could this documentation issue be managed?",viboes
4510,[program_options]: implicit_value and positional options conflict,program_options,Boost 1.44.0,Boost 1.44.0,Bugs,Vladimir Prus,new,2010-08-05T17:18:48Z,2014-12-29T20:17:42Z,"Hello,

Thanks for a great library.  
I just updated to 1.43 and it appears options with implicit values no longer work if there are also positional options.


In fact libs/src/program_options/example/options_description.cpp fails in 1.43:

{{{
1.43% options_description --verbose foo
in option 'verbose': invalid option value
}}}

In 1.38 this worked fine

{{{
1.38% options_description --verbose foo
Input files are: foo
Verbosity enabled.  Level is 1
Optimization level is 10
Listen port is 0
}}}

I briefly looked at the library source code and see new code added in cmdline.cpp: 

{{{
 /* If an key option is followed by a positional option,
     can can consume more tokens (e.g. it's multitoke option),
    give those tokens to it.  */
 ...
}}}

It seems that in order to make implicit options work in presence of positional options, the semantic()->max_tokens() function must return 0, that is, you can never specify a value for an implicit option.   I don't know if this is desired, but it will work for me.

Thank you,

Soren Soe",Soren Soe <soren.soe@…>
4503,unused parameter warning for bimap/relation/mutant_relation.hpp serialize,bimap,Boost 1.44.0,Boost 1.44.0,Bugs,Matias Capeletto,new,2010-08-02T13:01:00Z,2010-08-02T13:01:00Z,"The parameter 'const unsigned int version' is not used and depending on the compiler flags results in a lot of warnings being generated.

A patch against the current trunk is attached.",alexander.petry@…
4494,recursive_directory_iterator throws unexpectedly in the non-throw mode,filesystem,Boost Development Trunk,Boost 1.44.0,Feature Requests,Beman Dawes,assigned,2010-07-30T06:13:15Z,2013-08-31T15:54:02Z,"In boost::filesystem v3, while it’s possible to choose a no-throw version of recursive_directory_iterator by passing an boost::system::error_code object to its constructor, like this:
                                  boost::system::error_code m_ec;
                                  for ( recursive_directory_iterator itr(root, m_ec), end_itr; itr != end_itr; ++itr)

However, because in the implementation of the recursive_directory_iterator::increment(),  directory_iterator is always constructed with the throw version, it would cause exception throws during the for-loop while accessing folders like \System Volume Information on Windows: 
    void increment()
    { 
      BOOST_ASSERT(m_imp.get() && ""increment of end recursive_directory_iterator"");
      m_imp->increment(0);
      if (m_imp->m_stack.empty()) m_imp.reset(); // done, so make end iterator
}

Where m_imp is an object of recur_dir_itr_imp:
    void recur_dir_itr_imp::increment(system::error_code* ec)
    // ec == 0 means throw on error
{
…
}

As it’s not possible to catch this exception within the for-loop and continue the loop, it greatly limits the use of recursive_directory_iterator. 
With a rough check, V2 does not seem to have this problem. it's preferred that the directory_iterator to behave the same as recursive_directory_iterator in this case.
",ttan@…
4489,References to function object types,result_of,Boost Development Trunk,To Be Determined,Feature Requests,Daniel Walker,new,2010-07-29T17:01:40Z,2012-09-25T14:02:54Z,"The current implementation of boost::result_of doesn't permit Fn in boost::result_of<Fn(Args...)> to be a reference to a class type.
I would like to see that changed. Allowing reference-qualified function object types would be in useful with c++11's explicit reference qualification of member functions (n3090 / 13.3.1/4), and this change would bring boost::result_of more in line with c++11's std::result_of, which does allow ""reference[s] to function object type[s]"" (n3090 / 20.7.6.6)",Christopher Schmidt
4479,OpenVMS fixes for system library,system,Boost 1.43.0,Boost 1.44.0,Patches,Beman Dawes,new,2010-07-27T18:45:36Z,2010-07-27T18:45:36Z,"This patch fixes for OpenVMS platform -
workaround of compiler bugs and some warnings fixes.

It is **very important** for the organization I work for to submit them to upstream Boost in order to make an upgrade to future Boost versions simpler.

This patch related to ticket: #4473

Thanks,

    Artyom
",artyomtnk@…
4476,OpenVMS patch for 64 bit support,function,Boost 1.44.0,Boost 1.44.0,Patches,Douglas Gregor,new,2010-07-27T14:12:03Z,2010-07-27T14:12:03Z,"Hello,

This patch provides 64 bit fixes for OpenVMS platform.

It is **very important** for
the organization I work for to submit them to upstream Boost
in order to make an upgrade to future Boost versions simpler.

This patch related to ticket: #4473

Thanks,
  Artyom
",artyomtnk@…
4473,OpenVMS patch for Asio,asio,Boost 1.43.0,Boost 1.44.0,Patches,chris_kohlhoff,new,2010-07-27T14:04:18Z,2010-08-02T10:55:17Z,"Hello,

This paths allows to compile and run all unit-tests of 
Boost.Asio under OpenVMS 8.3 Itanium both 32 and 64 bits.

It is **very important** for
the organization I work for to submit them to upstream Boost
in order to make an upgrade to future Boost versions simpler.

Note, I had also submitted some other related patches for other
parts of boost.

Thanks,
  Artyom
",artyomtnk@…
4466,"""multiple paths"" algorithms",graph,Boost 1.44.0,To Be Determined,Feature Requests,Andrew Sutton,new,2010-07-25T17:20:17Z,2010-12-08T19:45:07Z,"I'm relatively new to the BGL, so I might be missing something. but it seems to me that all algorithms in the BGL deal with finding one specific path, or with transforming graphs.

I recently needed to find all unique paths that connect two nodes, i.e. count the number of feedback loops a node is part of in a directed graph, and I could not find any algorithm, or visitor that an algorithm could be built upon, in BGL.

a quick google search turned up this for example:
http://portal.acm.org/citation.cfm?id=7863

there might be more algorithms that have multiple paths as a result, I don't know, graph theory isn't my specialty. there is at least this one and BGL seems to ignore these kinds of algorithms altogether.
",anonymous
4464,gccxml error with msvc 9 and boost,typeof,Boost 1.43.0,Boost 1.44.0,Bugs,Peder Holt,new,2010-07-23T17:21:21Z,2012-09-05T17:24:08Z,"
I am using gccxml, built from current cvs at
  www.gccxml.org:/cvsroot/GCC_XML
On Windows XP SP3, with Visual Studio version 9.0.30729.1 SP (SP1)

// file test.hpp:
{{{
#include <boost/typeof/typeof.hpp>
}}}

typing this command:


{{{
   gccxml -I""C:/Program Files/boost/boost_1_43_0"" test.hpp
}}}


yields the following error message:

##################

{{{
In file included from C:/Program Files/boost/boost_1_43_0/boost/typeof/typeof.hpp:103,
                 from test3.hpp:1:
C:/Program Files/boost/boost_1_43_0/boost/typeof/msvc/typeof_impl.hpp:151: error: qualified name does not name a class before '{' token
}}}

##################

The code in question appears on a block of the form


{{{
#if BOOST_WORKAROUND(BOOST_MSVC,==1300)
// Code specific to VC 7.0.
#elif BOOST_WORKAROUND(BOOST_MSVC,>=1400)
// Code for VC 8.0 and above.
#else
// Code commented with ""This uses nice VC6.5 and VC7.1 bugfeature""
// that does not work with gccxml.  Error is reported here.
#endif
}}}


I'd guess it should be choosing the middle block here.  My fumbling attempts at preprocessor debugging suggest that the ""BOOST_MSVC"" macro is undefined when gccxml is emulating msvc here.

The gccxml preprocessor simulates the definitions
of the target compiler, but adds __GCCXML__ to distinguish
itself.

Sorry I don't have a patch to submit.  I'm unsure what the right way to handle this is.
",Christopher Bruns <cmbruns@…>
4461,"build failure with debug, mpi, and python options on macintosh",mpi,Boost 1.43.0,Boost 1.44.0,Bugs,Douglas Gregor,new,2010-07-21T18:03:42Z,2010-07-21T18:03:42Z,"When building boost-1.43 on Mac OS X (10.6.4, System GCC 4.2.1, `MacPorts` Python2.6 and OpenMPI) with the debug-build enabled, boost-build fails building `mpi.so` for python.

I '''think''' that it is failing to distinguish between the debug and release builds.

If only a `release` build is specified via `variant=release`, the build proceeds without error.

If `variant=debug,release` is specified, the build fails with the attached error log.

This has been logged in the `MacPorts` Trac as http://trac.macports.org/ticket/23667.",Andrew Fernandes <andrew@…>
4443,Bounded vector constructor missing explicit and an initialization version,uBLAS,Boost 1.44.0,Boost 1.44.0,Bugs,Gunter,new,2010-07-15T23:01:30Z,2010-08-11T19:15:09Z,"While vector<> has an 'explicit' on its constructor with unsigned integers, bounded_vector does not.  This means the following ugliness compiles:
bounded_vector<double, 2> v;
v = 2; //This SHOULDN'T compile if the patch is applied.  Using cast to unsigned int.

Also, while vector<> has a constructor that takes a size and then a value to initialize with, bounded_vector does not. I added in a constructor for this operation and for consistency, so the following compiles:
ublas::vector<double> v(2, 1.8);
ublas::bounded_vector<double,2> v(2, 1.8); //Now consistent.

.... this became necessary when I was doing programming for generic vector types and wanted to construct with an initial value.",Jesse Perla <jesseperla@…>
4442,Simple implementation of operator * for matrices with 0 complexity,uBLAS,Boost Development Trunk,To Be Determined,Patches,David Bellot,assigned,2010-07-15T22:47:25Z,2013-08-01T12:18:50Z,"The following is a simple implementation of operator * for matrix-matrix and matrix-vector which simply forwards to the existing prod() implementation.

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

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

",Jesse Perla <jesseperla@…>
4441,SFINAE for operator * breaking auto differentiation code,uBLAS,Boost 1.44.0,Boost 1.44.0,Bugs,Gunter,new,2010-07-15T22:16:34Z,2010-07-15T22:44:49Z,"A while back we had discussed adding overload resolution with SFINAE to the matrix/vector expressions involving scalars in order to implement operator*, etc. 
The choice was made to use is_convertible between the scalar and matrix type.

But this ended up breaking an auto-differentiation library (CPPAD) I was using.  Templated AD libraries will often have their own, arithmetic type which will record operations of the type * a double, etc. for a matrix multiplication by a scalar, etc. But you can't convert between them!

The basic change is to change from using is_convertible to using is_arithmetic.  A change to the result type is also needed for autodifferentation to work.

See the attached patch for the change to matrix/vector expression.",Jesse Perla <jesseperla@…>
4440,MSVC doesn't work with bounded_vector's of size 0,uBLAS,Boost 1.44.0,Boost 1.44.0,Bugs,Gunter,new,2010-07-15T21:48:06Z,2010-07-15T21:48:06Z,"A bounded_vector<double, 0> will not compile in MSVC9/10.  It works fine in Intel 11.1 windows and MinGW.

In my generic programming, this comes up quite often.  I added in a temporary hatch that changes the size of the allocated array to 1 if using MSVC.  This doesn't seem to have caused any issues, but I don't know enough about alignment issues to see if it is a problem.

See the attached patch to the boost trunk and a boost test file.  This patch works on MSVC10, Intel 11.1 MinGW4.5",jesseperla@…
4438,Possible infinite loop in boost:: filesystem::copy_file for unix,filesystem,Boost Development Trunk,Boost 1.44.0,Bugs,Beman Dawes,new,2010-07-15T12:52:15Z,2014-02-23T09:06:35Z,"In the write cycle:


     do
      {
        if ((sz = ::write(outfile, buf.get() + sz_write,
          sz_read - sz_write))< 0)
        { 
          sz_read = sz; // cause read loop termination
          break;        //  and error to be thrown after closes
        }
        sz_write += sz;
      } while (sz_write < sz_read);
    



Always try to write a number of bytes strictly greater than zero and the api ::write returns according to the official documentation :"" On  success,  the  number of bytes written is returned (Zero Indicates Nothing Was Written).  On error, -1 is returned, and errno is set appropriately"". Now imagine that the ::write api for any error or side effect, always returns zero, then we are in an infinite loop.

To fix it I think the appropriate condition should be:

 if ((sz =:: write (outfile, buf.get () + sz_write,
          sz_read - sz_write)) <= 0)

that is, change the Boolean operation for less than or equal to (<=)

If I'm wrong please let me know what to learn. In my opinion you are the best.",Roberto Carlos Toledano Gómez <rctg82@…>
4436,Introduce an unpack to arguments operation for vectors and matrices,uBLAS,Boost Development Trunk,To Be Determined,Feature Requests,Gunter,new,2010-07-15T12:17:14Z,2010-07-15T12:17:14Z,"The new ublas assignment facility provides a convenient way to fill up matrices and vectors, but the opposite would also be useful. 
Quoting:
{{{
The boost assignment is really nice, but what about the other direction
(from vector to scalars)? This comes up quite often.

ublas::vector<double> f()
{
ublas::vector<double> v(2);
 v(0) = 1.1;
v(1) = 2.1;
return v;
}

double x;
double y;

 ublas::vector<double> v(2);
v(0) = 1.1;
v(1) = 2.1;

ublas::tie(x, y) = v;
ublas::tie(x, y) = f(); //With function

ublas::matrix<double> mat(2,2); //....
ublas::tie(x, y) = row(mat, 0);

ublas::vector<int> v2(2);
v2(0) = 1;
 v2(1) = 2;

        int z;
        ublas::tie(x, z); //With different types

For vector expressions, this seems to be easy enough to do. See the
attached basic implementation for 2 parameters. With a little boost
preprocessor, this could be fairly general. What do people think? Are
there any boost PP who could generalize this?

-Jesse 

}}}

and 
{{{
What's about ublas::tie(V1,V2,V3) = M;
That could be useful for applications where Vn are not directly managed by
ublas. I mean that you make matrix computations which vectors are then sent
to some sort of external outputs. That would be written in one line (like
controlling and engine or whatever you can imagine, you know).
that's splitting up a matrix in vectors .... ?

Cheers,
David 
}}}

Some ideas of implementation tools and techniques include:
1. Boost tuple
2. Variadic templates
3. Custom exhaustive implementation (up to a certain number of return values)
",nasos_i@…
4428,serial_port Bugs,asio,Boost 1.43.0,Boost 1.44.0,Bugs,chris_kohlhoff,new,2010-07-13T07:04:35Z,2010-07-13T07:04:35Z,"when you use a USB-Serial Port convertor and when use a async_write to send a large buffer to Serial Port,at the time of sending data, you pull out the USB-Serail Port Convertor from computer. the async call back handler for sending and receiving will not get a error and the io_service can't be delete.",tirelessfighter@…
4424,Program using Boost.Asio stops processing the request,asio,Boost 1.43.0,Boost 1.44.0,Bugs,chris_kohlhoff,new,2010-07-11T12:49:22Z,2010-07-11T14:10:06Z,"I made a small HTTP proxy, and after +- 1000 simultaneous requests, the process stops working, accepts new connections but does not send anything to the client, which is eternally waiting.

I made a small HTTP proxy, and after + - 1000 simultaneous requests, the process stops working, accepts new connections but does not send anything to the client, which is eternally waiting.

I drove by a GDB backtrace, do not know if it helps a lot.",Joaquim Pedro França Simão <osmano807@…>
4409,boost::in_place_factory produces warning,utility,Boost 1.44.0,Boost 1.44.0,Feature Requests,No-Maintainer,new,2010-07-08T09:38:05Z,2010-11-29T15:44:33Z,"Visual C++ 9.0, Warning level 4

{{{
#!cpp

#include <boost/utility/in_place_factory.hpp>
#include <boost/optional.hpp>

#include <boost/noncopyable.hpp>

struct x : boost::noncopyable
{
public:
	static void init(int i);
	
private:
	x(int i) : i (i)
	{
	}

	friend boost::in_place_factory1<int>;

	int i;
};

boost::optional<x> x_instance;

void x::init(int i)
{
	x_instance = boost::in_place(i);
}

}}}

{{{
1>boost\utility\in_place_factory.hpp(68): warning C4512: 'boost::in_place_factory1<A0>' : assignment operator could not be generated
1>          with
1>          [
1>              A0=int
1>          ]
1>          a.cpp(26) : see reference to class template instantiation 'boost::in_place_factory1<A0>' being compiled
1>          with
1>          [
1>              A0=int
1>          ]
}}}",NN
4404,last_write_time for a symlink,filesystem,Boost 1.44.0,Boost 1.44.0,Feature Requests,Beman Dawes,new,2010-07-06T13:59:30Z,2012-04-10T19:10:33Z,last_write_time returns the last data modification time for a file as might be obtained by the posix stat system call m_time. It would be useful to be able to obtain the similar time as returned by the posix lstat system call.,anonymous
4393,all_eccentricities not in documented,graph,Boost 1.43.0,Boost 1.46.0,Tasks,Andrew Sutton,new,2010-06-29T16:27:27Z,2010-12-08T19:45:28Z,"The function all_eccentricities contains a sample, but is not listed in (the table of contents of) the documentation",Barend Gehrels
4381,GCC previous to 4.3.x does not implement inclass member initialization,python USE GITHUB,Boost 1.43.0,Boost 1.44.0,Bugs,Dave Abrahams,new,2010-06-26T09:59:08Z,2010-09-22T18:06:53Z,"o Add compile gcc option to make sure that boost compilation toolchain
  acknowledges that gcc versions prior to 4.3.x do not implement
  inclass member initialization.
o This enables libtorrent-rasterbar 1.4.x to build python
  bindings with the base system gcc on FreeBSD 8.x. Previously, we
  would have had to resort gcc 4.3+ ports.
o Further information can be found at

http://www.freebsd.org/cgi/query-pr.cgi?pr=144336
",Mario Ferreira <lioux@…>
4378,numeric/interval/hw_rounding.hpp upgrade  to accept __SUNPRO_CC rounding control mechanism,interval,Boost 1.44.0,Boost 1.44.0,Bugs,Boris Gubenko,new,2010-06-25T22:53:19Z,2016-01-05T20:46:54Z,"This fix upgrades 

boost/numeric/interval/hw_rounding.hpp

file which allows several numeric/interval benchmarks
to be successfully built and run. 

Without this fix those benchmarks produce the following error message:

""error Boost.Numeric.Interval: Please specify rounding control mechanism.""

Please note that for successful build of mentioned
benchmarks on x86 Solaris 5.10 platform you need to
install Solaris patch 119967-01.

This patch has fix for bug in <fenv.h> system file which
othervise will fail with syntax errors.

There is no problem on Open Solaris though.
",anonymous
4376,"Compilation failure on Solaris 5.9, 5.10, because of non existent membar_producer(membar_consumer)",asio,Boost 1.43.0,Boost 1.44.0,Bugs,chris_kohlhoff,new,2010-06-24T19:23:55Z,2010-11-23T14:32:55Z,"We have to compile our application for a large set of unixes, including solaris 5.9 and 5.10.
After switching from 1.42 to 1.43 I have got the following compilation error:

{{{
/export/esuitebuild/boost_1_43_0/boost/asio/detail/solaris_fenced_block.hpp: In constructor 'boost::asio::detail::solaris_fe\
nced_block::solaris_fenced_block()':
/export/esuitebuild/boost_1_43_0/boost/asio/detail/solaris_fenced_block.hpp:41: error: 'membar_consumer' was not declared in\
 this scope
/export/esuitebuild/boost_1_43_0/boost/asio/detail/solaris_fenced_block.hpp: In destructor 'boost::asio::detail::solaris_fen\
ced_block::~solaris_fenced_block()':
/export/esuitebuild/boost_1_43_0/boost/asio/detail/solaris_fenced_block.hpp:47: error: 'membar_producer' was not declared in\
 this scope
}}}

These functions doesn`t exists in atomic.h. I found them in sys/atomic.h, and they can be used only from kernel mode.

Is there any way to avoid membar_producer(membar_consumer) usage?
",Kozlov Taras
4361,boost/concept_check gcc warning cleanup,concept_check,Boost Development Trunk,Boost 1.44.0,Patches,jsiek,new,2010-06-21T18:43:17Z,2014-09-30T01:10:04Z,"Patch to clean up gcc 4.x warning barf. To reproduce issue, compile using -Wshadow.

One of the methods was left using just 'c' as parameter name. Patch renames this to 'cc' as with other instances.",tatu.kilappa@…
4360,Borland / Codegear patch for boost::enable_error_info,exception,Boost 1.44.0,Boost 1.43.0,Patches,Emil Dotchevski,new,2010-06-19T16:27:07Z,2010-06-19T16:27:07Z,"Please consider the attached patch, which will allow Codegear 2010 to pass the enable_error_info_test. The patch supports calling enable_error_info(T const &), as long as T is ''not'' derived from {{{boost::exception}}}. Which seems like an acceptable limitation to me. Right?

Note: The attached patch assumes that the little patch from #4344 is also applied: https://svn.boost.org/trac/boost/attachment/ticket/4344/helper1_cpp_qualified_call_to_boost_enable_error_info.patch",niels_dekker
4359,boost bind doesn't work with inherited structures,bind,Boost 1.44.0,Boost 1.44.0,Bugs,Peter Dimov,new,2010-06-18T13:43:28Z,2010-06-24T20:26:21Z,"The following code gives an error in VC++2008, VC++2010, g++ 4.2.4:

{{{
#include <boost/bind.hpp>

struct Y {
	void reset() {};	
};

template<typename T1, typename T2>
struct my_pair {
	T1 first;
	T2 second;
};

template<typename T1, typename T2>
struct my_pair2 : my_pair<T1, T2> {};

typedef my_pair<int, Y> mypair_t;
typedef my_pair2<int, Y> mypair2_t;

int main()
{
	mypair_t t1;
	mypair2_t t2;

	boost::bind<Y&>( &mypair_t::second, _1 )( t1 ).reset();  // OK!
	boost::bind<Y&>( &mypair2_t::second, _1 )( t2 ).reset(); // error: cannot convert from 'const Y' to 'Y &'

	return 0;
}
}}}
",jia3ep@…
4357,mpl::equal for associative sequences,mpl,Boost 1.44.0,Boost 1.46.0,Feature Requests,Joel Falcou,new,2010-06-17T07:51:29Z,2010-12-30T15:04:32Z,"this is not a bug, as the current behaviour is documented correctly, but I think mpl::equal<> should return equality for mpl::set<>s that are equal but are not in the same sequence.
something like:

struct equal :
  mpl::and_<
    mpl::equal_to<
      mpl::size<Set1>,
      mpl::size<Set2>
    >,
    mpl::fold<
      Set1,
      mpl::true_,
      mpl::and_<
        mpl::_1,
        mpl::has_key<Set2,mpl::_2>
      >
    >
  >{};

also I think it would be usable for equal sets to be runtime-convertible.

template<...>
struct set{
  template<class OtherSet>
  set(OtherSet,typename enable_if<equal<set,OtherSet> >::type *e=0){}
};

so you can do this:

void f(set<e1,e2>);

f(set<e2,e1>());

the same might be usable for mpl::map.
",anonymous
4356,small change to allow mpl code to compile with nvcc (the compiler for cuda),mpl,Boost 1.44.0,Boost 1.43.0,Patches,Joel Falcou,new,2010-06-17T04:13:37Z,2010-12-30T15:06:12Z,fixes compilation problem when using mpl and mpl dependent libraries with nvcc (Edg front-end),anonymous
4351,boost 1_43_0 BOOST_MPL_ASSERT compile error (gcc 4.2),mpl,Boost Development Trunk,Boost 1.46.0,Bugs,Joel Falcou,new,2010-06-16T16:09:42Z,2010-12-30T14:31:31Z,"The simple version:
{{{
#include <boost/mpl/assert.hpp>
int main() { BOOST_MPL_ASSERT((1)); BOOST_MPL_ASSERT((1)); return 0;}
}}}
(it is important that both BOOST_MPL_ASSERT invocations are '''on the same line''')

On gcc 4.2.4 (Ubuntu 8.04), this leads to the following error:
{{{
$ g++ -I /src/jepler/boost_1_43_0/ main.c
main.c: In function ‘int main()’:
main.c:2: error: conflicting declaration ‘mpl_assertion_in_line_2’
main.c:2: error: ‘mpl_assertion_in_line_2’ has a previous declaration
 as ‘main()::<anonymous enum> mpl_assertion_in_line_2’
}}}

I am trying to migrate an application from boost 1_34_0 to boost 1_43_0.  Among other boost features, it uses boost serialization.  It has BOOST_CLASS_VERSION declarations across various header files.  When two header files are included in the same source file, and they both contain BOOST_CLASS_VERSION declarations '''on the same source line''' (e.g., fooclass.h line 30 and barclass.h line 30) a similar error results.

The attached tar file demonstrates the original problem with BOOST_CLASS_VERSION that first came to my attention.",Jeff Epler <jepler@…>
4349,Autolinking against debug STLport,Getting Started Guide,Boost Development Trunk,To Be Determined,Bugs,Dave Abrahams,new,2010-06-16T10:55:32Z,2010-07-25T09:58:56Z,"I can't use autolinking with the following setup:
 * using a debug build
 * using STLport
 * not using additional checks and diagnostics (_STLP_DEBUG)

The autolinking code should simply look for the ""dp"" variant of the Boost libraries. What I get is a warning that these libs are not built by default. Even worse, I get an error downright refusing to link with that version, even though I did compile them. However, that error is still better than nothing, because the macros defining the version are then set to ""gdp"" which is simply incompatible with my settings.

Things to fix:
 * Fix the generated tags, i.e. replace ""gdp"" with ""dp"" for above example.
 * Don't generate an error when using STLport with debug symbols but without additional diagnostic.

Further things that could be fixed, too:
 * Don't output a warning unless lib diagnostics (BOOST_LIB_DIAGNOSTIC) are actually requested.
 * Document the meaning of an 'n' in the generated tag.
 * Remove redundant comment documenting the 'p' in the generated tag.
 * Fix spelling of STLport here, without a capital P.
 * Fix warnings, those claim that you should use ""/D_STLP_DEBUG=1"", but a simple ""/D_STLP_DEBUG"" is sufficient. A short grep shows that several other parts of Boost also have this, maybe creating separate ticket and patch would be a better choice for this.
 * Fix indention of preprocessor commands, large parts use 3 spaces, some parts use 4.

Concerning the version, this bug is present in today's trunk, 1.43 and 1.33.1, which are also all versions I checked. Concerning 1.33.1, we are using a local version where this discrepancy is fixed and have not found any problems with it.
",eckhardt@…
4346,Boost pool's not comaptible with Microsoft memory leak detection,pool,Boost 1.60.0,Boost 1.61.0,Bugs,Chris Newbold,reopened,2010-06-15T16:51:24Z,2016-04-03T19:44:08Z,"Boost pool classes not compatible with Microsoft  memory leak detection.

You can include that lines in code:
#ifdef _DEBUG
   #define _CRTDBG_MAP_ALLOC
#endif
#include <crtdbg.h>
#include ""boost\pool\pool_alloc.hpp""

We can solve problem using two ways:
1. Rename all malloc & free methods
2. Add #pragma push_macro, #undef and #pragma pop_macro lines. Also add alternative names for malloc and free methods",Arkadiy Shapkin <arkadiy_s@…>
4336,[spirit] A trait to access encoding-specific parsers,spirit,Boost 1.44.0,Boost 1.43.0,Feature Requests,Hartmut Kaiser,new,2010-06-12T15:49:21Z,2010-06-12T15:49:21Z,"Originated from [http://article.gmane.org/gmane.comp.lib.boost.devel/205392 this] discussion.

The attached patch allows to gain access to the encoding-specific parsers by specifying the encoding type to the encoding_specific template parameter. This allows the following use case:

{{{
  template< typename CharT >
  void parse(const CharT* str)
  {
    typedef typename my_traits< CharT >::encoding encoding;
    typedef spirit::encoding_specific< encoding > parsers;
    qi::parse(str, *parsers::char_);
  }
}}}
",Andrey Semashev
4307,basic_oarchive optimization,serialization,Boost 1.44.0,Boost 1.43.0,Patches,Robert Ramey,new,2010-06-06T21:15:06Z,2010-06-08T21:31:42Z,"attached are patches that optimizes memory allocation and runtime complexity of basic_oarchive.
it should not change any serialization behaviour, and archives by the patched basic_oarchive can be read by the unpatched basic_iarchive.

what the patch does in detail:
 - replace log(O) lookup of ""cobject"" class info for each
   serialized class with a log(1) vector lookup. avoids
   container node allocation.
 - replace log(O) lookup of ""aobject"" object tracking info
   with log(1) hashing. avoids container node allocation.
 - use allocation pools for ""aobject"" object tracking info
 - store whether a class was stored as a pointer inside
   the ""cobject"" class info, to remove std::set stored_pointers

before:
 - 4 allocations on construction
 - 1 allocation for each serialized class, tracked or not
 - 1 allocation for each tracked object
after:
 - 1 allocation on construction(PIMPL)
 - no allocation for classes if less than 256 classes are serialized.
   1 allocation for 512 classes, 2 for 1024, ...
 - no allocation for object tracking if less than 256 objects are serialized.
   after that, about 1 allocation for 16 tracked objects
",anonymous
4301,and_<true_>::type is false_,mpl,Boost Development Trunk,Boost 1.46.0,Bugs,Joel Falcou,new,2010-06-05T23:02:03Z,2010-12-30T14:39:41Z,"It is probably a good idea to make and_<true_>::type be true_, or throw a compiler error, or at least fix the documentation at http://www.boost.org/doc/libs/1_43_0/libs/mpl/doc/refmanual/and.html such that this unusual behavior is documented.
",mstefanro
4298,boost build mpi fails to compile with CC: Sun C++ 5.9 SunOS_sparc Patch 124863-23 2010/04/13,mpi,Boost 1.43.0,Boost 1.43.0,Bugs,Douglas Gregor,new,2010-06-04T21:51:14Z,2010-06-05T20:05:36Z,"I'm trying to compile boost on Solaris SPARC 10 with latest Sun Studio compiler and mpi support and the mpi component fails. First error is:
""libs/mpi/src/python/py_communicator.cpp"", line 48: Error: Overloading ambiguity between ""boost::python::make_tuple<boost::python::api::object, boost::mpi::st
atus>(const boost::python::api::object&, const boost::mpi::status&)"" and ""boost::tuples::make_tuple<boost::python::api::object, boost::mpi::status>(const boos
t::python::api::object&, const boost::mpi::status&)"".

More detailed log will be attached.


C++ Compiler:
$ CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-23 2010/04/13

Open MPI implementation: Oracle HPC ClusterTools 8.2.1c

boost build is performed as per recommended instructions with mpi enabled:
./bjam --with-mpi
and with ""using mpi ;"" in user-config.jam
",nikolov.javor@…
4295,Make tests fail when missing sources,build,Boost 1.44.0,To Be Determined,Feature Requests,Vladimir Prus,new,2010-06-04T04:11:42Z,2010-06-04T04:11:42Z,Currently Boost Build exits with failure interrupting the build when sources are missing for test targets. To prevent testing stalls change it such that the tests fail when sources can't be found.,René Rivera
4294,boost::asio::context_base should not depend on OpenSSL Types,asio,Boost Development Trunk,To Be Determined,Feature Requests,chris_kohlhoff,new,2010-06-04T03:30:07Z,2018-03-06T16:18:58Z,"For the moment boost::asio::context_base depends on OpenSSL types.

But implementation details should go to context service impl.

Indeed, if one want to implement a backend based on GnuTLS (or another), this implies that contect_base and then ssl::basic_context template can't be used to use another thing than OpenSSL.

context_base should look something like this :

class context_base
{
public:
  /// Different methods supported by a context.
  enum methods
  {
    /// Client method
    client,
    /// Server method
    server,
    /// Generic SSL version 2.
    ssl_2,

    /// Generic SSL version 3.
    ssl_3,

    /// Generic TLS version 1.
    tls_1,

    /// Generic TLS version 1.1.
    tls_1_1,

    /// Generic TLS version 1.2.
    tls_1_2
  };

  typedef int method_option;

  static const method_option bit_client  = 1<<client;
  static const method_option bit_server  = 1<<server;
  static const method_option bit_ssl_2   = 1<<ssl_2;
  static const method_option bit_ssl_3   = 1<<ssl_3;
  static const method_option bit_tls_1   = 1<<tls_1;
  static const method_option bit_tls_1_1 = 1<<tls_1_1;
  static const method_option bit_tls_1_2 = 1<<tls_1_2;

  /// File format types.
  enum file_format
  {
    /// ASN.1 file.
    asn1,

    /// PEM file.
    pem
  };

  enum verify_mode {
    verify_none,
    verify_peer,
    verify_fail_if_no_peer_cert,
    verify_client_once
  };

  typedef int verify_mode_option;

  const verify_mode_option bit_verify_none                 = 1<<verify_none;
  const verify_mode_option bit_verify_peer                 = 1<<verify_peer;
  const verify_mode_option bit_verify_fail_if_no_peer_cert = 1<<verify_fail_if_no_peer_cert;
  const verify_mode_option bit_verify_client_once          = 1<<verify_client_once;

  /// Purpose of PEM password.
  enum password_purpose
  {
    /// The password is needed for reading/decryption.
    for_reading,

    /// The password is needed for writing/encryption.
    for_writing
  };
};


then in basic_context :

-the constructor should take a combination (with the ""|"" operator) of method_option (you can even define short combinations for classic openssl default methods if you want) and the implementation set or trigger errors accordingly (if the requested mode is not supplied, like tls_1.1 or 1.2 with the openssl backend.

I'm currently trying to implement GnuTLS backend, but i don't want to fork all the public asio::ssl api. a common one should be a better solution for everybody.
-",ecyrbe <ecyrbe@…>
4283,Missing doygen features in boost book,Documentation,Boost 1.44.0,Boost 1.43.0,Feature Requests,Steven Watanabe,new,2010-06-03T08:18:11Z,2012-12-18T17:16:55Z,"1)

Doxygen commands like @see seem to be ignored, doxygen generates :

<para><simplesect kind=""see""><para>AddEmptyVars() </para></simplesect>

but the boostbook conversion has :

</para></description></parameter><description><para><para>AddEmptyVars() </para>

So I get a text and not a link.

2)

I like to use array notation for arrays i.e ""int somearray[]"", but
this gets ignored and displayed like ""int somearray"" in the parameters
section, eventhough doxygen seem to correctly has parsed my source :

       <param>
         <type>double</type>
         <declname>up</declname>
         <array>[]</array>
       </param>

becomes :

<parameter name=""up""><paramtype>double</paramtype>

Also group features would be nice to have.",jensen.bo@…
4276,"warning ""type qualifiers ignored on function return type"" in ptr_map",ptr_container,Boost 1.47.0,To Be Determined,Bugs,Thorsten Ottosen,new,2010-06-01T12:15:42Z,2016-10-25T14:07:52Z,"The following program compiled with gcc using options -W and -Wall spits out a warning about ignored type qualifiers.

test.cpp:
#include <boost/ptr_container/ptr_map.hpp>
int main() { } 

g++ -W -Wall test.cpp
../include/boost/ptr_container/detail/map_iterator.hpp:52: warning: type qualifiers ignored on function return type

It seems like there is a superfluous const in the -> operator.
const ref_pair* const operator->() const
should be
const ref_pair* operator->() const",boris.bigott@…
4272,Wrong assumption about compiler for ARM g++,asio,Boost 1.43.0,Boost 1.43.0,Bugs,chris_kohlhoff,new,2010-05-31T10:07:15Z,2010-07-05T08:03:23Z,"The compiler arm-920tsoftfloat-linux-gnueabi-g++ (GCC) 4.1.1 does not know __sync_lock_test_and_set - extensions.

It is used in
boost::asio::detail::gcc_fenced_block::gcc_fenced_block()

",Stefan Wegele <s.wegele@…>
4259,Reference leak in boost::python::function::add_to_namespace(),python USE GITHUB,Boost 1.44.0,Boost 1.43.0,Patches,Ralf W. Grosse-Kunstleve,new,2010-05-26T12:58:06Z,2011-09-08T21:27:56Z,"In libs/python/src/object/function.cpp, there is an obvious reference leak:

https://svn.boost.org/trac/boost/browser/trunk/libs/python/src/object/function.cpp?rev=60625#L444

The first branch retrieves a borrowed reference, when the seconds gets  a new reference.  This is stored in a plain `PyObject*`, there is no magic in some destructor.  This code is likely to leak references.

I suggest to use `dict = PyObject_GetAttrString(ns, ""__dict__"")` in all cases, and add `Py_DECREF(dict)` when it is no more needed.",Amaury Forgeot d'Arc <amauryfa@…>
4255,"Documentation: No overflow-checking in accumulators, no precision guarantees",accumulator,Boost 1.44.0,Boost 1.43.0,Bugs,Eric Niebler,new,2010-05-25T09:49:58Z,2010-05-25T09:49:58Z,"As discussed here[http://old.nabble.com/-accumulators--Is-there-a-reset-function-yet--td28635232.html], I suggest changing the documentation to warn users of possible overflow/loss of precision issues:

Maybe in the section ""The Accumulators Framework"" one could add the sentence

''To ensure maximum performance, the predefined accumulators in the library do not check for possible overflows or loss of precision by adding numbers of very different exponents.''

",Tim Odenthal
4239,Python on OSX is shipped as a Framework,python USE GITHUB,Boost 1.41.0,Boost 1.43.0,Bugs,Dave Abrahams,new,2010-05-19T19:05:45Z,2010-05-19T19:05:45Z,"On OSX 10.5 at least, Python is shipped as a framework which requires Boost to include Python using the #include <Python/Python.h> syntax. 

I'm not sure which version of OSX started doing this but this patch fixed the problem for me on 10.5 and 10.6.",Sohail Somani
4234,Implementation of mapped_file is unnecessarily bloated,iostreams,Boost 1.44.0,Boost 1.43.0,Bugs,Jonathan Turkanis,new,2010-05-18T09:15:26Z,2010-05-18T09:15:26Z,"This post http://lists.boost.org/Archives/boost/2010/03/164035.php goes over the issue in detail, with tests and real data.

Additionaly, the same functionality is duplicated in Boost.Interprocess (managed mapped files, which suffer less from the efficiency issues outlined in the above post) so it might be worthwhile to somehow kill the duplication with a single 'core'/'base' implementation.",Domagoj Šarić
4229,Lookup by 'order',mpl,Boost 1.44.0,Boost 1.43.0,Feature Requests,Aleksey Gurtovoy,new,2010-05-17T15:39:45Z,2010-05-17T15:39:45Z,"Please provide an at<> (or at-like) implementation for associative containers that accepts the value 'returned' by order<>.
Motivation/a description of an example use case can be found in the following post:
http://lists.boost.org/Archives/boost/2010/05/166358.php.",Domagoj Šarić
4228,Associative containers performance,fusion,Boost 1.44.0,Boost 1.43.0,Bugs,Joel de Guzman,new,2010-05-17T15:33:02Z,2014-04-09T02:08:43Z,"The Boost.Fusion documentation states that associative containers provide efficient key-based access while this seems not to be so in reality (AFAICT the associative containers actually use vectors for their implementation).

As reported in this post http://lists.boost.org/Archives/boost/2010/05/166358.php I have achieved meassurably better compile-time performance when using plain fusion::vectors with linear searches than with fusion::maps.
Attached are two simple tests that try to demonstrate this (Steven Watanabe's template profiler 'says' that both approaches yield the same number of template instantiations).

The reason that in my real life (much more complicated) project I get not only same but better performance with vectors might perhaps be that the find<> (linear search) on the 'main vector' might already be 'cached'/instantiated by some other operation.",Domagoj Šarić
4189,Add better support for non-default constructible function objects,iterator,Boost 1.42.0,Boost 1.43.0,Feature Requests,jeffrey.hellrung,new,2010-05-04T22:43:03Z,2013-08-23T07:29:19Z,"boost::transform_iterator is required to be default constructible, but not all function objects are. For example, boost::mem_fn_t is not default constructible. To allow transform_iterator to model DefaultConstructible with any function object type, Peter Dimov suggested using boost::optional. Thanks to Samuel Debionne for identifying and reporting the problem.",Daniel Walker
4186,"BOOST date_time:""time_resolution_traits"" undeclared or ambig error on IBM XL on AIX",date_time,Boost 1.54.0,Boost 1.54.0,Bugs,az_sw_dude,new,2010-05-04T17:52:44Z,2013-02-19T17:00:29Z,"Tests affected:
interprocess/comp_doc_anonymous_mutexA
interprocess/comp_doc_anonymous_mutexB
interprocess/comp_doc_anonymous_semaphoreA
interprocess/comp_doc_anonymous_semaphoreB
interprocess/comp_doc_anonymous_upgradable_mutexA
interprocess/comp_doc_anonymous_upgradable_mutexB
interprocess/comp_doc_anonymous_conditionA
interprocess/comp_doc_anonymous_conditionB

The compile-time error on with IBM XL (vacpp) on AIX is occuring due to name collision between a macro name (v_type) found on the OS in /usr/include/sys/vnode.h and same named template argument found in the boost header boost/date_time/time_resolution_traits.hpp.  

Here is a reduced test that demonstrates the problem:

t.C
=========
// From /usr/include/sys/vnode.h
enum vtype { VNON, VREG, VDIR, VBLK, VCHR, VLNK, VSOCK, VBAD, VFIFO, VMPC };
typedef enum vtype vtype_t;
struct gnode {
	enum vtype gn_type;	
};

struct vnode {
 	struct gnode *v_gnode;	
};

#define v_type		v_gnode->gn_type

template<typename v_type = int> class time_resolution_traits 
{ };

==============
Command: xlC -c t.C
Result:
""t.C"", line 15.21: 1540-0063 (S) The text ""->"" is unexpected.

Note that this problem is specific to AIX due to this macro used in AIX header.  Linux or other operating systems do not appear to exhibit this problem.

The solution is to provide a Boost patch file that renames template argument to another name in order to avoid name collision with the system files.",ccambly@…
4179,time_duration::operator*(int) has no versions for double and int64_t causing implicit truncating them to int32_t,date_time,Boost 1.42.0,Boost 1.43.0,Bugs,"James E. King, III",new,2010-05-03T02:47:05Z,2018-08-02T11:28:58Z,"time_duration::operator*(int) has no versions for double and int64_t causing implicit truncating them to int32_t

{{{
  std::cout << boost::posix_time::microseconds(1) * 1e8 << std::endl;
  std::cout << boost::posix_time::microseconds(1) * 1e9 << std::endl;
  std::cout << boost::posix_time::microseconds(1) * 1e10 << std::endl;
  std::cout << boost::posix_time::microseconds(1) * 1e11 << std::endl;
}}}

{{{
00:01:40
00:16:40
00:23:30.065408
00:20:15.752192
}}}",anonymous
4155,function docstring signatures include self argument,python USE GITHUB,Boost 1.40.0,Boost 1.43.0,Bugs,Dave Abrahams,new,2010-04-27T20:41:51Z,2010-06-14T14:31:36Z,"boost::python generates Python signatures, but these include a useless (and confusing) arg1 arguments for the class's self. I don't believe that python documentation should generally show this because people know that they are class methods.

For example:
http://www.murrayc.com/temp/glom_1_14_pydoc.html

I'm using boost::python 1.40 in Ubuntu Karmic. I can't find any list of what's changed since then.",murrayc@…
4153,Add symlink support for bjam on Windows,build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-27T09:28:53Z,2014-11-14T01:31:24Z,"Currently bjam does not supports symlinks under Windows and it does copy the files instead. This is doubling the required disk space for boost libraries (overhead of ~1.4GB).

Windows does supports several types of symlinks and hardlinks.

The problem is that there are several limitations that require to make a wise decision regarding implementation:

NT symlinks are limited to 32 per path so we cannot use them for libraries.

Instead we can create hardlinks because they do not have this limitation.

Now regarding hardlinks: 
* NTFS is required (not FAT32 support but this shouldn't be a real limitation in 2010). The same limitation would apply if you have FAT32 on Linux.
* Hardlink can be created using two options: fsutil hardlink create (XP+, but requires Admin rights), or mklink /H (Vista+, requires 'Create symbolic link' privilege that by default is assigned to Administrators group.)

I could easily patch symlink.jab file to use mklink or fsutil but I don't know if the above limitation are a blocking issue for accepting the patch. If this is true what would be the requirements for adding this feature to bjam?

I'm not sure if I can check the current partition type and privileges using jam but I could easily check if mklink fails and fallback to copy.

",Sorin Sbarnea <sorin.sbarnea@…>
4151,option_description::option_description(3 args) is exception-unsafe,program_options,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-26T06:01:09Z,2010-04-26T06:26:42Z,"Given the code in libs/program_options/src/options_description.cpp:


{{{
option_description::
option_description(const char* name,
                   const value_semantic* s,
                   const char* description)
: m_description(description), m_value_semantic(s)
{
    this->set_name(name);
}
}}}

s leaks in case if initialization of m_description throws.

The simplest cure is to make option::description::m_value_semantic member to be before all other members.",anonymous
4150,bool_switch() is exception-unsafe,program_options,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-25T18:07:26Z,2010-04-25T18:07:26Z,"
bool_switch() function leaks memory if typed_value::default_value() throws exception",anonymous
4148,bootstrap.bat generates project-config.jam file as Unicode (UTF-16),build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-24T20:07:51Z,2011-03-31T00:57:51Z,"On modern Windows (that is using Unicode console by default) the bootstrap.bat generates project-config.jam file as Unicode (UTF-16).

Boost is not able to read this file and is writing:
project-config.jam:1: syntax error at EOF

Solution is to modify bootstrap.bat to force the generation of ASCII file instead of Unicode:

Old line:
ECHO using %toolset% ; > project-config.jam

New line:
cmd /a /c ECHO using %toolset% ; > project-config.jam

This small change will force the usage of ANSI output. 

Reference:
http://www.netikka.net/tsneti/info/tscmd028.htm#ansivsunicode
cmd /a /c echo using %toolset% ; > project-config.jam



",Sorin Sbarnea <sorin.sbarnea@…>
4147,Use target-os instead of os in Jamfiles,build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-24T18:29:02Z,2010-06-07T09:50:21Z,"In many of the Jamfiles in Boost, the ""os"" property is used to add libraries and defines appropriate to the target operating system.  But the ""os"" property doesn't give the target operating system; it gives the build operating system.  The ""target-os"" property gives the target operating system.  So these Jamfiles do the wrong thing when cross-compiling.

According to Vladimir Prus on the Boost-build mailing list:

""Yes, in most cases 'target-os' should be used. Please file bugs for libraries that use 'os'.""

The full list of Boost libraries that appear to have this problem is:

asio
iostreams
thread

I generated this list by doing ""grep 'import os'"" and filtering out the python files, so it may not be all that accurate.
",Steve Soule <sts11dbxr@…>
4144,boost::program_options::parse_enviornment lacks allow_unregistered,program_options,Boost 1.42.0,Boost 1.43.0,Feature Requests,Vladimir Prus,new,2010-04-24T04:47:28Z,2010-04-24T04:47:28Z,"allow_unregistered should be an option for the parse_environment parser.

Given a suite of tools that share some but not all options, parse_environment forces all programs to register all possible options.

Given a suite of tools progb and progc such that:

progb --opta --optb
progc --opta --optc

are valid options to parse, using parse_environment(desc, ""PREFIX_"") will only work for PREFIX_OPTA.  If PREFIX_OPTB or PREFIX_OPTC are set the other program will fail.",dan@…
4142,Option names should be constructible from strings,program_options,Boost 1.42.0,Boost 1.43.0,Feature Requests,Vladimir Prus,new,2010-04-22T22:33:13Z,2011-10-01T13:05:15Z,"The constructor and set_name methods of option_description take only const char pointers and not strings.  (Likewise for the option_description_easy_init operator().)

Currently code such as the below fails to compile

{{{
std::string help=""help"";
po::options_description desc(""Allowed options"");
desc.add_options()
    (HELP, ""produce help message"");
}}}

We use strings for easy reuse them when checking the variable map of parsed options.

This came up on the dev list last month, and Vladimir said he'd look into why overloads for strings didn't already exist.([http://lists.boost.org/Archives/boost/2010/03/162646.php])  I assume you haven't had time, so here's a more persistent reminder.
",afoglia@…
4133,std::logic_error as a base class for program_options::error,program_options,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-04-21T13:15:21Z,2011-06-28T14:39:10Z,"""19.1 Exception classes

1 The Standard C  +  + library provides classes to be used to report certain errors (17.4.4.8) in C  +  + programs. In
the error model reflected in these classes, errors are divided into two broad categories: logic errors and
runtime errors.

2 The distinguishing characteristic of logic errors is that they are due to errors in the internal logic of the pro-
gram. In theory, they are preventable.

3 By contrast, runtime errors are due to events beyond the scope of the program. They cannot be easily pre-
dicted in advance. The header <stdexcept> defines several types of predefined exceptions for reporting
errors in a C  +  + program. These exceptions are related by inheritance.""

From what POV po::unknown_option is 'due to errors in the internal logic of the program'? All po:: errors should be separated into two groups (runtime and logic) or std::exception should be used as a base class.",anonymous
4125,Boost.Python should use macros to access members of PyMethodObject,python USE GITHUB,Boost 1.42.0,Boost 1.43.0,Patches,Dave Abrahams,new,2010-04-20T17:40:51Z,2010-12-23T13:44:59Z,"In libs/python/src/wrapper.cpp, the members of !PyMethodObject are accessed directly:
{{{
  ((PyMethodObject*)m.get())->im_self
  ((PyMethodObject*)m.get())->im_func
}}}
These accesses are not documented in the python API.
I suggest to use the following macros instead, which have been existing since python 1.6 at least:
{{{
  PyMethod_GET_SELF(m.get())
  PyMethod_GET_FUNCTION(m.get())
}}}
When using CPython, these macros expand to exactly the same code.

The goal is to allow other implementations of python, like !PyPy, to provide alternate compatible implementation of these macros, and thus be able to load modules compiled with Boost.Python.
",Amaury Forgeot d'Arc <amauryfa@…>
4111,Support for windmc tool,build,Boost 1.42.0,Boost 1.44.0,Feature Requests,Vladimir Prus,new,2010-04-18T09:20:32Z,2014-04-05T02:46:29Z,"It would be good if Boost.Build recognized the windmc tool that is available for MinGW and Cygwin toolsets. The documentation mentions[1] the mc-compiler feature that is supposed to alleviate the problem, but apparently this option doesn't work.

[1] http://www.boost.org/doc/tools/build/doc/html/bbv2/reference/tools.html
",Andrey Semashev
4097,limited support for detecting platform,build,Boost 1.42.0,Boost 1.43.0,Feature Requests,Vladimir Prus,new,2010-04-13T18:15:05Z,2013-06-12T21:36:59Z,"I some assembler code is required by a library - boost.build has some limited support to detect platform features.
For instance it is necessary to know for which architecture the lib should be build. The builtin properties <architecture> and <instruction-set> are optional properties (so a developer can not rely on it). Additinaly the binary format has to be known. Suggestion: new builtin property <linkage> with values like elf, windowspe, mach-o.",k-oli@…
4068,Borland also needs private/public workaround in boost::exception,exception,Boost 1.42.0,Boost 1.43.0,Patches,niels_dekker,new,2010-04-05T14:21:26Z,2011-07-30T22:39:37Z,"Borland/CodeGear currently won't compile boost::exception, because it cannot deal with the friend declarations of exception_detail::set_info, inside the boost::exception class definition. So please consider applying the attached patch. It leaves the data of boost::exception public, when {{{__BORLANDC__<=0x621}}}, just like you did for other compilers.

Note: I have no idea whether the workaround is still needed when {{{__BORLANDC__>0x621}}}. It's just that I only tested Embarcadero/CodeGear C++ 6.21. But older Borland versions certainly have the same problem.  For example, http://www.boost.org/development/tests/trunk/output/siliconman-boost-bin-v2-libs-exception-test-all_hpp_test-test-borland-5-9-3-debug.html says:
{{{
..\libs\exception\test\all_hpp_test.cpp:
Error E2401 ..\boost/exception/exception.hpp 228: Invalid template argument list
Error E2401 ..\boost/exception/exception.hpp 231: Invalid template argument list
Error E2401 ..\boost/exception/exception.hpp 234: Invalid template argument list
Error E2401 ..\boost/exception/exception.hpp 237: Invalid template argument list
Error E2109 ..\boost/exception/exception.hpp 337: Not an allowed type
Error E2228 ..\boost/exception/exception.hpp 337: Too many error or warning messages
*** 6 errors in Compile ***
}}}

",niels_dekker
4064,std::bad_cast should be thrown with BOOST_THROW_EXCEPTION,statechart,Boost 1.42.0,Boost 1.46.0,Bugs,Andreas Huber,assigned,2010-04-04T10:33:25Z,2010-11-06T08:11:07Z,"Also, other try/catch/throw statements should be put into appropriate #ifndef blocks.

Reported by Thomas Mathys.",Andreas Huber
4063,Add debugging support,statechart,Boost 1.42.0,Boost 1.47.0,Feature Requests,Andreas Huber,assigned,2010-04-04T09:48:56Z,2010-11-06T08:09:26Z,See <http://thread.gmane.org/gmane.comp.lib.boost.user/52305>,Andreas Huber
4062,Write a FAQ item on why state constructors do not have access to event data,statechart,Boost 1.42.0,Boost 1.46.0,Tasks,Andreas Huber,assigned,2010-04-04T09:33:16Z,2013-12-15T14:42:02Z,"The following techniques should be mentioned:

- transition actions & store data in an outer state
- repost in transition action & react in an in-state reaction
- triggering_event",Andreas Huber
4057,Patch to allow posix_time::ptime to have boost::gregorian::days overloaded operators,date_time,Boost 1.42.0,Boost 1.43.0,Feature Requests,az_sw_dude,new,2010-04-02T03:53:09Z,2010-12-02T08:44:08Z,"Within boost/date_time/posix_time/date_duration_operators.hpp, there are overloaded operators for months and years, but not days.  I found out this was missing while trying to use ptime for some things.  I wanted to contribute a patch.

The patch will allow operators +, -, +=, -= for gregorian days.

I am using gentoo's dev-libs/boost-1.42 at this time.  My apologies if I'm out of date.

Please apply my patch directly to the file.  Again, my apologies if I'm not complying with some format.  I don't often contribute patches to projects.",adam.preble@…
4045,"MultiArray implementation from base, extents, strides",multi_array,Boost 1.42.0,To Be Determined,Feature Requests,Ronald Garcia,new,2010-03-25T14:38:28Z,2010-03-25T19:42:21Z,"It would be useful to have a multi_array_ref constructor or some other MultiArray implementation that can accept explicit stride information rather than storage order information.  The former is more flexible and can accomplish things the latter cannot (see example below).

----

I sent the following question to boost-users (http://lists.boost.org/boost-users/2010/03/57634.php):



I'd like to obtain an N-dimensional MultiArray implementation given a base pointer, N extents, and N strides.  My use case requires padding the stride in one dimension in a way seemingly not obtainable taking views of the usual boost::multi_array_ref.

Code like the following would be ideal
{{{
   boost::array<std::size_t,3> extents = { 2, 3, 4 };
   boost::array<std::size_t,3> strides = { 1, 2, 7 };  // Note 7 not 6
   boost::scoped_array<int> raw(new int[extents[2]*strides[2]]);

   using boost::detail::multi_array::multi_array_view;
   multi_array_view<int,3> a(raw.get(), extents, strides);
}}}
except that the appropriate constructor in multi_array_view is private (boost/multi_array/view.hpp:442).
boost::detail::multi_array::sub_array would also be ideal if it's
constructor was accessible (boost/multi_array/subarray.hpp:370).  I can make either accessible by #defining BOOST_NO_MEMBER_TEMPLATE_FRIENDS, but that's evil.

Am I missing something in Boost.MultiArray?  Or is there no publicly
accessible way to provide a custom stride list?",Rhys Ulerich <rhys.ulerich@…>
4040,Program Options has issues with options that support multiple tokens when using multiple parsers,program_options,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-03-24T18:23:45Z,2010-03-24T18:23:45Z,"If you have an option that allows multiple tokens and give that option at both command line and config file, only the tokens listed on the command line are saved.

I fixed this issue by changing:
{{{
            // If option has final value, skip this assignment
            if (xm.m_final.count(name))
                continue;

            const option_description& d = desc.find(name, false, 
                                                      false, false);
}}}
to:
{{{
            const option_description& d = desc.find(name, false, 
                                                      false, false);

            // If option has final value, skip this assignment
            if ((xm.m_final.count(name)) && (d.semantic()->max_tokens() <= 1))
                continue;
}}}

in boost::program_options::store() function in the file boost/libs/program_options/src/variables_map.cpp.",Devin Crumb <dcrumb@…>
4037,Create is_multi_array and is_const_multi_array type trait,multi_array,Boost 1.42.0,To Be Determined,Feature Requests,Ronald Garcia,new,2010-03-23T15:34:44Z,2010-03-23T15:34:44Z,"Please consider creating Boost.TypeTraits-like is_multi_array and is_const_multi_array.  It seems that the current concept checks are not usable for SFINAE purposes, e.g. using the Enable = void boost::enable_if trick.

Arises from discussions about getting MultiArray plugged into uBlas: http://lists.boost.org/MailArchives/ublas/2010/03/4107.php",Rhys Ulerich <rhys.ulerich@…>
4035,"Milliseconds separated by other char than ""."" cannot be parsed by date_time_io",date_time,Boost 1.42.0,Boost 1.43.0,Feature Requests,az_sw_dude,new,2010-03-23T11:29:53Z,2010-03-23T11:29:53Z,"We have input data in the form of:
11:16:27:000
representing
hour:minutes:seconds:milliseconds

Currently, there seems to be no way of defining a format string to parse this. ""%f"" always expects a dot character starting the substring.",stefan.moebius@…
4033,optimized matrix products,uBLAS,Boost 1.42.0,Boost 1.43.0,Patches,Gunter,assigned,2010-03-22T21:38:27Z,2010-03-29T06:58:56Z,"proposal from Jörn Ungermann:

'''Abstract'''

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

'''Details'''

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

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

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

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

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

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

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

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

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

The runtime shall be taken only qualitatively.

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

It is also obvious to see, why some people complain about product
performance, as especially axpy_prod and prod are sometimes ridiculously
slow for sparse matrices and sparse_prod does not seem to be documented
in the special products section.
My favorite case is ""com_cm, com_cm, den_rm"" one, which actually
occurred in the diagnostics part of our application and was the reason
why we started looking into this topic.",Gunter
4028,fusion::begin and fusion::end lead to problems with ADL-based begin and end functions for ranges,fusion,Boost 1.42.0,To Be Determined,Bugs,Joel de Guzman,reopened,2010-03-19T11:05:17Z,2013-07-02T11:56:21Z,"In C++0x, begin and end for ranges (that extract the beginning iterator and the past-the-end one, respectively) are to be found through ADL.
This causes problems when fusion is an associated namespace (as for example in the case {{{ iterator_range< some_iterator< fusion::vector<> > > }}}), since the begin and end of the fusion namespace will be considered by ADL, and that results in an error because a range is not a fusion sequence.

I see two (three) solutions:[[BR]]
- Mask fusion::begin and fusion::end with SFINAE so that they are only available if the argument is a fusion sequence. That means however that we can't have a fusion sequence that is at the same time a range, even though this could have some uses.[[BR]]
- Rename fusion::begin and fusion::end to something else.[[BR]]
(- Ask the standard people to reconsider)",Mathias Gaunard
4011,Strange bug may be associated with rounded_transc_opp policy,interval,Boost 1.38.0,To Be Determined,Bugs,Boris Gubenko,new,2010-03-15T19:54:19Z,2010-06-04T07:35:22Z,"When I evaluate the following expression:
a = Interval(1.0, 3.0)[[BR]]
exp( a * log(0.001) )[[BR]]

I receive the result [nan ~ nan] when I select the rounded_transc_opp policy. However, if I select the rounded_transc_exact all goes well and I receive the expected result: [1E-9 ~ 0.001]

If I select the rounded_transc_opp policy and evaluate the expression:[[BR]]
exp( a * log(0.0001) )
all works well and I receive the expected result: [1E-12 ~ 0.0001]
also works well for:[[BR]]
exp( a * log(0.0011) )
but not with:[[BR]]
exp( a * log(0.00101) )

I hope that someone can look at this problem, since this is really a very strange situation.

Keep up with this excellent work and
best regards...

Vitor


",Vitor Vieira Lopes <vitor.lopes@…>
3996,Enable use of BOOST_FOREACH over const-ref of noncopyable ptr_containers,ptr_container,Boost Development Trunk,To Be Determined,Patches,Thorsten Ottosen,reopened,2010-03-10T20:24:04Z,2012-07-20T19:32:45Z,"I have encountered an error about allocating abstract type, with the
following code:
{{{
#include ""boost/ptr_container/ptr_vector.hpp""
#include ""boost/foreach.hpp""
struct S { virtual void f() const = 0; };
typedef boost::ptr_vector<S> ptr_vector;
void f(ptr_vector const& v) { BOOST_FOREACH(S const& s, v) s.f(); }
}}}
And I found this is a known issue:
[http://www.boost.org/doc/libs/1_42_0/doc/html/foreach/extensibility.html#id862475 Boost.Foreach > Extensibility]

Then I thought that boost::foreach::is_noncopyable<> should be
specialized for ptr_containers of which value_type is abstruct. Then I
put the following:
{{{
namespace boost { namespace foreach {
  template<typename T, typename A, typenale CA>
  struct is_noncopyable<ptr_vector<T,A,CA> > : is_abstract<T> {};
}}
}}}
... and the error disappeared.

After that, since ptr_container is designed to be an alternative of the
standard containers for the case of the value is non-copyable, I thought
this is a wide problem worth making a patch.

The patch looks better than the above workaround in some points:
  - fixes the problem for all ptr_containers at once
  - also supports types marked by boost::noncopyable
  - keeps the container copyable if view_clone_allocator is used

The patch also includes some test cases I actually used, while I have no
idea how to integrate it into boost test infrastructure.
",Kazutoshi Satoda <k_satoda@…>
3993,target-os=linux should imply threadapi=posix,build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-03-09T21:14:01Z,2010-06-07T09:27:58Z,Trying to do crosscompile from windows host to linux target results in windows.h included in Boost.Thread. Should default to posix threadapi in this case.,Vladimir Prus
3982,mpl::at documentation out of sync with code,mpl,Boost 1.42.0,Boost 1.43.0,Bugs,Aleksey Gurtovoy,new,2010-03-06T11:03:41Z,2016-03-07T19:26:50Z,"Documentation of mpl::at indicates that it can take either 2 or 3 template parameters, but in fact only takes just 2.  The documentation indicates a third template parameter to forward a default if lookup fails to find a match.  This option does not exist.

Code or Documentation should be amended.  If there will be no 3 template parameter option, the following would be nice to have in the documentation, as how to achieve a default when no match is found:


typename boost::mpl::eval_if<
    typename boost::mpl::has_key< Map, Key >::type
  , boost::mpl::at< Map, Key >
  , boost::mpl::identity< Default >
  >::type  


",manfred.doudar@…
3967,Parsing dates using date_input_facet accepts wrong input,date_time,Boost 1.37.0,Boost 1.43.0,Bugs,az_sw_dude,new,2010-03-01T13:17:41Z,2013-06-08T19:41:16Z,"Hi!

I got no answer on the ML, but I consider this a bug.
With the code below I try to automagically determine the date
format found in input files. I'd expect the code below to find the
date format ""%d.%m.%Y"" for ""05.02.2008"", but I got surprised by 
obtaining ""%m/%d/%Y"". 
It seems like date accepts '.' where I said ""expect '/'"", so I think
this should be changed. 


#include <boost/assign/list_of.hpp>

#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/date_time/gregorian/gregorian.hpp>
#include <boost/date_time/local_time/local_time.hpp>
#include <boost/foreach.hpp>
#include <boost/algorithm/string.hpp>

#include <string>
#include <list>

inline std::string determine_date_format(std::string const & s)
{
    using namespace boost::assign;
    using namespace boost::gregorian; 

    std::list<std::string> possible_formats = // TODO: add others here!
        list_of (""%Y-%m-%d"")(""%Y/%m/%d"")(""%m/%d/%Y"")(""%d.%m.%Y""); 

    bool inform_user = false;

    BOOST_FOREACH(std::string const & format, possible_formats)
    {
        if (inform_user)
        {
            std::cout << ""Trying format '"" << format << ""' ..."" << std::endl; 
        } 

        try
        {
            date_input_facet * input_facet = 
                new date_input_facet(format.c_str()); 
            std::istringstream iss(s); 
            iss.imbue(std::locale(iss.getloc(), input_facet)); 
            date d(not_a_date_time); 

            iss >> d; 
            if (!iss.fail() && (!d.is_not_a_date()))
            {
                return format;
            }

            std::cout << ""WARNING: date format '"" << format 
                      << ""' does not match '"" << s << ""'."" << std::endl;   
            inform_user = true;
        }
        catch(...)
        {
        }
    }

    std::cout << ""WARNING: date format not recognized. ""
              << ""Please reconfigure your measurement equipment ""
              << ""to ISO standard output!"" 
              << std::endl;

    return """";
}

int main()
{
    std::string the_date = ""05.02.2008""; 
    std::string format = determine_date_format(the_date);
    std::cout << the_date << "" has date-time-format "" 
              << format << std::endl;    
    return 0;
}

",anonymous
3965,missing functions last_access_time() and last_status_change_time(),filesystem,Boost 1.42.0,Boost 1.43.0,Feature Requests,Beman Dawes,assigned,2010-02-28T05:35:24Z,2012-04-20T13:03:10Z,"In Boost.Filesystem I can find a function:

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

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

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

Cheers,
Sascha
",Sascha Ochsenknecht
3954,fusion algorithms must be overloaded for const and non-const arguments,fusion,Boost 1.42.0,Boost 1.43.0,Bugs,Joel de Guzman,new,2010-02-23T08:38:32Z,2010-02-23T08:38:53Z,"Several fusion algorithms (e.g. pop_front, reverse) take their arguments by const reference unconditionally. This is inconsistent with the result_of templates for these algorithms which are sensitive to the const-ness of their arguments. For consistency and correctness, all fusion algorithms must have overloads that take their arguments by non-const reference.
",Eric Niebler
3949,"filesystem::rename() ""does not exist"" check is sometimes unwanted",filesystem,Boost 1.42.0,Boost 1.43.0,Feature Requests,Beman Dawes,new,2010-02-19T22:01:03Z,2010-02-19T22:01:03Z,"POSIX allows to rename/move a file over another, unlike Windows.  Currently, Boost (according to source code) explicitly adds a check against this, using an exists() call.  However, sometimes POSIX behavior is desired, to avoid extra remove() call.

Moreover, since exist()/remove()/rename() is inherently non-atomic (as are all filesystem operation), this unnecessarily (on POSIX) creates another race-condition point.

Request: change rename prototype to rename(from, to, overwrite = false) and adjust code accordingly.  If 'overwrite' is false (default) it will work just as now, so the change is fully backward-compatible.  If overwrite is 'true', POSIX implementation will just omit its exist() check, while Windows implementation will call remove(to) and catch errors.",Paul Pogonyshev <pogonyshev@…>
3948,Conflict between concept_check and shared_ptr,concept_check,Boost 1.42.0,Boost 1.43.0,Bugs,jsiek,new,2010-02-19T21:49:02Z,2010-02-19T21:49:02Z,"Hello,

The following code compiled with MSVC 2005 or 2008 :
{{{
#include <boost/concept_check.hpp>

namespace boost
{
    template< typename T >
    class some_type
    {};

    template< typename T1, typename T2 >
    bool operator<( const some_type< T1 >&, const some_type< T2 >& );
}

class c {};

BOOST_CONCEPT_ASSERT((boost::LessThanComparable< c >));
}}}

Produces the following error :
{{{
1>C:\Users\Mat\Desktop\dev\include\boost/concept_check.hpp(242) : error C2784: 'bool boost::operator <(const boost::some_type<T> &,const boost::some_type<T2> &)' : could not deduce template argument for 'const boost::some_type<T> &' from 'c'
1>        ..\..\src\tests\turtle_test\concept_check_test.cpp(19) : see declaration of 'boost::operator <'
1>        C:\Users\Mat\Desktop\dev\include\boost/concept_check.hpp(241) : while compiling class template member function 'boost::LessThanComparable<TT>::~LessThanComparable(void)'
...
}}}

Changing the namespace from boost to anything else (for instance nm) produces the correct error output e.g. :
{{{
1>C:\Users\Mat\Desktop\dev\include\boost/concept_check.hpp(242) : error C2676: binary '<' : 'c' does not define this operator or a conversion to a type acceptable to the predefined operator
1>        C:\Users\Mat\Desktop\dev\include\boost/concept_check.hpp(241) : while compiling class template member function 'boost::LessThanComparable<TT>::~LessThanComparable(void)'
...
}}}

This use case is actually quite common because for instance in boost::shared_ptr there is such a construct, in the boost namespace of course. Therefore the following code exhibits the same problem :

{{{
#include <boost/concept_check.hpp>
#include <boost/shared_ptr.hpp>

class c {};

BOOST_CONCEPT_ASSERT((boost::LessThanComparable< c >));
}}}

Maybe enclosing the concept check code into another level of namespace would prove enough to protect from the lookup ?

Thank you !",m.champlon@…
3943,LSB compliance for ASIO,asio,Boost 1.42.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2010-02-18T01:35:38Z,2010-03-18T20:07:41Z,ASIO uses ioctls which LSB considers unportable. It would be useful if ASIO could instead switch to using alternates like fcntl where possible and degrade gracefully for LSB compliance.,Sohail Somani
3940,BOOST_SCOPE_EXIT without arguments,scope_exit,Boost 1.48.0,To Be Determined,Feature Requests,nasonov,reopened,2010-02-17T16:19:51Z,2011-11-23T12:33:26Z,"Why the following code doesn't work ??

{{{
#!cpp

BOOST_SCOPE_EXIT()
{
  puts(""Exit"");
} BOOST_SCOPE_EXIT_END
}}}

But this does work:

{{{
#!cpp

int dummy;
BOOST_SCOPE_EXIT( (dummy) )
{
  puts(""Exit"");
} BOOST_SCOPE_EXIT_END
}}}",anonymous
3936,[xpressive] stack overflow.,xpressive,Boost 1.42.0,Boost 1.43.0,Bugs,Eric Niebler,assigned,2010-02-16T14:56:20Z,2010-02-17T00:06:35Z,"The following simple program fires a stack overflow exception in xpressive. It's seems too simple to be causing such problems.

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


int _tmain(int argc, _TCHAR* argv[])
{
	sregex rx = ~(set='{', '}', ',');
	sregex rx2 = +rx;

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

	return 0;
}}}}

I'm using MSVC 2005. The problem only occurs if the string is large.",shewitt.au@…
3935,stream<file_sink> does not throw an exception and not set fail/bad bits when file is wrong,iostreams,Boost 1.42.0,Boost 1.43.0,Bugs,Jonathan Turkanis,new,2010-02-16T13:28:02Z,2014-11-05T04:30:42Z,"I'm trying to write some content to a new file using
boost::stream<file_sink> class.
Unfortunately errors/failures during opening the file are ignored by
boost library.

See attached test.cpp file for snippet.

Above program is started as non root user and have not access for file /wrong.txt

Result is:[[BR]]
mariusz@ppbw:~/boost-1.42$ ./test [[BR]]
boost ver:1_42
[[BR]]
0 0[[BR]]
nothing thrown[[BR]]

mariusz@ppbw:~/boost-1.42$ ls /[[BR]]
bin    dev   initrd.img      lost+found  opt   sbin  tmp  vmlinuz[[BR]]
boot   etc   initrd.img.old  media       proc  srv   usr 
vmlinuz.old[[BR]]
cdrom  home  lib             mnt         root  sys   var[[BR]]

mariusz@ppbw:~/boost-1.42$ ldd ./test[[BR]]
	linux-gate.so.1 =>  (0xb7fc4000)[[BR]]
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7eb0000)[[BR]]
	libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e8a000)[[BR]]
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e6c000)[[BR]]
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d0e000)[[BR]]
	/lib/ld-linux.so.2 (0xb7faa000)[[BR]]
mariusz@ppbw:~/boost-1.42$ [[BR]]

Similar program using std::ofstream works as I expected:
- console prints: 1 0[[BR]]
- exception is thrown [[BR]]

I made tests using:[[BR]]
boost 1.42[[BR]]
Ubuntu 8.10 intrepid[[BR]]
g++ (Debian 4.3.2-1.1) 4.3.2[[BR]]",zxspeccy.cpp@…
3930,More flexible dynamic linking for python module on OS X,python USE GITHUB,Boost 1.42.0,To Be Determined,Patches,Dave Abrahams,new,2010-02-14T14:38:03Z,2013-07-29T15:32:17Z,"See http://trac.mapnik.org/ticket/453/.

Without these patches to python.jam and darwin.jam, boost.python refused to build with the following error for me on OS X 10.6 (Snow Leopard), even when I set my path to use a version of Python (from Sage) which was compiled with UCS4. With these changes, you can build against both system Python (UCS2) and Sage Python (UCS4). This should probably be incorporated directly into boost, it took me several hours of headaches to figure this out.

{{{
Undefined symbols:
  ""_PyUnicodeUCS4_FromEncodedObject"", referenced from:
      _encode_string_unaryfunc in builtin_converters.o
  ""_PyUnicodeUCS4_AsWideChar"", referenced from:
      boost::python::converter::(anonymous namespace)::slot_rvalue_from_python<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, boost::python::converter::(anonymous namespace)::wstring_rvalue_from_python>::construct(_object*, boost::python::converter::rvalue_from_python_stage1_data*)in builtin_converters.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
}}}",Cyrus Omar
3926,thread_specific_ptr + dlopen library causes a SIGSEGV.,thread,Boost 1.42.0,,Bugs,viboes,reopened,2010-02-12T23:05:31Z,2016-03-31T22:13:53Z,"hi,

i've discovered that using thread_specific_ptr in shared library dlopened from thread causes a gpf.[[BR]]
please consider following scenario:
[[BR]][[BR]]
spawn thread[[BR]]
dlopen a shared library with thread_specific_ptr[[BR]]
dlclose the library[[BR]]
terminate the thread[[BR]]
[[BR]]
observe the gpf[[BR]]
[[BR]]
{{{
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff62b7400 in ?? ()
(gdb) bt
#0  0x00007ffff62b7400 in ?? ()
#1  0x00007ffff7221f79 in __nptl_deallocate_tsd () at pthread_create.c:154
#2  0x00007ffff722291b in start_thread (arg=<value optimized out>) at pthread_create.c:304
#3  0x00007ffff6f9293d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()
}}}
afaics the pthread (user provided) destructor keyed to pthread specific data is called on dlunloaded code.[[BR]][[BR]]
BR,[[BR]]
Pawel.


",pluto@…
3925,Property tree documentation is seriously out of date,property_tree,Boost 1.42.0,Boost 1.43.0,Tasks,Sebastian Redl,new,2010-02-12T15:51:21Z,2013-12-20T10:47:51Z,"At http://www.boost.org/doc/libs/1_42_0/doc/html/boost_propertytree/parsers.html, the end page notes contains stuffs like ""[include cmd_line_parser.qbk]"", this is unlikely what the author wants.

At http://www.boost.org/doc/libs/1_42_0/doc/html/boost_propertytree/accessing.html, the 2nd code is like ""double pi = boost::lexical_cast<double>(it->second._ptree_data__());"", _ptree_data__ is just wrong. Same for the last code ""pt.__ptree_put_own__(3.14f);""

I'm pretty sure I could find much more errors like this, someone should take the time to read the documentation accuratly.

",anonymous
3918,MPI std::string serialization,mpi,Boost 1.41.0,,Support Requests,Matthias Troyer,new,2010-02-11T12:36:59Z,2013-01-01T11:09:35Z,"I'm new in MPI and cluster computations.
I have 2 machines on gentoo (amd64 and x86), both with openmpi-1.4.1 and boost-1.41.0 . 'Heterogeneous' flags is set.
I'm trying to run example at http://www.boost.org/doc/libs/1_41_0/doc/html/mpi/tutorial.html#mpi.nonblocking and it work when i run it in two processes at one machine, but it throws an exception, if i use both (-npernode 1).
I didn't fully understand what serialization does, but on separate machine it work with or without it (i'm talking about header boost/serialization/string.hpp), with using both of machines, i always have exception.

I don't mark that message as bug, i really think i'm just doing something wrong.",Ghost99 <ghost99@…>
3904,installing boost 1.42 does not update all include files in the destination directory,build,Boost 1.42.0,Boost 1.43.0,Bugs,Vladimir Prus,new,2010-02-05T21:49:53Z,2010-06-07T09:51:06Z,"Having  previously installed boost 1_41_0 on CentOS 5.4 (x86_64 bit), I built and installed boost 1_42_0.  Some include files were not updated, because test programs I tried to compile outside the boost 1_42_0 tree would not compile.  Once I removed the destination directory 
/opt/local/boost, and re-installed boost 1_42_0, my test programs did compile.",Joe VanAndel <vanandel@…>
3880,Program_options -> wostream operator,program_options,Boost Development Trunk,Boost 1.42.0,Feature Requests,Sascha Ochsenknecht,new,2010-01-29T22:50:46Z,2010-02-03T06:51:27Z,"Program options::options_description has a output operator for
std::ostream, but none for std::wostream.",jensen.bo@…
3877,I don't see any doc for is_lvalue_iterator (and related metafunctions),iterator,Boost 1.41.0,Boost 1.42.0,Bugs,jeffrey.hellrung,new,2010-01-29T11:42:35Z,2012-11-21T19:43:15Z,subject says it all,anonymous
3874,[map0 / insert] inserting into map0 does not work without including map10.hpp,mpl,Boost 1.41.0,Boost 1.42.0,Bugs,Aleksey Gurtovoy,new,2010-01-29T01:02:00Z,2010-06-05T20:51:46Z,"The following does not compile on MSVC9:

{{{
#include <boost/mpl/insert.hpp>
#include <boost/mpl/map/map0.hpp>
#include <boost/mpl/pair.hpp>

typedef boost::mpl::insert<
    boost::mpl::map0<>,
    boost::mpl::pair< void, void >
>::type map1_type;

typedef boost::mpl::insert<
    map1_type,
    boost::mpl::pair< int, int >
>::type map2_type;

int main() { }
}}}

The compiler output is

{{{
1>------ Build started: Project: test, Configuration: Debug Win32 ------
1>Compiling...
1>main.cpp
1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2903: 'apply' : symbol is neither a class template nor a function template
1>        d:\test\main.cpp(13) : see reference to class template instantiation 'boost::mpl::insert<Sequence,Pos_or_T>' being compiled
1>        with
1>        [
1>            Sequence=map1_type,
1>            Pos_or_T=boost::mpl::pair<int,int>
1>        ]
1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2039: 'apply' : is not a member of 'boost::mpl::insert_impl<boost::mpl::non_sequence_tag>'
1>        d:\boost_1_41_0\boost\mpl\aux_\insert_impl.hpp(64) : see declaration of 'boost::mpl::insert_impl<boost::mpl::non_sequence_tag>'
1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2955: 'boost::mpl::apply' : use of class template requires template argument list
1>        d:\boost_1_41_0\boost\mpl\aux_\preprocessed\plain\apply.hpp(134) : see declaration of 'boost::mpl::apply'
1>d:\boost_1_41_0\boost\mpl\insert.hpp(32) : error C2143: syntax error : missing ',' before '<'
1>d:\test\main.cpp(13) : error C2039: 'type' : is not a member of 'boost::mpl::insert<Sequence,Pos_or_T>'
1>        with
1>        [
1>            Sequence=map1_type,
1>            Pos_or_T=boost::mpl::pair<int,int>
1>        ]
1>d:\test\main.cpp(13) : error C2146: syntax error : missing ';' before identifier 'map2_type'
1>d:\test\main.cpp(13) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\test\main.cpp(13) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>Build log was saved at ""file://d:\test\Debug\BuildLog.htm""
1>test - 8 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
}}}

A fix (which took me a while to figure out, since the above error message didn't give me any clues) is to include <boost/mpl/map/map10.hpp>.  I think either a note should be made in the documentation for insert, the error message should be more helpful (maybe a comment in mpl/insert.hpp line 32???), or the above code should ""just work"".",Jeffrey Hellrung <jhellrung@…>
3841,error: Empty path passed to 'make-UNIX',Building Boost,Boost 1.41.0,Boost 1.42.0,Support Requests,Vladimir Prus,new,2010-01-14T17:30:32Z,2010-01-14T17:30:32Z,"macos 10.5.7
xcode 3.1.4
compiler: gcc 4.0.1
boost: 1.41.0
bjam 3.1.17

1. i have installed boost into /usr/local/boost 
2. compilation succeeded
3. bjam was copied to /usr/bin
3. but when i try to run bjam in folder on other drive (only Jamroot.jam is in folder, BOOST_ROOT and BOOST_BUILD_PATH variables are set in local environment) to build my project, then i get these errors:

/usr/local/boost/tools/build/v2/util/path.jam:528: in make-UNIX from module path
error: Empty path passed to 'make-UNIX'
/usr/local/boost/tools/build/v2/util/path.jam:44: in path.make from module path
/usr/local/boost/tools/build/v2/build/targets.jam:395: in find-really from module object(project-target)@39
/usr/local/boost/tools/build/v2/build/targets.jam:428: in object(project-target)@39.find from module object(project-target)@39
/usr/local/boost/tools/build/v2/build-system.jam:666: in load from module build-system
/usr/local/boost/tools/build/v2/kernel/modules.jam:283: in import from module modules
/usr/local/boost/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module
/usr/local/boost/tools/build/v2/boost-build.jam:8: in module scope from module

how can i fix this problem?
--
Sergey

",i509lancome-tm@…
3821,[graph] Improved version of transitive_reduction.hpp and documentation for it.,graph,Boost 1.43.0,Boost 1.46.0,Feature Requests,Jeremiah Willcock,new,2010-01-05T18:14:40Z,2013-10-28T10:19:16Z,"Hi there, 

in the attached transitive_reduction.tar.bz2 there are the following
files:

transitive_reduction.hpp          -- the actual algorithm

transitive_reduction.html         -- its documentation, the links are done so, that it *should* work if this file and the figs directory below is placed in 
libs/graph/doc

transitive_reduction_example1.cpp -- in this example a graph is compared to its transitive closure and transitive reduction, which my wife and I computed by hand.

transitive_reduction_example2.cpp -- in this example a graph is compared to its transitive closure and transitive reduction, which my wife and I computed by hand.

transitive_reduction_test1.cpp    -- the silenced example1 for use as a regression test. Returns 0 if everything is all right and 1 if it is not so.

transitive_reduction_test2.cpp    -- same here.

-- these figures are used by the documentation

figs/tr_example_graph_1.png
figs/tr_example_graph_1_transitive_closure.png
figs/tr_example_graph_1_transitive_reduction.png
figs/tr_example_graph_2.png
figs/tr_example_graph_2_transitive_closure.png
figs/tr_example_graph_2_transitive_reduction.png

Sorry for not providing a real ""patch"" or a Jamfile for the test cases, but I simply don't know how to write a Jamfile and refuse
to learn ""just the next make/cmake/ant/..."".

Yours sincerely,

Eric",Eric Böse-Wolf <eric@…>
3813,program_options::options_description.add() permits duplicate options,program_options,Boost 1.41.0,Boost 1.42.0,Bugs,Sascha Ochsenknecht,new,2010-01-03T17:00:42Z,2011-12-16T09:23:23Z,"The documentations for options_description.add() says it will through duplicate_variable_error for duplicate short or long options. I have check versions 1.32.0 and 1.41.0, and both permit this code:
{{{
#include <boost/program_options.hpp>
#include <iostream>

namespace po = boost::program_options;
 
int main()
{
    po::options_description opts;

    opts.add_options()
        (""help"", ""first  --help"")
        (""help"", ""second --help"")
        ;
    opts.add_options()
        (""alpha,a"", ""first  -a"")
        (""apple,a"", ""second -a"")
        ;
 

    std::cout << opts;

    return 0;
}
}}}

Producing this output:
{{{
  --help                first  --help
  --help                second --help
  -a [ --alpha ]        first  -a
  -a [ --apple ]        second -a
}}}

",Matthew Wesley <weslem-boosttrac@…>
3792,Boolean Metafunction for determining whether a type has been registered,typeof,Boost 1.41.0,Boost 1.42.0,Support Requests,Peder Holt,new,2009-12-23T17:40:54Z,2009-12-23T17:40:54Z,The typeof library should have a boolean metafunction which can be used to determine whether a type has been registered or not. This would greatly aid in using typeof in template metaprogramming.,Edward Diener <eld@…>
3791,incorrect postcondition in documentation,mpl,Boost 1.41.0,Boost 1.42.0,Bugs,Aleksey Gurtovoy,new,2009-12-22T14:20:40Z,2009-12-22T14:20:40Z,"I don't think the following postcondition for ""insert"" on associative sequences is correct:

typedef insert<s,x>::type r;
Postcondition:
size<r>::value == size<s>::value + 1.

if r contains x, size<r>::value == size<s>::value
",anonymous
3790,parameterize SBO size on boost::function,function,Boost 1.41.0,Boost 1.42.0,Feature Requests,Douglas Gregor,new,2009-12-22T13:37:05Z,2009-12-22T13:37:05Z,"http://lists.boost.org/boost-users/2009/12/54250.php

* It would be really nice to parameterize the SBO size like this:

{{{
template<typename Signature,std::size_t SBOSize=3*sizeof(void*)> 
class function; 
}}}


* Saving that it would be useful to have a constructor to allow you to change the allocator like this:
{{{
  template<typename Allocator> 
  functionN(const functionN&, Allocator); 
}}}
",Christopher Hite
3789,boost::object_pool::free() is very slow.,pool,Boost 1.41.0,To Be Determined,Bugs,John Maddock,new,2009-12-22T07:03:36Z,2016-07-29T05:17:08Z,"    boost::object_pool::free() Design is very bad。The main problem is in ：
    [void * simple_segregated_storage<SizeType>::find_prev(void * const ptr)]
    Whenever a user to delete a node, we must traverse to the previous nodes from list head. Means, if we have created 10,000 objects and 9,000 removed from the ground, then when the user to delete the first 9001 objects, he would traverse the list from scratch 9,000 times.",Dai Yun <dy95020@…>
3786,Incoherent views of various storage order,multi_array,Boost 1.41.0,To Be Determined,Bugs,Ronald Garcia,new,2009-12-21T06:15:33Z,2009-12-21T06:15:33Z,"I have a 256x258 array with only the first 256 lines of interest.
The flatten memory block contains then 256 interesting values, 2 craps, 256 interesting values, 2 craps, etc.

I want to access each column of the interesting block, then each line. For this I use :
 1. a view of the array with limited range in the second dimension
 2. a view of line-major ordered array reference to the same block of memory, with limited range in the first dimension

Here is a test code:

{{{
#!cpp
#include <algorithm>
#include ""boost/multi_array.hpp""

using namespace boost;
using namespace std;

int 
main () {
  // Create a 2D array that is 256 x 258
  typedef multi_array<float, 2> array_type;
  typedef multi_array_ref<float, 2> ref_type;
  typedef array_type::array_view<2>::type view_type;
  
  array<size_t, 3> paddedExt = {256,258};
  array_type A(paddedExt);
  
  /*Initialize the whole memory block with -1 */
  fill(A.origin(), A.origin()+A.num_elements(),-1.0);
  
  /*Fill the usefull part of the array by accessing data by column*/
  view_type B = A[indices[range()][range(0,256)]];
  for(view_type::iterator i=B.begin(); i!=B.end(); ++i)
    for(view_type::subarray<1>::type::iterator j=i->begin(); j!=i->end(); ++j)
      *j = 1.0;

  /*Access usefull data by line*/
  paddedExt[0]=258;
  paddedExt[1]=256;
  ref_type C(A.origin(), paddedExt, fortran_storage_order);
  view_type D = C[indices[range(0,256)][range()]];
  for(view_type::iterator i=D.begin(); i!=D.end(); ++i)
    for(view_type::subarray<1>::type::iterator j=i->begin(); j!=i->end(); ++j)
      output(*j);

return EXIT_SUCCESS;
}

}}}

This outputs a pretty high number of -1 ! More precisely, we have :
 * 256 values
 * 2 craps, 254 values
 * 2 values, 2 craps, 252 values
 * 4 values, 2 craps, 250 values
 * etc.
 * the last 2*256 good values are not output

It's like the views have lost their index_bases somewhere on the way.

I compiled and run this test under winXP, mingw32, gcc 3.4.5",Mathieu Leocmach <mathieu.leocmach@…>
3780,"Patch for disabling strict aliasing warnings, changing reinterpret_cast's",function,Boost Development Trunk,Boost 1.42.0,Patches,Douglas Gregor,new,2009-12-20T00:10:56Z,2009-12-20T00:10:56Z,"Because of the warnings reported by GCC the patch attached treats boost/function/function_base.hpp as a system header which makes GCC be a little less strict. Also, it removes the reliance on reinterpret_cast<> using static_cast<> in places where it can.",Dean Michael Berris
3779,Warning using less_equal points to bug,mpl,Boost 1.41.0,Boost 1.42.0,Bugs,Aleksey Gurtovoy,new,2009-12-19T07:18:17Z,2018-04-25T09:22:18Z,"Compiling the following metafunction using VC9 gives a warning which suggests an mpl bug:

#include <boost/mpl/less_equal.hpp>
#include <boost/mpl/long.hpp>
#include <boost/integer_traits.hpp>
namespace nmspace {
struct ResultTypeIntegerValues
  {
  typedef boost::mpl::long_<0L> lzero;
  typedef boost::mpl::long_<boost::integer_traits<long>::const_min> lmin;
  typedef boost::mpl::less_equal<lmin,lzero>::type type;
  }; 
}

with warning:

c:\utilities\boost\boost_1_40_0\boost\mpl\aux_\integral_wrapper.hpp(73) : warning C4307: '-' : integral constant overflow
1> c:\utilities\boost\boost_1_40_0\boost\mpl\aux_\preprocessed\plain\less_equal.hpp(60) : see reference to class template instantiation 'boost::mpl::long_<N>' being compiled
1>        with
1>        [
1>            N=-2147483648
1>        ]
1> c:\utilities\boost\boost_1_40_0\boost\mpl\aux_\preprocessed\plain\less_equal.hpp(70) : see reference to class template instantiation 'boost::mpl::less_equal_tag<T>' being compiled
1>        with
1>        [
1>            T=nmspace::ResultTypeIntegerValues::lmin
1>        ]
1>        c:\programming\programs\xxx\yyy.h(64) : see reference to class template instantiation 'boost::mpl::less_equal<N1,N2>' being compiled
1>        with
1>        [
1>            N1=nmspace::ResultTypeIntegerValues::lmin,
1>            N2=nmspace::ResultTypeIntegerValues::lzero
1>        ]

The same warning occurs using Boost 1.41. As Steve Watanabe pointed out the problem looks to be:

typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;

which overflows when one is already at the minimal value. It seems mpl has to take into account the minimal value when using prior and probably the maximal value when using next. In any case I see nothing wrong in the code and therefore I do not think an overflow condition should not be taking place.",Edward Diener <eld@…>
3776,libs/python/src/object/class.cpp treats string constant as char*,python USE GITHUB,Boost 1.41.0,Boost 1.42.0,Patches,Dave Abrahams,new,2009-12-18T00:29:59Z,2010-12-23T13:29:25Z,"gcc gives the following warnings:

libs/python/src/object/class.cpp: In function ‘int boost::python::property_init(PyObject*, PyObject*, PyObject*)’:
libs/python/src/object/class.cpp:79: warning: deprecated conversion from string constant to ‘char*’
libs/python/src/object/class.cpp:79: warning: deprecated conversion from string constant to ‘char*’
libs/python/src/object/class.cpp:79: warning: deprecated conversion from string constant to ‘char*’
libs/python/src/object/class.cpp:79: warning: deprecated conversion from string constant to ‘char*’
",anonymous
3769,darwin.jam: <cxxflags> should include framework paths,build,Boost 1.41.0,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-12-14T08:11:04Z,2012-03-08T16:32:59Z,"As -F is used to find include files, <cxxflags> should include -F. See #3767 to see how it is used to work with Qt.",Sohail Somani
3767,Support for Frameworks on OSX + Qt4,build,Boost 1.41.0,Boost 1.42.0,Feature Requests,Vladimir Prus,new,2009-12-14T04:00:46Z,2009-12-14T09:05:02Z,"When using Cocoa with Qt4.5 onwards, we need to use the Qt framework bundles rather than linking to the dynamic libraries. This is because a NIB file needs to be loaded to properly handle menus.

I think a new feature qt-cocoa (yes/no) would be enough from the user's point of view.

I can provide testing if needed. I tried to add it myself but failed miserably!
",Sohail Somani
3745,Remove deprecated class,tokenizer,Boost 1.41.0,Boost 1.42.0,Feature Requests,jsiek,new,2009-12-10T10:51:18Z,2009-12-10T10:51:18Z,"According to http://www.boost.org/doc/libs/1_41_0/libs/tokenizer/char_delimiters_separator.htm
char_delemiters_separator is a deprecated class and wasn't removed because of compatibility.
There is no reason to keep going with this compatibility when the char_separator offers the same functionality.
Currently it makes you to declare a new type definition for tokenizer<char_separator<char>> instead of using the one from boost.

Thank you.",anonymous
3740,Documentation error in the MPL Reference manual,mpl,Boost 1.41.0,Boost 1.42.0,Bugs,Joel Falcou,new,2009-12-09T00:46:12Z,2011-04-10T11:31:09Z,"In the MPL Reference Manual, for the miscellaneous data type void_, the synopsis shows a template class called ""is_void"". The name of the actual class in the boost/mpl/void.hpp header file is ""is_void_"". The documentation should be corrected.",Edward Diener <eld@…>
3738,adding support of other systems of time and converting from each one to other,date_time,Boost 1.41.0,Boost 1.42.0,Feature Requests,az_sw_dude,new,2009-12-08T23:30:57Z,2009-12-08T23:30:57Z,"For ex. I need GPS time system.
Short description is available at http://leapsecond.com/java/gpsclock.htm
In gps it is rather convenient to have converting function from gps time in form of weeks cycles days and seconds (see example at site above noted) to UTC time. 
More information can be obtained from various gps-related sites or you can ask me, I'll help according to my knowledge.
Leap second is noted in the library documentation, but really there is not any support. I guess that it is better to make function to set current leap seconds value since it is not predictable.
",serggzz@…
3733,Detect platform to choose the conventional option for help,program_options,Boost 1.41.0,,Feature Requests,Vladimir Prus,new,2009-12-08T15:09:01Z,2009-12-09T10:39:14Z,"on POSIX, the --help option is typically used for printing usage information.
on Windows, the /? is the typical option for that.

It would be cleaner if the user could check with some function whether the <help option> is set or not instead of explicitly checking for the ""help"" string 
{{{
   if (vm.count(""help""))
}}}

to decide when to print usage information.",hicham@…
3732,Detect platform to choose delimiter to use for reading options from command line,program_options,Boost 1.41.0,,Feature Requests,Vladimir Prus,new,2009-12-08T15:03:00Z,2009-12-09T11:24:07Z,"POSIX systems usually use - or -- as a ""delimiter"" when reading options from command lines. For e.g. the 'ls' program on a linux system:

{{{
  ls --help
  ....
  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
      --author               with -l, print the author of each file
  -b, --escape               print octal escapes for nongraphic 
 characters
      --block-size=SIZE      use SIZE-byte blocks
      --help                 print this
  ....
}}}


Windows usually uses the / character instead, for e.g. for dir:
dir /?: Typically, the '/' is the delimiter.
{{{
  ...
  /B          Uses bare format (no heading information or summary).
  ...
}}}

It would be useful to have the library recognize the platform on which it is begin compiled (or even better, the platform being targeted) and use the default for that platform for reading options from the command line.
",anonymous
3728,boost::ublas headers cause multiple warnings with -Wshadow,uBLAS,Boost 1.40.0,Boost 1.42.0,Patches,Gunter,new,2009-12-07T22:51:29Z,2010-03-27T06:01:34Z,The headers in boost::ublas often make use of local variables that shadow functions or other local variables.  Eliminating these warnings simply requires changing the variable names.,marc.schafer@…
3720,templated comparison operators,optional,Boost 1.41.0,Boost 1.42.0,Feature Requests,Fernando Cacciola,new,2009-12-05T03:30:44Z,2009-12-05T03:30:44Z,"template<class T> inline bool operator == ( optional<T> const& x, optional<T> const& y ) ;

and all other comparison operators should be replaced by

template<class T,class Y> bool operator==(optional<T> const &,optional<Y> const &);

so optionals of different but comparable types can be compared.
",anonymous
3716,Application crash when using Boost.Python in a plug-in DLL for that application,python USE GITHUB,Boost 1.41.0,Boost 1.42.0,Bugs,Dave Abrahams,new,2009-12-04T17:42:53Z,2010-04-20T17:57:02Z,"I am developping a DLL for a Win32 application that already host a Python interpreter (Python 2.5.x) which I extend using Boost.Python.

As far as Boost.Python is concerned, the sequence of operations (which I can't change) is :

1. App calls Py_Initialize

2. App loads my DLL

3. my DLL extend Python with a ""boost module"" (such as the ""Hello World"" example in the documentation

4. App notifies my DLL that it is about to be unloaded

5. App unloads my DLL

6. App calls Py_Finalize... and crash!

The application doesn't use Boost.Python, and doesn't even share the C run-time (i.e. different heaps). Whether I use static or dynamic linking of Boost.Python doesn't seem relevant in that case. Yes, I know, Boost.Python doc states that Py_Finalize should not be called. But in that case, it IS called after my DLL is unloaded and I can't do anything about it (and I'd like to use Boost.Python in such a scenario).

Cause : 

I manage to pinpoint where it fails from Py_Finalize. At that point, the 'Boost.Python.function' python object (defined in the function_type global variable in libs/python/src/object/function.cpp) is internally referenced by Python (by base class type among other things) and Python eventually tries to access it (at least change its ref count I guess). However, since the DLL is already unloaded, the memory that held the global variable is not mapped anymore.

Resolution :

Not being a Python expert, I haven't found a way to remove references to that 'Boost.Python.function' when my DLL is notified about being unloaded. I'd be glad to know if there is. However, it was fairly simple to get Python to allocate this object in its own heap, so that it lives as long as the interpreter. Attached is the patch file for that fix. I can't tell though how ""clean"" or not is copying a complete 'PyTypeObject' structure instance over a somewhat-already-initialized instance from PyObject_New()... but that seems to work.

Note that to avoid the crash, I also need to ""undef"" all function definitions from the boost module with PyObject_DelAttr() (else Py_Finalize accesses them but they're from a heap that was deallocated from memory when the DLL was unloaded). That does not however require any modification to Boost.Python.",Emmanuel Giasson <zirconia_@…>
3713,no straightforward way to convert fractional number of seconds to time duration,date_time,Boost 1.40.0,Boost 1.42.0,Feature Requests,az_sw_dude,new,2009-12-03T20:12:46Z,2010-12-08T20:48:58Z,"It should be possible to just build a time duration for given number of seconds for double or float parameters.  Current best way suggested on IRC is 'milliseconds (1000 * num_seconds)', but it feels like doing extra unneeded work.  Besides, this way I need to choose between milli/micro/nano weighing precision loss vs. potential overflow on 32-bit machines.  Boost, knowing how many ticks are in a second, could do this better.

What I'm actually trying to do is to call timed_wait() on a condition.  Currently, I have to

    condition.timed_wait (lock, milliseconds (1000 * num_seconds));

where as if double was implicitly convertible to time duration I could just

    condition.timed_wait (lock, num_seconds);

which is cleaner and more explicit.",Paul Pogonyshev <pogonyshev@…>
3710,error incorrect when calling boost::python function via functools.partial,python USE GITHUB,Boost 1.41.0,Boost 1.42.0,Bugs,troy d. straszheim,new,2009-12-03T18:54:50Z,2009-12-03T21:14:03Z,"Neal Becker wrote:
> Has anyone noticed that a function created with boost::python using
> args() to give keyword arguments doesn't seem to work with functools.partial keyword arguments (but does with positional args)?
>
> For example, I have this function:
>   class_<boost_uniform_real_wrap>
>     (""uniform_real"", ""Uniform float distribution"", bp::init<rng_t&,double,double>(
>     (bp::arg (""rng""),
>      bp::arg (""min""),
>      bp::arg (""max""))...
>
> Then:
> from functools import partial
> f = partial (uniform_real, rng=rng1) << using keyword doesn't work
> f (1,2)
> ArgumentError: Python argument types in
>     uniform_real.__init__(uniform_real, int, int)
> did not match C++ signature:
>     __init__(_object*, boost::random::mersenne_twister<unsigned int, 32, 624, 397, 31, 2567483615u, 11, 7, 2636928640u, 15, 4022730752u, 18, 3346425566u> {lvalue} rng, double min, double max)
>
> But this works:
> from functools import partial
> f = partial (uniform_real, rng1) << pos arg does work
>
> In [27]: f(1,2)
> Out[27]: uniform_real(1,2)
>

That doesn't work for pure python functions either:

>>> def f(x,y,z): return x*100 + y*10 + z
...
>>> from functools import partial as p
>>> p(f,x=1)(2,3)
Traceback (most recent call last):
  File ""<stdin>"", line 1, in <module>
TypeError: f() got multiple values for keyword argument 'x'
>>> p(f,x=1)(y=2,z=3)
123
>>> p(f,1)(2,3)
123

The error message is misleading for sure.  Boost.python is going through a list of overloads and trying them in order; if it runs out of overloads, it says nothing matched.",anonymous
3699,boost::asio support allocator parameter,asio,Boost 1.41.0,Boost 1.42.0,Feature Requests,chris_kohlhoff,new,2009-11-30T16:00:50Z,2009-11-30T16:00:50Z,"Hello

boost::asio should support different allocators.  If boost::asio supported different allocators, it would be very useful in writing performance code, and would be more C++ compliant.

Thanks.",anonymous
3690,regex depends on pthread library when boost is built with threading=single,build,Boost 1.40.0,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-11-28T06:19:27Z,2009-12-03T18:24:26Z,"regex depends on pthread library when boost is built with threading=single

static_mutex.cpp uses the functions pthread_mutex_unlock and pthread_mutex_lock. This creates a dependancy on pthreads which should not exist when compiled with threading=single.

This is, in particular, a problem when static linking on AIX.

It appears that BOOST_HAS_THREADS is still being set when threading=single is set on the bjam command line.",jdccdevel@…
3683,Build fails on MacOS,build,Boost 1.41.0,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-11-27T16:28:30Z,2010-03-06T08:37:37Z,"It looks like BB is using some option (-R) that's unknown to the default Mac toolset

{{{
$ bjam gcc --build-dir=/tmp/build --debug-configuration
notice: found boost-build.jam at /Users/dave/src/boost/boost-build.jam
notice: loading Boost.Build from /Users/dave/src/boost/tools/build/v2
notice: Searching /etc /Users/dave /Users/dave/src/boost/tools/build/v2 /usr/share/boost-build /Users/dave/src/boost/tools/build/v2/kernel /Users/dave/src/boost/tools/build/v2/util /Users/dave/src/boost/tools/build/v2/build /Users/dave/src/boost/tools/build/v2/tools /Users/dave/src/boost/tools/build/v2/contrib /Users/dave/src/boost/tools/build/v2/. for site-config configuration file site-config.jam .
notice: Loading site-config configuration file site-config.jam from /Users/dave/src/boost/tools/build/v2/site-config.jam .
notice: Searching /Users/dave /Users/dave/src/boost/tools/build/v2 /usr/share/boost-build /Users/dave/src/boost/tools/build/v2/kernel /Users/dave/src/boost/tools/build/v2/util /Users/dave/src/boost/tools/build/v2/build /Users/dave/src/boost/tools/build/v2/tools /Users/dave/src/boost/tools/build/v2/contrib /Users/dave/src/boost/tools/build/v2/. for user-config configuration file user-config.jam .
notice: Loading user-config configuration file user-config.jam from /Users/dave/user-config.jam .
docutils-dir=
tools-dir= /opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin
notice: will use 'g++' for gcc, condition <toolset>gcc-4.2
notice: using gcc libraries :: <toolset>gcc-4.2 :: /opt/local/bin /opt/local/lib /opt/local/lib32 /opt/local/lib64
notice: using gcc archiver :: <toolset>gcc-4.2 :: ar
warning: toolset gcc initialization: can not find tool windres
warning: initialized from /Users/dave/src/boost/tools/build/v2/build/project.jam:884
notice: using rc compiler :: <toolset>gcc-4.2 :: as
notice: will use 'g++' for gcc, condition <toolset>gcc-4.4
notice: using gcc libraries :: <toolset>gcc-4.4 :: /opt/local/bin /opt/local/lib /opt/local/lib32 /opt/local/lib64
notice: using gcc archiver :: <toolset>gcc-4.4 :: ar
warning: toolset gcc initialization: can not find tool windres
warning: initialized from /Users/dave/src/boost/tools/build/v2/build/project.jam:884
notice: using rc compiler :: <toolset>gcc-4.4 :: as
notice: iostreams: using prebuilt zlib
notice: iostreams: using prebuilt bzip2
notice: [python-cfg] Configuring python...
notice: [python-cfg] Checking interpreter command ""python""...
notice: [python-cfg] running command '""python"" -c ""from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))"" 2>&1'
notice: [python-cfg] ...requested configuration matched!
notice: [python-cfg] Details of this Python configuration:
notice: [python-cfg]   interpreter command: ""python""
notice: [python-cfg]   include path: ""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6""
notice: [python-cfg]   library path: ""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" ""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib""
notice: [python-cfg] framework directory is ""/opt/local/Library/Frameworks/Python.framework""
...patience...
...patience...
...found 2711 targets...
...updating 434 targets...
gcc.link /tmp/build/boost/bin.v2/libs/python/test/exec.test/gcc-4.2/debug/exec
ld: unknown option: -R
collect2: ld returned 1 exit status

    ""g++"" -L""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib"" -L""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config"" -Wl,-R -Wl,""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib"" -Wl,-R -Wl,""/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config""  -o ""/tmp/build/boost/bin.v2/libs/python/test/exec.test/gcc-4.2/debug/exec"" -Wl,--start-group ""/tmp/build/boost/bin.v2/libs/python/test/exec.test/gcc-4.2/debug/exec.o"" ""/tmp/build/boost/bin.v2/libs/python/build/gcc-4.2/debug/link-static/libboost_python.a""  -Wl,-Bstatic -lpython2.6 -Wl,-Bdynamic -lpython2.6 -Wl,--end-group -g 


...failed gcc.link /tmp/build/boost/bin.v2/libs/python/test/exec.test/gcc-4.2/debug/exec...
}}}
",Dave Abrahams
3675,Boost.Parameter passing function pointers,parameter,Boost 1.41.0,Boost 1.42.0,Bugs,Daniel Wallin,new,2009-11-26T16:10:03Z,2010-01-08T14:02:55Z,"When passing function pointers with Boost.Parameter on Boost 1.41 on MacPorts, there are errors.

Apparently, somewhere the function type gets a ""const"" and that breaks stuff.

That's the error message:

{{{
bash-3.2$ make CXXFLAGS=-I/opt/local/include test
g++ -I/opt/local/include    test.cc   -o test
/opt/local/include/boost/parameter/aux_/arg_list.hpp: In constructor 'boost::parameter::aux::arg_list<TaggedArg, Next>::arg_list(A0&, A1&, A2&, A3&, A4&) [with A0 = void ()(int)const, A1 = boost::parameter::void_, A2 = boost::parameter::void_, A3 = boost::parameter::void_, A4 = boost::parameter::void_, TaggedArg = boost::parameter::aux::tagged_argument<tag::par, void ()(int)>, Next = boost::parameter::aux::empty_arg_list]':
/opt/local/include/boost/parameter/parameters.hpp:876:   instantiated from 'typename boost::mpl::first<typename boost::parameter::aux::make_arg_list<boost::parameter::aux::item<PS0, A0, boost::parameter::void_>, typename boost::parameter::aux::make_deduced_items<PS0, boost::parameter::aux::make_deduced_items<PS1, boost::parameter::aux::make_deduced_items<PS2, boost::parameter::aux::make_deduced_items<PS3, boost::parameter::aux::make_deduced_items<PS4, boost::mpl::identity<boost::parameter::void_> > > > > >::type, boost::parameter::aux::tag_keyword_arg, mpl_::bool_<true> >::type>::type boost::parameter::parameters<PS0, PS1, PS2, PS3, PS4>::operator()(A0&) const [with A0 = void ()(int)const, PS0 = boost::parameter::required<tag::par, boost::mpl::always<mpl_::true_> >, PS1 = boost::parameter::void_, PS2 = boost::parameter::void_, PS3 = boost::parameter::void_, PS4 = boost::parameter::void_]'
test.cc:9:   instantiated from 'typename boost_param_result_14testfn<typename boost::parameter::aux::argument_pack<boost_param_parameters_14testfn, const ParameterArgumentType0, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::type>::type testfn(const ParameterArgumentType0&, typename boost::parameter::aux::match<boost_param_parameters_14testfn, ParameterArgumentType0, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::type) [with ParameterArgumentType0 = void ()(int)]'
test.cc:20:   instantiated from here
/opt/local/include/boost/parameter/aux_/arg_list.hpp:208: error: no matching function for call to 'boost::parameter::aux::tagged_argument<tag::par, void ()(int)>::tagged_argument(void (&)(int)const)'
/opt/local/include/boost/parameter/aux_/tagged_argument.hpp:37: note: candidates are: boost::parameter::aux::tagged_argument<KW, T>::tagged_argument(Arg&) [with Keyword = tag::par, Arg = void ()(int)]
/opt/local/include/boost/parameter/aux_/tagged_argument.hpp:32: note:                 boost::parameter::aux::tagged_argument<tag::par, void ()(int)>::tagged_argument(const boost::parameter::aux::tagged_argument<tag::par, void ()(int)>&)
make: *** [test] Error 1
bash-3.2$
}}}

The example compiles on Linux just fine. I will attach the example if I find out how to do it.

Please provide a workaround for the time until the fix for this hits the shelves.
",Aristid Breitkreuz <aristid.breitkreuz@…>
3673,boost python and weak_ptr from a shared_ptr argument,python USE GITHUB,Boost 1.41.0,Boost 1.43.0,Feature Requests,troy d. straszheim,assigned,2009-11-26T07:22:57Z,2013-06-11T18:44:38Z,"if you save a weak_ptr of a shared_ptr passed to you by python,
it expires almost immediately (see use of aliasing constructor in
shared_ptr_from_python.hpp).  See also mail from Jahn Fuchs on c++-sig list subject: boost python and weak_ptr from a shared_ptr argument",troy d. straszheim
3661,An exceptions puzzler:,python USE GITHUB,,,Tasks,troy d. straszheim,new,2009-11-23T19:09:35Z,2009-11-23T19:09:35Z,"Scenario:  From python I call wrapped c++ code.  This c++ code calls a python function via a boost::python::object and attempts to extract a value from what is returned.  This causes a throw, and the exception propagates back up to python.  It is possible for 'stuff' to get called in a function like this:

def foo():
   try:
       return
   except:
       stuff()

I don't have all the details handy about what is happening on the C++ side, this is a 'note to self' to investigate and document a best practice. ",troy d. straszheim
3653,converter collisions behave differently debug|release,python USE GITHUB,Boost 1.41.0,Boost 1.42.0,Bugs,Dave Abrahams,new,2009-11-20T21:02:41Z,2009-11-20T21:02:41Z,"from a thread on the c++-sig list titled ""dynamic compile and to-Python converter...""

The 'worst' and most common scenario is, precisely put:  more than one python extension module over which we have no control has wrapped type T.  We need to use them simultaneously.  For instance, here are two modules that both wrap vector<double>. With assertions enabled, this happens:

>>> import converter_collisions1_ext
>>> import converter_collisions2_ext
python: /home/troy/Projects/boost/src/libs/python/src/converter/registry.cpp:212: void boost::python::converter::registry::insert(PyObject* (*)(const void*), boost::python::type_info, const PyTypeObject* (*)()): Assertion `slot->m_to_python == 0' failed.
zsh: abort      python


delightfully, without assertions there is only a warning:


>>> import converter_collisions1_ext
>>> import converter_collisions2_ext
__main__:1: RuntimeWarning: to-Python converter for std::vector<double, std::allocator<double> > already registered; second conversion method ignored.


So one resolution is to remove the 'assert' that triggers this crash and leave the semantics as-is:  second and later converter registrations are warned about and ignored.   I'm simply suggesting we give the user more control over this behavior, because in a number of situations (it is up to the user to determine what they are) such control would be useful. ",troy d. straszheim
3650,Text Serialization crashes when istream close unexpectedly,serialization,Boost Development Trunk,Boost 1.42.0,Feature Requests,Robert Ramey,reopened,2009-11-20T13:40:52Z,2010-01-21T07:46:33Z,"I am using TextSerialization over a tcp::iostream.
I am retrieving object pointers through the serialization mecanisms.

boost::archive::text_iarchive ia(*_stream);
while(!_stream->eof())
{		
   boost::shared_ptr<Message> msg;
   ia >> msg;
   ...
}

If the socket stream close unexpectedly, then the program goes to fault.

It seems that moving the check for stream failure after the data reads in the basic_text_iprimitive.hpp file fixes the problem.

Thanks
",Doug Wallas
3627,boost::asio::async_read() cannot be used with null_buffers(),asio,Boost 1.40.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2009-11-16T09:55:23Z,2010-01-12T21:46:23Z,"An attempt to use async_read() with null_buffers() causes the handler to be invoked even when the underlying file descriptor is not yet available for reading.

The following test demonstrates the problem

void test_async_read()
{
    struct local
    {
        static void on_ready(boost::system::error_code const& error, int* invoked)
        {
            BOOST_CHECK(!error);
            *invoked = 1;
        }
    };

    int p[2];
    int const s = pipe(p);
    BOOST_CHECK(0 == s);

    boost::asio::io_service ios;
    boost::asio::posix::stream_descriptor sd(ios, p[0]);
    ios.reset();
    int invoked = 0;
    boost::asio::async_read(sd, boost::asio::null_buffers(), boost::bind(&local::on_ready, _1, &invoked));
    ios.poll_one();
    BOOST_CHECK(!invoked); // doesn't pass
}

This test doesn't pass on linux using either epoll or select multiplexing mechanism. This test also doesn't pass on freebsd using either kqueue or select multiplexing mechanism.",Dmitry Goncharov <dgoncharov@…>
3625,python detection randomly broken,build,Boost 1.40.0,To Be Determined,Bugs,Vladimir Prus,new,2009-11-15T15:49:49Z,2010-06-07T09:52:58Z,"We had at least two bug reports that python detection does not work on windows. In both cases, removing the
{{{
if [ version.check-jam-version 3 1 17 ] || ( [ os.name ] != NT )
}}}
block in python.jam:probe fixed that. One case was definitely mingw-built bjam, the other case, for all appearences, is MSVC. Log for the second case is attached.

",Vladimir Prus
3624,quote0 is missing,mpl,Boost 1.40.0,Boost 1.41.0,Feature Requests,Aleksey Gurtovoy,new,2009-11-15T15:23:01Z,2009-11-15T15:33:25Z,"quote0 is missing but maybe needed in case we want to turn a meta-function like :

struct foo
{
  typedef float type;
}

in a meta-function class.",Joel Falcou <joel.falcou@…>
3609,"select_reactor, result of select() isn't checked for error",asio,Boost 1.40.0,Boost 1.41.0,Bugs,chris_kohlhoff,new,2009-11-11T12:05:13Z,2011-01-24T09:39:58Z,"The problem is in select_reactor::run() (boost\asio\detail\select_reactor.hpp).

Related issue: [http://sourceforge.net/tracker/?func=detail&aid=2893275&group_id=122478&atid=694037]
",pavel@…
3607,no error reporting when parsing ptime with user-defined facets (with bugfix),date_time,Boost 1.40.0,Boost 1.41.0,Bugs,az_sw_dude,new,2009-11-11T10:15:32Z,2009-11-11T10:15:32Z,"When parsing date/time with facets mismatches doe not get reported (e.g. vial failbit)

reproduceable testcase:
parse ""20090101"" with facet ""%Y-%m-%dT%H:%M:%S%F"" yields correctly parsed ptime ""1-Oct-2009"" but should not.

the patch:
adds check for testing of seperator characters to match format and actual parsed string. 

Maybe the additional check should be applied to different locations in the source code, which I cannot judge at this point.",Thomas.Lemm@…
3587,"Hi,I find memory leaks in boost::python where the Py_Finalize() been called.",python USE GITHUB,Boost Development Trunk,Boost 1.41.0,Bugs,-,new,2009-11-04T05:58:01Z,2009-11-26T07:19:53Z,"when I wrote ""boost::python::detail::init_module(""xxxx"", &init_module_xxxx);"" in my code,the memory leak occurred when the application ended(I'm sure that I called Py_Finalize() already).",ahccom <4.u-ahc@…>
3572,mapped_file: reading/writing mapped memory can throw (structured) exceptions? (windows),iostreams,Boost 1.40.0,Boost 1.41.0,Bugs,Jonathan Turkanis,new,2009-10-28T11:48:58Z,2009-10-28T12:15:26Z,"msdn: ""Reading and Writing From a File View""
(http://msdn.microsoft.com/en-us/library/aa366801(VS.85).aspx)

""Reading from or writing to a file view can cause an EXCEPTION_IN_PAGE_ERROR exception. 
For example, accessing a mapped file that resides on a remote server can generate an exception 
if the connection to the server is lost. Exceptions can also occur because of a full disk, an
underlying device failure, or a memory allocation failure. When writing to a file view, exceptions 
can also occur because the file is shared and a different process has locked a byte range. To guard 
against exceptions due to input and output (I/O) errors, all attempts to access memory mapped files 
should be wrapped in structured exception handlers""

  DWORD dwLength;
  __try
  {
    dwLength = *((LPDWORD) lpMapAddress);
  }
  __except(GetExceptionCode()==EXCEPTION_IN_PAGE_ERROR ?
    EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
  {
    // Failed to read from the view.
  }

... so it should be mentioned in the documentation?
(windows specific)
",xurux1-mail@…
3564,bjam creates wrong library name when toolset choice is invalid,Building Boost,Boost 1.40.0,Boost 1.42.0,Bugs,Vladimir Prus,assigned,2009-10-26T15:25:57Z,2009-11-10T07:11:18Z,"Hi,

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

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

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

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

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

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

cheers
Chris",bielow@…
3547,Valgrind finds errors into compressed_matrix serialization,uBLAS,Boost 1.40.0,Boost 1.42.0,Bugs,Gunter,new,2009-10-23T13:14:36Z,2009-10-28T22:21:43Z,"I tried to write a compressed matrix to an archive and to re-read it from the archive.[[BR]]
Without valgrind, the program seems to run correctly, but, if run with valgrind, it outputs some errors.[[BR]]
[[BR]]
I attached the source code and the valgrind output.[[BR]]
I ran valgrind with this command:
{{{
valgrind ./compressed_mtx_ser test.arch >& valgrind.out
}}}

It seems that the serialization function tries to write not itialized bytes to file.",micdestefano@…
3540,[fix in git] use boost::aligned_storage rather than boost::python::aligned_storage,python USE GITHUB,Boost 1.40.0,Boost 1.41.0,Bugs,troy d. straszheim,new,2009-10-22T02:50:55Z,2009-10-22T04:04:19Z,"Looks like duplicated code that could be factored out.  Also the parameter library depends on boost/python/detail/referent_storage, see ticket #3490, this causes packaging problems.",troy d. straszheim
3531,initial_path is not thread-safe,filesystem,Boost 1.40.0,Boost 1.41.0,Bugs,Beman Dawes,reopened,2009-10-19T09:10:50Z,2016-06-27T13:36:20Z,"The initial_path template function uses function-local static variable and thus is not thread-safe.

The documentation states the recommendadion to call initial_path from the beginning of the main function. However, following it is not sufficient because:

1. If the application consists of several modules (dll or so), on many architectures each module will contain its own copy of the static variable defined in initial_path. Each copy will be initialized as needed, when initial_path is called from within the corresponding module.

2. The threads may already be running when initial_path is called. This may be true regardless of whether initial_path is called from main or some another place in a dll.

What makes the problem worse is that there are two such functions, actually: initial_path< path >() and initial_path< wpath >(). Each of them will have the described problem.
",Andrey Semashev
3530,MPL components missing ADL barrier,mpl,Boost 1.40.0,Boost 1.41.0,Bugs,Aleksey Gurtovoy,new,2009-10-17T09:40:54Z,2009-10-17T09:40:54Z,"mpl::size (among others) are not ADL protected which leads to ambiguity in soem scenario where MPL components are used as tempalte parameters and a size() function is defined. 

As there is already a ADL barrier system usable in MPL, the fix should be only to use it around those components.",Joel Falcou <joel.falcou@…>
3519,It should be possible to use consts as external placeholder variables.,xpressive,Boost 1.40.0,To Be Determined,Feature Requests,Eric Niebler,assigned,2009-10-12T15:26:05Z,2010-10-06T18:18:53Z,"The right-and-side of placeholder let-expressions are not declared as const, so common use-cases like:

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


or:

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


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


{{{
placeholder<int const> _i;
}}}

(suggested by Eric Niebler)
",ami.ganguli@…
3510,Introduce new diag function for creating diagonal matrices and for returning the diagonal of a matrix,uBLAS,Boost 1.40.0,Boost 1.41.0,Feature Requests,Gunter,new,2009-10-05T08:37:10Z,2009-10-05T08:37:10Z,"Introduce a new '''diag''' free function in the spirit of the MATLAB's ''diag'' function and Mathematica's ''DiagonalMatrix function''.

Basically it allows both the creation of a ''generalized'' diagonal matrix and the creation of a ''diagonal'' view of an existing matrix.

A ''generalized'' k-th diagonal matrix is a special kind of matrix which has all elements set to zero but the ones on its k-th diagonal. The integer k is the offset from the main diagonal, that is:

* k = 0: the elements on the main diagonal can be different from zero.

* k > 0: only the elements on the k-th upper diagonal can be different from zero.

* k < 0: only the elements on the k-th lower diagonal can be different from zero.

A generalized diagonal matrix can be a rectangular matrix.



Here below is a list of the requested cases:

* Create a square diagonal matrix M with vector V
being the k-th diagonal
  {{{M = diag(v,k)}}}

* Like the above, but M has layout l (e.g., column major)
  {{{M = diag(v,k,l)}}}

* Create a rectangular diagonal matrix M of size mXn with vector V being the k-th diagonal
  {{{M = diag(v,m,n,k)}}}


* Like the above, but M has layout l (e.g., column major)
  {{{M = diag(v,m,n,k,l)}}}

* Create a diagonal view of the k-th diagonal of matrix M
  {{{v = diag(M,k)}}}
",marco.guazzone@…
3508,bjam output in colours,build,Boost Development Trunk,Boost 1.47.0,Feature Requests,Vladimir Prus,new,2009-10-04T17:25:50Z,2020-04-21T00:33:39Z,"I think it would be very useful if bjam prints output to stdout in colours to help to distinguish at least information messages, warnings and errors.

CMake does provide coloured output out of the box. For GNU make and GCC there are http://bre.klaki.net/programs/colormake/ colormake] and [http://schlueters.de/colorgcc.html colorgcc].

All these tools help programmers to avoid ''nystagmus'' issues while analysing compiler output :-)

As a proof of concept, I attached [http://mateusz.loskot.net/?p=465 colorbb'' script a rough port of the colormake] to work with bjam + GCC toolset.",mloskot <mateusz@…>
3504,deadline_timer (based on UTC time) is not suitable for communication timeouts,asio,Boost 1.41.0,To Be Determined,Feature Requests,chris_kohlhoff,reopened,2009-10-02T07:36:59Z,2016-12-27T13:39:31Z,"If you use the deadline_timer to make a polling every 10th second, it will be heavely affected if someone adjust the system clock with date command, or if the time is adjusted automaticly by NTP.

Uses as this should use a timer that cannot make jumps like that.

I solved this by making a new time_traits called monotone_time. It uses GetTickCount() for windows and clock_gettime(CLOCK_MONOTONIC, ...) for linux. See attachment.

To use it your timer must be a monotone_timer instead of a deadline_timer. You can use both types of timers in you application.

I hope this can be a part of a future release of boost::asio",Bjarne Laursen <bla@…>
3490,Boost.Parameter should not depend on Boost.Python,parameter,Boost 1.40.0,Boost 1.41.0,Bugs,troy d. straszheim,new,2009-09-27T02:17:31Z,2010-01-19T20:08:36Z,"The header boost/parameter/aux_/maybe.hpp includes <boost/python/detail/referent_storage.hpp>.  This introduces a dependency for Boost.Parameter on Boost.Python.  Worse: it depends on a '''detail''' of Boost.Python.

Vendors such as Debian often split out Boost.Python from the mainstream, and this causes problems for us; c.f. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548503
",smr@…
3488,A better way to make python functions that take arbitrary number of args than raw_function,python USE GITHUB,Boost 1.40.0,To Be Determined,Feature Requests,Dave Abrahams,new,2009-09-25T20:48:31Z,2009-09-25T21:31:27Z,"raw_function can handle only C++ functions that take two args (tuple, dict) and seems to cause static assert if a keyword-expression is passed to def thus causing a lot of manual code if one wants to make it take named arguments or default arguments.

It would be nice if there was a way to make such functions closer to defs in python itself, something like this:


{{{
void foo(int arg1, int arg2, tuple args, dict kw);

def(""foo"", foo, (arg(""arg1"") = 1, arg(""arg2"") = 2, arg(""*args""), arg(""**kw"")) // that would pass extra positional args in foo's third arg and extra keyword args to foo's fourth arg
}}}
",loonycyborg
3484,[Test] documentation and thread safety,test,Boost 1.39.0,Boost 1.41.0,Bugs,Gennadiy Rozental,new,2009-09-23T11:09:27Z,2009-09-27T02:15:38Z,"Today I spend half a day to reveal that Boost.Test is not thread safe :)

Please point it explicitly in documentation.

(When MT, BOOST_ERROR, for example, cause unknown exception but only after thread exit, and only 1 time for 10 runs. This makes bugs extremely difficult to locate, and since most Boost libraries are thread-safe, Boost.Test is the last thing to check).",bstarostin@…
3483,non-null requirement in ptr_vector::transfer,ptr_container,Boost 1.40.0,,Feature Requests,Thorsten Ottosen,assigned,2009-09-23T09:40:17Z,2011-03-31T20:52:16Z,"[http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_vector.html#c-array-support]

is it possible to remove non-null requirement for ''from'' argument in ptr_vector::transfer method?",Igor Pavlov <arabesc@…>
3482,ptr_sequence_adapter documentation erratum,ptr_container,Boost 1.40.0,,Bugs,Thorsten Ottosen,new,2009-09-23T09:14:08Z,2009-09-23T09:14:08Z,"[http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_sequence_adapter.html]

Semantics: construct/copy/destroy
 * template< class !InputIterator > void assign( !InputIterator first, !InputIterator last );
  * Requirements: '''('''first,last''']''' is a valid range

there is should be '''['''first, last''')''' half-open interval",Igor Pavlov <arabesc@…>
3478,Min cut interface for BGL,graph,Boost 1.40.0,To Be Determined,Feature Requests,Andrew Sutton,assigned,2009-09-22T14:00:56Z,2010-12-08T19:44:44Z,"1) The max flow can be obtained with: (any of the max_flow algorithms, kolmogorov is just used as an example)

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

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

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

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

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

5) VERY simple examples (actually constructing a graph (not reading it from file) with < 10 nodes) should be provided to demonstrate all of these cases.",David Doria <daviddoria@…>
3457,introduce move semantics to container types,uBLAS,Boost 1.40.0,Boost 1.41.0,Feature Requests,Gunter,new,2009-09-16T21:54:30Z,2009-10-06T22:35:55Z,"I am writing many routines where I would strongly prefer: {{{matrix<double> f(const matrix<double>& in)}}}
to 
{{{void f(const matrix<double>& in, matrix<double>& out )}}}

There has been a lot of discussion about this from the C++ groups:

 * The move library to support this in C++03
 * http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/

Also, I see that this is native to MTL:
http://www.osl.iu.edu/research/mtl/mtl4/doc/matrix_assignment.html#move_semantics",Gunter
3450,[fix in git] Bug into boost::python::stl_input_iterator,python USE GITHUB,Boost 1.40.0,Boost 1.41.0,Bugs,troy d. straszheim,assigned,2009-09-15T07:53:33Z,2009-09-21T07:59:44Z,"I noticed that if you try to traverse more than once the range (begin,end) obtained with the `stl_input_iterator`, you don't get the expected results.[[BR]]
[[BR]]
Please, look at the attached code (rangemodule.cpp) and at the usage from the python console (python_console.txt).[[BR]]
[[BR]]
The problem is given by the call to the `std::distance` function.[[BR]]
If you build with `-DWORK_AROUND` the problem disappears, but I need to call `std::distance`, because it is the original class that calls it (and I prefer not to modify it simply for building a python extension).",micdestefano@…
3447,After destruction binary_iarchive seeks to the end of file,serialization,Boost 1.39.0,,Bugs,Robert Ramey,new,2009-09-14T09:30:30Z,2009-09-14T19:27:35Z,"After destruction binary_iarchive seeks to the end of file. This is occured because boost::archive::basic_binary_iprimitive (the ancestor of binary_iarchive) calls std::basic_streambuf::sync in destructor. Calling 'sync' on a file streambuf seeks to the end of file.

This is bad, because it lead to skipping of unread input data!

I think calling 'sync' is a bad idea (and this call should be removed), but if it is necessary, then the documentation must clearly note that using a file streambuf with binary_iarchive skips to the end of the file.

----
Example:

{{{
std::ifstream is( ARCHIVE_FILE_NAME, std::ios::binary );

int i;
    
{
    boost::archive::binary_iarchive ar( is, boost::archive::no_header );
        
    ar >> i;
        
    std::cout << ""Pos after read: "" << is.tellg() << std::endl;
}

std::cout << ""Pos after dtor: "" << is.tellg() << std::endl;
}}}

Output:
{{{
Pos after read: 4
Pos after dtor: 11
}}}
(sizeof(int) is 4, archive file length is 11)",Andrey Upadyshev <oliora@…>
3446,[boost] [fusion] transform does not return a mutable view,fusion,Boost 1.40.0,Boost 1.41.0,Feature Requests,Joel de Guzman,new,2009-09-14T05:03:53Z,2009-09-21T18:40:45Z,"Based on the documentation (and my own experience), it doesn't appear that transform will return a mutable transform_view, since transform receives its sequence argument always by const reference.  Is this intentional, or an oversight?  It seems like there's no loss in providing 2 overloads of transform, one accepting a const reference and one accepting a non-const reference.",jhellrung@…
3443,improve documentation,uBLAS,Boost Development Trunk,To Be Determined,Tasks,David Bellot,new,2009-09-12T22:54:12Z,2010-07-26T12:41:22Z,this task was created to track all documentation updates that do not belong to a specific bug or feature ticket.,Gunter
3430,Build boost.regex shared-link 1.40 under mingw 3.4,build,Boost 1.40.0,Boost 1.41.0,Bugs,Vladimir Prus,new,2009-09-09T22:24:14Z,2009-11-16T17:08:07Z,"I try build boost.regex under mingw 3.4 (include in Qt SDK)
I add mingw to PATH enviroment variable, than run:
bootstrap.bat
bjam.exe --build_type=complete --toolset=gcc --with-regex --with-program_options variant=release link=shared runtime-link=shared stage 

bjam build static lib version of boost.regex.
It i use msvc2008 console tool, and use toolset ""msvc-9.0"" shared version build correct.

It's like on bug. 
Thank you!",Oleg Tsarev <zabivator@…>
3423,Diagnostic of errors.,program_options,Boost 1.40.0,Boost 1.42.0,Feature Requests,Sascha Ochsenknecht,reopened,2009-09-08T11:22:54Z,2010-05-11T14:21:39Z,"1. Some classes of errors (for example ""unknown_option"")  are not remembered parameters transferred in the constructor. It does not allow to generate non standard diagnostics (for example not in English).
2. In a class ""multiple_occurrences"" there is no diagnostics for what parameter the error is found out.
",Alex Bukreev <bucreev@…>
3408,gamma distribution's quantile performance,math,Boost 1.40.0,Boost 1.41.0,Tasks,John Maddock,assigned,2009-09-06T18:50:32Z,2009-10-06T17:13:28Z,"Hi there, I have created a test which times the performance of
boost::math::quantile( ... ) when using a gamma distribution. I ran it against source code we use here at work, for ages. It can be found here:

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

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

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

Intel 11.1:
boost: 21.4sec
att_bell: 11.2sec

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

Here the code:

#include <dcdflib.h>

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

#include <boost/timer.hpp>

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

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

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

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

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

inline
double get_rand()
{
   return static_cast< double >( std::rand() )
        / static_cast< double >( RAND_MAX    );
}

inline
void boost_( boost::math::gamma_distribution<>& d, double q )
{
   double value = boost::math::quantile( d, q );
}

inline
void att_bell( double alpha, double beta, double q )
{
       double q_Minus1 = 1 - q;
       double value = 0.0;
       double bound = 0.0;

       int which  = 2;
       int status = 0;

   cdfgam( &which
         , &q
         , &q_Minus1
         , &value
         , &alpha
         , &beta
         , &status
         , &bound
         );
}

int main()
{
   // boost
   {
       std::srand( 0 );

       boost::timer timer;
       for( std::size_t y = 0; y < max_year; ++y )
       {
           if(( y % 100000 ) == 0 )
               std::cout << y << std::endl;

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

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

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

       std::cout << ""Boost - Time elapsed: "" << timer.elapsed() << ""
sec"" << std::endl;
   }

   // att bell
   {
       std::srand( 0 );

       boost::timer timer;
       for( std::size_t y = 0; y < max_year; ++y )
       {
           if(( y % 100000 ) == 0 )
               std::cout << y << std::endl;

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

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

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

       std::cout << ""ATT Bell - Time elapsed: "" << timer.elapsed() <<
"" sec"" << std::endl;
   }

   return 0;
}
",chhenning@…
3406,False strong guarantee in documentation,ptr_container,Boost 1.40.0,Boost 1.41.0,Bugs,Thorsten Ottosen,new,2009-09-05T17:04:26Z,2009-09-05T17:04:26Z,"For many functions inserting pointers into a pointer container, the
documentation says that they provide strong exception-safety
guarantee while they are actually not. Instead, they perform delete
on the passed pointer if an exception is thrown.

I propose the wording like this; ""When an exception is thrown,
nothing happens except performing delete x.""

Note that replacing it with ""basic guarantee"" is over relaxing.
One should be able to assume the contents of the container are
unchanged when an exception is thrown.

This was first posted on the mailing list.
http://lists.boost.org/Archives/boost/2009/08/155078.php
",Kazutoshi Satoda <k_satoda@…>
3398,boost::posix_time::time_duration accesser for obtaining milliseconds,date_time,Boost 1.40.0,Boost 1.41.0,Feature Requests,az_sw_dude,new,2009-09-03T22:08:17Z,2010-12-08T06:37:34Z,"Hey guys:

It would be really nice to get the milliseconds of time in boost::posix_time::time_duration. There is only an option to get the total_milliseconds(), which gives the result of the total milliseconds that have passed in that day. Although I can take this and compute hours, minutes, seconds and milliseconds from it, it is a bit of a pain in the ass to do it that way.

It would be much nicer if I could just call a function to give me the millisecond remainder from seconds. You have accessers like this for hours, minutes, and seconds, so why not milliseconds?",Raymond Chandler III <raymond.chandler.ctr@…>
3396,add a sparse_view class that wraps pre-allocated data into a matrix expression,uBLAS,Boost 1.40.0,Boost 1.42.0,Feature Requests,Gunter,assigned,2009-09-03T20:16:06Z,2009-10-06T23:13:48Z,"Provide a way to use ublas with pre-allocated data. Implement a matrix view of a CRS matrix as proof of concept. Details:

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

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

Further tasks:

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

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

* add necessary tests



",Gunter
3383,no ptr_list::splice,ptr_container,Boost 1.40.0,Boost 1.41.0,Bugs,Thorsten Ottosen,new,2009-09-01T14:20:10Z,2009-09-04T07:18:50Z,"ptr_list doesn't offer an equivalent to std::list::splice.
it does offer ptr_sequence_adapter::transfer(), but that doesn't give any guarantee of constant time complexity, and as far as I can see transfering all the contents of a ptr_list into another is in fact implemented in linear complexity.
",anonymous
3366,ICU shared lib not found on fedora x86_64,Building Boost,Boost Release Branch,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-08-26T15:30:24Z,2010-06-07T14:14:48Z,"On linux fedora F11 x86_64 I get this warning:

 bjam -sICU_PATH=/usr -sEXPAT_INCLUDE=/usr -sEXPAT_LIBPATH=/usr/lib64 --
layout=tagged threading=single,multi stage 

warning: ICU shared common library not found in path.
hint: If the regex library fails to link then try again
with the environment variable ICU_LINK set to contain
the linker options required to link to ICU.
Defaulting to look for libicuuc ...
LINUX
warning: ICU shared data library not found in path.
hint: If the regex library fails to link then try again
with the environment variable ICU_LINK set to contain
the linker options required to link to ICU.

1. bjam should know to look in /usr/lib64 for all system libs
2. Is this just a harmless warning, or will the build be incorrect?",Neal Becker <ndbecker2@…>
3363,linking 2 files compiled with different NDEBUG causes segfault,date_time,Boost 1.39.0,Boost 1.40.0,Bugs,az_sw_dude,new,2009-08-25T05:00:32Z,2011-02-21T04:29:58Z,"Linking y1.o and y2.o compiled as below causes the resulting executable to segfault and show valgrind errors.
x1.o defines NDEBUG before including a boost header, x2.o doesn't.
If both define NDEBUG, or both don't then linking them produces an executable that runs, and shows no valgrind errors.

This is y1.cpp:
#define NDEBUG 1
#include <boost/date_time/posix_time/posix_time.hpp>
#include <iostream>

void foobar() {
    boost::posix_time::time_duration td(0, 0, 1, 0);
    std::stringstream ss;
    ss << td;
}
void bar(void);
int main()
{
    bar();
    return 0;
}

This is y2.cpp:
#include <boost/date_time/posix_time/posix_time.hpp>
void bar(void) {
    std::cerr<<boost::posix_time::second_clock::local_time()<<' ';
}

Fails:
$ g++ y1.cpp y2.cpp && ./a.out
Segmentation fault

Reported by Debian user; see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537680 for valgrind output.

I have reproduced this behaviour on today's trunk, so I expect it is still a problem in 1.39.0 and upcoming 1.40.0.


",smr@…
3362,PySte crashes with TypeError,python USE GITHUB,Boost 1.39.0,Boost 1.40.0,Patches,Dave Abrahams,new,2009-08-24T21:00:49Z,2014-02-18T14:13:48Z,"Certain C++ declarations can create unnamed classes, which cause GCCXML output to omit the name field. This in turn will trigger the following nasty exception (only the last part of the long traceback is shown):

{{{
  File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 350, in ParsePointerType
    type = self.GetType(element.get('type'))
  File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 126, in GetType
    decl = self.GetDecl(id)
  File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 108, in GetDecl
    self.ParseElement(id, elem)
  File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 70, in ParseElement
    func(id, element)
  File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 319, in ParseStruct
    self.ParseClass(id, element)
  File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 306, in ParseClass
    self.AddDecl(class_)
  File ""C:\Python26\lib\site-packages\Pyste\GCCXMLParser.py"", line 57, in AddDecl
    if decl.FullName() in self._names:
  File ""C:\Python26\lib\site-packages\Pyste\declarations.py"", line 49, in FullName
    return namespace + self.name
TypeError: cannot concatenate 'str' and 'NoneType' objects
}}}

The fix is quite simple: change
{{{
    def ParseClass(self, id, element):
        name = element.get('name')
}}}
to
{{{
    def ParseClass(self, id, element):
        name = element.get('name', id)
}}}
on line 290 of GCCXMLParser.py.",nneonneo@…
3353,warning C4244: Py_ssize_t to unsigned int,python USE GITHUB,Boost 1.39.0,Boost 1.40.0,Bugs,Dave Abrahams,new,2009-08-18T20:01:58Z,2017-09-03T20:44:27Z,"I am seeing a compiler warning regarding an unsafe type conversion:


{{{
1>c:\program files\boost\boost_1_39\boost\python\detail\caller.hpp(55) : warning C4244: 'return' : conversion from 'Py_ssize_t' to 'unsigned int', possible loss of data
}}}


Visual Studio 2005

Note that this may be a known issue or regression, as it was discussed 2 years ago here:
http://lists.boost.org/Archives/boost/2007/04/120377.php
",davidm@…
3343,[Program options] add option to place description on the next line in output,program_options,Boost 1.39.0,To Be Determined,Feature Requests,Vladimir Prus,new,2009-08-14T10:54:53Z,2015-03-30T12:56:24Z,"If some param has long length and default value, then description of such param (and other params) has ugly output - very narrow text column.[[BR]]
If it is possible then please deal with this issue.[[BR]][[BR]]
For example, description of some option could be placed on the second line after its-name-and-default-value line.",rshmelev@…
3342,vector_c should use maximum integral constant type,mpl,Boost 1.39.0,Boost 1.40.0,Bugs,Aleksey Gurtovoy,new,2009-08-14T06:21:21Z,2009-08-14T06:21:21Z,"It looks like currently long is built in, which leads to problems on 32 bit architectures with sizeofs int = long < int64_t.

How it's defined currently:
{{{
#!cpp
template<
      typename T, long C0 = LONG_MAX, long C1 = LONG_MAX, long C2 = LONG_MAX, ...
    >
struct vector_c;
}}}


I believe the maximum integral type (e.g. int64_t) should be used instead of long.

Example that shows the problem:
{{{
#!cpp
  const int64_t max_int         = integer_traits<int>::const_max;
  const int64_t max_int_plus_1  = max_int + 1;
  
  BOOST_MPL_ASSERT(( equal<           vector_c< int64_t, 1 >
                          , vector< integral_c< int64_t, 1 > >
                          > ));

  BOOST_MPL_ASSERT(( equal<           vector_c< int64_t, max_int >
                          , vector< integral_c< int64_t, max_int > >
                          > ));

  BOOST_MPL_ASSERT(( equal<           vector_c< int64_t, max_int_plus_1 >
                          , vector< integral_c< int64_t, max_int_plus_1 > >
                          > ));
}}}
The first assert passes, while the second and third fail with the following
error messages (removed repetition of 2147483647l for readability):
{{{
test.h:149: error: ************mpl::equal<mpl::vector_c<int64_t, 2147483647l,
2147483647l, ...>, mpl::vector<mpl_::integral_c<int64_t, 2147483647>>,
is_same<true> >::************'
test.h:153: error: ************mpl::equal<mpl::vector_c<int64_t,
-0x00000000080000000l, 2147483647l, ...>, mpl::vector<mpl_::integral_c<int64_t,
2147483648ll>>, is_same<true> >::************'
}}}",Maxim Yanchenko <Maxim.Yanchenko@…>
3340,boost.python.numeric docs out-of-date,python USE GITHUB,Boost 1.39.0,Boost 1.40.0,Bugs,Dave Abrahams,new,2009-08-13T16:21:07Z,2009-08-13T16:21:07Z,"Reading http://www.boost.org/doc/libs/1_39_0/libs/python/doc/v2/numeric.html#array-spec I run into a number of invalid / outdated URLs. Notably, the above page starts with

""Provides access to the array types of Numerical Python's Numeric and NumArray modules"", but in one of the followup URLs I find

""numarray is being phased out and replaced by numpy"".

Thus my questions:

Other than a fix to the above docs, does boost.python need any adjustments to work with numpy ? In fact, what is the relationship between the above (old) modules and numpy ? Reading some follow-up docs it appears as if the numpy array types grew out of Numeric / NumArray.
Sorry for those somewhat tangential questions. I believe at least some clarification on the boost.python documentation as to what exact array types it is able to bind to would be very helpful.
",Stefan Seefeld
3336,utc offset calculated wrong,date_time,Boost 1.54.0,Boost 1.57.0,Bugs,az_sw_dude,new,2009-08-11T16:13:24Z,2014-01-19T11:31:50Z,"Boost seems to invert the posix time zone specs or even worse to calculate them completely wrong:

[http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html]

states:

""If preceded by a '-', the timezone shall be east of the Prime Meridian; otherwise, it shall be west (which may be indicated by an optional preceding '+' ).""

Using the following lines in a c++ program:

{{{
  time_zone_ptr myzone(new posix_time_zone(string(""CET-1CEST,M3.5.0,M10.5.0/3""))); // e.g. Europe/Berlin
  cout << ""Posix time string: "" << myzone->to_posix_string() << endl;
  local_date_time mylocaltime(date(2009,8,11), time_duration(17,0,0), myzone, true);
  cout << ""Wall clock: "" << mylocaltime.local_time() << endl;
  cout << ""Time in UTC: "" << mylocaltime.utc_time() << endl;
}}}

gives following output: [[BR]]
Posix time string: CET-01CEST+01,M3.5.0/02:00,M10.5.0/03:00 [[BR]]
Wall clock: 2009-Aug-11 17:00:00 [[BR]]
Time in UTC: 2009-Aug-11 17:00:00 [[BR]]

The system I used: Debian GNU/Linux squeeze/sid [[BR]]
uname -a[[BR]]
Linux fafner 2.6.28.7 #1 SMP Mon Mar 16 17:39:15 CET 2009 i686 GNU/Linux

output from date:[[BR]]
date -d ""2009-8-11 17:00 CEST ""[[BR]]
Di 11. Aug 17:00:00 CEST 2009[[BR]]
date -d ""2009-8-11 17:00 CEST "" -u[[BR]]
Di 11. Aug 15:00:00 UTC 2009

Libraries (debian):
libboost-date-time1.38.0
libboost-date-time1.38-dev
libboost-date-time-dev

The time zone spec ist taken from /usr/share/zoneinfo/CET on my system.",silvan@…
3318,boost/python/detail/caller.hpp doesn't  compile (no member named 'get_pytype'),python USE GITHUB,Boost 1.39.0,Boost 1.40.0,Bugs,troy d. straszheim,new,2009-08-06T10:57:51Z,2011-09-08T20:09:35Z,"When compiling vegastrike-0.5.0 against boost 1.39.0 (./configure --with-boost=system to use the system boost instead of internal copy), the build breaks on errors in the boost/python/detail/caller.hpp header:

{{{
In file included from /usr/include/boost/python/object/function_handle.hpp:9,                                                                                                                                  
                 from /usr/include/boost/python/converter/arg_to_python.hpp:20,                                                                                                                                
                 from /usr/include/boost/python/call.hpp:16,                                                                                                                                                   
                 from /usr/include/boost/python/object_core.hpp:13,                                                                                                                                            
                 from /usr/include/boost/python/object.hpp:10,                                                                                                                                                 
                 from src/python/python_class.h:24,                                                                                                                                                            
                 from src/python/briefing_wrapper.cpp:4:                                                                                                                                                       
/usr/include/boost/python/detail/caller.hpp: In static member function 'static const PyTypeObject* boost::python::detail::converter_target_type<ResultConverter>::get_pytype() [with ResultConverter = boost::python::to_python_value<const Vector&>]':                                                                                                                                                                       
/usr/include/boost/python/detail/caller.hpp:242:   instantiated from 'static boost::python::detail::py_func_sig_info boost::python::detail::caller_arity<1u>::impl<F, Policies, Sig>::signature() [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<Vector, int>]'                                                                                                        
/usr/include/boost/python/object/py_function.hpp:48:   instantiated from 'boost::python::detail::py_func_sig_info boost::python::objects::caller_py_function_impl<Caller>::signature() const [with Caller = boost::python::detail::caller<Vector (*)(int), boost::python::default_call_policies, boost::mpl::vector2<Vector, int> >]'                                                                                         
src/python/briefing_wrapper.cpp:59:   instantiated from here                                                                                                                                                   
/usr/include/boost/python/detail/caller.hpp:102: error: 'struct boost::python::detail::caller_arity<1u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = Vector (*)(int), Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2<Vector, int>]::result_converter' has no member named 'get_pytype'                                                                                     
make[1]: *** [src/python/briefing_wrapper.o] Error 1                                                                                                                                                           
}}}

Labelling this as regression since vegastrike is known to compile with boost 1.36.0.

I'm using GCC 4.4.0, glibc 2.10.1, python 2.6.1 on Exherbo Linux
",Ingmar Vanhassel <ingmar@…>
3313,Excessive line length in vector200.hpp,typeof,Boost 1.38.0,,Bugs,Peder Holt,new,2009-08-03T18:50:50Z,2009-08-03T18:50:50Z,"The file vector200.hpp, which appears to be an auto-generated file, does not import into the ClearCase configuration management tool properly due to excessive line length.  This was observed when using ClearCase on Windows for configuration management of a software project using Boost.  ClearCase has a documented per line import maximum of 8000 characters for text files (refer to http://www.ibm.com/developerworks/rational/library/4704.html).  In general files with lines exceeding 100+ characters are undesirable for a number of reasons.  Since this file appears to be auto-generated, it should be generated such that the lines are much shorter so the file is more compatible with CM tools and other editors that may have troubles with the line length.",Lisa Preston <lisa.preston@…>
3301,Problem building boost with ICU (since version 1.39.0),Building Boost,Boost 1.39.0,To Be Determined,Bugs,Vladimir Prus,new,2009-07-30T05:42:27Z,2010-06-06T15:29:12Z,"I have tried build boost 1.39.0 with MSVS 8.0, including regex library and with ICU support. 

The build string was
{{{
bjam -j2 -sHAVE_ICU=1 --without-python --with-regex --build-dir=""D:\Temp\BoostBuild"" --toolset=msvc-8.0 --build-type=complete address-model=32 stage
}}}
(version 1.38.0 was allright with this build string).

This raised an error:
{{{
error: link=shared together with runtime-link=static is not allowed
error: such property combination is either impossible 
error: or too dangerious to be of any use
}}}

Then I tried to narrow the building settings and use static linking only:
{{{
bjam --toolset=msvc-8.0 --builddir=""D:\Temp\BoostBuild"" address-model=32 link=static runtime-link=static threading=multi stage debug release --with-regex -sHAVE_ICU=1
}}}

This also did raise the same error, despite shared linking wasn't demanded explicitly.

The problem comes when trying to build boost with ICU. Without ICU it seems beeing ok, but I need unicode support in regex.



",Yana A. Kireyonok <death.iron.bug@…>
3265,parse vectors,program_options,Boost 1.39.0,Boost 1.40.0,Feature Requests,Vladimir Prus,new,2009-07-15T03:09:11Z,2012-12-27T10:21:09Z,"As discussed on the boost users mailinglist, when a user specified a vector as return target in their options_description, that is:

{{{(""opt"", po::value<float>&fA), """")}}}

instead of

{{{(""vecopt"", po::value<vector<float>>&vfa), """")}}}

a simple syntax for specifying such a vector (that is, an option that can occur multiple times), on the command line, in a config file or even in an environment variable (sic!) can be used.

Compare (for command line) [--test ""(1 2 3)""] with [--test 1 --test 2 --test 3].

Adding support for this syntax in the validate() function for vectors ensures that the braces (feel free to change them to another symbol that makes better sense to you) will only be processed specially when the user specified a vector as output variable. It will not break any existing option input systems defined by users.

Note that it will still be possible to specify options multiple times, the values of which will be accumulated in the vector. One could even supply multiple vector-syntax inputs for the same option, which would then get concatenated together.

The code is not yet totally finished, I need to add support for handling vectors of strings, marked as TODO in the code.

proposed diff:

{{{
Index: value_semantic.hpp
===================================================================
--- value_semantic.hpp  (revision 54915)
+++ value_semantic.hpp  (working copy)
@@ -8,6 +8,8 @@

 #include <boost/throw_exception.hpp>

+#include <boost/algorithm/string.hpp>
+
 namespace boost { namespace program_options {

     extern BOOST_PROGRAM_OPTIONS_DECL std::string arg;
@@ -124,7 +126,8 @@
 #endif

     /** Validates sequences. Allows multiple values per option occurrence
-       and multiple occurrences. */
+       and multiple occurrences. This function is only called when user
+       supplied vector<T> as datatype in option_description */
     template<class T, class charT>
     void validate(boost::any& v,
                   const std::vector<std::basic_string<charT> >& s,
@@ -142,11 +145,37 @@
                 /* We call validate so that if user provided
                    a validator for class T, we use it even
                    when parsing vector<T>.  */
-                boost::any a;
-                std::vector<std::basic_string<charT> > v;
-                v.push_back(s[i]);
-                validate(a, v, (T*)0, 0);
-                tv->push_back(boost::any_cast<T>(a));
+
+                vector<std::basic_string<charT>> value;
+
+                // test if vector notation is used in input
+                if (*s[i].begin() == '(' && *s[i].rbegin() == ')')
+                {
+                    // test if it is a vector of strings
+                    if (is_same<T, string>::value||is_same<T, wstring>::value)
+                    {
+                        /** TODO: needs special treatment, cant simply split
+                            on space character
+                            For now, proceed as before */
+                        value.push_back(s[i]);
+                    }
+                    else
+                    {
+                        split( value, s[i].substr(1, s[i].size()-2), is_any_of(
"" "") );
+                    }
+                }
+                else
+                    value.push_back(s[i]);
+
+                // validate option values
+                for (unsigned j = 0; j < value.size(); j++)
+                {
+                    boost::any a;
+                    std::vector<std::basic_string<charT> > v;
+                    v.push_back(value[j]);
+                    validate(a, v, (T*)0, 0);
+                    tv->push_back(boost::any_cast<T>(a));
+                }
             }
             catch(const bad_lexical_cast& /*e*/) {
                 boost::throw_exception(invalid_option_value(s[i]));
}}}",Diederick C. Niehorster <dcnieho@…>
3248,xlc warnings in MPL,mpl,Boost 1.39.0,Boost 1.40.0,Bugs,Aleksey Gurtovoy,new,2009-07-07T00:10:05Z,2012-03-03T18:57:26Z,"xlc 10.1 throws the following warnings when using mpl::set:

""/usr/local/include/boost/mpl/set/aux_/set0.hpp"", line 63.6: 1540-0095 (W) The friend function declaration ""operator||"" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters.

""/usr/local/include/boost/mpl/set/aux_/set0.hpp"", line 64.6: 1540-0095 (W) The friend function declaration ""operator%"" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters.
",Ioannis Papadopoulos <ipapadop@…>
3247,Multicast join group does not honor interface specification,asio,Boost 1.39.0,Boost 1.40.0,Bugs,chris_kohlhoff,new,2009-07-06T21:18:46Z,2013-03-22T10:15:55Z,"I'm working with the Multicast receiver example at:

http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/example/multicast/receiver.cpp

Notice that you specify the listen_address as you create the endpoint that is bound to the socket. Later when you call socket::set_option with the multicast_address, I would expect the listen_address to be honored. The current implementation uses INET_ANY for the interface in the multicast subscription.   This means the multicast messages may arrive on one interface while you are listening for them on another one.  I can't think of any case in which you would want to specify an IP for the receive, but not for the join_group and it certainly shouldn't be the default behavior when you use the example code as a guide.

Workaround: There is a different constructor for the join_group object that does produce the desired behavior, but it is not obvious that you should need it.  Also it does not accept boost::asio::ip::addresses as arguments (which would make sense) but requires that you ""convert"" them to ip4 (or ip6) addresses.   Seems awkward.
",Dale Wilson <wilson@…>
3240,Boostbook documentation is built under the current working directory.,build,Boost 1.39.0,To Be Determined,Bugs,Vladimir Prus,new,2009-07-03T10:07:48Z,2009-07-03T10:07:48Z,"For a demonstration, change to `$BOOST_ROOT`, and run:

    bjam libs/static_assert/doc/

The documentation is built in `$BOOST_ROOT/html` when I'd expect it to be built in `$BOOST_ROOT/libs/static_assert/doc/html`. The css file is installed to `$BOOST_ROOT/libs/static_assert/doc/html` so the links to it are broken. Also, for some other documentation, links are broken unless it's built in the correct location.

If this is fixed, the asio documentation build will have to be fixed as it relies on the current behaviour. In `doc/Jamfile.v2` an alias is used which builds the documentation in `doc/html`, so ideally there should be a way to preserve that - perhaps a parameter to specify the destination, in a similar manner to `install`.

This isn't a priority as it doesn't create any real problems in practice but it would be nice as it would make it easy to create a Jamfile which builds all the boostbook documentation, including 'standalone' documentation.",Daniel James
3239,duplicate case value in error_code.cpp on mipsel,system,Boost 1.39.0,Boost 1.40.0,Bugs,markus_werle,new,2009-07-02T20:23:52Z,2009-07-20T13:33:51Z,"Compiler: gcc version 4.1.2
Target: mipsel-linux-uclibc

Error:
libs/system/src/error_code.cpp:223: error: duplicate case value

libs/system/src/error_code.cpp:179: error: previously used here

libs/system/src/error_code.cpp:232: error: duplicate case value

libs/system/src/error_code.cpp:177: error: previously used here


Solution?

# if ECONNRESET != ENOTRECOVERABLE

case ENOTRECOVERABLE: return make_error_condition( state_not_recoverable );

# endif // ECONNRESET != ENOTRECOVERABLE



# if ECONNABORTED != EOWNERDEAD

case EOWNERDEAD: return make_error_condition( owner_dead );

# endif // ECONNABORTED != EOWNERDEAD



Thank you :)",der_felix@…
3224,shape() should return a RandomAccessCollection,multi_array,Boost 1.39.0,Boost 1.40.0,Feature Requests,Ronald Garcia,new,2009-06-26T15:53:08Z,2009-06-26T15:53:08Z,"Has there ever been any thought to making multi_array::shape() return something that models the Collection concept (RandomAccessCollection in particular I suppose) rather than a raw pointer?  This would allow the return value from shape() to be passed directly to multi_array::reshape() or multi_array::resize(), for added convenience.  It would also allow a debug assertion to be added to make sure you don't try to access beyond the end of the array returned by shape().

From looking at the multi_array code, it looks like it would be relatively easy to add a new function called maybe ""size()"" which would replace ""shape()"" (which could be kept but deprecated) where
size() would return a const reference to the boost::array used internally to store the extent_list_.
",fhess
3223,number  of dimensions as static constant,multi_array,Boost 1.39.0,Boost 1.40.0,Feature Requests,Ronald Garcia,new,2009-06-26T15:48:15Z,2012-01-13T15:48:06Z,"multi_array and friends should provide the number of dimensions as a static member constant, so it is available at compile time and can be used in generic programming.  I assume the num_dimensions() non-static member function was put in the design with the idea that the number of dimensions of a multi_array object might be dynamically changed.  But since the multi array concept and classes doen't support changing the number of dimensions, it doesn't provide anything useful over a static constant.",fhess
3222,const-correctness and documentation bugs,multi_array,Boost 1.39.0,Boost 1.40.0,Bugs,Ronald Garcia,new,2009-06-26T15:47:00Z,2009-06-26T15:47:00Z,"I am able to modify a const multi_array through a multi_array_ref.  For example:

const boost::multi_array<int, 2> myarray(boost::extents[2][2]);
boost::multi_array_ref<int, 2> myarrayref(myarray);
myarrayref[0][1] = 2;

IMO, trying to create a multi_array_ref from a const multi_array should fail to compile, only a const_multi_array_ref should work.
Also, the reference doesn't include the public inheritance between multi_array, multi_array_ref, and const_multi_array in their class synopses. It is important because it seems to be the only reason you can do conversions from multi_array to multi_array_ref or const_multi_array_ref.
",fhess
3221,Collection concept documentation missing reverse_iterator,utility,Boost 1.39.0,Boost 1.40.0,Bugs,jsiek,new,2009-06-26T14:14:28Z,2013-02-04T22:45:10Z,"The ReversibleCollection concept should list reverse_iterator as an associated type required by the concept, with a little 1-sentence description of what it needs to to (like the listings for the associated types of a Collection).",fhess
3219,restrict1 or mutable_restrict1,uBLAS,Boost 1.39.0,To Be Determined,Bugs,Gunter,new,2009-06-26T08:54:56Z,2009-10-05T22:22:36Z,"hi, when you compile the Bayes++ library with Boost (for 1.39 and 1.38 versions),
there is a bug with uBlas :
In boost/numeric/ublas/symmetric.hpp
ln1145 : i = triangular_type::mutable_restrict1 (i, j);
ln1175 : j = triangular_type::mutable_restrict2 (i, j);

In boost/numeric/ublas/functional.hpp ln1730 there is a
""// FIXME: this should not be used at all""
for mutable_restrict1 and so.

I get the following error message :
error C2660: 'boost::numeric::ublas::detail::transposed_structure<L>::mutable_restrict1' : la fonction ne prend pas 2 arguments	D:\Program Files\CEA\lcviExtern_test\boost_1_39_0\boost\numeric\ublas\symmetric.hpp	1145


",julien michot
3217,inconsistent from_xxx_string() name for date and ptime,date_time,Boost 1.39.0,Boost 1.40.0,Bugs,az_sw_dude,new,2009-06-25T21:21:47Z,2009-06-25T21:21:47Z,"The date and ptime class both have a function that constructs an instance from an ISO formatted string. However, date names this function from_undelimited_string() and ptime from_iso_string(). This is a unnecessary inconsistency. Either name would work for me though my preference is the iso variant.","""LeJacq, Jean Pierre"" <jplejacq@…>"
3196,compiler warnings in VC9,concept_check,Boost 1.39.0,Boost 1.40.0,Bugs,jsiek,new,2009-06-20T02:44:21Z,2011-06-10T08:26:33Z,"The following code in boost/concept/detail/msvc.hpp generates a warning stating that 'x' is an unreferenced formal parameter under VC9 at warning level 4 when failed() isn't invoked.  Since this already appears to be an msvc-specific file, can it's contents be wrapped in a #pragma warning( disable : 4100 ) to suppress the warning?

template <class Model>
struct check
{
    virtual void failed(Model* x)
    {
        x->~Model();
    }
};",kfriddile@…
3194,compiler warnings in VC9,crc,Boost 1.39.0,Boost 1.40.0,Bugs,Daryle Walker,new,2009-06-20T01:29:13Z,2011-01-14T23:22:15Z,"The following code under VC9 with warning level 4 produces the warnings below. Warnings are not allowed on my project, and rather than wrapping boost includes with a #pragma directive, I'd rather these warnings just be suppressed in the code that's causing them.

boost::uint32_t GenerateChecksum( const char* data, size_t length )
{
  boost::crc_32_type computer;

  computer = std::for_each( data,
                            data + length,
                            computer );

  return computer();
}

2>C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(377) : warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<8>::least', signed/unsigned mismatch
2>C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(400) : warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<16>::least', signed/unsigned mismatch
2>C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(574) : warning C4244: 'return' : conversion from 'unsigned int' to 'unsigned char', possible loss of data
2>        C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(574) : while compiling class template member function 'unsigned char boost::detail::crc_helper<Bits,DoReflect>::index(unsigned int,unsigned char)'
2>        with
2>        [
2>            Bits=32,
2>            DoReflect=true
2>        ]
2>        C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(836) : see reference to class template instantiation 'boost::detail::crc_helper<Bits,DoReflect>' being compiled
2>        with
2>        [
2>            Bits=32,
2>            DoReflect=true
2>        ]
2>        C:\Documents and Settings\Administrator\My Documents\Development\development\third_party\boost\1_39_0\boost/crc.hpp(836) : while compiling class template member function 'boost::crc_optimal<Bits,TruncPoly,InitRem,FinalXor,ReflectIn,ReflectRem>::crc_optimal(unsigned int)'
2>        with
2>        [
2>            Bits=32,
2>            TruncPoly=79764919,
2>            InitRem=-1,
2>            FinalXor=-1,
2>            ReflectIn=true,
2>            ReflectRem=true
2>        ]
2>        ..\..\..\..\components\libs\checksum\source\Checksum.cpp(12) : see reference to class template instantiation 'boost::crc_optimal<Bits,TruncPoly,InitRem,FinalXor,ReflectIn,ReflectRem>' being compiled
2>        with
2>        [
2>            Bits=32,
2>            TruncPoly=79764919,
2>            InitRem=-1,
2>            FinalXor=-1,
2>            ReflectIn=true,
2>            ReflectRem=true
2>        ]",kfriddile@…
3188,concepts for immutable types,uBLAS,Boost 1.39.0,To Be Determined,Feature Requests,Gunter,new,2009-06-18T07:56:28Z,2009-06-18T07:56:28Z,"Currently all concepts are written for mutable objects although all containers and expressions can be either constant or mutable. 

I suggest to split the current concepts in basic concepts that contain the operations for both constant and mutable classes and special concepts only for mutable classes (which are a refinement of the constant concepts).",Gunter
3165,wrong project-config.jam generated for intel-linux,build,Boost 1.39.0,Boost 1.42.0,Bugs,Vladimir Prus,new,2009-06-11T06:22:00Z,2009-11-10T08:27:13Z,"Per http://permalink.gmane.org/gmane.comp.lib.boost.user/48455, if using the intel-linux toolset, bootstrap.sh generates wrong code to check if intel-linux is already initialized, which leads to double-initialization.",Vladimir Prus
3154,Documentation does not specify support (or lack of) for negative strides,multi_array,Boost 1.39.0,Boost 1.40.0,Feature Requests,Ronald Garcia,new,2009-06-09T11:44:35Z,2009-06-09T11:44:35Z,"Are negative strides supported by the multi_array library? The documentation does not mention them explicitly. Anecdotal evidence suggests that they work in some cases when range checking is disabled. See:

[http://article.gmane.org/gmane.comp.lib.boost.devel/190214]",John Reid <j.reid@…>
3153,Can only disable range checking by defining BOOST_DISABLE_ASSERTS macro,multi_array,Boost 1.39.0,Boost 1.40.0,Feature Requests,Ronald Garcia,new,2009-06-09T11:40:56Z,2009-06-09T12:09:20Z,Defining BOOST_DISABLE_ASSERTS disables boost asserts compilation unit wide. It would be nice to have finer grained control over the range checking in multi_array via a multi_array specific macro.,John Reid <john.reid@…>
3152,Obtaining a minimum s-t cut edge set,graph,Boost 1.39.0,To Be Determined,Feature Requests,Douglas Gregor,new,2009-06-09T07:17:52Z,2010-12-08T19:44:37Z,"The boost graph library offers a set of algorithms to solve linear max-flow problems, among them push-relabel and kolmogorov max-flow algorithms.

Often, the application of the max-flow algorithm is in order to solve for a minimum edge cut set separating nodes s and t.  Right now, obtaining a minimum edge cut set is not supported in the boost graph library.  Thus one of the main applications of solving max flow problems is not catered for by boost graph.

Limited support for this functionality is available in the kolmogorov_max_flow algorithm by means of a color map mapping vertices to black, white and gray states.  However, this is specific to the kolmogorov max flow algorithm whereas the general feature to obtain the minimum cut set is so important such that it should be an own feature supported by all max flow algorithms in the library.

Additionally, the documentation or code of the colormap in the kolmogorov max flow algorithm is wrong; there are connected but undecided states (gray) and applying the white-nonwhite or black-nonblack separation suggested in the documentation does not always yield a minimum cut set.

Thanks for considering.",nowozin@…
3150,"boost.asio: async_copy(in, out, ...) for POSIX sendfile() support",asio,Boost 1.39.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2009-06-08T13:00:57Z,2009-08-11T09:43:27Z,"hey guys,

i wanted to use boost and boost.asio in order to implement a web service, however, when transmitting static files, i feel not welcome in just memcpy'ing the file into RAM and copying back into kernel space for transmission over TCP/IP.
that's where POSIX sendfile() comes into play.

it takes an input file descriptor (local file e.g.), an output file descriptor (socket e.g.), offset and count, and transfers data directly from input to output *without* leaving kernel space, this is highly recommented e.g. when sending local files to sockets in HA software.

just like async_read/async_write, i imagine that it could be possible in providing an
  return_type async_copy(input, output, count, finish_callback, ...);

would you mind?",trapni@…
3144,Support unicode punctuation,quickbook,Boost 1.39.0,To Be Determined,Feature Requests,Daniel James,new,2009-06-06T13:47:00Z,2014-04-09T02:19:44Z,"Spirit 1's punct_p uses the standard C locale `ispunct`. So use something that supports unicode punctuation.

Maybe also add a way to choose the locale to use and look for anywhere else that the locale matters.

[http://tinyurl.com/35j57v David Abrahams wrote]:

> It seems like Quickbook defines ""punctuation"" as whatever the 'C'
> locale says it is.  As a result, none of the following foo's are
> italicized:
{{{
/foo/—a generic name used in programming—came to being after WWII.

“/foo/” came into being after WWII.
}}}
> This fact (if I have it right) should be documented.
>
> [QB should be fixed to handle unicode input.] ",Daniel James
3132,Provide conversions to time_t,date_time,Boost 1.39.0,,Feature Requests,az_sw_dude,assigned,2009-06-04T09:23:12Z,2012-07-01T18:11:19Z,"Extracted from #889.

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

Need to provide conversion function from Boost.DateTime types to std::time_t.",Andrey Semashev
3131,DCCP protocol support in Boost.Asio,asio,Boost 1.39.0,Boost 1.40.0,Feature Requests,chris_kohlhoff,new,2009-06-04T08:45:27Z,2009-07-10T10:35:44Z,"DCCP is a connected datagram protocol, which can be seen to occupy the niche between UDP and TCP. Newer versions of glibc enable support of this protocol to some extent, so I decided, it may be handy to have support for it in Asio as well.

Considering that it only operates on connected sockets, I hacked up new basic_dccp_socket/dccp_socket_service classes, which are datagram in nature, but do not support unconnected operation.

One problem I haven't though about the way to address (hopefully, somebody will help me out with this) is concept of DCCP service codes. Each DCCP socket must be associated with one or several service codes. Information about the desired service codes must be communicated somehow down the pipe (either through an appropriate change to the ""resolver"" or by some other means).

If ignored, service code on sockets default to 0 and everything works fine, but it is not an intended approach to DCCP use.
",oakad@…
3129,Return types of Parameter ArgumentPack creation functions should be documented,parameter,Boost 1.39.0,Boost 1.40.0,Feature Requests,Daniel Wallin,new,2009-06-03T17:57:16Z,2009-06-03T17:57:16Z,"The return types of functions such as operator= on keywords, operator, on ArgumentPacks, and the empty ArgumentPack are not documented.  This information is necessary to write functions that return ArgumentPacks.  This could be provided by a traits class that allows the underlying implementations of these constructs to be changed later.",Jeremiah Willcock
3128,comma operator not in reference docs,parameter,Boost 1.38.0,Boost 1.40.0,Bugs,Daniel Wallin,new,2009-06-03T17:10:27Z,2009-06-03T17:10:27Z,It should be described there.,Dave Abrahams
3114,Modified interface to allow even lazier return types for defaults,parameter,Boost 1.38.0,Boost 1.42.0,Feature Requests,Jeremiah Willcock,new,2009-05-30T23:51:19Z,2010-01-09T19:56:50Z,"There are some use cases where the return type of operator() in a default computation class is not valid in some cases when that default is not used.  The current interface to such classes does not allow that case; see the message at http://lists.boost.org/Archives/boost/2009/05/152009.php for more information.  The attached patch allows a special member type (that must be void) to be used to change the interface to pass a single int argument to operator(), while keeping the old no-parameter interface for function objects without the special tag.  The tag could also have been implemented as a traits class used with enable_if.  The patch passes all of the Boost.Parameter tests except two (which appear to freeze up).  I only changed the normal path through the code, and not the compatibility code which I am unable to test.  A test for the new functionality added by the patch is also attached.",Jeremiah Willcock
3112,Tag object initialization not guaranteed legal,parameter,Boost 1.38.0,Boost 1.40.0,Bugs,Daniel Wallin,new,2009-05-29T17:53:00Z,2009-05-29T18:31:49Z,We should be using this technique: http://tinyurl.com/threadsafe-static-globals,Dave Abrahams
3109,time_duration::total_seconds() - overflow,date_time,Boost 1.41.0,To Be Determined,Bugs,az_sw_dude,new,2009-05-29T14:30:21Z,2016-08-02T05:45:20Z,"time_duration::total_seconds() overflow value

minimal sample (based on boost example)
//////////////////////////////////////////////////////////////
#include <string>
#include <boost/date_time/local_time/local_time.hpp>

int main()
{
    using namespace boost::gregorian; 
    using namespace boost::local_time;
    using namespace boost::posix_time;

    date in_date(2039, 10, 04);
    time_duration td(12,14,32);
    std::string z(""PST-8PDT,M4.1.0,M10.1.0"");
    time_zone_ptr zone(new posix_time_zone(z));
    local_date_time my_time(in_date, td, zone,  local_date_time::NOT_DATE_TIME_ON_ERROR);
    std::cout << my_time << std::endl;
    //
    ptime time_t_epoch( date(1970,1,1) ); 
    std::cout << time_t_epoch << std::endl;
    //
    time_duration diff = my_time.utc_time() - time_t_epoch;
    std::cout << ""Seconds diff: "" << diff.total_seconds() << std::endl;
    return 0;
}
//////////////////////////////////////////////////////////////


",ioni@…
3077,Reverse iterator compile-time bug in multi_array,multi_array,Boost 1.38.0,Boost 1.40.0,Bugs,Jeremiah Willcock,assigned,2009-05-25T10:47:28Z,2010-06-08T22:51:47Z,"I'm having some trouble iterating over a 2-dimensional multi_array in reverse order. I'm using boost 1.38 with gcc-4.2.4 and the following code won't compile with the error given below:

{{{
#include <boost/multi_array.hpp>

template< typename It >
void
iterate_over( It begin, It end )
{
    while( end != begin ) {
        begin->end() - begin->begin();
        ++begin;
    }
}

void
test()
{
    boost::multi_array< double, 2 > m;
    iterate_over( m.begin(), m.end() );   // works fine
    iterate_over( m.rbegin(), m.rend() ); // causes error
}
}}}


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


/home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp: In static member function ‘static typename boost::mpl::if_<boost::is_reference<Reference>, Pointer, boost::detail::operator_arrow_proxy<ValueType> >::type boost::detail::operator_arrow_result<ValueType, Reference, Pointer>::make(Reference) [with ValueType = boost::multi_array<double, 1ul, std::allocator<double> >, Reference = boost::detail::multi_array::sub_array<double, 1ul>, Pointer = boost::multi_array<double, 1ul, std::allocator<double> >*]’:
/home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:648:   instantiated from ‘typename boost::detail::operator_arrow_result<typename boost::detail::iterator_facade_types<Value, CategoryOrTraversal, Reference, Difference>::value_type, Reference, typename boost::detail::iterator_facade_types<Value, CategoryOrTraversal, Reference, Difference>::pointer>::type boost::iterator_facade<I, V, TC, R, D>::operator->() const [with Derived = boost::reverse_iterator<boost::detail::multi_array::array_iterator<double, double*, mpl_::size_t<2ul>, boost::detail::multi_array::sub_array<double, 1ul> > >, Value = boost::multi_array<double, 1ul, std::allocator<double> >, CategoryOrTraversal = boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, Reference = boost::detail::multi_array::sub_array<double, 1ul>, Difference = long int]’
src/sandbox/seqan_sandbox.cpp:12:   instantiated from ‘void iterate_over(It, It) [with It = boost::reverse_iterator<boost::detail::multi_array::array_iterator<double, double*, mpl_::size_t<2ul>, boost::detail::multi_array::sub_array<double, 1ul> > >]’
src/sandbox/seqan_sandbox.cpp:22:   instantiated from here
/home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:326: error: no matching function for call to ‘implicit_cast(boost::detail::multi_array::sub_array<double, 1ul>*)’ ",John Reid <john.reid@…>
3054,boost::python doesn't support implicit intrusive_ptr casts,python USE GITHUB,Boost 1.37.0,Boost 1.40.0,Bugs,troy d. straszheim,new,2009-05-20T12:52:44Z,2013-02-06T08:18:30Z,"See http://mail.python.org/pipermail/cplusplus-sig/2007-February/011651.html for code that solves this. (the boostPatch namespace contents)

I couldn't find anything on Boost.Python in the release notes for 1.38 or 1.39, so I assume it's still in there.

Also, for those who need this before it's included in boost::python::class_, a better use of the functions (than the typedeffing in the post above) is:

{{{
#!cpp
template<class T, class B, class X, class Y>
class myclass : boost::python::class_<T, B, X, Y>
{
public:
   template<class Constructor>
   myclass(const char* name, const Constructor& t) : boost::python::class_<T, B, X, Y>(name, t)
   {
      boostPatch::register_intrusive_ptr_from_python_and_casts( (T *)0, metadata::bases() );
   }
};
}}}

",macke@…
3053,asio::placeholders not compatible with std::tr1::bind,asio,Boost 1.38.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2009-05-20T09:18:09Z,2009-06-27T08:03:06Z,"If I use a placeholder from `boost::asio::placeholders` with `std::tr1::bind` from `<functional>`, I get loads of compiler output, concluding with this:
{{{
/usr/include/c++/4.3/tr1_impl/functional:1138: error: no match for call to '(std::tr1::_Mem_fn<void (Connection::*)(const boost::system::error_code&)>) (Connection*&, boost::arg<1> (*&)())'
/usr/include/c++/4.3/tr1_impl/functional:551: note: candidates are: _Res std::tr1::_Mem_fn<_Res (_Class::*)(_ArgTypes ...)>::operator()(_Class&, _ArgTypes ...) const [with _Res = void, _Class = Connection, _ArgTypes = const boost::system::error_code&]
/usr/include/c++/4.3/tr1_impl/functional:556: note:                 _Res std::tr1::_Mem_fn<_Res (_Class::*)(_ArgTypes ...)>::operator()(_Class*, _ArgTypes ...) const [with _Res = void, _Class = Connection, _ArgTypes = const boost::system::error_code&]
/usr/include/c++/4.3/tr1_impl/functional:1138: error: return-statement with a value, in function returning 'void'
}}}
With `Connection` a self-defined class. If I use `boost::bind` instead of `std::tr1::bind`, it works.

To me, this seems like the placeholders from asio are not usable with `bind` from TR1. Is there any way to fix this in Boost, perhaps using BOOST_HAS_TR1_BIND in the asio headers?",sdrongel@…
3049,libs/mpl/preprocessed need README on purpose and howto,mpl,Boost 1.38.0,Boost 1.40.0,Feature Requests,Aleksey Gurtovoy,new,2009-05-19T14:57:23Z,2014-01-13T22:33:55Z,"After application of recent patch file:

https://svn.boost.org/trac/boost/attachment/ticket
  /3044/iter_fold_if.patch

an attempt to run the test resulted in an error msg:

gcc.compile.c++ ../../../bin.v2/libs/mpl/test/iter_fold_if.test
  /gcc-4.2/debug/iter_fold_if.o
In file included from iter_fold_if.cpp:14:
../../../boost/mpl/iter_fold_if.hpp:86: error: wrong number of
  template arguments (5, should be 6)
../../../boost/mpl/aux_/preprocessed/gcc/iter_fold_if_impl.hpp:96:
  error: provided for 'template<class Iterator, class State, 
  class ForwardOp, class ForwardPredicate, class BackwardOp, 
  class BackwardPredicate> struct 
  boost::mpl::aux::iter_fold_if_impl'

This message indicates need to regenerate the preprocessed 
files from the programs in /mpl/lib/preprocessed; however,
there's no README file in that directory providing
instructions on how to do that.

It would be very helpful if one were provided.

",cppljevans@…
3044,mpl::aux_::iter_fold_if_impl allows deref l_end,mpl,Boost 1.38.0,Boost 1.40.0,Bugs,Aleksey Gurtovoy,new,2009-05-18T16:06:03Z,2009-06-06T11:07:10Z,"The mpl::aux_::iter_fold_if_impl template:

  https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/aux_
    /iter_fold_if_impl.hpp

allows deref'ing of an end iterator. The problem is most easily
shown with list because deref<l_end> is not possible.
Apparently, deref of an end iterator from other sequences
(e.g. vector or range_c) allow deref of an end iterator.

The attached:

  iter_fold_if_bkprotect.zip
  
illustrates the problem.  The attached:

  iter_fold_if_bkprotect2.zip
  
illustrates the cause.  The attached:

  while.cpp
  
illustrates a solution.  However, the while.cpp suffers from the
template instantiation depth problem described here:

  http://www.mywikinet.com/mpl/paper 
    /mpl_paper.html#sequences.unrolling

More (*maybe* helpful) details can be found at the following
boost ml thread:

  http://thread.gmane.org/gmane.comp.lib.boost.devel/187289
",cppljevans@…
3040,add ability to reset an accumulator_set,accumulator,Boost 1.38.0,Boost 1.40.0,Feature Requests,Eric Niebler,new,2009-05-15T21:39:18Z,2009-05-15T21:39:18Z,See discussion [http://groups.google.com/group/boost-list/browse_thread/thread/aaede77988f827db?pli=1 here],Eric Niebler
3030,[crc] optimization of crc_optimal::process_block,crc,Boost 1.39.0,Boost 1.40.0,Patches,Daryle Walker,new,2009-05-14T21:18:29Z,2012-02-26T12:09:37Z,Function 'process_block()' can be easily optimized (I got about 20% in performance on ARM9/GCC 3.4.3/4.2.0),qehgt0@…
2990,[fix in git] boost::python::detail::caller implementation should use mpl::deref while fiddling with the signature sequence,python USE GITHUB,Boost 1.38.0,Boost 1.39.0,Bugs,Dave Abrahams,new,2009-05-05T05:37:13Z,2009-10-20T02:58:56Z,"In boost/python/detail/caller.hpp, to get at the various elements of the call signature sequence, the code directly uses Sig_iterator::type to access the element. This has a side effect of not allowing mpl::list to be used as the sequence, even though it is an MPL front extensible sequence (stated as required for the signature argument of, say, make_function).

The solution is to use mpl::deref<Sig_iterator>::type instead of Sig_iterator::type.",LiJie Wong <lycheewlj@…>
2985,Progress Display Remaining Time,timer,Boost Development Trunk,Boost 1.39.0,Feature Requests,Beman Dawes,new,2009-05-03T21:17:35Z,2009-05-04T20:08:46Z,"It would be nice if the progress bar could calculate the estimated time remaining. There would have to be some kind of assumption about the uniformity of the remaining computations, but often I have a simple loop 
for(i = 0; i < 1e6; i++)

where I am doing the same thing in each iteration, so if I am 50% complete after 10 minutes, I expect to be done in about another 10 minutes.

Of course this is not the case with all loops, but if the thing being timed is known not to exhibit that behavior, then this shouldn't be used.",daviddoria@…
2968,Add a BOOST_BUILD_DIR Environment variable,build,Boost 1.38.0,Boost 1.39.0,Feature Requests,Vladimir Prus,new,2009-04-25T17:10:04Z,2009-04-25T17:10:04Z,"To set the global build dir it would be very convenient to have
a BOOST_BUILD_DIR environment variable that has the same semantic as the --build-dir= command line switch.

It would be equally nice to be able to specify it in the *-config.jam
files, but a first glance it looks as if this would come too late
in the start-up process.",Roland Schwarz
2960,"Composing argument pack formed with positional arguments, using the comma operator",parameter,Boost 1.37.0,To Be Determined,Bugs,Daniel Wallin,new,2009-04-19T16:33:51Z,1970-01-01T00:00:00Z,"Due to a  bug (or perhaps my misusage), I am unable to compose two argument packs, each formed using positional arguments, using the comma operator.

news://news.gmane.org:119/grtmb9$tpq$1@ger.gmane.org
Compiler : i686-apple-darwin9-gcc-4.0.1

BOOST_PARAMETER_KEYWORD(tag, x)
BOOST_PARAMETER_KEYWORD(tag, y)
template<class ArgumentPack>
void f(ArgumentPack const & args){
     double x_val = args[x];
     double y_val = args[y];
}

    typedef boost::parameter::parameters<
        parameter::required<tag::x>
    > par_x_t;
    typedef boost::parameter::parameters<
        parameter::required<tag::y>
    > par_y_t;

     double x_val = 9.0;
     double y_val = 0.1;
     spec_x_t spec_x;
     spec_y_t spec_y;
     f(
         ( spec_x(x_val),spec_y(y_val))         
     ); //no match operator[<unnamed>::x] 



",e_r
2958,[patch] changes to make asio compile on vxWorks,asio,Boost 1.38.0,Boost 1.39.0,Patches,chris_kohlhoff,new,2009-04-18T22:03:37Z,2009-04-18T22:04:48Z,"An explanation of some of the changes:

socket/pipe interrupter: Despite that vxWorks has a pipe facility, it appears that you must create a named pipe, and then open the file, which is a bit different than the unix pipe function. Since its not clear to me how many different interrupters may be created by asio, its far easier to use the select_interrupter instead (and it works just as well). 

socket_ops: for whatever reason the arguments to its socket related functions take an int, and a socklen_t is an unsigned int. there are also a number of functions where a non-const arg is passed that apparently is typically a const arg on other systems.  

socket_ops/descriptor_ops: when running as a kernel module, apparently open and ioctl have three fixed arguments, with the third argument being an integer. outside of kernel modules it appears to have the traditional API. 

Patch from ticket #2917 is required for vxWorks as well, since it does not support serial ports via termios. 

There are patches to other boost libraries required also, those have been submitted in other bugs. 
",Dustin Spicuzza <dustin@…>
2956,vxWorks POSIX quirks for date_time,date_time,Boost 1.38.0,Boost 1.39.0,Patches,az_sw_dude,new,2009-04-18T20:10:47Z,2013-06-12T21:44:49Z,"vxWorks is almost a unix-like platform, that supports the POSIX realtime extensions and a lot of POSIX stuff.. but its weird. 

It apparently doesn't support gettimeofday. I modified microsec_time_clock to support a situation where gettimeofday isn't available but clock_gettime is. 

vxWorks has localtime_r, but it is defined as ""extern int localtime_r (const time_t *_tod, struct tm *_result);""... so it needs some hand holding to work correctly. same with gmtime_r

Of course, this patch also requires the user to setup a config that defines BOOST_HAS_CLOCK_GETTIME, but I'm going to submit a separate patch for vxWorks platform config",Dustin Spicuzza <dustin@…>
2952,Windows: path.glob doesn't accept paths at the root of the current drive,build,Boost.Build-M3,To Be Determined,Bugs,Vladimir Prus,new,2009-04-17T00:17:33Z,2009-04-17T20:04:05Z,"Trying to provide a full pathname to boost-build caused [[BR]]
error: Unknown target type EXE[[BR]]
The problem occurs with[[BR]]

{{{
boost-build /temp/boost-build ;
}}}

Based on the debug output the leading slash of the pathname is removed in util/path.jam:
{{{
/temp/boost-build/util\path.jam:54:>>>>|>>>>|>>>>|>>>>| native-NT /temp/boost-build/tools/types/*.jam
/temp/boost-build/util\path.jam:464:>>>>|>>>>|>>>>|>>>>|>> MATCH ^/?(.*) : /temp/boost-build/tools/types/*.jam
/temp/boost-build/util\path.jam:464:>>>>|>>>>|>>>>|>>>>|>> local result = temp/boost-build/tools/types/*.jam
/temp/boost-build/util\path.jam:465:>>>>|>>>>|>>>>|>>>>|>> regex.split temp/boost-build/tools/types/*.jam /
}}}
While the equivalent

{{{
boost-build c:/temp/boost-build ;
}}}
is processed successfully. Note that the boost-build kernel is loaded using the path specified in either case, up to the point of loading the contents of tools/types/.",John <jwbito@…>
2944,"boost::archive::xml_iarchive hangs, if BOOST_SP_USE_PTHREADS used",serialization,Boost 1.38.0,Boost 1.39.0,Bugs,Joel de Guzman,new,2009-04-13T21:53:51Z,2009-04-20T19:36:29Z,"I use 'BOOST_SP_USE_PTHREADS' option, with serialization library.
When I try to create xml_iarchive, application hangs.

Reproduced on:
x86_64 Gentoo Linux, x86_64-pc-linux-gnu-4.3.3, glibc: 2.9_p20081201
ARM (Openmoko toolchain): gcc 4.1.2, glibc: 2.6.1

Also tried:
x32 Gentoo Linux, i686-pc-linux-gnu-4.1.2, glibc: 2.6.1
 - works perfectly, without hangs.



Backtrace while the application hang:

0x00007ffb03bf3414 in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0  0x00007ffb03bf3414 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x00007ffb03beec50 in _L_lock_55 () from /lib/libpthread.so.0
#2  0x00007ffb03bee53e in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x0000000000427c43 in boost::detail::sp_counted_base::release (this=0x672140) at /home/distr/boost/x86_64_boost_1_38_0/include/boost-1_38/boost/detail/sp_counted_base_pt.hpp:91
#4  0x0000000000433189 in boost::archive::basic_xml_grammar<char>::init_chset ()
#5  0x0000000000440ff1 in boost::archive::basic_xml_grammar<char>::basic_xml_grammar ()
#6  0x0000000000432035 in boost::archive::xml_iarchive_impl<boost::archive::xml_iarchive>::xml_iarchive_impl ()
#7  0x0000000000427b81 in xml_iarchive (this=0x7fff0d07b840, is=@0x7fff0d07b630, flags=0) at /home/distr/boost/x86_64_boost_1_38_0/include/boost-1_38/boost/archive/xml_iarchive.hpp:119
#8  0x00000000004272fb in test_xmlArchive () at /home/remote_projects/fl-dict/src/test/boost_archive_load_test.cpp:43
#9  0x00000000004273fb in main (argc=1, argv=0x7fff0d07b9c8) at /home/remote_projects/fl-dict/src/test/boost_archive_load_test.cpp:15
",highcatland@…
2939,Possible thread-safety issue with Boost Function,function,Boost 1.38.0,Boost 1.39.0,Bugs,Douglas Gregor,new,2009-04-12T04:56:21Z,2009-04-12T04:56:21Z,"Hi, I realize this might slip through the mailing lists so I am posting it here:

http://article.gmane.org/gmane.comp.lib.boost.devel/188442

I was just looking through the Boost Function source and noticed the
following in assign_to:
{{{
      // Note: it is extremely important that this initialization use
      // static initialization. Otherwise, we will have a race
      // condition here in multi-threaded code. See
      // http://thread.gmane.org/gmane.comp.lib.boost.devel/164902/.
      static vtable_type stored_vtable =
        { { &manager_type::manage }, &invoker_type::invoke };
}}}

However, my copy of the C++ standard seems to say this regarding local statics in section 6.7:

The zero-initialization (8.5) of all local objects with static storage duration (3.7.1) is performed before any other initialization takes place. A local object of POD type (3.9) with static storage duration initialized with constant-expressions is initialized before its block is first entered. An implementation is permitted to perform early initialization of other local objects with static storage duration under the same conditions that an implementation is permitted to statically initialize an object with static storage duration in namespace scope. 

I read this to mean that an implementation may decide to initialize
stored_vtable statically or the first time the block is entered. So I think that this means we cannot rely on static initialization behaviour.

If you agree, then a simple fix for this might just be:

{{{
template<typename VTable, typename Invoker, typename Manager>
struct vtable_static_constructor
{
  static VTable vtable;
};

template<...>
VTable vtable_static_constructor<V,I,M>::vtable =
  { {&Manager::manage, &Manager::invoke } };

assign_to()
{
...
  vtable_type & stored_vtable =
vtable_static_constructor<vtable_type,invoker_type,manager_type>::vtable;
...
}
}}}

If not, could you please point me to where in the standard this is
guaranteed to be statically initialized? It would help me decide whether
or not to fix some other code that has a similar pattern, if nothing else.

Thanks in advance!

",boost-trac@…
2928,Some relational operators are not listed in synopsis,optional,Boost 1.38.0,Boost 1.39.0,Bugs,Fernando Cacciola,new,2009-04-08T18:29:25Z,2013-02-16T00:53:25Z,"Direct comparison between optional<T> and T has been supported since
Boost 1.34. But such operators are not listed in synopsis in the
latest docs.

They were added to optional.html in r37126. But they seems to have
been missed in r43247.
",Kazutoshi Satoda <k_satoda@…>
2927,BOOST_MPL_DISABLE_ASSERTS,mpl,Boost Development Trunk,To Be Determined,Feature Requests,Joel Falcou,new,2009-04-08T16:23:28Z,2011-04-10T10:56:44Z,"analogous to BOOST_DISABLE_ASSERTS

The use case that drove this was some places in proto where mpl asserts could be, but aren't (like to enforce the arity requirement of the _value transform), because proto is trying to keep compile times down.

",troy d. straszheim
2917,BOOST_ASIO_DISABLE_SERIAL_PORT doesn't work as expected,xpressive,Boost.Build-M3,Website 1.X,Library Submissions,chris_kohlhoff,reopened,2009-04-05T21:48:58Z,2016-06-05T04:35:25Z,"The expected result is that none of the serial port code would be included. This does not happen, many of the serial port related headers get included and potentially cause many compile errors (for example, if your platform doesn't have termios).

Obviously there are a number of different ways to handle this problem, I can provide a patch if you like, but placement of the checks is just a matter of opinion (it seems like one would want to just put the check in the top level serial port files after boost/config.hpp is included, however). ",dustin@…
2915,Request for allowing ParameterSpec to be defined by an MPL sequence,parameter,Boost 1.38.0,Boost 1.39.0,Feature Requests,Daniel Wallin,new,2009-04-05T16:25:42Z,2009-06-08T01:31:21Z,"May I please suggest that a metafunction be provided that maps an mpl sequence such as

 typedef mpl::vector<r1,...,rn> IN; 
//each r is of the form required<T> or required<T,P>

to the template class boost::parameter::parameters instantiated with
the elements of that sequence:

  typedef parameter::parameters<
    r1,
    ...
    rn
  > OUT;

This need arises when we can generate IN automatically, for example:

typedef mpl::transform<range_c<1,n+1>,meta_r>::type IN;

Thanks.",e_r
2914,Support for cumulative parameters in a doxyfile,build,Boost 1.38.0,To Be Determined,Feature Requests,René Rivera,new,2009-04-05T11:44:56Z,2010-03-04T16:22:24Z,"It would be nice if it was possible to specify cumulative parameters as arguments to <doxygen:param>. Aliases for instance really require this. E.g.:

{{{
DOXYGEN_PARAMS =

    ...

    ALIASES+=defModule{1}=""\""\module{\1} \defgroup group_class_\1 \1\""""
    ALIASES+=module{1}=""\""\ingroup group_class_\1 \\n<div><span class=\""module\"">Module:</span>&nbsp;&nbsp;<span class=\""module_text\"">\ref group_class_\1</span></div>\""""

    ...

    ;

doxygen doc.html
    :   [ glob include/*/*.hpp ] # or whatever
    :   <doxygen:param>$(DOXYGEN_PARAMS)
    ;
}}}

Currently the parser chokes on the += construct; it expects = always. I have tinkered with doxygen.jam in my local BBv2 dir, but I am very unsure about the correctness of what I'm doing. FWIW here is the patch for what I currently use...

{{{
Index: tools/doxygen.jam
===================================================================
--- tools/doxygen.jam   (revision 52181)
+++ tools/doxygen.jam   (working copy)
@@ -197,11 +197,11 @@
     # Translate <doxygen:param> into command line flags.
     for local param in [ feature.get-values <doxygen:param> : $(properties) ]
     {
-        local namevalue = [ regex.match ([^=]*)=(.*) : $(param) ] ;
-        text += ""$(namevalue[1]) = $(namevalue[2])"" ;
+        local namevalue = [ regex.match ([^+=]*)([+]?=)(.*) : $(param) ] ;
+        text += ""$(namevalue[1]) $(namevalue[2]) $(namevalue[3])"" ;
         if $(namevalue[1]) = OUTPUT_DIRECTORY
         {
-            output-dir = ""$(namevalue[2])"" ;
+            output-dir = ""$(namevalue[3])"" ;
         }
     }
}}}
",brian@…
2911,shared_from_this free function,smart_ptr,Boost 1.38.0,To Be Determined,Feature Requests,Frank Mori Hess,new,2009-04-03T21:27:21Z,2009-12-01T01:49:22Z,"Attached is an implementation of a free shared_from_this function, plus a non-template enable_shared_from_this_base class which can only be used with the free shared_from_this function.  The free function will also work with the usual enable_shared_from_this template.  It is implemented on top of the existing enable_shared_from_this class, and so requires no modification of the existing smart_ptr code.

This scheme has the advantage of simplicity, since the ""curiously recurring template pattern"" is not needed.  It also ""just works"" if you have a class hierarchy that looks like ""X is derived from Y is derived from enable_shared_from_this_base"" and want to use shared_from_this with both X and Y.

I've only tried it with gcc 4.3.
",fhess
2909,[Fix in git] Wrong type signatures?,python USE GITHUB,Boost 1.38.0,Boost 1.39.0,Bugs,troy d. straszheim,new,2009-04-03T13:11:45Z,2009-10-12T22:44:10Z,"In python/converter/builtin_converters.hpp, I found these lines:

BOOST_PYTHON_TO_PYTHON_BY_VALUE(signed BOOST_PYTHON_LONG_LONG, ::PyLong_FromLongLong(x), &PyInt_Type)
BOOST_PYTHON_TO_PYTHON_BY_VALUE(unsigned BOOST_PYTHON_LONG_LONG, ::PyLong_FromUnsignedLongLong(x), &PyInt_Type)

and,

BOOST_PYTHON_TO_PYTHON_BY_VALUE(std::wstring, ::PyUnicode_FromWideChar(x.data(),implicit_cast<ssize_t>(x.size())), &PyString_Type)

Seems it is a typo. Should the PyInt_Type be PyLong_Type, and the PyString_Type be PyUnicode_Type?

These macro argument is used for generate the return value of get_pytype(). And seems get_pytype() is only used to generate docstring. So there's accutally no problem caused by these.

But, should these be typo? If so, we'd better fix it.

Thanks!",Haoyu Bai
2904,boost::date_time io fails simple back-and-forth test,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-04-02T21:18:24Z,2009-04-02T22:44:08Z,"set up a stringstream and use boost::io facets to specify a time format.  Sent a time_t from a known time through it to get a string (converting to posix_time along the way), then back through to to get a time, and back through to get a string.  The string results should always match, and the time_t results always match.  Both tests fail.  

stringstream>> operator does not seem to modify the supplied instance of class boost::posix_time.
",mgl@…
2901,Resizing banded matrices,uBLAS,Boost 1.38.0,Boost 1.42.0,Bugs,Gunter,new,2009-03-31T15:22:21Z,2009-10-05T22:16:55Z,"Similar to #1237 but with banded matrices. When resizing a banded matrix with preserve set to true, I get

{{{
Check failed in file /home/britter/include/boost/numeric/ublas/storage.hpp at line 195:
i < size_
terminate called after throwing an instance of 'boost::numeric::ublas::bad_index'
  what():  bad index
}}}

See attached program. ",Burkhard Ritter <burkhard@…>
2896,Gregorian date input facet do not handle every string form,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-03-27T12:43:12Z,2009-03-27T12:43:12Z,"boost::gregorian::date_input_facet do not follow other date facet schems (like local_time_input_facet).
The folowing test case can be used to reproduce the trouble.",anonymous
2888,python static linking must use defaults for dl and pthread,python USE GITHUB,Boost 1.38.0,Boost 1.39.0,Bugs,Dave Abrahams,new,2009-03-26T15:35:55Z,2009-03-26T15:35:55Z,"When statically linking boost.python, you will get errors when it also tries to statically link libdl and and pthread.[[BR]]

The solution is to change a line in 
boost_1_38_0/tools/build/v2/tools/python.jam[[BR]]

line 657 from 


case * : return  <library>pthread <library>dl[[BR]]

to[[BR]]

case * : return  [[BR]]

",niklas@…
2883,Boost::signals compile problem with GCC 3.4.5,signals,Boost 1.38.0,Boost 1.39.0,Bugs,Douglas Gregor,new,2009-03-23T23:51:19Z,2013-06-12T21:46:23Z,"I get the following error when trying to use boost sigals with GCC 3.4.5 for arm:

{{{

In file included from /home/tk/centidev/target/staging/include/boost/signals/detail/signal_base.hpp:15,
                 from /home/tk/centidev/target/staging/include/boost/signals/signal_template.hpp:23,
                 from /home/tk/centidev/target/staging/include/boost/signals/signal0.hpp:24,
                 from /home/tk/centidev/target/staging/include/boost/signal.hpp:19,
                 from TableScoreboard.h:4,
                 from TableAssembler.cpp:3:
/home/tk/centidev/target/staging/include/boost/signals/detail/named_slot_map.hpp: In member function `boost::signals::detail::connection_slot_pair& boost::signals::detail::named_slot_map_iterator::dereference() const':
/home/tk/centidev/target/staging/include/boost/signals/detail/named_slot_map.hpp:114: error: invalid initialization of reference of type 'boost::signals::detail::connection_slot_pair&' from expression of type 'const boost::signals::detail::connection_slot_pair'

}}}


Thomas",tk@…
2881,Macros conflict: BOOST_HAS_FTIME and BOOST_NO_GETSYSTEMTIMEASFILETIME,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-03-23T19:19:18Z,2011-07-13T18:08:22Z,"There are two macros related to the WinAPI FILETIME-related functions: BOOST_HAS_FTIME and BOOST_NO_GETSYSTEMTIMEASFILETIME. The first one is documented as the one that is defined if the GetSystemTimeAsFileTime API is available, whereas the second one is defined when it's not (while other functions and the FILETIME type itself are available). On Windows Mobile it is possible to get both these macros defined, which is quite contradictory to the documentation.

I believe, docs and tests should be corrected so that BOOST_HAS_FTIME is defined if the FILETIME type is available, and BOOST_NO_GETSYSTEMTIMEASFILETIME is only defined when the GetSystemTimeAsFileTime function is not available. A quick search shows that these macros are only used in Boost.DateTime and in the described meaning.",Andrey Semashev
2875,Windows: ip::tcp::acceptor::local_endpoint() cannot be used in socket connect,asio,Boost 1.38.0,To Be Determined,Feature Requests,chris_kohlhoff,assigned,2009-03-20T06:19:50Z,2009-04-09T13:05:18Z,"On linux the local_endpoint() function returns an endpoint similar to 0.0.0.0:1234. A socket which is given this endpoint to connect to will connect successfully. A similar endpoint is returned on Windows, however the socket connection is not successful.

I am currently working around this problem by inserting loopback as the address to connect to. For the sake of consistency between platforms it may be worthwhile including a similar substitution within the socket's connect operation if 0.0.0.0 is detected.",Benjamin Carlyle <ben.carlyle@…>
2863,svn.boost.org uses an invalid security certificate,serialization,Boost Development Trunk,Boost 1.58.0,Support Requests,Douglas Gregor,reopened,2009-03-17T18:59:21Z,2015-02-06T00:13:42Z,"When I navigate to https://svn.boost.org/trac/boost/ in Firefox (Windows version 3.0.7), I get the following message:

----
== Secure Connection Failed ==

svn.boost.org uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)

 * This could be a problem with the server's configuration, or it could be someone trying to impersonate the server.

 * If you have connected to this server successfully in the past, the error may be temporary, and you can try again later.
----

This can be worked around by adding a security exception. The certificate's status in the Add Security Exception dialog:

----
This site attempts to identify itself with invalid information.

'''Unknown Identity'''[[BR]]
Certificate is not trusted, because it hasn't been verified by a recognised authority.
----

MS Internet Explorer (version 6 SP2) also complains:

----
Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site's security certificate.

 * The security certificate was issued by a company you have not chosen to trust. View the certificate to determine whether you want to trust the certifying authority.

 * The security certificate date is valid.

 * The security certificate has a valid name matching the name of the page you are trying to view.

Do you want to proceed?
----
",anonymous
2841,boost::hash to support boost::dynamic_bitset,dynamic_bitset,Boost 1.43.0,,Feature Requests,"James E. King, III",new,2009-03-09T21:24:31Z,2019-06-06T13:56:16Z,"IIUC, there's no out-of-box support for hashing of dynamic_bitset.

Could something as simple as
{{{
#!cpp
    template <typename B, typename A>
    friend std::size_t hash_value(const dynamic_bitset<B, A>& v) {
        return hash_value( v.m_bits );
    }
}}}
be added to `boost::dynamic_bitset` class?

",astukalov@…
2838,MPI Python bindings not installed correctly,mpi,Boost 1.38.0,Boost 1.46.0,Bugs,Matthias Troyer,assigned,2009-03-09T09:22:55Z,2012-11-03T23:51:39Z,"I've successfully built and installed boost.MPI and the Python bindings in my home dir.

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

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

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

Otherwise, the boost.mpi Python bindings are gorgeous!",lenzo@…
2836,"Request boost::optional<T>::optional_assign_to, optional_move_to, optional_swap",optional,Boost 1.38.0,Boost 1.39.0,Feature Requests,niels_dekker,assigned,2009-03-07T11:25:11Z,2009-03-07T12:46:48Z,"I request the three member functions 

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

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

t=**this;
t=**this; and *this may have any value after the move
std::swap( t, **this );
",aschoedl@…
2833,extract result during initialization,accumulator,Boost 1.37.0,Boost 1.39.0,Feature Requests,Eric Niebler,new,2009-03-05T20:26:40Z,2009-03-05T20:26:40Z,"This is a follow up to:

news://news.gmane.org:119/goeic6$q4t$1@ger.gmane.org

where I asked :
I have an accumulator (a) that takes an initial value (x_), and another (b), whose initial value (x_) depends on that of (a). I would have thought that this is feasible because accumulator_set initializes (a) before (b), but apparently b.x_ is initialized with a garbage value. 

",e_r
2826,constant boost::mpl::aux::template_arity_impl::value causes 64 bit truncation warning,mpl,Boost Release Branch,Boost 1.47.0,Bugs,Joel Falcou,new,2009-03-03T22:29:56Z,2011-04-10T07:35:15Z,"When compiled for a 64 bit target, the constant boost::mpl::aux::template_arity_impl::value causes a warning about possible truncation of a 64 bit value to 32 bits. This is because size_t (returned by sizeof()) is 64 bits, while value is declared as an int. One fix would be to declare the constant as a size_t. Instead I added a static_cast on the assumption that it would be less disruptive and the value returned by sizeof() was unlikely to require more than 32 bits.


{{{
typename arity_tag<6>::type
arity_helper(type_wrapper< F< T1,T2,T3,T4,T5,T6 > >, arity_tag<6>);
template< typename F, int N >
struct template_arity_impl
{
    BOOST_STATIC_CONSTANT(int, value =
          static_cast<int>(sizeof(arity_helper(type_wrapper<F>(), arity_tag<N>())) - 1)
        );
};

}}}
",pelee@…
2812,Tutorial example errors,parameter,Boost 1.38.0,Boost 1.39.0,Bugs,Daniel Wallin,new,2009-02-28T09:45:42Z,2009-02-28T09:45:42Z,"In the tutorial for Boost parameter there are a number of documentation errors in section 2.1.2 when initially giving the depth_first_search example.

1) The example says ""depth_first_search algorithm is a generic function accepting from one to four arguments by reference"" but clearly the generic function takes 5 arguments with some by value.

2) The third argument listed in the prototype is given as ""typename graph_traits<g>::vertex_descriptor root_vertex"" but probably should be ""typename graph_traits<graph>::vertex_descriptor root_vertex"" as there is no 'g' argument in the prototype.

These are cosmetic documentation changes which should be made to allow someone who wants to understand the tutorial correctly to do so.

",Edward Diener <eld@…>
2811,date_time iostream dependencies,date_time,Boost 1.38.0,Boost 1.39.0,Feature Requests,az_sw_dude,new,2009-02-27T23:46:24Z,2009-02-27T23:46:24Z,"For footprint and performance reasons our codebase uses boost with BOOST_NO_IOSTREAM.  However, date_time has some iostream dependency in the form of std::ostringstream used for formatting string outputs.  For example, the method partial_date::to_string uses std::ostringstream to convert an integer to a string.

An alternative is as follows:

{{{
   //! Returns string suitable for use in POSIX time zone string
   /*! Returns string formatted with up to 3 digits: 
    * Jan-01 == ""0"" 
    * Feb-29 == ""58""
    * Dec-31 == ""365"" */
   virtual std::string to_string() const
   {
     date_type d(2004, month_, day_);
     unsigned short c = d.day_of_year() - 1; // numbered 0-365 while day_of_year is 1 based...
     std::string ret;
     if (c/100) {
       ret += '0' + c/100;
       c = c%100;
     }
     if (c/10) {
       ret +=  '0' + c/10;
       c = c%10;
     }
     ret +=  '0' + c;
     return ret;
   }
}}}

Would you be likely to accept a patch that simply omits all the iostream-dependent API, if BOOST_NO_IOSTREAM is defined?

Is there a boost-friendly alternative to std::ostringstream?
",Nigel T Stewart <nigels@…>
2806,Link to cross-compile instructions from Getting Started,Getting Started Guide,Boost 1.38.0,Boost 1.39.0,Feature Requests,Dave Abrahams,new,2009-02-27T07:36:41Z,2009-02-27T12:16:06Z,"Every now and then someone asks for cross-compilation instructions on the boost mailing lists. I do cross-compilation occasionally, too, and would like to find the instructions with a few clicks rather than digging deep into the boost-build documentation. A newbie user wouldn't even know where to look for. Therefore, I suggest the Getting Started guide would link to http://www.boost.org/boost-build2/doc/html/bbv2/tasks/crosscompile.html",anonymous
2805,Add Documentation to Date_Time to Highlight a Pitfall,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-02-27T03:34:27Z,2009-02-27T03:34:27Z,"A note should be added to the Date_Time documentation to warn programmers of a pitfall in the use of the comparison operators. Comparison of a valid date with not_a_date_time may return an unexpected result. In the expression, ''date A < date B'' if A is a valid date and B is ''not_a_date_time'', a Boolean true is returned. A programmer may expect that any comparison of valid date with ''not_a_date_time'' always returns false. In some cases it will return true.

In the ''\libs\date_time\xmldoc\date_class.xml'' file in the Operator table of the Gregorian Date System section I suggest the following text.

''Warning: Some comparisons of valid dates and not_a_date_time will return true. See the \libs\date_time\test\gregorian\testdate.cpp program for illustrations of the comparisons.''

The tests for the various comparisons are included in a patch contained in Trac #2804.
",Charles Brockman <cmbrockman@…>
2804,Add Some Missing Items to the Date_Time Tests,date_time,Boost 1.38.0,Boost 1.39.0,Bugs,az_sw_dude,new,2009-02-27T03:30:07Z,2009-02-27T03:36:32Z,The attached patch adds five missing tests to ''\libs\date_time\test\gregorian\testdate.cpp'' program. They demonstrate a pitfall in the use of the Date_Time comparison operators.,Charles Brockman <cmbrockman@…>
2801,gregorian_calendar_base: incorrectly assumes that sizeof(int)==sizeof(long),date_time,Boost 1.38.0,To Be Determined,Bugs,"James E. King, III",assigned,2009-02-25T20:54:04Z,2018-01-18T14:19:55Z,"boost::date_time::gregorian_calendar_base() returns an int, but uses several local variables of type unsigned long, leading to warnings about possible loss of data when converting from unsigned long to int on 64 bit OSes that use the LP64 data model.

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

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

}}}
",pelee@…
2793,function types don't work for named template type parameters,parameter,Boost 1.38.0,Boost 1.39.0,Bugs,Daniel Wallin,new,2009-02-22T17:16:59Z,2013-01-30T02:19:47Z,"See this thread for a more detailed description:

http://www.nabble.com/-parameter--function-types-as-named-template-parameters--td21614543.html

Dave Abrahams posted a patch for this problem to the mailing list, I will attach it to this ticket.",Frank Mori Hess
2792,HP aCC rejects string_parse_tree <> in string_parse_tree.hpp,date_time,Boost 1.38.0,To Be Determined,Bugs,az_sw_dude,new,2009-02-22T10:11:13Z,2013-03-10T17:27:15Z,"When trying to use date_time's format_date_parser<> I get errors
on string_parse_tree<> template instantiation. The error message
says ""incomplete type is not allowed"", the exact compiler version 
is HP C/aC++ B3910B A.06.20.

The core reason for the error is that string_parse_tree<> includes
the definition of ""ptree_coll"" and several typedefs above it:

template<typename charT>
struct string_parse_tree {
   ...
   typedef std::multimap<charT, string_parse_tree > ptree_coll;
   ...
   typedef typename ptree_coll::value_type value_type;
   typedef typename ptree_coll::iterator iterator;
   ...
   ptree_coll m_next_chars;
   ..
};

AFAIK this is not guaranteed to work by the current C++ standard,
because string_parse_tree<> is, generally speaking, incomplete
at the point of instantiation of ptree_coll.

I asked at comp.lang.c++.moderated, and these are the replies:

http://groups.google.ru/group/comp.lang.c++.moderated/browse_thread/thread/f04915083b8f0f93/a11c78689cffb71b
",Max Zinal <MaxZinal@…>
2790,Executable bit is lost on windows builds.,Building Boost,Boost 1.45.0,To Be Determined,Feature Requests,Beman Dawes,new,2009-02-21T18:05:09Z,2011-11-08T15:48:56Z,"The windows releases of boost don't have the executable bit set for scripts, so they can't be run if extracted on file systems which support the unix permissions (e.g. for OS X and linux). I think it would be retained if built on such a system.",Daniel James
2781,Add python exception info extractor,python USE GITHUB,Boost 1.38.0,Boost 1.39.0,Patches,Dave Abrahams,new,2009-02-19T13:54:29Z,2018-01-22T06:34:57Z,"Something like this is useful when embedding python, and it took me almost an entire day to figure out how to do this. (Having not used boost::python before, I got many crashes when trying to extract data again.)

Example:
{{{
    try {
        boost::python::eval(...);
    } catch (boost::python::error_already_set&) {
        std::string msg = handle_pyerror();
        std::cerr << ""Error runnin python code: "" << msg;
    }
}}}

Implementation:

{{{
#!cpp
std::string handle_pyerror()
{
    using namespace boost::python;

    std::ostringstream os;
    os << ""Python error:\n  "" << std::flush;

    PyObject *type = 0, *val = 0, *tb = 0;
    PyErr_Fetch(&type, &val, &tb);
    handle<> e_val(val), e_type(type), e_tb(allow_null(tb));

    try {
        object t = extract<object>(e_type.get());
        object t_name = t.attr(""__name__"");
        std::string typestr = extract<std::string>(t_name);

        os << typestr << std::flush;
    } catch (error_already_set const &) {
        os << ""Internal error getting error type:\n"";
        PyErr_Print();
    }

    os << "": "";

    try {
        object v = extract<object>(e_val.get());
        std::string valuestr = extract<std::string>(v.attr(""__str__"")());
        os  << valuestr << std::flush;
    } catch (error_already_set const &) {
        os << ""Internal error getting value type:\n"";
        PyErr_Print();
    }

    if (tb) {
        try {
            object tb_list = import(""traceback"").attr(""format_tb"")(e_tb);
            object tb_str = str("""").attr(""join"")(tb_list);
            std::string str = extract<std::string>(tb_str);

            os << ""\nTraceback (recent call last):\n"" << str;
        } catch (error_already_set const &) {
            os << ""Internal error getting traceback:\n"";
            PyErr_Print();
        }
    } else {
        os << std::endl;
    }

    return os.str();
}
}}}

I'm sure it could be done better, but I'm sure this would help quite a bit.

A wrapper for all python calls that translated python errors into C++-exceptions with proper contents would be very nice, but I can live with this.",macke@…
2778,Request for forward declarations header,asio,Boost 1.38.0,To Be Determined,Feature Requests,chris_kohlhoff,new,2009-02-18T16:17:16Z,2010-01-12T22:23:01Z,"I'm trying to implement a library that does something over the network. It exposes an interface that allows to supply local and remote host addresses to work with. However, as ASIO is header-only and depends on system headers, such as windows.h, I don't want to force the users of my library to include the whole implementation of ASIO and the system headers by using my library interface.

A header with forward declarations of the most commonly used ASIO types could help me to achieve this goal. In particular, forward declarations of IP address classes would be helpful.
",Andrey Semashev
2776,[fix in git] Failed to wrap classes with virtual inheritance,python USE GITHUB,,Boost 1.39.0,Bugs,Dave Abrahams,new,2009-02-18T12:02:10Z,2009-09-25T04:46:45Z,"Hi!

I've just generated a wrapper for the simple classes with virtual function and virtual inheritance with Py++ and generated code is failed to compile. Without virtual inheritance everything is ok.

Error log is below, source and generated files are in attachment.

% c++ -I/usr/include/python2.5 -lboost_python -shared -o test.so test.cxx
/usr/include/boost/python/class.hpp: In static member function `static void boost::python::detail::error::virtual_function_default<T, Fn>::must_be_derived_class_member(const Default&) [with Default = void (Petq_wrapper::*)(), T = Petq_wrapper, Fn = void (Vasq::*)()]':
/usr/include/boost/python/class.hpp:565:   instantiated from `void boost::python::class_<T, X1, X2, X3>::def_default(const char*, Fn, const Helper&, mpl_::bool_<true>) [with Fn = void (Vasq::*)(), Helper = boost::python::detail::def_helper<void (Petq_wrapper::*)(), boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, W = Petq_wrapper, X1 = boost::python::bases<Vasq, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]'
/usr/include/boost/python/class.hpp:548:   instantiated from `void boost::python::class_<T, X1, X2, X3>::def_impl(T*, const char*, Fn, const Helper&, ...) [with T = Petq, Fn = void (Vasq::*)(), Helper = boost::python::detail::def_helper<void (Petq_wrapper::*)(), boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>, W = Petq_wrapper, X1 = boost::python::bases<Vasq, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]'
/usr/include/boost/python/class.hpp:608:   instantiated from `void boost::python::class_<T, X1, X2, X3>::def_maybe_overloads(const char*, Fn, const A1&, ...) [with Fn = void (Vasq::*)(), A1 = void (Petq_wrapper::*)(), W = Petq_wrapper, X1 = boost::python::bases<Vasq, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]'
/usr/include/boost/python/class.hpp:244:   instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def(const char*, A1, const A2&) [with A1 = void (Vasq::*)(), A2 = void (Petq_wrapper::*)(), W = Petq_wrapper, X1 = boost::python::bases<Vasq, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, X2 = boost::noncopyable_::noncopyable, X3 = boost::python::detail::not_specified]'
test.cxx:52:   instantiated from here
/usr/include/boost/python/class.hpp:146: error: pointer to member conversion via virtual base `Vasq'",Alexander Kogan <alexander@…>
2769,x86_64 + g++: wrong results for sin(),interval,Boost 1.34.1,,Bugs,Boris Gubenko,new,2009-02-17T17:41:19Z,2010-11-29T03:13:12Z,"When using boost's interval library under x86_64-Linux with g++ we encountered strange results for sin():
For example for an interval [-2.1,-2.1] sin() returns [nan,nan].",anonymous
2758,Move container_device right inside Iostreams library,iostreams,Boost 1.38.0,Boost 1.39.0,Feature Requests,Jonathan Turkanis,new,2009-02-13T09:38:07Z,2009-02-13T09:38:47Z,It will be useful to have container_source/sink/device classes (from libs/iostreams/example/container_device.hpp) right inside the Iostreams library.,anonymous
2746,Please allow specifying the library SONAME in Jamroot,build,Boost 1.38.0,Boost 1.39.0,Feature Requests,Vladimir Prus,assigned,2009-02-11T02:11:36Z,2009-11-09T18:03:08Z,"In working on packaging the luabind library (which utilizes Boost.Jam) for Debian, I found the way that the library SONAME is passed to the linker is not ""correct.""  It seems like since the SONAME is something that should ideally be managed by the library developer, it would be good if Boost.Jam allowed the library SONAME to be specified in the Jamroot file (for operating systems that have a notion of a SONAME).

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

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

Thanks to some help from volodya in IRC, we worked up the patch from the first message in the above thread.  However, I think that some sort of configuration variable, that if set, allowed specifying the SONAME would be better.  In the absence of the SONAME being specified in the Jamroot file, the current behavior could be kept as default.",roberto@…
2732,boost bjam install respects umask,build,Boost 1.37.0,Boost 1.38.0,Bugs,Vladimir Prus,assigned,2009-02-05T21:19:52Z,2009-11-10T08:17:53Z,"Using bjam to install boost 1.37 the install procedure respects the current umask of the user.

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

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

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

",gsauthof@…
2730,Boostbook might place many authors on one line?,Documentation,Boost 1.37.0,To Be Determined,Feature Requests,No-Maintainer,new,2009-02-05T12:22:26Z,2012-11-08T11:18:09Z,"I note that many Boost libraries have many authors.

For example the math library, where the seven authors (so far) are listed separately, half of page one is a list of authors, rather widely spaced.

The Boost.Traits library ducks the issue by saying 'various authors', but listing them all in the copyright.  This doesn't seem ideal.

(If we output bibliographic info in future, we also want to be sure that all authors are specified, so putting ""various authors"" will output ""various authors"" as the authors!)

So could the authors be better placed on one line?

(I also note that the  ""Distributed under the Boost Software
License, ..."" is in a larger font that I think it need to be?)

",Paul A. Bristow
2726,better control over error-handling in Accumulators,accumulator,Boost 1.37.0,To Be Determined,Feature Requests,Eric Niebler,new,2009-02-04T17:24:19Z,2009-02-04T17:24:19Z,"Ticket #2671 describes a scenario where accumulators causes an integral overflow. The simple solution there is to use doubles, but the larger issue is how to accommodate both fast, unchecked integral arithmetic and slower checked arithmetic. This is an open design issue, and it probably makes sense to come up with a uniform solution across all math-related libraries in Boost.
",Eric Niebler
2718,local_date_time noticeably faster than ptime,date_time,Boost 1.37.0,To Be Determined,Bugs,az_sw_dude,new,2009-02-03T09:14:18Z,2009-02-03T09:14:18Z,"We noticed recently that using a local_date_time in tight loops was several times faster than using a ptime object. As these are both based largerly on the same template code this was a surprise. It appears this is caused by the implementation of the operater+=/-= and was wondering if there was any justification for the difference or if this was just an oversight.

{{{
#!cpp
    //.\boost\date_time\local_time\local_date_time.hpp
    local_date_time_base operator+=(const time_duration_type& td)
    {
      this->time_ = time_system_type::add_time_duration(this->time_,td);
      return *this;
    }
}}}

{{{
#!cpp
    //.\boost\date_time\time.hpp
    time_type operator+=(const time_duration_type& td)
    {
      time_ = (time_system::get_time_rep(date(), time_of_day() + td));
      return time_type(time_);
    }
}}}

It looks like the ptime implementation is doing extra work to split the ptime into date and time_duration components and if it is changed to follow a similar pattern to that used in the local time the performance is then indistinguishable.

{{{
#!cpp
    //.\boost\date_time\time.hpp
    time_type operator+=(const time_duration_type& td)
    {
      this->time_ = time_system::add_time_duration(this->time_, td);
      return time_type(time_);
    }
}}}
I can only think that maybe this was done to work around an issue and in which case should the same then be applied to the local time implementation? 

[http://www.nabble.com/user/SendEmail.jtp?type=user&user=627065 email via nabble]",oneill1979
2692,No concepts supporting the idea of dense,uBLAS,Boost 1.37.0,To Be Determined,Feature Requests,Gunter,assigned,2009-01-28T20:51:45Z,2009-06-18T08:01:37Z,"data() returns a reference to a Storage.  However, nowhere in the concepts is a statement saying that &m.data()[0] must to be the address of the first element of the linearly stored data in the Storage.  The adjective ""dense"" is used all over, but nowhere is this term given any operational guarantees. Without such guarantees, all the interfaces in, say, the numerics::binding libraries are being built on sand.  Related to this is that nothing requires unbounded_array<T>::value_type to be T. The problem boils down to the ublas concepts documentation borrowing from the stl vector concepts which are general enough to support vector<bool>.  The basic (and inadequate) change is the sprinkling around of the word dense and the phrase ""strict linear order"".  Instead you need to explicitly says things like value_type is T and  &v[i+j] == &v[i]+j (for reasonable i+j).",dougrm@…
2676,CodeGear compile error when including utility/result_of.hpp,result_of,Boost 1.37.0,Boost 1.38.0,Bugs,Douglas Gregor,new,2009-01-23T18:45:24Z,2013-04-13T16:51:06Z,"CodeGear fails to compile utility/result_of.hpp instead of
gracefully degrading to the version for compilers without
ISO decltype --apparently CodeGear has a decltype which is
not ISO conformant, leading to the problem.

See complete discussion at http://lists.boost.org/Archives/boost/2009/01/147163.php

Daniel Walker provides a patch for this problem (attached.)
I'm initially assigning this to Doug Gregor, but Daniel is
CCed just in case he wants to reassign to himself.",Joaquín M López Muñoz
2674,request to make BOOST_PARAMETER_MAX_ARITY re-defineable,parameter,Boost 1.37.0,Boost 1.38.0,Feature Requests,Daniel Wallin,new,2009-01-23T14:59:29Z,2014-10-30T19:14:38Z,"I'd like to be able to increase BOOST_PARAMETER_MAX_ARITY in my library header if needed, and then include the Boost.Parameter library without worrying that the user might have already included Boost.Parameter headers and thus made my attempt to increase the max arity futile.  I believe the Boost.Function library has this feature.  My use case is trying to apply Boost.Parameter to the boost::signals2::signal class, which currently has 7 template type parameters (but BOOST_PARAMETER_MAX_ARITY defaults to 5).",Frank Mori Hess
2660,`fd_set' has not been declared,xpressive,Boost.Build-M3,Website 1.X,Library Submissions,az_sw_dude,reopened,2009-01-16T12:13:14Z,2015-04-12T13:21:53Z,"I'm using Boost.Thread and Boost.Asio on Cygwin.

If I include boost/thread.hpp, without boost/asio.hpp first,
I get a compiler error:

In file included from /usr/include/cygwin/sys_time.h:13,
                 from /usr/include/sys/time.h:27,
                 from D:/local/boost/include/boost-1_37/boost/date_time/c_time.hpp:28,
                 from D:/local/boost/include/boost-1_37/boost/date_time/microsec_time_clock.hpp:18,
                 from D:/local/boost/include/boost-1_37/boost/thread/thread_time.hpp:9,
                 from D:/local/boost/include/boost-1_37/boost/thread/locks.hpp:12,
                 from D:/local/boost/include/boost-1_37/boost/thread/pthread/mutex.hpp:11,
                 from D:/local/boost/include/boost-1_37/boost/thread/mutex.hpp:16,
                 from D:/local/boost/include/boost-1_37/boost/thread/pthread/thread_data.hpp:12,
                 from D:/local/boost/include/boost-1_37/boost/thread/thread.hpp:17,
                 from D:/local/boost/include/boost-1_37/boost/thread.hpp:13,
                 from src/flightpath_controller.cpp:27:
/usr/include/sys/select.h:31: error: `fd_set' has not been declared
/usr/include/sys/select.h:31: error: `fd_set' has not been declared
/usr/include/sys/select.h:31: error: `fd_set' has not been declared
/usr/include/sys/select.h:33: error: `fd_set' has not been declared
/usr/include/sys/select.h:33: error: `fd_set' has not been declared
/usr/include/sys/select.h:33: error: `fd_set' has not been declared
make: *** [build/flightpath_controller.o] Error 1

A workaround for this issue is to include boost/asio.hpp before
boost/thread.hpp within the given sourcefile.

",jens.luedicke@…
2640,Legal forward iterators cannot store their referents (was: counting_iterator::reference lifetime tied to iterator),iterator,Boost 1.37.0,Boost 1.38.0,Bugs,jeffrey.hellrung,new,2009-01-05T20:54:53Z,2014-09-30T15:34:14Z,"The iterators library needs a redesign based on the facts noted in [[#comment:2|this comment]]

The original report is below.

----



Currently, counting_iterator<T>::reference is Incrementable const&. This makes reverse_iterator< counting_iterator<T> >::dereference return a reference to a temporary variable:

typename super_t::reference dereference() const { return *boost::prior(this->base()); }

The problem is that iterator::reference is expected to stay valid even if the iterator it was obtained from is dead.",schoedl
2635,date_time input_facet formatting,date_time,Boost 1.37.0,Boost 1.38.0,Bugs,az_sw_dude,new,2009-01-05T13:02:35Z,2009-01-05T19:36:24Z,"Hi,

I've found a problem with the input_facet formating. The following format:
""%Y-%m-%d""
causes that the date: ""1999-1-01"" is allowed, but shouldn't be (month has to be in 2-digit format). See attached main.cpp file. It's a unit test clearly describing the problem. Tested on gcc 3.3.6 and 4.3.1.
",tmmikolajczyk@…
2628,Sequence concept incorrectly fails for basic_string,concept_check,Boost 1.37.0,Boost 1.56.0,Bugs,acharles,assigned,2009-01-01T03:38:48Z,2014-02-21T09:24:23Z,"The Sequence concept fails when tested against basic_string (e.g. BOOST_CONCEPT_ASSERT((Sequence<T>)); ) because an extra constructor test is included.  This test is for X a(n) where n is the size of the sequence to be created.  However, section 23.1.1 table 67 of the C++ standard does not include this test in the definition of the Sequence concept.  Because this test is in place, basic_string is rejected by the current implementation of the Sequence concept, since basic_string does not have this constructor.  However, section 21.3 paragraph 2 of the C++ standard states, ""The class template basic_string conforms to the requirements of a Sequence, as specified in (23.1.1).""

The fix for this should be as simple as removing the test for a constructor of the form X a(n) in the Sequence concept implementation.",Joel Lathrop <jal6806@…>
2565,posix_chat_client.cpp does not work on mac os x,asio,Boost 1.37.0,To Be Determined,Bugs,chris_kohlhoff,reopened,2008-12-04T21:38:50Z,2010-01-12T22:43:49Z,"I am using Mac OS X 10.5 (Leopard), macbook pro and this example seems to be broken.

when I run

./chat_server 12345

and in a different terminal on the same machine run

./posix_chat_client localhost 12345

the client exits immediately (instead of accepting input to send to the server which echos is back).

the chat_client works fine however.
Note that the source is in boost/libs/asio/examples/chat

In similar code I get the error ""Operation not supported""

This same code works on linux (ubuntu 4.3.2) just fine.  Same build flags.

",kyle.tarplee@…
2557,iostreams filtering_stream w/ gzip infinite loop when writing to a full drive,iostreams,Boost 1.55.0,Boost 1.38.0,Bugs,Jonathan Turkanis,assigned,2008-12-01T19:27:03Z,2017-07-12T12:45:47Z,"When a filtering_stream with a gzip_compressor is used to write to a full hard drive (i.e. insufficient free space), boost enters an infinite loop in /boost/iostreams/detail/adapter/non_blocking_adapter.hpp:41 because the write function keeps returning zero. This loop happens during the destruction of the stream. I can't seem to find a client-side workaround.

Attached is a test case, point it to a volume with zero space and give some large number of bytes. If there's insufficient space, execution hangs. Tested on mingw/winxp/gcc4.2 but seems to fail on linux/gcc as well.",Tomasz Śniatowski <kailoran@…>
2555,"SIGTRAP received while calling a wrapped function with """"",python USE GITHUB,Boost 1.36.0,Boost 1.38.0,Bugs,Dave Abrahams,reopened,2008-12-01T16:00:35Z,2008-12-23T09:20:15Z,"We have a function that takes a std::string in parameter, and we wrap it using Boost.Python:

void foo(string s)
{
    cout << ""foo"" << endl;
}

BOOST_PYTHON_MODULE(mymodule)
{
    def(""foo"", &foo);
}


When we call it under gdb, we receive a SIGTRAP signal (see attachment). Note that the problem disappears if the std::string is replaced by a const char* or if we pass a non-empty literal string. Also, it only appears under gdb, a normal run won't make the program crash.

Here are the different platforms tested:
 * win32 - python2.2.3 - gcc3.4.5      - boost1.35 - gdb6.8     : KO
 * win32 - python2.5.2 - gcc3.4.5      - boost1.35 - gdb6.8     : KO
 * win32 - python2.5.2 - gcc3.4.5      - boost1.36 - gdb6.8     : KO
 * win32 - python2.5.2 - gcc4.2.1-sjlj - boost1.36 - gdb6.8     : KO
 * redhat 7.2 - python2.4.  - gcc3.3.6 - boost1.35 - gdb5.0     : OK
 * ubuntu 8.10 - python2.5.2 - gcc4.3.2 - boost1.35 - gdb6.8: OK

So the problem seems to be reproducible only with win32.

Bruno",bruno dot lalande at gmail dot com
2539,advance() and distance() for new iterator concepts,iterator,Boost 1.37.0,Boost 1.38.0,Bugs,jeffrey.hellrung,new,2008-11-26T15:42:24Z,2016-02-22T02:25:30Z,"I can't find a trace of a problem submitted by Sebastian Redl last year :
http://lists.boost.org/Archives/boost/2007/09/127785.php

In brief, the std version of advance() and distance() functions does not dispatch accordingly to the traversal_tag. For instance a transform_iterator is categorized as std::input_iterator_tag, boost::random_access_traversal_tag and the chosen distance() implementation is O(n) while O(1) is expected.

The patch suggested by Sebastian works fine. The only thing is that names collides with Boost.Range (which already have boost::distance).",debionne@…
2522,iostreams/stream_offset_64bit_test fails on QNX 6.4.0,iostreams,Boost Development Trunk,Boost 1.38.0,Bugs,Jonathan Turkanis,new,2008-11-21T11:13:26Z,2008-11-21T11:13:26Z,"...with the Dinkumware 5 library.

It fails on the first iteration and reports this:[[BR]]
* sizeof(fpos_t) = 16[[BR]]
* sizeof(streamoff) = 4[[BR]]
* sizeof(stream_offset) = 8[[BR]]
...

The constructor of std::streampos (fpos<_Mbstatet>) puts the value in a streamoff so the most significant 32 bits get chopped off.

Defining BOOST_IOSTREAMS_HAS_DINKUMWARE_FPOS results in this:[[BR]]
positioning.hpp: In function 'std::streampos boost::iostreams::offset_to_position(boost::iostreams::stream_offset)':[[BR]]
positioning.hpp:52: error: no matching function for call to 'std::fpos<_Mbstatet>::fpos(std::mbstate_t, boost::iostreams::stream_offset&)'[[BR]]
iosfwd:32: note: candidates are: std::fpos<_Statetype>::fpos(_Statetype, std::fpos_t) [with _Statetype = _Mbstatet][[BR]]
iosfwd:27: note:                 std::fpos<_Statetype>::fpos(std::streamoff) [with _Statetype = _Mbstatet][[BR]]
iosfwd:23: note:                 std::fpos<_Mbstatet>::fpos(const std::fpos<_Mbstatet>&)

std::fpos_t is defined like this:[[BR]]
struct _Fpost {[[BR]]
 _Off64t _Off;[[BR]]
 _Mbstatet _Wstate;[[BR]]
}

I wrote this simple test:[[BR]]
std::fpos_t fpos = { 100000000000LL, std::mbstate_t() };[[BR]]
std::streampos pos(std::mbstate_t(), fpos);[[BR]]
std::cout << _FPOSOFF(pos.seekpos()) << std::endl;

It prints 100 billion. Is there a better way to initialize fpos_t? I'm not sure it's correct to use the default value for mbstate_t  but offset_to_position() currently does it.",Niklas Angare <li51ckf02@…>
2515,[MSVC] ambiguous symbol type_info in boost/python tests,python USE GITHUB,Boost Development Trunk,Boost 1.38.0,Bugs,Dave Abrahams,new,2008-11-19T10:32:17Z,2008-11-19T10:32:17Z,"The most of the boost/python tests are failed to compile on MSVC with Apache stdcxx library.

[http://tinyurl.com/6hdez7 example 1]
[http://tinyurl.com/5wywqb example 2]

The reason is that <eh.h> header contains declaration of the:

{{{
int _is_exception_typeof(const type_info &, _EXCEPTION_POINTERS *) ;
}}}

<eh.h> header is included in libs/python/test/module_tail.cpp file. The module_tail.cpp is included in other pythons tests at the end of file after introducing boost::python symbols in global namespace.

That tests are compiled successfully on MSVC without stdcxx due to <eh.h> implicitly included thus <exception> header (before ""using namespace boost::python;"" directive). But any of the stdcxx headers are not including the <eh.h> (see [http://svn.boost.org/trac/boost/ticket/1599 ticket 1599]).

The possible solution is explicitly include <eh.h> in every test, that includes module_tail.cpp.

Another solution:

{{{
Index: module_tail.cpp
===================================================================
--- module_tail.cpp	(revision 49830)
+++ module_tail.cpp	(working copy)
@@ -13,7 +13,9 @@
 # endif
 
 # ifdef _MSC_VER
+#  define type_info ::type_info
 #  include <eh.h> // for _set_se_translator()
+#  undef type_info
 #  pragma warning(push)
 #  pragma warning(disable:4297)
 #  pragma warning(disable:4535)
}}}
",Farid Zaripov <faridz@…>
2487,Calculate the mlp::and_ or mpl_or of a sequence of nullary logical metafunctions.,mpl,Boost 1.36.0,Boost 1.38.0,Feature Requests,Aleksey Gurtovoy,new,2008-11-08T22:41:27Z,2010-06-12T16:46:25Z,"Do you think that these two metafunctions have a place in mpl?

template <typename Seq>
struct and_seq : boost::is_same<typename mpl::find_if<Seq, mpl::not_<mpl::_> >::type, 
										 typename mpl::end<Seq>::type> 
				 {};

template <typename Seq>
struct or_seq : mpl::not_<boost::is_same<typename mpl::find_if<Seq, mpl::_>::type, 
										 typename mpl::end<Seq>::type> 
				> {};

I have attached the code and the tests.",vicente.botet@…
2482,msvc-9.0 unreferenced formal parameter warning when using boost::breadth_first_visit,concept_check,Boost Release Branch,Boost 1.38.0,Patches,jsiek,new,2008-11-06T21:36:19Z,2014-05-21T10:22:34Z,"Boost. 1.37.0 (maybe earlier) and Boost.Trunk trigger msvc "" warning C4100: 'b' : unreferenced formal parameter"" in concept_check.hpp(144) and in concept/detail/msvc.hpp(21) : warning C4100: 'x' : unreferenced formal parameter.

Full obfuscated template instation stack attached.

I've attached our patch against 1.37.0, a patch against current trunk for msvc.hpp and a patch showing that trunk and release version of boost/concept_check.hpp are different.
",Jürgen Hunold
2473,unsigned integers going into interval of doubles get wrongly negated,interval,Boost Development Trunk,Boost 1.38.0,Bugs,Boris Gubenko,new,2008-11-04T13:12:14Z,2009-04-02T22:36:44Z,"interval<double> x(1U) gets wrong lower bound (-2**32+1 instead of 1). Apparently, the unary - operation is performed on the unsigned int instead of the double.

Workaround: manually cast to double before creating the interval.",David Monniaux <David.Monniaux@…>
2448,syntax highlighting for code in documentation or website,Documentation,Boost Development Trunk,Website 1.X,Feature Requests,Daniel James,assigned,2008-10-29T19:56:48Z,2009-02-21T17:15:22Z,"In Boost documentation there are a lot of code examples which it would be better if it will be with syntax highlighting to be more readable.
",hagai26@…
2438,gcc.jam sets LD_LIBRARY_PATH which breaks FreeBSD build,build,Boost Development Trunk,Boost 1.42.0,Bugs,Vladimir Prus,assigned,2008-10-27T16:57:06Z,2010-01-11T17:10:44Z,"In build/tools/v2/tools/gcc.jam we are setting the LD_LIBRARY_PATH for compilation to:

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

Couple of points:

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

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

Thread:

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

If it is decided to set LD_LIBRARY_PATH then we need to make this OS specific and unset it for FreeBSD (or minimally add back /lib which Steven pointed out in the above thread is probably not the right solution given LD_LIBRARY_PATH's semantics).",pisymbol@…
2433,bjam should honor include paths order,build,Boost Development Trunk,To Be Determined,Feature Requests,Vladimir Prus,new,2008-10-25T13:47:32Z,2011-11-23T18:49:55Z,"Currently bjam does not honor include paths and sorts things alphabetically as an speed optimization (I believe it has to do with comparing sets of paths for equivalence).  In reality, bjam should honor include path order not only within a <include> attribute but also within a project hierarchy itself.

Here is a great thread with a lot of good discussion about the issue and what I have in mind for bjam:

http://www.nabble.com/Sorting-include-headers-td19995752.html
",pisymbol@…
2430,shared_mutex for win32 doesn't have timed_lock_upgrade,thread,Boost 1.36.0,To Be Determined,Feature Requests,viboes,reopened,2008-10-22T19:43:10Z,2013-01-19T11:06:19Z,"The shared_mutex in boost/thread/win32/shared_mutex.hpp doesn't provide timed_lock_upgrade method while the POSIX counterpart does. Applies to 1.36, 1.37 (release in SVN) and trunk.",Andrey.Semashev@…
2426,Error in documentation for boost::python indexing suite,python USE GITHUB,Boost 1.44.0,To Be Determined,Patches,Dave Abrahams,new,2008-10-21T14:27:45Z,2010-10-30T12:33:52Z,"The documentation for boost::python indexing suite at http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/indexing.html claims the headers are in <boost/python/indexing/indexing_suite.hpp>. When I unpack boost_1_36_0 I get <boost/python/suite/indexing/vector_indexing_suite.hpp> (note boost/python/***suite***/...

Robert",rswanca@…
2400,Messages corrupted if isend requests are not retained,mpi,Boost 1.36.0,Boost 1.37.0,Feature Requests,Matthias Troyer,reopened,2008-10-09T21:16:30Z,2013-01-01T10:59:07Z,"If I do a series of isends and discard the request objects (because I don't need to know when they complete), the messages can get corrupted. I realize this is the way the MPI library is designed, but I'm wondering if it possible to use some C++ goodness to make the request objects persist behind-the-scenes until the request is completed? The behavior is particularly unexpected in the Python layer. Thanks very much!

",dwchiang@…
2399,Python boost.mpi.Request.test() crashes,mpi,Boost 1.36.0,Boost 1.37.0,Bugs,Douglas Gregor,reopened,2008-10-09T21:02:05Z,2009-08-07T17:05:55Z,"With the addition of the request_with_value type, the wrapper for request::test() was broken (can't convert optional<status> to Python type). A fix:

{{{
const object request_test(request &req)                                         
{                                                                               
  ::boost::optional<status> stat = req.test();                                  
  if (stat)                                                                     
    return object(*stat);                                                       
  else                                                                          
    return object();                                                            
}                                                                               
                  
}}}

and change the wrapper for Request to use &request_test instead of &cl::test.
",dwchiang@…
2348,const qualified return value in iterator_facade,iterator,Boost 1.36.0,Boost 1.37.0,Bugs,jeffrey.hellrung,new,2008-09-19T17:09:15Z,2012-11-21T19:41:56Z,"This is a very minor thing:

The line:

{{{
boost::indirect_iterator<const int* const *> it;
}}}

creating a iterator for constant iteration through a container of constant pointers creates a warning

""boost/iterator/iterator_facade.hpp:653: warning: type qualifiers ignored on function return type""

obviously this is not the way to fix it, but changing this line to
typename remove_const<typename boost::detail::operator_brackets_result<Derived,Value,reference>::type>::type
solves the problem.
",brian.tyler@…
2331,Boost.Parameter -- oveloading on keyword signature,parameter,Boost 1.35.0,Boost 1.37.0,Bugs,Daniel Wallin,new,2008-09-16T20:10:19Z,2008-09-17T20:56:11Z,"This bug was described in the users mailing list:

http://www.nabble.com/overloading-on-keyword-signature-td19503100.html

I used gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
",e_r
2326,"Library does not directly support serializing data of type  ""foo**""",serialization,Boost 1.36.0,Boost 1.37.0,Bugs,Robert Ramey,assigned,2008-09-15T03:40:34Z,2008-09-18T15:44:22Z,"The following example fails to compile, trying to find a .serialize() member function in an int*. Clearly the user can program around this, but serializing pointers-to-pointers seems a natural capability that should be in the library.

#include    <fstream>

#include    ""boost/archive/text_oarchive.hpp""

class       foo {

   friend class boost::serialization::access;

   template<class archive>

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

                   ar & BOOST_SERIALIZATION_NVP(buff);

                   ar & BOOST_SERIALIZATION_NVP(ptr);

                   }

public:

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

   int*        buff[10];

   int**       ptr;

   };

int main() {

       foo f;

       std::ofstream   serial(""serial"");

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

       oa << BOOST_SERIALIZATION_NVP(f);

       return 0;

       } ",anonymous
2319,"function::operator= should ""move"", copy assignment should have by-value argument",function,Boost 1.36.0,Boost 1.37.0,Bugs,Douglas Gregor,new,2008-09-11T16:11:21Z,2012-09-05T20:28:52Z,"A few days ago, I added a comment to ticket #1910 (regarding function::swap), suggesting to have boost::function's assignment operators calling its new ''move_assign'' member function, instead of calling ''swap''. Doing so would significantly improve its performance.

Now I think that function::operator= deserves its own ticket, especially because the ''copy assignment'' of boost::function can be improved even more, by having its argument passed ''by value'', instead of creating a copy of the argument inside the body of the function. Doing so would allow the compiler to do copy elision, when its argument is an rvalue. See also [http://lists.boost.org/Archives/boost/2008/09/142106.php Improving the assignment operators of various Boost types]

So please consider the attached patch.

",niels_dekker
2314,Finish intrusive_ptr_test.cpp,smart_ptr,Boost 1.36.0,To Be Determined,Bugs,Peter Dimov,new,2008-09-10T11:05:51Z,2011-02-24T22:06:43Z,"intrusive_ptr_test.cpp is incomplete and unfinished; it's missing, among other things, assignment tests, needed for #2312.",Peter Dimov
2312,intrusive_ptr::operator=  should have by-value argument,smart_ptr,Boost 1.36.0,To Be Determined,Patches,Peter Dimov,new,2008-09-10T09:16:41Z,2011-02-24T22:11:26Z,"When a copy assignment operator is implemented simply by doing copy-and-swap, it should pass its argument by value, instead of doing the copy inside the body of the function, to allow the compiler to do copy elision. As was discussed at the Boost developer mailing list, [http://lists.boost.org/Archives/boost/2008/09/142106.php Improving the assignment operators of various Boost types].

So please consider the attached patch.",niels_dekker
2297,Workaround for GCC bug,mpl,Boost 1.36.0,Boost 1.37.0,Patches,Aleksey Gurtovoy,new,2008-09-08T02:02:31Z,2011-04-11T08:28:20Z,"This patch works around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28088,
simplifies the code, and ''ought'' to speed up compilation a bit into the
bargain by instantiating fewer templates.  However, whether it breaks on any
compilers other than GCC remains to be seen.

Preprocessed headers need to be regenerated, of course.

",Dave Abrahams
2289,Problem with BOOST_AUTO and this keyword on VC8/9,typeof,Boost 1.51.0,Boost 1.37.0,Bugs,Peder Holt,new,2008-09-05T10:57:15Z,2012-09-10T14:52:19Z,"On both VC8SP1 and VC9SP1, the code

{{{
struct foo
{
	int i;

	foo::foo()
	{
		BOOST_AUTO(j, this->i);
	}
};
}}}


results in the compiler error

{{{

error C2355: 'this' : can only be referenced inside non-static member functions
error C2227: left of '->i' must point to class/struct/union/generic type

error C2955: 'boost::type_of::msvc_typeid_wrapper' : use of class template requires template argument list
        e:\boostsvn\boost\typeof\msvc\typeof_impl.hpp(209) : see declaration of 'boost::type_of::msvc_typeid_wrapper'
}}}

In both cases, changing it to simply BOOST_AUTO(j, i); allows it to compile.

The foreach lib used to have a similar problem (Ticket #1652), possibly down to the same compiler bug?",Richard Webb <Richard.Webb@…>
2287,pi test runtime failures,interval,Boost 1.35.0,Boost 1.37.0,Bugs,Guillaume Melquiond,new,2008-09-05T02:11:35Z,2008-09-14T08:58:52Z,"On Suse Linux Enterprise Server 10, with the default installed gcc-4.0.1,
I am getting the following errors:

{{{
/zorak/sles/boost_1_35_0/libs/numeric/interval/test/pi.cpp(37): test subset(pi_f, widen(I_f((float) PI), (std::numeric_limits<float> ::min)())) failed in function: 'int test_main(int, char**)'
/zorak/sles/boost_1_35_0/libs/numeric/interval/test/pi.cpp(38): test subset(pi_d, widen(I_d((double)PI), (std::numeric_limits<double>::min)())) failed in function: 'int test_main(int, char**)'
}}}

My bjam command-line is:
{{{
#!/sh
~/bin/bjam -sHAVE_ICU=1 -sEXPAT_INCLUDE=/usr/include -sEXPAT_LIBPATH=/usr/lib64 --debug-configuration -j4 release --build-dir=/zorak/sles/build cxxflags=-Wno-non-virtual-dtor
}}}

Even if there is no immediate fix, an explanation would be helpful.  Thanks!",Dave Abrahams
2262,BOOST_MPL_ASSERT_MSG producing linking problems in MSVC++ 8.0,mpl,Boost Development Trunk,Boost 1.37.0,Bugs,Aleksey Gurtovoy,new,2008-08-26T15:43:22Z,2013-04-19T02:16:07Z,"Steps to reproduce the problem:

* Create a basic console project in Visual Studio 2005[[BR]]
* Include files foo1.cpp and foo2.cpp[[BR]]
* Build; the following error shows up at linking time:[[BR]]

{{{
>Linking...
>foo2.obj : error LNK2005: ""public: static struct boost::mpl::failed
 * * * * * * * * * * * * (__thiscall `bool __cdecl f<int>(void)'::`2'
::ALWAYS_TRUE::** * * * * * * * * * * __cdecl `bool __cdecl f<int>
(void)'::`2'::ALWAYS_TRUE0::assert_arg(void))(int)"" 
(?assert_arg@ALWAYS_TRUE0@?1???$f@H@@YA_NXZ@SAPAPAPAPAPAPAPAPAPAPAPAP8
ALWAYS_TRUE@?1???$f@H@@YA_NXZ@AEPAPAPAPAPAPAPAPAPAPAPAPAUfailed@mpl@boost@@H@ZXZ)
already defined in foo1.obj
}}}
",Joaquín M López Muñoz
2258,Test annotation problems,function_types,Boost 1.36.0,Boost 1.37.0,Bugs,t_schwinger,new,2008-08-25T21:50:03Z,2008-08-25T21:51:01Z,"With x86 linux gcc-4.0.1, I get this for the member_ccs test:

  member_ccs.cpp:17:5: error: #error ""test not supported with this compiler/platform""

and the test is annotated thusly:

  Not all compilers/platforms implement nonstandard calling conventions.

  With GCC/x86 this failure reflects
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29328 .

But the nonme the nonmember_ccs test *also* fails with the same error,
and this annotation:

  Not all compilers/platforms implement nonstandard calling conventions.

i.e. there is no reference to a GCC bug.

Points:

 * The error message for member_ccs is inconsistent with the note about the
  gcc bug.  

 * The function types library documentation barely mentions ""calling
  conventions"" and doesn't explain what ""nonstandard"" means in this
  context.  For example, does extern ""C"" count?

 * Since I am running x86/GCC, the note about the GCC bug much more
  specific than the other part of the note, so I assumed that it
  applied. That would mean that my platform implements a nonstandard
  calling convention, but a compiler bug is causing the test to fail.

 * However, that interpretation would be inconsistent with the annotation
  for nonmember_ccs.

 * I suspect that my platform does not support nonstandard calling
  convention, and the bug only applies on platforms where GCC supports
  nonstandard calling conventions (e.g. Windows), and does not apply to
  me.  If so, the annotation should be more specific about the platforms
  on which the note applies.

 * The error message should be better, e.g.: ""this platform does not
  support nonstandard calling conventions; the test is irrelevant here""

 * A test that always succeeds when the platform doesn't support
  nonstandard calling conventions would yield far more reliable results
  than the overly general wildcard matching of failure annotations you
  have now, which makes a failure on any platform look as though it were
  expected in the testing chart.

(Also posted to the boost list because I want to start a discussion about test markup there)",Dave Abrahams
2256,Function/signals needs ABI prefix and suffix headers,function,Boost 1.36.0,Boost 1.37.0,Bugs,Douglas Gregor,new,2008-08-25T18:22:34Z,2008-08-25T18:22:34Z,"Both Boost.Function and Boost.Signals need to include the ABI prefix and suffix headers in the appropriate places, to cope with projects that use non-default alignments.",Douglas Gregor
2252,Doc or design problem,function_types,Boost 1.36.0,Boost 1.37.0,Bugs,t_schwinger,new,2008-08-25T07:25:37Z,2008-08-25T07:25:37Z," The library is designed to work well with other Boost libraries and uses well-accepted concepts introduced by Boost and TR1.

 Templates that encapsulate boolean or numeric properties define a static member constant called value.

 {{{
 is_function_pointer< bool(*)(int) >::value // == true 
 function_arity< bool(*)(int) >::value // == 1
 }}}

The problem is that having a nested static member constant called value is neither necessary nor sufficient to work with MPL.  The  approach that makes it work the most smoothly would derive the template specialization from an [http://www.boost.org/doc/libs/1_36_0/libs/mpl/doc/refmanual/integral-constant.html: MPL Integral Constant], but at ''least'' you need a nested {{{::type}}} member.",Dave Abrahams
2249,MPL::switch_ not working and not documented,mpl,Boost 1.36.0,Boost 1.37.0,Bugs,Aleksey Gurtovoy,new,2008-08-23T15:43:11Z,2012-10-30T17:45:13Z,"Seems the current swich_ implementations uses lambda<> where it shouldn't. Moreover, there is no documentation for switch_.

Here's a link to a working code with added default_ and case_ meta-functions (for purely cosmetic feature, remove if uneeded).

http://codepad.org/OOZ7riiy

Here's a link to a sample usage.
http://codepad.org/Vho6k97u",Joel Falcou <joel.falcou@…>
2240,Move placeholders into the boost::placeholders namespace,bind,Boost Development Trunk,To Be Determined,Tasks,Peter Dimov,new,2008-08-21T15:22:31Z,2014-01-29T16:41:46Z,,Peter Dimov
2232,Documentation build needs to detect missing prerequisites,Documentation,Boost 1.36.0,To Be Determined,Feature Requests,No-Maintainer,new,2008-08-20T11:04:05Z,2013-04-28T14:11:49Z,"Building documentation requires a lengthy tool chain to work correctly.

The following tools have to be installed:

     libxml2, libxslt, doxygen, docbook-xml42, docbook-xsl, tetex (?), ghostscript

user-config.jam needs to supply usings for:

     xsltproc,
     boostbook with docbook-xsl and docbook/4.2,
     doxygen,
     quickbook
     
Experience has shown that (1) even very experienced Boost developers can have missing tool chain items, and (2) missing tool chain items are very difficult to diagnose and repair because the current bjam setup does not issue meaningful error messages, produces partial documentation, and gives the appearance of working.

The requested fix is twofold:

*  Specific error messages should be issued if the tool chain is not complete. The messages should distinguish between tools not being installed and user-config.jam not having all the required entires. The error messages should name the specific missing tool or missing user-config.jam entry.

*  If one of the above errors is detected, the process should stop at that point. Currently partial documentation is built, and that can be very misleading and time-consuming. If the tool chain is wrong, nothing at all should be built.",Beman Dawes
2215,Using of accumulators in paralled computation,accumulator,,To Be Determined,Feature Requests,Eric Niebler,new,2008-08-18T14:41:06Z,2008-08-18T14:41:06Z,"In the time of multicore processors and Thread Building Blocks at hand, it would be nice to be able to use accumulators in parallel computations.

To do so, one would need to combine partial computations. In other words,we need accumulator_set::combine(). This would combine the partial computation state from another accumulator_set.

This operation would enable the accumulators to be used with parallel_reduce.
",Pavol Droba
2179,add support for weak_ptr,python USE GITHUB,Boost 1.35.0,Boost 1.36.0,Bugs,Dave Abrahams,new,2008-08-09T02:44:28Z,2013-04-19T06:03:05Z,"Today shared_ptr works very well, but it makes it difficult for the C++ application to retain control over the lifetime of its objects. Variables in the interpreter which are hard to clear can prevent an object from being deleting.

weak_ptr support would be the ideal solution. A application could hand out only weak_ptrs to Python.  The object could then be deleted as normal.  

Attempting to use a weak_ptr in Python if the object has been released should throw.  Python code which knows its objects might be deleted out from under it can catch this exception.

See thread w/ Dave Abrahams titled ""application exit and shared_ptr"" in C++-sig.",pwinston@…
2150,Inspect needs to check for missing files,inspection script,Boost 1.35.0,Boost 1.37.0,Feature Requests,Beman Dawes,assigned,2008-07-28T14:51:59Z,2013-01-03T19:10:48Z,"Objective: Report missing files early enough to take corrective action before a crisis develops. Include generated doc files in the lists searched for.

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

See attached file for possible ""required_files.txt"" format.",Beman Dawes
2142,[fix in git] Patch for boost.python - return_pointee_value,python USE GITHUB,Boost Development Trunk,Boost 1.36.0,Patches,troy d. straszheim,new,2008-07-23T08:07:40Z,2009-10-24T04:57:21Z,"The patch adds the return value policy return_pointee_value, which can be nicely used for functions that return pointers to non-exposed objects. I wrote documentation, the header and testcases.[[BR]]


There are some issues:
- The test cases are not integrated into the Jamfile in the tests-directory (I dont know bjam very well).[[BR]]
- I dont know, wether the tests are OK the way they are done.[[BR]]
- I did not add an #include directive to any boost-python header. But some header should include the <boost/python/return_pointee_value.hpp>, but I dont know which one. ",Maximilian Matthe <Maxi.Matthe@…>
2138,Windows test cases need to include \\?\ and \\.\ prefixes,filesystem,Boost 1.35.0,Boost 1.37.0,Feature Requests,Beman Dawes,new,2008-07-22T14:54:39Z,2008-07-22T15:01:35Z,"See Naming a Volume docs, http://msdn.microsoft.com/en-us/library/aa365248(VS.85).aspx, for information about \\?\ prefixes.

See CreateFile() docs, http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx, for information about \\.\ prefixes. ",Beman Dawes
2135,Biggest integral types for value-based template arguments,integer,Boost Development Trunk,To Be Determined,Feature Requests,Daryle Walker,new,2008-07-22T05:22:52Z,2008-07-22T05:23:12Z,"This is based on the post at <http://lists.boost.org/Archives/boost/2008/07/139965.php>:

The `boost::intmax_t` and `boost::uintmax_t` types in ""[source:trunk/boost/boost/cstdint.hpp@32397 boost/cstdint.hpp]"" alias the largest built-in signed and unsigned integer types.  They should be the special 64-bit types, (`unsigned`) `long long` or` __int64`, on systems that support 64-bit registers (and no higher).  However, the `BOOST_NO_INTEGRAL_INT64_T` preprocessor flag warns when these types are not suitable as integral constant expressions.  Therefore, there needs to be types that indicate the largest integral types still suitable in integral constant expressions.",Daryle Walker
2129,iterator problem in ublas::basic_range (boost/numeric/ublas/storage.hpp),uBLAS,Boost 1.35.0,To Be Determined,Feature Requests,Gunter,new,2008-07-19T19:26:41Z,2008-07-29T20:06:07Z,"Decrementing (--) a forward iterator through a basic_range containing negative values throws an error (bad_index). This seems inconsistent because it is possible to increment (++) through such a range without throwing error.

lines 937 - 941 of boost/numeric/ublas/storage.hpp read

{{{
const_iterator &operator -- () {
  BOOST_UBLAS_CHECK (it_ > 0, bad_index ());
  -- it_;
  return *this;
}
}}}


Removing ""BOOST_UBLAS_CHECK (it_ > 0, bad_index ());"" solves the problem. Similarly for the += and -= operators.

The documentation makes no mention of the range needing to consist only of positive values and this seems a rather arbitrary restriction.",brian.tyler@…
2087,enable in-place construction of fusion container content,fusion,Boost 1.35.0,Boost 1.36.0,Feature Requests,Joel de Guzman,new,2008-07-08T11:16:27Z,2008-07-08T11:16:27Z,"when a fusion container is initialized, the objects in the container are constructed and after that copied (using the copy constructor).
an in-place initialization would allow to have a fusion container of non-copy-constructible types as the copy construction would not be necessary anymore. (fusion sequence of non-copy-constructible types are not currently supported.)
using an in-place solution should also be more efficient.

",oliver.mueller@…
2068,Better path comparison for common.mkdir,build,Boost 1.35.0,,Bugs,Vladimir Prus,new,2008-07-03T22:10:49Z,2010-01-10T10:14:47Z,"The problem is exposed by the accumulators doc build, which fails because bjam tries to create the same target directory twice, once with a relative path and once with an absolute path. bjam doesn't normalize the paths correctly and therefore fails to recognize that the targets are the same. The build fails on the second mkdir attempt because the target directory already exists.

Jurko Gospodnetić tracked the problem down to the following:

Ok, I managed to reproduce an equivalent problem using regular Windows bjam. To reproduce it use the following jamroot.jam file placed in a folder called UUU:

{{{
import common ;
install fff                      : jamroot.jam ; <name>file.1 ;
install fff/ggg/..               : jamroot.jam : <name>file.2 ;
install fff/ggg/../ggg/../../fff : jamroot.jam : <name>file.3 ;
install ../UUU/fff               : jamroot.jam : <name>file.4 ;
}}}


Boost Build tries to battle this problem by normalizing any paths passed to it (i.e. shortcircuiting any . path elements except and any .. path elements except for the initial series), which makes cases 2 & 3 above not conflict with case 1. However the path passed in case 4. is already normalized and does not get recognized as pointing to the same location as the one in case 1. Therefore the initial build fails, while any repeated builds work as expected.

The problem could be solved by updating the bindtarget() function in Boost Jam's rules.c source file to find some sort of a 'unique' identifier for each of its targets. Any suggestions on what such an identifier might be?

I guess we could attempt to root any non absolute paths from the current folder's absolute path and then normalize that. But is that enough?

Should we be prepared to handle stuff like symbolic links?

I have not researched this much before, but is there any 'standard solution' to such a problem that I am not aware of?

Is there some portable 'file system object identifier' we can use in case the file system already exists? There are some other places in Boost Jam code (e.g. file_query() function in filent.c) that could benefit from such an identifier since they hash their results based on the parameter name and so may cache multiple result sets for the same file in some cases. If there is no portable identifier, then are there at least different identifiers on different systems?

Note that this is not just a MkDir problem. Any other target build could fail due to similar reasons. 
",Eric Niebler
2066,Inspect needs to review generated doc files too,inspection script,Boost 1.35.0,Boost 1.36.0,Tasks,Beman Dawes,assigned,2008-07-03T11:16:35Z,2013-01-03T19:11:23Z,"Inspect needs to run on release snapshot so that it is looking at the generated doc files too.

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

Maybe it would be easier to copy the files from the release snapshot into a release working copy so that inspect will work as it is not.",Beman Dawes
2041,"MPL: more comprehensive test coverage for ""fail"" situations requiring diagnostics",mpl,Boost 1.35.0,Boost 1.36.0,Bugs,Aleksey Gurtovoy,assigned,2008-06-23T21:07:19Z,2008-06-23T21:07:36Z,See http://thread.gmane.org/gmane.comp.lib.boost.user/36876,Aleksey Gurtovoy
2031,PDF version of MPL reference manual is out-of-date,mpl,Boost 1.35.0,Boost 1.36.0,Bugs,Aleksey Gurtovoy,new,2008-06-21T03:09:30Z,2008-06-21T03:09:30Z,The reference manual in PDF is out-of-sync with HTML docs (and .rst sources). It either needs to be regenerated or removed from the docs.,Aleksey Gurtovoy
2013,Support for homogeneous MPI builds in BBv2,mpi,Boost 1.35.0,Boost 1.36.0,Feature Requests,Douglas Gregor,new,2008-06-16T19:43:41Z,2010-12-16T16:43:34Z,"We need a BBv2 feature to determine whether to build the MPI library for homogeneous clusters or heterogeneous clusters. The default will be heterogeneous clusters, but we can provide some additional optimizations for homogeneous clusters.",Douglas Gregor
1979,More example hash functions,unordered,Boost Development Trunk,To Be Determined,Feature Requests,Daniel James,assigned,2008-06-01T10:17:27Z,2009-02-21T18:17:46Z,,Daniel James
1974,ambiguous call to ref in vector_of_vector.hpp when using bind.hpp,uBLAS,Boost 1.56.0,To Be Determined,Bugs,Gunter,reopened,2008-05-30T14:13:00Z,2018-02-17T15:32:15Z,"When bind.hpp and numeric/ublas/vector_of_vector.hpp are both included, instantiating and using a generalized_vector_of_vector causes an ambiguous call to the overloaded function 'boost::numeric::ublas::ref'.  See attached code for a simple example and attached patch for the simple proposed fix.",Will Moss <wmoss@…>
1966,Need VC8 workaround,parameter,Boost 1.35.0,Boost 1.36.0,Bugs,Daniel Wallin,new,2008-05-28T16:29:06Z,2009-05-30T00:14:49Z,"{{{
template <class A0, class A1 = boost::parameter::void_>
struct sparse
  : sparse_impl<
        typename sparse_signature::bind<A0,A1>::type
    >
{
    typedef sparse_impl< typename sparse_signature::bind<A0,A1>::type > base;
    
    BOOST_PARAMETER_CONSTRUCTOR(
        sparse, (base), tag,
        (required
         (nrows, (std::size_t))
        )
        (optional
         (nstored, (std::size_t))
        )
    )

    // workarounds for VC8 bugs
    sparse(sparse const& rhs)
    : sparse_impl((sparse_impl const&)rhs)
    {}
    sparse& operator=(sparse const& rhs)
    {
        *(sparse_impl*)this = (sparse_impl const&)rhs;
        return *this;
    }
};
}}}

The problem is that the automatically-generated copy ctor and assignment essentially leave out the casts above, and get routed to the templated ctor in the base class.
The question is, should we incorporate these fixes in BOOST_PARAMETER_CONSTRUCTOR?
",Dave Abrahams
1949,suggestion for iterator library - templated constructors,iterator,Boost 1.35.0,Boost 1.36.0,Feature Requests,jeffrey.hellrung,new,2008-05-26T03:28:23Z,2012-11-21T19:41:16Z,"This feature was implemented via derivation for ""DataFlow"" iterators in the serialization library.  It is described in a page in that library at
libs\serialization\doc\dataflow.html

I don't think that actually adding the feature would be a huge deal.  But a good tutorial document on the utility of such a feature would take some effort.

Robert Ramey",Robert Ramey
1948,shared_container_const_iterator to complement shared_container_iterator,iterator,Boost 1.35.0,To Be Determined,Feature Requests,jeffrey.hellrung,new,2008-05-26T01:42:39Z,2012-11-21T19:40:30Z,A version of shared_container_iterator that can iterate over a const container might be useful.  I was able to locally modify shared_container_iterator to work with a shared_ptr<const Container> without too much trouble.,Frank Mori Hess
1947,traversal access decoupling,iterator,Boost 1.35.0,Boost 1.36.0,Patches,jeffrey.hellrung,new,2008-05-25T14:21:10Z,2012-11-21T22:38:25Z,"In an attempt to use iterator_facade to
implement a ""Readable"" and ""Writeable""
== ""Swapable"" ""Random Access"" iterator
I found that the expression:
it[n] returns an object of type
operator_brackets_proxy that is convert-
ible to ""reference"" but not to ""value_type"".

Consequently I can use

value_type a;
it[n] = a;

but not
a = it[n];

I am not sure of how to correctly solve
this issue. Here is a pointer to a
discussion on the list:

http://lists.boost.org/Archives/boost/2008/05/137868.php

",Roland Schwarz
1916,[mpl] MPL_HAS_XXX_TRAIT_DEF bug in MSVC71,mpl,Boost 1.35.0,Boost 1.36.0,Bugs,Aleksey Gurtovoy,new,2008-05-14T10:24:32Z,2008-05-14T10:24:32Z,"The MSVC71 implementation of MPL_HAS_XXX_TRAIT_DEF does not correctly support defining a trait of the same name even if that is enclosed within a different namespace.  It seems to have something to do with the instantiation of the 'msvc71_sfinae_helper'.  In the code below I do the following:
{{{
#!cpp
namespace one
{
   BOOST_MPL_HAS_XXX_TRAIT_DEF(result_type)
   BOOST_MPL_HAS_XXX_TRAIT_DEF(another_type)
}

namespace two
{
   BOOST_MPL_HAS_XXX_TRAIT_DEF(result_type)
}
}}}
Namespace two's {{{has_result_type}}} actually ends up testing for the presence of {{{another_type}}} rather than {{{result_type}}}.  If the declarations in namespace one are reordered so that result_type trait is last, then the namespace two trait works as expected.

I wrote a basic sfinae trait-check implementation myself which worked ok.  Maybe something similar could be used for msvc71 in the mpl?

If the following code is compiled with -DUSE_MPL_TRAIT_DEF then the mpl is used, otherwise my own implementation is used.

{{{
#!cpp

#if USE_MPL_TRAIT_DEF

   #define SELECTIVE_HAS_XXX_TRAIT_DEF   BOOST_MPL_HAS_XXX_TRAIT_DEF
   #include <boost/mpl/has_xxx.hpp>

#else

   #define SELECTIVE_HAS_XXX_TRAIT_DEF   MY_HAS_XXX_TRAIT_DEF
   #define MY_HAS_XXX_TRAIT_DEF( trait )                                                     \
      template <class T>                                                                     \
      struct has_##trait                                                                     \
      {                                                                                      \
         template <typename U>                                                               \
         static char test( U const volatile*, typename U::trait* = 0 );                      \
         static long test( ... );                                                            \
                                                                                             \
         static const bool value = sizeof test( static_cast<T*>(0) ) == sizeof(char);        \
      };                                                                                     \

#endif


namespace one
{
   SELECTIVE_HAS_XXX_TRAIT_DEF(result_type)
   SELECTIVE_HAS_XXX_TRAIT_DEF(another_type)
}


namespace two
{
   // This instantiation of msvc71_sfinae_helper in the msvc71
   // implementation has been seen before --- but its function is that
   // of the last trait def.
   // 
   // This line has the effect of defining a 'has_result_type' struct
   // that tests for 'another_type' in msvc71.
   //
   SELECTIVE_HAS_XXX_TRAIT_DEF(result_type)
}


template <bool> struct test;
template <> struct test<true> {};


struct X
{
   typedef int result_type;
   typedef int another_type;
};


struct Y
{
   typedef int result_type;
};


int main()
{
   test< one::has_another_type< X >::value >();
   test< one::has_result_type< X >::value >();

   // this works but is actual testing for 'another_type'!!!
   test< two::has_result_type< X >::value >();

   // this fails as it doesn't have 'another_type'
   test< two::has_result_type< Y >::value >();
}
}}}",Adam Butcher <adam.butcher@…>
1915,Nested matrix products with transposes causes compiler to complain error: invalid application of ‘sizeof’,uBLAS,Boost 1.34.1,To Be Determined,Support Requests,Gunter,assigned,2008-05-14T05:52:05Z,2008-05-14T21:56:28Z,"When using ublas, a pair of nested products will cause the compiler to complain if there is a `trans` on any of the operands.  For example:

{{{
#!cpp
using namespace boost::numeric::ublas;
matrix<float> A(3,3),	B(3,3),	C(3,3);

prod(prod(A,B),trans(C));  // fails
prod(prod(trans(A),B),C);  // fails
prod(prod(A,trans(B)),C);  // fails
prod(prod(A,B),C);  // OK
}}}

The compiler produces the following error message:
{{{
/opt/local/include/boost/numeric/ublas/matrix_expression.hpp: In function ‘typename boost::numeric::ublas::matrix_matrix_binary_traits<typename E1::value_type, E1, typename E2::value_type, E2>::result_type boost::numeric::ublas::prod(const boost::numeric::ublas::matrix_expression<E>&, const boost::numeric::ublas::matrix_expression<E2>&) [with E1 = boost::numeric::ublas::matrix_matrix_binary<boost::numeric::ublas::matrix<float, boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, boost::numeric::ublas::unbounded_array<float, std::allocator<float> > >, boost::numeric::ublas::matrix<float, boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, boost::numeric::ublas::unbounded_array<float, std::allocator<float> > >, boost::numeric::ublas::matrix_matrix_prod<float, float, float> >, E2 = boost::numeric::ublas::matrix_unary2<boost::numeric::ublas::matrix<float, boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, boost::numeric::ublas::unbounded_array<float, std::allocator<float> > >, boost::numeric::ublas::scalar_identity<float> >]’:
bad_multiply.cpp:9:   instantiated from here
/opt/local/include/boost/numeric/ublas/matrix_expression.hpp:4815: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’ 
}}}",Leo Singer <aronnax@…>
1913,Null deleter for shared_ptr,smart_ptr,Boost 1.35.0,To Be Determined,Feature Requests,Peter Dimov,new,2008-05-12T21:58:36Z,2011-03-08T13:25:32Z,"As raised in this (http://article.gmane.org/gmane.comp.lib.boost.user/35693) message on the boost-users mailing list, it would be very nice if the smart pointer library contained a null deleter object so it could be used for stack/static objects. To save the user having to define their own.",Kevin Martin <kev82@…>
1909,Documentation is out of sync,concept_check,Boost 1.43.0,To Be Determined,Bugs,jsiek,new,2008-05-09T07:55:33Z,2010-06-07T15:20:16Z,"The page ""Implementation"" of the documentation still uses the deprecated way of defining and checking concepts:

http://www.boost.org/doc/libs/1_35_0/libs/concept_check/implementation.htm

The rest of the pages seem to be up to date.

Another small thing is that the ""Prev"" and ""Next"" links at the the bottom of the page ""Using Concept Checks"" are switched compared to the other pages.

http://www.boost.org/doc/libs/1_35_0/libs/concept_check/using_concept_check.htm
",Kimon.Hoffmann@…
1900,Missing documentation for mpl::print in the MPL library,mpl,Boost 1.35.0,Boost 1.36.0,Bugs,Joel Falcou,new,2008-05-07T19:31:27Z,2011-11-27T18:46:09Z,The documentation for mpl::print is missing from the Boost reference documentation.,Edward Diener <eldiener@…>
1888,Why doesn't InputIterator require that reference is convertible to value_type?,concept_check,Boost 1.35.0,Boost 1.36.0,Bugs,jsiek,new,2008-05-01T19:34:50Z,2008-05-01T21:09:47Z,"Bug title says it all. boost::InputIterator doesn't enforce any relationship between the reference and value_type associated types. Seems wrong to me, but perhaps there is a reason.

It also doesn't check that the type of dereferencing an input iterator is reference.
",Eric Niebler
1887,[doc] input_iterator_archetype is not a valid InputIterator,concept_check,Boost 1.35.0,Boost 1.36.0,Bugs,Dave Abrahams,new,2008-05-01T19:02:56Z,2011-09-20T19:15:01Z,"creating_concepts.htm shows an InputIterator concept which requires that the type of *it++ is the same as the value_type. (This is legit according to the C++03 requirements table for input iterators, but probably too strict in practice.) Then, concept_covering.htm shows an input_iterator_archetype, which fails to meet this requirement because *it++ will return an object of type input_iterator_archetype::reference which is distinct from, but convertible to, the iterator's value_type. If you try to assert that input_iterator_archetype satisfies the InputIterator concepts as both are presented in the docs, it will fail.

This is only a documentation problem. As defined by the BCCL, input_iterator_archetype is a valid InputIterator.",Eric Niebler
1836,bug in serializing wide character strings,serialization,Boost 1.34.1,To Be Determined,Bugs,Robert Ramey,assigned,2008-04-17T21:12:21Z,2010-11-29T20:32:54Z,"We've discovered an issue Boost has writing and reading wide character
strings (wchar_t* and std::wstrings) to non-wide character file streams
(std::ifstream and std::ofstream).  The issue stems from the fact that
wide characters are written and read as a sequence of characters (in
text_oarchive_impl.ipp and text_iarchive_impl.ipp, respectively).  For
text streams, an EOF character terminates the reading of a file on Windows.
Some wide characters have EOF (value = 26 decimal) as one of the bytes so
reading that byte causes early termination of the read.  We have worked
around the issue by deriving our own input and output archives from
text_i|oarchive_impl<Archive> and overriding load_override() and
save_override for std::wstring and wchar_t*.  Our implementation just
sequences through the wide characters and writes them 1 by 1 as
wchar_t to the archive.  This isn't very elegant and is even less readable
in the file than the current implementation but does resolve the problem. 

Although the test test_simple_class does test wstrings, it only uses characters 'a'-'z' which does not expose this problem.
",Jeff Faust <jeff@…>
1811,Help packaging by supporting DESTDIR,Building Boost,Boost 1.35.0,To Be Determined,Patches,Vladimir Prus,new,2008-04-10T23:36:48Z,2018-07-13T07:10:00Z,"Usual practice for package builders is to invoke installation with
{{{
DESTDIR=/tmp/package make install
}}}
and then build package from the content of ""/tmp/package"" directory.
When package is installed ""/tmp/package/usr"" becomes ""/usr""

Usually this is different than --prefix, because some component may need to reference another by using the full path. For example - in pkgconfig .pc files. If prefix is set to the temporarily location the component would try to reference on the wrong place, instead of the place where the needed component is installed.

I was assured that boost doesn't have any such dependences, however for packager convenience it is relatively easy to make it follow the above convention.

The attached patch adds ""${DESTDIR}"" into the generated Makefile, so when make is involved normally , DESTDIR would be empty and files would be generated using the PREFIX where they are going to reside. 
On installation if it is not empty, it would place the files in the directory requested by the package builder.
",iive
1808,Trim middle,algorithm,Boost 1.35.0,Boost 1.46.0,Feature Requests,Marshall Clow,new,2008-04-10T12:55:28Z,2012-02-29T23:53:14Z,"Could you add a function to trim 'internal' whitespace? I think two functions would be handy, one for single-line data and one for multi-line data.
The single-line one would replace all internal whitespace by a single space character.
The multi-line one would replace multiple empty lines by a single empty line and remove trailing whitespace from each line.",Olaf van der Spek
1802,Add autodetection of Expat and MPI in configure,build,Boost 1.35.0,Boost 1.42.0,Feature Requests,Vladimir Prus,new,2008-04-09T17:04:00Z,2009-11-10T07:43:20Z,"The configure script in Boost already autodetects the presence and versions of Python and ICU, but the paths for Expat and the user's MPI implementation must be provided by hand.  It would be useful if the script found those and added them to user-config.jam automatically.",jewillco@…
1798,"met an error using boost::tokenizer in multi-times in vs2005, unicode",tokenizer,Boost 1.34.1,,Bugs,jsiek,new,2008-04-09T08:12:28Z,2008-04-09T08:12:28Z,"test function:

const CHAR* tnotifymsg = “HTTP/1.1
Host: 176.177.193.111
Content-Length: 110
Date : ......

<?xml version=""1.0""?>
<Encodeing>
 <Body cls=""auto"" obj=""10001"">
  <ID>19</ID>
</ Encodeing >”;

CHAR* pSeparator =  "" ,;\n\r"";
	int nErrorcode = 0;

	boost::char_separator<CHAR> sep(pSeparator);
	std::string strNotifymsg = tnotifymsg;
	boost::tokenizer<boost::char_separator<CHAR>> tokens(strNotifymsg, sep);

	boost::tokenizer<boost::char_separator<CHAR>>::iterator itBegin  = tokens.begin();

	boost::tokenizer<boost::char_separator<CHAR>>::iterator itEnd    = tokens.end();

	boost::tokenizer<boost::char_separator<CHAR>>::iterator beg = itBegin;

	// error code if ""HTTP/1.1"" at the beginning of notify message
	if(_stricmp((*beg).c_str(),  ""HTTP/1.1"") == 0)
	{
		using boost::lexical_cast;
		++beg;
		nErrorcode = lexical_cast<int>(*beg);

		return nErrorcode;
	}
	else{

		// else the right message for parser
		for(; !bFinishFlag; ++beg)
		{
			;
}
	}

",wingo <wangtonggu@…>
1726,boost/date_time/posix_time/time_formatters.hpp incorrectly formats fractional seconds using global locale,date_time,Boost 1.34.1,To Be Determined,Bugs,az_sw_dude,new,2008-03-28T22:51:42Z,2008-03-28T22:51:42Z,"The function boost::posix_time::to_iso_string_type() uses the ostream::operator<<() function to write the time. This later function will use the current global locale to format each of the elements of the time. In particular, when the global locale is set to en_US, the fractional will be formatted to be 123,456 when there are six digits, which is incorrect.

The proposed solution is to temporarily imbue the ostream with the classic locale to disable formatting. The attached patch only applies this to the fractional seconds but it would be more robust to apply to the other time components as well.

This type of error probably exists in other functions. In particular see Ticket #1674 which is the same error.",jplejacq@…
1702,serialization for Mersenne twister,random,Boost 1.34.1,Boost 1.36.0,Patches,No-Maintainer,new,2008-03-20T22:48:22Z,2011-04-07T15:49:48Z,"Based on email by Neal Becker from 2007-12-17, quoting:

This is an improved patch for mt serialization, using the serialization
collection stuff
",Pavel Vozenilek
1670,wave almost unusably slow on real-world input,wave,Boost Development Trunk,Boost 1.36.0,Bugs,Hartmut Kaiser,reopened,2008-03-04T16:31:40Z,2008-11-20T21:25:01Z,"I'm running a wave-based preprocessor on boost/python.hpp as part of document generation (Synopsis). The preprocessing alone takes >6 hours ! (The subsequent parsing with Synopsis' own C++ parser is then relatively quick, surprisingly.

I notice that wave seems to get increasingly slow, so I wonder whether the speed decrease is caused by some internal lookup on a growing dictionary (map) that has super-linear lookup time ?
",Stefan Seefeld
1656,Consider implementing flush() for symmetric filters,iostreams,Boost 1.34.1,Boost 1.36.0,Bugs,Jonathan Turkanis,new,2008-02-27T03:32:19Z,2018-07-13T17:33:45Z,,Jonathan Turkanis
1649,Fix definition of JavaScript menu to avoid long chains of functions,iostreams,Boost 1.34.1,Boost 1.36.0,Bugs,Jonathan Turkanis,new,2008-02-20T00:14:39Z,2008-02-20T00:14:39Z,"See problem raised here: http://article.gmane.org/gmane.comp.lib.boost.devel/171201.

This was fixed for the platform in question by breaking the menu definition into chunks, but the chunks should be made even smaller in case other platforms have lower limits on the size of function chains",Jonathan Turkanis
1633,"Make pipelines first class devices, so they can be passed to copy",iostreams,Boost 1.34.1,Boost 1.36.0,Feature Requests,Jonathan Turkanis,reopened,2008-02-12T19:26:21Z,2009-04-19T19:18:42Z,See thread starting with [http://article.gmane.org/gmane.comp.lib.boost.user/33255],Jonathan Turkanis
1632,Default Interval rounding policies incomplete,numeric,Boost 1.34.1,Boost 1.36.0,Bugs,No-Maintainer,new,2008-02-11T03:42:41Z,2008-05-24T16:15:02Z,"Report originates at http://bugs.debian.org/440178

The rounding policy requirements (http://boost.org/libs/numeric/interval/doc/rounding.htm) list e.g. tan_down(), but none of the implementations in rounded_arith.hpp implement it.  

The result is that this code fails to compile:
{{{
#include <boost/numeric/interval.hpp>

int main( int ac, char* av[] )
{
    boost::numeric::interval<double> I(0.1, 0.2);
    I = tan(I);

    return 0;
}
}}}

",Steven Robbins <smr@…>
1574,operator<< for boost::posix_time::ptime ignores ostream flags,date_time,Boost 1.45.0,,Patches,az_sw_dude,new,2008-01-16T17:15:54Z,2013-10-24T11:10:51Z,"Consider the following:
{{{
boost::posix_time::ptime a;

cout << ""one "" << 1 << endl;
cout.clear(ios::failbit);
cout << ""two "" << 2 << endl;
cout << ""time "" << a << endl;
cout << ""three"" << 3 << endl;
cout.clear(ios::goodbit);
cout << ""four "" << 4 << endl;
}}}

Since cout should not produce output when ios::failbit is set, one would expect the output to be:
{{{
one 1
four 4
}}}

However, the output is:
{{{
one 1
not-a-date-timefour 4
}}}",adam@…
1560,Performance testing with boost::test,test,Boost Development Trunk,To Be Determined,Feature Requests,Gennadiy Rozental,reopened,2008-01-07T22:06:36Z,2008-01-23T09:00:20Z,"I have been trying to use boost::test to do some performance testing.

With the following macros:

{{{
// The basic idea of ""test"" is to call the function to be timed many 
// times (say up to 1000), throw away the slowest 10% of those times, 
// and average the rest. Why? <shrug> shoot-from-the-hip ""theory"" and 
// experience that its return is fairly consistent to 2, maybe 3 
// digits. The test function has a ""time out"" feature where it quits if 
// the accumulated measured time grows beyond 1 second (which may not be 
// appropriate for all tests). But it is easy to get bored when you 
// unexpectedly find yourself waiting 30 minutes for timing result, so 
// that's why it's there. Otoh, I put in a minimum repetition of at 
// least 10, no matter how long the measured time is, so you get at 
// least some accuracy (tweak knobs as you like). Note that the 
// accumulation/averaging happens in double, even though the data and 
// answer are float (just paranoia really). Weakness: If you're timing 
// something that is quicker than the minimum resolution of your timer, 
// this doesn't work. But otherwise, this is better than the 
// traditional loop inside the timer as it throws away those results 
// that happen to get interrupted by your email checker running. :-) 

#include <numeric>
#include <boost\timer.hpp>

template <class F> 
double 
time_tests(F f) // f is a function that returns its execution time
{ 
	std::vector<double> t; 

	// Store time of 10 executions of f
	unsigned int i;
	for (i = 0; i < 10; ++i) 
		t.push_back(f()); 

	double total_time = std::accumulate(t.begin(), t.end(), 0.0);

	// Keep running until at least 1s of results are available, or 1000 executions
	while (i < 1000 && total_time < 1.0) 
	{ 
		t.push_back(f()); 
		total_time += t.back(); 
		++i; 
	} 
	std::sort(t.begin(), t.end()); 
	t.resize(t.size() * 9 / 10); 
	return std::accumulate(t.begin(), t.end(), 0.0) / t.size(); 
} 


#define TIMED_TEST_CASE( test_name ) \
	double \
	time_test_##test_name() \
	{ \
		boost::timer t; \
		{ \
			test_name##_impl();  \
		} \
		return t.elapsed(); \
	} 

#define TIMED_AUTO_TEST_CASE( test_name ) \
	void \
	test_name##_impl(); \
	\
	TIMED_TEST_CASE( test_name ) \
	\
	BOOST_AUTO_TEST_CASE( test_name ) \
	{ \
		double execution_time = time_test_##test_name(); \
		boost::unit_test::unit_test_log.set_threshold_level( boost::unit_test::log_messages ); \
		BOOST_TEST_MESSAGE(BOOST_TEST_STRINGIZE( test_name ).trim( ""\"""" ) << "" execution time: "" << execution_time << ""s""); \
		BOOST_CHECK( true ); \
	} \
	\
	inline void test_name##_impl()
}}}

I can define tests such as

{{{

// Boost.Test
//#define BOOST_AUTO_TEST_MAIN
// #include <boost/test/unit_test.hpp>
#define BOOST_TEST_MODULE allTests
#include <boost/test/unit_test.hpp>

#include ""time_test.h""

#include <vector>


#define BaseT float

 
BOOST_AUTO_TEST_SUITE(vectors);

TIMED_AUTO_TEST_CASE( vector_test )
{
	unsigned int const v1_dim = 6;
	unsigned int const v2_dim = 4;
	unsigned int const v3_dim = 65535;

	std::vector<BaseT> v1(v1_dim, 1.0);
	std::vector< std::vector<BaseT> > v2(v2_dim, v1);
	std::vector< std::vector< std::vector<BaseT> > > v3(v3_dim, v2);

	
}

TIMED_AUTO_TEST_CASE( test2 )
{
    BOOST_CHECK( true );
}

TIMED_AUTO_TEST_CASE( test3 )
{
	for (int i=0; i<10000; i++)
	{
		BOOST_CHECK( true );
	}
}


BOOST_AUTO_TEST_SUITE_END();

}}}

This works, but is not particularly elegant.  Is there a better solution (eg, involving defining a class that inherits from one of the existing ones)?

",John Pavel <jrp@…>
1558,Optional separate compilation,unordered,Boost Development Trunk,To Be Determined,Feature Requests,Daniel James,assigned,2008-01-06T18:41:53Z,2009-02-21T18:17:31Z,There are some parts of Boost.Unordered that could be compiled into a library file. Provide an option to do this.,Daniel James
1549,Boost.MPL: 'index_of' algorithm is not documented,mpl,Boost 1.34.1,Boost 1.36.0,Bugs,Aleksey Gurtovoy,assigned,2008-01-04T02:24:33Z,2008-01-04T02:24:52Z,,Aleksey Gurtovoy
1499,xxx is not a member of 'boost::signals::detail::named_slot_map_iterator,signals,Boost 1.55.0,Boost 1.50.0,Bugs,Douglas Gregor,reopened,2007-12-03T18:52:05Z,2014-08-08T04:09:15Z,"Compiling boost with msvc-9.0 I get errors such as

{{{
.\boost/iterator/iterator_facade.hpp(529) : error C2039: 'decrement' : is not a member of 'boost::signals::detail::named_slot_map_iterator'

}}}

and 
{{{

.\boost/iterator/iterator_facade.hpp(547) : error C2039: 'advance' : is not a member of 'boost::signals::detail::named_slot_map_iterator'

}}}",jrp at dial dot pipex dot com
1497,Ruling needed on tracker usage,trac / subversion,Boost Development Trunk,Boost 1.40.0,Tasks,Beman Dawes,new,2007-12-03T14:54:44Z,2010-11-29T15:24:28Z,"I know my concerns of http://thread.gmane.org/gmane.comp.lib.boost.devel/167139/focus=167657 were not universally well-received, and Beman was silent on the issue.  Beman, I really think the release manager for 1.35 needs to definitively demonstrate support for, or opposition to, this approach.  I think you know my opinion: if we don't institute these practices now, our new tracking system will be just as ineffective as the last one was.

I will be happy to write documentation if necessary.
",Dave Abrahams
1487,Update the writing documentation instructions,Documentation,,To Be Determined,Tasks,Daniel James,assigned,2007-11-30T20:01:35Z,2010-06-07T22:40:00Z,The documentation (http://www.boost.org/more/writingdoc/structure.html) needs to updated and probably should be moved to the new site.,Daniel James
1485,Add ability to have some blocks before doc-info.,quickbook,Boost Development Trunk,To Be Determined,Feature Requests,Daniel James,new,2007-11-30T06:34:22Z,2014-04-09T01:57:54Z,"Now that templates are reasonably functional, it would be nice to allow including and defining them even before one gets to a doc-info. It might be useful to use other blocks before the doc-info. So change the syntax so that one can at minimum place ""include"", ""template"", and comments before doc-info.",René Rivera
1482,boost::python::throw_error_already_set should be marked noreturn,python USE GITHUB,Boost 1.34.1,To Be Determined,Bugs,Dave Abrahams,new,2007-11-29T19:34:10Z,2007-12-11T14:20:12Z,"boost::python::throw_error_already_set should be marked noreturn, so that gcc
doesn't complain when functions call it at the end and then don't return.

Thanks!
Geoffrey",irving@…
1479,Document litre tool.,Documentation,Boost Development Trunk,To Be Determined,Tasks,Daniel Wallin,new,2007-11-25T17:04:39Z,2011-11-08T15:47:06Z,"Add documentation, and copyrights, for the code at tools/litre. Could use a general cleanup into build/src/doc/example structure.",René Rivera
1469,[mpl] nested typedef of set has two different meanings,mpl,Boost 1.34.1,To Be Determined,Bugs,Aleksey Gurtovoy,new,2007-11-22T13:25:20Z,2007-11-22T13:25:20Z,"This problem was diagnosed by Steve Watanabe after my posting on the developer list (see http://thread.gmane.org/gmane.comp.lib.boost.devel/168339/focus=168366)

Basically the following doesn't compile:

{{{
#include <boost/mpl/set.hpp>
#include <boost/mpl/vector.hpp>
#include <boost/mpl/copy.hpp>
#include <boost/mpl/insert.hpp>
#include <boost/mpl/inserter.hpp>

using namespace boost::mpl;

template<
  typename T
> >
struct as_set :
  copy<
    T
  , inserter<
      set<>
    , insert< _1, _2 >
    >
  >
{};

typedef set<int,char>             a_set;
typedef vector<int,int,char>      a_vector;
typedef as_set< a_set >::type     set_as_set;
typedef as_set< a_vector >::type  vector_as_set;

typedef next< begin< a_set >::type >::type
THIS_IS_OK;
typedef next< next< begin< a_set >::type >::type >::type
THIS_IS_OK_AS_WELL;
typedef next< begin< a_vector >::type >::type
THIS_IS_OK_TOO;
typedef next< begin< set_as_set >::type >::type
THIS_WORKS_TOO;
typedef next< next< begin< set_as_set >::type >::type >::type
THIS_FAILS;
typedef next< next< begin< vector_as_set >::type >::type >::type
THIS_FAILS_TOO;
}}}

Steve Watanabe diagnosed this to be a problem of mpl::set using the nested typedef 'type' for two different purposes: one as an alias of the set<>, the other refering to the item type. The result is that upon iteration the termination condition isn't recognized and the iterator blows up",sven.vanechelpoel@…
1460,"Python classes with multiple bases are convertible only to the first class in the lists (even if super(classname, self).__init__() is called)",python USE GITHUB,Boost 1.34.1,To Be Determined,Bugs,Dave Abrahams,reopened,2007-11-18T13:42:37Z,2018-05-02T13:22:42Z,"first reported here: http://mail.python.org/pipermail/c++-sig/2007-October/012926.html

{{{
C++:
#include <boost/python.hpp>

namespace bp = boost::python;

struct A { };
struct B { };

void test_A(const A &) { }
void test_B(const B &) { }

BOOST_PYTHON_MODULE(multiple_inheritance)
{
    bp::def(""test_A"", &test_A);
    bp::def(""test_B"", &test_B);

    bp::class_<A>(""A"", bp::init<>());
    bp::class_<B>(""B"", bp::init<>());
}

Python:
class C(A, B):
    pass

test_A(C())
test_B(C())

And I get:
Traceback (most recent call last):
  File ""./multiple_inheritance.py"", line 10, in <module>
    test_B(C())
Boost.Python.ArgumentError: Python argument types in
    multiple_inheritance.test_B(C)
did not match C++ signature:
    test_B(B)
}}}

I will try to figure it out once I am done with the exceptions.",Piotr Jaroszyński <p.jaroszynski@…>
1404,Unordered Fusion Map constructors.,fusion,Boost Development Trunk,To Be Determined,Feature Requests,Joel de Guzman,new,2007-11-02T06:10:55Z,2009-05-28T17:48:33Z,"Currenty, when constructing Fusion Maps, the order of type arguments used as template parameters need to be followed in the constructor as well.

Example:

{{{

struct tags {
  struct type_1 { };
  struct type_2 { };
};

using namespace boost::fusion ;

typedef map< pair<tags::type_1, int>, pair<tags::type_2, int> > my_map_type ;

{
  // following line will not compile, because of the argument ordering
  my_map_type instance( make_pair<tags::type_2>(2), make_pair<tags::type_1>(1) );

  // following line will compile, because the argument order is the same as
  // the order of elements in the fusion map specialization
  my_map_type instace_works( make_pair<tags::type_1>(1), make_pair<tags::type_2>(2) );

}

}}}

The feature request is to support arbitrary ordering of constructor arguments, not necessarily to follow the order of argument types as prescribed in the template arguments to the fusion map.
",Dean Michael Berris <mikhailberis@…>
1396,wrong result_of invocation around transform_view,fusion,Boost Development Trunk,Boost 1.36.0,Bugs,Joel de Guzman,new,2007-10-31T22:49:37Z,2007-11-29T03:15:42Z,"See the following snippet.
For some reason, `boost::result_of< ::identity(int) >` is invoked in `as_vector`,
which means that the argument is rvalue.
It should be `boost::result_of< ::identity(int &) >`.

{{{
#include <boost/fusion/include/as_vector.hpp>
#include <boost/fusion/include/transform_view.hpp>
#include <boost/fusion/include/vector.hpp>


struct identity
{
    template<class FunCall>
    struct result;

    template<class Fun>
    struct result<Fun(int&)>
    {
        typedef int& type;
    };

    int& operator()(int& i) const
    {
        return i;
    }
};


int main()
{
    typedef boost::fusion::vector<int, int> from_t;
    from_t from;
    boost::fusion::transform_view<from_t, ::identity> v(from, ::identity());

    boost::fusion::as_vector(v); // doesn't compile.
}
}}}",Shunsuke Sogame <pstade.mb@…>
1393,library binaries should be buildable by name from the top level,build,Boost 1.34.1,To Be Determined,Feature Requests,Vladimir Prus,new,2007-10-31T16:18:52Z,2009-08-29T08:00:45Z,http://article.gmane.org/gmane.comp.lib.boost.devel/166925,Dave Abrahams
1387,Review / update docs to reflect changes,parameter,Boost 1.34.1,Boost 1.36.0,Bugs,Daniel Wallin,new,2007-10-30T16:29:58Z,2008-06-27T00:18:54Z,"There are at ''least'' changes in the equivalent C++ for {{{BOOST_PARAMETER_KEYWORD(tag,name)}}}.  However, there may well be other changes that need to be documented.

Daniel, If you can think of any, please add them to this ticket or create a ticket of your own.",Dave Abrahams
1338,g++ warnings and incomplete header inclusions,numeric,Boost Development Trunk,To Be Determined,Patches,Douglas Gregor,reopened,2007-10-21T12:31:56Z,2009-04-19T19:17:25Z,"Hi,

as reported in http://lists.boost.org/Archives/boost/2007/10/128948.php
g++ reports various minor issues processing header files of numeric in current
trunk. Please fix it!",jensseidel@…
1326,Unable to check graph isomorphism using LEDA adapter,graph,Boost Development Trunk,To Be Determined,Bugs,Jeremiah Willcock,reopened,2007-10-18T11:08:58Z,2012-01-04T23:41:20Z,"I tried to use isomorphism() algorithm with LEDA graphs and encountered several compilation issues:

1. ""leda::"" namespace is not used in LEDA 4.3.1, therefore declaration ""leda::GRAPH<vtype,etype>"" might be wrong.

2. EdgeListGraph concept must be supported by a graph in order to use it by the isomorphism() algorithm. For me it's unclear why this interface is not implemented in LEDA adapter. Generally, it is possible to iterate through edges in LEDA graphs. Moreover, EdgeListGraph interface implementation may look very similar to VertexListGraph one.

3. All LEDA adapter iterators publicly inherit from
   iterator_facade< Derived, Value, CategoryOrTraversal, Reference, Difference >
but const pointers to Value are incorrectly passed as the last argument (i.e. Difference) while ptrdiff_t is expected. It causes wrong instantiation of count() and count_if() algorithms used by isomorphism() one.

I would like to present my fixes of these problems in LEDA adapter for review. Thanks!
",iouri.smirnov@…
1315,iterator_adaptor does not work with incomplete Value types,iterator,Boost Development Trunk,To Be Determined,Feature Requests,jeffrey.hellrung,new,2007-10-11T12:05:46Z,2012-11-22T15:52:09Z,"boost::iterator_adaptor doesn't work when the associated Value type is incomplete,
at least in MSVC++ 8.0 (my hunch is that the problem is general). The following
{{{
#include <boost/iterator/iterator_adaptor.hpp>

template<typename T>
struct my_iterator:
  boost::iterator_adaptor<my_iterator<T>,T*>
{
};

struct foo
{
  my_iterator<foo> it;
};

int main(){}

}}}
results in:
{{{
...\boost\type_traits\is_pod.hpp(34) : error C2139: 'foo' :
an undefined class is not allowed as an argument to compiler
intrinsic type trait '__is_pod'
    ...\sandbox.cpp(10) : see declaration of 'foo'
    ...\type_traits\is_pod.hpp(128) : see reference to class template
    instantiation 'boost::detail::is_pod_impl<T>' being compiled
[...]
    ...\boost\iterator\iterator_facade.hpp(652) : see reference to
    class templateinstantiation 
    'boost::detail::operator_brackets_result<Iterator,Value,Reference>'
    being compiled
    with
    [
        Iterator=my_iterator<foo>,
        Value=foo,
        Reference=foo &
    ]
[...]
}}}
Although this is probably not a bug strictly speaking, it would be fine
if iterator_adaptor could be made to work with incomplete Value types,
just as the canonical model for iterators, Value*, does.",Joaquín M López Muñoz
1303,Per-target resource limits.,build,,Boost.Jam 4.0.0,Feature Requests,Vladimir Prus,new,2007-10-07T18:52:16Z,2012-10-16T07:14:53Z,"The -lN options is a nice addition, but it's a rather blunt tool. Martin is wanting a system where one can limit the resources used by individual actions. Currently he does something like it on Linux with the use of a launcher script. It would be good to provide that functionality in a portable manner in bjam. Tasks would be:

  * RLIMIT_CPU, RLIMIT_DATA, etc. target variables.
  * Change current time limit code to check the RLIMIT_CPU target var and using that instead of the -lN value.
  * Implement other limits as possible.
",René Rivera
1288,Quickbook article info needs expansion to include more bibliographic info,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-09-27T11:13:20Z,2014-04-09T02:19:17Z,"Quickbook article info needs expansion to include more bibliographic info

[@ http://www.oasis-open.org/docbook/documentation/reference/html/biblioset.html Docbook Bibliographic info]

It is unclear which items are to appear on the front page (and indeed I think there is a bug in that this

[article Math Toolkit
    [quickbook 1.4]
    [copyright 2006-2007 John Maddock, Paul A. Bristow, Hubert Holin and Xiaogang Zhang]
    [purpose ISBN 0-9504833-2-X  978-0-9504833-2-0]
    [license
        Distributed under the Boost Software License, Version 1.0.
        (See accompanying file LICENSE_1_0.txt or copy at
        [@http://www.boost.org/LICENSE_1_0.txt])
    ]
    [authors [Maddock, John], [Bristow, Paul A.], [Holin, Hubert], [Zhang, Xiaogang]]
    [category math]
    [purpose mathematics]
    [/last-revision $Date: 2007-09-24 11:12:19 +0100 (Mon, 24 Sep 2007) $]
]

Note the TWO [purpose...] blocks.

produces this XML

  <articlepurpose>mathematics</articlepurpose> 
  <articlecategory name=""category:math"" /> 
  </articleinfo>
  <title>Math Toolkit</title> 
  <para>ISBN 0-9504833-2-X 978-0-9504833-2-0</para> 

Actually this would be best as <isbn>  - but of course it needs to be printed.

This needs my needs to show an ISBN on the front page for now, but is a kludge!
",Paul A. Bristow
1279,Make sure multiple #import of a file imports the file only once.,quickbook,Boost 1.34.1,To Be Determined,Tasks,Daniel James,assigned,2007-09-24T06:37:48Z,2013-09-29T11:21:32Z,,Joel de Guzman
1264,Add option to specify qbk file to use.,quickbook,Boost Development Trunk,To Be Determined,Tasks,Joel de Guzman,new,2007-09-13T23:49:27Z,2007-10-28T15:02:03Z,"Need to add an option to let users specify the backend qbk file to use in generation (which would be found in the search path). This brings up the question of how to supply the default boostbook backend. In particular, if we want to keep the simple distribution of a single executable, the need to embed the default backend into the code.",René Rivera
1251,Implement RSS backend for Quickbook.,quickbook,Boost Development Trunk,To Be Determined,Tasks,René Rivera,new,2007-09-12T20:25:11Z,2007-10-28T22:43:39Z,"Implement backend for Quickbook that generates RSS feed files. This is to have the Boost website news items edited in the easier Quickbook, and have them be automatically generated for inclusion in the website.",René Rivera
1236,email addresses of bug submitters should be obfuscated on publicly visible Trac pages,xpressive,Boost.Build-M3,Website 1.X,Library Submissions,Douglas Gregor,reopened,2007-09-08T18:34:17Z,2017-01-09T13:34:58Z,If you ask bug submitters on Trac to use a valid email address you should not make these addresses publicly visible or at least obfuscate them such that naive email spiders overlook them.,Stephan Tolksdorf <andorxor (at) gmx (dot) de>
1227,Original/Signed/Unsigned Integer Variant Selection Templates,integer,,To Be Determined,Feature Requests,Daryle Walker,new,2007-09-02T20:06:24Z,2008-07-13T21:59:21Z,"Add new integer selection templates to ""boost/integer.hpp"" for
  *  The underlying type for a given integral type.  This could be called `underlying` and would map
    *  `char` to whichever of {`signed char`, `unsigned char`} that shares the same values (section 3.9.1, paragraph 1 of the 2003 C++ standard)
    *  `wchar_t` to its underlying type (paragraph 5 of the same part of the standard)
    *  any other type to itself (This includes `bool` because it could be implemented distinctly from any other integral type.)
    *  (Someday: extend this to find the underlying type of an enumeration)
  *  Find the unsigned equivalent of a given signed integral type, like the `get_unsigned` examples at source:/tags/Version_1_34_1/boost/boost/typeof/int_encoding.hpp and source:/tags/Version_1_34_1/boost/boost/wave/util/flex_string.hpp
  *  Find the signed equivalent of a given unsigned integral type, as a dual to the previous point (for both templates, non-matching types return themselves)",Daryle Walker
1215,"Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33)",mpl,Boost 1.34.1,To Be Determined,Bugs,Aleksey Gurtovoy,assigned,2007-08-26T15:31:24Z,2010-01-25T01:20:08Z,"#if defined(_MSC_VER) is not the right thing for MinGW because _MSC_VER is defined but the compiler is still from GNUs Compiler Collection. But i am not sure about the MinGW support in general.

Regard, Hans.",hfp@…
1207,"Method ""from_julian_day_number"" (class gregorian_calendar) not documented",date_time,Boost 1.38.0,Boost 1.51.0,Feature Requests,az_sw_dude,assigned,2007-08-23T10:19:03Z,2012-07-01T17:53:56Z,"please could you put the method gregorian_calendar::from_julian_day_number() in the documentation ?
library: date_time

thanks

gizmo",thom_schu@…
1206,Document escaping from within code.,quickbook,Boost 1.34.1,To Be Determined,Bugs,Daniel James,new,2007-08-23T00:04:33Z,2014-04-09T02:18:11Z,"John:

Just another data point: escaping to BoostBook from within code doesn't work unless the escape is inside a macro:

template <class T>
struct function_traits
{
  static const std::size_t arity = __below;
  typedef __below result_type;
  typedef __below '''arg<replaceable>N</replaceable>_type''';
};

Does *not* process the escape, whereas:

[def __argN '''arg<replaceable>N</replaceable>_type''']
template <class T>
struct function_traits
{
  static const std::size_t arity = __below;
  typedef __below result_type;
  typedef __below __argN;
};

Does process the escape.  Took me a while to figure this out

",Joel de Guzman
1204,Non-breaking-space?,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-08-22T23:44:18Z,2014-04-09T02:19:00Z,"Joel:

>> >> I think we should take advantage of macros as much as possible
>> >> before considering any syntax addition. nbsp can definitely be
>> >> a macro, FWIW, e.g.:
>> >>     {{{[def _nbsp_ ['''&nbsp;''']]}}}

Rene:

> > Won't that break in most situations? Specifically because it won't have 
> > spaces around it to differentiate it from the context:
> >
> >     {{{[^-f_nbsp_/Jambase/]}}}

Dave:

At my urging, docutils ended up with a ""breaking non-space"".  That is,
if you escape a regular space it just separates docutils tokens with
no other significance.  Thus:

  {{{[^-f\ _nbsp_\ /Jambase/]}}}",Joel de Guzman
1203,Decouple the backend,quickbook,Boost Development Trunk,To Be Determined,Feature Requests,-,new,2007-08-22T23:40:19Z,2017-08-26T15:51:04Z,"See http://tinyurl.com/2xsa2c

Basically, the first step is to reduce the c++ code and convert as many markups as possible to (quickbook) templates, leaving only a few intrinsics. Rene (Rivera) is working on this right now.
",Joel de Guzman
1201,Regexify the syntax highlighter,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Andreas Pokorny,assigned,2007-08-22T23:27:56Z,2007-08-26T09:37:26Z,"What I'd really want is to Regex-ify the syntax highlighter and
have them reconfigurable as user-supplied regex strings from
configuration files. This would simplify our life a lot. There'll
be only one syntax highlighter grammar and code that can accept
various lexer files. Our job then is just to churn out various
lexer files for different languages.

",Joel de Guzman
1200,Revamp the header information,quickbook,Boost 1.34.1,To Be Determined,Tasks,Daniel James,new,2007-08-22T23:24:24Z,2014-04-09T02:28:04Z,"(see this thread for context: http://tinyurl.com/2b9ywv)

Allow a couple of the (header) items there to be *overridden* in 
included files. Example:

* copyright (a) or (b)
* authors (a) or (b)
* license (a) or (b)
* last-revision (a), if it's more recent than current value

where:

a) Merge with the current value.
b) Use new value only for current file/doc.

I took out all the ones you have as (c) -- Ignore the new value.
I also took out source-mode since this can already be overridden.

So, these overrides can be placed anywhere. Example:

main.qbk

     [library foo
         [quickbook 1.4]
         [version 1.4]
         [copyright 2006 Joe Bloke]
         [authors [Bloke, Joe]]
         [purpose Whatever...]
         [license
             Distributed under the Boost Software License, Version 1.0.
             (See accompanying file LICENSE_1_0.txt or copy at
             [@http://www.boost.org/LICENSE_1_0.txt])
         ]
         [last-revision $Date: 2006/09/16 09:21:08 $]
     ]

include.qbk

     [license
         Distributed under the Boost Software License, Version 1.0.
         (See accompanying file LICENSE_1_0.txt or copy at
         [@http://www.boost.org/LICENSE_1_0.txt])
     ]

     [last-revision $Date: 2006/09/16 09:21:08 $]

John (M): 

I like the way this is going, but I would actually prune the list of
overrides a little more:

[last-revision...]

Definitely needed, as per my original post :-)

[quickbook....]

Also needed so that individual includes can start using new features without
having to go through and fix errors in the whole doc.

[version...]

Not sure about this one, shouldn't a library have a single version number?

[copywrite...][authors...]

These would be useful to have: especially for ""meta-libraries"" like
Boost.Math which has many sub-components by different authors.

The ideal world senario - probably not possible (!) - would be to merge all
the author names onto the main front page, but for sections just to include
the authors who worked on that section.  Does that make sence?

[purpose...]

Isn't this used just once on the main page, or maybe the index of libraries?
I don't see any great advantage to having more than one such block.

[license...]

Given that everything should be under the same license (as far as Boost is
concerned anyway), having more than one such block just complicates things.

",Joel de Guzman
1190,Markups inside simple markups,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-08-20T07:36:19Z,2010-07-10T15:29:23Z,"Stjepan Rajko wrote:
> On 7/29/07, Joel de Guzman <joel@boost-consulting.com> wrote:
>> Stjepan Rajko wrote:
>>> If I have a template ProducerConcept and I write:
>>>
>>> ['[ProducerConcept]]
>>>
>>> the template gets expanded and written in italics, but if I write:
>>>
>>> /[ProducerConcept]/
>>>
>>> I get [ProducerConcept] in italics, i.e. the template does not get
>>> expanded.  Is this intended? Seems a bit weird.
>> This is documented:
>
> Doh!  Yep, right there it is... sorry for the noise.
>
>> I know a way to relax these limitations, but it will involve some
>> complexity. I am not sure yet if the added complexity is worth it.
>>
>
> I don't see it as necessary.  I was just confused, due to having
> missed the relevant parts of the docs.

Don't brush it off just yet. There's the principle of ""least
surprise"". If this behavior is surprising, regardless if it
is documented or not, then it must be reconsidered. ",Joel de Guzman
1181,[boost.python] can modify enum value,python USE GITHUB,Boost 1.34.0,To Be Determined,Bugs,troy d. straszheim,new,2007-08-14T08:17:12Z,2009-10-11T00:27:51Z,"I use boost 1.34.0, python 2.5.1
User can modify the enum value, But enum should be a const value(read only).

{{{
#!cpp
enum my_enum{my_value};
struct my_s{ enum{ my_value2 };};

void my_export
{
    enum_< my_enum >(""my_enum"") .value(""my_value"", my_value);
    scope* my_s_scope = new scope(class_< my_s>(""my_s"", init<  >()));
    scope().attr(""my_value2"") = (int)my_value2;
    delete my_s_scope;
} 
}}}

{{{
#!python
#in python
module.my_enum.my_value = 1
print module.my_enum.my_value
module.my_s.my_value2 = 2
print module.my_s.my_value2
# we can modify the const value.
# output 
#  1
#  2
}}}",qiaozhiqiang@…
1180,[boost.python] def_readwrite need a default docstring,python USE GITHUB,Boost 1.34.0,To Be Determined,Feature Requests,troy d. straszheim,new,2007-08-14T07:52:16Z,2009-11-01T20:00:28Z,"the default docstring defined by def_readwrite is null, 
can boost.python add the type name of my_s::a as the default docstring? like the function's ""C++ signature"" docstring.

{{{
#!cpp
struct my_s
{
	int a;
};

void export_module
{
      class_<my_s >  s_class(""my_s"", init<  >());
      s_class.def_readwrite(""a"", &my_s::a);// __doc__ is empty, can boost.python add the type name of my_s::a as the default docstring? like the function's ""C++ signature"" docstring.
}

// I do this like this:
// get type name of data member of class 
template<typename T, typename C>
char const* MemberTypeName(T C::*)
{
	char const* name = typeid(T).name();
	return name;
}

// boost::python def_readwrite no docstring
// read write property
#define DEF_READWRITE(n, p) \
	def_readwrite((n), (p), std::string(""read write property, type is "") + MemberTypeName(p)).c_str())



void export_module
{
      class_<my_s >  s_class(""my_s"", init<  >());
      s_class.DEF_READWRITE(""a"", &my_s::a);// replace all auto genarated def_readwrite to DEF_READWRITE.
}
}}}
",qiaozhiqiang@…
1178,Regular expression min match length,regex,Boost 1.34.1,To Be Determined,Feature Requests,John Maddock,new,2007-08-14T07:36:05Z,2009-05-08T11:07:57Z,"From the mailing list:

I need to calculate, given a regular expression, the min length for a match.
For example if I have as regexp ^HTTP.*, 4 is the min length required for a match.",anonymous
1175,Document quickbook's (lack of) unicode support.,quickbook,Boost 1.34.1,To Be Determined,Tasks,Daniel James,assigned,2007-08-13T11:23:21Z,2009-06-06T13:47:40Z,See http://tinyurl.com/35j57v,Joel de Guzman
1172,non-utf,quickbook,Boost 1.34.1,To Be Determined,Bugs,Daniel James,new,2007-08-13T11:16:08Z,2014-04-09T02:17:50Z,"Rene Rivera: i was converting some word and html docs today and noticed that i
was pasting in non-ascii (and non-utf) into my qbk files. which quickbook would 
faithfully copy into the resulting boostbook. this would cause xsltproc to choke 
with an error. not sure if anything can be done. just thought you'd like to know.",Joel de Guzman
1159,bibliography support,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-08-10T07:21:32Z,2014-04-09T01:58:13Z,"All (especially documenters),

I seem to be rewriting much of the Boost.Graph documentation as I  
slowly translate it into quickbook format, and augment it with  
concepts from my SoC project. However, I've run into a ""small-ish""  
missing feature in quickbook that I might need to do the job  
correctly: bibliography support. Boost.Graph has a (growing)  
bibliography of about 60 different references.

What I would like to be able to do is something like this...

# somewhere in graph.qbk
[include bibliography.qbk]

The bibliography should contains a set of structured records that  
define bibliographic entries that we can cite in then documentation   
proper. It would probably be worthwhile to support a number of  
different entry types.

# book references
[bibbook
   [authors [Aho, A.V.] [Hopcroft J.E.] [Ullman J.D.]]
   [title Data Structures and Algorithms]
   [year 1983]
   [publisher Addison-Wesley]
]

# journal articles
[bibarticle
   # ...
   [journal [title Software - Practice and Experience] [volume 25]  
[issue 8]]
   [year 1995]
   [date Aug]
   [pages 863-889]
]

# conference proceedings
[bibproceedings
   # ...
   [conference 23rd International Conference on Software Maintenance]
   [location Paris, France]
   [year 2007]
   [date Oct 2-5]
]

There are probably others to support (i.e., theses and  
dissertations). Citations should be easy since they're basically just  
links. A citation might look something like:

[bibref aho_1983_data_structures_and_algorithms]

This could generate something like:

[<a href=""...#..."">Aho'1983</a>]

Although there are a number of different represent references. They  
could simply be numbers.

Does this sound like something that might be useful for quickbook? I  
was thinking about trying to write it myself, but I'm a little busy  
between SoC and my narrowing down a dissertation topic. I still might  
give it a shot, but I don't really know anything about the back-end  
formatting.

Thoughts? Comments?

Andrew Sutton
asutton@cs.kent.edu",Joel de Guzman
1158,optional named parameters,quickbook,Boost 1.34.1,To Be Determined,Feature Requests,Daniel James,new,2007-08-10T07:16:54Z,2014-04-09T01:58:37Z,"Can templates notation be extended to use optional named
parameters (onp). I am thinking in:

Template definition:

[template tname [a b c]
    [onp_1 default_1]
    [onp_2 default_2]

This is the template body...
use unamed forced parameters: [a]
use onp parameters: [onp_1] (This prints the value or the default)
[onp_1? if was used do this : if not do this ]

]

IMO this is a good extension and is backward compatible with the
current implementation.",Joel de Guzman
1136,Let BOOST_CHECK_EQUAL support std::wstring,test,Boost 1.34.1,To Be Determined,Feature Requests,Gennadiy Rozental,new,2007-08-03T05:22:59Z,2014-01-03T07:58:12Z,"e.g.
{{{
std::wstring s1,s2;
BOOST_CHECK_EQUAL(s1, s2);
}}}
",pop.atry@…
1125,parse_config_file should be mentioned in the How To,program_options,Boost 1.34.1,To Be Determined,Feature Requests,Vladimir Prus,reopened,2007-07-28T08:58:45Z,2012-02-01T02:30:28Z,"Hi,

> po::store(po::parse_config_file(is, desc), vm);

The very useful parse_config_file function should be mentioned in the How To and in the examples.",Olaf van der Spek <OlafvdSpek@…>
1107,Add weak_use_count to weak_ptr as a debugging aid,smart_ptr,,To Be Determined,Feature Requests,Peter Dimov,new,2007-07-21T23:20:18Z,2011-02-24T22:11:09Z,"http://lists.boost.org/Archives/boost/2006/03/102620.php

  This is a feature request to add weak_use_count() to weak_ptr.

  I am not interested in this feature for anything else than a debugging
  aid. Recently, a weakness was highlighted in one of my projects, I had
  stale weak_ptr objects that would remain in core even if all copies of
  weak and shared pointer objects should have been eliminated by now.

  To confirm the bug fix and audit the rest of the code base, a debugger
  was used to set a conditional break point on internal members of
  weak_ptr. I would rather have the ability to write assertions when
  needed hence weak_use_count().",Peter Dimov
1094,Finding the correct library to link (feature  request for pkg-config support)h,build,,Boost 1.42.0,Feature Requests,Vladimir Prus,assigned,2007-07-16T17:41:27Z,2018-06-06T12:34:57Z,"This bug report is a feature request for the addition of pkg-config support to Boost, in order to provide a simple, reliable, platform-independent mechanism for discovering if the Boost libraries are installed, what they are called, where they are installed, and how to link with them.  This is currently not possible to achieve.  A detailed rationale and an example for how to implement this follow.


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

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


To illustrate my problem:

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

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

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


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

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

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

AC_CHECK_HEADERS([tr1/tuple])

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

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

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

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

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

AC_SUBST([BOOST_LIBS])

---configure.ac----

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


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

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

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

You can generate this from a template:

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

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

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

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

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


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


You may find much more detailed discussion of these issues at

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

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


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.",rleigh@…
1090,scoped_file class that deletes file at end of scope,filesystem,,To Be Determined,Feature Requests,Beman Dawes,new,2007-07-13T12:35:23Z,2008-06-30T10:01:47Z,"I've found myself wanting this on a couple of occasions with 1.33.1, and I've done it with boost::shared_ptr:

{{{
#!c++
boost::shared_ptr<fs::path> removeFile(&file, bind(&fs::remove, boost::cref(file)));
}}}

That didn't work with 1.34.1 (maybe due to compiler intricacies), so I did it properly:

{{{
#!cpp
class scoped_file {
public:
    explicit scoped_file(const std::string& file) : m_path(file, boost::filesystem::native) {}
    explicit scoped_file(const boost::filesystem::path& file) : m_path(file) {}

    ~scoped_file() { boost::filesystem::remove(m_path); }

private:
    boost::filesystem::path m_path;
};
}}}

That might be something to add?",Marcus Lindblom <macke@…>
1088,Docs for template escape feature.,quickbook,,To Be Determined,Tasks,René Rivera,new,2007-07-12T01:31:21Z,2007-07-12T01:31:21Z,Write docs for the new template escape QuickBook feature.,René Rivera
1049,Getting mpl/has_xxx.hpp to compile on AIX,mpl,,To Be Determined,Patches,Aleksey Gurtovoy,new,2007-06-13T08:23:52Z,2016-11-18T01:36:06Z,"Moving the class gcc_3_2_wknd out of the enclosing class scope into the namespace scope makes thius compile on AIX.

The attached patch was for 1.33.1",troyer@…
1045,[multi_array] Need a proper swap operation,multi_array,Boost 1.34.0,To Be Determined,Feature Requests,Ronald Garcia,new,2007-06-08T16:35:05Z,2018-03-29T13:33:04Z,"See [http://lists.boost.org/Archives/boost/2007/05/121165.php this email] which was unanswered.

Basically, a proper pointer swap operation would be both efficent and useful.

(P.S. multi_array is not listed in components?)",Marcus Lindblom <macke@…>
1020,Boost.Iterator proposal to add is_constant_iterator,iterator,,Boost 1.36.0,Patches,jeffrey.hellrung,new,2007-05-31T18:49:35Z,2012-11-21T22:29:10Z,"I propose to add a new trait to the Boost.Iterator library: `is_constant_iterator`. The trait is applied to an iterator and returns true if the iterator's reference type is a constant reference and false if the type is a non-constant reference. The trait will fail to compile when applied to iterators having non-reference reference types.

This addition would make it easier to use library components like `iterator_facade` and `iterator_adaptor` for implementing container iterator wrappers like this:
{{{
  template< NodeItT >
  struct MyIterator :
      public iterator_facade<
          MyIterator< NodeItT >,
          typename mpl::if_<
              is_constant_iterator< NodeItT >,
              const value_type,
              value_type
          >::type,
          typename iterator_category< NodeItT >::type
      >
  {
  };
}}}
Here `NodeItT` is a wrapped iterator and may be a `const_iterator` or `iterator` of a container.

Another use case is when a user wants to detect whether an iterator is `const_iterator` or `iterator`. An example of this: implementing functionality of iterator translation similar to Boost.MultiIndex `project` method.

I've attached an archive with the implementation, tests and patches to documentation. The implementation, in addition to the abovementioned functionality, supports `std::vector< bool >` iterators, though their reference types are not references.
",andysem@…
973,zip_iterator has value_type == reference,iterator,Boost 1.34.0,,Bugs,jeffrey.hellrung,new,2007-05-21T04:27:20Z,2012-12-02T08:18:41Z,"That looks wrong to me.  See http://groups.google.com/group/comp.std.c++/browse_frm/thread/9c40ffc2f6394ca0/89ef062ddcb231e7
",anonymous
957,"The ""Getting Started"" page does not mention the stdlib option",Getting Started Guide,Boost 1.34.0,To Be Determined,Bugs,Thomas Witt,new,2007-05-15T06:24:41Z,2009-05-13T06:37:26Z,"The ""Getting Started"" page does not mention the stdlib option, that allows to compile using STLport for example.

Also, maybe it is also worth mentionning that using STLport when compiling Boost leads to linking error when the box is linux (and maybe other unix OS). See http://lists.boost.org/boost-users/2007/04/26818.php",Vincent Torri
889,Insane Dependencies,date_time,None,,Feature Requests,az_sw_dude,assigned,2007-04-09T23:07:09Z,2009-11-22T20:03:13Z,"{{{
From: helvey@accelrys.com

Simply including boost/date_time/posix_time headers causes build times to skyrocket. Building a file that includes boost/date_time/posix_time/posix_time.hpp takes almost a minute, removing the header drops the time to less than a second.
Also why no conversions to time_t? It would be nice not to have include the header outside of translation units. :)
}}}",nobody
863,[parameter] fix operator|| for lazy binding,parameter,Boost 1.34.0,To Be Determined,Patches,Daniel Wallin,new,2007-03-21T16:47:54Z,2007-07-03T14:56:17Z,"Apply with 'patch -p0 < djw_lazy_binding.patch' from the boost root directory. See discussion here http://tinyurl.com/26kwnh.
",daniel_walker@…
857,add shared_ptr< const T> support,python USE GITHUB,Boost 1.34.0,To Be Determined,Patches,Dave Abrahams,new,2007-03-20T20:27:00Z,2009-09-18T01:02:01Z,"This patch adds support to Boost.Python library to handle boost::shared_ptr< const T> class.

The problem and solution were discussed in this thread:
http://mail.python.org/pipermail/c++-sig/2006-November/011626.html",roman_yakovenko@…
850,program_options strips off escaped quotes in some situations,program_options,None,Boost 1.42.0,Bugs,Vladimir Prus,reopened,2007-03-09T20:56:52Z,2012-02-02T22:29:39Z,"{{{
boost::program_options strips off escaped quotes from command line strings like -a ""\""quoted value\"""".  A command line string like -a ""\""quoted value\"" unquoted_value"" does not have its escaped quotes striped out.

I am using program_options in Windows to parse the command line of my application.  One of the requirements is that I be able to pass in the command line of a different application such as the following:
myapp -c ""\""c:\App versions\App v1\App.exe\"" -a \""A Value\"" -b Another_Value""

In this case, program_options will correctly parse out the value of the parameter c to be:
""c:\App versions\App v1\App.exe"" -a ""A Value"" -b Another_Value

However, if I pass in the following:
myapp -c ""\""c:\App versions\App v1\App.exe\""""

program_options parses c as:
c:\App versions\App v1\App.exe

Note that the escaped quotes were stripped off instead of preserved like you would expect.  This is a problem because my application immediately turns around and calls ::CreateProcess using the value of the c parameter.   ::CreateProcess' documented behavior is that it executes the first match it can find of c:\App.exe, c:\App versions\App.exe, and c:\App versions\App v1\App.exe.  The only way you can stop this behavior is by enclosing the file path in quotes.

The code I'm using to get the options is pasted below.  Please email me with any questions.  Thanks!

--------------------

pair<string, bool> CCmdLineParser::GetParam(const string& sParamName)
{
	Run(); // Make sure we're parsed
	if (!Impl_.bOptionsDescribed && !Impl_.bPositionalOptionsDescribed)
		return GetUnregisteredParam_(sParamName);
	return Impl_.RegisteredOptions.count(sParamName)
		? make_pair(Impl_.RegisteredOptions[sParamName].as<string>(), true) : make_pair("""", false);
}

void CCmdLineParser::Run(void)
{
	if (Impl_.bInitialized)
		return;
	Impl_.bInitialized = true;

	// Create parser
	command_line_parser Parser(split_winmain(AfxGetApp()->m_lpCmdLine));
	bool bUnregistered = !Impl_.bOptionsDescribed && !Impl_.bPositionalOptionsDescribed;

	// Setup parser
	Parser.options(Impl_.OptionsDesc); // Always required (even if empty) because command_line_parser::run() asserts it
	if (Impl_.bPositionalOptionsDescribed)
		Parser.positional(Impl_.PositionalOptionsDesc);
	if (bUnregistered)
		Parser.allow_unregistered();

	// Parse
	parsed_options ParsedOptions = Parser.run();

	// Retrieve
	// We can't call store on something with unregistered options.  It throws an exception even if you specifically
	// call allow_unregistered().  This is a known bug.  It is fixed in the boost CVS tree, but not released yet.
	// What all of this basically means if that we can't mix registered and unregistered options (yet).
	if (bUnregistered)
		Impl_.UnregisteredOptions = collect_unrecognized(ParsedOptions.options, include_positional);
	else {
		store(ParsedOptions, Impl_.RegisteredOptions);
		// notify() is required for automatic value storage and default values
		notify(Impl_.RegisteredOptions);
	}
}
}}}",apoxy
810,support for weak_ptr binding ,smart_ptr,None,To Be Determined,Feature Requests,Peter Dimov,new,2007-01-11T19:56:30Z,2013-12-11T22:00:10Z,"{{{
Hello,

recently i faced with problem - i was not able to pass weak_ptr to bind() function. I started to study why and found there is no support for this in boost.

As result, me and my friend wrote ""get_pointer"" version
which accepts weak_ptr. 

At actual call moment, implementation uses weak_ptr::lock() to get shared_ptr. If retrieved shared_ptr is invalid, then exception of type ""disposed_exception"" thrown.

This code was tested on Windows XP SP2 with following compilers: VC6, VC7, VC7.1, VC8, g++ 3.2.3 (MinGW), g++ 3.4.4 (Cygwin).

If you find this code is useful for someone else me, please add to boost (it's actually not a library, this is why i'm poosting it to ""patches""). You can find sources + test app in attachment.


Thank you,
Dmytro Gokun
}}}",nobody
799,mpl::if_,mpl,Boost 1.45.0,Boost 1.46.0,Feature Requests,Joel Falcou,new,2006-12-22T12:20:30Z,2011-01-06T10:33:31Z,"{{{
There is an alternative implementation of mpl::if.
This implementation makes code clearer.

We can write:
typename if_
<
  X,
  Y
>
::else_if
<
  Z,
  U
>
::else_
<
  V
>::type

The implementation can be found here:
http://cbear.berlios.de/meta/if.hpp
}}}",nobody
795,[ublas] vector::back(),uBLAS,None,,Feature Requests,Gunter,new,2006-12-15T16:18:15Z,2011-05-07T17:33:49Z,"{{{
It would be nice to have this useful, nice little member...

T& back() {
 return *rbegin();
}

and

const T& back() const {
 return *rbegin();
}

}}}",slyilmaz
746,max flow with lower bounds (capacities),graph,None,To Be Determined,Feature Requests,Douglas Gregor,new,2006-10-06T21:51:10Z,2010-12-08T19:44:29Z,"{{{
hello

If I use the push_relabel_max_flow.hpp with only 
upper capacities everything works fine, but now I 
need to include lower capacities.
How can I do this and how can I compute the new flow 
values afterwards?

yours
jens
}}}",jens-
714,[jam] HardLink rule on NT platform,build,Boost Development Trunk,To Be Determined,Feature Requests,Vladimir Prus,new,2006-08-23T10:16:26Z,2007-12-06T04:17:41Z,"{{{
I've installed boost and noticed that HardLink rule on
NT copies file although NT has support for hardlinks
(on NTFS, of course).

To use this feature while installing boost i've created
file hardlink.bat with following contents:

fsutil hardlink create %2 %1

and put it into %WINDIR%\system32

also i've changed line 194 of
tools\build\v1\allyourbase.jam file from

    LN              ?= $(CP) ;

to

    LN              ?= hardlink ;

these changes allowed me to save about 600 M of my
harddisk space. Not a big deal, yes, but otherwise
these 600M would exceed my disk space :-)

I think my solution is not ideal, but it could be
helpful for people. So maybe it will be included in
boost distibution, when adapted.

Thanks.
mailto: forums (dog here) green dot nsk dot ru
}}}",nobody
605,Support different DST rules in timezone db based on years,date_time,None,,Feature Requests,az_sw_dude,assigned,2006-04-17T13:20:56Z,2010-11-28T06:27:44Z,"{{{
The boost time library supports processing of the
timezone database file as a .csv, with one entry per
time zone, such as ""America/New_York"".  However, in
2007, the daylight savings time rules will change.  The
contents of the csv need to change, to incorporate a
range of effective years.  Since DST is a spring and
fall event (in both north and south hemispheres) only a
year need be recorded.

I suggest adding two values at the beginning of the
line, (as one field in the form nnnn-nnnn) for the low
effective-year and high effective-year, as 4-digit
values.  Let 0000 be used for ""all previous years"" and
9999 be used for all subsequent years.  [If the '-'
separator is a problem, ':' could be used instead.]

Then, the change in 2007 can be recorded as two lines:
""2007-9999"",""America/New_York"", ...
""0000-2006"",""America/New_York"", ...

Lines unaffected by the change would have ""0000-9999""
as the first field.

}}}",nobody
403,Document copy_component,graph,None,Boost 1.46.0,Tasks,Douglas Gregor,new,2005-05-19T02:18:30Z,2010-12-08T19:45:17Z,"{{{
It's in boost/graph/copy.hpp, and useful, so we should document it.
}}}",Douglas Gregor
395,BGL graph types do not support allocators,graph,None,To Be Determined,Feature Requests,Douglas Gregor,new,2005-05-02T15:48:55Z,2010-12-08T19:44:18Z,"{{{
adjacency_list and adjacency_matrix should have an Allocator 
parameter, but they don't.
}}}",Douglas Gregor
380,Support for bundled properties in graph adaptors,graph,Boost 1.50.0,To Be Determined,Bugs,Douglas Gregor,reopened,2005-03-28T21:21:38Z,2012-09-07T08:18:57Z,"{{{
The graph adaptors (such as subgraph) do not support bundled 
properties, but they should.
}}}",Douglas Gregor
375,LEDA graph adaptors do not handle hidden nodes properly,graph,None,,Bugs,Jeremiah Willcock,reopened,2005-03-22T15:39:07Z,2012-01-04T23:33:38Z,"{{{
Hidden nodes are completely ignored by the LEDA graph adaptors. 
This may cause problems when, for instance, there are hidden 
nodes but the equivalent of vertex_index is used to construct a 
(BGL) property map. The LEDA adaptors should probably take the 
same approach as filtered_graph: let num_vertices() return the 
number of the nodes in the graph plus the number of hidden nodes, 
but vertices() filters out the hidden nodes. Similarly for edges.
}}}",Douglas Gregor
373,LEDA graph adaptors for undirected graphs,graph,Boost 1.39.0,To Be Determined,Feature Requests,Jeremiah Willcock,reopened,2005-03-22T15:33:33Z,2012-01-04T23:32:03Z,"{{{
The LEDA graph adaptors in the BGL seem to work properly for 
directed graphs (the LEDA type GRAPH<...>), but there are no 
corresponding adaptors for the undirected LEDA graph type 
(UGRAPH<...>).

Undirected LEDA graphs follow a very different model than the 
undirected graphs in the BGL, which will require some special 
machinery. The LEDA type UGRAPH<...> is actually just a class 
derived from GRAPH<...> that applies the ""make_undirected()"" 
member function upon initialization. make_undirected() moves all of 
the in-edges of each vertex to the out-edges list. This has several 
unfortunate consequences:
  1) The in-degree of an undirected LEDA graph is always zero, even 
when the out-degree is greater than zero. The in_edges list is 
therefore empty.
  2) When traversing the list of out-edges for a vertex u, the edges 
returned may have u as their target but not their source. This breaks 
an important invariant in the BGL, which mandates that source(e, 
g)==u if e came from out_edges(u, g). Similarly for in-edges.

Thus, an undirected LEDA graph adaptor will need to introduce 
special adaptors for the out_edge_iterator and in_edge_iterator 
types, which return a new edge_descriptor type for LEDA that can 
swap the source and target of a LEDA edge as needed. Additionally, 
graph-mutating operations (such as add_edge) may need to ensure 
that the graph remains undirected, as if make_undirected() had been 
called.
}}}",Douglas Gregor
231,Graph Header Clashes With Format Header,graph,None,,Bugs,jsiek,reopened,2004-02-05T19:38:38Z,2012-05-21T02:50:23Z,"{{{
The following code produces many errors in MSVC71


#include <boost/format.hpp> 
#include <boost/graph/adjacency_list.hpp>

int _tmain(int argc, _TCHAR* argv[])
{
	std::string s = (boost::format(""%1% %2% %
3%"") % ""a"" % ""b"" % ""c"").str();
	return 0;
}


}}}",schmoo2k