February 2017 - 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

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

[beast] Request for Discussion
by Vinnie Falco 12 Jun '17

12 Jun '17

Beast provides low level HTTP and WebSocket interfaces built on Boost.Asio, the project is here: https://github.com/vinniefalco/Beast The plan is to solicit feedback from the Boost community before submitting a request for a formal review. First a brief update: I have attended CppCon 2016 and provided a 15 minute Lightning Talk on the library. There should be a video up at some point with all the talks, including mine. I spread the word about Beast and discovered that there are several folks in the wild already using the library and happy with it. There are also a couple of commercial products that are using it. One point brought up during the conference is that Beast does not offer sufficient higher level HTTP functionality. This omission is intentional. It is my idea to offer the building blocks (serializing and deserializing HTTP/1 messages, in synchronous and asynchronous flavors, and a universal HTTP message model), upon which other developers more knowledgeable than me could build those interfaces. The higher level pubic operations requested were: 1. Perform HTTP GET or POST and receive the response. Presumably this would handle both plain and TLS connections, handle redirects, and handle HEAD requests. Not sure about traversing proxies. 2. Expose an asynchronous HTTP server class which callers can instantiate with some sort of handler that returns the HTTP response given a request. It should be possible, in a minimal number of lines, to quickly get a server up and running. The requestor informed me that this functionality did not need to provide every possible feature or handle every use case. It just needed to handle the common use-cases. For the record, I am against this higher level functionality for a number of reasons. The higher the level of functionality, the more contentious the feature becomes, and the harder it is to satisfy a quorum of reviewers. No one would dispute that we need the ability to read a complete HTTP message from a socket. But not everyone will agree that a HTTP server needs an option to allow multiple listening sockets with different level of permissions. Another problem with offering higher level functionality is that it could be less likely to be approved for standardization in the C++ standard library. For example, the attributes of ease of use and fully functional oppose each other. If the functionality offered by a hypothetical std::http::client is not sufficient, a developer would be forced to write their own with little possibility to reuse parts of the implementation from the stdlib. I doubt the committee would approve of such a thing. I know I wouldn't. Admittedly I have little experience or knowledge on what would or would not get approved. A point was raised that a low-level-only HTTP implementation in Boost has the potential to discourage new users that need to perform simple operations like HTTP GET from using Boost in the future, given that robustly handling such operations would require the developer to write a significant amount of code. I can see some validity here. On the other hand, if Boost.Asio was submitted for a formal review today, would those same points be raised? Would Asio get rejected because it doesn't offer public interfaces for doing simple tasks like requesting an object from a web server? I wonder if perhaps the Boost formal review process has become defective. For reference here is what the current API offers: Example program that performs HTTP GET, then receives and prints the response: https://github.com/vinniefalco/Beast/blob/master/examples/http_example.cpp This is a high performance asynchronous HTTP server that serves local files as static pages. It is not an official API, it is part of the examples. Users who want a server need to copy the source code and modify it to suit their needs: https://github.com/vinniefalco/Beast/blob/master/examples/http_async_server… My initial purpose for requesting this discussion is two-fold: 1. Determine the level of consensus on the issue that Beast needs to do more for HTTP than the lowest level of functionality (reading and writing messages). I'm open to hearing all arguments for and against. 2. Get feedback on what official public interfaces to higher level functionality might look like. Specifically, a client that handles GET and POST, and a generic asynchronous server. And what features those interfaces would support. For example, is traversing a proxy a necessary feature for an official client interface? The best answers would provide function signatures or class declarations using the existing Beast HTTP types. In case its not clear, I am asking stakeholders and reviewers to help design the library. I'll open a discourse on the HTTP client to illustrate the proposed style of discussion: We want to provide a HTTP client implementation that lets users perform simple tasks like fetch a resource from a remote host. Calling code should be compact, letting people get their job done without getting mired in boilerplate. Here's a possible signature with example use: response_v1<string_body> get(std::string const& url, error_code& ec); error_code ec; auto res = get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; The get function would automatically perform the name resolution, connect the socket, request the resource with uri "/", and return the result. There's a problem here though, the caller is forced to use a message with std::string as the container for the body. An obvious fix is to add a template parameter: template<class Body = string_body> response_v1<Body> get(std::string const& url, error_code& ec); Better, but what if the body is not DefaultConstructible? We can add some parameters to forward to the Body constructor: template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); We're getting somewhere now. Most users will use the default body, while an option exists for advanced users. But the implementation of get now has a complication. If an error occurs, it still has to construct a return value. This problem is likely surmountable but lets table it and start a new line of reasoning. What if the URI indicates https, e.g. "https://boost.org"? We can hide that under the hood by using a separate code path that uses asio::ssl::stream instead of ip::tcp::socket. But how does the caller provide the root CA certificates? How does the caller provide a client certificate? We are left with a client that satisfies two thirds of users but is unusable for the remaining one third. Is this Boost worthy? Is this std-lib worthy? I think not. Lets revisit the SSL issues later and think about a new problem. What happens to the socket when the request is done? In the proposed interface, the socket is destroyed. This means you can only make one request on a connection. At this point, I think its clear that the current interface is a non-starter. Here's a better idea. Lets define a class called client and make get a member function. Now we can have state, including configurable settings with reasonable defaults. class client { public: template<class Option> void set_option(Option&&); template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); }; client c; error_code ec; auto res = c.get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; We still have some of the original problems, but other problems are solved. The class can keep the socket around, so that a subsequent call to get with the same server will use the already-open socket. The caller can set options on the client object instance before invoking get, such as any TLS certificates. Unfortunately we have new problems. Where is the io_service? If the class creates it for you, how many threads? How do I use my existing io_service, or is that even necessary? The class interface allows the connection to be kept alive but what if now the caller wants to close it (i.e. specify "Connection: close" in the request)? And there are some problems which are applicable to any interface. How does the caller adjust the parser options, for example change the limit on the size of the body? What if the caller wants the request made using a specific HTTP version? How does this handle basic authentication? How can the caller adjust the headers in the request? etc... This is why I think that offering a HTTP client is a rabbit hole which can only lead to a rejected formal review. Or maybe I am overthinking this? I'd love to hear proposed solutions to the issues (which could be just to say "forget about those features"). Despite my objection I have started work on these features anyway. Here are the beginnings of a HTTP client: https://github.com/vinniefalco/Beast/blob/88b485df7e6216282842f40cf99cc75de… Here is some work on a generic server: https://github.com/vinniefalco/Beast/blob/server/extras/beast/http/async_se… Please reply to this thread instead of starting a new thread, and keep the subject line prefix (e.g. "Re: [boost] [beast] ...") Thank you

21 58

[build] [config] check_target_builds and feature.subfeature composition
by Edward Diener 30 May '17

30 May '17

The Boost library config uses the check_target_builds rule to provide build time feature testing. Other Boost libraries use config checks in their own build and test jamfiles. I have found that this works reliably when a particular toolset is used in a normal manner. However when using the feature.subfeature and feature.compose rules to extend the toolset-version designation with a subfeature, such that the toolset designation now becomes toolset-version-subfeature, the use of the check_target_builds rule does not work as expected. In particular the individual check_target_builds rule results are put into a subdirectory based on the toolset-version and not based on the toolset-version-subfeature when toolset subfeature composition is used. I also suspect that the cached value reflects setup. This causes wrong results in tests where the toolset designation uses subfeatures, and a library's jamfile is using config and/or predef checks. As an example My toolset designation looks like: using gcc : 6.3 : some_path ; feature.subfeature toolset gcc : cxxstd : c03 c11 c14 c17 : optional composite propagated ; feature.compose <toolset-gcc:cxxstd>c03 : <cxxflags>-std=c++03 ; feature.compose <toolset-gcc:cxxstd>c11 : <cxxflags>-std=c++11 ; feature.compose <toolset-gcc:cxxstd>c14 : <cxxflags>-std=c++14 ; feature.compose <toolset-gcc:cxxstd>c17 : <cxxflags>-std=c++1z ; A library's test looks like: import ../../config/checks/config : requires ; run some_test.cpp : : : [ requires cxx11_hdr_forward_list ] ; If I run some some_test with toolset=gcc-6.3-c03, the config result for checking if forward list is supported is put into a subdirectory reflecting the toolset-version while the test result will be put into a subdirectory reflecting the toolset-version-subfeature. Subsequently if I run some_test with toolset=gcc-6.3-c11 the config result is taken from the subdirectory reflect the toolset-version even though whether the forward list is supported or not depends very much on the subfeature I am designating as part of the toolset. This naturally causes incorrect results for the test. Is this a known problem ? Is it a problem with Boost Build or is it a problem with how config uses the check_target_builds rule ? I have run into this problem extensively in my testing once I started to use the feature.subfeature ability of Boost Build.

5 9

[msm] [statechart] unmerged PRs
by András Kucsma 23 May '17

23 May '17

Hi Everyone, There are a couple of PRs for msm and statechart by me and others, which didn't get any attention for many months now. Can the maintainers please take a look at them? https://github.com/boostorg/msm/pulls https://github.com/boostorg/statechart/pulls Thank you, Andras

2 2

[clang] clang-cl expansion of macros
by Edward Diener 29 Apr '17

29 Apr '17

You can get clang-cl ( clang-win ) to show its VC++ emulated expansion of macros somewhat by passing the c++ option '-fmacro-backtrace-limit=0' to the compiler. It is still blessedly difficult to see the what and the why of clang's error messages when expanding macro using clang-cl, but at least it gives you a better chance of understanding where clang's emulation of VC++ has gone wrong. I have posted bug 27380 to the llvm/clang bug tracker at https://llvm.org/bugs/show_bug.cgi?id=27380 showing the main failure in VC++ emulation which I see when testing Boost PP with clang-cl.

3 8

[container] moving a pre-built vector into a flat_set
by Sam Kellett 12 Mar '17

12 Mar '17

a common problem i encounter is that i have two stage's w/r/t to a large collection of data: building and querying. vector is obviously the king of building. flat_set is the king of querying. so what i often tend to do is build up a very large vector, sort it then create a flat_set using the flat_set(ordered_unique_t) constructor. however this still copies the entire vector into the flat_set, right? what i would like to be able to do is move the vector straight into the flat_set, something like: std::vector<T> data; flat_set data_set1(std::move(data)) // move vector in and sort it // or: std::sort(data.begin(), data.end()); // sort vector flat_set data_set2(ordered_unique_t, std::move(data)) // and move it in is this doable (am i just being blind?) or is there plans/interest for this?

8 19

[Endian] Reading/writing from/to byte buffers
by Olaf van der Spek 10 Mar '17

10 Mar '17

Hi, One often needs to read or write values from/to a buffer while having a pointer. Could you support this? I guess one could use *reinterpret_cast<big_int64_buf_t&>(*p) but I think functions would be more convenient. On second guess one probably has to use memcpy rather then reinterpret_cast. The functions are probably implemented already but aren't exposed. https://github.com/boostorg/endian/issues/17 -- Olaf

2 3

[stacktrace] review
by Artyom Beilis 10 Mar '17

10 Mar '17

Hello, This is my review of stacktrace library: Note that I have experience with the subject as I developed a similar library for the CppCMS framework [1] > - What is your evaluation of the design? > The design is straight forward and I don't see any major issues with the API. Also I have several suggestions in handling backtrace with catch from } catch (const traced& e) { std::cerr << e.what() << '\n'; if (e.trace) { std::cerr << "Backtrace:\n" << e.trace << '\n'; } } catch (const std::exception& e) { std::cerr << e.what() << '\n'; } In my library I use much simpler approach in terms of API [2] catch(std::exception const &e) { std::cerr << e.what() << std::endl; std::cerr << booster::trace(e); } Where booster::trace is a manipulator that prints strack trace if "e" contains backtrace information - much shorted code without additional catch. I find it very easy to use. Just a suggestion. I also like with_trace templated class idea. > - What is your evaluation of the implementation? Most of my > personal concerns with this library are with the implementation and I > would hugely appreciate feedback from others with substantial > experience of using stacktracing "in anger" in non-trivial use case > scenarios. I mostly reviewed the backend. Linux: ========= 1st of all: I recommend mentioning in the documentation the option -rdynamic/-export-dynamic as otherwise dladdr would likely to fail - it is critical as many may miss one. Regarding use of add2line utility: 1. Failing to calling an external program in case of dladdr fails is bad idea. This behaviour is unexpected by the user. I understand the advantage of this as you can use debug information but should be done only per user specific request (i.e. compilation option) and not by default. 2. If you call add2line - use it for ALL addresses in backtrace at once and not for each single one! My recommendation is to provide alternative backed that uses other way to extract information not involving forking. Maybe try to analyze debug data or so - or require preparing initial map using nm tool and than loading it from file or something like that. Additionally calling the backed linux is bad - as same approach with slight modifications works on *BSD, Mac OS X and Solaris (RIP). Windows: ======== I have a question why you used COM instead of SymFromAddr functions? I understand thread safety issues but simple mutex can solve them. My concerns are regarding MinGW compilers. Have you tested it on MinGW compiler? It wouldn't work as it used MSVC debug information in general so maybe it is good idea to provide an alternative backend that extracts only address and DLL name so you can analyse the stacktrace later (using addr2line utility for example) Take a look on my code [1] regarding non-msvc windows compilers - it provides at least some useful information. > - What is your evaluation of the documentation? The documentation is ok in general and straight forward as the library itself. What I do lack is the documentation of underlying backends - how do they work. 1. use of -rdynamic/-export-dynamic should be noted in "bold face" regarding the use of the library. 2. please do not call it "POSIX backend" - as there none of the stuff you use is actually POSIX... Also you'll probably need different backends for MINGW and mention it. > - What is your evaluation of the potential usefulness of the > library? Very Very useful. > - Did you try to use the library? With what compiler? Did you have any problems? No I didn't - I mostly read the documentation and the backend code. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? 3-4 hours > - Are you knowledgeable about the problem domain? Yes I am. I have written similar library for CppCMS project [1] - FINAL VOTE: Yes, Conditionally Conditions: Use of addr2line must not be enabled by default. [1] https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/boo… https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/lib… [2] https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/boo… Best Regards, Artyom Beilis

4 5

[metal] Feature Complete - Request for Feedback
by Bruno Dutra 05 Mar '17

05 Mar '17

Dear community, As some of you might be aware through sporadic discussions on this mailing list throughout the last couple of years, I've been working for quite a while on a modern template metaprogramming library called Metal, that I advocate as a direct replacement for the aging Boost.MPL. I believe my work is finally complete now and so I come to you to request for feedback and ask whether you think that Metal would be a valuable addition to the Boost distribution. My intention is to request a formal review in the next days / weeks, depending on your preliminary feedback. In a glimpse, Metal is a pure template metaprogramming that explores all modern features available to C++14 to overcome the limitations of Boost.MPL, most notably: * vastly improved performance [1]; * terser syntax [2]. Repository: https://github.com/brunocodutra/metal Documentation: http://brunocodutra.github.io/metal/ Boost Incubator: http://blincubator.com/bi_library/metal-2/?gform_post_id=1566 I appreciate your feedback and opinion on whether Metal is a good fit for Boost! - Previous discussions About a year ago I came to this list to discuss a proposal of merging Metal into MPL as a new API built from ground up, while at the same time serving as a backend for the previous API on modern compilers. At that time, Metal was lazy and very similar to MPL, but since then it underwent great simplification and embraced the all-eager design, so I don't think this would be a good idea anymore. Besides, it soon became clear that this would be a huge undertaking with potential to inadvertently breaking a lot of good code to little gain, so I decided instead to tackle the problem migration from MPL by providing a handy adaptor [3]. [1]: http://metaben.ch/ [2]: http://brunocodutra.github.io/metal/index.html#in_a_glimpse [3]: http://brunocodutra.github.io/metal/group__external.html#gaede6847ad3e0bb64… Regards, Bruno Dutra

13 35

[nowide] Library Updates
by Artyom Beilis 04 Mar '17

04 Mar '17

Hello, Disclaimer: --------------- I recently discovered that virtually all e-mails sent from Yahoo account to any mailing lists go to user's spam due to recent Yahoo's DMARC policy. So I'm sending some important stuff from GMail account that almost certainly was missed: What is Boost.Nowide: -------------------------------- Boost.Nowide is a library that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. It was inspiration and inspired by http://utf8everywhere.org/ development ideas and policy. Some updates regarding Boost.Nowide ------------------------------- 1. Library moved to github and its format is converted to modular boost layout: https://github.com/artyom-beilis/nowide 2. Fixed unsupported std::ios::ate flag by boost::nowide::fstream 3. Added some C++11 interfaces to boost::nowide::fstream 4. Added integration functionality with boost::filesystem: https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/in… Note: that the links to the source code on review schedule aren't relevant, it should be: - Code: https://github.com/artyom-beilis/nowide - Documentation: http://cppcms.com/files/nowide/html/ Also the library is still looking for review manager. Artyom Beilis P.S.: I'm sorry if you are getting this as "duplicate"

2 1

[MPL][vector] Is there interest in mpl::vector using variadic templates?
by Михаил Максимов 03 Mar '17

03 Mar '17

Dear community, I've recently started contributing to boost::variant. To speed up variant's compilation I'm implementing mpl::vector on variadic templates. For now status of new vector implementation is: 1) it passes all mpl/test tests on gcc 4.9 and 6.3 2) it is decoupled from mpl::vectorN, simultaneously making mpl::vectorN visible, so libs like Boost.Geometry, which rely on mpl::vectorN compile nicely 3) There are several compilation errors during full build on gcc 4.9 and 6.3 4) I fix problems on mpl/tests stage for clang 3.4 and latest MSVS2017 compiler Bruno's introduction of new shiny Metal library and Sergey's comment in the same thread: > The biggest and most useful feature of "new" TMP libraries is variadic > templates that increase performance by a really huge factor. The problem > with MPL is that vector type sequence must derive from vectorN-s, which are > documented and can be used in template specialization. So it is impossible > or pointless to remplement mpl::vector in terms of variadic parameters > because of that. The other problem that I can quickly recall is recursive > iterator-based approach, which also kills performance. made me wonder, is there interest in variadic templates implementation? Are there limitations for it's usefulness, which I did not see? Regards, Mike Maximov

7 14

[thread]Forever sleeping
by Niklas Angare 01 Mar '17

01 Mar '17

Recent runs of my regression test runner NA-QNX660-x86 leave a lot of Boost.Thread test executables stuck in nanosleep, waiting for a condition variable, or both. Commit 544eda [1] which switched from CLOCK_REALTIME to CLOCK_MONOTONIC seems suspicious to me. If the returned timespec is ever compared to values based on the CLOCK_REALTIME epoch, such as system_clock, the results will be quite undesirable. Are you sure the return values of timespec_now() are only ever compared to each other and values based on the CLOCK_MONOTONIC epoch? [1] https://github.com/boostorg/thread/commit/544eda51bdf0c62b2f29dea6fe1cf935a… Regards, Niklas Angare

3 9

boost exception to_string()
by Olaf van der Spek 28 Feb '17

28 Feb '17

Hi, Is to_string() here supposed to match to_string() in boost\exception\to_string.hpp? class shared_array2 : public boost::iterator_range<T*> {}; typedef shared_array2<unsigned char> shared_data; to_string(shared_data()); I really didn't expect this to_string() to be found here.. is it a feature or is it a bug? -- Olaf

1 0

[config] [atomic] Problem with placement of BOOST_ALIGNMENT - requesting opinions/suggestions
by Groke, Paul 28 Feb '17

28 Feb '17

While preparing a pull request for my Boost.Atomic extensions for the z/OS compiler, I noticed that I have a slight problem there. To get the code to work on z/OS, I changed the placement of the BOOST_ALIGNMENT macro in atomic/detail/storage_type.hpp from... BOOST_ALIGNMENT(16) unsigned char data[Size]; to unsigned char data[Size] BOOST_ALIGNMENT(16); ...because unfortunately the z compiler doesn't understand the __attribute__ ((__aligned__(x))) when it's at the beginning of a variable/data member definition. (For the GNU __attribute__ ((__aligned__(x))) the new location is also the only documented location, although GCC doesn't seem to mind.) While reviewing my changes I now realized that this won't do, because BOOST_ALIGNMENT can also be defined as __declspec(align(x)) or alignas(x), both of which are legal at the beginning but not at the end of a variable/data member definition. (I'm not 100% sure about valid positions of alignas (x) - the examples I can find use alignas (x) at the beginning, but the compilers we currently use - which include MSVC, GCC and Clang, also seem to accept it at the end. __declspec(align(x)) definitely is a problem though.) And now I'm wondering what to do about this. One way to fix this would obviously be to introduce two additional macros, e.g. BOOST_ALIGNMENT_DECLSPEC and BOOST_ALIGNMENT_ATTRIBUTE. Only one of those would then expand to something non-empty, and both would have to be used in variable definitions. The BOOST_ALIGNMENT macro would remain as is for type declarations and for compatibility. The code in storage_type.hpp would then have to be re-written as BOOST_ALIGNMENT_DECLSPEC(16) unsigned char data[Size] BOOST_ALIGNMENT_ATTRIBUTE(16); Which of course is very very ugly. Another option would be a BOOST_ALIGNED_VARIABLE(alignment, variable_definition) macro. This would be nice in definitions like BOOST_ALIGNED_VARIABLE(16, unsigned char data[Size]); but much less nice in definitions like BOOST_ALIGNED_VARIABLE(16, some_template<foo BOOST_PP_COMMA bar BOOST_PP_COMMA baz>); And since not all compilers support variadic macros, this is probably the best one could do. The third option I can think of would be to leave things as they are, which of course would mean that I can't submit my Boost.Atomic implementation for z/OS... hm. I realize that making things uglier for a single compiler that almost nobody uses isn't something many people will cheer for. But then again I'd really like to have my Boost.Atomic implementation for z/OS in the official Boost releases :) So I'm calling out to you for suggestions/opinions/comments. Is there another way to combine the above mentioned square peg + round hole? And which option would you deem favorable/acceptable? Thank you for taking the time to read this wall of text, Cheers, Paul Groke The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistaedterstrasse 313

3 8

[gsoc17] Boost will be participating in Google Summer of Code in 2017
by Niall Douglas 27 Feb '17

27 Feb '17

I am very pleased to inform the Boost community that Google accepted us into their Summer of Code programme this year. This was especially welcome after we were given "a year off" last year which could have caused substantial disruption to the multi year student projects had it not been due to the timely action of the steering committee and generous sponsorship of a stop gap Boost Summer of Code in 2016 by IMC Financial Markets. Last year Google completely rebuilt the Summer of Code website so it no longer is anything like it was before. Now we must individually invite those who vote on student projects, so *anyone willing to rank student project proposals* can you please email us with your details: 1. Your email address matching your Google Account so we can invite you onto the GSoC programme. 2. (Optional) your email address matching your Github Account so we can invite you onto the Boost GSoC github org for 2017 as a potential mentor. Our thanks to those who have already added project ideas to https://svn.boost.org/trac/boost/wiki/SoC2017, but we need MORE ideas and MORE potential project mentors. Follow the project idea template at https://svn.boost.org/trac/boost/wiki/GSoCIdeaTemplate and either add it straight to the wiki page or email it to us so we can add it for you. Our thanks to all in advance.

1 0

ABI navigator for Boost libraries
by Andrey Ponomarenko 26 Feb '17

26 Feb '17

Hello, I'd like to present a new project called "ABI Navigator" to search for binary symbols (functions, methods, global data, etc.) in the Boost and other open-source libraries: https://abi-laboratory.pro/index.php?view=navigator The project allows to find out in which versions of the library and in which particular objects of the library some symbol is defined, added or removed. The project is based on the ABI report for Boost: https://abi-laboratory.pro/tracker/timeline/boost/ Examples: 1. symbol "boost::system::system_category()" from libboost_system.so: https://abi-laboratory.pro/index.php?view=navigator&selected=_ZN5boost6syst… 2. symbol _ZnwmPv21boost_container_new_t from libboost_container.so: https://abi-laboratory.pro/index.php?view=navigator&selected=_ZnwmPv21boost… The project aims to help library users and maintainers to resolve issues with missed symbols and navigate through the ABI reports. Have you ever encountered the "undefined reference" error or want to know whether the symbol is _stable_ enough to use in your code? Try to find it in the ABI Navigator! Enjoy!

1 0

[release] 1.64.0 closed for major changes
by Rene Rivera 23 Feb '17

23 Feb '17

The master branch is now closed for new libraries and breaking changes, and will be closing for major changes in a week and closed for the beta in two weeks. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_64_0.q… > Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[mpi] Merging a PR fixing auto_ptr usage
by Andrey Semashev 22 Feb '17

22 Feb '17

Hi, Could someone take a look at this PR and hopefully merge it? https://github.com/boostorg/mpi/pull/38 It should be safe to merge, and I would really like to see it in 1.64. I'm surprised noone fixed it earlier, actually. Thanks.

2 1

Status of Visual Studio 2017 support
by Mateusz Loskot 22 Feb '17

22 Feb '17

Hi, In the mid of 2016, PR "Add support for Visual Studio 15" [1] was merged into develop and eventually into master branch. Although the patch was released in Boost 1.63.0, the release notes [2] are silent about that update. That is about Boost.Build, which I assume is the first to be updated to support a new toolkit. I haven't checked current commits history of individual libraries. Status of VS2017 support in individual libraries may be at different stages. Could anyone clarify any of these points: - Does Boost.Build in Boost 1.63.0 officially support VS2017? - Is there any schedule to fully support VS2017 in Boost 1.64.0? - Or, is that left at discretion of maintainers of individual libraries and VS2017 support might be reached gradually over several releases instead of in a single shot? [1] https://github.com/boostorg/build/pull/132 [2] http://www.boost.org/users/history/version_1_63_0.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

16 46

[config] [atomics] Support for z/OS XL C/C++
by Groke, Paul 21 Feb '17

21 Feb '17

Hi, we're using several Boost libraries in a large cross-platform project. One of the platforms we need to support is z/OS, using the IBM z/OS XL C/C++ compiler (which BTW is a completely different beast from the XL C/C++ compilers for other IBM platforms, which Boost.Config already seems to support). To be able to use Boost we had to write some patches and we'd very much like to contribute them. In more detail: * A minor patch to make the configure script work * Patches to some of the configure tests to fix incorrect feature detections * Compiler-, library- and platform-config header files * A Boost.Atomic implementation * An implementation of Boost.SmartPtr atomic operations This won't result in full support for all Boost libraries, not even close, but it's enough to make an appreciable subset usable on z/OS. I've never contributed code to any open source project so far, so I'd appreciate your help. Where should I start? Do I have to talk to the maintainers of Config/Atomic/SmartPtr? Is there even a maintainer for every specific project? Or should I just fork the Git repos and create pull requests? I'm pretty much lost here, sorry :) Regards, Paul Groke The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistaedterstrasse 313

4 6

Re: [boost] Status of Visual Studio 2017 support
by Nat Goodspeed 20 Feb '17

20 Feb '17

On Feb 20, 2017 5:25 AM, "Olaf van der Spek" <ml(a)vdspek.org> wrote: On Fri, Feb 17, 2017 at 2:57 PM, Nat Goodspeed <nat(a)lindenlab.com> wrote: > In a (non-Boost) project with which I've helped, there's a script that > does the following: > > ... Wouldn't it be much simpler if you let the user pick the right dev environment prompt from the start menu and have all stuff available without having to call extra scripts? It's a command-line build tool. The command-line equivalent to what you suggest is making the user discover, and then type, the correct pathname of the desired VS version.

4 3

Mail List Migration - Update
by Michael Caisse 19 Feb '17

19 Feb '17

The Boost mail lists are now migrated to a new set of servers. This change affected all mail lists and web resources (signing up, changing passwords, moderator access, archives...) that were associated with the domain lists.boost.org . If you are having difficulties, please drop me an email. (Oh the irony) Happy coding! michael -- Michael Caisse Ciere Consulting ciere.com

9 15

Variadic append for std::string
by Olaf van der Spek 19 Feb '17

19 Feb '17

Hi, One frequently needs to append stuff to strings, but the standard way (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries. A variadic append() for std::string seems like the obvious solution. It could support string_view (boost and std), integers, maybe floats but without formatting options.. It could even be extensible by calling append(s, t); append(s, "A", "B", 42); Would this be useful for the Boost String Algo lib? -- Olaf

16 104

Interprocess mutex & condition variable at process termination
by Phil Endecott 18 Feb '17

18 Feb '17

Dear Experts, I've just been surprised by the behaviour of the interprocess mutex and condition variable on abnormal process termination, i.e. they are not automatically released. Google tells me that I'm not the first to be surprised by this; there have been previous posts here, stack overflow questions etc. One often-valid observation is that if a process crashes - or otherwise terminates without executing its destructors - while it holds a lock on a shared data structure then the data is probably now corrupt, so unlocking the mutex that protects it is not very useful. I think there is an important case where that does not apply - when the process that crashes is only reading the shared data. In my case, I had written a "monitor" utility that loops forever, waiting on a shared condition, taking the corresponding mutex, and then dumping the shared data to stdout. I had been running this and stopping it by pressing ctrl-C and it had not occurred to me that this might not work as I expected. My attempt at debugging using this utility was making my problems worse, not better! Modifying this code to run destructors on ctrl-C is non-trivial. I am aware that the SysV shared semaphore is able to undo on process termination (see SEM_UNDO in man semop), and I had assumed that Boost.Interprocess was using this or something like it. I now see that it is using pthreads, which I didn't even realise could work between processes, and I don't think this API has any way to specify process termination behaviour. Anyway, I'd like to suggest that the interprocess docs should make some mention of the behaviour of the synchronisation primitives on process termination, e.g. somewhere near the beginning of http://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/synchronization_… I may now try to implement some primitives that use semop() and unlock automatically. I haven't yet looked at what's involved to implement a condition variable on top of a semaphore, so I may not get very far! Has anyone else ever tried this? Also, I note that Interprocess is using "old style" times, not std::chrono like the std::mutex/condition do. Are there any plans to update this? Thanks, Phil.

5 6

Missing link for Boost.Algorithm documentation
by Alexander Zaitsev 17 Feb '17

17 Feb '17

3 2

Scheduled Outage : Web sites / Trac
by Michael Caisse 17 Feb '17

17 Feb '17

We are planning the final move of services from IU this week. Expect service outages for all web sites including Trac on 17-February-2017 between 16:00 UTC - 00:00 UTC. The mail lists will continue to operate during this time; however, all other sub-domains for boost.org will be affected. Sync'ing bandwidth with IU has been low recently and has caused us to increase the outage window. We will notify these lists when services are available again. Thank you for your patience during the move. -- Michael Caisse Ciere Consulting ciere.com

1 1

Boost.Python sandox or multiple interpreters
by David Bellot 17 Feb '17

17 Feb '17

Hi, I'm using Boost.Python to load and use plugins in Python. Each plugin can define a few functions which are are pre-determined, so that my C++ software knows what to call. However, the mistake I've made was to think that the Python interpreter could be initialized many times, so that each plugins was existing and running into a separate interpreter. It's of course not the case and therefore, each time I load a new plugin, its functions overwrite the functions of the same name from the previous plugin (the one which was loaded just before), and so on. Is there a possibility to either : - have as many independent Python interpreters at the same time ? - or encapsulate each plugin in an independent "environment" ? - or any other solution which would elegantly solve this problem ? :-D Thanks for your help, David

3 6

[trac] how close trac for bug reports
by Oliver Kowalke 17 Feb '17

17 Feb '17

Hello, how can I close boost trac for a specific library? Users should report issues only at github. ty, Oliver

1 0

[teeks] Missing winerror.h for MSVC-9
by Andrey Semashev 17 Feb '17

17 Feb '17

Hi, I see lots of tests failing on teeks99-09b-win2012R2-64on64, MSVC-9.0 because winerror.h is missing. Here's an example: http://www.boost.org/development/tests/develop/developer/output/teeks99-09b… I can see that the file is present in Windows SDK 6.0A, which is supposed to be used with this compiler. The tests are passing on my machine. Could this be a tester configuration issue? Also, all MSVC-15 tests are failing on teeks99-09o-win2012R2-64on64 with the error of 'cl' not being found.

3 14

Functional programming in boost
by Abhishek Kumar 16 Feb '17

16 Feb '17

Hello I am a Computer Science senior from India. I have been doing functional programming for quite some time and have also used C++ for different projects. I recently came across BOOST libraries for supporting functional programming in C++. I want to contribute to one of the BOOST libraries maybe PHOENIX. Are there any open issues or plans in this direction, in which I might help? Thanks Abhishek Kumar

1 0

[release] 1.64.0 deadline for new libraries approaching
by Rene Rivera 16 Feb '17

16 Feb '17

One week from today master will close for commits of new libraries. Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[safe_numerics] Review coming in March
by Andrzej Krzemienski 15 Feb '17

15 Feb '17

Hi Everyone, This is to inform you ahead of time that the formal review of Robert Ramey's Safe Numerics library will be held in about two weeks: March 2 - March 11. Boost Numerics is a set of drop-in replacements for the built-in integer types, which make the guarantee that the results of operations are either correct according to the rules of integer arithmetic or report a diagnosable error (rather than offering modulo arithmetic results, or resulting in undefined behavior, or returning incorrect results as in the case of signed vs. unsigned comparisons). The library can be found on GitHub: https://github.com/robertramey/safe_numerics/ Online docs: http://htmlpreview.github.io/?https://github.com/robertramey/safe_numerics/… Even before the formal review starts, you can provide your review on Boost Library Incubator: http://blincubator.com/reviews/?library_id=426 It will also be included in the final verdict. I will be making the official announcement on March 2. Andrzej Krzemienski, review manager.

1 0

Is there any interest in non-owning pointer-like types?
by Joseph Thomson 14 Feb '17

14 Feb '17

For some time, I have been developing a pair of non-owning pointer-like types that I am currently calling `observer_ptr` and `observer`. I had planned to propose their addition to the C++ standard library, but I have been informed by the author of the original `observer_ptr` proposal <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf> that the ISO C++ committee has rejected his proposal and made clear that it feels there is no place in the standard library for such types, believing that this role is filled to a satisfactory degree by regular pointers. I wholeheartedly disagree with this assessment, so I am bringing my proposal here instead. The `observer_ptr<T>` class template is a pointer-like type that does not do any resource management, and is intended to be used in place of `T*` wherever `T*` is used as a non-owning reference to an object of type `T`. `observer_ptr<T>` has three main advantages over `T*`: 1. `T&` is implicitly convertible to `observer_ptr<T>` which, unlike `T*`, makes it *type-safe*. `T*` can represent things that are not conceptually objects of type `T`: arrays, strings, iterators. No implicit conversion from `T*` means that these things cannot implicitly convert to `observer_ptr<T>`. Pointers aren't even required to point to valid objects (e.g. a past-the-end iterator). Conversely, in a well-formed program, `T&` is *always* a valid object of type `T`. 2. `observer_ptr<T>` documents its purpose. This is really a side-effect of it being type-safe (a type should have a single, specific purpose), but it's worth mentioning. Conversely, when you see `T*`, it may not be immediately obvious what it represents. 3. `observer_ptr<T>` has a minimal interface, which makes it harder to misuse than `T*`; for example, `observer_ptr<T>` has no pointer arithmetic operators, no array subscript operator, no conversion to `void*`. The `observer<T>` class template is a counterpart to `observer_ptr<T>` that has *no null state*; it cannot be default constructed, constructed from `nullptr_t` or constructed from `T*`, and it does not contextually convert to `bool`. The only way to create an `observer<T>` is from `T&`. This allows a "not null" precondition to be enforced at compile-time, rather than having to worry about pointers being null at run-time. Just to give you an idea of the current syntax, here is a simple tree node type (where the nodes do not own their children) implemented using `observer_ptr` and `observer`: class node { public: node() = default; node(node const&) = delete; node& operator=(node const&) = delete; node(node&&) = delete; node& operator=(node&&) = delete; void set_parent(observer_ptr<node> new_parent) { if (parent) parent->remove_child(*this); parent = new_parent; if (parent) parent->add_child(*this); } observer_ptr<node> get_parent() const { return parent; } size_t get_child_count() const { return children.size(); } observer<node> get_child(size_t index) const { return children[index]; } private: observer_ptr<node> parent; vector<observer<node>> children; void add_child(observer<node> child) { children.push_back(child); } void remove_child(observer<node> child) { children.erase(find(begin(children), end(children), child)); } }; And a contrived usage example: node a, b, c; b.set_parent(a); // conversion from `T&` c.set_parent(b); observer_ptr<node> x = c.get_parent(); if (x) // conversion to `bool` { observer<node> y = x->get_child(0); assert(y == c); // comparison with `T&` y->set_parent(a); b.set_parent(y); // conversion from `observer<T>` to `observer_ptr<T>` } A project with a working implementation <https://github.com/hpesoj/cpp-observer/blob/master/api/observer.hpp> and full test suite <https://github.com/hpesoj/cpp-observer/blob/master/tests/observer_tests.cpp> can be found here <https://github.com/hpesoj/cpp-observer>. Regards, Joseph

16 35

What is http://downloads.sourceforge.net/boost/boost_1_63_0.tar.bz2 ?
by Jonathan Wakely 14 Feb '17

14 Feb '17

The link http://downloads.sourceforge.net/boost/boost_1_63_0.tar.bz2 redirects to http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost… which seems to be a snapshot from master, and VERY different to the boost_1_63_0 release (which makes it a VERY misleading URL). How often is that snapshot updated? Shouldn't it have a different name if it's not boost_1_63_0.tar.bz2 but some completely different set of sources (which currently don't even build)? The Fedora Linux packages have been using that URL, for several years by the look of things. So I have no idea what arbitrary collection of changes we've been shipping instead of a proper release.

9 21

[test]redefinition of boost::unit_test::ut_detail::auto_test_unit_registrar
by Takatoshi Kondo 14 Feb '17

14 Feb '17

Hello, I'm using Boost.Test. When I define BOOST_AUTO_TEST_SUITE, I got a compile error 'redefinition of boost::unit_test::ut_detail::auto_test_unit_registrar' if the all following conditions are satisfied: 1. The test suite names are the same. 2. BOOST_AUTO_TEST_SUITE are defined in different files. 3. The files are included by one file. 4. BOOST_AUTO_TEST_SUITE are defined at the same line number. For example, main.cpp #define BOOST_TEST_MODULE test #include <boost/test/unit_test.hpp> #include "one.ipp" #include "two.ipp" one.ipp BOOST_AUTO_TEST_SUITE(a) BOOST_AUTO_TEST_CASE(tc1) { } BOOST_AUTO_TEST_SUITE_END() two.ipp BOOST_AUTO_TEST_SUITE(a) BOOST_AUTO_TEST_CASE(tc2) { } BOOST_AUTO_TEST_SUITE_END() Here is a live demo: http://melpon.org/wandbox/permlink/R459VQ6apnQfapyw If I insert a line the top of two.ipp, no errors are occurred. http://melpon.org/wandbox/permlink/jPRTstNDVb7agjXl According to the following document http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/tests_or… "The same test suite can be restarted multiple times inside the same test file or in a different test files." The compile error is caused by the following line: https://github.com/boostorg/test/blob/develop/include/boost/test/unit_test_… If I replace BOOST_JOIN( BOOST_JOIN( test_name, _registrar ), __LINE__ ) \ with BOOST_JOIN( BOOST_JOIN( test_name, _registrar ), __COUNTER__ ) \ , then the error is disappeared. However, __COUNTER__ is not portable. I know that I can compile one.ipp and two.ipp separately, but I also want to have the option that include them from one file. Is there any good way to solve the error? Thanks, Takatoshi Kondo

2 2

Lazy Spirit Generators?
by Christof Donat 14 Feb '17

14 Feb '17

Hi, In a hobby project, I am using Spirit Karma generators. As far as I have understood Spirit Karma, it is not designed to work lazily in the iterator based interface. It takes an output iterator and writes to it until it has finished. What I am thinking of is a kind of generating range. E.g.: for(auto& char: generator_range(double_ << " + " << double_ << "i", context, c.real(), c.imag())) { // do whatever with the single characters returned by the generator } Is there something like that, which I simply have not found? Christof

3 2

Fit - Request for formal review
by Paul Fultz II 13 Feb '17

13 Feb '17

Hi, So I’ve made a lot of updates to the Fit library since last review. There are a few more changes I would like to make, but most of the work has been done. So, I would like to request for a formal review, and get it on the schedule soon. Vicente Botet was the review manager last time, I don’t know if he would be interested in being the review manager again. Is there perhaps someone else that would be interested in being review manager? https://github.com/pfultz2/Fit Thanks, Paul

1 1

boost::aligned_storage is not a POD.
by Vicente J. Botet Escriba 11 Feb '17

11 Feb '17

Hi, boost::aligned_storage is not a POD. I suspect it is because of the declared constructors private: // noncopyable aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); public: // structors aligned_storage() { } ~aligned_storage() { } Was this intentional? Why aligned_storage is not copyable? Best, Vicente

2 2

[exception] error: looser throw specifier
by Niklas Angare 11 Feb '17

11 Feb '17

On QNX 6.6.0 with GCC 4.7.3 and Dinkumware library in -std=gnu++0x mode, I get the following error: ../libs/exception/test/throw_exception_test.cpp:21:1: error: looser throw specifier for 'virtual exception2::~exception2()' In file included from ../libs/exception/test/helper2.hpp:9:0, from ../libs/exception/test/throw_exception_test.cpp:6: ../boost/exception/exception.hpp:303:5: error: overriding 'virtual boost::exception::~exception() throw ()' libs/exception/test/throw_exception_test.cpp has these definitions: struct exception1: std::exception {}; struct exception2: std::exception, boost::exception {}; There is no error for exception1. Is the bug in the Boost library, the test, the compiler or the Dinkumware library? Other regression runners with GCC 4.7 don't get the error. My regression test runner is NA-QNX660-x86 so you can see all details in the result matrix. Regards, Niklas Angare

1 0

Re: [boost] invalid access to stack memory?
by alexc 11 Feb '17

11 Feb '17

Original Message Sender:Bjorn Reese via Boostboost(a)lists.boost.org Recipient:boostboost@lists.boost.org Cc:Bjorn Reesebreese(a)mail1.stofanet.dk Date:Saturday, Feb 11, 2017 19:39 Subject:Re: [boost] invalid access to stack memory? On 02/11/2017 08:47 AM, alexc via Boost wrote: followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? From a quick look at the code, I do not think that it poses a problem. The idea, as I understand it, is to use RAII to push and pop a "stack frame" (call_stackT::context) onto a thread-local static "stack" (call_stackT::top_.) The context destructor will remove itself from the "stack". Oh, context class “recover” thecall_stackT::top_ indestructor, I miss this in the first place, thank you, Bjorn, it’s a very cool idea to me. _______________________________________________ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] invalid access to stack memory?
by Bjorn Reese 11 Feb '17

11 Feb '17

On 02/11/2017 08:47 AM, alexc via Boost wrote: > followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? From a quick look at the code, I do not think that it poses a problem. The idea, as I understand it, is to use RAII to push and pop a "stack frame" (call_stack<T>::context) onto a thread-local static "stack" (call_stack<T>::top_.) The context destructor will remove itself from the "stack".

1 0

invalid access to stack memory?
by alexc 11 Feb '17

11 Feb '17

Hi all, followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? detail/call_stack.hpp explicit context(Key* k) : key_(k), next_(call_stackKey, Value::top_) { value_ = reinterpret_castunsigned char*(this); call_stackKey, Value::top_ = this; // == store this to a static variable } detail/impl/strand_service.ipp void strand_service::do_complete(io_service_impl* owner, operation* base, const boost::system::error_code ec, std::size_t /*bytes_transferred*/) { if (owner) { strand_impl* impl = static_caststrand_impl*(base); // Indicate that this strand is executing on the current thread. call_stackstrand_impl::context ctx(impl); // == local variable ctx, its this pointer will be stroed in a static variable. Regards, Alex

1 0

Review Request : Boost.SIMD
by Joel FALCOU 10 Feb '17

10 Feb '17

Can Boost.SIMD please be added to the review queue? Michael Caisse has volunteered to act as the review manager. Boost.SIMD is an efficient modern C++ wrapper for SIMD instructiosn sets and computations that aims at providing a standard way to write code taking advantages of SIMD enabled hardwares. Boost.SIMD repository https://github.com/NumScale/boost.simd Documentation https://developer.numscale.com/boost.simd/documentation/develop/ Thanks in advance Joel Falcou - CTO @ NumScale

6 8

Testing DMARC spam binning
by Niall Douglas 10 Feb '17

10 Feb '17

Dear Boost, You all probably noticed that boost-dev now sends you emails from "Your Name via Boost <boost(a)lists.boost.org>" with your original email listed as CC. This should finally mean that DMARC protected email addresses are no longer flagged as Spam by many email services, including this email from me, as boost-dev is no longer sending email with a protected From: address. The list should be made aware that fixing this has taken nine months or so for good reason. A whole ton of work went into making this happen, not least relocating Boost's mailing list services from wowbagger where it had been for almost forever to new hosting partially donated to us for free. What wasn't obvious here was that there were problems of ownership transfer, arranging service donation and the change over and getting many, many long seized up cogs to turn, ones indeed I have failed to turn in many years of trying myself. The fact it all happened without service interruption is an amazing achievement. I'd like to ask the list to formally thank Michael Caisse and his team of many diligent workers who did all of this just to get mail posted here to not get flagged as Spam (there were other motivating factors too of course, but the Spam issue got the ball rolling). It was an awful lot of work for not a very obvious gain here on boost-dev. So thank you. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1

Re: [boost] Requirements: min and max macros
by Bjorn Reese 07 Feb '17

07 Feb '17

On 02/05/2017 06:15 PM, Vinnie Falco wrote: > From > http://www.boost.org/development/requirements.html#Naming > > "Make sure your code compiles in the presence of the min() and max() > macros. Some platform headers define min() and max()macros which cause > some common C++ constructs to fail to compile. Some simple tricks can > protect your code from inappropriate macro substitution:..." Is this guideline still relevant?

4 4

[gsoc17] Attn: We need 2017 mentors and project ideas for Boost!
by Niall Douglas 07 Feb '17

07 Feb '17

Dear Boost community, We are now a few weeks from the beginning of Google Summer of Code 2017! Last year we had the big surprise of being rejected by Google as an org, the second time ever, on the basis that Google felt we needed a year off. Thanks to the quick actions of the Boost Steering Committee and IMC Financial Markets we managed to put together a "Boost Summer of Code" so the students with projects in progress would not be left stranded. Despite a fair few teething problems, I think that worked out okay. As part of filling in our application for 2017, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2017 in order to be approved as an organisation this year. Therefore a lengthy page of awesome project ideas at https://svn.boost.org/trac/boost/wiki/SoC2017 before *February 9th* would be an enormous help to getting us approved again this year and bringing to Boost another US$35,000 of Google funding. If you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list. The year before last we had more slots awarded to us by Google than we had good combinations of student and mentor, so we had to return slots which I believe has not happened here at Boost GSoC in at least a decade. That means that your project ideas have a better chance than ever of receiving funding if you can find a good student, and that is best done by getting project ideas floated *early*. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org or via gsoc-admin(a)boost.org. Thank you in advance for your time.

1 1

[interprocess] Fix doc build ASAP
by Rene Rivera 07 Feb '17

07 Feb '17

This commit < https://github.com/boostorg/interprocess/commit/936afb13f0c106728bcf36c1ce1…> seems to have broken the release archive documentation build: Generating Output File: /home/ubuntu/build/boost/bin.v2/libs/interprocess/doc/docbook/gcc-4.9.2/debug/interprocess.xml /home/ubuntu/boost/libs/interprocess/doc/interprocess.qbk:7421: error: Mismatched [endsect] near column 9. Error: Error count: 1. Please fix ASAP. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[GIL] Bringing old bug fixes on development branch into regular boost releases
by Marcel Metz 06 Feb '17

06 Feb '17

Hello boost devs, I'm a user of the Boost.GIL library and maintained a fork inside inside another project because GIL lacked some features at that time this project needs. This GIL fork happened with boost release 1.37. After reviewing the changes recently it turned out that those can be implemented without maintaining a dedicated GIL fork. However when building the project with the upstream GIL library some compiler specific build bugs popped up. It seems like the forked GIL version already had fixes for those whereas the upstream Boost.GIL doesn't. Further investigation showed that some of those were fixed years ago in the GIL development branch, but never made it back into the master branch (and as far as I understand master is used for release tags). All of those were reported: #3908 - using boost::gil fails when upgrading to libpng-1.4.0 #7270 - C++11 narrowing problem in gil #8896 - image_view compile error under clang 3.1 #9517 - boost gil compile error because of type narrowing (dup of #7270) Is it possible for the maintainer to cherry-pick the corresponding commits from development onto master and put them into the next boost release or are there other steps involved that prevent the bug fix inclusion? Regards Marcel

2 1

[Fit] Update: Request for feedback
by Paul Fultz II 06 Feb '17

06 Feb '17

Hi, I have made a lot of updates to the Fit library based on the changes suggested during the review earlier this year. I have also improved the documentation. I have expanded on the introductory materials and have add a lot more cross-referencing. The documentation can be found here: http://fit.readthedocs.io <http://fit.readthedocs.io/> Let me know of any feedback about the library either here on the mailing list or on Github issues. Thanks, Paul

4 9