- Boost - lists.preview.boost.org

[release] 1.71.0 closed for Beta
by Michael Caisse 19 Jul '19

19 Jul '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to 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

5 8

Any sample code to configure boost log for syslog?
by JH 18 Jul '19

18 Jul '19

Hi, I am using boost log to write log file in the disk of the desktop, but for an embedded system application where the NAND flash is used, to prolong the flash service life time, I try not to write log files in flash, but use journalctl to view the log in RAM. Are there any simple example to configure boost log for syslog? Thank you. - jh

2 2

Something off my chest about Boost
by Maarten Verhage 18 Jul '19

18 Jul '19

Dear Boost people, Sorry but I need to get something off my chest regarding the Boost culture. To start of with something nice: I’m convinced Boost provides really useful facilities for C++ and some of them even make it into the standard C++ library. I do believe I can also contribute in a reasonable way. But the terse documentation keeps me from advancing. How it is currently stated on https://www.boost.org/users/faq.html “What about documentation? A very simple library might be accepted with only a well commented header file. For more substantial libraries, some form of documentation is certainly going to be expected. HTML is the preferred form.” To make Boost more accessible to people I believe Boost should ask more on this from current and new library authors. Speaking for myself. I think the first bits to get started with a library are on a sufficient level. You know the tutorial and the example code. But I get lost when I want to use the library for my own application domain. Then I do need library facilities not covered in the example code and sometimes the documentation mentions only the syntax. As I would imagine the library author working on his/her library judging whether to add a facility or not. Finally decided to add something: *the thought/motivation that goes along with that*, that would be so valuable for me to read that in the documentation!! Yes, I’m annoyed that I cannot read that in the documentation. Another issue is when example code introduces three or more facilities at once. Then it is very hard for me to see how these bits relate to each other to make it useful for myself. Ok, a few examples for what I would like to ask the Boost community to demand from the library authors: 1) In general, for the classes/functions where the user should directly deal with documentation like cppreference.com. So, with function prototypes showing the argument- and return types and a complete list of members along with what they do. 2) Specifically for Spirit X3, a part on Parser Directives: https://www.boost.org/doc/libs/develop/libs/spirit/doc/x3/html/spirit_x3/qu… I would very much like that the reason why each directive is added along with a minimal example that shows how to use just that directive. Anyway, I hope people are also interested to discus documentation policies on this mailing list. I do believe it is important. Best regards, Maarten Verhage

10 17

ASIO socket termination crashed at boost::asio::async_read
by JH 17 Jul '19

17 Jul '19

Hi, I use boost TCP socket for months, it works well until I call a termination of smart pointer which is running at boost::asio::async_read. Could anyone explain what could be the cause for the following errors? void Comms::HandleReadBody(const boost::system::error_code &error, const uint32_t length) { ................ boost::asio::async_read(this->mHandler->Socket(), boost::asio::buffer(this->mHeader, sizeof(this->mHeader)), [=](const boost::system::error_code &status, const uint32_t length) {this->HandleReadHeader(status, length);}); ............... } (gdb) run 2019-07-15 11:47:32.396184: Sanity check socket connection and terminate it when it is inactive ............. pure virtual method called terminate called without an active exception Program received signal SIGABRT, Aborted. (gdb) backtrace #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff7a24801 in __GI_abort () at abort.c:79 #2 0x00007ffff5565957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007ffff556bab6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007ffff556baf1 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007ffff556c8bf in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 HandleReadHeader(boost::system::error_code const&, unsigned int) () #7 0x00007ffff679a116 in boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code const&, unsigned int)#1}>::operator()(boost::system::error_code const&, unsigned long, int) () #8 0x00007ffff6799c20 in boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code c---Type <return> to continue, or q <return> to quit--- onst&, unsigned int)#1}> >::operator()(boost::system::error_code, unsigned long, int) () #9 0x00007ffff679b547 in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code const&, unsigned int)#1}> > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) () #10 0x000055555559f5c0 in boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) () #11 0x000055555559f747 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()

4 5

Useful Release Notes
by James E. King III 13 Jul '19

13 Jul '19

I'd suggest we make sure our release notes are useful to end users; I found some examples that are in the 1.71 that are not useful when reading the notes: * [phrase library..[(a)/libs/flyweight/index.html Flyweight]:] * Maintenance work. * [phrase library..[@/libs/poly_collection/ PolyCollection]:] * Maintenance work. Thanks, Jim

2 1

meeting today
by Robert Ramey 12 Jul '19

12 Jul '19

I was impressed with your presentation today. you can find current renderings at this link: https://we.tl/t-TDoBHgw9AF Robert Ramey

1 1

The out_ptr review is now over
by Zach Laine 11 Jul '19

11 Jul '19

Thanks to all that participated. A review result with be posted sometime in the next couple of weeks (the upcoming C++ standards meeting next week will delay it a bit). Zach

1 0

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

Link problem with graph and pending still appears unresolved?
by pbristow＠hetp.u-net.com 10 Jul '19

10 Jul '19

I have been bitten by this problem, again ☹ error: Cannot create link boost\pending\detail\disjoint_sets.hpp to libs\graph\include\boost\pending\detail\disjoint_sets.hpp. error: Link previously defined to another file, libs\disjoint_sets\include\boost\pending\detail\disjoint_sets.hpp. that was discussed https://lists.boost.org/Archives/boost/2019/04/246083.php I have got going again by deleting the contents of boost/boost/ containing the symlinks. But I note that a folder pending still exists, but not graph. Is this unresolved? Should it be fixed for the next release? Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

5 14

[releaase] 1.71.0 closed for major changes
by Marshall Clow 09 Jul '19

09 Jul '19

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. 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… > After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. As always, the calendar for the release cycle is available at: https://www.boost.org/development/ Thanks, -- The Boost Release Team

3 2

Beast repo history changed?
by Tom Kent 09 Jul '19

09 Jul '19

Did something get re-written in the beast repo? I was getting some weird errors on my cron mirror job: error: object file ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty error: object file ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty fatal: loose object 3c5bd5d909ee9b71f2b28d002dfe9d98355766c9 (stored in ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d9835576 6c9) is corrupt error: object file /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty error: object file /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty fatal: loose object 3c5bd5d909ee9b71f2b28d002dfe9d98355766c9 (stored in /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909e e9b71f2b28d002dfe9d98355766c9) is corrupt Deleting and re-creating the repo worked fine: git clone --mirror git@github.com:boostorg/beast.git Cloning into bare repository 'beast.git'... remote: Enumerating objects: 296, done. remote: Counting objects: 100% (296/296), done. remote: Compressing objects: 100% (158/158), done. remote: Total 48131 (delta 142), reused 210 (delta 110), pack-reused 47835 Receiving objects: 100% (48131/48131), 35.50 MiB | 24.22 MiB/s, done. Resolving deltas: 100% (33475/33475), done. Not an issue for my just curious/suspicious. Tom

2 1

Contributing to Boost. Astronomy
by Siddhartha Sen 09 Jul '19

09 Jul '19

Hello, I want to get started in contributing to Boost. Astronomy. Could anyone help me out here? This is the first time I will be contributing to open source. Hence I don't have any idea how this works. I am proficient in C and C++ and have a keen interest in Astronomy. Could anyone tell me what all things I need to learn first before I am able to contribute? What documentation should I read or what issues should I be aware of, before I can start contributing? Any help would be appreciated.

3 2

out_ptr formal review
by Gavin Lambert 05 Jul '19

05 Jul '19

My apologies in advance for the light novel. # Do you think the library should be accepted as a Boost library? Not in its current form, although I encourage cleaning it up and resubmitting it. # Your knowledge of the problem domain I've used COM smart pointers (usually CComPtr) a few times, and more rarely wrapped some other C or C-like APIs. (Although mostly pre-C++11, requiring something more hand-rolled than unique_ptr.) # What is your evaluation of the library's: ## Design The API seems reasonable for both out_ptr and inout_ptr. (Although also see the end of this post.) Actual uses for inout_ptr outside of a "realloc" type function seems a bit rare to me (and such APIs also seem rather rare), but perhaps there are other justifying cases I am not aware of, or it's more common in a particular domain. I do like that unspecified function argument evaluation order was considered, and I agree that it is better to try to maintain safety regardless of evaluation order rather than simply telling users to not access the smart pointer in other arguments -- it is a very easy trap for users to fall into, especially where the same code that has been working forever may suddenly fail with a different compiler version or different compiler settings. (Sequencing of destructor execution with additional && conditionals is admittedly a similar problem with no good solution within this design, as is explained in the caveats.) I don't like that it is left unspecified whether release() is called on construction or destruction (as that decision is left to the custom specialisations), as this potentially reintroduces that problem. I think it should be required that all specialisations behave in the following manner: For out_ptr: - construction initialises a raw ptr to nullptr and does not alter the smart ptr. - destruction resets the smart pointer to the raw ptr (in all cases). - this provides a useful guarantee that the smart ptr is always reset to nullptr if the called method returns nullptr, even if it had some other value previously. For inout_ptr: - construction get()s the current value of the smart ptr in two separate raw ptrs (one passed as the function argument, one cached for the destructor to use for comparison), but does not release() it. - destruction will (only if the raw ptr now has some different value) release()s the smart ptr and then reset()s it to the new raw ptr. - this makes it safe to use the smart ptr's value in other arguments of the method call; unspecified release() timing would have made that unsafe. (There is a slightly dodgy step in there where technically the smart pointer could be pointing at something which it thinks it owns, but that the called function has already deleted. However given that any normal or exceptional exit path would then call the inout_ptr destructor [guaranteed before the smart pointer destructor], which would safely release() the pointer without double-deleting it, this seems sufficiently safe, and worth it to permit safe argument usage. The only caveat is that usage of the smart pointer sequenced after the method call but before the destructor execution [as in additional && conditions] is not safe, as it may access deleted memory; however that code would never have the correct behaviour anyway and the documentation already warns to avoid doing that.) Perhaps there are some types of smart pointer for which this contract wouldn't work (eg. if it is possible for release() to fail, or to release a different pointer from what get() returns)? But then if so I'm not convinced it's safe to give them a uniform interface with pointers where it is safe, because otherwise inevitably someone is going to hit the unspecified-parameter-evaluation-order problem (or assuming that it will be nullptr on failure). Especially given these suggested constraints, I would prefer that a simple ADL or traits-type customisation point were added, so that you can adapt to smart pointers which merely have different spellings of the reset and release methods and don't require deeper customisation -- though the existing customisation point could be retained for especially weird smart pointer types if needed. (ADL customisation points are superior because, if designed correctly, they would not introduce a dependency on Boost.OutPtr, and if named well could theoretically also be used by other libraries, as with non-member begin and swap.) Similarly, while the static_assert check in base_out_ptr_impl specifically for std::shared_ptr and boost::shared_ptr seems valuable to prevent a significant class of bugs, I question whether it might be better handled by checking a type trait or other customisation point rather than checking directly for those types, such that it would be possible for a user-defined smart pointer type to also participate if it has a similar concern. Or perhaps it should just discourage use of shared_ptr at all; there should be little performance difference between using shared_ptr directly and using a unique_ptr which is later moved to a shared_ptr. (Since neither can take advantage of the make_shared optmisation, and by definition ownership must be unique at that point.) ## Implementation I haven't verified whether the current implementation exactly follows my suggested contract above, as there are a few too many layers of indirection and inheritance for me to easily parse. Simplifying the implementation would be nice if possible, especially for out_ptr, to improve readability. (However I think that my description is close at least.) I am strongly opposed to both of the "clever" implementations in the library. They should be completely removed. I can think of absolutely no justification (performance or otherwise) for a "clever" out_ptr. Due to both the requirement to pass in nullptr and to not delete the original smart pointer on construction (as it might be used in other parameters), the raw pointer can never have the same storage as the smart pointer anyway. (At least not unless you absolutely promise to never use a non-nullptr smart pointer, which reduces usefulness, albeit admittedly for a slightly peculiar use case [which would have been unsafe when used with raw pointers directly].) (In theory you could pass in an uninitialised raw pointer and then conditionally reset or do nothing depending on whether it still has the same uninitialised value after the call, but this both requires capturing the actual value at construction and providing a weaker contract to the C API, so it seems like a bad idea and a pessimisation to me. Another option is to unconditionally reset() on construction, but this sacrifices use in other parameters.) There is a possible justification for the clever inout_ptr, in that you can save two raw pointer copies if you reuse the smart pointer's storage, and this does not have the same caveats as with out_ptr. I am not convinced that anyone should care about that (especially in code paths also including memory allocation), although it is possible that the savings may be more significant with a smart pointer more complex than unique_ptr. Having said that, this "clever" implementation should absolutely never be used for any existing smart pointer, especially including std::unique_ptr or boost::movelib::unique_ptr. If there is sufficient justification for its existence at all, then you should instead create a new smart pointer (bikeshed: boost::out_ptr::fast_ptr) which behaves equivalent to std::unique_ptr except that you can steal its raw pointer storage when using inout_ptr. This could be made move-compatible with std::unique_ptr for the people who want to keep that type in their interfaces -- although that would presumably also remove any dubious performance benefit. As previously brought up in a separate thread, the current review implementation also leaks public inheritance of std::tuple, which is presumably intended as an empty-base optimisation, but must not be public or it will allow inappropriate slicing (and Very Bad Things™). ## Documentation The documentation seems decent, although being split into many short pages as at present can at times make it harder to locate something specific. I would prefer longer single pages divided into sections, but that's a matter of taste and not a review condition. I dislike the assertion that a "well-designed" C API would always set the parameter to nullptr on failure. That is certainly one option (and typically a preferred one), but leaving the parameter unchanged is another entirely reasonable option, and does not signify "poor design". It is only reasonable to claim poor design if the API allocates and sets the value, internally deletes it, and then reports failure (while still returning the altered and deleted pointer), as this condition cannot be handled by out_ptr (or indeed by anything that doesn't understand the failure return semantics of the API). The time axis scale in the benchmarks seems not entirely helpful as a lot of the time the difference between two implementations is within one axis division of each other. And again, the magnitude of performance difference sitting in the <1ns range in code which inherently implies memory allocation suggests a severe case of premature optimisation to me. (Though perhaps that might be more justifiable when used in non-memory handle contexts -- but then that might be an abuse of calling it a "pointer".) ## Usefulness I think that this library or something like it could be quite useful to help unify and improve safety when interacting with C-style T** APIs (or T* output arguments for some opaque handle type that requires cleanup), without requiring exploitation of operator& tricks like CComPtr does. (Sure, it's trivial to write an RAII wrapper around such APIs, but this can become cumbersome when there are hundreds or thousands of such APIs, unless you're using a code generator. And it's easy to accidentally forget subtle but important things such as deleting copy operations.) # Did you try to use the library? With what compiler? Did you have any problems? I did not try it. However the "clever" implementation is highly compiler-and-library-specific and quite aside from its design issues I think it would also produce significant portability issues. # How much effort did you put into your evaluation? I spent several hours on this review over the course of several days, and some related prior discussion in the mailing list. I read through all the documentation and most of the code (though not the tests). ============================ Having said all of the above, I wonder whether the library author has considered a different design for this functionality? Rather than the given example code: using bop = boost::out_ptr; boost::shared_ptr<mll_driver> axis_driver(nullptr); mll_errno err = mll_driver_init( bop::out_ptr(axis_driver, mll_driver_free), /* additional args ...*/); if (err != MLL_SUCESS) { // ... } A wrapping lambda syntax could be used instead: boost::shared_ptr<mll_driver> axis_driver(nullptr); mll_errno err = bop::invoke( [&](mll_driver** p) { return mll_driver_init(p, /* additional args ...*/); }, bop::out_ptr(axis_driver, mll_driver_free)); if (err != MLL_SUCESS) { // ... } Here, rather than its current meaning, bop::out_ptr just defines a parameter grouping which is then turned into a raw pointer-pointer argument for the lambda; it has no destructor-based shenanigans. (This could also be used for other non-pointer argument types -- there just needs to be a way for invoke to query the expected API argument type from the out_ptr or from the lambda itself.) This is admittedly more verbose than the current design (although bop::invoke could be written as just "invoke" due to ADL, for a slight simplification); but it would allow you to more safely control the sequencing between the API call and the reassignment of the smart pointer -- in particular all of the existing caveats with order of evaluations and with if-statement and composite conditional ordering no longer apply. (You can safely "&& axis_driver" above as long as you do it outside of the invoke call.) The API would be called (via the lambda) from a try-catch block inside of bop::invoke (or instead of the try-catch an RAII helper can be used to perform a try-finally action), and either the existing guarantee of not calling reset() or release() until after the call can be maintained (thereby allowing the smart pointer to be used by reference within the lambda), or it could be forbidden to use the smart pointer inside the lambda and the caller could lambda-capture the necessary arguments by value instead. Either way, the caller should be less surprised about lifetime issues across a lambda "border", and would quickly discover if they did it "wrong" (because the reset/release would either always occur before or always occur after argument evaluation, never in mixed order). invoke would normally be called with only one out_ptr or inout_ptr argument (and consequently one argument to the lambda), but could in principle be extended to any number of arguments either by nested invoke calls or by supporting a variadic form which does the equivalent within the library. It could possibly also be extended to support user-defined argument types to do something more complex, by defining a concept interface that it uses to interact with the argument, rather than explicit overloads or specialisations on those specific types. This could leave the decision of when to reset/release up to the smart-pointer-specific specialisation (if that's useful for performance reasons), and without leaving any time bombs for the caller.

1 0

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

Boost compatibility/communication issue with 1.47 to 1.7
by nunna, sarath babu (GE Healthcare) 03 Jul '19

03 Jul '19

Hello All, So far we have used Boost 1.47 VS2010 built binaries integrated with our VS2010 Code Base . But now we are upgrading VS2010 to VS2017 of our product code base, also we tried Boost 1.70 boost built using VS2017 and integrated with our VS2017 code base. Our product should be compatible with older versions of all tools including boost. We have not faced any issues except boost. Issue: 1.7 boost is not able to communicate to 1.47 boost and giving "SERIALIZATION ERRORS". 1.47 boost is not able to communicate with 1.7 boost and giving "SERIALIZATION ERRORS". Please help us and let us know which boost version we could upgrade that can be compatible with 1.47. Note: The customer is already using 1.47 2010 boost binaries with built VS2010 product which we can't change. Please suggest us the resolution or the version that we should use. Thanks, Sarath.

4 4

Construction of /defaultlib:XXX for boost::python
by Kacvinsky, Tom 01 Jul '19

01 Jul '19

I discovered while using boost 1.69 with Python 2.7 that a /defaultlib:XXX directive for the boost::python import library is injected into each object file that uses boost::python header files. What I have not been able to figure out is the magic for doing this. I presume it is a macro that makes a #pragma for default libs based on the threading model, the address model, the version of Python in use, and the _MSC_VER compiler macro. Am I am on the right track? Where would this code be? I could find it via searching for #\w?pragma in the code base. Thanks, Tom

2 1

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