October 2014 - Boost - lists.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

[build] b2 headers broken?
by Eric Niebler 02 Mar '15

02 Mar '15

I just updated to the latest develop. I ran bootstrap, then nuked my boost directory and reran b2 headers. Worked fine. Then I changed directory to libs/proto/test and ran ../../../b2 mem_ptr to run a test. Here's what I get: f:\modular-boost\libs\proto\test>..\..\..\b2 mem_ptr Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes ...patience... ...patience... ...found 4951 targets... ...updating 441 targets... common.mkdir ..\..\..\bin.v2\libs common.mkdir ..\..\..\bin.v2\libs\proto common.mkdir ..\..\..\bin.v2\libs\proto\test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0 common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static\threading-multi link.rm ..\..\..\boost\mpl common.mkdir ..\..\..\boost\mpl link.hardlink ..\..\..\boost\mpl\print.hpp Hardlink created for ..\..\..\boost\mpl\print.hpp <<===>> ..\..\mpl\include\boost\mpl\print.hpp <snip> link.rm ..\..\..\boost\numeric\conversion link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp The system cannot find the path specified. if exist "..\..\..\boost\numeric\conversion\conversion_traits.hpp" del "..\..\..\boost\numeric\conversion\conversion _traits.hpp" mklink /H "..\..\..\boost\numeric\conversion\conversion_traits.hpp" "..\..\numeric\conversion\include\boost\numeric\ conversion\conversion_traits.hpp" ...failed link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp... link.hardlink ..\..\..\boost\numeric\conversion\int_float_mixture_enum.hpp The system cannot find the path specified. For some reason, b2 thinks it needs to rerun b2 headers, but it does a crap job of it and dies. What's going on? Eric

4 6

Interactive metaprogramming shells
by Abel Sinkovics 28 Dec '14

28 Dec '14

Hi, I've built interactive shells for preprocessor and template metaprogramming. I've been using them for development and debugging of metaprograms and I think Boost developers could also find them useful. You can type in (metaprogramming) expressions which get evaluated and the result is displayed immediately. For example you can type boost::mpl::push_front<boost::mpl::vector<int, char>, double>::type and you get boost_::mpl::vector<double, int, char> as the result (the boost_ namespace is used because there are some tricks there to make the output more readable). As an example for the preprocessor shell you can type BOOST_PP_REPEAT(3, foo BOOST_PP_TUPLE_EAT(3), ~) and you get foo foo foo as the result. The tools are based on the Boost.Wave library and Clang. You can get them here: Preshell for preprocessor: https://github.com/sabel83/preshell Metashell for template metaprograms: https://github.com/sabel83/metashell You can also try them from your browser here: http://abel.web.elte.hu/shell Feedback is welcome. Regards, Ábel

6 16

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

[coroutine] x86 msvc11 stack corruption
by Tobias Loew 12 Dec '14

12 Dec '14

Hi, I use Boost 1.55 uni-directional coroutines to build an x86 MSVC11 application. I have a simple pull-type (boost::coroutines::coroutine<void>::pull_type) that under certain reproducable conditions destroys the stack after returning from the coroutine. Here is the corrupted stack as shown by VS2012 > ebs2000.exe!CScriptMainFrame::DoRun(CPascalEditorDoc * 0x00000000, int 0x00000000, int 0x00000000) Line 3372 C++ ebs2000.exe!CScriptMainFrame::OnDebugStepover() Line 4916 C++ mfc110u.dll!_AfxDispatchCmdMsg(CCmdTarget *, unsigned int, int, void (void) *, void *, unsigned int, AFX_CMDHANDLERINFO *) C++ 00000002() Unknown [Frames below may be incorrect and/or missing] mfc110u.dll!CCmdTarget::OnCmdMsg(unsigned int, int 0x00000000, void *, AFX_CMDHANDLERINFO *) Line 364 C++ mfc110u.dll!CWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 2785 C++ mfc110u.dll!CFrameWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 389 C++ ... This only happens in windows x86 32-bit release-builds when the coroutine finishes upon a user-action that also includes a windows WM_SETFOCUS message on my menu-bar. If at least one of the following is true, the stack-corruption does NOT happen: - debug-build - x64 build - using a different pull-type, e.g. enum status_enum{...}; boost::coroutines::coroutine<status_enum>::pull_type - not returning form the coroutine, but pushing just before the end of the coroutine and swapping the pull-type-variable with a default constructed "not-a-coroutine" Even though I have a lot of workarounds, I still would like to know, why this happens. regards Tobias PS: I had to recompile ml /safeseh /c make_i386_ms_pe_masm.asm ml /safeseh /c jump_i386_ms_pe_masm.asm to get SAFESEH-libraries. -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Review request for Compute
by Antony Polukhin 10 Dec '14

10 Dec '14

Hi, Please add the the Compute library to the review schedule. Compute is a GPU/parallel-computing library for C++ based on OpenCL. Author: Kyle Lutz Source code: https://github.com/kylelutz/compute Documentation: http://kylelutz.github.io/compute/ Review Manager: Antony Polukhin Approximate review date: end of November - December 2014 -- Best regards, Antony Polukhin

2 2

Boost People section largely outdated
by Joaquin M Lopez Munoz 09 Dec '14

09 Dec '14

Hi, It is a pity that the Boost People section: http://www.boost.org/users/people.html is so outdated: many people there are no longer around, and, more importantly, many (most) current contributors are not listed. This is is a reminder for people to get themselves on that page! Instructions at http://www.boost.org/development/submissions.html#People Best Joaquín M López Muñoz Telefónica

3 2

[mpl] [build] [testing] Merge pull requests
by Andrey Semashev 08 Dec '14

08 Dec '14

Hi, There were a lot of discussions about MPL recently, and I created a few pull requests to address issues: https://github.com/boostorg/boost/pull/39 Invoke 'headers' target before building testing tools. Note that several testers are currently failing to run because of this problem. Since this affects the testing process, I'd appreciate if someone familiar with it could take a look. https://github.com/boostorg/boost/pull/38 Add MPL.Core tests to the test report. These tests are currently not run by testers. https://github.com/boostorg/mpl/pull/12 Move a misplaced header from MPL to MPL.Core to resolve circular dependency between the two. I believe the first PR is especially critical. Could someone with permissions merge these? Thanks.

13 52

[Range] New I/O functions for ranges
by Indiana 25 Nov '14

25 Nov '14

I'm currently putting together a proposal to the standards committee about a set of range I/O functions, but i think they would make a good addition to Boost as well. They would probably fit in the Range library - i don't think they warrant a library all of their own. The stuff i wrote for the standards proposal is available at http://cpp.indi.frih.net/rangeio/ - it goes into quite a bit of detail about the interface, and links to a sample implementation. But here's the executive summary: There is a single output function - currently called "write_all" - that takes a range and, optionally, a delimiter, like this: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 4>{1, 2, 3, 4}; cout << write_all(r); // prints "1234" cout << "{ " << write_all(r, ", ") << " }"; // prints "{ 1, 2, 3, 4 }" // END CODE /////////////////////////// It takes anything that works with range-for, so it works with range adaptors: // BEGIN CODE ///////////////////////// struct is_even { auto operator()(int x) const -> bool { return x % 2 == 0; } }; cout << write_all(r | reversed | filtered(is_even{})); // prints "42" // END CODE /////////////////////////// Note also that the delimiter doesn't have to be a string (there are some examples in the reference of that). Why not just use std::copy() and stream iterators? Several reasons - the most obvious of which you can see above: this syntax is much cleaner, much less error-prone, well-integrated with the existing stream I/O mechanisms, and it produces properly delimited output (unlike the delimited version of ostream_iterator). But also, stream formatting is properly handled: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 3>{1, 2, 3}; std::cout.width(3); std::cout.fill('0'); // --------------------------- // The old way: using std::begin; using std::end; std::copy(begin(r), end(r), std::ostream_iterator<int>{std::cout, ", "}); // even with Boost.Range, this just reduces to: //boost::copy(r, std::ostream_iterator<int>{std::cout, ", "}); // prints: "001, 2, 3, " // --------------------------- // The new way: std::cout << write_all(r, ", "); // prints "001, 002, 003" // END CODE /////////////////////////// And of course this works as expected in chained expressions: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; cout.width(3); cout.fill('0'); cout << '(' << setw(3) << setfill('0') << write_all(r, ',') << ')'; // prints: "(001,002,003)" // END CODE /////////////////////////// It is also possible to get more information about errors, and react better to them. If there is an error in the formatting or in the stream during an output operation using std::copy() and ostream_iterator, the algorithm will chug merrily along until it's all the way through the range even though it's no longer writing anything. You will have no way to detect where the problem occurred - did it fail after the first element was written, or *before*, or did it fail after the millionth element? If the range is begin lazy-generated, that could be particularly wasteful, or even problematic. By contrast, write_all() stops immediately when there is an error in the output stream. It is even possible get more information about the last range write operation by capturing the temporary object, like this: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; auto p = write_all(r); cout << p; if (!cout) { cerr << "only " << p.count << " elements written\n"; cerr << "next element would have been " << *p.next << '\n'; } // END CODE /////////////////////////// On the input side, there are 7 functions: * overwrite * back_insert * front_insert * insert * back_insert_n * front_insert_n * insert_n Overwrite simply replaces the contents of a range with whatever is read from input: // BEGIN CODE ///////////////////////// auto r = array<int, 100>{}; cin >> overwrite(r); // reads up to 100 ints // END CODE /////////////////////////// The *insert functions map to the *insert_iterators in the standard library, using push_back(), push_front(), or insert(). In each case: in >> ???insert(r[, i]); is basically equivalent to: copy(istream_iterator<value_type_of_r>{in}, // use braces on the next line, or face the most vexing parse istream_iterator<value_type_of_r>{}, ???inserter(r[, i])); The *insert_n functions are for the common case where you know in advance how many elements will be read, at maximum - or for when you want to limit the amount of elements read in a single read operation. This: in >> ???insert_n(r[, i], n); is conceptually equivalent to: copy_n(istream_iterator<value_type_of_r>{in}, n, ???inserter(r[, i])); except it can handle formatting and errors properly. The reference at http://cpp.indi.frih.net/rangeio/ goes into much more detail, of course. Why add it to Boost? Because these operations (reading/writing ranges) are so common they are almost universal, and there is no standard facility that handles them easily or well. They are not *difficult* to implement, but they are far from trivial - for example, you might think write_all() is just a simple range-for loop or for_each(), and it is... up until you add error checking, the delimiter, and formatting awareness. A sample implementation already exists - it can be implemented portably in pure standard C++11. (Can it be implemented in C++03 with? Good question. It might be possible with some Boost help, but it might require dependencies on libraries other than Boost.Range. If this proposal finds approval, that's something i can look into.) Would there be any interest in adding these functions to Boost.Range?

5 13

[dynamic_bitset] capacity(), reserve(), shrink_to_fit()
by Riccardo Marcangelo 24 Nov '14

24 Nov '14

Hi, I have implemented capacity(), reserve(), and shrink_to_fit() for dynamic_bitset. I find these useful and am surprised by their omission. I'm wondering if there is any interest in including them in Boost. Perhaps there are reasons why they're not implemented? Riccardo -- View this message in context: http://boost.2283326.n4.nabble.com/dynamic-bitset-capacity-reserve-shrink-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Changes in Boost.Optional
by Dean Michael Berris 24 Nov '14

24 Nov '14

Suppose I have the following type: struct container { boost::optional<uint16_t> optional() const { return value_; } private: boost::optional<uint16_t> value_; }; struct value_wrapper { value_wrapper(const container& c) : c_(c) {} operator uint16_t () { return 1; } operator boost::optional<uint16_t>() { return c_.optional(); } private: const container& c_; }; And that I have the following function: value_wrapper value(const container& c) { return value_wrapper(c); } The following used to work in MSVC 2010: container c; // leave c.value_ alone. boost::optional<uint16_t> some_value = value(c); assert(!some_value); Now with Boost 1.56, this breaks because the constructor for some_value from a temporary optional is now marked explicit. What is the work-around for the previous behavior to be regained? All the following changes cause the assertion to fail: boost::optional<uint16_t> some_value(value(c)); assert(!some_value); // some_value's constructor will use the uint16_t conversion operator, therefore some_value == 1 boost::optional<uint16_t> some_value = static_cast<boost::optional<uint16_t> >(value(c)); assert(!some_value); // same problem as above, the temporary created will favor the uint16_t conversion operator Help? PS. For better context, see https://github.com/cpp-netlib/cpp-netlib/blob/0.11-devel/boost/network/prot…

8 26

[Boost.DLL] Formal Review request
by Antony Polukhin 21 Nov '14

21 Nov '14

Dear Boost, Some time passed since checking interest in plugin development library and now all the requested features are implemented (self loading, getting symbol location, better docs, automatic platform-specific library decorations append, much more examples, listing library exports and so on...). While there's still some room for minor improvements, library API is stable and the library will benefit greatly from a larger user base and more feedback. So unless someone thinks the library isn't ready or would get rejected right away in its current state for reason X, I am requesting a formal review for Boost.DLL. Library location: https://github.com/apolukhin/Boost.DLL Library Docs: http://apolukhin.github.io/Boost.DLL/index.html -- Best regards, Antony Polukhin

10 40

Re: [boost] Is there interest in a library for string-convertible enums?
by Felix Uhl 05 Nov '14

05 Nov '14

Gavin Lambert wrote: > Features that I would expect of such a library: > - support for arbitrary non-contiguous values. > - enum value to string. > - string to enum value. That's done already. > - list of all valid values, either as strings or values. > - can indicate whether a given value (string or enum) is a member of > the enumeration. Easy, will do. > - can round-trip (enum -> string -> enum) values that are not members > of the enumeration; of course (string -> enum -> string) is not feasible > for non-members. What would a conversion from an enum that is not a member to a string look like? Should it just be converted to the string representation of the underlying type like “7”? Or something like “MyEnum::7”? Or would the string representation solve a term with bitwise OR like so: “one|two|four”? The latter would be very interesting for bitwise flag enums. > - can specify a custom string value that the enum value generates (not > just the BOOST_PP_STRINGIZE). Yeah I will implement that. Not sure why one would want it, it does nothing but induce confusion in my eyes, but I’m not the one to tell you what to do. > Features that would be nice, but not necessarily expected: > - enum to string and back for "bitwise flag" style enums (eg. CSV names). Not sure what you mean by that, because the regular string conversions work for those just as fine. Do you mean what I wrote above with the OR connected values in a string representation? > - some mapping to std::bitset or similar. That would be interesting! I’ve added it to the feature list, but it will probably take some time . > - can specify multiple string values that map to the same enum value. Hm. I’m not sure if I’d want that, or how that could even be implemented. If somebody wanted non-casesensitive behaviour, it would be better to use a std::string with custom char_traits, and that’s something I’ll definitely offer. > - can specify different conversion tables for the same enum type (for > use in different contexts, eg. serialisation vs. user output). I thought about that, too. I already give the option to choose between std::maps and a linear search for lookups, but I would really like to give the client more options. Those were good suggestions, thank you very much! You’ve given me quite some things to work on, but now I’ve got a pretty decent feature list. --- Felix Uhl Von: Gavin Lambert Gesendet: ‎Mittwoch‎, ‎29‎. ‎Oktober‎ ‎2014 ‎00‎:‎57 An: boost(a)lists.boost.org On 29/10/2014 00:09, Felix Uhl wrote: > So far, the only way to convert an enumeration value to a string is > a lot of boilerplate code consisting of switch case statements for > every single possible value of the enum. Not the only way. The method I use is to create a lookup table via a little macro magic. Granted that I'm then doing a linear scan through the table (whereas a switch statement could be more efficient, or knowledge that the enum is contiguous and could therefore do an index lookup), but having a table allows for other useful queries, and I wanted something that could be defined statically. As a side-benefit (that undoubtedly will horrify some people), the way the code was implemented also allows it to act as a string-to-member-pointer lookup table, which can be quite handy for typed property bags and the like with a string lookup key. > What features would you want from such a library? Features that I would expect of such a library: - support for arbitrary non-contiguous values. - enum value to string. - string to enum value. - list of all valid values, either as strings or values. - can indicate whether a given value (string or enum) is a member of the enumeration. - can round-trip (enum -> string -> enum) values that are not members of the enumeration; of course (string -> enum -> string) is not feasible for non-members. - can specify a custom string value that the enum value generates (not just the BOOST_PP_STRINGIZE). Features that would be nice, but not necessarily expected: - enum to string and back for "bitwise flag" style enums (eg. CSV names). - some mapping to std::bitset or similar. - can specify multiple string values that map to the same enum value. - can specify different conversion tables for the same enum type (for use in different contexts, eg. serialisation vs. user output). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2

[ANN] "The Boost C++ Libraries", 2nd edition available
by Boris Schäling 03 Nov '14

03 Nov '14

Just a quick announcement: The 2nd edition of my book "The Boost C++ Libraries" is available. - It introduces 72 Boost libraries. - It contains more than 430 examples. - The print version has about 570 pages. - There is also a Kindle, Epub and PDF version. - It's even online: <http://theboostcpplibraries.com/> A special "thank you" goes to Niall who handled this year's Google Summer of Code program so smoothly that I as a backup admin didn't need to do anything - and had enough time to work on the book. :) Boris

6 8

[1.57.0] Release candidates available
by Marshall Clow 01 Nov '14

01 Nov '14

[ Please disregard previous message; apparently I am brain-dead this morning. The uploaded files are correct, though. ] Release candidate files for 1.57.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (./boost_1_57_0_rc1.7z) = 17c98dd78d6180f553fbefe5a0f57d12 MD5 (./boost_1_57_0_rc1.tar.bz2) = 1be49befbdd9a5ce9def2983ba3e7b76 MD5 (./boost_1_57_0_rc1.tar.gz) = 25f9a8ac28beeb5ab84aa98510305299 MD5 (./boost_1_57_0_rc1.zip) = 5e040e578e3f0ba879da04a1e0cd55ff Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_57_0.html

1 1

Enhancing regression tests summary
by Adam Wulkiewicz 31 Oct '14

31 Oct '14

Hi, Some time ago I was writing about regression summaries enhancements, that I'd be nice to see more meaningful list of errors, etc. I asked questions, even prepared a PR for regression, to no avail. So I developed a simple program downloading summaries, test logs and saving the enhanced result. You may check it out here: https://github.com/awulkiew/summary-enhancer Regards, Adam

5 8

[regression] [develop] OSError: [Errno 2] No such file or directory: any_test.test
by Suckow, Thomas J 31 Oct '14

31 Oct '14

# Running Boost.Build tests Traceback (most recent call last): File "run.py", line 83, in <module> runner(root) File "/Boost_Regression_Develop/tools_regression_src/regression.py", line 264, in __init__ self.main() File "/Boost_Regression_Develop/tools_regression_src/regression.py", line 650, in main getattr(self,action_m)() File "/Boost_Regression_Develop/tools_regression_src/regression.py", line 615, in command_regression self.command_test() File "/Boost_Regression_Develop/tools_regression_src/regression.py", line 394, in command_test self.command_test_boost_build() File “/Boost_Regression_Develop/tools_regression_src/regression.py", line 438, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: ‘/Boost_Regression_Develop/results/boost/bin.v2/libs/any/test/any_test.test’ Looks like everyone but teeks is failing to build. - Thomas

3 4

[1.56.0] Release candidates available
by Marshall Clow 31 Oct '14

31 Oct '14

Release candidate files for 1.65.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (./boost_1_57_0_rc1.7z) = 17c98dd78d6180f553fbefe5a0f57d12 MD5 (./boost_1_57_0_rc1.tar.bz2) = 1be49befbdd9a5ce9def2983ba3e7b76 MD5 (./boost_1_57_0_rc1.tar.gz) = 25f9a8ac28beeb5ab84aa98510305299 MD5 (./boost_1_57_0_rc1.zip) = 5e040e578e3f0ba879da04a1e0cd55ff Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_57_0.html

1 0

[PropertyTree][variant] Reading JSON into a recursive variant.
by Arindam Mukherjee 31 Oct '14

31 Oct '14

I have a recursive variant definition that can handle JSON data. Is there a way to read JSON data using PropertyTree into a recursive JSON? Here is the variant defn. #define BOOST_VARIANT_NO_FULL_RECURSIVE_VARIANT_SUPPORT #include <boost/variant.hpp> JSONNullType {}; boost::variant<std::string, double, bool, JSONNullType> jsonToken; typedef boost::make_recursive_variant< std::string, double, JSONNullType, std::map<std::string, boost::recursive_variant_>, std::vector<boost::recursive_variant_> >::type JSONValue; Regards, Arindam

1 0

Re: [boost] Coming up on 1.57 release date - get your fixes in
by Felix Uhl 30 Oct '14

30 Oct '14

Edward Diener wrote: > Marshall Clow wrote: > > Just this morning we received a report of Boost.PP failing on VS 2013. > > It is not failing. It is just giving a warning. I don’t know for sure, but Marshall may be referring to this ticket: https://svn.boost.org/trac/boost/ticket/10686 On VS2013, VARIADICS and MSVC_VARIADICS don’t get defined despite the fact that they should, rendering some variadic macros useless. Von: Edward Diener Gesendet: ‎Donnerstag‎, ‎30‎. ‎Oktober‎ ‎2014 ‎04‎:‎10 An: boost(a)lists.boost.org On 10/29/2014 10:50 AM, Marshall Clow wrote: > We’ll be closing the master branch tomorrow (Thursday) for the 1.57.0 release. > Changes not in by then will not go into the release. > > Also, what issues in the beta have not been addressed? > >> Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP: all libraries >> built successfully (but some are not usable, mostly because of missing >> noexcept) > >> >> All projects using Boost I tried (Debug 32-bit + 64-bit) compiled >> successfully with MSVC12. For MSVC14, TypeTraits 9de6a49 is missing in >> master. > > I believe that these have been merged. > >> Interprocess is broken for MinGW and there are some issues with Intrusive in GCC. I've committed fixes for both. > > I believe that this has been merged. > > Thread fixes have been merged. > > I do not know if the patches described in http://lists.boost.org/Archives/boost/2014/10/217257.php have been merged. > >> range/detail/any_iterator.hpp is broken because it expects >> postfix_increment_proxy and writable_postfix_increment_proxy to be in >> namespace boost::detail, but they are in boost::iterators::detail now. > > This does NOT appear to have been fixed > >> boost serialization is still broken(said so: http://article.gmane.org/gmane.comp.lib.boost.user/82715 ) and to date i do know no workaround to get my library to work on fx Arch Linux without telling users to rebuild with boost 1.55 (or sending them a saved package from my system…) > > I do not know what the status of this is; but there have been no commits to range/master in October. > > Just this morning we received a report of Boost.PP failing on VS 2013. It is not failing. It is just giving a warning. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[testing] Compile failures on MSVC (teeks)
by Andrey Semashev 30 Oct '14

30 Oct '14

Hi, I'm seeing weird compilation failures on Teeks (MSVC 10 and 11): http://www.boost.org/development/tests/develop/developer/output/teeks99-08c… http://www.boost.org/development/tests/develop/developer/output/teeks99-08d… The weird part is this: D:\teeks99-08\d\boost_root\boost/fusion/support/detail/result_of.hpp(32) : error C2143: syntax error : missing ',' before '...' I cannot find the boost/fusion/support/detail/result_of.hpp file in git. Am I missing something or these test machines are broken somehow?

2 1

Coming up on 1.57 release date - get your fixes in
by Marshall Clow 30 Oct '14

30 Oct '14

We’ll be closing the master branch tomorrow (Thursday) for the 1.57.0 release. Changes not in by then will not go into the release. Also, what issues in the beta have not been addressed? > Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP: all libraries > built successfully (but some are not usable, mostly because of missing > noexcept) > > All projects using Boost I tried (Debug 32-bit + 64-bit) compiled > successfully with MSVC12. For MSVC14, TypeTraits 9de6a49 is missing in > master. I believe that these have been merged. > Interprocess is broken for MinGW and there are some issues with Intrusive in GCC. I've committed fixes for both. I believe that this has been merged. Thread fixes have been merged. I do not know if the patches described in http://lists.boost.org/Archives/boost/2014/10/217257.php have been merged. > range/detail/any_iterator.hpp is broken because it expects > postfix_increment_proxy and writable_postfix_increment_proxy to be in > namespace boost::detail, but they are in boost::iterators::detail now. This does NOT appear to have been fixed > boost serialization is still broken(said so: http://article.gmane.org/gmane.comp.lib.boost.user/82715 ) and to date i do know no workaround to get my library to work on fx Arch Linux without telling users to rebuild with boost 1.55 (or sending them a saved package from my system…) I do not know what the status of this is; but there have been no commits to range/master in October. Just this morning we received a report of Boost.PP failing on VS 2013. Have I missed any of the beta issues? — Marshall

7 11