June 2019 - Boost - lists.preview.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

[asio][coroutine] forbid_suspend blocks
by Vinícius dos Santos Oliveira 07 Aug '19

07 Aug '19

I've implemented a dumb linter using Python + clang API that allows you to mark certain blocks as “atomic in respect to coroutines” using C++11 attributes. Usage example follows: void f() { int yield; g(yield); [[bt::forbid_suspend]] { // Comment this call to make linter accept the code g(yield); t(); } } You can change bt::forbid_suspend to another identifier by tuning settings on the beginning of the script. The prefix forbid was inspired by Rust's linters[1] as you cannot disallow the linter from inside the forbid_suspend block. Some limitations follow: - A suspend point is identified by looking references to any id equals to yield in the last argument passed to function calls. It means that yield[ignored_ec] and alike will be correctly identified, but it needs to be named yield and it needs to be the last argument to the function call. - I haven't found a way to extract attributes related to COMPOUND_STMT nodes with clang API, so I manually look for token gaps and do a simple regex. It means you cannot use macros to [[bt::forbid_suspend]] as the macro won't be expanded. - You better call the script with '-x c++' and also ' -I/usr/lib/clang/5.0.1/include'. Like I've said in the beginning of the email, it's a *dumb* linter, which means it doesn't try to handle all cases. Therefore, I don't hope to do many changes to it or maintain it to work against newer releases of clang and I'm only uploading it to gist (not fullblow Github): < https://gist.github.com/vinipsmaker2/d930fbe5b7597432b021effe618da171>. It should also be easy to hack as it is very small. I'm releasing the linter under public domain. Enjoy. I have been using fibers in a daily basis on the last months of my job to solve networking problems on a gateway project. Some of the technologies I use are: - Boost.Asio and its spawn function. - A few custom synchronization primitives for the fibers (e.g. mutex, semaphore). - Eventually I'll have to write a custom spawn function that returns a joinable handle so I can kill the usage of a fiber::barrier in a few places. I've been using the linter for about a week already and looks fine. My use case are: - To prevent iterator invalidation in regions accessing shared variables. - To guarantee events order in algorithms that handle races (cannot yield while task YYY hasn't finished). The project I use it in is not an open source project, so I cannot talk much more about it. Also, I don't claim my solution is original. I wouldn't be surprised if the very same solution exists in the wild (please let me know if you know of a similar approach). This is not a new problem. It is know for some time. For instance, in P0171, Gor Nishanov noted this same problem: “In coroutines the suspend point is clearly marked with await, which tells the reader that something unusual happens in this function and allows the reader, for example, to confirm whether the lifetimes of the objects of interest align with the lifetime of the coroutine or not, whether some locks need to be acquired to protect some concurrently accessed data, and whether some locks need to be released before the execution reaches the suspend point.” — <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html>, 2015 However, the solution he presented was to manually examine whole blocks of code without help from the compiler. I argue that the solution he presented is as error-prone as manually looking for exit paths that don't free acquired resources in languages lacking RAII. And I've been spoiled too much by RAII. Furthermore, I take this comment of his with highly suspicious look: “Since we are on the subject of maintenance nightmares, we would like to offer a conjecture that the absence of the await in P0114 is a likely source of many maintenance nightmares. Without a syntactic marker to signal to the person reading the code that something funny is going on, it is impossible to tell whether the following code is correct or not” — http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html If I had to give a vote to the proposal he was defending or Chris' proposal, I'd probably have chosen Chris'. [1] https://doc.rust-lang.org/reference/attributes.html# lint-check-attributes -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

Failed reconnection
by JH 11 Jul '19

11 Jul '19

Sorry for keeping posting questions about ASIO TCP socket reconnection regarding to network interface changes, I am very much stuck at the moment. As I described in other emails, when one network interface WiFi failed, the network interface Ethernet takes over, the client application using boost ASIO TCP socket cannot detect the broken of WiFi, it continually sent messages to the remote server via the broken WiFi interface without triggering errors but obviously the server could not receive messages any more. So my solution is prior to send message, it ping to 8.8.8.8 via the network interface WiFi, if it failed, it called the SetConnection again to close the socket binding to WiFi interface and to start reconnection to bind to Ethernet interface: void SetConnection(void) { if (this->mSocket.lowest_layer().is_open()) { std::cout << "Set connection close socket" << std::endl; this->mSocket.lowest_layer().close(); } boost::asio::ip::tcp::resolver resolver(this->mIoService); boost::asio::ip::tcp::resolver::query query(this->mHost, this->mPort); this->mIterator = resolver.resolve(query); this->mContext.load_verify_file("ssl/ca.pem"); this->mSocket.set_verify_mode(boost::asio::ssl::verify_peer); this->mSocket.set_verify_callback(boost::bind(&client::verify_certificate, this, _1, _2)); boost::asio::async_connect(mSocket.lowest_layer(), this->mIterator, boost::bind(&client::handle_connect, this, boost::asio::placeholders::error)); } But it did not work, the error: handle_connect connect failed: Network is unreachable What I am missing here? How can I make the TCP socket reconnection? Thank you. Kind regards, - jupiter

2 3

Mother of all Variants
by Robert Ramey 05 Jul '19

05 Jul '19

I'm way out of my depth in the variant discussion. Seems to me it revolves around all the trade offs regarding design choices. Could we perhaps decide not to decide. Suppose we create a type which looks like: template< bool BasicGuaranteeSupported, bool StrongGuaranteeSupported, bool EmptyStateProhibited, bool AssignmentSupported, bool MoveSupported, class T ... > struct mother_of_variants{ // some trivial mp11 code }; Now we could define: using boost_variant = mother_of_all variants< bool true, //BasicGuaranteeSupported, bool true, //StrongGuaranteeSupported, bool true, //EmptyStateProhibited, bool true, //AssignmentSupported, bool true, //MoveSupported, >; std_variant, std_optional, std_expect, boost_outcome, etc. would be similarly defined. And some "extras" like no_except_variant, trivial_variant, etc. would be added. and of course my favorite candidate: using safe_variant = mother_of_all variants< bool true, //BasicGuaranteeSupported, bool true, //StrongGuaranteeSupported, bool true, //EmptyStateProhibited, bool false, //AssignmentSupported, bool false //MoveSupported, >; In addition, we'd have some type traits: mother_of_all_variants::no_runtime_allocation<mov>; mother_of_all_variants::no_double_instancen<mov>; mother_of_all_variants::is_mother_of_all_variants<mov>; etc. Just think that of all the time we've spent on discussions about optional, expected, std::variant, boost::variant, etc. At this rate, these discussions will keep hounding us forever. Of course I realize that the main purpose of having these variants of variants is to justify the discussions - but perhaps we might be ready for a new topic. Robert Ramey

17 57

Boost Version 1.47 not building with 2017.
by nunna, sarath babu (GE Healthcare) 03 Jul '19

03 Jul '19

Hello, 1.47 boost is not being built with VS2017. We want to get boost 1.47 built with VS2017, So that we can integrate them with our VS2017 code base. Please guide us, it will be a great help. Thanks, Sarath.

4 9

out_ptr review
by Glen Fernandes 30 Jun '19

30 Jun '19

[Edit: Some changes for clarity within, as it was pointed out on Slack that some of the phrasing is confusing. Also updated subject.] Many thanks to JeanHeyd for going through the Boost review process, and to Zach for managing the review. Briefly: I cannot justify acceptance for out_ptr just yet in its current form. I hope to see it return for a new review if the feedback from this review shapes the design so that some of these concerns are resolved. Second: This excludes "inout_ptr" (for which I had even more concerns) and just covers "out_ptr" which is the simpler and more common use case of the two. Below when comparing "what happens under the hood" with out_ptr against the hand written code that a user would write to use a typical C out-pointer API with smart pointers, this is what I'm comparing: [Typical code user would write to use a smart pointer]: Type* raw; Result result = TheCApi(args..., &raw); if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Smart<Type, Deleter> smart(raw, etc...); [What would happen under the hood when using out_ptr]: /* First, 'smart' already has to exist here before TheCApi is called. Either as Smart<Type, Deleter> smart; or Smart<Type, Deleter> smart(nullptr, etc...); depending on deleter */ /* User writes: Result result = TheCApi(args..., out_ptr(smart)); or Result result = TheCApi(args..., out_ptr(smart, etc...)); depending on deleter */ Type* raw = nullptr; Result result = TheCApi(args..., &raw); if (raw != nullptr) { smart.reset(raw); // or smart.reset(raw, etc...); depending on deleter } if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Concern 1. Having to define the smart pointer before TheCApi is called. Ordinarily this might be fine for some smart pointers and stateful deleters, but it may not be fine or desirable for others (depending on the deleter, and depending on the use case). Concern 2. The original user code initializes the smart pointer based on Success(result). The out_ptr version does so based on whether the raw out pointer was changed to something non-null by TheCApi. This might be fine for some cases, but it may not be for others. That it isn't the same as fundamental logic as the user code bothers me, though. Concern 3. The equivalent of the hand written user code is less overhead. Personally I'm of the opinion that this doesn't matter too, but here the author does say he has users who cannot abide by it, and that this facility needs support from e.g. std::unique_ptr to be viable. I'm not a fan of needing unique_ptr implementations to add support for this to make it comparable to some user's hand written code (And this also leads to concern 4 below). Concern 4. The UB optimization that the author wrote because of Concern 3 is a real concern to him. The UB optimization has no place in Boost, and one of which doesn't even work with many C++ library vendors' unique_ptr. (Fortunately the Boost reviews have already echoed this sentiment and I believe this is going away). Concern 5. Supporting other custom smart pointers requires effectively re-implementing out_ptr_t by specialization. I have come to see this as not viable. (Already mentioned in other reviews, and I echo this.) Concern 6. C APIs where the deleter (its state, logic, etc.) are governed by some other result from TheCApi. This is can be worked around in many cases, but the workaround is clumsy. Or insupportable, in other cases. i.e. The stateful deleter in the example above is always initialized with 'etc...' either before-hand via Smart<Type> smart(nullptr, etc...) or at call site with: TheCApi(args, out_ptr(etc...)); before analyzing other results of calling TheCApi. [Concern 7. This concern I had made notes about pre-review has already been eliminated, when the unconditionally noexcept destructor is now only conditionally noexcept.] Other thoughts: The suggestion by Emil lead to an interesting alternative idea to this problem domain, but I had no time to fully explore it. I don't think it would address all of these concerns. It has some other greater appeal, e.g. a way to call C APIs that materializes the smart pointers as results (along with C API return value) of an "Invoke-style" thing. Or even a way to transform a C API with out-pointers into a C++ callable that returns smart pointers (along with C API return value) via a "Bind-style" thing. Glen

2 1

out_ptr's formal review starts now!
by Zach Laine 30 Jun '19

30 Jun '19

Dear Boost community, The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th and ends on Wednesday, June 26th. out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks ( https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc) and the Standard C++ proposal for more details). Online docs can be found here: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc The GitHub repository is available here: https://github.com/ThePhD/out_ptr Also, there is an associated standards proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/ThePhD/out_ptr/issues. Regards, Zach Laine

11 31

out_ptr review
by David Sankel 29 Jun '19

29 Jun '19

# Whether you believe the library should be accepted into Boost No. Not until some of the major issues are addressed. # Your name David Sankel # Your knowledge of the problem domain I've had to wrap C APIs on multiple occasions. # What is your evaluation of the library's: ## Design The design of the `out_ptr` type is reasonable as a shorthand for calling certain C APIs. In my experience a use case for `in_out_ptr` has never come up. Given the subtleties of its correct (and likely rare) usage, I'd be in favor of leaving this out of the library altogether. Especially given that the semantics of when 'release()' is called are not specified. I agree with the other comments that the customization point is not minimally complete. Ideally a customization point would not require one to replicate all the functionality of the class I'm customizing and, instead, only require a few general purpose functions that that interface can make use of. ## Implementation There are two implementations of `out_ptr`. The one called "clever" invokes undefined behavior as a means to squeeze out some extra performance. I do not think the performance overhead of using this library with the "non clever" implementation justifies the potential portability and and other risks associated with depending on undefined behavior working a particular way. It looks like "clever" mode was #ifdef'ed out, but removing it as cruft would improve maintainability of the implementation and remove the complexity of having an additional `core_out_ptr_t` class. The provided implementation works for smart pointers that follow conventions like the standard, but has some additional logic if the types happen to be `std::shared_ptr` or `boost::shared_ptr`. This hard coded special casing won't work with, say, a company specific shared pointer implementation. This relates to my earlier comment that the customization point should be simplified. ## Documentation The recommendation in the "caveats and caution" to not use out_ptr outside if/else conditionals goes a bit far in my opinion. It is common practice to make function calls that emit failure with return codes in conditionals, as in: ``` if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database, sqlite3_close))) { std::cout << "Problem opening the file"; } ``` For these cases it is safe to use `out_ptr` so I'd suggest rewording the recommendation to allow calls like this. "Almost all well-designed C APIs will set the user-provided output pointer argument to NULL/nullptr upon invalid parameters". This is a very difficult claim to make (what's the sample size?). I'd suggest changing "Almost all" to "Many". I don't understand what the issue is here with APIs not setting the out parameter on failure (which IMO is good practice especially as it relates to strong exception safety guarantees). These APIs have return codes that need to be inspected anyway. The reference documentation reads like a specification rather than what I would typically consider reference documentation. I'd expect to see it written with an intended audience of a casual user with examples and an organization that would be helpful for this reader (e.g.: purpose, description, examples, details) ## Tests The tests look reasonable and comprehensive although there seems to be some `#if 0` conditions that could either be cruft or perhaps the intent is the developer would manually change those to verify compilation failure. The tests are using the 'catch' library which is intended to be a submodule. Is there a precedence for using a third party library like this? For folks using Boost it could be painful to get another dependency approved to run all the Boost tests. It would be preferable IMO to use Boost.Test or something self contained. ## Usefulness I attempted to use the library with g++ 8.3.0 and clang 8.0.0. My example code is below: ```C++ #include <boost/out_ptr.hpp> #include <sqlite3.h> #include <iostream> int main() { std::shared_ptr<sqlite3> database; if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database, sqlite3_close))) { std::cout << "Problem opening the file"; } using Sqlite3Ptr = std::unique_ptr<sqlite3, decltype(&sqlite3_close)>; Sqlite3Ptr database2(nullptr, &sqlite3_close); if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database2, sqlite3_close))) { std::cout << "Problem opening the file"; } } ``` With this `Makefile` ```c++ main : main.cpp g++ -I/home/dsankel/code/out_ptr/include -o $@ $< `pkg-config sqlite3 --cflags --libs` .PHONY: clean clean: $(RM) main ``` I didn't run into any issues. Everything worked okay. I think this library would be handy for wrapping C libraries like sqlite. # How much effort did you put into your evaluation of the review? I spent a few hours on this review. I read through all the documentation, did a cursory review of the code, and came up with the example above. # Minor things * Copyright notices need to have a person's real name to have legal benefits. * In `aout_ptr.adoc` the examples link goes to the overview page. * Some grammar errors in the "C function calls are indeterminately sequenced..." paragraph. * When referring to a Boost library in free flowing text, the correct form is Boost.LibraryName with the same font as the surrounding text.

5 5

out_ptr review is extended until Wednesday, July 10
by Zach Laine 29 Jun '19

29 Jun '19

We don't have enough reviews yet, so we're extending the review by two weeks. Please review this small and useful library! >From the original announcement: The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th and ends on Wednesday, June 26th. out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks ( https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc) and the Standard C++ proposal for more details). Online docs can be found here: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc The GitHub repository is available here: https://github.com/ThePhD/out_ptr Also, there is an associated standards proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/ThePhD/out_ptr/issues. Zach

5 7

[accumulators] Offer to help with maintenance
by Cromwell Enage 29 Jun '19

29 Jun '19

Hi, everyone! I'm offering to help maintain Boost.Accumulators and have already e-mailed Eric Niebler regarding my intentions. With the deadline for Boost release 1.71 fast approaching, I can take steps to ensure that Boost.Accumulators is in a usable state. I also have a few ideas on how to update and improve Boost.Accumulators (one of them being to make use of variadic templates), but they can wait until after the release for further discussion. Very respectfully, Cromwell D. Enage

1 0

Re: [boost] [logic] Boost::logic (tribool?) actively developed?
by Jacob Lidman 28 Jun '19

28 Jun '19

> It has resently updated to support a change in gcc compilers. So I > would say it's actively maintained. I never asked if it was actively maintained but rather if the library is actively developed, i.e. are new features added, improvements in documentation... > I would say it seems stagnant because it's always been as close to perfection as a > library can be. The reason why the library appear close to perfect is because it clearly has minimal number of features. Improvements can be made to accommodate new needs, e.g. by including other logics. > see https://github.com/boostorg/logic As I mentioned this is the repo for the tribool library, at least that was the name prior to boost 1.70.0

2 1

Some out_ptr concerns
by Glen Fernandes 28 Jun '19

28 Jun '19

Thanks to JeanHeyd for going through the Boost review process, and to Zach for managing the review. Briefly: I do not have enough reasons to recommend acceptance for out_ptr just yet --- in its current form. (I'd like to see it return for a new review when the feedback from this review shapes the design so that some of these concerns are resolved). Second: This excludes "inout_ptr" (for which I had even more concerns) and just focusing on "out_ptr" - which is the simpler and more common use case of the two. Below comparing out_ptr vs the hand written code that a user would write to use a /typical/ C out-pointer API with smart pointers, this is what I'm comparing: [Typical code user would write]: Type* raw; Result result = TheCApi(args..., &raw); if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Smart<Type, Deleter> smart(raw, etc...); [What happens with out_ptr now]: /* 'smart' already has to exist here before TheCApi is called. Either as Smart<Type, Deleter> smart; or Smart<Type, Deleter> smart(nullptr, etc...); depending on deleter */ /* User writes: Result result = TheCApi(args..., out_ptr(smart)); // or Result result = TheCApi(args..., out_ptr(smart, etc...)); depending on deleter */ Type* raw = nullptr; Result result = TheCApi(args..., &raw); if (raw != nullptr) { smart.reset(raw); // or smart.reset(raw, etc...); depending on deleter } if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Concern 1. Having to materialize the smart pointer before TheCApi is called. Ordinarily this might be fine for some smart pointers and stateful deleters, but it may not be for others. Concern 2. The original user code initializes the smart pointer based on Success(result). The out_ptr version would do so based on whether the raw out pointer was changed to something non-null by TheCApi. This might be fine for some cases, but it may not be for others. That it isn't the same as fundamental logic as the user code bothers me, though. Concern 3. The equivalent of the hand written user code is less overhead. Personally I'm of the opinion that maybe this doesn't matter too, but here the author does say he has users who cannot abide by it, and that this facility needs support from e.g. std::unique_ptr to be viable. (And this leads to concern 4 below). [I'm not a fan of needing unique_ptr implementations to add support for this to make it comparable to some user's hand written code]. Concern 4. The UB optimization that the author wrote because of Concern 3 is a real concern to him. The UB optimization has no place in Boost, and one of which doesn't even work with many C++ library vendors' unique_ptr. [Fortunately the Boost reviews have already echoed this sentiment and I believe this is going away]. Concern 5. Supporting other custom smart pointers requires effectively re-implementing out_ptr_t by specialization. I have come to see this as not viable. [Already mentioned in other reviews] Concern 6. C APIs where the deleter (its state, logic, etc.) are governed by some other result from TheCApi. This is can be worked around in many cases, but the workaround is clumsy. Or insupportable, in other cases. i.e. The stateful deleter is always initialized with 'etc...' either before-hand via Smart<Type> smart(nullptr, etc...) or at call site with: TheCApi(args, out_ptr(etc...)); before analyzing other results of calling TheCApi. (The 7th concern I had made notes about pre-review has already been eliminated, when the unconditionally noexcept destructor is now only conditionally noexcept). Other thoughts: The suggestion by Emil lead to an interesting alternative idea to this problem domain, but I had no time to fully explore it. I don't think it would address all of these concerns. It has some other greater appeal, e.g. a way to call C APIs that materializes the smart pointers as results (along with C API return value) of an "Invoke-style" thing. Or even a way to transform a C API with out-pointers into a C++ callable that returns smart pointers (along with C API return value) via a "Bind-style" thing. Glen

1 0

out_ptr -- alternatives
by Andrzej Krzemienski 28 Jun '19

28 Jun '19

Hi Everyone, This is not a review of out_ptr, but I wanted to share my thoughts about the motivation for this library. I do not recall any time from my programming experience where I was in need of passing a smart pointer to a T** interface, so maybe this is why I cannot appreciate the value of out_ptr. On the other hand, if I need to use a library with a C API, or other non-C++ API (this happens when someone wants to naively port a Java library to C++ and keep the Java interface) the first thing I do is to wrap the API functions into a RAII class. It takes some time up front, but then whenever it is used, I do not have to deal with the problems of the old API. `T**` is only one of the problems. The motivation focuses on only easily passing smart pointers to `init(T**)` functions, but it does not address the problem of adapting the error reporting of `init(T**)`to the error reporting of my program. I would never want to only solve the former problem and omit the latter. Also, I would never want to represent a handle to a resource with a smart pointer, as I do not want to voluntarily inject the null-pointer state that I now have to take care of everywhere. Instead I would prefer a dedicated type that is not default-constructible, where one really needs to try hard to get the special no-resource state (e.g. by moving from and not destroying the object). What I am missing from the motivation of out_ptr is the comparison with a full RAII wrapper solution. You can argue that the scope of out_ptr is just different: provide interpoperation between `init(T**)`functions and smart pointers. But I would argue that this latter goal is wrong. In fact, I am concerned that we might be encouraging a bad programming style: "need to work with init(T**) APIs? use shared_ptr." instead of promoting RAII wrappers that directly wrap the resource. Does anyone else feel the same? Or am I missing something about the problem domain? Anyway, I think that this problem should be covered in the documentation. Regards, &rzej;

6 8

[logic] Boost::logic (tribool?) actively developed?
by Jacob Lidman 27 Jun '19

27 Jun '19

Hi, Is boost::logic actively developed and if so what are the future plans for the library? >From the source/documentation it seems to be dormant since ~2004 and a renaming of the tribool package. The latter is listed as a library on the boost homepage but lack a library repo on github.com/boostorg (?). BR /Jacob

2 1

ASIO TCP connection switch
by JH 27 Jun '19

27 Jun '19

Hi, I have an application using ASIO TCP/IP SSL socket connection in an embedded device, the device has two network interfaces, when one is down, another network interface takes over, which requires application TCP SSL socket connection to be established binding to a new network interface. What will be an appropriate implementation to switch application TCP connection from one to another interface? Option 1: Restart application Option 2: Terminate the old interface socket, create a new socket to start initial connection Option 3: Some reconnection method which I don't know Appreciate you advice. Thank you. Kind regards, - jupiter

3 4

Can boost ASIO socket binding to any interfaces or support QUIC?
by JH 27 Jun '19

27 Jun '19

Hi, I posted a similar question in another email but title was not appropriate, let me try it here using a more accurate clear title. I might need separate it into email questions, I am not quite clear it is boost socket nature or it is NAT issue. I have both client server applications using boost asio TCP socket, the client application is a Linux embedded system IoT device installed in home connect to server via NAT, the embedded system has two network interfaces, WiFi and cellular, in anytime there is only one network interface is up ans signed by an IP address, when one interface is down, another interface is up and signed IP address. The problem for an existing TCP socket connection is it cannot change from one interface to another. When one interface down another interface takes over, the client application continual sends data to the down interface buffered in TCP queue without transmission error but the server would never receive the data. It seems the only solution is to use QUIC, hence I asked here if there is any boost functions to support QUIC I can replace the TCP socket by QUIC. Appreciate your advice and tips. Thank you. Kind regards, - jupiter

1 0

[build] Build errors with gcc - bad argument -mcpu=v7
by Andrey Semashev 26 Jun '19

26 Jun '19

Hi, I'm trying to run tests for Boost.Core with the following command: bjam -j 8 toolset=gcc cxxstd=14 variant=release libs/core/test Compilation fails with the following errors: gcc.compile.c++ bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead cc1plus: error: bad value (‘v7’) for ‘-mtune=’ switch cc1plus: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server bonnell atom silvermont slm knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2 generic native "g++" -std=c++14 -fvisibility-inlines-hidden -fPIC -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -mcpu=v7 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o" "libs/core/test/lightweight_test_fail10.cpp" ...failed gcc.compile.c++ bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o... I'm not sure where that -mcpu=v7 comes from, but I don't have it in my options, nether do I see it in the Jamfile.

2 2

[release] 1.71.0 closed for new libraries and breaking changes
by Michael Caisse 26 Jun '19

26 Jun '19

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_71_0.q…> Thanks, -- The Boost Release Team

1 0

Boost 1.54 build integration errors in VS2017
by nunna, sarath babu (GE Healthcare) 26 Jun '19

26 Jun '19

HI, I am getting below error when I tried to integrate boost 1.54 version into our project using VS2017. error C3861: 'assert_arg': identifier not found error C2039: 'assert_arg': is not a member of 'boost::mpl' I am not able to fix this error. Hence, Please provide me help to get rid of this error. Thanks, Sarath.

2 1

IP TCP connections asio::ip::tcp::socket
by JH 25 Jun '19

25 Jun '19

Hi, I am running an application using boost ASIO IP/TCP socket to connect Internet. I have two network interfaces, when one is down, it switches to another one, in my application

1 0

[boost-ci] Added support for building big-endian on Travis CI
by James E. King III 24 Jun '19

24 Jun '19

You can now run a big-endian build job on Travis CI through some docker magic. I had an endian bug in some relatively new code in Boost.UUID (in the MD5 hasher) that required a big endian environment to build in and test with, so I had to solve this impediment. The Boost Docker Development Environment (BDDE) was taught how to build and run multiarch images. At this point I'd like to consider having BDDE move into boostorg alongside boost-ci. It provides an easy way to hop into or run boost builds inside docker containers. One of the examples is to run a predef unit test in the arm64 or ppc64 containers and see how predef defines the macros. Following that, Boost-CI was taught how to use BDDE under Travis CI to run a build in one of the containers. When running the red-ppc64 image expect a slowdown in the 10x to 20x range. If you are concerned about build time on Travis CI (maximum length 50 minutes), I would recommend running a subset of tests. Even building b2 (bootstrap) takes more than a minute. Building Boost.UUID with tests takes about 25 minutes (this includes building some of Boost.Serialization). You can also use BDDE directly to build the same way on a docker-enabled development system. I wasn't able to run gdb in this environment when the architecture was ppc64, but I could build and run tests. gdb works on the x86_64 docker container. Boost-CI: https://github.com/boostorg/boost-ci BDDE: https://github.com/jeking3/bdde Example PR that enables it on Travis CI: https://github.com/boostorg/uuid/pull/109 Enjoy, - Jim

1 0

Serialization Issue found in 1.69 and 1.70 of boost libraries
by nunna, sarath babu (GE Healthcare) 24 Jun '19

24 Jun '19

Hello, We use boost libraries in our project. We had no issues found in 1.47 version in our product.(In Windows 7) But we wanted to upgrade to latest version into Windows 10 environment. We have got issues with serialization. Please let us know in which version you have introduced serialization above than 1.47 version? So that we will take one version below than that or let us know whether have to include/modify anything to adopt latest 1.69 or 1.7 version of boost. Your response will be a great help to us. Thanks, Sarath.

2 1

[build] Option to have b2 show stdout from target run?
by James E. King III 24 Jun '19

24 Jun '19

Currently b2 only shows output when a test fails unexpectedly. If I want to build and run a test and see the stdout from the test all in one command, is there a b2 option that would do that? For example, the output from predef's "info_as_cpp" test is useful, and I'd like to have a single command line that builds it, runs it, and shows stdout. I don't see a way to do this with b2, even with the -d+n flags. I can do it this way, but it's fragile: $(b2 -a -ox info_as_cpp | grep 'gcc.link' | cut -d' ' -f2) - Jim

3 2

B2 release 4.0.0
by Rene Rivera 24 Jun '19

24 Jun '19

After even more years of development the landscape of build systems has changed considerably, and so has the landscape of compilers. This version marks the start of B2 transitioning to a C++ implementation. Initially this means that the engine will be compiled as C++ source but that source is still the base C implementation. Over time it will transform to a C++ code base in both the engine and build system. Some changes in this start: - Requires C++ 11 to build engine. - Simplified build scripts to make it easier to maintain. - Building with C++ optimizations gives an immediate performance improvement. *Other changes in this release:* - Add support for using prebuilt OpenSSL. -- *Damian Jarek* - Define the riscv architecture feature. -- *Andreas Schwab* - Add ARM64 as a valid architecture for MSVC. -- *Marc Sweetgall* - Set coverage flags, from coverage feature, for gcc and clang. -- *Damian Jarek* - Add s390x CPU and support in gcc/clang. -- *Neale Ferguson* - Support importing pkg-config packages. -- *Dmitry Arkhipov* - Support for leak sanitizer. -- *Damian Jarek* - Fix missing /manifest option in clang-win to fix admin elevation for exes - with "update" in the name. -- *Peter Dimov* - Add freertos to os feature. -- *tee3* - Default parallel jobs (-jX) to the available CPU threads. -- *Rene Rivera* - Simpler coverage feature. -- *Hans Dembinski* - Better stacks for sanitizers. -- *James E. King III* *WARNING*: The default number of parallel jobs has changed in this release from "1" to the number of cores. There are circumstances when that default can be larger than the allocated cpu resources, for instance in some virtualized container installs. *Continuously tested on:* - Linux Clang 3.5, 3.6, 3.7, 3.8, 3.9, 4, 5, 6, 7, 8 - Linux GCC 4.7, 4.8, 4.9, 5, 6, 7, 8, 9 - macOS Xcode 8.3.3, 9.0, 9.0.1, 9.1, 9.2, 9.3, 9.3.1, 9.4, 9.4.1, 10.0, 10.1, 10.2, 10.2.1 - Windows MinGW 8.1.0 - Windows VS 2013, 2015, 2017, 2019 Documentation and more at <https://boostorg.github.io/build/> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 2

Re: [boost] [Boost-testing] Test Failures on develop
by Tom Kent 24 Jun '19

24 Jun '19

On Fri, Jun 21, 2019 at 5:11 AM Tom Kent <lists(a)teeks99.com> wrote: > > > On Thu, Jun 20, 2019, 10:35 PM Rene Rivera <grafikrobot(a)gmail.com> wrote: > >> On Thu, Jun 20, 2019 at 10:28 PM Tom Kent <lists(a)teeks99.com> wrote: >> >>> >>> On Thu, Jun 20, 2019 at 7:15 AM Rene Rivera <grafikrobot(a)gmail.com> >>> wrote: >>> >>>> Since it's not due to the b2 -j change.. >>>> >>>> On Fri, Jun 14, 2019 at 8:25 AM Tom Kent via Boost-Testing < >>>> boost-testing(a)lists.boost.org> wrote: >>>> >>>>> For the last few days (Since June 4?) I've been having problems with >>>>> all my linux tests running against the develop branch. >>>>> >>>>> GCC ends with this: >>>>> >>>>> gcc.compile.c++ ../../bin/common/build/gcc-8/release/process_jam_log.o >>>>> >>>>> "g++-8" -fPIC -O3 -finline-functions -Wno-inline -Wall >>>>> -DBOOST_ALL_NO_LIB=1 -DNDEBUG -D_CRT_SECURE_NO_WARNINGS - >>>>> I"/var/boost/run/boost_root" -c -o >>>>> "../../bin/common/build/gcc-8/release/process_jam_log.o" >>>>> "../../common/build/../src/p >>>>> rocess_jam_log.cpp" >>>>> >>>>> ../../common/build/../src/process_jam_log.cpp: In function >>>>> 'std::__cxx11::string {anonymous}::revision(const string&)': >>>>> ../../common/build/../src/process_jam_log.cpp:359:16: warning: >>>>> ignoring return value of 'int system(const char*)', decla >>>>> red with attribute warn_unused_result [-Wunused-result] >>>>> std::system("git rev-parse --short=6 HEAD >.short-sha"); >>>>> ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> ...skipped <p../../bin/testing/build/gcc-8/release>process_jam_log for >>>>> lack of <p/var/boost/run/boost_root/bin.v2/libs/f >>>>> ilesystem/build/gcc-8/release/link-static/visibility-hidden>libboost_filesystem.a... >>>>> >>>>> >>>> >>>> I guess you'd need to find out what it says for trying to build >>>> filesystem lib. >>>> >>> >>> Here's what I'm seeing with the filesystem error: >>> >>> ln -f -s >>> "../../libs/detail/include/boost/detail/has_default_constructor.hpp" >>> "../../../boost_root/boost/detail/has_ >>> default_constructor.hpp" >>> >>> gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o >>> >>> "g++-8" -fvisibility-inlines-hidden -m64 -O3 -finline-functions >>> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL >>> _NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG >>> -I"/var/boost/run/boost_root" -c -o "/var/boost/run/boost_root/bin. >>> v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o" >>> "/var/boost/run/boost_root/libs/file >>> system/src/path_traits.cpp" >>> >>> /var/boost/run/boost_root/libs/filesystem/src/path_traits.cpp:20:10: >>> fatal error: boost/filesystem/config.hpp: No such f >>> ile or directory >>> #include <boost/filesystem/config.hpp> >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> compilation terminated. >>> ...failed gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o... >>> gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o >>> >>> "g++-8" -fvisibility-inlines-hidden -m64 -O3 -finline-functions >>> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL >>> _NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG >>> -I"/var/boost/run/boost_root" -c -o "/var/boost/run/boost_root/bin. >>> v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o" >>> "/var/boost/run/boost_root/libs/file >>> system/src/portability.cpp" >>> >>> /var/boost/run/boost_root/libs/filesystem/src/portability.cpp:20:10: >>> fatal error: boost/filesystem/config.hpp: No such f >>> ile or directory >>> #include <boost/filesystem/config.hpp> >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> compilation terminated. >>> ...failed gcc.compile.c++ >>> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o... >>> >>> >>> And several more like that. >>> >>> However, I'm also suspicious of the timing with the processor change. >>> >>> Looking back at the last successful builds of develop on linux. I have a >>> few from linux/x86_64/docker machines. The last one I saw was building with >>> gcc-8 on June 4 around 6:30am CDT. There should have been a successful >>> clang run about 5hrs after that (11:30am CDT), and another successful gcc >>> around 10hrs after the last one that was actually successful (4:30pm CDT). >>> >>> This seems like it would correspond to the change to build here: >>> >>> https://github.com/boostorg/build/commit/451059949d92b52b21f802562a50587f1e… >>> >>> The other failure I started seeing was only my linux/arm64 machine. This >>> doesn't run docker, so might not be affected in the same way. The last >>> successful run on there was at 4:50pm CDT on June 4...but it typically >>> takes around 9hrs to run so it probably got the pre 451059949 commit. >>> However here I can't rule out that it was impacted by a8ab76ef973. >>> >>> I'm going to try to standup some normal VMs soon and run on them to see >>> if they are affected in the same way. It would also be nice if we could try >>> backing out the usage of _SC_NPROCESSORS_ONLN and see if that fixes things, >>> is that feasible to try for a couple days? >>> >> >> Again.. It's not a b2 issue. Specifying the "-jX" option entirely >> obviates the changed code. It's almost certainly something else. Places to >> look would be in the filesystem lib, or the root "boost" project for >> changes. >> > > Looking at regression.py it looks like the command that builds > process_jam_log doesn't use the bjam options. Can you verify if this > is/isn't the case? > > Tom > Somewhere between 9:57am and 12:02pm CDT today this bug migrated to master. It can trivially be re-produced. On a bare linux vm...Azure F8s_v2, Ubuntu 18.04, standard SSD. $ sudo apt update && sudo apt install build-essential gcc-8 g++-8 python python3 git wget ... $ wget https://raw.githubusercontent.com/boostorg/regression/develop/testing/src/r… $ echo using gcc : 8 : g++-8 : \; > ~/user-config.jam $ python run.py --runner=teeks99-test01 --toolsets=gcc-8 --tag=develop --bjam-options="-j8 address-model=64" ...fails with the above errors. You can also do the same thing to reproduce in a docker image (ubuntu:bionic). --bjam-options of -j1 -j8 and absent all fail the same. This does not correspond to any changes between the filesystem library that indicates the error. But it *does* correspond exactly with the release of the new B2. https://github.com/boostorg/build/commit/04efaac148671479b514db882b1c520dca… There have been no successful regression tests by any linux runners since that time. Tom

2 2

Release tags request..
by Rene Rivera 24 Jun '19

24 Jun '19

B2 is doing it's own "out of band" (aka independent) releases. In order to avoid confusion.. Can the Boost release process please avoid tagging the build subrepo with the Boost release tags from now on? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

4 8

[boost-users] [compiler] Boost VC++ 14.2 test compiler
by Alex J 23 Jun '19

23 Jun '19

Hi, Does anybody know when VC++ 14.2 will be added as a 'primary compiler tested' ?. At the moment there is only VC++ 14.1. Thanks

1 0

Travis CI again.
by John Maddock 23 Jun '19

23 Jun '19

Sorry, but I need help, and simply can not see what's going wrong with: https://github.com/boostorg/config/pull/286. Travis doesn't even seem to be building the same code as has been pushed? And until I can get CI functioning again here, and in other libraries, nothing gets merged to master :( Sorry if I'm being dense, and thanks in advance, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 4

[release] 1.71.0 deadline for new libraries approaching
by Michael Caisse 22 Jun '19

22 Jun '19

One week from today master will closed for new libraries and breaking changes. Thanks, -- The Boost Release Team Boost Calendar with the release schedule: <http://www.boost.org/development/index.html>

3 4

[process][type_erasure] Including both process and type_erasure creates duplicate definitions in mp11 and fusion
by Jared McIntyre 21 Jun '19

21 Jun '19

I've found that type_erasure::any and process::child conflict with each other in how they use mp11 and fusion. The issue may be specific to compiling the process library on Windows as it occurs in calls through detail headers in the library that are specific to Windows, and I haven't tested on other platforms.. #include <boost/type_erasure/any.hpp> #include <boost/process/child.hpp> Order doesn't matter. 1>c:\<removed>\boost\boost\fusion\adapted\std_tuple\tag_of.hpp(38): error C2953: 'boost::mpl::sequence_tag<std::tuple<_Types...>>': class template has already been defined 1>c:\<removed>\boost\boost\mp11\mpl.hpp(155): note: see declaration of 'boost::mpl::sequence_tag<std::tuple<_Types...>>' Boost 1.67, 1.70 VS 2017 (5.9.12)

1 0

[boost-developers] [MSVC142] When is boost going to add MSVC 14.2 as a test compiler
by Alex J 21 Jun '19

21 Jun '19

Hi, I can see that boost has updated their code to support MSVC14.2 builds. However according to latest 1.70 docs, they are not testing on 14.2 compiler. When can we expect boost to include 14.2 as one of their primary test compilers ? Thanks Alex

2 1

Re: [boost] [release] 1.71.0 deadline for new libraries approaching
by Kenneth Porter 20 Jun '19

20 Jun '19

Can we get this fix into the crc library? It fixes a warning in MSVC compilers. <https://github.com/boostorg/crc/pull/2>

1 0

CMake config scripts broken in 1.70
by Alexander Grund 19 Jun '19

19 Jun '19

Hi all, I discovered a severe logic flaw in the generated CMake Config files for the new Boost 1.70 which make them almost unusable. As an example the static variant contains: if(NOT"${Boost_USE_STATIC_LIBS}"STREQUAL""ANDNOTBoost_USE_STATIC_LIBS) _BOOST_SKIPPED("libboost_filesystem.a""static, Boost_USE_STATIC_LIBS=${Boost_USE_STATIC_LIBS}") return() endif() if(BUILD_SHARED_LIBS) _BOOST_SKIPPED("libboost_filesystem.a""static, BUILD_SHARED_LIBS=${BUILD_SHARED_LIBS}, set Boost_USE_STATIC_LIBS=ON to override") return() endif() The shared variant contains: if(NOT"${Boost_USE_STATIC_LIBS}"STREQUAL""ANDBoost_USE_STATIC_LIBS) _BOOST_SKIPPED("libboost_filesystem.so.1.70.0""shared, Boost_USE_STATIC_LIBS=${Boost_USE_STATIC_LIBS}") return() endif() if(NOTBUILD_SHARED_LIBS) _BOOST_SKIPPED("libboost_filesystem.so.1.70.0""shared, BUILD_SHARED_LIBS not ON, set Boost_USE_STATIC_LIBS=OFF to override") return() endif() Although the message text says otherwise the 2nd return in both cases depends solely on BUILD_SHARED_LIBS. I'm pretty sure the intention was too check for BUILD_SHARED_LIBS *only* if Boost_USE_STATIC_LIBS is not set (see thread https://lists.boost.org/Archives/boost/2019/02/245030.php) As can be seen this is not the case. I haven't found the repo which contains the code that generates this so I can't report it there or fix it myself. As the issue here makes using Boost 1.70 (almost) impossible (in Scenarios like BUILD_SHARED_LIBS=ON (a CMake variable influencing the project build) and Boost_USE_STATIC_LIBS=ON) I'd recommend fixing this and pushing out a bugfix release. Regards, Alexander Grund

2 4

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 19 Jun '19

19 Jun '19

> > >>> 2) How can I test proper support for std::current_exception() and > >>> std::rethrow_exception() if exceptions are disabled for the test? > >> > >> You should probably condition your test on BOOST_NO_EXCEPTIONS and make > >> the test no-op when exceptions are disabled. > > > > But that defeats the whole purpose of having tests. > > Not really. You would still test the facilities when exceptions are > enabled. OTOH, I don't see why would anyone care about these components > when exceptions are disabled. > > If the Jamfile disables exceptions for the library tests, then I think I need to care. Otherwise this config macro would be untested. > > I think I should at least use the type std::exception_ptr, and make sure > > the functions std::current_exception() and std::rethrow_exception() exist > > (even if I cannot test that they actually work as expected at runtime). > > > > I think the following should work, and at least the test tests something > > when exceptions are off: > > > > using std::exception_ptr; > > auto current = &std::current_exception; > > auto rethrow = &std::rethrow_exception; > > > > What do you think? > > If it works, that would be fine by me. I don't disable exceptions and I > don't know whether the standard library components related to exceptions > stay available when exceptions are disabled. I wouldn't be surprised if > they don't (now or in a future version of the standard library > implementation). In any case, as I said, I don't see anyone using these > components when exceptions are disabled, so not much point in testing. > > In the end I settled for using std::exception_ptr; using std::current_exception; using std::rethrow_exception; because some old version of clang had issues with auto, sigh... The problem now is that something else is broken in the CI tests, but I'm quite confident that the tests should pass in all of msvc, gcc, clang I'd like to ask for the PR #285 to be merged into develop please ( https://github.com/boostorg/config/pull/285) Thanks!

1 0

Ticket #9804 - polygon intersection
by Michael Knafo MTH 19 Jun '19

19 Jun '19

Hello ! I have encountered the same problem described in bug #9804: "The result of an intersection is sometimes equal to one of the input polygons, when the result should be empty". https://svn.boost.org/trac10/ticket/9804 Does anyone knows if this bug was fixed and in which boost version ? Is there any version release notes related to this bug ? Alternatively, does anybody know what cause this problem ? Thanks Michael *********************************************************************************************** Please consider the environment before printing this email ! The information contained in this communication is proprietary to Israel Aerospace Industries Ltd. and/or third parties, may contain confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this communication in error, please notify the sender immediately and delete it from your computer. Thank you. Visit us at: www.iai.co.il

2 2

Proposed for inclusion in boost: a C++11 span
by Hans Dembinski 17 Jun '19

17 Jun '19

Dear all, I started to work on a C++11 implementation of std::span. The interface will be an exact mirror of std::span, https://en.cppreference.com/w/cpp/container/span. Having a drop-in replacement of std::span for systems with older compilers in Boost seems like a very good idea. Is anyone else already working on this? I am happy to join forces. Coding down the span took me an hour, but several more hours will go into unit testing and documenting. Best regards, Hans

3 4

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 17 Jun '19

17 Jun '19

> > > > > However, in my test I throw and catch exceptions: > > But the CI jobs have gcc and clang configured to compile without > exception > > support! > I have two questions: > > > > 1) Where are exceptions disabled in the CI jobs? I can't find it in > > the .travis.yml, > > but I can see e.g. clang being invoked with -fno-exceptions > > It's in the test/Jamfile.v2 file, look for <exception-handling>off. > Thanks! > > > 2) How can I test proper support for std::current_exception() and > > std::rethrow_exception() if exceptions are disabled for the test? > > You should probably condition your test on BOOST_NO_EXCEPTIONS and make > the test no-op when exceptions are disabled. > But that defeats the whole purpose of having tests. I think I should at least use the type std::exception_ptr, and make sure the functions std::current_exception() and std::rethrow_exception() exist (even if I cannot test that they actually work as expected at runtime). I think the following should work, and at least the test tests something when exceptions are off: using std::exception_ptr; auto current = &std::current_exception; auto rethrow = &std::rethrow_exception; What do you think?

2 1

CI: clang installation broken in current Travis build images
by John Maddock 17 Jun '19

17 Jun '19

Currently, pretty much all attempts at installing clang on the travis build images is failing: https://travis-ci.org/boostorg/config/builds/546084433?utm_source=github_st…. And since all the boost libraries have pretty much copied each others .travis.yml files, this means that most PR's for most libraries will be failing. Anyone any ideas? Thanks, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

[boostrap.bat] compilation error
by Raffi Enficiaud 16 Jun '19

16 Jun '19

I have the following during the compilation of bootsrap/b2: d:\bamboo_build_dir\rs-bcb233-vc2008win\library\tools\build\src\engine\sysinfo.h(41) : error C2864: 'b2::system_info::cpu_core_count_' : only static const integral data members can be initialized within a class d:\bamboo_build_dir\rs-bcb233-vc2008win\library\tools\build\src\engine\sysinfo.h(42) : error C2864: 'b2::system_info::cpu_thread_count_' : only static const integral data members can be initialized within a class Current develop (yesterday), Raffi

2 1

[Range] pr for bug in any_range / development/maintenance status
by Max Jendruk 14 Jun '19

14 Jun '19

Hello everyone, I submitted a bugfix on Github about a month ago that fixes an issue where passing a (non-reference) value type as Reference parameter to any_range could lead to undefined behaviour. The issue has been known for a while (5 years). I would like to know when I can expect this to be merged. Also, is there a general review cycle that I'm not aware of? There are still a couple of other pull requests open, some of which were opened over a year ago. Just by looking at the activity on Github, it's difficult to determined how actively Boost.Range is still being maintained. What is the development/maintenance status of the library? I'm wondering whether it would be worth the time implementing a few more adaptors similar to those in the C++20 standard like take_view, join_view, and all_view, which I'd be happy to do. Are additions to the library still being accepted at this point? Best regards, Max

3 2

[regression tests] Regression test pages not updating since June 4th
by Joaquin M López Muñoz 11 Jun '19

11 Jun '19

Thank you, Joaquín M López Muñoz

1 0

[out_ptr] Review scheduled for June 16 to June 26
by Zach Laine 10 Jun '19

10 Jun '19

This is a heads-up that out_ptr has been scheduled for review, starting next Sunday, June 16. From JenHeyd's earlier post about the library: " Documentation: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc Repository: https://github.com/ThePhD/out_ptr <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc> Standards Proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html boost.out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks ( https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc) and the Standard C++ proposal for more details). " Please consider checking out the library now, and doing a review next week. It's a pretty small library; reviews should be pretty quick to do. Zach

1 0

Re: [boost] [Boost.Stringify] Yet another formatting library.
by Roberto Hinz 09 Jun '19

09 Jun '19

On Sat, Jun 8, 2019 at 9:53 AM Helmut Zeisel <HZ2012(a)gmx.at> wrote: > Actually I did not check your library, but I would be interested in a > formatting library that is not based on functions, but on function objects. > > The usage would not be something like > > std::string s1 = to_string("base10", 15); > std::string s2 = to_string("base16", 42); > > but > > stringifier dec; > dec.set_base(10); > std::string s1=hex(15); > stringifier hex; > hex.set_base(16); > std::string s2=hex(42); > > To format values in Boost.Stringify, one does like this, for example: namespace strf = boost::stringify; int v = 255; std::string s = strf::to_string(v, " in hexadecimal is ", strf::hex(v)); assert(s == "255 in hexadecimal is ff"); So could maybe lambdas solve your need ? auto hex = [](int v){return strf::to_string(strf::hex(v)); }; auto dec = [](int v){return strf::to_string(v); }; auto s1 = hex(15); auto s2 = dec(42); assert(s1 == "f"); assert(s2 == "42"); > With a function object based interface, one could easily store and reuse > different formating options in parallel. > Not clear to me what you mean by that. Could you explain better ?

2 2

[Boost.Stringify] Yet another formatting library.
by Roberto Hinz 08 Jun '19

08 Jun '19

Dear Boost Community, Naturally, any interest in a new formatting library must be lower now that fmtlib is approved into C++20. Still, I'm confident that the library I'm working on has great potential, so I would like to know your opinions. https://github.com/robhz786/stringify This is a locale-independent formatting library that: - has great performance ( almost twice as fast as fmtlib ) - can do things that others can't, like encoding conversion. - is highly customizable. Through "facets" you can specify things like numeric punctuation, encoding error handling, and the width calculation algorithm. - is highly extensible. Not only you can add new input types with own formatting options and facets, but also easily add new output types. The doc has an example of how to extend the library to write to QString ( from Qt ). Actually, I did announce this library about two years ago. But the design is much enhanced now. I believe it will be ready for review by the end of this year. But it may take longer. I much appreciate any feedback. Thank you. Roberto

2 2

Setting up linter for boost library development
by Sagnik Dey 07 Jun '19

07 Jun '19

If someone has a linter setup with appropriate settings, can you please share details? I'm working on Boost.Real and would like to have a linter to help with coding style consistency. Help is appreciated. Thank You

2 1

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 06 Jun '19

06 Jun '19

> > >Are there instructions for developers that I've missed? > > There are some instructions here: > > > https://www.boost.org/doc/libs/1_70_0/libs/config/doc/html/boost_config/gui… > > Thanks! I was expecting developer guidelines in the github readme, not in the actual library docs! doh! I have made a PR #285 and after some trial and error (I only have VS2015 and VS2017 available to test locally) I think I have something. However, in my test I throw and catch exceptions: int test() { std::exception_ptr ep; try { throw 42; } catch(...) { ep = std::current_exception(); } try { std::rethrow_exception(ep); } catch(int i) { // return zero on success return i == 42 ? 0 : 1; } return 1; } But the CI jobs have gcc and clang configured to compile without exception support! And I get errors like: libs/config/test/boost_no_cxx11_hdr_exception.ipp:22:5: error: cannot use 'throw' with exceptions disabled throw 42; ^ libs/config/test/boost_no_cxx11_hdr_exception.ipp:20:3: error: cannot use 'try' with exceptions disabled try ^ I have two questions: 1) Where are exceptions disabled in the CI jobs? I can't find it in the .travis.yml, but I can see e.g. clang being invoked with -fno-exceptions 2) How can I test proper support for std::current_exception() and std::rethrow_exception() if exceptions are disabled for the test? Thanks!

2 1

[ boost.out_ptr ] [ Review Endorsement ] New Library targeting C++11
by JeanHeyd Meneide 04 Jun '19

04 Jun '19

Dear Boost Community, After a lot of work and discussion in-person, via e-mail, and on the Slack, I would like to ask for the library boost.out_ptr <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc> -- targeting C++11 -- to be endorsed for review. Documentation: ascii doc-ready and readable on GitHub <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc> Repository: GitHub <https://github.com/ThePhD/out_ptr> Standards Proposal: p1132 <https://thephd.github.io/vendor/future_cxx/papers/d1132.html> (accepted for and targeting C++20) boost.out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt-into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc> and the Standard C++ proposal <https://thephd.github.io/vendor/future_cxx/papers/d1132.html#perf> for more details). Many thanks to the in-person discussion during Library in a Week at C++Now, which helped shape the implementation and yield the final Rationale <https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/rationale.adoc>. Many thanks to Ezra (eracpp) for a lot of the quick, easy-to-read examples that became part of the documentation. Sincerely, JeanHeyd Meneide

11 19

Re: [boost] [Boost.Config] Detect compiler support for std::current_exception
by dariomt＠gmail.com 03 Jun '19

03 Jun '19

> > >>> Hi all, > >>> > >>> I'm working on a Boost.Exception issue [1] and I need to detect > compiler > >>> support of std::current_exception. In the issue there is a suggestion > to > >>> use #if __cplusplus > 199711L but that does not work for my use case > >>> (VS2015 reports __cplusplus = 199711L). > >> > >> MSVC defines _MSVC_LANG for this[1]. At least, it used to. However, it > >> would be cleaner to have a dedicated macro in Boost.Config for this. > >> > > Totally agree. > > > >> > >>> Is it possible to add a config macro for this? > >>> Or is there a good enough existing macro I can use? > >> > >> I don't think there is. Something like BOOST_NO_CXX11_HDR_EXCEPTION > >> would be useful. > > > > I would need to detect support for std::current_exception, not the > presence > > of header <exception>, so I would think that > > BOOST_NO_CXX11_CURRENT_EXCEPTION is what I need, right? > > BOOST_NO_CXX11_HDR_EXCEPTION, as all BOOST_NO_CXX11_HDR_* macros, detect > that the header not only exists, but is usable and contains all major > components described by the standard. In case of > BOOST_NO_CXX11_HDR_EXCEPTION, that would mean std::exception_ptr, > std::current_exception, std::rethrow_exception, std::make_exception_ptr, > etc. You need at least std::exception_ptr and std::current_exception. > Thanks, that makes sense! > > Should I open an issue in github for Boost.Config? > > Yes, or better yet - make a PR. > Added github Issue #284 [1], I'll try to come up with a PR. Wondering how deep the rabbit hole goes... ^_^ Regards [1] https://github.com/boostorg/config/issues/284

2 2