January 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

[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

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

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

[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

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

[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

[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

[outcome] Feedback on parts A and B of Tutorial mk III requested
by Niall Douglas 02 Feb '17

02 Feb '17

Dear Boost, I am truly hoping that this will be the last time I ask for feedback on Outcome's tutorial as this is the third complete rewrite. Many thanks for all the feedback so far, this Mk. III tutorial wouldn't look like this without all your help. Part A is 100% on pure expected<T, E> as currently before the standards committee. It has nothing to do with Outcome, but places Outcome in context. Part B is a polemic on why people should not use arbitrary type E in expected<T, E> and instead should restrain themselves to either E = std::error_code or E = std::exception_ptr. I'm requesting feedback on parts A and B of the tutorial which I think are mostly complete now. Specific feedback on these topics is particularly welcomed: 1. I've tried to make some of the code examples in Part A less contrived. Are there any obviously specific additional things I can do (note Parts B and C have more realistic programs)? 2. Are you convinced by the end of Part B that using arbitrary types for type E is a bad idea? If not, what did I fail to do in my explanation? Many thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 5

Re: [boost] Boost XML Serialization Stability across library versions
by Adlai Shawareb 01 Feb '17

01 Feb '17

Thanks Robert, Regarding your suggestion to use text serialization. Since, over time, we will be adding and deleting data from the data set that we serialize, would the following be the right approach to managing the changes in the data that is de/serialized. I'm thinking that we would set the BOOST_CLASS_VERSION before de/serializing. { ar & mInt; If(version >= 2) ar & mFloat; If(version >= 3) ar & mInt2; ar & mFloat2; } Regards, Adlai On 1/25/17 12:04:00, Robert Ramey wrote: > Right. No one as under taken that task. Should be fairly straight > forward using spirit v3. > Robert Ramey

2 3

[container] ::flat_map function force_copy break strict-aliasing on gcc < 4.4
by Владислав Щапов 31 Jan '17

31 Jan '17

Hello! On function: template<class D, class S> BOOST_CONTAINER_FORCEINLINE static D force_copy(S s) { D *vp = reinterpret_cast<D *>(&s); return D(*vp); } gcc 4.3.4 (SLE 11) produced wrong code. It seems that the compiler does not create a copy of an object "s" and returns an object of D(). If I change the signature of function on "BOOST_CONTAINER_FORCEINLINE static D force_copy(const S& s)" the code works and the tests pass. But then does not create a copy of an object "s" in a function call. I'm not sure that this change is correct. Is there any other workaround for this problem with a compiler gcc 4.3 or better disable strict-aliasing? -- Best regards, Vladislav

2 2

C++Now 2017 Registration is Open
by Jon Kalb 31 Jan '17

31 Jan '17

Boost Devs, Registration for C++Now 2017 is now open: http://bit.ly/CppNow2017IsOpen The conference will be in Aspen, Colorado from May 15th to 20th. The deadline for submissions is this Friday: http://cppnow.org/2017-conference/announcements/2017/01/06/call-for-submiss… Jon

1 0

[CallableTraits] Still seeking Review Manager
by Barrett Adair 31 Jan '17

31 Jan '17

Hi, I'm still seeking a review manager for my CallableTraits library. I have spent hundreds of hours on this library, most of which went toward documentation and cross-platform testing. I think a small subset of the features in CallableTraits belong in the C++ standard. Occasionally at work, I have wished this were in Boost already. In short, this library eliminates the need to specialize templates for function signatures, and accounts for the *many* corner cases and cross-platform quirks that most users never care to do thoroughly themselves. I have 9 issues remaining on the GitHub page that would be resolved before an eventual acceptance, and I'd like to write some additional tests and documentation, but I think this library is ready for a review manager. Would anyone like to volunteer? https://github.com/badair/callable_traits Thanks, Barrett

1 0

[regression] Are tests not running?
by Andrey Semashev 31 Jan '17

31 Jan '17

Hi, Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?

6 16

Re: [boost] [sort] pdqsort
by Orson Peters 30 Jan '17

30 Jan '17

Hi, Orson here, I'm the original author of pdqsort. As discussed in this long github issue ( https://github.com/boostorg/sort/issues/11) I have full copyright on the pdqsort implementation (which is freely available under the zlib license on https://github.com/orlp/pdqsort) and am willing to provide it to Boost free of charge under the Boost license. @Marc Glisse, since your 2015 experiment the code has changed, and pdqsort now uses a technique called block quicksort. It's substantially faster for branchless comparisons (50-80%), but it seems that on some systems it also give significant (5-15%) slowdowns for branchful code. I will revert pdqsort's default implementation to the old version, except when the passed in type is built-in, and the comparison operator is std::less / std::greater, then I will use the branchless code. I will provide the branchless code explicitly as well, under a different function name, for experienced users that know their comparison function is branchless. The old implementation was never slower than std::sort in my experiments, for the record. If any of you have further questions, please do let me know.

2 1

[rational] Compilation issues on VS2013+
by Raffi Enficiaud 30 Jan '17

30 Jan '17

Hi Boost, I am having the following issues when compiling boost.test on develop: http://www.boost.org/development/tests/develop/developer/output/teeks99-09e… It seems that the problem is related to rational (worked for the 1.63 release), but I am not sure. Thanks! Raffi

1 0

[Beast] WebSocket is now feature-complete!
by Vinnie Falco 29 Jan '17

29 Jan '17

I'm pleased to announce that Beast 1.0.0-b24 has been pushed to the master branch, making Beast's WebSocket implementation feature complete with respect to RFC 6455 ("The WebSocket Protocol") and draft-ietf-hybi-permessage-compression-28 ("Compression Extensions for WebSocket). The latest version adds support for the "permessage-deflate" extension, which allows WebSocket messages to be compressed using the deflate algorithm. Beast comes with a header-only port of ZLib to modern C++11, no additional library is necessary to use the extension. The library now passes every test in the Autobahn TestSuite including compression tests. Official Repository https://github.com/vinniefalco/Beast/ Documentation http://vinniefalco.github.io/beast/index.html Autobahn TestSuite results http://vinniefalco.github.io/autobahn/index.html Thanks! -- Follow me on Github: https://github.com/vinniefalco

3 2

[Boost.Lockfree] Interest in a ringbuffer class
by Raphaël Londeix 27 Jan '17

27 Jan '17

Hi everyone, Is there any interest in having a lower level ringbuffer type in Boost.Lockfree ? The containers provided today in the library can only store homogeneous types of fixed size. At work, we have refined many implementations of ringbuffer classes that allow one to push/pop raw buffers. Before investing some time into a pull request, I wanted to know if there's some interest in such a type. The interface looks like this: template<typename Self, typename... Policies> class basic_ringbuffer { public: typedef ... buffer; public: buffer* start_write(size_t); void commit_write(size_t); void commit_write(buffer const*); buffer const* start_read(); void commit_read(size_t); void commit_read(buffer const*); public: void reader_reset(); void writer_reset(); private: buffer* _ring() { return static_cast<Self>(*this).ring(); } }; Of course, these are only the lowest level methods, one could implement push()/pop() or other higher level methods. Beyond the fact that this API provides by default zero-copy semantics, this interface is also agnostic to the actual owner of the memory, which allow users to implement custom ringbuffers easily (shared memory, mmap trick to map the beginning at the end, etc.), for example: class custom_ringbuffer : basic_ringbuffer<custom_ringbuffer, SomePolicies...> { buffer* ring() { return some_memory; } }; The usage would look like: custom_ringbuffer rb; // the write side if (auto buf = rb.start_write(100)) { memcpy(buf.data, "some data", 9); rb.commit_write(9); } // the read side if (auto buf = rb.start_read()) { std::cout << std::string_view(buf.data, buf.size) << std::endl; rb.commit_read(buf); } What do you think ? Did I miss something in boost itself ? Should I give a more complete overview of the API ? Cheers, -- Raphaël Londeix http://hotgloupi.fr

6 13

[outcome] Requesting second pre-review of Boost.Outcome tutorial
by Niall Douglas 27 Jan '17

27 Jan '17

Dear Boost, Last November you gave me some valuable feedback on rewriting the tutorial for Boost.Outcome, a C++ 14 library providing a factory and family of policy driven lightweight monadic value-or-error transports. I recently came out of employment contract and so have had the time to rewrite Outcome's Tutorial (anyone interested in employing a remote working C++ consultant please do get in contact). I'd appreciate feedback on https://ned14.github.io/boost.outcome/: 1. Is this rewritten tutorial too simple, too detailed or about right? 2. Do you feel you could use Outcome in your own code without difficulty after reading it? If not, what information is missing? 3. Are you persuaded of the merits of using Outcome after reading it? If not, what else do I need to say? The first FOUR sections at https://ned14.github.io/boost.outcome/ have been rewritten by me to hopefully reflect the feedback you gave me last November, so these have been refactored so far: * Description, Prerequisites and Support * Installing, building and testing Outcome * Quick start for the expert * Tutorial The package repo install methods haven't been implemented yet, these are marked in the docs as todo. These sections have yet to be refactored: * Frequently Asked Questions * Advanced usage: Outcome as a Monad * Outcome and the upcoming std::expected<T, E> Many thanks in advance for any feedback received. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

7 20

Why is this message in Spam?
by Olaf van der Spek 26 Jan '17

26 Jan '17

Hi, > Why is this message in Spam? It has a from address in microsoft.com but has failed microsoft.com's required tests for authentication. Learn more I think this list isn't configured properly.. and this causes some messages to end up in Spam consistently.. Who's responsible for the mailing list infrastructure? Gr, -- Olaf

7 12

[sort] pdqsort
by Steven Ross 26 Jan '17

26 Jan '17

I've been reviewing a proposed addition to Boost.Sort called pdqsort. When using a general-case partitioning algorithm, it performs comparably to std::sort in my testing (Windows and Linux). When used as a replacement for the std::sort fallback in spreadsort, using a branch-reducing optimization it is ~20% faster on ints and floats, and ~40% slower on strings. The concerning part is that any comparison operator that involves a branch may have a comparable slowdown to the string case. pdqsort is also significantly faster than std::sort on mostly-sorted data and some other (relatively common) special cases. This makes little difference when used as a fallback by spreadsort, but does make a difference when used on its own. I see these possible things to do with pdqsort: 1) Reject it completely as too similar to std::sort, which is already highly optimized. 2) Add it as another optional library in the Boost.Sort library. 3) Add it to Boost.Sort, and only use it as a fallback for ints and floats. 4) Add it to Boost.Sort, use it as a fallback for all of spreadsort, and have pdqsort itself only use its branch-reduction optimization on ints and floats. 5) #4, except eliminate the branch-reduction optimization completely from pdqsort for simplicity. Does anyone have a strong preference, advice, or comments on how they use Boost.Sort? Should I run a mini-review for pdqsort?

5 9

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

Boost XML Serialization Stability across library versions
by Adlai Shawareb 26 Jan '17

26 Jan '17

Hi, We want to generate an Serialized XML archive now, and be able to deserialize it and get the same data it in the future. Is Boost XML Serialization guaranteed to be compatible across versions of the library? The XML serialized archive would be stored in a memory chip and, in the future, read back and deserialized. I don't believe that would impact the answer, but want to offer that. Adlai

6 12

Moving away from SourceForge
by Louis Dionne 26 Jan '17

26 Jan '17

Hi, I know this has been discussed in the past, but I would like to revive the discussion about moving away from SourceForge as Boosts' release hosting provider. SourceForge has at least the following issues: - There is no way of controlling the format when downloading an archive of the latest release. This can break people that rely on this in their CI scripts. For example, Metabench's[1] CI was broken for a while when the archive changed from .bz2 to .zip. - SourceForge has been in the middle of some controversies[2]. - Their reliability has not been so great. In the past year, I've had quite a few of my Travis jobs fail due to SourceForge being unresponsive. There are most likely other concerns, but these are the ones that really bite me as a user right now. Am I the only one? If there's some push to do the move, the two main candidates I see would be - GitHub's native hosting - Bintray Thoughts? Louis [1]: https://github.com/ldionne/metabench [2]: https://en.wikipedia.org/wiki/SourceForge#Controversies -- View this message in context: http://boost.2283326.n4.nabble.com/Moving-away-from-SourceForge-tp4691184.h… Sent from the Boost - Dev mailing list archive at Nabble.com.

9 17

Boost.Endian - endian_buffer requirements
by Vicente J. Botet Escriba 26 Jan '17

26 Jan '17

Hi, I wanted to put an Int wrapper inside a endian_buffer and I have some compiler errors depending on whether it is aligned ort not. http://melpon.org/wandbox/permlink/k52wH2A7yagL2vMP I was expecting that the endian_buffer would make abstraction of the wrapped type and consider it just as a sequence of bytes, but it seems that it instead works only for some builtin integral. Am I missing something? Was this restriction intended? Could this restriction be removed and if yes, how? Best, Vicente

1 2

[program_options] implicit value and non-adjacent tokens
by Vladimir Prus 25 Jan '17

25 Jan '17

Hi, some time ago, program_options was modified so that options with implicit value would only take value from the same token. Previously, one could have: ./program -a foo -b # uses 'foo' as value for 'a' ./program -a -b # uses some default value for 'a' ./program -b # has no value for 'a' Now, the first syntax interprets 'foo' as positional option, and one has two write ./program -a=foo Ever since, I hear concerns from users about this behavior. Maybe not very loud, but quite consistent. Maybe, the new behavior is not very good, indeed, because it now mixes syntax matter (whether value is in the same token) with semantic matter (whether an option has implied value). I am considering reverting this change for next version of Boost. Does anybody have opinions either way? Thanks, Volodya

3 5

C++Now / BoostCon 2017 -- Call For Submissions
by Michael Caisse 23 Jan '17

23 Jan '17

This is a quick reminder that the C++Now 2017 Call For Submissions is *open*. All submissions must be made by February 3rd. For more information, see http://cppnow.org/

1 0

boost build with emscripten
by Emil Dotchevski 23 Jan '17

23 Jan '17

I see that there is now emscripten support in boost build but it doesn't seem to work for me. After installing emscripten on Windows, adding using emscripten ; in my site-config.jam, then running b2 from the emscripten command prompt, I get the output below. Any help greatly appreciated! Emil boost-build/src/build\property.jam:743: in class(a)property-map.find from module object(property-map)@26 error: Ambiguous key boost-build/src/build\type.jam:333: in generated-target-ps from module type boost-build/src/build\type.jam:270: in type.generated-target-suffix from module type boost-build/src/build\virtual-target.jam:509: in virtual-target.add-prefix-and-suffix from module virtual-target boost-build/src/build\virtual-target.jam:468: in _adjust-name from module object(file-target)@3764 boost-build/src/build\virtual-target.jam:253: in abstract-file-target.__init__ from module object(file-target)@3764 boost-build/src/build\virtual-target.jam:561: in class(a)file-target.__init__ from module object(file-target)@3764 boost-build/src/kernel\class.jam:90: in class.new from module class boost-build/src/build\generators.jam:558: in generated-targets from module object(C-compiling-generator)@138 boost-build/src/build\generators.jam:453: in construct-result from module object(C-compiling-generator)@138 boost-build/src/build\generators.jam:412: in run-really from module object(C-compiling-generator)@138 boost-build/src/build\generators.jam:386: in class(a)generator.run from module object(C-compiling-generator)@138 boost-build/src/build\generators.jam:994: in try-one-generator-really from module generators boost-build/src/build\generators.jam:1056: in try-one-generator from module generators boost-build/src/build\generators.jam:1294: in construct-really from module generators boost-build/src/build\generators.jam:1378: in generators.construct from module generators boost-build/src/build\targets.jam:1553: in construct from module object(typed-target)@3554 boost-build/src/build\targets.jam:1353: in class(a)basic-target.generate from module object(typed-target)@3554 boost-build/src/build\targets.jam:774: in generate-really from module object(main-target)@3735 boost-build/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@3735 boost-build/src/build\targets.jam:895: in targets.generate-from-reference from module targets boost-build/src/build\targets.jam:1266: in generate-dependencies from module object(typed-target)@2173 boost-build/src/build\targets.jam:1323: in class(a)basic-target.generate from module object(typed-target)@2173 boost-build/src/build\targets.jam:774: in generate-really from module object(main-target)@2988 boost-build/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@2988 boost-build/src\build-system.jam:714: in load from module build-system NT\..\..\munch\boost-build\src\kernel\modules.jam:295: in import from module modules NT\..\..\munch\boost-build\src\kernel\bootstrap.jam:139: in boost-build from module NT\..\..\munch\boost-build.jam:6: in module scope from module

3 8

Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
by Ion Gaztañaga 23 Jan '17

23 Jan '17

On 22/12/2016 10:01, Thomas Dahms wrote: > Dear developers, dear Ion, > > We are experiencing issues on Windows where boost::interprocess relies > on a certain event in the system event log to get the system's boot-up > time. This has proven to be unreliable, because that event is not always > present in the log. In that case, initialization of boost::interprocess > fails. > Several bug reports exist for that issue, e.g. [1, 2]. > > Report [1] contains a proposed fix to use GetTickCount64() and there is > an open PR with an alternative fix to fall back to WMI mechanisms [3]. I > understand that the fix [1] would need some polishing, because > GetTickCount64() is not available in pre-Vista. > > Nevertheless, both proposed fixes have been uncommented and unconsidered > for a while now. Is there any chance that the maintainers could look > into this? Thanks for the ping. I don't think GetTickCount64 is very reliable, as other methods also have problems with time correction, hibernation, fast bootup, etc. In [1] one the last bootup log is lost new processes won't be able to communicate with others. The same happens with [3] In http://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/acknowledgements… there are some instructions to give up on kernel persistence and define the directory at compile time or run-time. This is the best workaround so far. I've trying to find a solution with no luck. I tried: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\BootId in modern Windows systems but hybrid shutdown (default since Windows 8) does not seem to update it as kernel is suspended. Searching for a unique bootup id in windows that does not suffer when hibernating or correcting the RTC is really complicated. Any suggestion welcomed. Best, Ion

2 1

[serialization][test] failures in serialization causing regressions
by Barend Gehrels 21 Jan '17

21 Jan '17

Hi, The regression matrix in develop of Boost.Geometry contains many new compilation failures due to: 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std' 2): ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)???: ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? ar & serialization::make_array(data_, s);and a The master is still OK. Can this be solved? Regards, Barend

6 9

Boost Cmake Modules
by Paul Fultz II 20 Jan '17

20 Jan '17

Hi All, So I would like to start work with adding support for cmake to boost libraries. To make the boilerplate needed to write some of the cmake, I wrote BCM(Boost Cmake Modules), here: https://boost-cmake.github.io/bcm/doc/html/ Of course, the documentation is still a WIP. The core part is bcm_boost_package. So to write cmake for a library, you would just write something like this: bcm_boost_package(core VERSION 1.0 DEPENDS config ) It also provides a mechanism to add tests as well. My goal at first would be to update libraries on per-module level(one PR at a time). So to use cmake, the user wold build and install each library individually with cmake. Later, we can update the cmake modules to support superproject building(which may be necessary for libraries that have circular dependencies). Right now, there are no modules for building documentation. This can be added later, as well. So does anyone have any feedback on this setup? If you had ideas, or would like to help update boost libraries, contributions are welcome. Thanks, Paul

6 13

Testing issues
by Belcourt, Kenneth 19 Jan '17

19 Jan '17

Hi, Tests seem to have stopped cycling, and I see this error in the nightly testing output: error: Cannot create link ../../../boost_root/boost/process.hpp to ../../../boost_root/libs/process/include/boost/process.hpp. error: Link previously defined to another file, ../../../boost_root/libs/proccess/include/boost/process.hpp. # Searching for "process_jam_log" in "/scratch/kbelco/boost_testing/boost_regression/stage/bin"... Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 287, in __init__ self.main() File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 624, in main getattr(self,action_m)() File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 581, in command_regression self.command_setup() File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 352, in command_setup self.build_if_needed(self.process_jam_log,self.pjl_toolset) File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 715, in build_if_needed tool[ 'build_path' ] = self.tool_path( tool ) File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 740, in tool_path , '\n'.join( [ name_or_spec[ 'path' ], build_dir ] ) Exception: Cannot find "process_jam_log" in any of the following locations: Does this problem look familiar to anyone? —- Noel

3 3

[asio] doc format changed?
by Vinnie Falco 19 Jan '17

19 Jan '17

Why did the formatting for Boost.Asio documentation change from 1.61 to 1.63? Compare: http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio.html http://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio.html This looks like it was unintended, and its screwing up search engines (try searching for "Boost Asio 1.63.0 Reference" -- Follow me on Github: https://github.com/vinniefalco

4 9

[Interprocess] move semantics for intrusive_ptr
by Mikolaj Krzewicki 19 Jan '17

19 Jan '17

Dear all, would it be possible to add the rvalue operators to interprocess::intrusive_ptr akin to what is already available in "regular" boost::intrusive_ptr: // Move support #if !defined( BOOST_NO_CXX11_RVALUE_REFERENCES ) intrusive_ptr(intrusive_ptr && rhs) BOOST_NOEXCEPT : px( rhs.px ) { rhs.px = 0; } intrusive_ptr & operator=(intrusive_ptr && rhs) BOOST_NOEXCEPT { this_type( static_cast< intrusive_ptr && >( rhs ) ).swap(*this); return *this; } #endif many thanks, Mikolaj

2 1

[outcome] "sea of noexcept, islands of throwing"
by Andrzej Krzemienski 18 Jan '17

18 Jan '17

Niall, I moved this to another thread, as I believe it is quite independent of the documentation review. I am trying to understand the concept of "sea of noexcept, islands of throwing", and its significance. First, is this programming technique the primary motivation for Boost.Outcome? In the docs, I only saw a small mention of it, but from your replies it looks like this is an important part of the library. But I might be wrong. This "sea and islands" are quite similar to what is described in P0364R0 ("Report on Exception Handling Lite (Disappointment) from SG14"). The authors argue that if the exception control flow is indicated explicitly, the compiler has a better chance of performing optimizations. I understand that your goal (with the Outcome library) is to offer something more modest, but implementable in C++. You are saying, that the C++ compiler can implement similar optimizations, provided that all the try-catch-throw flows are confined to one translation unit. Did I get it right? The authors of P0364R0 claim that in some business domains, like video games, if you encounter a failure to acquire resources, you might as well terminate the program. For this reason RAII is not really that important there: you want to shut down the app rather than clean up and continue. Is it also what you are saying? Do you also intend to support something like 'panic mode' in Rust? I do not know Rust, but I understand that this 'panic mode' is shut down the program but with resource cleanup. Sorry, my questions are quite random. But I am trying to understand the idea. Regards, &rzej;

3 7

Generating Boost documentation with pandoc
by Vinícius dos Santos Oliveira 18 Jan '17

18 Jan '17

Has anyone tried to generate Boost-styled documentation using pandoc? I never fully liked PDF documentation because I never actually print documentation. However, a few weeks ago I got an ebook reader and I've been fascinated by the ePUB format. I'm using it to read even the IETF's RFCs and it's very pleasant. I'm using ePUB to read files even on my usual laptop. Anyway, I was wondering how nice would be to have an ePUB file containing the whole Boost documentation. pandoc has docbook support as one of its input formats and is capable of generating great ePUB output. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

[outcome] Added LEWG expected<T, E> implementation, what about the tutorial?
by Niall Douglas 17 Jan '17

17 Jan '17

Quite a bit of feedback from here, from SG14 and from Reddit expressed disappointment that Outcome doesn't implement the LEWG expected<T, E>. basic_monad makes implementing a fully compliant expected<T, E> just a few hours of work, so I went ahead and added one today and you can see its reference docs at https://ned14.github.io/boost.outcome/group__expected.html. These are the known deviations from the LEWG proposal: * P0323R1 doesn't yet specify what will be done if you try accessing an expected which is valueless due to exception. We throw a bad_expected_access<void> in this situation as that seemed sensible. If the LEWG proposal decides on something different, this implementation will change to track the LEWG proposal. * unexpected_type<E> is implemented as an expected<void, E> and it lets the basic_monad machinery do the implicit conversion to some expected<T, E>. * Types T and E cannot be constructible into one another. * expected<T, E> defaults E to error_code_extended. If you don't like this, predefine the BOOST_OUTCOME_EXPECTED_DEFAULT_ERROR_TYPE macro. * The ordering operators are not implemented due to https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional/ So now you get in Outcome expected<T, E>; option<T>, result<T> and outcome<T>. And the Expected implementation ought to be drop in compatible with any future C++ 20 standard. How would people prefer the Outcome tutorial to now go? Should it mention expected<T, E> at all? Or should it get its own tutorial page (which will look very similar to the tutorial for result<T>). Which order should they be in? Is expected<T, E> easier than outcomes or the other way round? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

docs for hana broken on webpage (boost 1.63)
by Hans Dembinski 17 Jan '17

17 Jan '17

Hi, the current docs for Hana are still broken: http://www.boost.org/doc/libs/1_63_0/libs/hana/doc/html/index.html yields "404 Not Found". Best regards, Hans

5 8

[function] Problem with simple pointer to function
by Fu ji 17 Jan '17

17 Jan '17

Hello all, I have a problem with boost::function, when I try to assign function to pointer I have a crash. It is simple void function(); boost::function <void (void)> m_Wakeup; and the code where crush occurs looks like: Wakeup = &function; Here is also the dump: Program terminated with signal 6, Aborted. *#0 0x03c4a092 in _dl_start () from /lib/ld-linux.so.2* *#0 0x03c4a092 in _dl_start () from /lib/ld-linux.so.2* *#1 0x03d0eca5 in raise () from /opt/vmware/cimpdk-6.0.0-2768847/debug/build-3825889/lib/libc.so.6* *#2 0x03d104e3 in abort () from /opt/vmware/cimpdk-6.0.0-2768847/debug/build-3825889/lib/libc.so.6* *#3 0x03ca2aec in handleSigSegv () from /opt/vmware/cimpdk-6.0.0-2768847/debug/build-3825889/usr/lib/libsfcBrokerCore.so.0* *#4 0x00310002 in ?? ()* *#5 0x025c060a in move_assign () at /workspace/raid0/src/boost/function/function_template.hpp:998* *#6 swap () at /workspace/raid0/src/boost/function/function_template.hpp:870* *#7 operator=<void (*)()> () at /workspace/raid0/src/boost/function/function_template.hpp:1126* *#8 create_interface () at /workspace/raid0/src/CppWrapper.cpp:298* Do anyone have a clue what was wrong ? Best regards

2 2

Interest in updated expression template library?
by Zach Laine 17 Jan '17

17 Jan '17

I'm trying to gauge interest in submitting a library to the review queue, It's an expression template library called Yap using C++14 and C++17 features, built on top of Hana. It does not work quite the same as Proto, though of course it covers the same problem domain. My goal for the library was to cover the Proto functionality (while allowing the user to write less code than she would have had to with Proto) plus more functionality made easier by the new language features. In the examples you will find nearly all of the Proto examples reproduced, each in a-bit-less to dramatically-less code. The only Proto examples that were left out were ones that are now trivial using Yap due to differences in design. Online docs: https://tzlaine.github.io/yap GiHub page: https://github.com/tzlaine/yap Zach

7 32

BGL Algo Contribution
by Robert R. McCune 17 Jan '17

17 Jan '17

Hello, I'd like to contribute to the Boost Graph Library I've written code for Lexicographic Breadth-First Search (LexBFS) How may I best contribute? Thanks, Ryan

2 1

Re: [boost] Boost 1.64 release date
by Rene Rivera 16 Jan '17

16 Jan '17

On Tue, Jan 10, 2017 at 4:16 AM, Raffi Enficiaud < raffi.enficiaud(a)mines-paris.org> wrote: > Dear all, > > I would like to know in advance (approximately) the release date of 1.64. > > Would it be possible to date of the next release at each new release? > Release Dates Spring release on the second Wednesday of April. Summer release on the second Wednesday of August. Fall/Winter release on the second Wednesday of December. <https://svn.boost.org/trac/boost/wiki/ReleaseSchedule> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

5 8

[SmartPtr] alternative to enable_shared_from_this
by Roberto Hinz 16 Jan '17

16 Jan '17

Dear Boost Community, I've been following this list for a time with the desire of contributing to Boost. It seems to me a good idea to start with small and easy to review proposals, before attempting anything big. So my first shot is shared_handle class, an alternative to enable_shared_from_this that doesn't suffer from multiple inheritance issues. It also provides the capability of instantiating a shared_ptr to a member object. doc: https://robhz786.github.io/smart_ptr/shared_handle.html source: https://github.com/boostorg/smart_ptr/compare/develop... robhz786:develop Unfortunately, the implementation produces at least one regression: clang 3.1 crashes when it compiles cpp11_pointer_cast_test.cpp with -std=c++11. There may be others since I couldn't test in all compilers used in the regression tests. Nevertheless, is there any interest? Kind regards, Roberto Hinz

9 11

Logging Documentation issue
by jack nade 13 Jan '17

13 Jan '17

There is no visible Design Figure in the Design Overview at http://www.boost.org/doc/libs/1_63_0/libs/log/doc/html/log/design.html using Chrome or IE. The Design Overview refers to it 4 times.

3 3

shutdown ticket-system on svn.boost.org
by Oliver Kowalke 13 Jan '17

13 Jan '17

Hi, I encountered that the ticket system at svn.boost.org is not up-to-date: components coroutine2 and fiber are missing. At least the reports created for coroutine2 and fiber do not know the components (not in drop-down list). I would vote for shutdown of the ticket-system in favour of github - for me it makes no sense to manage two bug reporting systems. best regards, Oliver

9 19

Stringify
by Olaf van der Spek 13 Jan '17

13 Jan '17

On Wed, Jan 11, 2017 at 8:03 PM, Roberto Hinz <robhz786(a)gmail.com> wrote: > On Wed, Jan 11, 2017 at 3:40 PM, Roberto Hinz <robhz786(a)gmail.com> wrote: > > > > > Hi, > > > > I've been working in a format library that contains a function template > > called appendf that can do this: > > > > std::string str("blabla"); > > boost::stringify::appendf(str) () (" AAA ", 25, " BBB ", {255, "x"}); > > assert(str == "blabla AAA 25 BBB ff"); // ( 255 formated in > > hexadecimal ) > > > > This library - I call it Boost.Stringify - is in very early stage of > > development and I though it would be to premature to mention it now. But > > given the repercussion in this thread so far, I changed my mind. So I > will > > soon publish it in github and I will start to write a brief documentation > > so that I can soon present here to gauge interest. > Hi, I think your library deserves it's own thread. ;) How does it compare to for example fmtlib? Gr, Olaf

2 1

gregorian::date limited to years 1400 - 9999
by Viacheslav Usov 12 Jan '17

12 Jan '17

Conceptual question: why is the Gregorian calendar's time range limited to years 1400 - 9999? If this or any of the below has already discussed in some public forum (which I have failed to found, gmane's rebuild being possibly the culprit), kindly point me it to it. I am specifically interested in 1400. It seems completely arbitrary to me. It predates the time the calendar was introduced by almost two centuries, so that cannot be the reason why it cannot support earlier times. ISO 8601 allows the entire 0 - 9999 range, even though dates earlier than 1582-10-15 are subject to an agreement among the parties involved. Extending the proleptic Gregorian calendar all the way back to year 0 seems like one of the very few things that make sense. So my question is, is there any technical problem in supporting the entire 0 - 9999 range? If not, then my next question would be, what else would speak against supporting the 0 - 9999 range? If you expect some compatibility could be broken by that, then perhaps the low end could become a template parameter with the default at 1400? Cheers, V.

5 7

Tagged pointer library?
by Hans Dembinski 11 Jan '17

11 Jan '17

Hi all, I recently learned about tagged pointers, https://en.m.wikipedia.org/wiki/Tagged_pointer. Over the weekend, I was working on a tiny_string implementation which has a width of only one pointer. Essentially it's a null-terminated char* array managed by std::unique_ptr. On my system, std::string is four times larger (probably 8 byte for the pointer, 8 byte for the length, 8 byte for the allocator and 8 byte for … good measure?). With a tagged pointer, I could even implement a small-string optimisation in that tiny_string, by storing small strings with up to 7 bytes in the memory that otherwise holds the address to the char* array. The tag then allows you to discriminate between the two uses of the memory. You may rightfully question whether it is really practical to do this, but it is certainly one possible application of a tagged pointer. Looking into boost, I found that the lockfree library has a tagged pointer implementation in its "detail" namespace. The implementation is nice, because it falls back to a safe version with a separate tag field on systems which do not follow the required alignment conventions. Wouldn't it make sense to make the tagged pointer accessible by users, i.e. place it in a separate library (or in the existing smart_ptr library)? Best regards, Hans

3 3

tensor library
by Paulo Pereira 09 Jan '17

09 Jan '17

Hello everyone, I am new in the community. I would like to ask, how interesting would be to have in boost a new container with multiple indices (tensor) using variadic templates. I know that Boost.MultiArray library already exists in boost. However I think it does not fulfill the readability and friendliness of something like: newlib::tensor<3,double> t(2,2,3); t(0,0,0)=1; also with extra possibilities similar to Matlab/Octave t(newlib::all,1)=0; I would also like to add mathematical operations t1=t2+t3; using lazy evaluation like in armadillo package or in the David Abrahams and Aleksey Gurtovoy book (C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond). I fell that something similar to this is very important for numerical calculations and somehow it is not a standard in C++ (maybe I am missing something). Best regards, Paulo

4 3

Interested in contributing
by vivekroyandroid＠gmail.com 09 Jan '17

09 Jan '17

Sir, I would like to contribute in whichever way possible. I have a decent amount of knowledge in C/C++, but I am new to contributing to open-source. If someone might guide me and tell me how to proceed, I would appreciate it. Thank You. Vivek Roy --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Crosscompiling context and fiber without multithreading
by Vitaly Osipov 09 Jan '17

09 Jan '17

Dear all, I am developing for a PowerPC target under real-time os und studying a possibility to employ fibers. They seem to be a good fit, since we have a single thread but several entities, which could in fact be considered parallel. Data exchange through channels also is relevant for the project. The problem is, that though we are provided with a quite recent compiler gcc 4.7.4 with c++11 support, the multithreading part of std is missing, since the OS has its own implementation of multithreading functionality different from pthreads and std::thread. Is there any chance to compile context and fiber without multithreading support? Or it is used under the hood and can not be avoided? Best, Vitaly

2 3

Boost 1.63 vs GCC 5.4.0
by Andrzej Krzemienski 06 Jan '17

06 Jan '17

Hi Everyone, I am trying to determine if Boost 1.63 (or 1.62) will work on GCC 5.4.0 on Linux. I can see in release notes that Boost 1.62 was tested on Linux with "GCC 5.4.1" (I am not aware that v 5.4.1 even exists). However in release notes for 1.63 there is no GCC 5.4 listed for Linux (only for Android). Does anyone know if there is any reason to suspect that Boost 1.63 may have problems on Linux with GCC 5.4.0 ? Regards, &rzej;

4 3

Re: [boost] [root_ptr] Into consideration by Qt & QtQuickCompiler
by Mathias Gaunard 03 Jan '17

03 Jan '17

On 28 Dec 2016 2:32 pm, "Phil Bouchard" <philippeb8(a)gmail.com> wrote: Greetings, I did my homework and the Qt Project is considering root_ptr despite the fact that there is no paper written on it: http://lists.qt-project.org/pipermail/development/2016-December/028222.html So there is a big demand out there. I am not sure what else is required to find a review manager but everything is on a silver plate now. I don't understand how you can possibly interpret that reply as "big demand".

2 3

bad boost_1_63_0.tar.bz2 sha256sum
by jack nade 03 Jan '17

03 Jan '17

Expect beae2529f759f6b3bf3f4969a19c2e9d6f0c503edcb2de4a61d1428519fcb3b0 for https://sourceforge.net/projects/boost/files/boost/1.63.0/boost_1_63_0.tar.… Get a9eec759dd97798b06eb258a1c6ad4a39ff43b483594a22298ccdfae8116ce16

3 3

[trac] Boost v1.64 in the milestones?
by Raffi Enficiaud 03 Jan '17

03 Jan '17

Dear all, Since 1.63 is (almost) out, would it be possible to have 1.64 in the milestones of trac? Thanks, Raffi

7 15

Review quality (was: [stacktrace] review (changing vote to NO))
by Andrey Semashev 03 Jan '17

03 Jan '17

On Mon, Dec 26, 2016 at 3:58 AM, Vladimir Batov <Vladimir.Batov(a)constrainttec.com> wrote: > On 2016-12-26 10:41, Andrey Semashev wrote: >> >> Acknowledging the need for a particular functionality is not the same >> as accepting a particular implementation. > > Put bluntly users do not care about implementation. Please, don't speak for others. I, personally, very much care about implementation, and I can see other reviewers did take a look at the implementation as well. I think, making judgment on the library quality without regard to the implementation quality is irresponsible and short sighted. That kind of approach tend to result in "5 minute hack" solutions of obviously poor quality. But that's just my opinion. > They care about > functionality provided. I advocate giving the lib a "foot in the door". That > and far better feedback from the users will be a strong incentive for the > author to keep working and improving the lib. You seem to prefer > all-or-nothing approach. I believe it's unrealistic and bad. You might > disagree. First, nowhere in my message I advocated for "all-or-nothing approach". What I advocated for is a fair review, outlining all ups and downs of the library, and if the reviewer feels downs are significant enough, he would be right to vote for rejection. Second, it's not like the library does not exist before it is accepted. Users and the author have every opportunity to try the library in the field, if they want to. There is blincubator.com as well. >> By >> turning a blind eye on a design flaw of a presented library you're >> doing a disservice to the library author and the library users. >> Instead, by giving constructive feedback (positive and negative), >> especially if supported by real world experience, you help the library >> improvement. In fact, this (the feedback) is the most valuable reward >> for the author from the review. And let me say, there's nothing >> humiliating in having a library rejected during a review. > > Well, I do not get scolded often these days. So, it is quite "refreshing" to > learn that I am "turning a blind eye on a design" and "doing a disservice". > I thought I was merely expressing my humble opinion... but probably I got it > all wrong. Well, maybe you shouldn't have taken my message personally then. It wasn't meant to scold anyone. If anything, it was written with the intent to provide another (mine) perspective on what a review is and object to your notion of library review as being a humiliation. The last part, actually, was kind of offending from your side and what triggered my reply in the first place. > As for the feedback, then I do not see voting something useful "no" to be > much of a feedback. Indeed, the author does get initial feedback during a > review. However, not all of that feedback is constructive. Some valid, some > subjective, some capricious. After it's voted out the feedback is no more. The review entails a discussion. Some reviewers get convinced. Some review points get refined, and the author gets convinced. Sometimes review votes get changed. And it's not like the votes are final - the actual decision is taken by the review manager, and he can weigh the points made in reviews and discussion at his discretion. And it's not like the library disappears after the review. If it's interesting and useful, it'll have its users, and they will no doubt provide feedback. > Real valuable feedback will come when the lib is in Boost. People'll start > using the lib (I would) in their real projects asking for this and that. Real world usage produces valuable feedback, no doubt about that. But Boost acceptance is not a pre-requisite for real world usage. >> There are things that can be fixed post-review. >> ... >> There are other things that cannot be fixed easily and would probably >> require changing library design. Those changes often affect library >> API and usage patterns, which warrants the need of a new review of the >> reworked library. > > Yes, all that sounds wonderful... on paper. In real life as a user I'll take > what's available first. Then, if that is improved in the next version, I'll > take it gladly. If design changes and gives me more or fixes something, I'll > accept that. I doubt you'd be so easy to accept the changes if that required you to rewrite half of your code. :) > I do not remember Spirit transitioning from V1 to not > backward-compatible V2 being re-reviewed. I can be wrong though. I don't remember the review either. But Spirit v2 was added in addition to Spirit Classic (aka v1), which is still available in Boost. It was more like a new library was added. Should it have been reviewed? In my opinion, at least a mini-review should have been performed. Luckily, Boost.Spirit dev team has rich experteese in the domain and a lot of experience gained with v1, so v2 was a success. >> In those cases it's better to reject the library so >> that the new, improved version is presented later. > > Again, wonderful.. in theory. The reality IMO is different because 1) > "improving" is better with real user feedback that you deny to the author by > voting "no"; 2) "later" might never come as the review process is quite > exhausting/draining; not everyone wants to experience it again; you might > say "too bad for him"; I'll say it's bad for the user as well as they end up > with your good intentions and no library; 3) "later" might be too late as by > that time the user'll have something else in place. Again, it's not like the library doesn't exist outside Boost. If it fits you, go right ahead, so 1 is not true. But Boost does set a certain bar of quality, and the review process exists precisely to maintain that bar. And I'll take your 2 and 3 any time if it results in a high quality library in Boost. >> Consider also that whenever a library is accepted into Boost, the >> matter of backward compatibility appears. If the accepted library is >> somehow seriously flawed, that flaw may be difficult and painful to >> fix in the future. > > "difficult", "painful", "backward compatibility"... Come on. I am sure > you've been in the industry for a while, have "survived" many > upgrades/updates, etc. We all know it's not an issue. We update, adjust, > move on. Let's just say it can be an issue. On Mon, Dec 26, 2016 at 3:54 AM, Robert Ramey <ramey(a)rrsd.com> wrote: > On 12/25/16 3:41 PM, Andrey Semashev wrote: >> >> Consider also that whenever a library is accepted into Boost, the >> matter of backward compatibility appears. > > How so? Certainly there is no requirement that boost libraries support older > versions of C++ and/or compilers - and indeed many don't. I don't think I > see what you're referring to here. I think you misunderstood. I wasn't speaking of C++ versions backward compatibility. I was speaking of the library backward compatibility. AFAIK, making backward incompatible changes is still considered an undesirable practice. >> If the accepted library is somehow seriously flawed, > > Then of course it should be rejected. Of course reaching a concensus as to > whether it's flawed might not be so easy. Right, that was my point. >> [1]: http://www.boost.org/community/reviews.html > > I checked this page and don't see where it says anything relevent to your > points. Maybe you missed this section: http://www.boost.org/community/reviews.html#Comments <quote> Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. The goal of a Boost library review is to improve the library through constructive criticism, and at the end a decision must be made: is the library good enough at this point to accept into Boost? If not, we hope to have provided enough constructive criticism for it to be improved and accepted at a later time. The Serialization library is a good example of how constructive criticism resulted in revisions resulting in an excellent library that was accepted in its second review. </quote>

8 16

[sandia] Sandia-intel-16.0-c++11 is running in C++14 mode
by Andrey Semashev 02 Jan '17

02 Jan '17

Hi, Despite what the name implies, Sandia-intel-16.0-c++11 is actually running in C++14 mode. You can see there is -std=c++14 in the compiler command line: http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… Could this inconsistency be fixed?

2 1

[Stacktrace] Review Manager report
by Niall Douglas 02 Jan '17

02 Jan '17

Firstly happy new year to everyone, and many thanks to all those who participated in the peer review of proposed Boost.Stacktrace before Christmas. I received the following formal reviews: 1. Vladimir Batov (YES) 2. Klemens Morgenstern (YES) 3. Andrey Semashev (NO) 4. Nat Goodspeed (YES) 5. Artyom Beilis (NO) 6. Barrett Adair (YES) Extensive comments without a formal acceptance recommendation were also made by: 1. Peter Dimov 2. Edward Diener There was a very noticeable lack of consensus on the strengths and weaknesses of the proposed library which has made summarising all these reviews into a coherent report with concrete conditions for acceptance very difficult. Antony also responded to many of the concerns throughout the review, agreeing with some points, disagreeing with others. I think this lack of consensus stemmed from multiple opinions on what a stacktrace library ought to provide: Minimum viable product: A portable backtrace() and backtrace_symbols() implementation with a C++ STL idiomatic API. The stack backtrace capture implementation must not allocate memory and be "fast". Note that backtrace_symbols() does NOT symbolise into strings containing source file name and line number. It also allocates memory (backtrace_symbols_fd() does not). Opinion 1: Portable serialisation of the stacktrace with instruction pointers converted to offsets into SO/DLL binary paths so a later external process can use those in combination with their debug symbols to retrieve source file names and line numbers. Ideally the serialisation formats supported would include those consumable by well known tooling for this purpose e.g. addr2line or llvm-symbolizer. Opinion 2: That Stacktrace can in process use debug symbols to retrieve source file names and line numbers. This could be implemented by invoking addr2line or equivalent as a child process which has the enormous advantage of being async safe, but has disadvantages in almost every other area. Or it could be implemented by one's own DWARF parser but with the huge caveat that memory could be badly corrupted by now. Opinion 3: That Stacktrace be "async safe" in that backtraces can be safely captured and parsed from a signal handler or SEH/TEH handler callback or point of C++ exception throw. *This implies no memory allocation during the execution of the handler*. >From the reviews, I think there is consensus that the minimum viable product is achieved in Stacktrace though many mentioned that improvements are needed to the documentation and most of the negative feedback was on features not in the minimum viable product described above. I therefore recommend the ACCEPTANCE of proposed Boost.Stacktrace into Boost with the following conditions: 1. That the documentation more clearly set out what Stacktrace does and especially does not do, and that the default facilities provided are those of the Minimum Viable Product described above i.e. no source file nor line number discovery, no external dependencies on libraries not always provided on the target platform, no invocation of child processes, no async safety during stacktrace parsing. Stacktrace ought to be pared back to the minimum viable product featureset with no external dependencies at all. 2. That suitable predefined macros opt in to additional functionality such as serialisation of offset translated backtraces, retrieval of source code path and line number etc. Enabling these may introduce dependencies on third party libraries not always present on a system such as libunwind, or on third party helper utilities such as addr2line. I would recommend that the APIs the use of which are dependent on such third party items are entirely compiled out of Stacktrace when the macro enabling them is not defined. 3. That the documentation describe ONLY the default minimum viable product functionality in its tutorial and quick start. All extra functionality enabled by macros is to be relocated into a separate documentation section away from the main documentation e.g. "Advanced/optional features". 4. That APIs made available only when a given macro has turned them on are documented as such in the API reference docs. I'd like to congratulate Antony on getting yet another library of his into Boost. I hope some of his magic rubs off on me when I bring Outcome to review later this year! Regards, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 3

Re: [boost] documentation 1.63 not up to date
by Oliver Kowalke 02 Jan '17

02 Jan '17

Hello Daniel, I'm referring to http://www.boost.org/doc/libs/1_63_0/libs/fiber/doc/html/fiber/performance.… . The page should contain three tables (the one related to threads is missing) - my modification s date from end of November. Oliver Am 27.12.2016 1:35 nachm. schrieb "Daniel James" <dnljms(a)gmail.com>: On 27 December 2016 at 08:59, Oliver Kowalke <oliver.kowalke(a)gmail.com> wrote: > Hi, > could you update the documentation of boost-1.63 please - it is not up to > date. > For instance in boost.fiber commit 648de6a66544c5d03e5595cb25ed76 5ee0cd40d2 > (17.12.2016) is missing. > Thank you in advance, > Oliver The documentation on the website should just be whatever is in the release. It's a bit hard to know without a link to the page where that change is meant to be. I think what you're seeing on the website are the html files that are checked into git. I guess the documentation build isn't replacing them. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

3 4