October 2014 - Boost - lists.preview.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

[fusion] Broken compilation on MSVC (was: [testing] Compile failures on MSVC (teeks))
by Andrey Semashev 30 Oct '14

30 Oct '14

On Thu, Oct 30, 2014 at 1:28 PM, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: > 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? Oh, sorry, I was looking at the master local branch, and it fails on develop. Anyway, the header is there and it is broken for compilers not supporting variadic templates.

1 0

Re: [boost] 1.57.0 beta 1 is now available
by Felix Uhl 30 Oct '14

30 Oct '14

Edward Diener wrote: >John Doré wrote: >> Unfortunately this gives us the warning: >> >> warning C4003: not enough actual parameters for macro 'BOOST_PP_EXPAND_I' > > It is an expected warning from Boost PP, which can be ignored. The VC++ > preprocessor is not a C++ standard conforming preprocessor so it gives > warnings when none are necessary. There is virtually nothing that can be > done against such warnings except to attempt to turn them off completely > within Boost PP code. I will look into doing this but often it is > impossible to do since VC++ often does not honor where the preprocessor > warning actually takes place when an effort is made to eliminate the > warning at that place. Does that mean the regular >#pragma warning(disable : 4003) doesn’t work for pre-processor related warnings?

1 0

1.57.0 beta 1 is now available
by Marshall Clow 30 Oct '14

30 Oct '14

Boost release 1.57.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost-binaries/1.57.0.beta.1/ This release contains no new libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_57_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team P.S. There are a couple of known problems with this beta: * There are problems building with MSVC 8.0 * There are some problems with range/detail/any_iterator.hpp. These will be fixed before the release.

9 10

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

30 Oct '14

Artyom Tokmakov wrote: > Have you considered X-macro trick? Yes, and I heavily dislike the syntax. I played around with it a bit and it is absolutely not feasible for this use case. My goal is a simple, intuitive and easy to use syntax. With xmacros you’d have to define an enum in a separate file, Which only makes sense for really, really large enumerations.

1 0

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

29 Oct '14

Artyom Tokmakov wrote: >In addition to various useful suggestions on the list, I would ask for >implementation to support (almost) any large number of enum elements >(enumerators) within enum declaration.: >I have ad-hoc implementation of my own which uses Boost.Proprocessor's >sequence to define enum elements. Then I can generate whatever >parser/printer/other code I want (I find that very useful). >There's a disadvantage, however: obvious limitation of max 256 >elements (at least, by default) coming from Boost.Preprocessor. And that’s where the problem lies. To enable large numbers of enum values, I’d have to find a solution without using Boost.PP. Without C++ introducing argument number based macro overloading, that is not possible, short of defining my own macro sequences for more than 256 elements, which I would like to avoid. I am still thankful that you asked for this, because it uncovered a huge implementation problem which induces enormous compilation overhead (1 minute for 48 enum values on my laptop). I will do my best to make the library comprehend large enums, but I can’t guarantee anything larger than 256. --- Felix Uhl

2 1

Is there interest in a library for string-convertible enums?
by Felix Uhl 29 Oct '14

29 Oct '14

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. I’ve written a small header-only library that uses Boost.Preprocessor and templates to ease the definition of named enumerations that are convertible to and from strings. Those can also be used with the std::cin and std::cout streams naturally, while maintaining all syntactic and semantic properties, regarding initialisation, assignment, type safety and conversion to underlying types. Currently, I am documenting the first version of the library to make it available on the Boost Library Incubator website, but I wanted to get some initial feedback from the developers mailing list, too. I would be glad to extend the library to a general extension of enumeration behaviour, like changing the generation of underlying values from a continuous increment to a continuous shift left by one, effectively making the underlying values binary flags. What features would you want from such a library? Is there even a chance that such a library would get included in boost (given that it satisfied the quality requirements), or is there too little interest in this functionality?

8 7

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

29 Oct '14

Pieter wrote: > Are you aware of the earlier effort by Frank Laub? Frankly (no pun intended), I am not. It would be interesting to see how he has implemented that and what caveats his implementation has. --- Felix

1 0

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

29 Oct '14

Jeffrey Bush wrote: > I have also offered a class for doing this as well, although it didn't draw > the interest that this one did. > Here was my attempt at it with a test/example class: > https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81 Looks good to me, and seems to be quite close to what I aim at. But the definition seems very user unfriendly. Is it correct that you always have to declare enums in the public namespace? --- Felix

1 0

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

29 Oct '14

Rob Stewart wrote: > You should not add features because someone on this list asked for them. > If you're not convinced of the utility of something, push back > to understand the request better. This sounds like advice I should follow. I tend to forget that I’m not writing for a specific client. Also, I noticed that the library has too much compile time overhead already, which should be fixed before introducing any additional ground-breaking features. So I’ve gone through the features suggested and ordered them by priority, perhaps the requesters of the following ones could answer my questions about them and specify why they think these features would be a good addition to the library: By Damien Buhl: - Adaptation of enums after declaration with something like BOOST_ADAPT_ENUM Is this really worth the effort? If somebody knows they want to string-convert an enum (or enum class), why would they not define it as one in the first place? Or is this about enumerations that are already defined by other libraries? Would it be ok to instead define a new enum that has the “to adapted” one as its underlying type and can thus be converted to and from it? There are implementational problems with offering both namespace independent definition of those enums and adaptability. By Gavin Lambert: - Specify custom and multiple strings In which use cases would this actually be beneficial for anyone? Could those use cases be solved by using custom char_traits or even custom string classes? - Specify different conversion tables for use in different contexts What do you exactly mean by that? Conversion to different string values? Conversion by different algorithms? Again, if you could answer those questions, it would really help evaluation. --- Felix

1 0

[gsoc] Any interest in Google Code In?
by Niall Douglas 29 Oct '14

29 Oct '14

The application period for Google Code In 2015 has opened. This is a "tiny GSoC" programme for high school students where the tasks set might take the student three to five hours each. Stuff like writing documentation, improving unit testing, duplicating bug reports, making YouTube video tutorials, blogging about or writing an essay about getting a Boost development setup ready, even refactoring small segments of code if the student is up to it. The important part is the shortness of work item, and of course that you review it and give constructive feedback. More detail is at https://developers.google.com/open-source/gci/. Some example tasks from last year are at https://developers.google.com/open-source/gci/resources/example-tasks. Is there any interest from the Boost community in mentoring such high school student work? If so, now is the time to say. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

Re: [boost] Is there interest in a library for string-convertible enums?
by Artyom Tokmakov 29 Oct '14

29 Oct '14

> What features would you want from such a library? Hello, thanks for the proposal, it's very useful! In addition to various useful suggestions on the list, I would ask for implementation to support (almost) any large number of enum elements (enumerators) within enum declaration.: I have ad-hoc implementation of my own which uses Boost.Proprocessor's sequence to define enum elements. Then I can generate whatever parser/printer/other code I want (I find that very useful). There's a disadvantage, however: obvious limitation of max 256 elements (at least, by default) coming from Boost.Preprocessor. In fact, I hit some other limitations even before that. One of them was max 'if else' statements (I used them in parser implementation. Don't judge me, it was good enough!). When I fixed that, my VC compiler started complaining about some macro processor limitations around 220 enum elements (don't have details handy). Speed of parsing/printing implementation doesn't matter for me. PS: This is my first post in this DL, sorry if I broke some rules. -- Best regards, Artem Tokmakov

1 0

Re: [boost] Is there interest in a library for string-convertible enums?
by Jeffrey Bush 29 Oct '14

29 Oct '14

> > 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. > > > I?ve written a small header-only library that uses Boost.Preprocessor and > templates to ease the definition of named enumerations that are convertible > to and from strings. Those can also be used with the std::cin and std::cout > streams naturally, while maintaining all syntactic and semantic properties, > regarding initialisation, assignment, type safety and conversion to > underlying types. > > > Currently, I am documenting the first version of the library to make it > available on the Boost Library Incubator website, but I wanted to get some > initial feedback from the developers mailing list, too. I would be glad to > extend the library to a general extension of enumeration behaviour, like > changing the generation of underlying values from a continuous increment to > a continuous shift left by one, effectively making the underlying values > binary flags. > > > What features would you want from such a library? Is there even a chance > that such a library would get included in boost (given that it satisfied > the quality requirements), or is there too little interest in this > functionality? > I have also offered a class for doing this as well, although it didn't draw the interest that this one did. Here was my attempt at it with a test/example class: https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81 Supports value to string and string to value, including multiple values with | between them, meaning all combinations can be round-tripped. Supports default power-of-two values and custom values, listing all valid values (as enum types, but each is easily convertible to integral and string values), Although you cannot specify custom string names for an enum value that is not the "STRINGIZE" name, however you can choose to have multiple enum entries with the same value and different names. Jeff

1 0

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

28 Oct '14

Marcel Raad wrote: >being able to specify the underlying >type, not being implicitly convertible >to any other type, and being able to >forward-declare them. Apart from forward-declaration, that’s what I’ve implemented. I want to stay as close to the stock enum class as possible. Forward declaration is added to the feature list :) --- Felix Uhl

1 0

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

28 Oct '14

On 28/10/2014, Rob Stewart wrote: >That sounds interesting. Ease of use and compilation overhead are concerns, of course. I’ll answer your ease of use concern with example code for definition of the enum class Zott: >BOOST_ADVANCED_ENUM_DEFINE( Zott, > zero, > one, > two, > three >); And now for the mentioned “flag” values: >BOOST_ADVANCED_ENUM_DEFINE_W_SUPPLY( > TwoToThePowerOf, > ::boost::advanced_enum::supplies:shiftL1::values, > zero, > one, > two, > three >); Seems easy enough. The second one could be shortened to another macro, of course. Arbitrary values have a bit strange syntax, though: >BOOST_ADVANCED_ENUM_DEFINE_W_SUPPLY( > BOOST_ADCANCED_ENUM_ARBITRARY(4, 8, 6, 20), > four, > eight, > six, > twenty >); I’ll see what I can do about that. Conversions to and from string are done via static_cast (not sure if that’s the ideal solution), in- and output work naturally like this: >Zott myZott = Zott:one; >std::cin >> myZott; //if input is not convertible, no changes are made >std::cout << myZott; I think that's as easy as it can get :) Compilation overhead indeed needs to be considered. >What about enum classes? My mistake, with “named enums” I meant “enum classes”, but now that you say it, I should try to implement string convertible regular enums as well. Thank you for your feedback! --- Felix Uhl Von: Rob Stewart Gesendet: ‎Dienstag‎, ‎28‎. ‎Oktober‎ ‎2014 ‎22‎:‎23 An: boost(a)lists.boost.org On October 28, 2014 7:09:35 AM EDT, Felix Uhl <felix.uhl(a)outlook.de> 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. As Niall noted, most of us have done that before. >I’ve written a small header-only library that uses Boost.Preprocessor >and templates to ease the definition of named enumerations that are >convertible to and from strings. That sounds interesting. Ease of use and compilation overhead are concerns, of course. >Currently, I am documenting the first version of the library to make it >available on the Boost Library Incubator website, I can hear Robert yelling, "Yes!" > but I wanted to get >some initial feedback from the developers mailing list, too. I would be >glad to extend the library to a general extension of enumeration >behaviour, like changing the generation of underlying values from a >continuous increment to a continuous shift left by one, effectively >making the underlying values binary flags. That would certainly be useful. What about enum classes? ___ Rob (Sent from my portable computation engine) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

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

28 Oct '14

On 08/10/2014, Damien Buhl wrote: >What I would like to is to have a complete adapted enum for >Boost.Fusion, this was implemented at some point in some old version of >Boost.Fusion but I cannot find it anymore. Yes, interoperability with other boost libraries is a huge point to consider, and I like the concepts of Boost.Fusion a lot. I also thought about MPL, getting the names as compile time strings could be really useful. >And before all it's important I believe that it doesn't ask the user to >write the enums with macros, but that an additional call later to >something like BOOST_ADAPT_ENUM adds the boilerplate code. >It's naturally possible to offer both choice to the user like >BOOST_FUSION_ADAPT_STRUCT / BOOST_FUSION_DEFINE_STRUCT. I don’t think it is possible to offer an ADAPT_STRUCT macro without forcing the client to either rewrite every single value of the enumeration or define the enum with another macro in the first place. The former would could become problematic when clients change what values the enum actually contains but forget to change that in the macro. I would really want to enable the most natural syntax possible, but even a flexible language like C++ has boundaries where you can’t bend it anymore. So yes, I will offer both to the user. Thanks for your feedback! Felix Uhl Von: Damien Buhl Gesendet: ‎Dienstag‎, ‎28‎. ‎Oktober‎ ‎2014 ‎22‎:‎47 An: boost(a)lists.boost.org Hi Felix, Personally I'm interested, because so far I've been always using a silly macro for this, which doesn't make much : > #ifndef SWISSARMYKNIFE_ENUMS_ADAPT_ENUM_HPP > #define SWISSARMYKNIFE_ENUMS_ADAPT_ENUM_HPP > > #include <string> > #include <ostream> > #include <boost/preprocessor/cat.hpp> > #include <boost/preprocessor/stringize.hpp> > #include <boost/preprocessor/seq/for_each.hpp> > > > #define SWISSARMYKNIFE_ADAPT_ENUM_EACH_ENUMERATION_ENTRY_C( \ > R, unused, ENUMERATION_ENTRY) \ > case ENUMERATION_ENTRY: \ > return BOOST_PP_STRINGIZE(ENUMERATION_ENTRY); \ > break; > > #define SWISSARMYKNIFE_ADAPT_ENUM(ENUM_TYPE, ENUMERATION_SEQ) \ > inline std::string to_string(const ENUM_TYPE& enum_value) { \ > switch (enum_value) { \ > BOOST_PP_SEQ_FOR_EACH( \ > SWISSARMYKNIFE_ADAPT_ENUM_EACH_ENUMERATION_ENTRY_C, \ > unused, ENUMERATION_SEQ) \ > default: \ > return BOOST_PP_STRINGIZE(ENUM_TYPE); \ > } \ > } \ > \ > inline std::ostream& operator<<(std::ostream& os, const ENUM_TYPE& value) { \ > os << to_string(value); \ > return os; \ > } > > #endif What I would like to is to have a complete adapted enum for Boost.Fusion, this was implemented at some point in some old version of Boost.Fusion but I cannot find it anymore. Because if this had the extension struct_member_name or some other better named extension, then I could print out all the possible states with some generic code like I print struct member name with "boost::fusion::for_each_member(enumValue, *this);" > #ifndef BOOST_FUSION_FOR_EACH_MEMBER_HPP > #define BOOST_FUSION_FOR_EACH_MEMBER_HPP > > #include <functional> > > #include <boost/fusion/include/adapt_struct.hpp> > > #include <boost/fusion/sequence/intrinsic/begin.hpp> > #include <boost/fusion/sequence/intrinsic/end.hpp> > #include <boost/fusion/sequence/intrinsic/front.hpp> > #include <boost/fusion/iterator/equal_to.hpp> > #include <boost/fusion/iterator/next.hpp> > #include <boost/fusion/iterator/deref.hpp> > #include <boost/fusion/iterator/distance.hpp> > #include <boost/fusion/support/category_of.hpp> > #include <boost/mpl/bool.hpp> > > namespace boost { namespace fusion { > > namespace detail { > > template <typename First, typename Last, typename F> > inline void > for_each_member_linear(First const& first, > Last const& last, > F const& f, > boost::mpl::true_) {} > > template <typename First, typename Last, typename F> > inline void > for_each_member_linear(First const& first, > Last const& last, > F const& f, > boost::mpl::false_) { > > f( > extension::struct_member_name< > typename First::seq_type, First::index::value > >::call(), > *first > ); > > for_each_member_linear( > next(first), > last, > f, > result_of::equal_to< typename result_of::next<First>::type, Last>() > ); > } > > template <typename Sequence, typename F> > inline void > for_each_member(Sequence& seq, F const& f) { > > detail::for_each_member_linear( > fusion::begin(seq), > fusion::end(seq), > f, > result_of::equal_to< > typename result_of::begin<Sequence>::type, > typename result_of::end<Sequence>::type>() > ); > } > > } > > template <typename Sequence, typename F> > inline void > for_each_member(Sequence& seq, F f) { > detail::for_each_member(seq, f); > } > > }} > > #endif And before all it's important I believe that it doesn't ask the user to write the enums with macros, but that an additional call later to something like BOOST_ADAPT_ENUM adds the boilerplate code. It's naturally possible to offer both choice to the user like BOOST_FUSION_ADAPT_STRUCT / BOOST_FUSION_DEFINE_STRUCT. Cheers, -- Damien Buhl On 10/28/2014 12:09 PM, 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. > > > Iâ€™ve written a small header-only library that uses Boost.Preprocessor and templates to ease the definition of named enumerations that are convertible to and from strings. Those can also be used with the std::cin and std::cout streams naturally, while maintaining all syntactic and semantic properties, regarding initialisation, assignment, type safety and conversion to underlying types. > > > Currently, I am documenting the first version of the library to make it available on the Boost Library Incubator website, but I wanted to get some initial feedback from the developers mailing list, too. I would be glad to extend the library to a general extension of enumeration behaviour, like changing the generation of underlying values from a continuous increment to a continuous shift left by one, effectively making the underlying values binary flags. > > > What features would you want from such a library? Is there even a chance that such a library would get included in boost (given that it satisfied the quality requirements), or is there too little interest in this functionality? > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[Lockfree] has_trivial_destructor and has_trivial_assign restrictions
by Dan Dillon 28 Oct '14

28 Oct '14

I've been doing some thinking about this, and to my untrained eye these restrictions do not seem to be a requirement of the lock-free structure. That is to say, they need not be atomic anyhow, so why does it matter if they are trivial or not? The question goes to making the data structures more globally useful. The more structures they can be used with, the better they are (at least in my opinion). Thanks, Dan

2 1

Custom logging backend difficulty
by Kenneth Adam Miller 28 Oct '14

28 Oct '14

So, I need malleable logging facilities, and so far I've identified boost's logging facilities as useful. I've read the docs on logging, and right now I'm having difficulty achieving what I want-basically, I have a custom backend, in order that when logging is done, it gets routed to an alternative destination - over the network namely. I extended from text_ostream_backend, and basically I'm having the following trouble: I don't understand the record_view visitation API. I'd like the ability to set formatters and what not to remain untouched, but have the final formatted result sent off else where. I can change this by sending the string received in the consume function that has to be overrode, but the values are lost in the record_view. void consume (const record_view & rec, std::string s); where I do { send(s); } for the body. What I think is necessary is just to retain the default behavior of accepting whatever formatter was specified... What is the best way to go about achieving what I want?

3 8

1.57.0 beta 1 is in a new location
by Marshall Clow 27 Oct '14

27 Oct '14

Tom Kent pointed out that I put the beta 1 files in a folder that we traditionally use for Windows binaries, so I have moved the beta files to https://sourceforge.net/projects/boost/files/boost/1.57.0.beta.1/ These are the same files as last Monday - merely in a new location. If you have already downloaded and tested the beta, thanks! - no need to do it again. — Marshall

1 0

Re: [boost] Non-allocating constexpr functional continuations-based future-promise
by Bjorn Reese 26 Oct '14

26 Oct '14

On 10/23/2014 11:00 PM, Niall Douglas wrote: > Given Hartmut's feedback from my previous attempt at a non-allocating > future-promise implementation, I now have a second, much more generic > demonstration prototype which is based on heterogenous sequences of > constexpr functional calls. I think this design may have huge potential. This is a very nice evolution of your previous promise-future framework. > template<class T> struct then_continuation > { > std::vector<std::function<void(T)>> _conts; > template<class U> auto then(U &&c) > { > typedef decltype(c(std::declval<T>())) result_type; > promise<result_type> p; > future<result_type> ret(p.get_future()); > // Unfortunately libstdc++'s std::function currently always tries to > copy lambda types > //_conts.emplace_back([p=std::move(p), c=std::forward(c)](T > v){p.set_value(c(v));}); > _conts.push_back([p = > std::make_shared<promise<result_type>>(std::move(p)), > c=std::forward(c)](T v){p->set_value(c(v));}); > return ret; > } > BOOST_CONSTEXPR T operator()(T v) const > { > for(auto &i : _conts) > i(v); > return v; > } > }; > > All this continuation does is provide a .then(callable) which stores those > callables into a std::vector and its operator() executes the previously > stored callables. Previously you defined callables as composed functions, but here you execute them sequentially. That is, then(f1).then(f2) gets executed as f1(v),f2(v) instead of f2(f1(v)). Or am I missing something?

2 1

[boost.lockfree] spsc_queue preallocated memory block
by Philip Bennefall 25 Oct '14

25 Oct '14

Hi all, I have a feature request for Boost.lockfree (spsc_queue in particular). When using the runtime sized version, could there possibly be a constructor that takes max_size as well as a T* that is then used as the memory buffer? This would remove the need for a specialized allocator if I want to quickly initialize the buffer with memory that does not come from the default std allocator. Kind regards, Philip Bennefall

2 2

Re: [boost] Applying Boost Phoenix to infinite sequence
by Aaron Levy 25 Oct '14

25 Oct '14

25.10.2014, 00:54, "Aaron Levy" <aaron.levy(a)yandex.com>: > Is there a way to use Boost Phoenix to define an infinite sequence and evaluate specific terms of it, compute partial sums, etc? I am looking for pointers to specific libraries or examples. > Indeed, what would are some examples of common programming problems that can be succinctly solved using Phoenix? Aaron.

2 1

Why is iterator_traits<unordered_map<K, M>>::pointer a detail::ptr_node type rather than value_type *?
by Alex Mohr 24 Oct '14

24 Oct '14

The iterator type looks like: template <typename NodePointer, typename Value> struct iterator : public boost::iterator< std::forward_iterator_tag, Value, std::ptrdiff_t, NodePointer, Value&> The NodePointer argument here (which is boost::unordered::detail::ptr_node<...>) becomes the iterator_traits<>::pointer type. But iterator's operator->() returns Value *: Value* operator->() const { return &node_->value(); } Why shouldn't iterator_traits<>::pointer be Value* here? This detail::ptr_node<> type seems intended to be completely internal. Thanks, Alex

3 2

Non-allocating constexpr functional continuations-based future-promise
by Niall Douglas 23 Oct '14

23 Oct '14

>

1 0

Non-allocating constexpr functional continuations-based future-promise
by Niall Douglas 23 Oct '14

23 Oct '14

Dear Boost, Given Hartmut's feedback from my previous attempt at a non-allocating future-promise implementation, I now have a second, much more generic demonstration prototype which is based on heterogenous sequences of constexpr functional calls. I think this design may have huge potential. Consider some heterogenous sequence of callables C { f1, f2, f3, f4, ... } such that fN(... f4(f3(f2(f1(Args...))))) -> R i.e. if you call the heterogenous sequence with arguments Args..., f1(args...) will be called and fed to f2() which then is fed to f3() up to fN() whose return type is R. If I understand proposed Boost.Hana correctly, these potentially constexpr sequences of heterogeneous callables are the main bridge between pure compile-time heterogeneous type sequences and doing something with them in real code as they can decay on demand into actual code when needed. And for proposed Boost.Expected, its monadic programming sequences bind(), map() and then() all functionally operate on some expected<T, E>, consuming an instance and returning new instances, so these monadic sequences are also potentially constexpr sequences of heterogenous callables. Now, what new basic_future-basic_promise will do is to allow you to insert a suspend-resume of execution into some functional sequence C, so essentially: split<idx>(C) => [ basic_promise<X>, basic_future<Y> ] ... where X is some split front part of C and Y is some back part of C. You can now execute the first part of C via the call operator: basic_promise<X>(Args...) Execution of the C0...Cn making up X occurs, but instead of continuing into Y it stores the result of Cn and makes that available to the corresponding basic_future. At some later point you can resume the execution of C: basic_future<Y>() -> R ... and thus complete the execution of the functional sequence C, returning the same value R as invoking the original functional sequence C with the same input parameters. For those who prefer to understand theory via code, here is some example C++ 14 code: // Let this be an arbitrarily long sequence of functional callables auto ct=make_continuations([](auto x){return 5+x;}, [](auto x){ return x+6;}); { // Make a future promise pair for if we called c(int) auto fp=ct.suspend_resume<1, int>(); // Execute promise fp.first(1); // Execute future b=std::move(fp.second)(); } { // Make a future promise pair for if we called c(double) auto fp=ct.suspend_resume<1, double>(); // Execute promise fp.first(1.0); // Execute future d=std::move(fp.second)(); } // b=12, d=12.0 There are a multitude of uses for this very fundamental pattern. Let us try implementing something closely resembling the Concurrency TS's dynamic continuations support .then(launch, callable). Let us define this functional continuation: template<class T> struct then_continuation { std::vector<std::function<void(T)>> _conts; template<class U> auto then(U &&c) { typedef decltype(c(std::declval<T>())) result_type; promise<result_type> p; future<result_type> ret(p.get_future()); // Unfortunately libstdc++'s std::function currently always tries to copy lambda types //_conts.emplace_back([p=std::move(p), c=std::forward(c)](T v){p.set_value(c(v));}); _conts.push_back([p = std::make_shared<promise<result_type>>(std::move(p)), c=std::forward(c)](T v){p->set_value(c(v));}); return ret; } BOOST_CONSTEXPR T operator()(T v) const { for(auto &i : _conts) i(v); return v; } }; All this continuation does is provide a .then(callable) which stores those callables into a std::vector and its operator() executes the previously stored callables. Now let us define a std::promise lookalike, with its main deficiencies being a total lack of exception_ptr support (one would use expected<T, E> as the transport type for that) and of course any thread safety: template<class T> class promise : public basic_promise<detail::then_continuation<T>, T, detail::then_continuation<T>> ... basic_promise takes three template parameters, the type of the front split of the continuations, the transported type between the two halves of continuations, and the type of the back split of the continuations. Here, we are defining promise as transporting a type T, and two then_continuation continuations exist before and after the transport of the type T. To our future<T> lookalike we now add this: template<class U> auto then(launch policy, U &&c) { if(policy==launch::deferred) return Base::_after.then(std::forward(c)); else if(Base::_other) return Base::_other->_before.then(std::forward(c)); } So, if the .then() dynamic continuation is deferred, push it into the latter then_continuation, else push it into the former. And voila, you can now do this very similar to Concurrency TS code: promise<int> p; future<int> f(p.get_future()); future<double> f2(f.then(launch(), [](int a){return a+1.0;})); p.set_value(5); return f2.get(); And you get back 6.0, as expected. However here is where things get neato. How many instructions do you think GCC 4.9 generates for this sequence? promise<int> p; future<int> f(p.get_future()); p.set_value(5); return f.get(); In traditional future-promise, that is an operation perhaps consuming thousands of CPU cycles and at least one memory allocation and deallocation. Well, this is the assembler produced by the above by GCC 4.9: _Z19test_futurepromise4v: movq $0, -88(%rsp) movq $0, -80(%rsp) movl $5, %eax movq $0, -72(%rsp) movq $0, -48(%rsp) movq $0, -40(%rsp) movq $0, -32(%rsp) movl $5, -56(%rsp) movq $0, -64(%rsp) movq $0, -24(%rsp) ret Believe it or not, this is actually bad output - there is a bug in GCC's optimiser and it should in fact be outputting a single instruction rather than writing zeros into the stack for no purpose - it seems to get confused by the double declation of a std::vector which is never used, because having just one std::vector produces the ideal output but having two produces the above. However clang 3.4's optimiser does far worse, and a bug there with how non-immediately defined types are treated causes complete expansion of code in its entirety, even if you remove all std::vector's (supplying any type not immediately declared in the same function breaks the optimiser for some unknown reason. I haven't tried clang 3.5 yet, it may be fixed). Other very interesting policy continuations which can be statically mixed into custom future promise types include calling some application specific callback without needing to indirect via a pointer to a function. This lets you combine future promise with invoking callbacks, useful for legacy code. The idea behind this suite of future-promise fundamental parts is that they can be mixed at will into bespoke future-ish promise-ish application specific future promise types. Because they all share the same foundations, a when_any() or when_all() can accept heterogenous future types - and I don't mean future<int> with future<double>, rather I mean afio::future<> with qt::future<int>, that sort of heterogenity. Another very interesting idea is combining these with signals and slots, so via custom continuations you can keep slots and fire signals in sync with future promises. This design I think shows a lot of potential. Anyway, I feel very happy with this design, and something along these lines is where I shall proceed next. The eventual intention is for these future promises to become the default Boost.Thread future promises when C++11 is available, though this will be up to a year from now. I won't be able to support future-promise custom allocators, but I certainly should be able to completely avoid memory allocation and sometimes the generation of any code at all with this design. The demonstration prototype code is at https://github.com/ned14/boost.spinlock/blob/expected_future/test_constexpr_ future_promise2.cpp for anyone interested. It needs a C++ 14 compiler, so a minimum of libstdc++ 4.9 and either GCC 4.9 or clang 3.4 or better. Comments are welcome. Niall

1 0

DTLS support in boost
by Indtiny S 22 Oct '14

22 Oct '14

Hi, Currently I am using boost for one of my cpp application ... now my application needs DTLS security support ... I currently have written using openssl APIs .. I want nowb...does boost asio has any APIs for DTLS handshake ? Rgds Indhra

1 0