- Boost - lists.preview.boost.org

Regression Tests Failing for Develop
by Tom Kent 05 Sep '22

05 Sep '22

I just noticed that all regression tests have been failing for develop since somewhere around Aug 24. https://www.boost.org/development/tests/develop/developer/summary.html I'm not sure if this is it or not, but I see an error in my ../libs/multiprecision/test/Jamfile.v2:1020: Unescaped special character in argument <toolset>msvc:<cxxflags>-constexpr: steps10000000 ../libs/multiprecision/test/Jamfile.v2:1021: Unescaped special character in argument <toolset>msvc:<cxxflags>-constexpr: steps10000000 /var/boost/run/boost_bb/src/build/project.jam:259: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory '../libs/python/build'. error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile. [Jj]amfile.jam'. error: Please consult the documentation at 'https://www.bfgroup.xyz/b2/'. Then the output shows: # Starting tests ("/var/boost/run/boost_bb/src/engine/b2" "-sBOOST_BUILD_PATH=/var/boost/run:/var/boost/run/boost_bb/src " "-sBOOST_ROOT=/var/boost/run/boost_root" "--boost=/var/boost/run/boost_root" "--boost-root=/var/boost/run/boost_root" "--boost-build=/var/boost/run/boost_bb/src" "--debug-configuration" -l300 toolset=clang-13~c++20 -d2 preserve-test-targ ets=off --dump-tests -j8 address-model=64 debug-symbols=off --remove-test-targets -m64 "--build-dir=/var/boost/run/resul ts" >>"/var/boost/run/results/bjam.log" 2>&1)... # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "/var/boost/run/boost_regression_src/regression.py", line 286, in __init__ self.main() File "/var/boost/run/boost_regression_src/regression.py", line 623, in main getattr(self,action_m)() File "/var/boost/run/boost_regression_src/regression.py", line 588, in command_regression self.command_test() File "/var/boost/run/boost_regression_src/regression.py", line 367, in command_test self.command_test_boost_build() File "/var/boost/run/boost_regression_src/regression.py", line 409, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/var/boost/run/results/boost/bin.v2/libs/any/test/any_test.test' But I think that's just a generic failure. Thanks, Tom

2 1

[Units] Incorrect definitions for torque, newton_meter
by Albert Dvornik 04 Sep '22

04 Sep '22

#include <iostream> #include "boost/units/systems/si.hpp" #include "boost/units/systems/si/io.hpp" using boost::units::quantity; using boost::units::si::torque; using boost::units::si::newton_meter; using boost::units::si::newton; using boost::units::si::meter; using boost::units::si::radian; int main() { // works fine: quantity<torque, double> tau0 = 0.0 * newton_meter; // SURPRISE: compilation fails because newton_meter is not the // same as newton*meter! // quantity<torque, double> tau1 = 0.0 * newton * meter; // Compilation succeeds even though the units on the RHS do not // represent torque but torsional stiffness! quantity<torque, double> tau2 = 0.0 * newton * meter / radian; // newton * meter should give us a quantity with units of Newton- // meters, i.e. m^2 kg s^-2. What this actually prints out is "0 J", // which is reasonable since dimensionally J is the same as N m. std::cout << boost::units::to_string(0.0 * newton * meter) << std::endl; // One might hope that newton_meter would be the same thing as // newton * meter. Instead, the result is "0 m^2 kg s^-2 rad^-1" std::cout << boost::units::to_string(0.0 * newton_meter) << std::endl; // The "torque" unit is also messed up in the same way. std::cout << boost::units::to_string(torque()) << std::endl; }

5 8

additional math-functions
by Gero Peterhoff 04 Sep '22

04 Sep '22

Hello, I would like to add several missing math functions in boost or specialize/overload existing ones for more types. These should be constexpr if possible. My problems with the concrete implementations are: - Which C++ standard to use C++11/14/17/20/23 ? - Should these be implemented in ccmath and math ? a) ccmath requires C++17 (eg "if constexpr"), so it is not possible to simply call the ccmath version in math, since math requires C++11. b) On the other hand, the math functions are already included in the standard (since C++11), so it wouldn't be necessary to continue to provide them (especially since they are not constexpr). Where and how exactly and with which C++ standard can I add the functions ? thx Gero

4 10

Password_protected .csv file
by Daggumati, Rajesh 31 Aug '22

31 Aug '22

Hi Team, We can create an .csv file using std::ofstream() function. But my project requirement demands to create a .csv file with password protected. Ofstream has open() function to create a file but how to create a file with password protected? Please help me on this. Regards, Rajesh D Confidential - Company Proprietary Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

4 4

Boost warning philosophy
by Scott Johnson 30 Aug '22

30 Aug '22

Hello, We are migrating a legacy codebase (embedded system though a PC architecture) from Centos 7.x, using various boost 1.5x components and GCC 7.3, to Ubuntu 22.04 and GCC 11.2 (the compiler that ships with this version of Ubuntu). As our application needs things that don't come with the "stock" Boost version that Canonical packages for 22.04, specifically Python 2.x support, I have downloaded and configured Boost 1.80 for our application to use. Unfortunately, our code development standard is -Wall -Werror (turn on all warnings and treat them as errors), with exceptions to -Wall only allowed grudgingly. And this version of Boost seems to break things, with all sorts of warnings being thrown that we simply don't see on the older version, distro, and toolchain. One of the biggest offenders seems to be things like #if _MSC_VER when this preprocessor symbol is not defined--GCC likes to warn that the symbol is being "defaulted" to zero in this context. (Defining it as 0 causes all heck to break loose, as there is also plenty of #ifdef _MSC_VER in the code). I've also seen warnings for overloaded virtual functions being hidden (a warning I would prefer not to disable), null pointer dereferences (ditto), and local variables being shadowed (ditto) from various Boost components. This is on production builds with -O2 optimization level. What is, if anything, the Boost policy towards compiler diagnostics of this sort? Is there a set of warnings we should be prepared to ignore if we use Boost with a more modern (and pickier) compiler? Should we perhaps consider another version of GCC? An older, more mature version of Boost (we don't need any specific features in the current one)? Thanks, Scott -- engineer_scotty (no, not that one) If life gives you lemons, drink Hefeweizen

3 2

[filesystem] becoming worse than the standard?
by Vinnie Falco 29 Aug '22

29 Aug '22

I see this in the commit log for boost.filesystem: Deprecated path construction/assignment/appending from container types. Users are advised to use string types and iterators instead of containers to construct/assign/append to paths. In v4, the support for containers is removed. This can't be right now, can it? Because std::filesystem supports path construction from anything meeting the requirements of Source which is kind of range-like. Boost.URL and its downstream libraries HTTP-Proto, HTTP-IO, Websocket-Proto, and Websocket-IO are depending on the container-based interface to achieve reasonably decent syntax and semantics despite the limitations of the path API (which are the fault of the standard and not Boost). If std::filesystem::path supports container-based parameters to assign() and append() then why is boost::filesystem::path removing it? Thanks

11 45

Re: [boost] [url] Andrzej's notes
by Vinnie Falco 25 Aug '22

25 Aug '22

On Mon, Aug 22, 2022 at 11:48 PM Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > Like in this example from the docs: > https://www.boost.org/doc/libs/1_80_0/libs/beast/doc/html/beast/quick_start… > > http::request<http::string_body> req{http::verb::get, target, version}; > req.set(http::field::host, host); > req.set(http::field::user_agent, BOOST_BEAST_VERSION_STRING); > > At no point do I have to see or provide a full URL. "target" is the URL there, it came from the command line. It is a relative-ref. >> * modifiers which take un-encoded inputs have a wide contract: all >> input strings are valid >> - however the url might need to reallocate memory to encode the result > > Does set_port() taking a string_view fall into that category? > Unlike other parts, port has special requirements on the string > contents that cannot be satisfied by pct-encoding. Yeah, we have a problem here. It sounds like we need to design an extra set functions. Maybe: url_base& url_base::set_port( string_view ); // throws result<void> url_base::try_set_port( string_view ); // returns result what do you think about that? > If you used result<>, you would lose the ability to chain the setters. Yeah... well, I think I'm OK with that. > As an alternative, you could say that function set_port() has a precondition: > the input string has to represent a number, the caller is responsible for that, > and set_port() performs no validation, and therefore throws nothing. But I > guess that would violate one of the design goals of the library: "securely, > including the case where the inputs come from untrusted sources". My original thinking was that untrusted sources would only be presented to parse functions. But our dialog has convinced me that we should treat the parameters to modification functions as untrusted as well. True, in some situations we will be performing unavoidable, needless re-validation. But I think it is the right tradeoff, as offering the stronger invariant has more value for users. Besides, there are workarounds for assembling a URL which trade back performance in exchange for weaker invariants. > Just to clarify what I mean: https://godbolt.org/z/qY3Y76fd9 > > urls::string_view s = "https://path?id=42&id=43"; > urls::url r = urls::parse_uri( s ).value(); > > Should the above input string not cause the invariant to be broken? (because param 'id' appears twice.) No, because the query is just a string. The interpretation of the query as "params" (an ampersand delimited list of name=value pairs) is an HTTP thing (and it has also spread to some other domains). When the query is used this way, duplicates are allowed. So the invariant is preserved in this case. It is always a valid URL. It might not be valid for custom schemes though. I could invent the "boost" scheme which requires that keys used in query parameters are unique. But there is no way for Boost.URL to enforce this (see my previous message regarding "mailto"). Users are provided with the tools to further specialize the generic URLs into custom schemes in a way that can preserve scheme-specific invariants. Thanks

5 11

Re: [boost] Boost.URL review
by Zach Laine 24 Aug '22

24 Aug '22

On Mon, Aug 22, 2022 at 9:41 AM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Sun, Aug 21, 2022 at 6:47 PM Vinnie Falco <vinnie.falco(a)gmail.com> wrote: > > > > On Sun, Aug 21, 2022 at 4:03 PM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > > ... > > > > It wouldn't be a proper review without at least one person forgetting > > to use "Reply All" :) So here it is, from Zach. I have quoted his > > message: > > > > > This makes sense. The larger issue I'm raising is that a user is > > > going to have a harder time remembering this, if the names don't > > > match. A way to mitigate that is to make this naming rationale > > > explicit, so that user > > > expectations will adjust. I didn't get that this was the pattern from > > > the documentation, though I think you did say it. A call-out > > > specifically noting this would porbably be enough. > > > > Yeah we can do that. > > > > > Hm. By lazy flat_map, do you mean that the positions are computed one > > > step at a time during iteration? is that why they have > > > forward_iterators? > > > > Yes. operator++ and operator-- intelligently find the next param or > > segment using a non-validating parse algorithm (since we know that the > > underlying character buffer has already been validated). > > > > > If so, please document that. It might make a > > > pretty big difference whether I decided to keep using a params object > > > that I need to update a lot, or copy everything over to a proper > > > flat_map or vector to do my work. > > > > Yes I agree, but I thought we did document that. Here, no? > > > > <https://master.url.cpp.al/url/ref/boost__urls__params_encoded_view.html#url…> > > > > We could probably add something here too: > > > > <https://master.url.cpp.al/url/ref/boost__urls__params_encoded_view/iterator…> > > Right, and I understood how those worked. However, I had no idea that > the owning containers were based on the same lazy approach (unless I > misunderstand what you said in this thread...). > > > > This works for an immutable container. It is *very surprising* for a > > > mutable one. The rest of my notes about the containers are predicated > > > on a false assumption that mutability implied non-laziness in the > > > container itself. I think all of these container would be better off > > > referred to as views, and made immutable. All you really need to > > > support is begin/end, plus maybe key-lookup. I suggest you drop the > > > mutability entirely. With mutability, these containers are trying to > > > do two things at once. > > > > Well, that's another way to do it and it certainly would remove > > complexity and simplify the names. Right now we have 8 containers: > > > > segments > > segments_view > > segments_encoded > > segments_encoded_view > > params > > params_view > > params_encoded > > params_encoded_view > > > > All of these containers reference the underlying character buffer of > > the URL (although you can also construct the views from separately > > parsed string views but that's basically the same thing in terms of > > the ownership model being reference-like). > > > > If we remove mutability as you suggest, then we can cut the number of > > containers down to 4: > > > > params_view > > segments_view > > params_encoded_view > > segments_encoded_view > > > > But this leaves us with a problem - how do you modify individual path > > segments and query params? > > Easy -- you just copy them into a flat_map, vector, or whatever. The > 90% use case is just to look at the result of the parse. Also making > the parsing library responsible for mutations you do to the data later > seems unnecessary. If you provide parsing -- including the lazy views > -- and then writing of URLs, and the writing can be done via a generic > container, that's all your library needs, IMO. To be clear: > > Parsing -> lazy_containers -> user mutations outside of Boost.URL -> > writing URLs > > That last step only needs to understand the different kinds of data it > might write, abstractly. That abstraction might be a params_view, a > flat_map, or a std::vector<std::pair<strd::string, std::string>>. > > > How do you do position-based insert and > > erase of elements using an iterator? These features seem kind of > > useful, I'm not sure I want to lose them. > > You won't lose them, because the STL exists. > > > > > Did you mean that it "doesn't" have proper error reporting? Where do > > > > you see this lack of reporting (if that's what you meant)? > > > > > > By "proper" I mean that if the parse fails it should provide an > > > end-user-friendly diagnostic, and optionally quote the line and put a > > > caret under the position that the parse failed (a la the Clang > > > diagnostics). Your non-end-user error reporting is fine. > > > > Oh... hmm.. well, each rule does leave the iterator out-param at the > > spot where an error occurred. But I'm not quite sure how to emit the > > diagnostic - surely you aren't suggesting we write to std::cout or > > std::cerr? Are we using curses or something? Or maybe just plain ASCII > > art? How exactly would this look? > > The diagnostics go to some optional output channel, which might be a > stream or file or logger. If you don't set the output, the diagnostic > is never generated. You set this output in the call to parse*(), as > an optional param -- usually a std::function<void(std::string const > &)>. > > > Thanks to Peter's work on boost::system::error_code, when a parse > > error occurs the error is augmented with file name, line, and function > > name information. And I have worked on adding visualizers so these are > > nicely presented in the debugger. So at least we have that. > > That's really nice for programmers, but it leaves the programmer with > a lot of work to do to present the error to the user. > > Zach Forgot to reply-all *again*. Zach

4 11

boost.url is accpted into boost
by Klemens Morgenstern 24 Aug '22

24 Aug '22

Boost.URL is ACCEPTED into boost without any conditions. The review recommendations were 6 ACCEPT, 1 CONDITIONAL ACCEPT and 1 REJECT. Many points were raised as part of the review, based on which I recommend doing the following: - reviewing which types/functions in the lower-level API are exposed and which ones are not (Ruben Perez' condition) - reviewing pct_encoded_view & encoded_path (as mentioned by Дмитрий) - adding more verbose docs without relying on knowledge of RFC3986 on the user side (mentioned by Richard) - adding more simple examples (recommended by Jon Kalb) - consider adding IRI support in the future (recommended by Rainer) Alan & Vinnie have been very responsive and read all the reviews, which makes it unnecessary to summarize everything. There is only one real point of controversy, namely the only reason for rejection written by Phil Endecott: > More fundamentally, I'm not convinced that this allocation-avoiding > view-rich API style is best for a general purpose vocabulary type > like URL. URL should be a "Keep It Simple" type, accessible to > C++ beginners, with straightforward lifetime semantics. Compare with > std::filesystem::path, which does not try to optimise by actually > being a view. > > Because of these concerns about the basic API design, I believe that > the library should be REJECTED. This argument has however been directly addressed in other reviews, with Seth considering it as an appropriate choice: > Like some of the earlier reviewers, I also have some concerns over introducing > non-owning vocabulary type. I do appreciate the design choice though, because I > think it ultimately fits the Boost ecosystem best - favoring > performance/versatility over ease of use. While Zach Laine considers this as the correct choice: > Overall, I quite like the design. Lazy, lazy, lazy. The fact that > only views into the underlying sequence are returned from the parse is > great, and the fact that there are both owning (url::url and > fixed-capcity owning url::static_url) and view versions of the URL > representations is exactly what I would need as a user. For my decision, the first factor is that more people approved of this particular design choice than disapproved. Secondly it seems to me that the C++ ecosystem is moving towards more view-support. The potential pitfalls can be addressed by coding guidelines (e.g. don't use auto) and do not need to be addressed by constraining libraries. Thus in finding a result, I did not consider Phil's argument to outweigh the other reviews which were considering it an acceptable choice. Other issues were the documentation, the confusion about encoded and decoded data and IRI support. Neither did lead to a rejection, so I'll leave it up to Alan's & Vinnie's discretion to review & address all the raised issues and to engage in further discussion on the mailing lists. Thank you Dmitry, Jon, Phil, Rainer, Richard, Ruben, Seth and Zach for your reviews and Alan & Vinnie for providing yet another boost library.

2 1

Fwd: Review of Boost.url
by Klemens Morgenstern 24 Aug '22

24 Aug '22

Forwarded from an email I received directly. ---------- Forwarded message --------- From: Jon Kalb Date: Mon, Aug 22, 2022 at 11:39 AM Subject: Review of Boost.url To: *- Does this library bring real benefit to C++ developers for real world use-case?* Boost currently contains at least three parsers (Regex, Spirit, and Xpressive) and most application seem to make do with std::string as a URL container implementation. That said, URL parsing is a non-trivial undertaking if done right and need to be done with in a surprising number of applications (because the number of applications that simply store and/or process URLs far out numbers the number of applications that directly use URLs). Having to re-invent the wheel of URL parsing in each of these apps results in both wasted time and poorly implemented solutions. URLs are both general enough and broadly used enough that they a library such as this will be a vocabulary library. *- Do you have an application for this library?* No. * - Does the API match with current best practices?* It appears so. The designed guidelines for the library are the correct ones. The issues that would cause a library such as this to not become widely used would be: - Language version dependency is too recent. - Module dependencies - Slow build times - Relies on dynamic allocation - Relies on exceptions - Not header-only - Not suitable for minimal devices/environments This is pretty much the design requirements for the library. In particular the approaches for minimizing and even avoiding dynamic allocations and functioning with or without exceptions will remove most what would be common stumbling blocks for this library. * - Is the documentation helpful and clear?* The documentation does appear to be thorough with a bit of a gentle introduction. I’d like to see more examples of getting, setting, and removing parameters and a better explanation of how escaping is handled. I suspect there is some magic there that I’d like to understand better. The “Help Card” is a brilliant design but the text in the URL syntax at the top renders improperly in my browser. * - Did you try to use it? What problems or surprises did you encounter?* I only did a read-through of the documentation, but it was thorough enough that I found (and submitted) a few minor corrections needed in the docs. * - What is your evaluation of the implementation?* I didn’t examine the implementation. *Some additional thoughts/questions for the author:* - I read Ruben’s review and tended to agree with and appreciate his thoughts. I did however disagree about exposing the low level parsing tools. If they were not a complete general implementation due to the fact that the library only needed some use cases, so they didn’t represent a completely implemented set of functionality, then I’d be skeptical and wonder if they were well tested. But it seems to me that the tools involved represent a valid and valuable contribution to the community. - I wonder if an operator<() should be defined so that urls could be used as keys out-of-the-box. - I wonder if more scheme constants should be provided. Probably not for the entire official list, but ‘ldap’, ‘mailto’, ‘news’, and ‘telnet’ might be useful enough to include. - This is out of my area of expertise, but I wondered if there might be platforms where instead of using “char” the library should be built on “signed char” or “unsigned char.” I think the URL library should be added to the Boost Libraries. I think will be valuable to the community and the level of professionalism in its design will reflect well on Boost. Thanks. Jon

2 1

boost.url review period has ended
by Klemens Morgenstern 24 Aug '22

24 Aug '22

Based on the amount of reviews I don't think we need an extension to make a clear & well-founded decision, which I hope to be able to announce soon. I would encourage those who didn't find the time to write a review to engage in discussion with Alan & Vinnie who have been very responsive to criticism. Thanks to everyone who participated in the review and discussion.

1 0

[url] Andrzej's notes
by Andrzej Krzemienski 23 Aug '22

23 Aug '22

Hi Everyone, It is somewhat unfortunate that the review happens during the vacation period, therefore I will not be able to devote the amount of time that the library deserves for the review. There is a procedure for extending the review period for a couple of days, but even if it were engaged, I doubt it would have bought me sufficient time. So let me instead offer some loose thoughts. Am I familiar with the problem domain, or do I have a use for this library? My understanding of an URL is that it is a text that I type into my browser (or other tools) that starts with either "http" or "https". I use URLs indirectly by using Boost.Beast, but Boost.Beast offers a higher-level interface for providing parts of URL, and even if this library is accepted, I would use the higher-level interface of Boost.Beast. This is not to claim that there are no uses for the proposed library. It is just my experience. Obviously, Boost.URL fits into the trend of providing many types with strong invariants, which I am very fond of. The fact that you have to set host, port and path separately avoids many bugs: you just cannot create an invalid URL. There is one thing that I do not understand though. I read that: 1. The library is tailored for environments that do not use exceptions 2. url guarantees that it maintains its invariant of always storing a string that represents a valid url. So given the following code executed on a platform with exceptions disabled, what happens? void test(url my_url) { my_url.set_port("twenty-one"); } is it going to kill the program? If so, is this considered a satisfactory solution? I use exceptions in my job, so this is a rather theoretical issue for me, but if I were using urls in no-exceptions environment, I think I would expect an interface like: error_code ec; my_url.set_port("twenty-one", ec); Or something similar. Next, the interface of parse_uri(). This library offers three types for storing (and owing) the characters representing a url: * url * static_url * an unnamed type returned by url_view::persist(). This is good, as in C++ the way the data is stored and laid out is in fact part of the contract. For the same reason we have multiple string types that differ by how memory is allocated, if it is stack allocated, how big the SSO is, what is guaranteed for swap. As a consequence we have a practical engineering issue -- not confined to URLs -- if there is N types storing the same logical data in N different ways, and I have a function returning this logical data, I do not want to offer N functions with N names. I may add a template, or I may use a universal type that can cheaply convert to the N types. How do I do that if I do not want to put templates in the interface of my library? The choice made by Boost.URL may not be optimal, but it is certainly a good starting point in the pursuit of the solution to this problem. I see url_view not as a view but as a universal type for cheaply constructing different containers storing URLs. Of course, this approach is incompatible with the "almost always auto" philosophy, which some people now promote to simply "always auto". My personal opinion is that this AAA philosophy is harmful from the outset and it begs for problems and bugs. If someone adapts the AAA one must accept the responsibility for the problems like the one with dangling references. Next, classes url_base and url_view_base are part of the library's public API. Why? You can keep them as bases but not advertise them in the library documentation. Do you expect any use cases for them? Next. the design in url classes is that it is a mixture of the generic URL as defined in the RFC, and the HTTP-speciffic stuff, such as paths and parameters. It is never the case that I need both of this worlds at the same time: I either need a generic URL that has a password but doesn't have path or params, or I need a HTTP-like URL, where I do not need a password. So if we think about strong types with strong invariants, I never get as strong a type as I would need. For instance, I would never want to pass the password in URL when using Boost.Beast, so having member set_password would only be a potential for bugs. Am I suggesting anything? The only use case that I have for this library is HTTP-like URLS. I would appreciate a http::url class that is tailored for http or even REST protocols. Regarding the docs, while I agree with others that some examples of use cases, such as percent encoding, would be desired, I also note that the documentation stands up to the high standards of of Boost libraries: not only could I figure out the architecture and how things work, but I was able to learn a lot about the problem domain, the URLs, URIs, IRIs, design trade-offs. I really appreciate the effort the authors have put in making the documentation this good. I have two recommendations, though. One, the picture that associates IQs with facial expressions: I strongly recommend that it is removed. It does not bring any technical value, but it seems to be sending a hostile message. Two, the colouring of different parts of URL syntax, as in https://master.url.cpp.al/url/containers.html#url.containers.generic_syntax: it help to quickly grasp things, but it also bring some confusion. For instance, I cannot tell if the double-slash is part of authority, or if the colon is part of the scheme. The colors suggest that they are, but the member functions tell otherwise. I have spent maybe like 30 hours studying the docs, superficially studying the implementation and tried to find if the two match, played with the toy examples in godbolt (gcc 12.1): https://godbolt.org/z/Tbsqrd77M Found a number of bugs and reported them in GitHub. The authors were very responsive and very quickly addressed practically all of them. Every implementation of every Boost library is difficult to read, in my opinion. Boost.URL matches the Boost standard in this respect. I could understand what the functions do, and what they do wrong. I found the solution in function url_view::persist() very innovative: you have one allocation instead of three. I didn't have time to play with path and param views. They seem fine on the surface, but I have a feeling that they would be clumsy to use in practice. I observed that params allow duplicate keys? Is it legal? I am hesitant to give a recommendation for acceptance. I would rather have a longer discussion than a fast decision. I also want to see how the authors respond to these notes. Finally, I want to thank the authors for writing and sharing this library. It is clear that a lot of effort and thought has been invested in it. Regards, &rzej;

6 9

boost.url review
by Christopher Bläsius 22 Aug '22

22 Aug '22

Hi, I'm not a boost developer, but as someone who has to deal with URLs (for calling or implementing Web-APIs) at his job frequently, I want to give my two cents as a most likely user of this library. I hope this is OK (I won't give a recommendation to accept or reject though). I spent about 2.5h integrating the library into our program and tried some simple parsing and constructing of urls. I used MSVC2022 which worked without problems. > - Does this library bring real benefit to C++ developers for real > world use-case? Yes definitely. I believe probably every programmer has written a (mostly crappy) URL-parser before, and I would be more than happy to replace our parser with this library. > - Do you have an application for this library? Yes. Besides parsing incoming HTTP-Requests, I would use it to programmatically construct urls to call external Web-APIs. One of the more common scenarios in our applications is the construction of urls after the user provided some login credentials and often hosts/port combinations. Also a prefix path is often needed (for example to differentiate between a demo or beta service and the real production api). I feel like the current API design lacks a bit in this regard. To construct a new url i did the following: auto url = boost::urls::url{}; url.set_scheme("https") .set_host("special-api.com") .set_port("443") .set_path("/prefix/api/v1/"); url.segments().push_back("applications"); url.segments().push_back(applicationId); url.segments().push_back("devices"); url.params().append("since", "2022-01-01"); The url::set_... methods seem to follow a fluent api design which is nice, but unfortunately they return url_base&. So I can't construct a url inside a function call like: httpClientGet(url{}.set_host(host).set_path("some/path")) Being able to add segments is great. Personally I'm a big fan of overloading the /-operator to append paths like in the filesystem library, because I think this results in more readable code. The example of above could become: httpClientGet(url{host} / "some/path") I really like that the library offers different parse_ functions, so an user can choose the appropriate one depending on the context. But it is a shame that there are no semantic types to go along with them. As mentioned above we often have the case that we have to construct a url by combining a prefix path with the actual path of the resource. As this prefix path has to be absolute and the resource path relative I want to use 2 distinct types for them. It seems to me, the resolve() function has a similar problem. The documentation states that the base url has to satisfy the absolute-URI grammar. Wouldn't it be great to have a distinct type for this? BTW why is there only an authority_view and not an owning container? Seems inconsistent to me. Its nice that there are functions to manually do percentage encoding, but I would prefer (additional) simpler functions which just return a std::string. It would be nice if the library also provided the default port numbers for the schemes. I know the documentation states that this is not part of the URL-protocol, but I gonna need that information if I use the library. > - Is the documentation helpful and clear? Mostly yes. Reading the "Quick Look" page is enough to get started with using the library which I appreciate. I also like the help card, which would be greatly improved by adding links to the reference pages. I skipped / skimmed the Customization and Concept pages. I would recommend not to start your example page with a 700 lines implementation of magnet links, that's super intimidating. Something I missed was a simple example showing that the parse functions also accept unknown schemes like opc.tcp:// for example. Thanks a lot for all your work on providing useful high quality libraries for everyone! Best Regards, Chris

3 2

URL Review
by Phil Endecott 22 Aug '22

22 Aug '22

My review of the proposed Boost.URL library follows. Unfortunately I have been away for most of the review period and I have not been able to spend as much time on this as I would have liked; in particular I have not tried to run any code. But I have looked at the source and documentation. In previous email discussions a few months ago I complained about the dangerous use of non-owning view types in the library interface, and I see that these issues are still present. Specifically, quoting the "Quick Look" docs: result<url_view> r = parse_uri( s ); url u = parse_uri( s ).value(); That's fine for C++03, but since C++11 we have auto, and this is where it becomes dangerous: auto r = parse_uri( s ); There's no indication here that r is a non-owning view and that the caller is responsible for keeping s alive for the lifetime of r. Such errors could be difficult to detect; the code may appear to work correctly much of the time if the storage for s is not re-used. auto u = parse_uri( s ).value(); That's even worse, because we're calling a method called value() but what it returns is not actually a value, it's still a view. A safer API design would, at a minimum, give the parsing function a name with "view" in it. The default, shorter-named function should return a value type. More fundamentally, I'm not convinced that this allocation-avoiding view-rich API style is best for a general purpose vocabulary type like URL. URL should be a "Keep It Simple" type, accessible to C++ beginners, with straightforward lifetime semantics. Compare with std::filesystem::path, which does not try to optimise by actually being a view. Because of these concerns about the basic API design, I believe that the library should be REJECTED. Following are some comments about other more minor issues that I have noticed: I see that there is a method called persist(): std::shared_ptr< url_view const > persist() const; This function returns a read-only copy of the URL, with shared lifetime. The returned value owns (persists) the underlying string. The algorithm used to create the value minimizes the number of individual memory allocations, making it more efficient than when using direct standard library functions. Hmm, so url_view doesn't own the underlying storage, except when it does as a result of this mysterious method. What's the rationale for this? (Have I missed some documentation?) What is sizeof(url) or sizeof(url_view)? I think it must be about 160 bytes, since you store offsets to each of the components. I'm not convinced that this is the best approach. I would be inclined to determine the offsets each time they are needed by the accessor methods. In the constructor, parse to validate the syntax but don't store any offsets. I believe that in the case of the path segments and the query parameters, you are not storing offsets (because the number is variable, and that would need allocations); why not adopt that approach for the other offsets? Making the objects smaller would probably have measurable performance benefits. In your non-view url object, you seem to allocate storage using new char[]. Why not use a std::string? One benefit of a std::string is SBO. Another is that you could provide a move constructor from a string. I find the names of the encoding/decoding views confusing. I would expect a "decoded_view" to refer to underlying encoded data and return equivalent decoded data when it is read from, but you seen to call that an "encoded_view". In your query parameter API, you expose something that looks like a standard associative container except that you call the key and value "key" and "value" respectively, rather than "first" and "second". While I think many of us would agree that those are better names, it does make it more difficult to use this container with generic code than it would be otherwise. I see that you also have a bool called "has_value" in the value_type. I think this is to handle this: ?a=1 // has_value == true && value == "1" ?a= // has_value == true && value == "" ?a // has_value == false Is that correct? Again having this third member in the container's value_type makes generic code more difficult. I would be inclined to use a std::optional for the value instead. In the past I have had situations where it was necessary to specify the case for hex letters in %-encoding; please consider adding this to pct_encode_opts. The Magnet Link example needs a paragraph at the start to say what a Magnet Link is. Regards, Phil.

5 6

boost.url review
by Klemens Morgenstern 22 Aug '22

22 Aug '22

Hi all, the formal boost review of the boost.url library starts today, the 13th of August and will last until and including the 22nd of this month. The library has been developed by Vinnie Falco and Alan de Freitas. The master branch is frozen during the review and can be found here: https://github.com/CPPAlliance/url The current documentation can be found here: https://master.url.cpp.al/ Boost.URL is a portable C++ library which provides containers and algorithms which model a "URL" and understands the various grammars related to URLs and provides for validating and parsing of strings, manipulation of URL strings, and algorithms operating on URLs such as normalization and resolution. Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost. Also please indicate the time & effort spent on the evaluation and give the reasons for your decision. Some questions to consider: - Does this library bring real benefit to C++ developers for real world use-case? - Do you have an application for this library? - Does the API match with current best practices? - Is the documentation helpful and clear? - Did you try to use it? What problems or surprises did you encounter? - What is your evaluation of the implementation? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Reviews can also be submitted privately to me, and I will not disclose who sent them. I might however cite passages from those reviews in my conclusion. Thanks to Vinnie & Alan for providing us with a new library & thanks for all the reviews in advance. Klemens

9 20

Boost.URL review planned for 13-22 August 2022
by Mateusz Loskot 22 Aug '22

22 Aug '22

Folks, Klemens Morgenstern kindly volunteered [1] as the Review Manager (thanks Klemens!) for the Boost.URL [2], so we have planned the review shortly after the upcoming release of the Boost 1.80. Check the Review Schedule [3] for details! [1] https://lists.boost.org/Archives/boost/2022/06/253225.php [2] https://lists.boost.org/Archives/boost/2022/04/252814.php [3] https://www.boost.org/community/review_schedule.html Best regards, -- The Boost Review Wizards Mateusz Loskot

3 4

boost.url review ends today
by Klemens Morgenstern 22 Aug '22

22 Aug '22

Today is the last day to submit your review for boost.url. Thanks in advance!

1 0

bug - boost::math::ccmath::copysign not work
by Gero Peterhoff 22 Aug '22

22 Aug '22

Hi, I just see that boost::math::ccmath::copysign doesn't work. https://godbolt.org/z/9af1ME9fT cu Gero

5 11

Re: [boost] Boost.URL review
by Vinnie Falco 21 Aug '22

21 Aug '22

On Sun, Aug 21, 2022 at 4:03 PM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > ... It wouldn't be a proper review without at least one person forgetting to use "Reply All" :) So here it is, from Zach. I have quoted his message: > This makes sense. The larger issue I'm raising is that a user is > going to have a harder time remembering this, if the names don't > match. A way to mitigate that is to make this naming rationale > explicit, so that user > expectations will adjust. I didn't get that this was the pattern from > the documentation, though I think you did say it. A call-out > specifically noting this would porbably be enough. Yeah we can do that. > Hm. By lazy flat_map, do you mean that the positions are computed one > step at a time during iteration? is that why they have > forward_iterators? Yes. operator++ and operator-- intelligently find the next param or segment using a non-validating parse algorithm (since we know that the underlying character buffer has already been validated). > If so, please document that. It might make a > pretty big difference whether I decided to keep using a params object > that I need to update a lot, or copy everything over to a proper > flat_map or vector to do my work. Yes I agree, but I thought we did document that. Here, no? <https://master.url.cpp.al/url/ref/boost__urls__params_encoded_view.html#url…> We could probably add something here too: <https://master.url.cpp.al/url/ref/boost__urls__params_encoded_view/iterator…> > This works for an immutable container. It is *very surprising* for a > mutable one. The rest of my notes about the containers are predicated > on a false assumption that mutability implied non-laziness in the > container itself. I think all of these container would be better off > referred to as views, and made immutable. All you really need to > support is begin/end, plus maybe key-lookup. I suggest you drop the > mutability entirely. With mutability, these containers are trying to > do two things at once. Well, that's another way to do it and it certainly would remove complexity and simplify the names. Right now we have 8 containers: segments segments_view segments_encoded segments_encoded_view params params_view params_encoded params_encoded_view All of these containers reference the underlying character buffer of the URL (although you can also construct the views from separately parsed string views but that's basically the same thing in terms of the ownership model being reference-like). If we remove mutability as you suggest, then we can cut the number of containers down to 4: params_view segments_view params_encoded_view segments_encoded_view But this leaves us with a problem - how do you modify individual path segments and query params? How do you do position-based insert and erase of elements using an iterator? These features seem kind of useful, I'm not sure I want to lose them. > > > "Remove" is not really a term used in the STL. I think your > > > "remove*()" container members should be "erase*()" instead. > > > > I'm not sure where you're seeing this? There are no "remove" functions > > in these containers. > > params::remove_value() is one. I think(?) there are others. Oh. Well... remove_value() only removes the value part of the param. It does not erase the entire param. There's no such thing as insert_value. The javadoc is wrong unfortunately (sorry about that). We do use the term erase() when the operation removes the entire element. > > Did you mean that it "doesn't" have proper error reporting? Where do > > you see this lack of reporting (if that's what you meant)? > > By "proper" I mean that if the parse fails it should provide an > end-user-friendly diagnostic, and optionally quote the line and put a > caret under the position that the parse failed (a la the Clang > diagnostics). Your non-end-user error reporting is fine. Oh... hmm.. well, each rule does leave the iterator out-param at the spot where an error occurred. But I'm not quite sure how to emit the diagnostic - surely you aren't suggesting we write to std::cout or std::cerr? Are we using curses or something? Or maybe just plain ASCII art? How exactly would this look? Thanks to Peter's work on boost::system::error_code, when a parse error occurs the error is augmented with file name, line, and function name information. And I have worked on adding visualizers so these are nicely presented in the debugger. So at least we have that. Thanks

1 0

boost.url review
by Richard Hodges 21 Aug '22

21 Aug '22

My review of Boost.URL Before answering the questions presented by the review manager, I thought I’d share a few words about what Boost represents to me and why I take an interest in it. Many moons ago, Boost was pretty much the only way to use the C++ programming language in any kind of useful, cross-platform way. Today, the C++ standard has evolved and grown considerably. Many of the original drivers to use Boost are seemingly “solved” in the language itself. Notwithstanding that some of the design decisions taken by the Committee over the years have resulted in an anaemic half-copy of Boost features being standardised. Because of this (in my view) failure of the committee decision process in the face of reality, I still use many of the fundamental Boost utilities in place of their standard counterparts. Therefore, to my mind, Boost is still a necessary component of any non-trivial program I write in C++. Boost also has a collection of utility libraries, some of which have waned in relevance over time. For example, Boost.Format is now pretty much obsolete in the face of fmtlib (not std::format, which is another example of a half-hearted attempt to standardise a solution). When I program, I do so almost exclusively in C++. I don’t really want the bother of having to reach for other languages or to stay current in their dependency management solutions of the day. What I really want is one massive library that I can pull in which does everything I need, or at least the common things. Common things for me are: - Communications, including HTTP, WebSockets, databases and messages buses. - Console IO - Logging - Graphics & Human Interfaces - Sound For me, anything that takes us a step closer to having one library that shrink-wraps all that into one `find_package` call in CMake is a win. Now I will admit that once upon a time, I believed that all this stuff should be in the standard library. However since then, having worked as a library maintainer myself, I have come to realise that this is an error. Giving compiler maintainers the burden of maintaining humongous libraries will simply discourage innovation in compiler technology and result in incomplete implementations and porting to new computing platforms. Boost’s cross-platform compatibility is unparalleled. Therefore I am strongly of the view that the place for C++ library innovation is Boost, and the place for standardising the language changes that are demonstrated as necessary by Boost innovation lies with the Committee and compiler developers. For me, any new library that increases Boost’s real-world utility, is fully cross platform and reduces my workload when writing application programs is very welcome. For for the review: > Does this library bring real benefit to C++ developers for real world use-case? Yes. URL parsing can be fluked with regex, split and a few hand-rolled utilities. But why give developers the burden of hand-rolling this boilerplate nonsense? Make simple things simple! > Do you have an application for this library? Absolutely. I am happy to retrofit Boost.URL into existing code and would certainly use it in all future code. > Does the API match with current best practices? I have no idea what “best practices” are in API design. The API allows me to interrogate, build and update internet URLs. I may have made different naming choices and if I had written it I would probably have made more use of free functions, but I’m not going to argue about style. Utility is all that matters to me. > Is the documentation helpful and clear? Much like the Boost.ASIO documentation, it is 100% correct and tersely describes the exact functionality of the API. Use of the documentation requires at least a cursory understanding of the terms in RFC3986. Twenty years ago, it would probably have been reasonable to require users to read this RFC prior to using the library. Today, attention spans are shorter and the internet is a commodity. I would prefer to see a little more narrative and descriptions of real-world uses of some of the methods, along with code examples. > Did you try to use it? Yes, I retrofitted Boost.URL into a program that I used as the basis of a blog post - a program to demonstrate following redirect responses when connecting a WebSocket. I have also integrated Boost.URL into a new program which connects to an exchange in the past week. Doing so saved probably 200 lines of hand-rolled code. > What problems or surprises did you encounter? The library lacked a specific facility to extract just the HTTP TARGET field from a URL. After reporting this to the author with a supporting use case and hand-rolled work-arwound, this has now been added. > What is your evaluation of the implementation? It is clear that a great deal of care has gone into making the implementation robust and efficient. > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I retrofitted Boost.URL into an existing program and wrote a new program that uses the library. I spent some time discussing what I felt were missing features with the author, who has been responsive. My required features subsequently appeared. > Are you knowledgeable about the problem domain? I’ve been writing internet-facing servers and clients in C++ for a decade. In all that time I have never read RFC3986. I suspect like 99% of developers, I have simply inferred the rules of URL encoding through use. So perhaps a time-served journeyman rather than domain expert. Recommendation: ACCEPT The day I can write a CML that has only one dependency, Boost, will be a happy day. -- Richard Hodges hodges.r(a)gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212

3 2

Boost.URL review
by Zach Laine 21 Aug '22

21 Aug '22

- Does this library bring real benefit to C++ developers for real world use-case? Yes. - Do you have an application for this library? No. - Does the API match with current best practices? See details below. - Is the documentation helpful and clear? In Overview: - s/will be easy to read/is easy to read (no need to use the future tense) - s/1.78/1.81 (can't use 1.78 if URL depends on TOT, which is stated elsewhere in the review announcement) - The bullet list is an awkward mix of verb- and noun-phrases (e.g. "Require only C++11" and "Fast compilation, few templates"). I suggest all noun-phrases, like "Requires only C++11"). - s/1.80/1.81 -- same reason as above. - I think that flow in tutorial-style documentation is important. In the Overview, you introduce what the library is at a high level, then jump into some build- and compiler-support weeds, only to then follow with the Quick Look section. IMO, you should move the bits after the bullet list to a section called Compilers and Build Considerations or similar, and place it much later in the docs. In Containers: The text at the top makes the relative/absolute distinction sound important, but the rest of the page does not define or show examples of the difference between the two. I suggest single quotes around "/" in "The reason is any decoded character / could make", since on first reading I thought it was part of the documentation text, not in code-font. Maybe do it like you do for the mention of double slashes a few lines later? When the ambiguity of the string "https://www.example.com/get-customer.php?name=John%26Doe" is mentioned, the docs say that if the query string represents parameters, the quoted "&" is not ambiguous. Then it shows an example of getting all the parameters from the string "https://www.example.com/get-customer.php?id=409&name=Joe&individual". This begs the question, what happens when there's a "%26" in the string, and you use .params()? Please show this as part of the example, or at least explain it. Examples: It would be nice if these were on separate pages. Even nicer would be some context, besides just a bunch of code. I had to Google "magnet link", and I still don't really know what it is. A brief explanation would be helpful. API Docs: The utl::params API docs refer to it as a random-access view, but it is neither random-access, nor a view. - Did you try to use it? What problems or surprises did you encounter? I did not. - What is your evaluation of the implementation? I did not look too much at the implementation. but what I did look at was somewhat hard to follow. I went looking for where a result<> is filled in during the parse, and it took me a solid 45 minutes to find it. Design: Overall, I quite like the design. Lazy, lazy, lazy. The fact that only views into the underlying sequence are returned from the parse is great, and the fact that there are both owning (url::url and fixed-capcity owning url::static_url) and view versions of the URL representations is exactly what I would need as a user. When I call parse_uri(), I get a result of type result<url_view>? Why isn't the function spelled parse_url(), or the return type spelled result<uri_view>? This seems needlessly inconsistent, given the assertion in the docs that URL is fine to use in place of URI. The assign_to() API seems awkward to me (as in std::string str; u.query().assign_to(str);). This would be better as a conversion function with a name, like string(), to_string(), or as_string(). Assignment is fundamental, and the compiler knows what to do with it (how to optimize it away, for one thing). Assignment through an out-param is awkward at best, and is actually more likely to lead to more pessimal code, since RVO cannot be applied. The append_to() API is really very nice. Most libraries don't support appending as a first-order operation, but it is essential for string perf in many use patterns. However, the containers are frankly a mess. What are they, exactly, at a high level of abstraction? For instance, is params a singly-linked list? It has a forward iterator, so it kinda looks like one. Is it an associative container? It has key/value pairs (where, sure the value might be empty, but it still exists at the level of the container), so it looks like one of those too. Is it array-like? The keys are not sorted, and the order corresponds to the order in a URL, so it sure looks array-like. This is important to users who want to use your containers in generic code, including the standard algorithms (which often have a pessimal implementation specific to forward_iteretors). Also, your containers have about 10% of the API of any of the kinds of containers listed above, meaning generic code will have to special-case use of your container if it's missing some of the SequenceContainer or AssociativeContainer API that the generic code relies on. I recommend that you implement params in terms of a std::vector<std::pair<string_type, string_type>> (using whatever string_type you're already using), and then add the API that is URL-specific on top of it, and have two members: std::vector<std::pair<string_type, string_type>> & storage(); std::vector<std::pair<string_type, string_type>> const & storage() const; Then make the iterators RA. Similar changes seem appropriate for the other containers as well. "Remove" is not really a term used in the STL. I think your "remove*()" container members should be "erase*()" instead. The replace() API is nice. I only wish it were range-capable (that is, I wish there were an overload taking two iterators to erase, and two iterators to insert). Why did you define your own find_if() and find_if_not(), instead of using the std ones? And why the hell does CharSet have these two as members? That's crazy! I find the creation of a mini-parsing library and the expectation that users will use this mini-library to write their own parsers to be somewhat problematic. No one is going to use your mini-library for serious parsing work (except perhaps for modifications to the way URL does its parsing). It does have proper error reporting, for one thing. There are other equally obvious limitations. If the parsing were an implementation detail, or if you were only providing the parsing lib for extensions to your existing parsing, what you've provided would be enough. However, you also claim that you can use URL as part of a larger parser, and I don't think that's realistic. I vote to ACCEPT. I think I've raised legitimate concerns about the design here, but none of them rises to the level of a blocker. Zach

2 1

Boost.url review reminder
by Klemens Morgenstern 21 Aug '22

21 Aug '22

Hi all, this is a reminder that the boost.url review is currently going on, and we only got one review so far. Any review is appreciated. The Review ends on the 22nd, i.e. next Monday. Thanks in advance, Klemens

3 2

Is there an analogue of `boost::reference_wrapper`, that can also work with rvalue references?
by Денис Михайлов 20 Aug '22

20 Aug '22

I find an wrapper like `boost::reference_wrapper`, but with more abilities, like this: ``` int value = 0; auto rref = boost::ref(std::move(value)); auto prref = boost::ref(int{}); f(rref); // pass rref into f by ordinary reference f(std::move(rref)); // move rref into f f(std::move(prref)); // move prref into f ``` Is there such functionality on the Boost side? If not, is it allowed to discuss the possibility of contributing it?

1 0

Is there a way to get ctype facet with boost::locale::generator?
by Gleb Igumnov 19 Aug '22

19 Aug '22

Hello. I have a problem. I need to get std::locale object for my locale (ru_RU.UTF-8) on a systems that don't have one. I decided to take a look at boost::locale::generator, as it has ICU as a backend and there must be full locale info in it. But to my surprise generator do not generate only locale facet that I really need - ctype one. For example following code will go "oops" branch: #include <iostream> #include <boost/locale.hpp> #include <boost/locale/localization_backend.hpp> using namespace std; int main() { using namespace boost::locale; localization_backend_manager my = localization_backend_manager::global(); my.select("icu"); // I know that icu is default backend but I select it explicitly to be sure. boost::locale::generator gen(my); std::locale loc( gen.generate( "ru_RU.UTF-8" ) ); if( !std::isalpha( L'ф', loc ) ) std::cout<< "Oops\n"; else std::cout << "Ok\n"; return 0; } But if I will do std::locale loc( gen.generate( std::locale( "en_US.UTF-8" ), "ru_RU.UTF-8" ) ); It will work, as it will have ctype facet from en_US.UTF-8 locale, but that is not a solution as I may not have en_US.UTF-8 locale either, and on some systems, (for example iOS) I won't have any UTF-8 locale available for std::locale constructor. So I'm curious, why generator won't generate ctype locale? Is there any reason behind it? Or maybe I'm doing something wrong? Is there any way to generate locale with proper ctype facet from ICU using boost::locale::generator? -- -- With respect Gleb "Crazy Sage" Igumnov mailto:crazy.sage@gmail.com

1 0

TSAN SEGFAULT in Boost.Beast CI
by Richard Hodges 16 Aug '22

16 Aug '22

Dear all, You may have noticed that one of the Beast CI checks fails on the master and develop branches. The failure is a segfault in thread sanitizer. Running on my local machine I get the stack trace embedded below. This does not happen if Asio is reverted back to version 1.79.0 Chris has confirmed that the change in Asio that caused this is in asio::spawn. Note that at this stage there is no reason to suspect that Asio is actually at fault. I believe it to be a false positive. However, I am an absolute noob when it comes to the Dark Arts of thread sanitizer. I have no idea what to blacklist. This email has two aims: 1. To prevent multiple people wasting their time trying to get to the bottom of this, 2. To encourage some sage TSAN-maester to emerge who may guide me to enlightenment. Here is the error and stack trace: testing.capture-output bin.v2/libs/beast/test/beast/http/read.test/gcc-12/debug/link-static/thread-sanitizer-norecover/threading-multi/visibility-hidden/read.run ====== BEGIN OUTPUT ====== beast.http.read ThreadSanitizer:DEADLYSIGNAL ==1761540==ERROR: ThreadSanitizer: SEGV on unknown address 0x7f6ea78ff000 (pc 0x7f6eaaaba0d0 bp 0x000000000000 sp 0x7f6ea783d910 T1761542) ==1761540==The signal is caused by a READ memory access. #0 __sanitizer::StackDepotBase<__sanitizer::StackDepotNode, 1, 20>::Put(__sanitizer::StackTrace, bool*) <null> (libtsan.so.2+0xba0d0) #1 __tsan::CurrentStackId(__tsan::ThreadState*, unsigned long) <null> (libtsan.so.2+0x8c48f) #2 __sanitizer::DD::MutexInit(__sanitizer::DDCallback*, __sanitizer::DDMutex*) <null> (libtsan.so.2+0xac534) #3 __tsan::DDMutexInit(__tsan::ThreadState*, unsigned long, __tsan::SyncVar*) <null> (libtsan.so.2+0x9a3f8) #4 __tsan::MetaMap::GetSync(__tsan::ThreadState*, unsigned long, unsigned long, bool, bool) <null> (libtsan.so.2+0xa85dc) #5 __tsan_atomic32_fetch_add <null> (libtsan.so.2+0x783e9) #6 __gnu_cxx::__exchange_and_add(int volatile*, int) /usr/include/c++/12/ext/atomicity.h:66 (read+0x41ad46) #7 __gnu_cxx::__exchange_and_add_dispatch(int*, int) /usr/include/c++/12/ext/atomicity.h:101 (read+0x41ad46) #8 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release_last_use() /usr/include/c++/12/bits/shared_ptr_base.h:187 (read+0x41ad46) #9 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/12/bits/shared_ptr_base.h:361 (read+0x40d87c) #10 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/12/bits/shared_ptr_base.h:1071 (read+0x41b43c) #11 std::__shared_ptr<boost::asio::detail::strand_executor_service::strand_impl, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/12/bits/shared_ptr_base.h:1524 (read+0x424db7) #12 std::shared_ptr<boost::asio::detail::strand_executor_service::strand_impl>::~shared_ptr() /usr/include/c++/12/bits/shared_ptr.h:175 (read+0x424de3) #13 boost::asio::detail::strand_executor_service::invoker<boost::asio::io_context::basic_executor_type<std::allocator<void>, 0ul> const, void>::~invoker() <null> (read+0x486f4d) #14 boost::asio::detail::executor_op<boost::asio::detail::strand_executor_service::invoker<boost::asio::io_context::basic_executor_type<std::allocator<void>, 0ul> const, void>, boost::asio::detail::recycling_allocator<void, boost::asio::detail::thread_info_base::default_tag>, boost::asio::detail::scheduler_operation>::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) <null> (read+0x49ff36) #15 boost::asio::detail::scheduler_operation::complete(void*, boost::system::error_code const&, unsigned long) boost/asio/detail/scheduler_operation.hpp:40 (read+0x513742) #16 boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&) boost/asio/detail/impl/scheduler.ipp:492 (read+0x501be9) #17 boost::asio::detail::scheduler::run(boost::system::error_code&) boost/asio/detail/impl/scheduler.ipp:210 (read+0x5008af) #18 boost::asio::io_context::run() boost/asio/impl/io_context.ipp:63 (read+0x4f54d6) #19 boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}::operator()() const <null> (read+0x41480d) #20 void std::__invoke_impl<void, boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}>(std::__invoke_other, boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}&&) <null> (read+0x4bb4bc) #21 std::__invoke_result<boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}>::type std::__invoke<boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}>(boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}&&) <null> (read+0x4b8c78) #22 void std::thread::_Invoker<std::tuple<boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) <null> (read+0x4b5b00) #23 std::thread::_Invoker<std::tuple<boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}> >::operator()() <null> (read+0x4b1f74) #24 std::thread::_State_impl<std::thread::_Invoker<std::tuple<boost::beast::test::enable_yield_to::enable_yield_to(unsigned long)::{lambda()#1}> > >::_M_run() <null> (read+0x4ab02e) #25 execute_native_thread_routine <null> (libstdc++.so.6+0xdbb72) #26 __tsan_thread_start_func <null> (libtsan.so.2+0x393ef) #27 start_thread <null> (libc.so.6+0x8ce2c) #28 clone3 <null> (libc.so.6+0x1121af) ThreadSanitizer can not provide additional info. SUMMARY: ThreadSanitizer: SEGV (/lib64/libtsan.so.2+0xba0d0) in __sanitizer::StackDepotBase<__sanitizer::StackDepotNode, 1, 20>::Put(__sanitizer::StackTrace, bool*) ==1761540==ABORTING EXIT STATUS: 66 ====== END OUTPUT ====== -- Richard Hodges hodges.r(a)gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212

3 8

stream operators for number
by Gero Peterhoff 15 Aug '22

15 Aug '22

Hello, can you please provide the << and >> operators for boost::multiprecision::number as a stream template? currently (fixed ostream) template <class Backend, expression_template_option ExpressionTemplates> std::ostream& operator<<(std::ostream& os, const number<Backend, ExpressionTemplates>&) useful template <typename Char, typename Traits, typename Backend, expression_template_option ExpressionTemplates> std::basic_ostream<Char, Traits>& operator<<(std::basic_ostream<Char, Traits>& stream, const number<Backend, ExpressionTemplates>&) thx Gero

2 2

Tested Compilers
by Eduardo Quintana 15 Aug '22

15 Aug '22

Hi! I would like to suggest that Boost is also tested on compilers like Intel OneAPI 2022 and Visual Studio 2022. Regards, Eduardo Quintana SFTWY CDI Ltda. 5511-2157-6800 / 5511-2251-8181- / 5511-95025-3705

1 0

numeric_cast
by Gero Peterhoff 15 Aug '22

15 Aug '22

Hallo, can you improve numeric_cast 1) constexpr 2) vectorisable The problem is that the compilers on x86 without hardware support (AVX512DQ) do not vectorize the conversions u/int64_t -> float64/32_t. This may also apply to other architectures. But that can be solved manually. My patch requires C++20 (std::bit_cast), but you can probably work around that. Modifications: - add #include <boost/predef.h> - improve raw_converter For a better understanding see https://godbolt.org/z/j58rW411s regards Gero

2 1

Boostbook doesn't not work with libxslt 1.1.35
by Giovanni Mascellani 13 Aug '22

13 Aug '22

Hi, it seems that Boost fails building boostbook docs if xsltproc and libxslt1 version 1.1.35 is installed (it works with version up to 1.1.34). Specifically, I can reproduce the failure following these steps: * recursively clone git@github.com:boostorg/boost.git * ./bootstrap.sh * echo "using boostbook ;" > user-config-doc.jam * ./b2 -j32 -q -d2 --ignore-site-config --enable-index --user-config=user-config-doc.jam --build-dir=build-doc * ./b2 -j32 -q -d2 --ignore-site-config --enable-index --user-config=user-config-doc.jam --build-dir=build-doc doc On my Debian unstable system this works when xsltproc and libxslt1.1 version 1.1.34 are installed, but fails when 1.1.35 is installed, with the following error: "xsltproc" --stringparam boost.defaults "Boost" --stringparam boost.root "../../../.." --path "build-doc/boost/bin.v2/libs/logic/doc/docbook" --xinclude -o "build-doc/boost/bin.v2/libs/logic/doc/docbook/tribool.docbook" "/<<PKGBUILDDIR>>/tools/boostbook/xsl/docbook.xsl" "/<<PKGBUILDDIR>>/libs/logic/doc/tribool.boostbook" runtime error: file /<<PKGBUILDDIR>>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName. runtime error: file /<<PKGBUILDDIR>>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName.runtime error: file /<<PKGBUILDDIR>>/tools/boostbook/xsl/annotation.xsl line 432 element element xsl:element: The effective name '' is not a valid QName. [repeated many times] Many different libraries are failing in the same way, so I guess that the real problem is in boostbook. However I don't know enough of XSLT and xsltproc to give a proper diagnosis. For the context, this bug was discovered during a test rebuild of the Debian package for Boost[1]. However it can be reproduced with master doing the steps above. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016321 Thanks in advance for any help you can provide, Giovanni.

1 0

Superproject is taking a nap
by Vinnie Falco 12 Aug '22

12 Aug '22

The Boost superproject is not updating submodules on master, that switch needs to be flipped back on if Boost.URL is going to work. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

2 1

Questions about incorporating my library into a new library within Boost
by Jooseong Lee 11 Aug '22

11 Aug '22

I recently wrote a general-purpose STL-like ordered associative B-Tree based container in C++. . Its API and usage is very similar to std::set, std::map, std::multiset, std::multimap, and when the number of elements is relatively large, my benchmark shows that it is 2.5~3 times faster than std::set and its friends. Repo link: https://github.com/frozenca/BTree This was better than I thought, so I'd like to contribute to the Boost community by incorporating it within the list of Boost libraries. I'd like to know if it's possible or if you think it's worth it. Best Regards, Jooseong Lee

5 16

beep sound from buzzer
by Daggumati, Rajesh 11 Aug '22

11 Aug '22

Hi Team, I am working on an instrument which is not having any speaker. It is having buzzer only. We use C++ BEEP() function to generate beep sound by using provided frequency number. Ex: Beep(1000,1000); This function is producing sound but its not audible as we don't have speakers. Can we have any specific function in boost so if we call that function then it will interact with buzzer and give sound . Regards, Rajesh D Confidential - Company Proprietary Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

1 0

Master is open for merges
by Glen Fernandes 11 Aug '22

11 Aug '22

Master is open again, with no restrictions. Boost version numbers bumped (boost, config, more), and new release notes stubbed (website). Next milestone: October 26, Boost 1.81.0 closed for new libraries and breaking changes Release calendar: https://boost.org/development Glen

1 0

[release] Boost 1.80.0
by Glen Fernandes 11 Aug '22

11 Aug '22

Release 1.80.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.80.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.80.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes, Michael Caisse

1 0

[release] Boost 1.80.0 Release Candidate 1 is available
by Marshall Clow 09 Aug '22

09 Aug '22

The first release candidates for the 1.80.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.80.0/source/> The SHA256 checksums are as follows: 4b2136f98bdd1f5857f1c3dea9ac2018effe65286cf251534b6ae20cc45e1847 boost_1_80_0_rc1.tar.gz 1e19565d82e43bc59209a168f5ac899d3ba471d55c7610c677d4ccf2c9c500c0 boost_1_80_0_rc1.tar.bz2 d12a2af721e22dbfb984ef061ee4c4ab2387f1904f6d65bc5acebaa34d6366ec boost_1_80_0_rc1.7z e34756f63abe8ac34b35352743f17d061fcc825969a2dd8458264edb38781782 boost_1_80_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

3 9

[review][JSON] Review of JSON starts today: Sept 14 - Sept 23
by Pranam Lashkari 09 Aug '22

09 Aug '22

Boost formal review of Vinnie Falco and Krystian Stasiowski's library JSON starts today and will run for 10 days ending on 23 Sept 2020. Both of these authors have already developed a couple of libraries which are accepted in Boost(boost beast and Static String) This library focuses on a common and popular use-case for JSON. It provides a container to hold parsed and serialised JSON types. It provides more flexibility and better benchmark performance than its competitors. JSON highlights the following features in the documentation: - Fast compilation - Require only C++11 - Fast streaming parser and serializer - Easy and safe API with allocator support - Constant-time key lookup for objects - Options to allow non-standard JSON - Compile without Boost, define BOOST_JSON_STANDALONE - Optional header-only, without linking to a library (a point I would like to add in highlight: it has cool Jason logo 😝) To quickly understand and get the flavour of the library take a look at "Quick Look" <http://master.json.cpp.al/json/usage/quick_look.html> You can find the source code to be reviewed here: <https://github.com/CPPAlliance/json/tree/master> You can find the latest documentation here: <http://master.json.cpp.al/> Benchmarks are also given in the document which can be found here: <http://master.json.cpp.al/json/benchmarks.html> Some people have also given the early reviews, the thread can be found here: <https://lists.boost.org/Archives/boost/2020/09/249745.php> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including JSON as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

21 73

Potentially include xproc library in boost?
by Samuel Venable 08 Aug '22

08 Aug '22

Hi, I've tried sending an email about this already and no one responded from what I can tell. I guess because I was saying way too much. I was wondering if this code of mine could potentially be added to boost. xproc/process.cpp at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp> It lets you get process information from foreign processes on a lot of platforms. Thanks. Samuel [https://opengraph.githubassets.com/b27d922324c973dacc517314510a40f1739ffa17…]<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp> xproc/process.cpp at main · time-killer-games/xproc<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp> Contribute to time-killer-games/xproc development by creating an account on GitHub. github.com

3 3

Upcoming Boost.URL review
by Klemens Morgenstern 06 Aug '22

06 Aug '22

This is a reminder that the boost.url review will start in a week on the 13th. The source code can be found here https://github.com/CPPAlliance/url and the documentation here https://master.url.cpp.al/ . I am looking forward to plenty of reviews.

4 3

Boost 1.80.0 closed for all changes
by Glen Fernandes 04 Aug '22

04 Aug '22

The master branch is closed for all changes. Release expected on 2022-08-10. - Release Managers

1 0

Boost 1.80.0 master open for bug fixes
by Glen Fernandes 03 Aug '22

03 Aug '22

Now open for bug fixes and documentation changes. Other changes by release manager permission. The next deadline: On August 3rd, master closes for all changes. Glen

6 10

Binary Serialization
by Benedict Bede McNamara 02 Aug '22

02 Aug '22

It appears that the main fact determining collection build speed is the heap you use. I++ now uses its own binary heap to perform allocations for the collection forward_list (which is what oarchive uses). So binary serialization goes even faster now. Here are some figures for collections with a million elements: stl list build time is: 0:0:0:0:27 stl list sort time is: 0:0:0:0:21 stl forward_list build time is: 0:0:0:0:20 stl forward_list sort time is: 0:0:0:0:20 stl set build time is: 0:0:0:0:111 I++ set build time is: 0:0:0:0:61 stl unordered_set build time is: 0:0:0:0:149 stl map build time is: 0:0:0:0:118 I++ dictionary build time is: 0:0:0:0:60 Linked list build time is: 0:0:0:0:23 Linked list sort time is: 0:0:0:0:23 Forward list build time is: 0:0:0:0:16 Forward list sort time is: 0:0:0:0:17 I++ serialization/deserialization time is: 0:0:0:0:150 list build time is: 0:0:0:0:74 stl vector build time is: 0:0:0:0:5 Vector sort time is: 0:0:0:0:12 Quick Sort time is: 0:0:0:0:10 heap allocations: 12000007 heap allocations: 0 >From this we see that in general binary serialization/deserialization takes a bit longer than collection allocation. For example the serialization/deserialization time is 150 milliseconds for a million elements whereas forward_list only takes 16 milliseconds to build. I would be interested to see what the equivalent figures are for Boosts text based serialization. Yours Sincerely, Benedict Bede McNamara P.S. The program that produced these figures is attached. Sent from Mail for Windows

1 0

Why was the boostorg/sort master branch deleted
by Glen Fernandes 02 Aug '22

02 Aug '22

Why was the boostorg/sort master branch deleted? The repository has only a develop branch now. I'm going to recreate the master branch and reset its head to before the recent commits, but - I'd like to know why the branch was removed. Glen

3 2

Re: [boost] Boost Digest, Vol 6764, Issue 1
by Benedict Bede McNamara 29 Jul '22

29 Jul '22

I++ Binary Serialization I++ binary serialization just got twice as fast by using linked lists rather than binary trees as before. Sent from Mail for Windows From: boost-request(a)lists.boost.org Sent: Friday, 29 July 2022 10:00 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6764, Issue 1 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: Questions about incorporating my library into a new library within Boost (Phil Endecott) 2. Re: Questions about incorporating my library into a new library within Boost (Jooseong Lee) ---------------------------------------------------------------------- Message: 1 Date: Thu, 28 Jul 2022 13:57:50 +0100 From: "Phil Endecott" <spam_from_boost_dev(a)chezphil.org> To: <boost(a)lists.boost.org> Subject: Re: [boost] Questions about incorporating my library into a new library within Boost Message-ID: <1659013070554(a)dmwebmail.dmwebmail.chezphil.org> Content-Type: text/plain; format="flowed"; charset="UTF-8" Jooseong Lee wrote: >> What is not stored contiguously is child, this is stored in >> std::vector<std::unique_ptr>. >> But when N keys are erased, the number of children erased is not O(N), >> because a node can have #(fanout) keys. > > I have to correct this sentence, the number of children erased is O(N). > But the coefficient is small, because practically B-Trees use large fanouts. > > Most technically, a call for erase_range(a, b) would be O(log N) + O(K) > where N is the number of whole keys and K is the number of keys being > erased. > I've updated the repo description, thanks for the catch. Good, I'm glad I don't have to give the CS101 complexity lecture :-) One other comment - how do you deal with strings? To get the locality benefits of the B-Tree you can't store variable-size data totally out-of-band. Regarding the general "how do I get this in Boost?" question, I encourage you to look back through the mailing list archive at the last few "Is Boost interested in my XYZ libary?" threads. Some people post useful replies about what to do next which. Cynically, what happens most often is that there are one or two emails and then the library author and any replies disappear. Some persistence is required to make anything happen. One hint: put something more descriptive (i.e. "B-Tree") in your subject line! Regards, Phil. ------------------------------ Message: 2 Date: Thu, 28 Jul 2022 22:18:33 +0900 From: Jooseong Lee <frozenca91(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] Questions about incorporating my library into a new library within Boost Message-ID: <CAPPJyCuKa8mRMzhKhwaVWXbyuECQDVjXCs_m8kcM_EtDz8dZvg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" > One other comment - how do you deal with strings? To get the locality > benefits of the B-Tree you can't store variable-size data totally out-of-band. For std::string and its friends (i.e. not trivially copyable types) it is stored as something like std::vector<std::string>, so it is not *that* good (but still better than std::set<std::string>). Google Abseil's B-Tree implementation use similar approach. When I personally use my B-Tree for strings, I use raw char arrays like std::array<char, 16> > Regarding the general "how do I get this in Boost?" question, I > encourage you to look back through the mailing list archive at the > last few "Is Boost interested in my XYZ libary?" threads. Thanks, I'll have a look. Best, Jooseong On Thu, Jul 28, 2022, 9:58 PM Phil Endecott via Boost <boost(a)lists.boost.org> wrote: > Jooseong Lee wrote: > >> What is not stored contiguously is child, this is stored in > >> std::vector<std::unique_ptr>. > >> But when N keys are erased, the number of children erased is not O(N), > >> because a node can have #(fanout) keys. > > > > I have to correct this sentence, the number of children erased is O(N). > > But the coefficient is small, because practically B-Trees use large > fanouts. > > > > Most technically, a call for erase_range(a, b) would be O(log N) + O(K) > > where N is the number of whole keys and K is the number of keys being > > erased. > > I've updated the repo description, thanks for the catch. > > Good, I'm glad I don't have to give the CS101 complexity lecture :-) > > One other comment - how do you deal with strings? To get the locality > benefits of the B-Tree you can't store variable-size data totally > out-of-band. > > Regarding the general "how do I get this in Boost?" question, I > encourage you to look back through the mailing list archive at the > last few "Is Boost interested in my XYZ libary?" threads. Some people > post useful replies about what to do next which. Cynically, what > happens most often is that there are one or two emails and then > the library author and any replies disappear. Some persistence is > required to make anything happen. One hint: put something more > descriptive (i.e. "B-Tree") in your subject line! > > > Regards, Phil. > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6764, Issue 1 **************************************

1 0

Is there any interest in a library that solves genetic simulations?
by Arnaud Becheler 27 Jul '22

27 Jul '22

Hi, I am Arnaud, software engineer in genetics, always eager to learn more about C++! Happy to be on this mailing list :) Is there any interest in a library that solves genetic simulations? A proof of concept library that focuses on a particular simulation framework (spatial coalescence) can be found here: https://github.com/Quetzal-framework/quetzal-CoaTL It lacks many basics including genetic code, mutations, sequences, recombination etc. Such algorithms and data structures are constantly re-implemented in the scientific community, and providing a generic implementation could help significantly. Best, Arnaud Becheler

1 0

C++11 or C++14?
by Vinnie Falco 25 Jul '22

25 Jul '22

I'm considering bumping up the C++ language requirement for Boost.URL from C++11 to C++14. I have concerns about doing this, because it affects all my downstream libraries (HTTP.Proto, HTTP.IO, Websocket.Proto, Websocket.IO, and any examples or complete clients/servers that I write). My main fear is that there are still a considerable number of individuals or corporations who, for whatever reason, cannot build with -std=c++14 or later despite having access to newer compilers. I don't mind if there is a small percentage of loss but I do mind if 20% or more of potential users will be locked out. The questions are: 1. Would you or your company be prevented from using Boost.URL if it required C++14? 2. Do you know any other organizations who cannot use C++14 or later? 3. Do you know of any regional or global metrics on who _cannot_ use libraries which require C++14? See also, this reddit thread on r/cpp: <https://www.reddit.com/r/cpp/comments/w6zuo5/c11_or_require_c14/> -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

2 1

xproc: get process information from foreign processes
by Samuel Venable 20 Jul '22

20 Jul '22

Hi all. The main developer of the boost process library liked what he saw when I showed him my xproc API. He recommended me to send it to the boost mailing list and see what the other developers at boost think of it and whether it could be modified and adjusted into making it worthy of becoming an official part of the boost libraries. The Windows build currently only works with MSYS2/MinGW, see the open issue here for the full details on what works and what doesn't on the Windows platform and why: currently known Windows-related bugs · Issue #1 · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/issues/1> The build.sh to build and example.sh to test is all you need to test all features, the only thing that isn't verified by the scripts is whether any memory leaks exist, and afaik in my testing Windows might be the only platform whith memory leaks, but its very unclear to me how to debug the source of them, because the code looks very correct, as I'm freeing memory everywhere online Microsoft documentation tells me to. Also supports Mac, Linux, FreeBSD, DragonFly BSD, NetBSD, and OpenBSD. If I ever find hardware that will work with an Illumos-based Operating System, then that will be added to the mix, (I refuse to use a VM, my personal hang-up). If the libprocps library the linux version depends on were ported to Android, that is another potential platform, but the "Enable Windowing Macro" will need to not be defined as that is more of a desktop-related thing. iOS can work with windowing disabled as well, but some sysctl() with KERN_PROCARGS2 may only work when running in developer/debug mode due to Apple's publishing restrictions. Linux and android are the only platforms with the third party library dependency. All other platforms only rely on dependencies already provided by the OS base and/or kernel. Here's everything you need for the API to work on most platforms, source & header... * xproc/process.cpp at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.cpp> * xproc/process.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process.h> And only on Windows you will need these helper blobs generated by the build script... * xproc/process32.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process32.h> * xproc/process64.h at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/apiprocess/process64.h> Here's an example of how to use the library and repository source tree... * xproc/main.cpp at main · time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc/blob/main/main.cpp> * time-killer-games/xproc (github.com)<https://github.com/time-killer-games/xproc> * You guys have my permission to relicense this code under any version of the Boost license we can agree on if this work gets accepted at any point in time. All functions get process information in their current state at the time the functions are called expect on macOS KERN_PROCARGS2 gets the cmdline and environ of the process in its initial state when the process first launched, so if the cmdline or environ get modified after initialization or process lanch, you will have no way to get the updated values (OS-level limitation of macOS). Lastly, I have helper functions to optionally suspend and resume foreign processes to avoid race conditions where applicable. Let me know what you think and if you have any critiques or questions regarding my code do not hesitate to address that with me in a reply to this email! Thanks! Samuel

1 0

[Spirit] '_' parsed as '\0' with qi::phrase_parse
by Olaf van der Spek 19 Jul '22

19 Jul '22

Hi, The underscore is parsed as a null character. Is this expected. A bug? If a full repro is needed I can create one. qi::rule<iterator_t, std::string(), Skip> identifier; identifier %= lexeme[alpha >> *(alnum | '.' | '_')]; typedef boost::spirit::classic::position_iterator<const char*> iterator_t; std::string s = "a_b blah"; iterator_t is(s.c_str(), s.c_str() + s.size(), "<name>"); std::string out; bool res = qi::phrase_parse(is, iterator_t(), identifier, skip, out); if (!res && is != iterator_t()) error_handler_::err(is); cout << out.size() << "|" << out << "|\n"; cout << int(out[0]) << " " << int(out[1]) << " " << int(out[2]) << "\n"; Output: // 3|ab| // 97 0 98 Greetings, -- Olaf

2 2

[release] Boost 1.80.0 beta 1 released
by Glen Fernandes 14 Jul '22

14 Jul '22

Boost release 1.80.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.80.0.beta1/source/ The SHA256 checksums are: boost_1_80_0_b1.tar.bz2 - b29191c1bd4504511f9b1155c6f79f06cc7044444780392ed7358f5778ac7d16 boost_1_80_0_b1.tar.gz - ad3df9f63acd667dcf13375fa0e90e7303f851251e91d1505974bdbbf1f94907 boost_1_80_0_b1.7z - 7bfdf705b1d058c3525be90ed5cb47aacf919cd74aa7d5752d55e78aa60880ba boost_1_80_0_b1.zip - 1b509ed848f153086984658d4d4a57af6230f496a53bf88aba805bb49039012d Release notes (still need updates): https://www.boost.org/users/history/version_1_80_0.html Please try the beta and report any problems you encounter. Thanks, -- Boost Release Team

5 10

[release] Boost 1.80.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 14 Jul '22

14 Jul '22

Available at: <https://boostorg.jfrog.io/ui/native/main/beta/1.80.0.beta1/source> The SHA256 checksums are as follows: b29191c1bd4504511f9b1155c6f79f06cc7044444780392ed7358f5778ac7d16 boost_1_80_0_b1.tar.bz2 7bfdf705b1d058c3525be90ed5cb47aacf919cd74aa7d5752d55e78aa60880ba boost_1_80_0_b1.7z ad3df9f63acd667dcf13375fa0e90e7303f851251e91d1505974bdbbf1f94907 boost_1_80_0_b1.tar.gz 1b509ed848f153086984658d4d4a57af6230f496a53bf88aba805bb49039012d boost_1_80_0_b1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers

5 6

[Graph] Can users on Xcode 7-10 help out?
by Jeremy Murphy 12 Jul '22

12 Jul '22

Dear Boost.Graph users, Is anyone that uses old Xcode 7-10 able to help out with some curious compilation errors? https://github.com/boostorg/graph/issues/298 We'll do our best to fix them but I assume it might be easier for someone that actually uses these particular platforms. Thanks, cheers. Jeremy

1 0

static_string
by Gero Peterhoff 10 Jul '22

10 Jul '22

Hello, if i include <boost/static_string.hpp> i get errors in std::variant: /usr/include/c++/12/variant:774:72: Fehler: Templateargument 4 ist ungültig 774 | void_t<decltype(_Arr<_Ti>{{std::declval<_Tp>()}})>> | ^~ /usr/include/c++/12/variant:804:76: Fehler: Templateargument 3 ist ungültig 804 | struct __accepted_index<_Tp, _Variant, void_t<_FUN_type<_Tp, _Variant>>> | ^ Can you retrace that? boost 1.79 gcc 12.1 -std=gnu++2b openSuse Tumbleweed thx Gero

3 2

[process] Process.Spawn leaves the child in zombie state on posix
by Benedek Tass 08 Jul '22

08 Jul '22

Hi, everyone! This bug was observed in 2022.07.05, using boost version 1.79.0. Similar behaviour was commented on before on online messageboards. Bug description When starting a new, detached process with Process.Spawn in a posix system, if the parent process outlives the child, the child process remains in zombie state for the parent process' lifetime. The bug described above is demonstrated in the CMake project attached to this document. Analysis The spawn function injects the syscall "signal(SIGCHLD, SIG_IGN)" with a functor of type boost::process::detail::posix::sig_init_. This is done to the forked child process, to no avail. And this is not done (and should not be done) in the parent process being too intrusive. Possible mitigation Introducing an in-between forked process that serves as the parent of the to-be-spawned process with SIGCHLD set to SIG_IGN would prevent the spawned process to become zombie, and simultaneously does not disturb the parent process' signal handlers. Introducing another class alternative to sig_init_ with the functionality described above would be a reasonable approach. An implementation sketch of the double fork method can be found in the attached project. System used OS: Ubuntu 18.04.6 LTS arch: x86_64 compiler: gcc-7.5.0 libc: libc-2.27 boost: 1.79.0 (built from source) Best regards, Benedek Tass

3 6

Boost 1.80.0 closed for beta
by Glen Fernandes 07 Jul '22

07 Jul '22

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

2 1

Boost 1.80 closed for all major changes
by Glen Fernandes 05 Jul '22

05 Jul '22

The next deadlines: - On 2022-07-06 master is closed for all changes. - On 2022-07-13 the beta is published -- Release Managers

3 6

Re: [boost] [Boost-users] Boost.URL review planned for 13-22 August 2022
by Vinnie Falco 29 Jun '22

29 Jun '22

On Fri, Jun 24, 2022 at 2:15 AM Mateusz Loskot via Boost-users <boost-users(a)lists.boost.org> wrote: > we have planned the review shortly after the upcoming release of the Boost 1.80. The review starts in August but there is no rule that says folks can't look at the library sooner :) The library is in very good shape and likely usable for your project today (although we do expect bugs to be found, which will be fixed as they get reported). Check it out here: <https://github.com/CPPAlliance/url> Docs: <https://master.url.cpp.al/> We're glad to answer any questions at any time either on the list or feel free to open an issue in the repository (even if it is just a question). Thanks

2 1

Boost Regression Results Not Updating
by Tom Kent 25 Jun '22

25 Jun '22

I just noticed that something happened with the regression results and they haven't updated since last Friday. https://www.boost.org/development/tests/master/developer/summary.html https://www.boost.org/development/tests/develop/developer/summary.html I'm not sure where these run these days, would it fit in a github action on the regression repo? Tom

3 3

Possible develop config issue on arm32
by Tom Kent 25 Jun '22

25 Jun '22

I have a regression runner running on raspberry pi 32-bit architecture (in addition to a one on 64-bit raspberry pi and tons of X86). gcc-8 builds fine in both master and develop clang-9 builds fine on master clang-9 running the same command line, just on develop, has errors like this [1], finding basic includes: ``` "clang++-9" -c -x c++ -Wno-c99-extensions -std=c++2a -O0 -fno-inline -Wall -g --target=arm-pc-linux -Wno-deprecated-declarations -DBOOST_ALL_NO_LIB=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/mnt/fs1/teeks99-05/run/results/boost/bin.v2/libs/accumulators/test/count.test/clang-linux-9~c++2a/debug/link-static/count.o" "../libs/accumulators/test/count.cpp" clang: warning: unknown platform, assuming -mfloat-abi=soft clang: warning: unknown platform, assuming -mfloat-abi=soft In file included from ../libs/accumulators/test/count.cpp:6: In file included from ../boost/test/unit_test.hpp:18: In file included from ../boost/test/test_tools.hpp:17: In file included from ../boost/config.hpp:44: ../boost/config/detail/select_stdlib_config.hpp:26:14: fatal error: 'cstddef' file not found # include <cstddef> ^~~~~~~~~ 1 error generated. ``` The relevant line of the user-config.jam is: using clang : 9~c++2a : clang++-9 : <cxxflags>"-Wno-c99-extensions -std=c++2a" ; The two command lines being run are: run.py --runner=teeks99-05-mc9-2a-32onarmv7l --toolsets=clang-9~c++2a \ "--bjam-options=-j4 address-model=32 --remove-test-targets" \ --comment=info.html --tag=master run.py --runner=teeks99-05-dc9-2a-32onarmv7l --toolsets=clang-9~c++2a \ "--bjam-options=-j4 address-model=32 --remove-test-targets" \ --comment=info.html --tag=develop Any ideas why master and develop would be different in this regard? Something with B2 changes? Thanks, Tom [1] https://www.boost.org/development/tests/develop/developer/output/teeks99-05…

3 2

Boost.URL review
by Klemens Morgenstern 24 Jun '22

24 Jun '22

Hi guys, I would like to volunteer as review manager for boost.url. Who can guide me through the process? Best regards, Klemens

2 2

Boost 1.80 closed for new libraries and breaking changes
by Glen Fernandes 23 Jun '22

23 Jun '22

Next deadline: On 2022-06-29 closed for all major code changes. See https://www.boost.org/development/index.html for the full calendar. -- Release Managers

1 0

Delayed response for sleep function
by Daggumati, Rajesh 21 Jun '22

21 Jun '22

Hi Team, When I use boost sleep function, I am getting delayed response. How to overcome this issue. Is there any alternative for this? boost::posix_time::ptime t1 = boost::posix_time::microsec_clock::local_time(); boost::this_thread::sleep(boost::posix_time::millisec(10000)); boost::posix_time::ptime t2 = boost::posix_time::microsec_clock::local_time(); boost::this_thread::sleep(boost::posix_time::millisec(10000)); boost::posix_time::ptime t3 = boost::posix_time::microsec_clock::local_time(); boost::posix_time::time_duration diff = t2 - t1; std::cout << diff.total_milliseconds() << std::endl; boost::posix_time::time_duration diff1 = t3 - t2; std::cout << diff1.total_milliseconds() << std::endl; output is : 10005 10006 Expected ouput should be 10000 and 10000 Regards, Rajesh D Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

6 8

Re: [boost] Delayed response for sleep function
by William Linkmeyer 21 Jun '22

21 Jun '22

This is interesting and helpful — yes! Although, it sounds like it’s more pertinent to software timers, right? I’ve done some work with hardware RTCs, many of which drift by 4ms/day, others by a few ms/year. (For physical quartz clocks, drift is a function of temperature and crystal frequency.) I had assumed that these clocks were more-or-less ubiquitous on computers today. Anyway, best regards and thank you for your detailed response. WL > On Jun 21, 2022, at 4:12 AM, Neil Groves <neilgroves(a)gmail.com> wrote: >

2 2

Re: [boost] [Boost-users] Boost Twitter is Blowing Up!!!
by Vinnie Falco 21 Jun '22

21 Jun '22

On Mon, Jun 20, 2022 at 7:48 PM 😉 Good Guy 😉 via Boost-users <boost-users(a)lists.boost.org> wrote: > The problem with Twitter is that it requires an account to read the posts. Yeah, so... my assumption when I made this post is that most folks have a Twitter account. I see that is not the case, even for long-time Boost authors. If you don't already have a Twitter account, there is not going to be much benefit to creating one just to like, follow, and retweet the Boost account, as you will have no followers and thus no reach. Although you might consider creating an account if you want to become more involved in C++ Twitter in general. That said, Twitter and the other socials might not be important to the senior engineers, authors, and maintainers here but collectively, Boost needs to catch up in terms of courting the younger generations of developers. We need fresh blood for library submissions, reviewers, and review managers. Our efforts on social media are aligned with this goal. Thanks

2 3

[JSON] Vote for Boost.JSON in this poll!
by Vinnie Falco 21 Jun '22

21 Jun '22

There's an online poll asking about which JSON library you use. If you use Boost.JSON consider voting for it: <https://meetingcpp.com/mcpp/survey/?q=2> Also, consider voting for it if you _don't_ use Boost.JSON, but you want to. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Boost Twitter is Blowing Up!!!
by Vinnie Falco 21 Jun '22

21 Jun '22

Greetings fellow users, library authors, maintainers, review wizards, release wizards, and Boost Foundation Board members! As part of our ongoing effort to continue the revitalization of Boost, a handful of us have taken the reins to post about Boost on social media. We have postings on Reddit and Hacker news, blog posts about the new efforts in Boost.Unordered, and new tweets. However, we could use your help! Right now the Boost Twitter account has a measly 957 followers. It would be great to increase our reach, so I'm asking everyone if they could be so kind as to Follow the official Boost Twitter account here: <https://twitter.com/Boost_Libraries> and then amplify our messages by Liking and Retweeting. Starting with this pinned tweet, which everyone will see when they visit the Boost Libraries Twittter profile page: <https://twitter.com/Boost_Libraries/status/1539003321939202048> Following the Boost Twitter account will give you up-to-date information about what is going on with Boost, including articles and mentions on other social media sites. Here is what we have so far: <https://www.reddit.com/r/cpp/comments/vfdcrz/advancing_the_state_of_the_art…> <https://www.reddit.com/r/cpp/comments/vbdr3z/new_boostunordered_containers_…> <https://twitter.com/hackernewstop10/status/1538622706035343364> <https://news.ycombinator.com/item?id=31801814> To summarize, engaging with Boost related content on social media will enhance our profile - any help is appreciated! -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

2 1

[thread] upgrade_to_unique_lock takes a upgrade_lock, not an upgrade_mutex
by Phil Endecott 20 Jun '22

20 Jun '22

Dear Experts, boost::upgrade_mutex m; void f() { boost::upgrade_lock l(m); // read shared state g(); } void g() { // precondition: upgrade lock held. boost::upgrade_to_unique_lock l(m); // write shared state } But that's not how it works. The upgrade_to_unique_lock takes the upgrade_lock as its ctor parameter, not the mutex. Is there a good reason for that? I think all that upgrade_to_unique_lock needs to do is to call m.unlock_upgrade_and_lock() in its ctor and m.unlock_and_lock_upgrade() in its dotr, i.e. it doesn't need to access any state in the upgrade_lock. Am I missing something? Regards, Phil.

3 4

multiprecision/gmp.hpp
by Gero Peterhoff 17 Jun '22

17 Jun '22

Hello John, if i include boost::cstdint/float.hpp AND boost::multiprecision::gmp.hpp gets errors in boost::multiprecision::detail::float128_functions.hpp. With the attached patch it works, although I have no idea why this is needed. regards Gero

2 1

[Boost] [Review] [Boost.MySQL] - Review Complete
by Richard Hodges 16 Jun '22

16 Jun '22

Dear All, The submission of Boost.MySQL has created plenty of "lively debate". Unsurprisingly, a library which is based on Asio, of which there are few experts, has given rise to a great deal of questioning around performance, memory re-use, correct return types and so on. It has been noted that Reuben, the library's author, has been very responsive. Both in this mailing list and in terms of raising PRs. A specific concern was raised about the name of the library, and whether it infringed any commercial trade marks. Reuben took the trouble to reach out to Oracle to check. They have responded that there is no infringement and we may use the name. In the end though, despite a great deal of words written raising concerns, ideas and suggestions, we received size reviews, all of which were high quality. The results were: Accept: 3 Conditional Accept: 2 Reject: 1 Having carefully weighed up: - The stated aims of the library - The quality of the implementation - The demonstrated responsiveness of the author - The value of the library to users of MySQL - The value of the library as a teaching tool for implementing a complex, cancellable, asynchronous protocol on ASIO, which correctly adapts to the use of user-selection completion tokens, It seems right to ACCEPT this library into Boost. My congratulations to Reuben. -- Richard Hodges hodges.r(a)gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212

5 5

The deadline for new libraries and breaking changes in Boost 1.80.0 is June 22
by Glen Fernandes 16 Jun '22

16 Jun '22

2022-06-22 closed for new libraries and breaking changes in Boost 1.80. See https://www.boost.org/development/index.html for the full calendar. - The Release Managers

1 0

Boost.MySQL naming
by Ruben Perez 14 Jun '22

14 Jun '22

Hi all, We have received an answer from Oracle's legal team, thanks to Norvald, who initially wrote in this ML and works for Oracle. TL;DR: Boost.MySQL keeps its name. > Naming the library as proposed (Boost.MySQL) is not a problem for a > community connector to MySQL. This is consistent with other naming we > see in the MySQL community and in our experience it has not caused > confusion. We would be concerned about any naming or statements that > suggest an inaccurate association between your library or product and > MySQL, but that does not appear to be the case. So I'm afraid we won't be having Boost.OurSQL anytime soon. Regards, Ruben.

1 0

[container] Contributing 'stationary_vector' to Boost
by Mehrdad Niknami 13 Jun '22

13 Jun '22

Hi all, Happy new year! New mailing list member here. I've developed an STL-style stationary_vector class that retains elements in-place when growing. Very briefly, it is effectively a piecewise-contiguous vector, with the following advantages over vector: - Appending has O(1) overhead in the *worst* case (e.g., push_back() does not move elements) - Insertion and random-access can be done in parallel, as prior iterators & references remain valid This has a variety of benefits, including better UX (no "hiccups" due to reallocations), and the ability to simplify parallel processing of streaming data. It occurred to me the larger C++ community might find this useful. I was wondering if there would be interest in incorporating it into Boost.Container, and if so, what steps I could take to make that happen? I'm of course happy to discuss the design etc. with anyone who might be interested. Summary: https://github.com/mehrdadn/libvital/blob/master/doc/vital/container/statio… Implementation: https://github.com/mehrdadn/libvital/blob/master/include/vital/container/st… Thank you, Mehrdad

7 19

Boost.URL -- some notes
by Andrzej Krzemienski 11 Jun '22

11 Jun '22

Hi Everyone, I am trying to do a review of Boost.URI library (I usually find the official ten-day review period to be too short), and there are a number of interesting things I came across that I thought I would mention. The docs say: > The library requires Boost and a compiler supporting at least C++11. > Even though the library is a candidate for a Boost library, I understand that it is now offered as a "stand alone" version, and this is what the docs describe. I tried to use it with the latest MinGW Distro on Windows ( https://nuwen.net/mingw.html) which uses GCC 11.2 and Boost 1.77. Without success. This is because Boost.URL relies on the component boost::system::result<T>, which is present in Boost.System only since version 1.78: https://www.boost.org/doc/libs/1_79_0/libs/system/doc/html/system.html#chan… First, this is news to me that we have `result<T>` in Boost.System, which has an overlap with result<T, E> from Boost.Outcome. Second, I recommend that Boost.URL docs say that it requires Boost 1.78 or higher. Next, we read: Aliases for standard types, such as string_view > <https://master.url.cpp.al/url/ref/boost__urls__string_view.html>, use > their Boost equivalents. > After reading this, I expected that Boost.URL would use boost::string_view from Boost.Utility library: https://www.boost.org/doc/libs/1_79_0/libs/utility/doc/html/utility/utiliti… But instead, it uses boost::core::string_view, which is an implementation detail from Boost.Core library: https://github.com/CPPAlliance/url/blob/master/include/boost/url/string_vie… Again, this is news for me that Boost has two implementations of string_view. Why? Second, I do not think that Boost.URL should rely on the implementation details of Boost.Core. A better alternative would be to use the official boost::string_view from Boost.Utility. Or is there a good reason not to? Next, the section on the parsers ( https://master.url.cpp.al/url/parsing/url.html) describes the function parse_uri() which returns result<url_view>. What strikes me is this difference: URI (Identifier) in the function name, and URL (Locator) in the return type. I always used the terms URL and URI interchangeably. But now that I see them used in this way in a well designed library, it looks disturbing. The quoted rfc3986 ( https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3) says that an URL is a subset of URI. Now, the name `parse_uri` implies that it will recognize any URI, but on the other hand it is impossible that the result will fit into a url_view, because not every URI is an URL. The synopsis for parse_uri ( https://master.url.cpp.al/url/ref/boost__urls__parse_uri.html) says: Exception safety: throws nothing. > And the line below it says that the function throws std::length_error when the input is too long. It looks like a bug in specs. Later we read: Return value: A result containing the view to the URL, or an error code if > the parsing was unsuccessful. > Which is not precise enough to give me the answer to the URI-vs-URL question. When can a parsing be non-successful? Is it only because it was not conformant to the grammar? The synopsis says "This function parses a string according to the URI grammar below", but is it a URI grammar or a URL grammar actually? Maybe the "return value" section should say instead: Return value: A result containing the view to the URL, or an error code if > the contents of `s` were not conformant with the above grammar. > That is, any other reason for not being successful (if any resources needed to be allocated and failed) may still be reported via exceptions. Now, there is probably a good explanation to the URI vs URL discrepancy. I think it would be good if it was placed in the docs, so that the users don't get confused. While this might look like a list of complaints, I really appreciate the efforts the authors put in creating this library and its documentation. The documentation is really high quality, way higher than the average you will find in GitHub. And this is actually because of this high quality that I am able to spot and report these issues. Regards, &rzej;

11 24

Any objections to making C++14 the current baseline for Boost support and testing?
by John Maddock 10 Jun '22

10 Jun '22

Pursuant of discussion elsewhere: Does anyone have any concrete objections to Boost moving to a C++14 baseline? This would mean: * Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases. * The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries. * CI tests no longer need report pre-C++14 results. * From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023. Thoughts? Thanks, John Maddock.

6 8

how to build boost 1.79 with "clang-cl" under Windows?
by Dennis Luehring 05 Jun '22

05 Jun '22

i've got a working LLVM 14.x/clang-cl installation (means working with cmake/ninja etc. with my non boost projects) and working boost builds for 32/64 bit with VS2017,2019,2022,mingw aka a "good working environment" for my boost projects i tried to use my VS2017 built libs by forcing the toolkit name with set(Boost_COMPILER "vc141") in my root CMakeLists.txt cmake -G Ninja -DCMAKE_C_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" -DCMAKE_CXX_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe" ../myproject that does not work for all linking (sometimes lld-link.exe complains about missing libboost_unit_test_framework-clangw14-mt-gd-x64-1_79.lib etc. (with the wrong "clangw14" in the name) im always using boosts own cmake configuration using the CONFIG parameter with cmakes find_package find_package(Boost CONFIG REQUIRED COMPONENTS unit_test_framework filesystem system) and i've checked that Boost_COMPILER is always "vc141" before find_package call do i miss something or does Boost_COMPILER does not work properly with boost own cmake config ? the other idea was to build boost directly with clang-cl in an VS2017 build environment inside my current boost build folder (where are the lib32-msvc-14.1, lib64-msvc-14.1 etc. b2 build folders resist) i tried to build with toolkit=clang without and beeing in a VS2017 build environment with C:\Program Files\LLVM\bin in my path using that b2 commandline for building b2 -j%NUMBER_OF_PROCESSORS% toolset=clang address-model=64 --stagedir=.\lib64-clang-14.0 --build-dir=.\__build --build-type=complete threading=multi architecture=x86 stage --with-date_time --with-graph --with-nowide --with-test --width-config --with-system --with-filesystem --with-serialization but that fails with linker errors (https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tool…) any tutorial how to force building boost with clang-cl instead of cl using the microsoft libraries etc. as usual? there is no clang-cl or clangw toolkit setting available to my understanding

2 5

Boost.Locale will require C++11
by Alexander Grund 03 Jun '22

03 Jun '22

Quick announcement: I'm planning on dropping C++98 support for Boost.Locale. I.e. require e.g. Rvalue references and std::unique_ptr to reduce maintenance effort. If anyone knows a reason to not do that please respond to https://github.com/boostorg/locale/issues/90 As per suggestion from Peter I'll add a warning for the upcoming release and will drop support in the next if there isn't anything in particular. Especially recent ICU headers already requiring C++11 is enough of a reason to not stick to the old stuff. Regards

1 0

Something has broken quickbook build
by John Maddock 03 Jun '22

03 Jun '22

I can't spot where, but something has changed in the last couple of days that has broken building quickbook: https://app.circleci.com/pipelines/github/boostorg/math/635/workflows/33cd9… ../../../boost/container_hash/hash.hpp:654:30: error: call of overloaded 'hash_value(const boost::filesystem::path&)' is ambiguous 654 | return hash_value( val ); | ~~~~~~~~~~^~~~~~~ ../../../boost/container_hash/hash.hpp:382:9: note: candidate: 'typename boost::enable_if_<((boost::hash_detail::is_range<T>::value && (! boost::hash_detail::is_contiguous_range<T>::value)) && (! boost::hash_detail::is_unordered_range<T>::value)), long unsigned int>::type boost::hash_value(const T&) [with T = boost::filesystem::path; typename boost::enable_if_<((boost::hash_detail::is_range<T>::value && (! boost::hash_detail::is_contiguous_range<T>::value)) && (! boost::hash_detail::is_unordered_range<T>::value)), long unsigned int>::type = long unsigned int]' 382 | hash_value( T const& v ) | ^~~~~~~~~~ In file included from /root/boost-local/boost/tools/quickbook/src/files.hpp:18, from /root/boost-local/boost/tools/quickbook/src/files.cpp:10: ../../../boost/filesystem/path.hpp:1183:82: note: candidate: 'typename boost::enable_if<boost::is_same<T, boost::filesystem::path>, long unsigned int>::type boost::filesystem::hash_value(const T&) [with T = boost::filesystem::path; typename boost::enable_if<boost::is_same<T, boost::filesystem::path>, long unsigned int>::type = long unsigned int]' 1183 | inline typename boost::enable_if< boost::is_same< T, path >, std::size_t >::type hash_value(T const& p) BOOST_NOEXCEPT In point of fact, those two overloads do look genuinely ambiguous to me, so I'm not sure why this compiled before, or what changed to make it fail now? Ideas? Thanks, John.

2 1

exception handling anti-patterns in documentation
by Andrzej Krzemienski 30 May '22

30 May '22

Hi Everyone, I wanted to share an observation. A number of Boost libraries, in documentation, when it comes to demonstrating that a given function throws an exception, has a code sample like the following: try { > lib::function(); > } > catch(lib::exception const&) { > // handle failure > } > This applies for instance to: * Boost.Lexical_cast: https://www.boost.org/doc/libs/1_79_0/doc/html/boost_lexical_cast/examples.… * Boost.Optional: https://www.boost.org/doc/libs/1_79_0/libs/optional/doc/html/boost_optional… * Boost.URL, waiting in the review queue: https://master.url.cpp.al/url/parsing/url.html What bothers me is that this is a very dangerous antipattern related to handling exceptions. If there is any benefit to be had from exceptions, it is that they separate the "positive" control flow form the "negative" (failure handling) one. Whereas in the examples like the one above it is quite the opposite: we are trying to catch the exception as soon as it is thrown. This is usually the cause of bugs and resource leaks. Such examples also lead many young programmers into thinking that exceptions are difficult or illogical. But they are not illogical: it is antipatterns like the one above that, which are working against the design of the exception handling mechanism, that confuse the programmers and enforce bad habits. One could say that the goal of the documentation is to demonstrate, in an efficient way, the interface of the library: not to teach how to program. But I would disagree. I have always considered Boost libraries to be more than that. I personally learned a lot about how to program, organize my code and organize my thinking about abstractions from reading the documentation of Boost libraries. Boost is a place to promote better programming practices. And these "catch immediately after throw and swallow" examples just do a disservice to the community. I would like to know if there are more people in this list that feel the same way. Maybe we could come up with a systematic way of demonstrating a throwing library interface, or guidelines for documentation authors. Regards, &rzej;

8 18

nullptr vs 0
by Peter Dimov 30 May '22

30 May '22

Compilers apparently are warning on the use of 0 as a null pointer constant, suggesting we use nullptr instead. But compilers don't know that we support C++03 where nullptr isn't a thing. Case in point: https://github.com/boostorg/throw_exception/pull/22 ifdef-ing every use of nullptr is unwieldy, so maybe we need BOOST_NULLPTR added to Boost.Config? That would expand to nullptr when it's supported, and 0 otherwise.

15 38

Re: [boost] Boost MySQL Review
by Ruben Perez 28 May '22

28 May '22

CC'ing the ML, as you just replied to me. On Sun, 22 May 2022 at 14:51, Seth <bugs(a)sehe.nl> wrote: > > Rubén, quick responses to your questions: > > >> TARGET_LINK_LIBRARIES(reviewtest Boost::mysql) > > > > This shouldn't be the case at all. The second line should be sufficient. > > Could you please open an issue against the repo and post your > > CMakeLists.txt, please? > > I think I understand what I did wrong/differently. I've filed the description as https://github.com/anarthal/mysql/issues/97 for potential improvement. I think there was an error in your link_libraries command, please have a look at the issue reply. I will leave the issue open to provide an example, though. > > > Implementing MySQL semantics implies the following: > > > > value("1") == value(1) // true > > value(1.0) == value(1) // true > > > > Which reminds me of the kind of patterns that have brought us > > pain in PHP and JS, and would prefer to avoid. Do you think > > "placing values in containers" is something that adds value? > > Obviously Mysql's type system is not something we want to embrace. In fact, my stance is that `mysql::value` should be for marshaling, not as a vocabulary type. As such, I do *not* think that general purpose support for "placing values in containers" adds value. > > Implementation-specific specialized containers like `mysql::row` can already handle the type appropriately. In fact I note that it does more harm than good because of the... surprising (some would say, broken) semantics. Again, for library internal use those are fine, but end-users should not get a false sense of "normalcy". > > Perhaps the library could document some utilities like `value_equal` or `value_hash` for explicit use. I'm reluctant to remove operator== and operator!=. I'd say their behavior matches the one for variants and can be useful. I see your point and I'm completely up to removing the other relational operators. > > >> > >> 3. The documentation claim "Values do not define `std::hash` yet, as > >> `boost::string_view` does not support it" is out of date. `hash_value` has > >> been added in 1.69.0 > > > > I can see a definition of hash_value, and from what I've read this makes > > it compatible with Boost containers, but the std::hash specializations are > > in a #ifdef 0 block. AFAIR std::hash doesn't use hash_value, and > > std::unordered_set<boost::string_view> fails to compile. The same > > applies for std::unordered_set<boost::mysql::value>. > > > Boost support is hash support, and it's trivial to `template <> struct std::hash<mysql::value> : boost::hash<mysql::value>` if desired. Missed that one. Thanks. Taking your comments into account, however, I'll likely won't provide it, though. > > >> 4. On that note, consider `boost::core::string_view` for better interop > >> ("lingua franca" string_view). If you're interested I just did an exhaustive > >> side-by-side comparison of features and observable behaviour` which I can > >> share. > > > > I wasn't aware of this class. Doing a quick grep in Beast, I've found it does > > use it, but it seems located in a detail/ folder > > (<boost/core/detail/string_view.hpp>). > > Could you please provide me with your comparison and any extra info I should > > be aware of? (BTW std::unordered_set<boost::core::string_view> doesn't compile > > either). > > My impact analysis consists of a suite of Very Ugly(TM) test cases that have lead to differences marked "OBSERVABLE" in the test code. It's not intended for publication, and I was lazy by using C++17 features. However, it has the "code talks" quality in that it leaves little to the imagination. So, please remember to wear goggles: https://github.com/sehe/beast/blob/core_string_view/test/beast/core/string.… > > The main area I didn't compare was constexpr-ness. Anecdotally I got the impression that core::string_view is more consistent in constexpr-ification. In fact my analysis uncovered a bug in Boost Utility https://github.com/boostorg/utility/issues/94 > > Some other differences have been addressed for an upcoming Boost release. The related tickets can be found in this cppslack thread: https://cpplang.slack.com/archives/CD7BDP8AX/p1651467929687909 I don't think any of these differences impact this library. I've raised https://github.com/anarthal/mysql/issues/98 to address it. It still freaks me out a little including a header labeled as "detail" - why is it not available as <boost/core/string_view.hpp> rather than <boost/core/detail/string_view.hpp>? It looks like if the class wasn't supposed to be used in public interfaces. > > > I'd say that the pipeline interface > > (https://github.com/anarthal/mysql/issues/76) > > may be a better interface than multi-statement for this use case. > > I think what I tried to describe is what you call the pipeline interface. So +1 > > > Note that prepared_statement's get allocated a server-side ID, which > > we expose via the prepared_statement::id() function. Something that > > could be useful for that use case is closing a statement without a > > prepared_statement object, just using its ID. > > > It may be worth adding a hint about the native_handle with the current warning about prepared_statement's destructor. > > > > > Something I noticed while implementing these erased types is that > > having prepared_statement and resultset be I/O objects makes > > the erased interface much harder. As I've mentioned in other > > review responses, I'm thinking on replacing the following signatures: > > > > prepared_statement::execute(const statement_params<ValueIterator>&) > > prepared_statement::close() > > resultset::read_one(row&) > > > > By functions in the connection: > > > > connection::execute_statement(const prepared_statement&) > > connection::close_statement(const prepared_statement&) > > connection::read_row(resultset&, row&) > > > > Where prepared_statement and resultset would be non-templated > > types. What do you think of this API? > > I can see how it simplifies things. It feel a bit C-api to me. But I have no strong opinion either way. > It's what you think is best for users in the end. Regards, Ruben.

3 2

Re: [boost] need help with building QuickBook docs
by Andrzej Krzemienski 25 May '22

25 May '22

I managed to figure out that it is this command that triggers the error: "xsltproc" -v --stringparam boost.defaults "Boost" --stringparam > boost.libraries "../../../../libs/libraries.htm" --stringparam boost.root > "../../../.." --stringparam chapter.autolabel "0" --stringparam > chunk.section.depth "8" --stringparam generate.section.toc.level "1" > --stringparam toc.max.depth "2" --stringparam toc.section.depth "2" --path > "../../bin.v2" --path "../../bin.v2/libs/optional/doc" --xinclude -o > "../../bin.v2/libs/optional/doc/optional.docbook" > "/home/andrzej/Repos/boost/tools/boostbook/xsl/docbook.xsl" > "../../bin.v2/libs/optional/doc/optional.xml" > I am using xsl files in boost/tools/boostbook/xsl from Boost repo. The contents of optional.xml are attached. It looks like QuickBook went fine. Well, this is now manageable. I got it to the point where QuickBook can detect bugs in my *.qbk files, and I can commit changes in documentation without the fear of introducing broken sources, but without the comfort of seeing the end results. I can then watch them in https://www.boost.org/doc/libs/develop/ Regards, &rzej; pon., 23 maj 2022 o 22:54 Andrzej Krzemienski <akrzemi1(a)gmail.com> napisał(a): > > > pon., 23 maj 2022 o 22:11 Andrey Semashev via Boost <boost(a)lists.boost.org> > napisał(a): > >> On 5/23/22 22:14, Andrzej Krzemienski wrote: >> > >> > >> > pon., 23 maj 2022 o 00:30 Andrey Semashev via Boost >> > > >> > > Are you using the latest built QuickBook >> > > executable? >> > >> > How can I check my version of QuickBook? >> >> quickbook --version >> >> But if you need to ask, it is probably better to just build it from >> sources. >> > > $ quickbook --version > Quickbook Version 1.7.2 (Boost 1.76) > > > >> >> > Also, make sure you don't have some stale content in bin.v2. Your >> log >> > doesn't indicate that QuickBook was run, probably because the >> BoostBook >> > document was already there. >> > >> > I now removed everything from folder bin.v2 before running `b2 doc`. I >> > still get the same result. >> > Maybe there is a way to see intermediate results, such as the generated >> > BoostBook format? >> >> The intermediate results can be found in bin.v2/libs/optional. >> > > So, the only intermediate result I found there is > bin.v2/libs/optional/doc/optional.xml (enclosed). > It has: > > <!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN" " > http://www.boost.org/tools/boostbook/dtd/boostbook.dtd"> > > Which is the output of quickbook, I suppose. > > I am using libxslt-1.1.35-1.fc36.x86_64, and it seems the lowest one that > I can get on my Fedora. > > # xsltproc --version > Using libxml 20914, libxslt 10135 and libexslt 820 > xsltproc was compiled against libxml 20912, libxslt 10135 and libexslt 820 > libxslt 10135 was compiled against libxml 20912 > libexslt 820 was compiled against libxml 20912 > > Regards, > &rzej; > > >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> >

2 2

Need help with SOCKS-Asio library
by Alan de Freitas 25 May '22

25 May '22

Hi! First of all, I'd like to apologize for asking for help last time during the Boost.MySql review. Terrible timing. :) So considering our recent discussions about the future of Boost, where providing more protocol implementations comes up frequently, we started this SOCKS <https://en.wikipedia.org/wiki/SOCKS> library I would like to "re-announce." The library is based on Asio and already contains the most relevant operations. There's also a client example and minimal proxy server example you can already use with your browser. At this point, I'd like to know if any kind soul, including the Asio experts, could have a quick look (as quick as you want) and provide some feedback regarding the implementation or even just the suitability of the library direction. Repo: https://github.com/alandefreitas/socks_proto Docs: https://develop.socks-proto.cpp.al/ #boost-socks on Slack Thanks! -- Alan Freitas https://github.com/alandefreitas

5 7

What do I need Boost for?
by Andrzej Krzemienski 25 May '22

25 May '22

Hi Everyone, In connection with the recent discussions on the future of Boost, I would like to offer a perspective of someone who is a consumer of open-source (but also commercial) libraries. In my work I often find myself in a situation where I need to use a new library for: * logging * unit testing * communication with DB * parsing requests XML, or simplified XML (without Unicode or less popular XML features), JSON * validating requests against XML/JSON schemas * HTTP communication * etc... I do not necessarily need Boost libraries for that. I need libraries that satisfy my criteria for correctness, safety, performance, and conformance with a certain programming style (e.g., a library cannot force me to inherit all my classes from class `Object`). These libraries do not necessarily have to come from one source. But they have to *interoperate* with one another. When I select a new library my concerns are usually the same: 1. Does the author understand the problem of exception safety and failure safety in general? The declaration "this library is exception safe" is an indication that the author at least heard about the term, but is still insufficient. I become convinced when I see a listing: these functions offer commit-or-rollback guarantee, these functions offer basic failure-safety guarantee, these functions offer other guarantees, like never-empty for some implementations of variants. 2. Does the author understand the problem of thread-safety? Similarly here, the note "this library is thread-safe" at least indicates that the author is aware of thread-safety problems. I feel more confident when I see the listing: "these functions can be called simultaneously from multiple threads", or similar declarations. 3. Does the library use the established patterns in C++, like value semantics, strong types? 4. Will the library give me the control over resource management? Or will it allocate like 30 threads behind my back, when I least expect it? 5. Will it interoperate with other libraries that I choose for other tasks? 6. Is the library actively maintained? 7. Is the library *decently* documented? (Not only the repetition of declarations from the header files.) 8. Did the author study the domain deeply, and has come up with the optimum concepts and the interface? Boost is often my first place to go. Because I have a high level of confidence that my expectations will be satisfied. But I do not always prefer Boost. For instance for unit tests I go to Google.Test, for instance, because I strongly disagree with the choice for how the precision for floating-point comparisons is silently chosen in a non uniform way. My confidence in boost stems from the review process and the assembly of experts that I trust. One could say that Boost offers a certification mechanism, even if informal. I do not care that much if all libraries come from one source, but I would love there to be a common certification body (even if informal) that would say "this library meets a certain set of criteria". I desperately needed Boost in the past because it offered a really basic fundamental primitives that were missing from the Standard library, as well from the language: optional, variant, tuple, any, shared_ptr, but also BOOST_FOREACH, BOOST_AUTO. You could call the types from the list the "vocabulary types": they can be used in other third party libraries, and therewith different libraries can interoperate seamlessly owing to these types. Today, these types from Boost do not necessarily fill this role anymore because we have the std equivalents. But Boost.ASIO can be thought of as such a building block: it can be used as a base for many higher-level libraries that interoperate owing to the same asynchrony model. If I, a library consumer, were to answer the question what I would like Boost to be, that would be: 1. The certification role: to educate what a high standard library means, to offer help and tools for library developers to achieve this level (not necessarily as a Boost library) and to issue opinions on the libraries. Boost to a great extent already implements this. 2. To focus on foundational libraries: those that can help other libraries interoperate. Like the one big decimal library. An interesting counter example to using vocabulary types is Boost.JSON implementing its own string type for efficiency. I was already convinced that it was the right decision to implement a custom string. But it illustrates something important: we cannot have the one string class. I guess where there is a need to manage resources (like string manages memory internally) there cannot be the one vocabulary type. Regards, &rzej;

2 1

need help with building QuickBook docs
by Andrzej Krzemienski 23 May '22

23 May '22

Hi Everyone, This is to ask for help with building QuickBook documentation, but also to spill my frustration. I would like to offer some feedback in connection with the recent "the future of Boost" threads: about the entry barrier for someone who wants to contribute to Boost. I maintain Boost.Optional. Getting my environment to the point where I was actually able to apply modifications to the official repo took some time, but it has been working fine since. Modifying the source files, so that they compile on multiple compilers, platforms and versions, including C++03 is the easiest part. Testing is a bit harder, but basically works also: I go to folder `test`, run the `b2` command, and it is done. But updating the documentation is the most difficult task for me. Not the content -- this is easy -- but the process/pipeline/framework. I inherited the documentation in QuickBook format, which as I understand was the recommended way for providing documentation for Boost libraries. Maybe it still is? (but I see more and more docs being rewritten to AsciDocs.) I understand that library authors have the freedom to choose their own format of docs for their libraries, but does boost recommend (as opposed to enforcing) one format? Anyway, in order to test if my QuickBook dos are correct, I need to build HTML version from the sources. Sometimes it "just works" with `b2` command, but when something goes wrong, this becomes a pain. I cannot just call `b2` for my library, because apparently my Fedora comes with preinstalled version of b2 (4.4) which appears to be incompatible with something in Boost libraries sources, as I get error: error: mismatched versions of B2 engine and core > error: B2 engine (b2) is 4.4.1 > error: B2 core (at /home/andrzej/Repos/boost/tools/build/src) is 4.9-git > Ok, I learned to live with it and to launch b2 from tools/build. It used to work for a while, but yesterday when I did a `git pull --rebase` on Boost repo, it no longer works. I get an error: Jamfile.v2:45: Unescaped special character in argument > <format>pdf:<xsl:param>boost.url.prefix= > http://www.boost.org/doc/libs/release/libs/optional/doc/html > Performing configuration checks > > - default address-model : 64-bit (cached) [1] > error: at /home/andrzej/Repos/boost/tools/build/src/kernel/modules.jam:106 > error: Unable to find file or target named > error: '/boost/architecture//mips' > error: referred to from project at > error: '.' > Ok, I can remove line `: /boost/architecture//mips` from file `boostcpp.jam`. (Am I supposed to do it before using `b2`?). But then, when trying to build the docs, I get a lot of errors, saying: runtime error: file > /home/andrzej/Repos/boost/tools/boostbook/xsl/annotation.xsl line 432 > element element > xsl:element: The effective name '' is not a valid QName. > (Full error message is enclosed.) I have no clue which element in the pipeline is causing or reporting this. QuickBook, BoostBook, DocBook, xsltproc? The process involves many components, at least according to this diagram: https://svn.boost.org/trac10/wiki/BoostDocs/GettingStarted Is this something obvious that I am missing? Is this a good idea, or a recommended practice to use QuickBook nowadays for Boost docs? I feel comfortable fixing or writing C++ code, and I am willing to devote some of my limited time to do this. But fighting with QuickBook documentation is something I would not rather do. I have a small library that I considered submitting to Boost: https://github.com/akrzemi1/markable But as long as it is on my GitHub page, it is simple to maintain, test and document. If I imagine how many nights I will have to spend making the documentation compatible with Boost, or getting all the b2-related stuff to work, I feel discouraged. Maybe I am being unfair to `b2` now. But it is certainly my personal emotional impression. I do not mind the current Boost website format or the underlying technology. I do not mind the mailing list format. My primary obstacle is this perceived or real difficulty to get a boost library into a shape where it just builds, including its documentation. My ideal as a Boost library maintainer, is that I just provide the source for the library and the documentation, and anything else "just works". Maybe this is not achievable, but the closer to this ideal, the more encouraged I would be to consider authoring or maintaining a library. Any help in fixing my build problem is most welcome. Regards, &rzej;

7 16

MySql review
by Phil Endecott 23 May '22

23 May '22

Here is my review of Ruben Perez's proposed MySql library. Background ---------- I have previously implemented C++ wrappers for PostgreSQL and SQLite, so I have some experience of what an SQL API can look like. I know little about ASIO. I have also recently used the AWS SDKs for C++ and Javascript to talk to DynamoDB; this has async functionality, which is interesting to compare. I confess some minor disappointment that MySql, rather than PostgreSQL or SQLite, is the subject of this first Boost database library review, since those others have liberal licences that are closer to Boost's own licence than MySql (and MariaDB). But I don't think that should be a factor in the review. Trying the library ------------------ I have tried using the library with - g++ 10.2.1, Arm64, Debian Linux - ASIO from Boost 1.74 (Debian packages) - Amazon Aurora MySql-compatible edition I've written a handful of simple test programs. Everything works as expected. Compilation times are a bit slow but not terrible. The remainder of this review approximately follows the structure of the library documentation. Introduction ------------ I note that "Ease of use" is claimed as the first design goal, which is good. I feel that some mention should be made of the existing C / C++ APIs and their deficiencies. You should also indicate whether or not the network protocol you are using to communicate with the server is a "public" interface with some sort of stability guarantee. (I guess maybe it is, if it is common to MySql and MariaDB.) Tutorial -------- The code fragments should start with the necessary #includes, OR you should prominently link to the complete tutorial source code at the start. You say that "this tutorial assumes you have a basic familiarity with Boost.Asio". I think that's unfortunate. It should be possible for someone to use much of the library's functionality knowing almost nothing about ASIO. Remember your design goal of ease-of-use. In fact, it IS possible to follow the tutorial with almost no knowledge of ASIO because I have just done so. You have this boilerplate at the start of the tutorial: boost::asio::io_context ctx; boost::asio::ssl::context ssl_ctx (boost::asio::ssl::context::tls_client); boost::mysql::tcp_ssl_connection conn (ctx.get_executor(), ssl_ctx); boost::asio::ip::tcp::resolver resolver (ctx.get_executor()); auto endpoints = resolver.resolve(argv[3], boost::mysql::default_port_string); boost::mysql::connection_params params ( argv[1], // username argv[2] // password ); conn.connect(*endpoints.begin(), params); // I guess that should really be doing something more // intelligent than just trying the first endpoint, right? I would like to see a convenience function that hides all of that: auto conn = boost::mysql::make_connection( ...params... ); I guess this will need to manage a global, private, ctx object or something. There are various possibilities for the connection parameters to pass to that, e.g. connection_params params = { .hostname = ".....", .port = 3306, // why is that a string in yours? .user = "admin", .password = "12345", .dbname = "foo" }; make_connection(params); Or make_connection("mysql://admin:12345@hostname:3306/dbname"); Now... why the heck does your connection_params struct use string_views? That ought to be a Regular Type, with Value Semantics, using std::strings. Is this the cult of not using strings because "avoid copying above all else"? Another point about the connection parameters: you should provide a way to supply credentials without embedding them in the source code. You should aim to make the secure option the default and the simplest to use. I suggest that you support the ~/.my.cnf and /etc/my.cnf files and read passwords etc. from there, by default. You might also support getting credentials from environment variables or by parsing the command line. You could even have it prompt for a password. Does MySQL support authentication using SSL client certs? I try to use this for PostgreSQL when I can. If it does, you should try to support that too. About two thirds of the way through the tutorial, it goes from "Hello World" to retrieving "employees". Please finish the hello world example with code that gets the "Hello World" string from the results and prints it. Queries ------- I encourage you to present prepared queries first in the documentation and to use them almost exclusively in the tutorial and examples. You say that "client side query composition is not available". What do you mean by "query composition"? I think you mean concatenating strings together'); drop table users; -- to form queries, right? Is that standard MySql terminology? I suggest that you replace the term with something like "dangerous string concatenation". In any case, that functionality *is* available, isn't it! It's trivial to concatenate strings and pass them to your text query functions. You're not doing anything to block that. So what you're really saying is that you have not provided any features to help users do this *safely*. I think that's a serious omission. It would not be difficult for you to provide an escape_for_mysql_quoted_string() function, rather than having every user roll their own slightly broken version. IIRC, in PostgreSQL you can only use prepared statements for SELECT, UPDATE, INSERT and DELETE statements; if you want to do something like ALTER TABLE a ALTER COLUMN c SET DEFAULT = ? or CREATE VIEW v as SELECT * FROM t WHERE c = ? then you are forced to do string concatenation with escaping of parameters. But according to https://dev.mysql.com/doc/refman/8.0/en/sql-prepared-statements.html, MySQL allows more statements to be prepared. In what cases can prepared statements not be used? Perhaps non-prepared statements really can be hidden as mysql::unsafe::statement? Regarding your prepared statements: tcp_ssl_prepared_statement is verbose. Why does the prepared statement type depend on the underlying connection type? I have to change it if I change the connection type?! If that's unavoidable, I suggest putting a type alias in the connection type: connection_t conn = ....; connection_t::prepared_statement stmt(.....); Does MySql allow numbered or named parameters? SQLite supports ?1 and :name; I think PostgreSQL uses $n. Queries with lots of parameters are error-prone if you just have ?. If MySql does support this, it would be good to see it used in some of the examples. Invoking the prepared statement seems unnecessarily verbose. Why can't I just write auto result = my_query("hello", "world", 42); ? That's a variadic operator(). In my PostgreSQL library, I chose to specify the query parameter types as template parameters to the query (prepared statement) type: Query<std::string, std::string, int> my_query("....."); Query's operator() takes exactly those types (maybe with some TMP to use std::string_view where std::string is specified). With hindsight, a default where all parameters are strings would have been useful in practice. I also added Query variants where the result is expected to be - A single value, e.g. a SELECT COUNT(*) statement. - Empty, e.g. INSERT or DELETE. - A single row. - Zero or one rows. - A single column. This is just syntactic sugar but it makes life easier. For example: SingletonQuery<int, string> sessions_for_user("SELECT COUNT(*) FROM sessions WHERE username = ?"); // int is the return type, string is the one parameter type. auto n_sessions = sessions_for_user("phil"); I don't see anything about the result of an INSERT or UPDATE. PostgreSQL tells me the number of rows affected, which I have found useful to return to the application. resultset, row and value ------------------------ I'm not enthusiastic about the behaviour nor the names of these types: - resultset is not a set of results. It's more like a sequence of rows. But more importantly, it's lazy; it's something like an input stream, or an input range. So why not actually make it an input range, i.e. make it "a model of the input_range concept". Then we could write things like: auto result = ...execute query... for (auto&& row: result) { ... } - row: not bad, it does actually represent a row; it's a shame it's not a regular type though. - value: it's not a value! It doesn't have value semantics! I guess it is time to address the string_view issue..... I just modified one of my example programs to copy from the string_view in the variant into a std::string, and it slowed the program down by... no, it actually went fractionally faster. The use of string_views in the value variant seems to me to be a premature optimisation. There are significant disadvantages to using string_view here. Your default API should have value semantics. If you want, provide another "low copying" API for users who want it with names that make it clear what they are doing. The problem is that the lifetime of the string_view is tied to the row in a non-obvious way. I'm also uncertain that a variant for the individual values is the right solution here. All the values in a column should have the same type, right? (Though some can be null.) So I would make row a tuple. Rather than querying individual values for their type, have users query the column. MySQL to C++ mapping reference ------------------------------ It seems odd that MySQL small integers all map to C++ 64-bit types. I use NUMERIC quite a lot in PostgreSQL; I don't know if the MySql type is similar. I would find it inconvenient that it is treated as a string. Can it not be converted to a numeric type, if that is what the user wants? Need to consume the entire resultset ------------------------------------ I seem to get an assertion if I fail to read the resultset (resultset.hpp:70). Could this throw instead? Or, should the library read and discard the unread results in this case? Going Async ----------- I have tried this with both callbacks and C++20 coroutines and it seems to work as expected. I'm actually delighted to see the support for coroutines here. But the lack of protocol support for multiple in-flight queries immediately becomes apparent. It almost makes me question the value of the library - what's the point of the async support, if we then have to serialise the queries? Should the library provide this serialisation for us? I.e. if I async_execute a query while another is in progress, the library could wait for the first to complete before starting the second. Or, should the library provide a connection pool? (Does some other part of ASIO provide connection pool functionality that can be used here?) Transactions ------------ I have found it useful to have a Transaction class: { Transaction t(conn); // Issues "BEGIN" .... run queries .... t.commit(); // Issues "COMMIT" } // t's dtor issues "ROLLBACK" if we have not committed. Nested transactions are an interesting problem. Trademark --------- Klemens Morgenstern makes the point that MySql is a trademark of Oracle. Calling this "Boost.MySql" doesn't look great to me. How can you write "The Boost MySql-compatible Database Library" more concisely? Conclusion ========== Good points: It actually works! Great to see coroutines! Bad points: The resultset / row / value type system is a poor design. A lot of boilerplate could be hidden from many users. Connection pool may be required for useful performance. Several features should be re-worked to be secure by default. Use of MySQL trademark needs to be considered. Overall, I think this proposal needs a fair amount of API re-design and additional features to be accepted, and should be rejected at this time. It does seem to be a good start though! Thanks to Ruben for the submission. (I have spend one working day on this review. I have not looked at any of the code.) Regards, Phil.

13 18

Re: [boost] need help with building QuickBook docs
by Andrzej Krzemienski 22 May '22

22 May '22

niedz., 22 maj 2022 o 17:33 <pbristow(a)hetp.u-net.com> napisał(a): > I don’t see where annotation.xsl comes from, or what is should contain > (but it looks as though it contains something wrong!!). > > > > Can you share it with us? And any metadata? > The file comes from the boostbook repo: https://github.com/boostorg/boostbook/blob/develop/xsl/annotation.xsl I applied no modifications. > > > None of this looks familiar to me from generating Quickbook docs ☹ > > > > Paul > > > > PS I also view items reported as cached with suspicion, as a result of > being bitten before. > > > > Especially when there are two difference versions. > > > > > https://stackoverflow.com/questions/5709105/how-do-i-force-bjam-in-boost-to… > may help. > Thanks for the idea. I'll try it later, in the evening. Regards, &rzej; > > > > > *From:* Andrzej Krzemienski <akrzemi1(a)gmail.com> > *Sent:* 22 May 2022 15:45 > *To:* Boost mailing list <boost(a)lists.boost.org> > *Cc:* pbristow(a)hetp.u-net.com > *Subject:* Re: [boost] need help with building QuickBook docs > > > > > > > > niedz., 22 maj 2022 o 15:52 Paul A Bristow via Boost < > boost(a)lists.boost.org> napisał(a): > > > -----Original Message----- > > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Andrzej > Krzemienski via Boost > > Sent: 22 May 2022 14:14 > > To: René Ferdinand Rivera Morell <grafikrobot(a)gmail.com> > > Cc: Andrzej Krzemienski <akrzemi1(a)gmail.com>; Boost Developers List < > boost(a)lists.boost.org> > > Subject: Re: [boost] need help with building QuickBook docs > > > > Thanks. That would be the most likely cause of my problems. Could you > point me to instructions for > > rebuilding the b2 engine executable? > > > > https://www.boost.org/doc/libs/1_79_0/more/getting_started/windows.html#get… > > > Section 5.1 Simplified Build From Source > > If you wish to build from source with Visual C++, you can use a simple > build procedure described in this section. Open the command prompt and > change your current directory to the Boost root directory. Then, type the > following commands: > > bootstrap > .\b2 > The first command prepares the Boost.Build system for use. The second > command invokes Boost.Build to build the separately-compiled Boost > libraries. Please consult the Boost.Build documentation for a list of > allowed options. > > https://www.boost.org/doc/libs/1_79_0/tools/build/doc/html/index.html > > > https://www.boost.org/doc/libs/1_79_0/tools/build/doc/html/index.html#bbv2.… > > Run either .\bootstrap.bat (on Windows), or ./bootstrap.sh (on other > operating systems) > > (which may be too simple. By default, Windows 10 and up, probably don't > provide cmd.exe, preferring the fancy new command shell Windows > PowerShell) > > b2 -v will show the current version. > > You will probably want to ensure that b2.exe is visible globally, perhaps > by adding to PATH. Perhaps using the Windows Environment Variables editor? > > HTH > > Paul > > > > Thank you. This seems to remove the first obstacle on my way to building > Boost.Optional docs. > > I am now using B2 Version 4.9. OS=LINUX. I get the error from another > tool, I suppose: > > > > [2] > gcc-12/release/cxxstd-0x-iso/link-static/python-3.10/threadapi-pthread/threading-multi/visibility-hidden > ...patience... > ...patience... > ...found 4351 targets... > ...updating 2 targets... > xslt-xsltproc ../../../bin.v2/libs/optional/doc/optional.docbook > runtime error: file > /home/andrzej/Repos/boost/tools/boostbook/xsl/annotation.xsl line 432 > element element > xsl:element: The effective name '' is not a valid QName. > > > > Is it DocBook, QuickBok, BoostBook? (I enclose the full error report.) I > am just running b2 on boost/libs/optional/doc from the official repo. Can > someone confirm if they see the same problem? or is it just me? > > > > Regards, > > &rzej; > > > > > > > > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > >

1 0

[Boost MySQL] - Review Period has Ended
by Richard Hodges 21 May '22

21 May '22

Looking at the number of messages in my inbox I see that we have had a great response to the request for reviewers while I have been in transit. Thank you everyone for taking the time to participate. Thank you also to Rubén, as it is apparent from the number of github commits I have seen that he has been very responsive to review comments. Now that I am back home it will take me a little time to collate the results and present. I expect to have this done by the end of the weekend. -- Richard Hodges hodges.r(a)gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212

1 0

Review of Boost.MySQL
by Christian Mazakas 20 May '22

20 May '22

Hello Boost Mailing List, this is my review of Boost.MySQL, ------------ Introduction ------------ Full disclosure, Rubén initially approached me and asked if a MySQL Asio implementation would be wortwhile and I emphatically said, "Yes!" so in some sense, it's impossible for me to be unbiased here. I strongly vote in favor of accepting this library into Boost, for the following set of reasons: * it actually works * it's incredibly idiomatic Asio code * it enables developers to meet business needs * everything else can be built on top of it ---------- Background ---------- I was one of the earlier users of this library, using it going back probably about a year or so ago. I used it at my last job to store records in a local DB. There's probably still a tractor somewhere in a tomato field in California that's running a version of Boost.MySQL on it. Originally, our goal was to have replication working between our deployed machines and a remote server that stored everything "for real". But unfortunately, that requires a bit of DBA voodoo that I'm not capable of so I settled for implementing my own replication logic for the tables where we had to preserve the data. It should also be known that I guess I fall into the "advanced" category of Asio user though that is somewhat contentious. I can write an iniating function okay and preserve executor/allocator correctness. I've also written my fair share of SQL queries as well, working as a webdev for 5+ years so I'm no stranger to MySQL. --------------------------- Discussed Issues & Concerns --------------------------- I've seen some recurring themes during review. Namely, no connection pool, no direct parse-to-struct, no fail-over/healthcheck support. As far as a connection pool is concerned, this should, in my opinion, be considered out-of-scope for an initial acceptance candidate, especially considering the work that was already put into the candidate we have today. It is nice to have one but it's also an open-ended design space and if one was included in the implementation, we'd all be bikeshedding it to death. Instead, I think it's better to let users write what works for them and then gradually we see what a community-driven approach looks like and add that to Boost officially at a later time. It's also worth noting that if you're running against a localhost DB, creating a unix socket connection on something like `/var/run/mysqld/mysqld.sock` is essentially free and you won't even need to use TLS. This helps ameliorate some of the need for a connection pool. Now, in terms of a health-check, this is something the library could add to its `connection` class and have it function identically to how Beast has its websocket streams with their automatic ping/pong semantics. I also saw in a previous email the idea of `void connection::ping()`. I think this should be added before acceptance. If we don't add automatic health-checks for a connection, we should at least give users a proper tool for solving that problem themselves. I will say, however, that it's actually common in Asio to handle reconnection and health-checking yourself. For example, I've delivered Asio-driven applications that communicated with serial ports and CANbus (using SocketCAN). These connection types had reconnection and timeout logic that I manually implemented. These things seem daunting at first but become second-nature once you're accustomed to Asio. Even moreso now that Asio's awaitable types implement `operator||`. As for fail-over, I can't comment too directly as it's something I've never had to deal with in my career. On first thought, I don't know if it'd be exactly the most difficult thing to get a connection to realize it's disconnected and then reconnect to another database from a known whitelist. I'm also under the impression that services like AWS' RDS will simply give you a static hostname or IP address to connect against which acts as a proxy and then the fail-over happens in the background. Maybe I misunderstand the intent of what "fail-over" is so I could simply be uninformed with an opinion here. For parsing directly into a user-defined struct, this is always something nice to have but it shouldn't be a requirement as C++ offers no standardized reflection interface so it's unreasonable to expect this library to accomodate that. This was similarly debated at length during the JSON review and we've learned that a library can still be good while not parsing directly to a structure. ----------------- Personal Opinions ----------------- There's a school of thought that only the lowest-level components should be standardized on a first-pass. Higher-level components can always be built on top of solid primitives. I think Boost.MySQL creates this set of primitives and I think it succeeds. >From a connection, you derive prepared statements or queries. From those, you derive a resultset which is an interface for reading what the DB writes back. Rows derive from the resultset and then values derive from the rows. The surface area of the library is delightfully small and well-contained. I think this library is "simple", for better or worse. I empathize with the side that expresses woes about this simplicity. I think perhaps I'm hardened by my own experiences with Asio so the pains of this library are nothing new to me. To this end, the simplicity of the library is a welcome breath of fresh air from my perspective. The for example, is actually small which is incredibly rare these days. There is one other issue I'd still like to discuss and it's the infamous usage of `std::vector` in interfaces. This is not a problem as a convenience interface as 98% of users are going to use `std::vector` anyway. But it does inhibit Allocators which is unsuitable for acceptance as a Boost library. Everywhere `std::vector` appears, there should be an accompanying version that works with a `Vector&` out-param, i.e. my_company::vector<mysql::row> v; co_await resultset.async_read_all(v); I don't think requiring `vector`-like operations on the type is problematic but preventing control over the allocation is. `error_info&` as an out-param is slightly awkward but I do appreciate that it at least enables us to read the messages about why our queries are wrong. This was my only real complaint about the ergonomics of the library. I would've expected to somehow pull this information from the `error_code` so using an `error_info&` out-param is clunky here. I also don't particularly mind that the backing data of a `value` is tied to the lifetime of a `row` but I can see why this is confusing so perhaps a change in naming is required. --------- Summation --------- In summary, the library is great, it's intuitive, it's idiomatic and I think it belongs in Boost aside other great Asio-based libraries like Beast. At some point, Boost will have its own LAMP/MEAN stack which is the dream. I also realize, I never critiqued the implementation and I think that's because parsing/serializing perf isn't a priority for me and simply working correctly and being clean under valgrind are all that matter so long as the library isn't horrendously slow. If anyone has different opinions on my take, I'd love to hear them. - Christian

2 2

Boost MySQL Review Is In Progress
by Richard Hodges 19 May '22

19 May '22

Dear All, We've had a good response for calls to review this much anticipated library, and there is a lot of interest on Reddit: https://www.reddit.com/r/cpp/comments/unik91/acceptance_review_for_boostmys… . In general the public perception of utility libraries like this in Boost seems popular, and Boost's emphasis on quality is often mentioned. If you are able, I would be more than grateful if you could take a few hours over this delightful weekend to offer a review. The more eyes on this project the better, as if it is successful, it will no doubt prompt submission of similar libraries targeting other popular database and messaging systems. The Boost formal review of the MySQL library started on May 10th, 2022 and will conclude on May 19th, 2022 (inclusive) - In fact, I am able to accept submissions up until the (GMT) morning of May 20th as I'll be traveling on May19th. The library is authored by Rubén Pérez Hidalgo (@anarthal in the CppLang slack). Documentation: https://anarthal.github.io/mysql/index.html Source: https://github.com/anarthal/mysql/ The library is built on the bedrock of Boost.Asio and provides both synchronous and asynchronous client connectors for the MySQL database system. Boost.MySQL is written from the ground up, implementing the entire protocol with no external dependencies beyond the Boost library. It is compatible with MariaDB. Connectivity options include TCP, SSL and Unix Sockets. For async interfaces, examples in the documentation demonstrate full compatibility with all Asio completion handler styles, including: Callbacks:- https://anarthal.github.io/mysql/mysql/examples/query_async_callbacks.html Futures :- https://anarthal.github.io/mysql/mysql/examples/query_async_futures.html Boost.Coroutine :- https://anarthal.github.io/mysql/mysql/examples/query_async_coroutines.html C++20 Coroutines :- https://anarthal.github.io/mysql/mysql/examples/query_async_coroutinescpp20… Rubén has also implemented the Asio protocols for deducing default completion token types :- https://anarthal.github.io/mysql/mysql/examples/default_completion_tokens.h… Reviewing a database connector in depth will require setting up an instance of a MySQL database. Fortunately most (all?) Linux distributions carry a MySQL and/or MariaDB package. MySQL community edition is available for download on all platforms here: https://dev.mysql.com/downloads/ Rubén has spent quite some time in order to bring us this library candidate. The development process has no doubt been a journey of discovery into Asio, its concepts and inner workings. I am sure he has become a fount of knowledge along the way. >From a personal perspective, I was very happy to be asked to manage this review. I hope it will be the first of many more reviews of libraries that tackle business connectivity problems without further dependencies beyond Boost, arguably one of the most trusted foundation libraries available. Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - Will the library bring additional out-of-the-box utility to Boost? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - Will the choice of API abstraction model ease the development of software that must talk to a MySQL database? - Are there any immediate improvements that could be made after acceptance, if acceptance should happen? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.MySQL library Rubén is often available on CppLang Slack and of course by email should you require any clarification not covered by the documentation, as am I. -- Richard Hodges hodges.r(a)gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212

5 6

Review of Boost.MySql
by Marcelo Zimbres Silva 19 May '22

19 May '22

Hi, here is my review. 1) ================================ > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__resultset/async_re… > The handler signature for this operation is > void(boost::mysql::error_code, std::vector<boost::mysql::row>). > etc. Having a std::vector in the signature of the completion handler is unusual in ASIO. In general, large objects should be passed as parameters to the initiating function. Additionally, this operation does not support custom allocators. That wouldn't be a big problem to me if I could reuse the same memory for each request but the interface above prevents me from doing so. It is also a pessimized storage as each row will allocate its own chunk of memory. A single block of memory would be better. 2) ================================ > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__connection/async_q… > The handler signature for this operation is > void(boost::mysql::error_code, boost::mysql::resultset<Stream>) Here the completion handler is returning an io object i.e. boost::mysql::resultset, which is also unusual as far as I can see. Wouldn't it make sense for users to specify a different executor for the resultset? This interface is preventing that. I prefer having the completion handler return config parameters with which I can instantiate a boost::mysql::resultset myself in my desired executor. 3) ================================ > https://github.com/anarthal/mysql/blob/13d3615464f41222052d9ad8fa0c86bcddde… I am not convinced the design of the value class is a good idea. The reason is that users know at compile time what types they are expecting from a given query. That means it would be possible for them to specify that before doing the query. So instead of doing this https://github.com/anarthal/mysql/blob/13d3615464f41222052d9ad8fa0c86bcddde… boost::mysql::row row; while (result.async_read_one(row, additional_info, yield[ec])) users could do boost::mysql::row<T1, T2, T3, T3> row; while (result.async_read_one(row, additional_info, yield[ec])) avoiding unnecessary further copies. In principle it would be even possible to parse directly in a custom data structure, for example, when storing json string in the database. 4) ================================ > https://anarthal.github.io/mysql/mysql/examples.html IMO, the examples are too limited and show variation of the same functionality. For example - Text query, async with callbacks - Text query, async with futures - Text query, async with Boost.Coroutine coroutines - Text query, async with C++20 coroutines - Default completion tokens Here you are showing nice Asio features. I am not meaning you should remove them but if I am not mistaken there is no example that shows - How to keep long lasting connections open (specially for ssl). - Timers for resolve, connect, read and write. - Synchronized writes. - Healthy checks, failover etc. I estimate that to address these points users will be required to write further 500 - 1000 LOC on top of your library. Otherwise they will be stuck on underperforming short lived connections. It would be helpful for users to have a starting point to begin with. There some minor things I have also noticed: 5) ================================ > https://github.com/anarthal/mysql/blob/13d3615464f41222052d9ad8fa0c86bcddde… I expect this function to be O(1). 6) ================================ > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_std_opti… > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_optional… Sounds also unusual to have two member functions for the different versions of optional. I suggest using the boost version until we transition to C++17. 7) ================================ > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__errc.html errc should be conditions and not error AFAICS. ============= Review End ================ I vote for conditional acceptance. Points 1, 2, 3 and 4 should be addressed before acceptance. My acceptance criteria sums up to 1) Remove functionality that provides low performance. With coroutines it will be easy for users to loop on async_query to create a std::vector of rows. 2) No IO object should be returned as a parameter of the completion handler. 3) Review the value type. Can it be improved? 4) Improve examples. Regards, Marcelo

10 27

Re: [boost] Review of Boost.MySql
by Ruben Perez 19 May '22

19 May '22

On Wed, 18 May 2022 at 11:05, Kostas Savvidis <ksavvidis(a)gmail.com> wrote: > > Hi Ruben, > > Some people have already suggested making the tcp_ssl connection as the default. In that spirit, it seems to me that it would be better to > remove such prefixes as tcp_ssl from tcp_ssl_prepared_statement and tcp_ssl_resultset > and instead add apropriate prefixes to the non-default connections. Actually, since the only other type is unix socket, > one only need to add the prefix plaintext or nonssl for the noncrypted connections. I like how this sounds. I've updated https://github.com/anarthal/mysql/issues/73 to reflect your comments. Note that we may want to add named_pipe_connection for Windows in the future. > Moreover, is there no technical solution that can completely remove the need to deal with these distinct names for resultset and prepared_statement after the appropriate connection is established? They depend on the Stream type because they have I/O operations. E.g. for a prepared_statement, you need the Stream type to implement the prepared_statement::execute function. Internally, these are really just pointers to the connection object (more or less). One possible option is making prepared_statement and resultset not be I/O objects, and move these functions to the connection object. So the following signatures: prepared_statement::execute(const params<ValueIterator>&) prepared_statement::close() resultset::read_one(row&) Would change to these ones: connection::execute_statement(const prepared_statement&, const params<ValueIterator>&) connection::close_statement(const prepared_statement&) connection::read_row(resultset&, row&) What do you think? Regards, Ruben.

2 2

B2 4.9.0
by René Ferdinand Rivera Morell 19 May '22

19 May '22

There is a new release of B2 and there are some important changes.. * The build-build.jam file, and the build-system rule, used to specify where to find the build system Jam file is no longer used for that purpose. There is now an internal method for finding the corresponding build files relative to the b2 executable. This means that the preferred method for using B2 is to install it first. But, the regular bootstrap use in Boost is still supported. * There is now a Windows MSI installer available that supports both per-user and per-machine installs without having to build it yourself. * Installing the current, and future, B2 allows one to use the newest B2 with current Boost release and most older Boost releases. And of course the same goes for non-Boost projects. For other changes see the release notes < https://github.com/bfgroup/b2/releases/tag/4.9.0> -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

4 6

Re: [boost] Boost MySQL Review Starts Today
by Ruben Perez 18 May '22

18 May '22

Forwarding this to the Boost ML (you just replied to me). On Mon, 16 May 2022 at 22:29, Alan de Freitas <alandefreitas(a)gmail.com> wrote: >> >> It is possible to write a Postgres connector with a similar approach. >> >> I indeed wrote a POC available here: >> https://github.com/anarthal/postgres-asio >> The protocols are different, though, so if you follow my approach >> of providing primitives easy to use, yet close to the protocol, >> the APIs will be a little different. The Postgres protocol allows >> finer grain control over statement execution, AFAIR. > > > Oh... That's great. > >> What actions do you think we can take here? Adding a section in the intro >> (https://anarthal.github.io/mysql/mysql/intro.html) about "knowing Asio >> is a requirement to use this library"? Do you think an overview on the protocol >> (handshake, query, metadata and row packets) would really be useful >> for the user at that point? > > > Considering the other reviews I've seen, I think people would like something like "Here's how you can use the library (with synchronous examples, so the user knows they don't need Asio to do what other libraries do)" and only then move to something like "This is how you can use it asynchronously (and by the way you need Asio to do that)". I think the Boost.Process documentation does something like that. I will move the examples on prepared statements forward, so all library functionality is explained before going into the async world. I may also refactor it to try to hide the ssl::context and io_context boilerplate. Besides that, I've got the following example suggestions: https://github.com/anarthal/mysql/issues/87 https://github.com/anarthal/mysql/issues/61 https://github.com/anarthal/mysql/issues/65 Any other ideas are welcome. > >> >> I'm as stuck as you here. What would be the best path here? >> For now, I've tried to contact a former user in the Boost ML who works >> at Oracle, to see whether he can provide me some guidance here. >> Any ideas are welcome. > > > I don't know if being better safe than sorry counts as a solution, but maybe being defensive and trying to come up with new names? Besides the legal issues, which I don't understand, there's the advantage of reflecting it also supports MariaDB. Our contact in Oracle has forwarded our query to the legal department, and I'm waiting for the response. I will wait for that before taking any action. > >> >> At the end of the day, I'd say this is similar to HTTP (half-duplex). > > > Yes. That's correct. I guess the main difference is only the use case. > > An HTTP server might spend its time serving multiple clients asynchronously because they're different connections. > But this same server might also be a MySql client and these SQL requests will need to be serialized to write back to the HTTP clients. > So the database becomes a shared resource being used by a number of asynchronous operations, even though HTTP and MySQL are individually similar. > But this is just something to think about. I guess this is a similar pattern to having the HTTP server calling another HTTP API while serving a request. The user will need to have a number of separate database connections to be able to scale. Connection pooling (https://github.com/anarthal/mysql/issues/19) should be important for this pattern. Using async functions for the database enables the server to keep serving HTTP requests (or whatever other processing it needs to do) while waiting for the MySQL server to answer a query. > >> >> Brought up by another user during review, tracked by >> https://github.com/anarthal/mysql/issues/58. I think the best thing >> here is just passing the vectors by lvalue reference. > > > I would think something like asio::buffer as input and size_t as a result, like asio::read functions, would be better because it allows the preferred data structure to be used. I'd say this pattern is effective for asio because it needs the byte elements in the output buffer to be contiguous. We may be able to use a concept like RowOutputIterator to achieve the same thing. I'm also thinking on making these functions return a custom range that doesn't own the rows (as proposed by Vinnie), but I need to study it more before making a decision. > >> >> Not sure if I follow you. What's the interface you propose here? >> The connection object already holds an internal buffer for requests. >> The library currently performs boost::asio::read call per packet, >> but I'm working in optimizing that to use read_some instead. >> With that approach, read_one may get the row from the buffer >> without performing any read at all. Is that what you mean? > > > Yes. If it read whatever it can to an internal buffer first, then read_some probably fixes that. I will have read_one read from the buffer if possible, and I'm thinking of implementing a read_some function for rows, but as I mentioned before, I'm still designing. > >> >> If we go down the compile-time parsing strategy, together with the buffering >> I described above, making it owning may be the best option. > > > Mmm... I hadn't considered that. That's correct. > Although I do not dislike the idea of it being a "view", because it's the most common use case anyway. > The only thing I didn't like was a "view" called "value". I've been given points in both directions. Would naming it sql_value_view or field_view make things better? Updated https://github.com/anarthal/mysql/issues/85. > >> >> First of all, I'd like to know your thoughts about the conversion >> functionality in value >> (https://anarthal.github.io/mysql/mysql/values.html#mysql.values.conversions) >> Do you think it's helpful for the user? > > > Yes. This looks good. > >> >> If it wasn't because of conversions, >> we could replace value::get_optional and value::get_std_optional for >> something similar to variant2::get_if, returning a pointer to the >> underlying value, >> avoiding the problem altogether. This could make even more sense if we make >> the value owning, as value::get_optional<std::string> would end up copying >> the underlying string, which doesn't make a lot of sense. > > > Yes. It depends on your next decisions. In any case, it would remove get_std_optional if get_optional is not removed. > >> Calling value::is_convertible_to, then value::get will perform the conversion >> twice, while value::get_optional will do it just once. It isn't >> horribly inefficient, >> though - maybe this section is causing more confusion than aid. > > > I'm not sure I'm following. So calling value::is_convertible_to actually needs to perform the conversion and then throw it away? It does. However, the conversions should be really fast - some int comparisons in the worst case. No memory allocations or expensive calls. > >> >> 4) Make value::get return a reference instead of a value. > > > You might have some problems keeping the implicit conversions here. I don't know what other libraries do. That would only be possible if we removed conversions. > >> I'm thinking on calling it query_operation or query_result. > > > I'm terrible at coming up with names. But query_operation or query_result look good. > >> >> > - The names "tcp_ssl_prepared_statement", "tcp_ssl_<component>" are quite >> > repetitive and verbose in the documentation. Maybe "tcp_ssl" could become a >> > namespace? Isn't that what Asio does for the ssl related objects? Some >> > names might be reduced if there's no alternative. For instance, >> > "prepared_statement" might become "statement" since there's no >> > "unprepared_statement". >> >> Would having type aliases under connection (i.e. connection::resultset_type) >> alleviate your concerns? > > > I think I would try to replicate whatever pattern Asio has. But it's really up to you. I've updated https://github.com/anarthal/mysql/issues/73 to add your suggestions. > >> >> Definitely. https://github.com/anarthal/mysql/issues/74 tracks it. >> How would variadic operator() work with async functions? > > > Yes. I'm not sure it has to be operator(). An explicit name, like execute, could be better. execute might become ambiguous though. To follow Asio's convention, I'd keep it a function like execute(). Should be possible to make it work, AFAIK. > >> >> Not aware there was a standard format. Could you please point >> me out to the relevant documentation? > > > I think this is the common template: https://github.com/boostorg/boost-ci > IRRC, some libraries, such as beast, have two paths: One path with find_package(Boost) when not in boost/libs and one path that considers it to be in boost/libs. > The template only has the second path. I haven't been able to locate the template - I can see a couple CMakeLists.txt but they seem test-related. Could you please point me to the specific file? > >> They are from the perspective that they require a real server to run. > > > Yes. They require lots of things but testing integration it's not their purpose or something specific to them. If their purpose was to test integration (with what?), then the examples would be wasteful because you don't need them to test integration. For instance, https://github.com/boostorg/boost-ci/tree/master/test/cmake_test includes a Cmake integration test, with only what we need to test CMake integration. (This is a minor point anyway) It could be worth changing the code to only *run* the examples if BOOST_MYSQL_INTEGRATION_TESTS is defined (as a signal of "hey, the user has a correctly configured server and wants to run all the tests she can"), but always build them, regardless of BOOST_MYSQL_INTEGRATION_TESTS. > >> >> > - The documentation refers to topics that haven't been explained yet. Maybe >> > "value" could be explained after "row", and "row" could be explained after >> > "resultset" and "resultset" after "queries". >> >> The basic concepts have been covered in the tutorial, which goes first. >> So at this point the user should know the *basic* concept of what a value, >> a row and a resultset is. The rest of the sections go deeper in these concepts. >> Did you find section order counter-intuitive, even reading the tutorial first? > > > I don't find it counter-intuitive. I think the mental model of (roughly) values < row < results < statements < DB is clear. > > The point here is probably that the snippets mysql/values.html represent stuff the user probably doesn't need and the following sections don't have many snippets. > At the same time, for instance, you referred to the tutorial when you thought I didn't understand the documentation. > > So I have the impression that the model of "values -> row -> results -> statements -> DB" makes it difficult to provide useful examples, while "DB -> statements -> results -> row -> values" makes the documentation more pleasant to read. > This is probably more important as the documentation grows with time. Technically, both options are fine. I see your point. Raised https://github.com/anarthal/mysql/issues/90. > >> >> No. In Asio, you always get two overloads for sync operations. > > > Oh... of course. I forgot the subsection was only talking about synchronous functions when I was reading that sentence. > >> >> I'd say this is personal preference. I will explore the tabular format >> when I have the chance. > > > The text format is not bad if you want to find the C++ type for a SQL type. > If you're looking for something with a different "column" as a reference, then you have to scan a lot of text to find what you want. Ah, do you mean adding a table that summarizes the mappings, additionally to what is currently written? That could be useful. Raised https://github.com/anarthal/mysql/issues/91. > >> >> Could you please be a little more explicit on your second point? >> Would adding a struct/tuple interface >> (https://github.com/anarthal/mysql/issues/60) > > > The tuple interface is something (really) nice to have but I don't think this should be a requirement for acceptance. > > On the other hand, the possibility of reusing memory (i.e. not depending on vector on the callbacks) seems urgent at this point. > This is what asio already does for its functions with asio::buffer so you don't depend on a specific data structure, like vector. > I think other people have mentioned the same issue in their reviews, and it seems problematic to bake this into the API at this point. > > For instance, if we replicate the asio interface, we would have something *similar* to: > > std::vector<boost::mysql::row> employees; > std::size_t n = result.read_all(employees); > > I'm not sure this example has the *best* API possible, but Asio functions tend to have this format. For instance, consider Boost.Beast: > > std::size_t n = http::read(stream, buffer, res); > > https://www.boost.org/doc/libs/1_79_0/libs/beast/doc/html/beast/ref/boost__… > > Same format. The buffers are input parameters and the function returns size_t. And the callback gives you error_code and size_t. > > Another small advantage of this format is that the callback function will match those of asio::read/asio::write, which is useful with asio::coroutine. > https://www.boost.org/doc/libs/1_79_0/doc/html/boost_asio/reference/corouti… Got it. I have to decide which API it will get, but it will allow for memory re-use. > >> >> and making it owning (https://github.com/anarthal/mysql/issues/85) > > > I don't even think making it own the data is important. I understand the value of making it a view. But that depends on other reviews. > I just care that something is done about it. Either making it owning or changing the name. Got it too. > >> >> Kind regards, > > > Thanks again for the library. Great work. > >> >> Ruben. > > > > -- > Alan Freitas > https://github.com/alandefreitas Thank you for your comments.

1 0

Boost MySQL Review Starts Today
by Richard Hodges 15 May '22

15 May '22

Dear All, The Boost formal review of the MySQL library starts Today, taking place from May 10th, 2022 to May 19th, 2022 (inclusive) - We are starting one day after the announced date and extending the period by one day to compensate. The library is authored by Rubén Pérez Hidalgo (@anarthal in the CppLang slack). Documentation: https://anarthal.github.io/mysql/index.html Source: https://github.com/anarthal/mysql/ The library is built on the bedrock of Boost.Asio and provides both synchronous and asynchronous client connectors for the MySQL database system. Boost.MySQL is written from the ground up, implementing the entire protocol with no external dependencies beyond the Boost library. It is compatible with MariaDB. Connectivity options include TCP, SSL and Unix Sockets. For async interfaces, examples in the documentation demonstrate full compatibility with all Asio completion handler styles, including: Callbacks:- https://anarthal.github.io/mysql/mysql/examples/query_async_callbacks.html Futures :- https://anarthal.github.io/mysql/mysql/examples/query_async_futures.html Boost.Coroutine :- https://anarthal.github.io/mysql/mysql/examples/query_async_coroutines.html C++20 Coroutines :- https://anarthal.github.io/mysql/mysql/examples/query_async_coroutinescpp20… Rubén has also implemented the Asio protocols for deducing default completion token types :- https://anarthal.github.io/mysql/mysql/examples/default_completion_tokens.h… Reviewing a database connector in depth will require setting up an instance of a MySQL database. Fortunately most (all?) Linux distributions carry a MySQL and/or MariaDB package. MySQL community edition is available for download on all platforms here: https://dev.mysql.com/downloads/ Rubén has spent quite some time in order to bring us this library candidate. The development process has no doubt been a journey of discovery into Asio, its concepts and inner workings. I am sure he has become a fount of knowledge along the way. >From a personal perspective, I was very happy to be asked to manage this review. I hope it will be the first of many more reviews of libraries that tackle business connectivity problems without further dependencies beyond Boost, arguably one of the most trusted foundation libraries available. Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - Will the library bring additional out-of-the-box utility to Boost? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - Will the choice of API abstraction model ease the development of software that must talk to a MySQL database? - Are there any immediate improvements that could be made after acceptance, if acceptance should happen? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.MySQL library Rubén is often available on CppLang Slack and of course by email should you require any clarification not covered by the documentation, as am I. -- Richard Hodges hodges.r(a)gmail.com tg: @rhodges office: +44 2032 898 513 mobile: +376 380 212

8 18

The Future of C++ and Boost - Modules
by Benedict Bede McNamara 14 May '22

14 May '22

>What I've noticed with modules (trying with MSVC) is that they are >ncredibly sensitive to compiler settings. I don't see MS (other >vendors too, for that matter) saying "these are the settings that will >be used, despite our tools offering much more". And I also have a >difficult time seeing modules losing that sensitivity, it would >basically require that the module contain the original >pre-preprocessed source. Or shipping an awkward - and growing - number >of module files. >For the time being I see modules as a nice idea that still needs lots >of work. Plus, there are things that can be done with includes that as >far as I'm aware modules simply don't support (Boost.Preprocessor's >iteration facility as an example). Bjarne Stroustup’s comments were to the effect that we should write programs that do not rely upon the pre-processor. Boost’s pre-processor iteration facility will have to be rewritten or dropped. I assume that you are going to use modules eventually or be left behind. If you choose not to use modules, then I will incorporate and rename Boost in my own module. Sent from Mail for Windows From: boost-request(a)lists.boost.org Sent: Saturday, 14 May 2022 6:58 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6705, Issue 1 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: cstring_view (Marshall Clow) 2. Re: The Future of C++ and Boost - C++ Modules (Soronel Haetir) 3. The Future of C++ Modules (Benedict Bede McNamara) 4. Re: cstring_view (Klemens Morgenstern) 5. Re: cstring_view (Rainer Deyke) 6. Re: The Future of C++ and Boost - C++ Modules (Mike) 7. Re: cstring_view (Daniela Engert) 8. Re: cstring_view (Klemens Morgenstern) 9. Boost MySQL Review Is In Progress (Richard Hodges) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 May 2022 15:42:59 -0700 From: Marshall Clow <mclow.lists(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] cstring_view Message-ID: <BEF2472F-B860-400F-B649-4024CD2F63CE(a)gmail.com> Content-Type: text/plain; charset=utf-8 > On May 13, 2022, at 3:19 PM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > > Marshall Clow wrote: >> On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost >> <boost(a)lists.boost.org> wrote: >>> >>> On 13.05.22 20:39, Marshall Clow via Boost wrote: >>>> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost >> <boost(a)lists.boost.org> wrote: >>>>> In what scenarios will it not give you a null-terminated string? >>>> char arr[6] = ?hello"; >>>> cstring_view csv(arr); >>>> assert(strlen(csv.data())) == 5); >>>> arr[5] = ?!?; >>>> assert(strlen(csv.data())) == 5); // boom ? Marshall PS. It >>>> promises to give you a null-terminated string, but has no way to actually >> guarantee that. >>> >>> That's an issue with views in general, not just cstring_view. >>> >>> std::string s = "hello"; >>> string_view sv = s; >>> assert(sv.size() == 5); >>> s += "!"; >>> assert(sv.size() == 5); // boom >> >> I don?t see the problem here (and when I run the code I get no error - after >> adding the missing ?std::'). >> >> No assertion failure; no undefined behavior (unlike the cstring_view example) > > Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates, > `sv` would be left dangling. Agreed. But even if the string *did* reallocate, the call "assert(sv.size() == 5)? is still valid and well defined. In the cstring_view example I wrote, there are no allocations (it?s a static buffer), and the call exhibits undefined behavior (as well as the assertion failure). The whole point of cstring_view is ?I have a sequence of N characters here, and I *swear* that then n+1st one is a NUL? ? Marshall P. S. Std::string has the same behavior (which I really dislike), but at least it owns the storage, so it can enforce the presence of the NUL. ------------------------------ Message: 2 Date: Fri, 13 May 2022 12:43:31 -0800 From: Soronel Haetir <soronel.haetir(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] The Future of C++ and Boost - C++ Modules Message-ID: <CAG5j88pttyHEeXnE8FbvRcJUL2hK_ogFm+UeCy26r19EhaphGA(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" What I've noticed with modules (trying with MSVC) is that they are incredibly sensitive to compiler settings. I don't see MS (other vendors too, for that matter) saying "these are the settings that will be used, despite our tools offering much more". And I also have a difficult time seeing modules losing that sensitivity, it would basically require that the module contain the original pre-preprocessed source. Or shipping an awkward - and growing - number of module files. For the time being I see modules as a nice idea that still needs lots of work. Plus, there are things that can be done with includes that as far as I'm aware modules simply don't support (Boost.Preprocessor's iteration facility as an example). On 5/13/22, John Maddock via Boost <boost(a)lists.boost.org> wrote: > >> If they ever are. >> >> Modules can work for leaf libraries, but for libraries used as >> dependencies >> by other libraries, you'll encounter a situation where the same >> translation >> unit imports boost.lib or "boost/lib.hpp" in one place and then includes >> "boost/lib/something.hpp" in another, which is probably never going to >> work correctly. >> >> I suppose it might stand a chance if all the imports are done first, so >> that >> the include guard macros are defined. But I think that's not going to work >> in practice either. >> >> Basically, all Regex consumers also must respect the REGEX_AS_MODULE >> macro and switch to `import boost.regex`. Repeat per every library. > > Modules don't expose macros, so there is no way to signal "this must be > used as a module", so you have to find every usage of library X and make > sure they are either all modules or all includes.? Or at least that > anything included doesn't use import: the other way around is fine since > the include is hidden within the module. > > John. > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- Soronel Haetir soronel.haetir(a)gmail.com ------------------------------ Message: 3 Date: Sat, 14 May 2022 08:45:53 +1000 From: Benedict Bede McNamara <benedict(a)gigasopht.net> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Subject: [boost] The Future of C++ Modules Message-ID: <1652481962361.5bcfb010425513a2(a)gigasopht.net> Content-Type: text/plain; charset="utf-8" On 5/13/22 5:24 AM, Peter Dimov via Boost wrote: >> John Maddock wrote: >> I'm afraid my conclusion is that modules are simply not yet ready for >> prime time. >> >> If they ever are. >> >> Modules can work for leaf libraries, but for libraries used as dependencies >> by other libraries, you'll encounter a situation where the same translation >> unit imports boost.lib or "boost/lib.hpp" in one place and then includes >> "boost/lib/something.hpp" in another, which is probably never going to >> work correctly. >This is sounds like how I thought it had to work to be effective. If I >understand this correctly, the whole modules concept is in fundamental >conflict with the anything which uses the boost inclusion/dependency >model - which is every module includes what it uses and nothing else. >In my view the whole modules idea is misconceived. One more nail in >coffin of C++ xx standard libraries. >It's time for use to seriously start moving on. >Robert Ramey You can?t be serious. I have used modules in I++ and they function perfectly. C++ was kind of dodgy with its use of the pre-processor. Modules re-establish C++ as being the predominant language of its time. It is C++ that ?has moved on? from where Boost is at present. Boost is running at least 2 years behind the standard and It risks becoming irrelevant if it remains there for much longer. Sent from Mail for Windows From: boost-request(a)lists.boost.org Sent: Saturday, 14 May 2022 8:19 AM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6704, Issue 5 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: cstring_view (Peter Dimov) 2. Re: cstring_view (Marshall Clow) 3. Re: cstring_view (Peter Dimov) 4. Re: cstring_view (Marshall Clow) 5. Re: cstring_view (Peter Dimov) 6. Re: cstring_view (Rainer Deyke) 7. Re: cstring_view (David Bien) 8. Re: MySql review (Rainer Deyke) 9. Re: The Future of C++ and Boost - C++ Modules (Robert Ramey) 10. Re: The Future of C++ and Boost - C++ Modules (Peter Dimov) 11. Re: cstring_view (Marshall Clow) 12. Re: cstring_view (Peter Dimov) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 May 2022 21:09:47 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <01d201d866f4$a330d710$e9928530$(a)gmail.com> Content-Type: text/plain; charset="utf-8" David Bien wrote: > I guess when I read the impl I think to myself: What this is missing is a _length > member. But then it just becomes boost::string_view. > > What value added is there to this impl except that it is smaller than > boost::string_view due to lacking a _length member? Please see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1402r0.pdf No idea why this particular implementation doesn't store the size. I would. ------------------------------ Message: 2 Date: Fri, 13 May 2022 11:14:13 -0700 From: Marshall Clow <mclow.lists(a)gmail.com> To: Boost Developers List <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <DFCD5BFF-F7CA-46CC-82DF-833CE68CB0F0(a)gmail.com> Content-Type: text/plain; charset=utf-8 On May 13, 2022, at 10:42 AM, David Bien via Boost <boost(a)lists.boost.org> wrote: > > I guess when I read the impl I think to myself: What this is missing is a _length member. But then it just becomes boost::string_view. > > What value added is there to this impl except that it is smaller than boost::string_view due to lacking a _length member? If you?re careful and don?t do much with it, it can hand you back a null terminated string. ? Marshall PS. I note that P1402 (the paper proposing cstring_view for the standard) was was reviewed by LEWG in 2019, and the resolution of that group was "We will not pursue P1402R0 or this problem space? ------------------------------ Message: 3 Date: Fri, 13 May 2022 21:18:24 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <01d301d866f5$d6cfe880$846fb980$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Marshall Clow wrote: > On May 13, 2022, at 10:42 AM, David Bien via Boost <boost(a)lists.boost.org> > wrote: > > > > I guess when I read the impl I think to myself: What this is missing is a > _length member. But then it just becomes boost::string_view. > > > > What value added is there to this impl except that it is smaller than > boost::string_view due to lacking a _length member? > > If you?re careful and don?t do much with it, it can hand you back a null > terminated string. ??? In what scenarios will it not give you a null-terminated string? ------------------------------ Message: 4 Date: Fri, 13 May 2022 11:39:37 -0700 From: Marshall Clow <mclow.lists(a)gmail.com> To: Peter Dimov <pdimov(a)gmail.com> Cc: Boost Developers List <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <F5FB00FB-3576-47CF-8BEA-FFD90C2C74F0(a)gmail.com> Content-Type: text/plain; charset=utf-8 On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > > Marshall Clow wrote: >> On May 13, 2022, at 10:42 AM, David Bien via Boost <boost(a)lists.boost.org> >> wrote: >>> >>> I guess when I read the impl I think to myself: What this is missing is a >> _length member. But then it just becomes boost::string_view. >>> >>> What value added is there to this impl except that it is smaller than >> boost::string_view due to lacking a _length member? >> >> If you?re careful and don?t do much with it, it can hand you back a null >> terminated string. > > ??? > > In what scenarios will it not give you a null-terminated string? char arr[6] = ?hello"; cstring_view csv(arr); assert(strlen(csv.data())) == 5); arr[5] = ?!?; assert(strlen(csv.data())) == 5); // boom ? Marshall PS. It promises to give you a null-terminated string, but has no way to actually guarantee that. ------------------------------ Message: 5 Date: Fri, 13 May 2022 21:57:39 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: "'Marshall Clow'" <mclow.lists(a)gmail.com> Cc: "'Boost Developers List'" <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <01df01d866fb$52ff30f0$f8fd92d0$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Marshall Clow wrote: > >> If you?re careful and don?t do much with it, it can hand you back a > >> null terminated string. > > > > ??? > > > > In what scenarios will it not give you a null-terminated string? > > char arr[6] = ?hello"; > cstring_view csv(arr); > assert(strlen(csv.data())) == 5); > arr[5] = ?!?; > assert(strlen(csv.data())) == 5); // boom The main use of cstring_view, like string_view, is as a parameter (and return) type. So if you have a function void f1( cstring_view csv ); it's true that if inside f1 you write to some random character this may invalidate csv's promise to be null-terminated, but I see little salient difference between this and void f2( char const* csv ); // pre: csv is null-terminated char seq where f2 writing to a carefully chosen char may also invalidate the precondition. Typing "cstring_view" is merely a different way of spelling out the "pre" of f2. Similarly, cstring_view g1(); is an alternative way of spelling char const* g2(); // post: the return value is a null-terminated char seq ------------------------------ Message: 6 Date: Fri, 13 May 2022 21:29:06 +0200 From: Rainer Deyke <rdeyke(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] cstring_view Message-ID: <t5mbi2$42u$1(a)ciao.gmane.io> Content-Type: text/plain; charset=UTF-8; format=flowed On 13.05.22 20:39, Marshall Clow via Boost wrote: > On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: >> In what scenarios will it not give you a null-terminated string? > > char arr[6] = ?hello"; > cstring_view csv(arr); > assert(strlen(csv.data())) == 5); > arr[5] = ?!?; > assert(strlen(csv.data())) == 5); // boom > > ? Marshall > > PS. It promises to give you a null-terminated string, but has no way to actually guarantee that. That's an issue with views in general, not just cstring_view. std::string s = "hello"; string_view sv = s; assert(sv.size() == 5); s += "!"; assert(sv.size() == 5); // boom It is the responsibility of the creator of a view to ensure that the object being viewed does not change in a way that breaks the invariants of the view while the view is in use. -- Rainer Deyke (rainerd(a)eldwood.com) ------------------------------ Message: 7 Date: Fri, 13 May 2022 18:20:40 +0000 From: David Bien <davidbien(a)hotmail.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Cc: Peter Dimov <pdimov(a)gmail.com> Subject: Re: [boost] cstring_view Message-ID: <MWHPR1801MB1934DE34D9E7AE1678101098B1CA9(a)MWHPR1801MB1934.namprd18.prod.outlook.com> Content-Type: text/plain; charset="Windows-1252" Exactly. But then it should just be called cstring_wrapper ? calling it cstring_view seems to impart qualities to it that it doesn?t have ? like I would assume that I could get a cstring_view that is a subview of an existing cstring_view for instance. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: Peter Dimov via Boost<mailto:boost@lists.boost.org> Sent: Friday, May 13, 2022 12:19 PM To: boost(a)lists.boost.org<mailto:boost@lists.boost.org> Cc: Peter Dimov<mailto:pdimov@gmail.com> Subject: Re: [boost] cstring_view Marshall Clow wrote: > On May 13, 2022, at 10:42 AM, David Bien via Boost <boost(a)lists.boost.org> > wrote: > > > > I guess when I read the impl I think to myself: What this is missing is a > _length member. But then it just becomes boost::string_view. > > > > What value added is there to this impl except that it is smaller than > boost::string_view due to lacking a _length member? > > If you?re careful and don?t do much with it, it can hand you back a null > terminated string. ??? In what scenarios will it not give you a null-terminated string? _______________________________________________ Unsubscribe & other changes: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boos… ------------------------------ Message: 8 Date: Fri, 13 May 2022 21:37:36 +0200 From: Rainer Deyke <rdeyke(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] MySql review Message-ID: <t5mc20$87r$1(a)ciao.gmane.io> Content-Type: text/plain; charset=UTF-8; format=flowed On 13.05.22 17:23, Phil Endecott via Boost wrote: > The aim should be "secure by default". Users are lazy. The > particular danger in this case is that they do an initial test with > the password in the source, and then move it somewhere secure later, > but the password is still exposed in their revision control history. > At this point in history, there is no excuse to repeat the mistakes > that have lead to really very serious security problems in the past. > Make the default mechanism, and the first one that you describe in > the docs, the most secure one. Looking for credentials in a file on disk may be more secure than embedding the credentials in code, but it is most definitely the most secure mechanism. The most secure mechanism is to always ask the user at program start-up. Or better yet, ask each time a connection is created, and then immediately wipe the credentials from RAM in order to mitigate RAM scanning attacks. -- Rainer Deyke (rainerd(a)eldwood.com) ------------------------------ Message: 9 Date: Fri, 13 May 2022 12:33:50 -0700 From: Robert Ramey <ramey(a)rrsd.com> To: Peter Dimov via Boost <boost(a)lists.boost.org> Subject: Re: [boost] The Future of C++ and Boost - C++ Modules Message-ID: <4134c080-20bb-16d2-ff81-0c6b6dc52d75(a)rrsd.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 5/13/22 5:24 AM, Peter Dimov via Boost wrote: > John Maddock wrote: >> I'm afraid my conclusion is that modules are simply not yet ready for >> prime time. > > If they ever are. > > Modules can work for leaf libraries, but for libraries used as dependencies > by other libraries, you'll encounter a situation where the same translation > unit imports boost.lib or "boost/lib.hpp" in one place and then includes > "boost/lib/something.hpp" in another, which is probably never going to > work correctly. This is sounds like how I thought it had to work to be effective. If I understand this correctly, the whole modules concept is in fundamental conflict with the anything which uses the boost inclusion/dependency model - which is every module includes what it uses and nothing else. In my view the whole modules idea is misconceived. One more nail in coffin of C++ xx standard libraries. It's time for use to seriously start moving on. Robert Ramey ------------------------------ Message: 10 Date: Sat, 14 May 2022 00:16:26 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] The Future of C++ and Boost - C++ Modules Message-ID: <01f501d8670e$b57a64d0$206f2e70$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Robert Ramey wrote: > On 5/13/22 5:24 AM, Peter Dimov via Boost wrote: > > John Maddock wrote: > > >> I'm afraid my conclusion is that modules are simply not yet ready for > >> prime time. > > > > If they ever are. > > > > Modules can work for leaf libraries, but for libraries used as > > dependencies by other libraries, you'll encounter a situation where > > the same translation unit imports boost.lib or "boost/lib.hpp" in one > > place and then includes "boost/lib/something.hpp" in another, which is > > probably never going to work correctly. > > This is sounds like how I thought it had to work to be effective. If I understand > this correctly, the whole modules concept is in fundamental conflict with the > anything which uses the boost inclusion/dependency model - which is every > module includes what it uses and nothing else. > > In my view the whole modules idea is misconceived. One more nail in coffin of > C++ xx standard libraries. > > It's time for use to seriously start moving on. Looks like I was mistaken, though. At least with header units, i.e. `import "boost/lib.hpp"`, it all seems to "just work" under MSVC. That is, the compiler automatically merges the identical definitions from the sub-#includes. ------------------------------ Message: 11 Date: Fri, 13 May 2022 15:16:19 -0700 From: Marshall Clow <mclow.lists(a)gmail.com> To: Boost Developers List <boost(a)lists.boost.org> Cc: Rainer Deyke <rdeyke(a)gmail.com> Subject: Re: [boost] cstring_view Message-ID: <3C70E2E0-DC7A-4263-9D93-FCD8220A39BE(a)gmail.com> Content-Type: text/plain; charset=utf-8 On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost <boost(a)lists.boost.org> wrote: > > On 13.05.22 20:39, Marshall Clow via Boost wrote: >> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: >>> In what scenarios will it not give you a null-terminated string? >> char arr[6] = ?hello"; >> cstring_view csv(arr); >> assert(strlen(csv.data())) == 5); >> arr[5] = ?!?; >> assert(strlen(csv.data())) == 5); // boom >> ? Marshall >> PS. It promises to give you a null-terminated string, but has no way to actually guarantee that. > > That's an issue with views in general, not just cstring_view. > > std::string s = "hello"; > string_view sv = s; > assert(sv.size() == 5); > s += "!"; > assert(sv.size() == 5); // boom I don?t see the problem here (and when I run the code I get no error - after adding the missing ?std::'). No assertion failure; no undefined behavior (unlike the cstring_view example) ? Marshall ------------------------------ Message: 12 Date: Sat, 14 May 2022 01:19:33 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <01fc01d86717$873b2a60$95b17f20$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Marshall Clow wrote: > On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost > <boost(a)lists.boost.org> wrote: > > > > On 13.05.22 20:39, Marshall Clow via Boost wrote: > >> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost > <boost(a)lists.boost.org> wrote: > >>> In what scenarios will it not give you a null-terminated string? > >> char arr[6] = ?hello"; > >> cstring_view csv(arr); > >> assert(strlen(csv.data())) == 5); > >> arr[5] = ?!?; > >> assert(strlen(csv.data())) == 5); // boom ? Marshall PS. It > >> promises to give you a null-terminated string, but has no way to actually > guarantee that. > > > > That's an issue with views in general, not just cstring_view. > > > > std::string s = "hello"; > > string_view sv = s; > > assert(sv.size() == 5); > > s += "!"; > > assert(sv.size() == 5); // boom > > I don?t see the problem here (and when I run the code I get no error - after > adding the missing ?std::'). > > No assertion failure; no undefined behavior (unlike the cstring_view example) Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates, `sv` would be left dangling. ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6704, Issue 5 ************************************** ------------------------------ Message: 4 Date: Sat, 14 May 2022 10:43:09 +0800 From: Klemens Morgenstern <klemens.morgenstern(a)gmx.net> To: boost(a)lists.boost.org Subject: Re: [boost] cstring_view Message-ID: <7b7ece8b46b77ced2a9826a273c5df0ea36ca14a.camel(a)gmx.net> Content-Type: text/plain; charset="UTF-8" On Fri, 2022-05-13 at 21:09 +0300, Peter Dimov via Boost wrote: > David Bien wrote: > > I guess when I read the impl I think to myself: What this is > > missing is a _length > > member. But then it just becomes boost::string_view. > > > > What value added is there to this impl except that it is smaller > > than > > boost::string_view due to lacking a _length member? > > Please see > > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1402r0.pdf > > No idea why this particular implementation doesn't store the size. I > would. I want to use it as a small wrapper around system-APIs, that can be implicitly constructed from any matching string type, e.g. boost::static_string as well as const char *. `strlen` would just be unnecessary. void set_env(cstring_view name, cstring_view value, error_code & ec) { auto e = ::setenv(name.c_str(), value.c_str()); if (!e) ec = some_error; } Using strlen seems unnecessary to me. I also stripped out most of the functions to just have a bare-bone view of a cstring in the PR I submitted: https://github.com/boostorg/utility/pull/100 Basic idea being: provide whatever you can do on a null terminated string, for anything more just use a string_view. I don't think there's much utility to the cstring_view outside of interaction with C-APIs. ------------------------------ Message: 5 Date: Sat, 14 May 2022 09:45:23 +0200 From: Rainer Deyke <rdeyke(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] cstring_view Message-ID: <t5nmmk$1266$1(a)ciao.gmane.io> Content-Type: text/plain; charset=UTF-8; format=flowed On 14.05.22 00:42, Marshall Clow via Boost wrote: > > >> On May 13, 2022, at 3:19 PM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: >> >> Marshall Clow wrote: >>> On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost >>> <boost(a)lists.boost.org> wrote: >>>> That's an issue with views in general, not just cstring_view. >>>> >>>> std::string s = "hello"; >>>> string_view sv = s; >>>> assert(sv.size() == 5); >>>> s += "!"; >>>> assert(sv.size() == 5); // boom >>> >>> I don?t see the problem here (and when I run the code I get no error - after >>> adding the missing ?std::'). >>> >>> No assertion failure; no undefined behavior (unlike the cstring_view example) >> >> Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates, >> `sv` would be left dangling. > > Agreed. > But even if the string *did* reallocate, the call "assert(sv.size() == 5)? is still valid and well defined. No it's not. sv.size() works by subtracting pointers, and it's only legal to subtract two pointers if they point into the same memory region. Which sv.begin() and sv.end() no longer do if s reallocates. It's subtle, but it's definitely undefined behavior. -- Rainer Deyke (rainerd(a)eldwood.com) ------------------------------ Message: 6 Date: Sat, 14 May 2022 10:14:18 +0200 From: Mike <mike.dev(a)gmx.de> To: boost(a)lists.boost.org Cc: mike.dev(a)gmx.de Subject: Re: [boost] The Future of C++ and Boost - C++ Modules Message-ID: <trinity-12e97b7f-9414-4767-8bcc-af0db788a334-1652516058595@3c-app-gmx-bs70> Content-Type: text/plain; charset=UTF-8 > Gesendet: Freitag, 13. Mai 2022 um 22:43 Uhr > Von: "Soronel Haetir via Boost" <boost(a)lists.boost.org> > > What I've noticed with modules (trying with MSVC) is that they are > incredibly sensitive to compiler settings. What do you mean by that? Best Mike ------------------------------ Message: 7 Date: Sat, 14 May 2022 10:31:20 +0200 From: Daniela Engert <dani(a)ngrt.de> To: boost(a)lists.boost.org Subject: Re: [boost] cstring_view Message-ID: <9bafc2cf-6bfe-ad96-7a5d-075e71e9aae3(a)ngrt.de> Content-Type: text/plain; charset=UTF-8; format=flowed Am 14.05.2022 um 09:45 schrieb Rainer Deyke via Boost: > On 14.05.22 00:42, Marshall Clow via Boost wrote: >> >> >>> On May 13, 2022, at 3:19 PM, Peter Dimov via Boost >>> <boost(a)lists.boost.org> wrote: >>> >>> Marshall Clow wrote: >>>> On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost >>>> <boost(a)lists.boost.org> wrote: >>>>> That's an issue with views in general, not just cstring_view. >>>>> >>>>> std::string s = "hello"; >>>>> string_view sv = s; >>>>> assert(sv.size() == 5); >>>>> s += "!"; >>>>> assert(sv.size() == 5); // boom >>>> >>>> I don?t see the problem here (and when I run the code I get no >>>> error - after >>>> adding the missing ?std::'). >>>> >>>> No assertion failure; no undefined behavior (unlike the >>>> cstring_view example) >>> >>> Only because "hello!" fits into the small buffer, I suspect. If `s` >>> reallocates, >>> `sv` would be left dangling. >> >> Agreed. >> But even if the string *did* reallocate, the call "assert(sv.size() >> == 5)? is still valid and well defined. > > No it's not.? sv.size() works by subtracting pointers, and it's only > legal to subtract two pointers if they point into the same memory > region.? Which sv.begin() and sv.end() no longer do if s reallocates. > It's subtle, but it's definitely undefined behavior. > Not really. The standard (in its current draft) is silent about the invalidation of size() and talks only about iterators, references and pointers with respect to the viewed object [string.view.template.general]/2. On top of that, afaik all major implementations have agreed on and settled on the same structure layout as shown in the standard as exposition only. So technically, this is unspecified. Ciao ? Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5 ------------------------------ Message: 8 Date: Sat, 14 May 2022 16:44:05 +0800 From: Klemens Morgenstern <klemens.morgenstern(a)gmx.net> To: boost(a)lists.boost.org Subject: Re: [boost] cstring_view Message-ID: <e9645d5ed8a1a265816998bb521f74e0722369dc.camel(a)gmx.net> Content-Type: text/plain; charset="UTF-8" On Fri, 2022-05-13 at 18:20 +0000, David Bien via Boost wrote: > Exactly. But then it should just be called cstring_wrapper ? calling > it cstring_view seems to impart qualities to it that it doesn?t have > ? like I would assume that I could get a cstring_view that is a > subview of an existing cstring_view for instance. > That's a fair point, I was thinking about naming it cstring_ref originally. The Paper reference by Peter made me reconsider. With cstring_ref, someone else could write a cstring_view that also contains the size. Do however note that you can get that subview if the result is still a cstring. Thus obly moving the start of the cstring works. ------------------------------ Message: 9 Date: Sat, 14 May 2022 10:58:29 +0200 From: Richard Hodges <hodges.r(a)gmail.com> To: "boost(a)lists.boost.org List" <boost(a)lists.boost.org>, boost-announce(a)lists.boost.org Subject: [boost] Boost MySQL Review Is In Progress Message-ID: <CALvx3hYe3DW8POaFb-k5smQpGzL6S6UNi5bMy8Gxfc5sW70C0w(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Dear All, We've had a good response for calls to review this much anticipated library, and there is a lot of interest on Reddit: https://www.reddit.com/r/cpp/comments/unik91/acceptance_review_for_boostmys… . In general the public perception of utility libraries like this in Boost seems popular, and Boost's emphasis on quality is often mentioned. If you are able, I would be more than grateful if you could take a few hours over this delightful weekend to offer a review. The more eyes on this project the better, as if it is successful, it will no doubt prompt submission of similar libraries targeting other popular database and messaging systems. The Boost formal review of the MySQL library started on May 10th, 2022 and will conclude on May 19th, 2022 (inclusive) - In fact, I am able to accept submissions up until the (GMT) morning of May 20th as I'll be traveling on May19th. The library is authored by Rub?n P?rez Hidalgo (@anarthal in the CppLang slack). Documentation: https://anarthal.github.io/mysql/index.html Source: https://github.com/anarthal/mysql/ The library is built on the bedrock of Boost.Asio and provides both synchronous and asynchronous client connectors for the MySQL database system. Boost.MySQL is written from the ground up, implementing the entire protocol with no external dependencies beyond the Boost library. It is compatible with MariaDB. Connectivity options include TCP, SSL and Unix Sockets. For async interfaces, examples in the documentation demonstrate full compatibility with all Asio completion handler styles, including: Callbacks:- https://anarthal.github.io/mysql/mysql/examples/query_async_callbacks.html Futures :- https://anarthal.github.io/mysql/mysql/examples/query_async_futures.html Boost.Coroutine :- https://anarthal.github.io/mysql/mysql/examples/query_async_coroutines.html C++20 Coroutines :- https://anarthal.github.io/mysql/mysql/examples/query_async_coroutinescpp20… Rub?n has also implemented the Asio protocols for deducing default completion token types :- https://anarthal.github.io/mysql/mysql/examples/default_completion_tokens.h… Reviewing a database connector in depth will require setting up an instance of a MySQL database. Fortunately most (all?) Linux distributions carry a MySQL and/or MariaDB package. MySQL community edition is available for download on all platforms here: https://dev.mysql.com/downloads/ Rub?n has spent quite some time in order to bring us this library candidate. The development process has no doubt been a journey of discovery into Asio, its concepts and inner workings. I am sure he has become a fount of knowledge along the way. >From a personal perspective, I was very happy to be asked to manage this review. I hope it will be the first of many more reviews of libraries that tackle business connectivity problems without further dependencies beyond Boost, arguably one of the most trusted foundation libraries available. Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Describe as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - Will the library bring additional out-of-the-box utility to Boost? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - Will the choice of API abstraction model ease the development of software that must talk to a MySQL database? - Are there any immediate improvements that could be made after acceptance, if acceptance should happen? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.MySQL library Rub?n is often available on CppLang Slack and of course by email should you require any clarification not covered by the documentation, as am I. -- Richard Hodges hodges.r(a)gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212 ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6705, Issue 1 **************************************

1 0

cstring_view
by Klemens Morgenstern 14 May '22

14 May '22

Hi y'all, I've hacked together a cstring_view class and would like to ask if it could be included in boost.utility or boost.core. https://gist.github.com/klemens-morgenstern/fc02dab8b37fc77ac80efbca30f297cf The main motivation is to have a view that works with C-APIs. I also need the char_traits for dealing with odd char semantics for some system APIs. (e.g. environment keys on windows are char-insensitive but preserving).

7 20

Re: [boost] Boost Digest, Vol 6704, Issue 1 - The Future of C++ and Boost - C++ Modules
by Benedict Bede McNamara 14 May '22

14 May '22

I believe that modules are so important that you should drop everything and aim to release a modular version of Boost. I believe this because I used Boost’s serialization to write the General Theory of Databases in C++ (I already had that theory in C# and Java). While that succeeded I upgraded I++ to use C++ Modules. I couldn’t get Boost’s header based system working with the modular form of databases. So I had to drop Boost altogether. I believe that if Boost is to remain relevant it must be expressed in Modular Form immediately. You should target a release for a week or two in the future. I sent Boost a starting module of about 15,000 lines of code. It compiles OK but needs work to link. You can pack the entire Boost library into a single .ixx file. You should target Microsoft’s compiler first then expand support as other compilers implement modules. That is, you should aim to make a quantum leap to ISO C++ 20 standard immediately. Cheers, Benedict Bede McNamara, 1st Class Honours, Pure Mathematics. From: boost-request(a)lists.boost.org Sent: Friday, 13 May 2022 12:24 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6704, Issue 1 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: MySql review (Ruben Perez) 2. Re: Review of Boost.MySql (Ruben Perez) 3. Re: Future of C++ and Boost (Andrey Semashev) 4. Re: Future of C++ and Boost (Gavin Lambert) 5. Re: Boost MySQL Review Starts Today (Alan de Freitas) ---------------------------------------------------------------------- Message: 1 Date: Thu, 12 May 2022 20:50:22 +0200 From: Ruben Perez <rubenperez038(a)gmail.com> To: boost(a)lists.boost.org Cc: Phil Endecott <spam_from_boost_dev(a)chezphil.org> Subject: Re: [boost] MySql review Message-ID: <CACR-md+=90n+Eh1HNCnDQNHcBtfKgYrohg3O-HryL6Wyts8_pA(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Wed, 11 May 2022 at 20:23, Phil Endecott via Boost <boost(a)lists.boost.org> wrote: > > Here is my review of Ruben Perez's proposed MySql library. Hi Phil, thank you for taking your time to write a review. > > Background > ---------- > > I have previously implemented C++ wrappers for PostgreSQL and > SQLite, so I have some experience of what an SQL API can look > like. I know little about ASIO. > > I have also recently used the AWS SDKs for C++ and Javascript to > talk to DynamoDB; this has async functionality, which is interesting > to compare. > > I confess some minor disappointment that MySql, rather than > PostgreSQL or SQLite, is the subject of this first Boost database > library review, since those others have liberal licences that > are closer to Boost's own licence than MySql (and MariaDB). But > I don't think that should be a factor in the review. > > > Trying the library > ------------------ > > I have tried using the library with > > - g++ 10.2.1, Arm64, Debian Linux > - ASIO from Boost 1.74 (Debian packages) > - Amazon Aurora MySql-compatible edition > > I've written a handful of simple test programs. Everything works > as expected. Compilation times are a bit slow but not terrible. > > > > The remainder of this review approximately follows the structure > of the library documentation. > > > Introduction > ------------ > > I note that "Ease of use" is claimed as the first design goal, > which is good. I think I failed to make the scope of the library clear enough in this aspect. The library is supposed to be pretty low level and close to the protocol, and not an ORM. I list ease of use here in the sense that * I have tried to abstract as much of the oddities of the protocol as possible (e.g. text and binary encodings). * The library takes care of SSL as part of the handshake, vs having the user have to take care of it. * The library provides helper connect() and close() functions to make things easier. * The object model is as semantic as I have been able to achieve, vs. having a connection object and standalone functions. * The value class offers stuff like conversions to make some use-cases simpler. I guess I listed that point in comparison to Beast or Asio, which are even lower level. Apologies if it caused confusion. > > I feel that some mention should be made of the existing C / C++ > APIs and their deficiencies. You should also indicate whether or > not the network protocol you are using to communicate with the > server is a "public" interface with some sort of stability > guarantee. (I guess maybe it is, if it is common to MySql and > MariaDB.) Updated https://github.com/anarthal/mysql/issues/50 on comparison with other APIs. The network protocol is public and documented (although the documentation is pretty poor). It's indeed a pretty old protocol that is not being extended right now, and it's widely used by a lot of clients today, so there is very little risk there. > > > Tutorial > -------- > > The code fragments should start with the necessary #includes, > OR you should prominently link to the complete tutorial source > code at the start. Raised https://github.com/anarthal/mysql/issues/71 to track it. > > You say that "this tutorial assumes you have a basic familiarity > with Boost.Asio". I think that's unfortunate. It should be > possible for someone to use much of the library's functionality > knowing almost nothing about ASIO. Remember your design goal of > ease-of-use. In fact, it IS possible to follow the tutorial with > almost no knowledge of ASIO because I have just done so. If you are to really take advantage of the library (i.e. use the asynchronous API), you will need some Asio familiarity. I'd say a very basic understanding is enough (i.e. knowing what a io_context is). If you think this comment is misleading, I can remove it. But I don't think this is the right place to provide a basic Asio tutorial. > > You have this boilerplate at the start of the tutorial: > > boost::asio::io_context ctx; > boost::asio::ssl::context ssl_ctx (boost::asio::ssl::context::tls_client); > boost::mysql::tcp_ssl_connection conn (ctx.get_executor(), ssl_ctx); > boost::asio::ip::tcp::resolver resolver (ctx.get_executor()); > auto endpoints = resolver.resolve(argv[3], boost::mysql::default_port_string); > boost::mysql::connection_params params ( > argv[1], // username > argv[2] // password > ); > conn.connect(*endpoints.begin(), params); > // I guess that should really be doing something more > // intelligent than just trying the first endpoint, right? The way to go here is providing an extra overload for connection::connect. Raised https://github.com/anarthal/mysql/issues/72 to track it. > > I would like to see a convenience function that hides all of that: > > auto conn = boost::mysql::make_connection( ...params... ); > > I guess this will need to manage a global, private, ctx object > or something. If you take a look to any other asio-based program, the user is always in charge of creating the io_context, and usually in charge of creating the SSL context, too. If you take a look to this Boost.Beast example, you will see similar stuff: https://www.boost.org/doc/libs/1_79_0/libs/beast/example/http/client/sync-s… I'm not keen on creating a function that both resolves the hostname and connects the connection, as I think it encourages doing more name resolution than really required (you usually have one server but multiple connections). I may be wrong though, so I'd like to know what the rest of the community thinks on this. > .port = 3306, // why is that a string in yours? It is not "mine", it's just how Asio works. Please have a look at https://www.boost.org/doc/libs/1_79_0/doc/html/boost_asio/reference/ip__bas… > make_connection("mysql://admin:12345@hostname:3306/dbname"); I guess you're suggesting that make_connection also perform the name resolution, the physical connect and the MySQL handshake? I'm not against this kind of URL-based way of specifying parameters. I've used it extensively in other languages. May be worth reconsidering it once Vinnie's Boost.Url gets accepted. > > Now... why the heck does your connection_params struct use > string_views? That ought to be a Regular Type, with Value > Semantics, using std::strings. Is this the cult of not using > strings because "avoid copying above all else"? I may have been a little too enthusiastic about optimization here. > > Another point about the connection parameters: you should > provide a way to supply credentials without embedding them > in the source code. You should aim to make the secure option > the default and the simplest to use. I suggest that you > support the ~/.my.cnf and /etc/my.cnf files and read passwords > etc. from there, by default. You might also support getting > credentials from environment variables or by parsing the > command line. You could even have it prompt for a password. I don't know of any database access library that does this. The official Python connector gets the password from a string. I think this is mixing concerns. Having the password passed as a string has nothing to do with having it embedded in the source code. Just use std::getenv, std::stdin or whatever mechanism your application needs and get a string from there, then pass it to the library. All the examples read the password from argv. Additionally, having passwords in plain text files like ~/.my.cnf and /etc/my.cnf is considered bad practice in terms of security, I wouldn't encourage it. > > Does MySQL support authentication using SSL client certs? > I try to use this for PostgreSQL when I can. If it does, you > should try to support that too. AFAIK you can make the server validate the client's certificate (that doesn't require extra library support), but you still have to pass a password. > > About two thirds of the way through the tutorial, it goes from > "Hello World" to retrieving "employees". Please finish the hello > world example with code that gets the "Hello World" string > from the results and prints it. My bad, that's a naming mistake - it should be named hello_resultset, instead. It's doing the right thing with the wrong variable name. Updated https://github.com/anarthal/mysql/issues/71 > > > Queries > ------- > > I encourage you to present prepared queries first in the > documentation and to use them almost exclusively in the tutorial > and examples. It can definitely make sense. > > You say that "client side query composition is not available". > What do you mean by "query composition"? I think you mean > concatenating strings together'); drop table users; -- to > form queries, right? Is that standard MySql terminology? I > suggest that you replace the term with something like > "dangerous string concatenation". Yes, I mean that. > > In any case, that functionality *is* available, isn't it! > It's trivial to concatenate strings and pass them to your > text query functions. You're not doing anything to block that. > So what you're really saying is that you have not provided any > features to help users do this *safely*. I think that's a serious > omission. It would not be difficult for you to provide an > escape_for_mysql_quoted_string() function, rather than having > every user roll their own slightly broken version. Definitely not trivial (please have a look at MySQL source code) but surely beneficial, see below. Tracked by https://github.com/anarthal/mysql/issues/69. > > IIRC, in PostgreSQL you can only use prepared statements > for SELECT, UPDATE, INSERT and DELETE statements; if you > want to do something like > > ALTER TABLE a ALTER COLUMN c SET DEFAULT = ? > or CREATE VIEW v as SELECT * FROM t WHERE c = ? You are right, these cases aren't covered by prepared statements. https://github.com/anarthal/mysql/issues/69 tracks it. > tcp_ssl_prepared_statement is verbose. Why does the prepared > statement type depend on the underlying connection type? Because it implements I/O operations (execute() and close()), which means that it needs access to the connection object, thus becoming a proxy object. > I have to change it if I change the connection type?! If that's > unavoidable, I suggest putting a type alias in the connection > type: > > connection_t conn = ....; > connection_t::prepared_statement stmt(.....); Raised https://github.com/anarthal/mysql/issues/73 > > Does MySql allow numbered or named parameters? SQLite supports > ?1 and :name; I think PostgreSQL uses $n. Queries with lots of > parameters are error-prone if you just have ?. If MySql does > support this, it would be good to see it used in some of the > examples. Not AFAIK, just regular positional placeholders. > > Invoking the prepared statement seems unnecessarily verbose. > Why can't I just write > > auto result = my_query("hello", "world", 42); Because this invokes a network operation. By Asio convention, you need a pair of sync functions (error codes and exceptions) and at least an async function, that is named the same as the sync function but with the "_async" suffix. I'm not against this kind of signature, building on top of what there already is: statement.execute("hello", "world", 42); statement.async_execute("hello", "world", 42, use_future); Which saves you a function call. Raised https://github.com/anarthal/mysql/issues/74 > > I also added Query variants where the result is expected to be > > - A single value, e.g. a SELECT COUNT(*) statement. > - Empty, e.g. INSERT or DELETE. > - A single row. > - Zero or one rows . > - A single column. I think this can be useful. I've updated https://github.com/anarthal/mysql/issues/22 to track this. > I don't see anything about the result of an INSERT or UPDATE. > PostgreSQL tells me the number of rows affected, which I have > found useful to return to the application. Please have a look at https://anarthal.github.io/mysql/mysql/resultsets.html#mysql.resultsets.com… > > > resultset, row and value > ------------------------ > > I'm not enthusiastic about the behaviour nor the names of these > types: Resultset is how MySQL calls it. It's not my choice. > > - resultset is not a set of results. It's more like a sequence of > rows. But more importantly, it's lazy; it's something like an > input stream, or an input range. So why not actually make it > an input range, i.e. make it "a model of the input_range concept". > Then we could write things like: > > auto result = ...execute query... > for (auto&& row: result) { > ... > } How does this translate to the async world? > > - row: not bad, it does actually represent a row; it's a shame > it's not a regular type though. > > - value: it's not a value! It doesn't have value semantics! If the library gets rejected I will likely make values owning (regular). > I'm also uncertain that a variant for the individual values > is the right solution here. All the values in a column should > have the same type, right? (Though some can be null.) So I > would make row a tuple. Rather than querying individual values > for their type, have users query the column. Are you talking about something like this? https://github.com/anarthal/mysql/issues/60 > > It seems odd that MySQL small integers all map to C++ 64-bit > types. It is done like this to prevent the variant from having too many alternatives - I don't think having that would add much value to the user. If I implement something like https://github.com/anarthal/mysql/issues/60, each int type will be mapped to its exact type. > > I use NUMERIC quite a lot in PostgreSQL; I don't know if the > MySql type is similar. I would find it inconvenient that it > is treated as a string. Can it not be converted to a numeric > type, if that is what the user wants? MySQL treats NUMERIC and DECIMAL the same, as exact numeric types. What C++ type would you put this into? float and double are not exact so they're not fit. > I seem to get an assertion if I fail to read the resultset > (resultset.hpp:70). Could this throw instead? This assertion is not related to this. It's just checking that the resultset has a valid connection behind it, and is not a default constructed (invalid) resultset. > > Or, should the library read and discard the unread results > in this case? Having a look into the Python implementation, it gives the option to do that. I think we can do a better job here. Track by https://github.com/anarthal/mysql/issues/14 > > But the lack of protocol support for multiple in-flight queries > immediately becomes apparent. It almost makes me question > the value of the library - what's the point of the async > support, if we then have to serialise the queries? As I pointed out in another email, it's a combination of lack of protocol support and lack of library support. Apologies if the documentation is not clear in this aspect. I think there is value in it, though, so you don't need to create 5000 threads to manage 5000 connections. The fact that the official MySQL client has added a "nonblocking" mode seems a good argument. > > Should the library provide this serialisation for us? I.e. > if I async_execute a query while another is in progress, the > library could wait for the first to complete before starting > the second. I would go for providing that bulk interface I talk about in other emails. > > Or, should the library provide a connection pool? (Does some > other part of ASIO provide connection pool functionality that > can be used here?) Asio doesn't provide that AFAIK. It is definitely useful functionality, tracked by https://github.com/anarthal/mysql/issues/19 > > > Transactions > ------------ > > I have found it useful to have a Transaction class: > > { > Transaction t(conn); // Issues "BEGIN" > .... run queries .... > t.commit(); // Issues "COMMIT" > } // t's dtor issues "ROLLBACK" if we have not committed. > Again, how would this work in the async world? How does the destructor handle communication failures when issuing the ROLLBACK? > Klemens Morgenstern makes the point that MySql is a trademark of > Oracle. Calling this "Boost.MySql" doesn't look great to me. > How can you write "The Boost MySql-compatible Database Library" > more concisely? I'm not very original at naming, as you may have already noticed. Using Boost.Delfin was proposed at some point, but Boost.Mysql definitely expresses its purpose better. > > Overall, I think this proposal needs a fair amount of API > re-design and additional features to be accepted, and should > be rejected at this time. It does seem to be a good start > though! > > > Thanks to Ruben for the submission. Thank you for sharing your thoughts, I think there is a lot of useful information here. ------------------------------ Message: 2 Date: Thu, 12 May 2022 21:02:48 +0200 From: Ruben Perez <rubenperez038(a)gmail.com> To: Dominique Devienne <ddevienne(a)gmail.com>, boost(a)lists.boost.org Subject: Re: [boost] Review of Boost.MySql Message-ID: <CACR-mdJntpKJ7x0cX8K4M4wasBWqTR5x9i-7FhygHxmCDL4=cA(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" > Indeed. But even your imagined batch interface only works well for > queries/selects, > while for inserts (or updates), the client does not need to just send > a small textual > SQL query, but potentially a bunch of data for the rows too. A true > pipeline allows > sending the rows for a second insert while the first insert is being processed. It would work for inserts too, as values are either part of the query string or part of the statement execute packet. In both cases, part of the request. > Such a mode may be useful for schema creation OTOH. We have large schemas, > with hundreds of tables, indexes, triggers, etc... Done from C++ code > client-side, > not via a DBA manually executing on the server using SQL files and the > native CLI. > For that use-case, the ability to send many DDLs in a single batch > would definitely > save on the round-trips to the server. We try hard to minimize roundtrips! Thanks for sharing this use case, I definitely wasn't aware of it and seems a reason towards implementing multi-statement. > You don't need to necessarily use Google's protobufs library. > There's https://github.com/mapbox/protozero for example, and similarly, a > from-scratch implementation to just encode-decode a specific protocol > can also be written. I wasn't aware of this.Thanks. > > The server sends several resultsets after that. I haven't focused a lot on > > this because it sounded risky (in terms of security) for me. > > Not sure what's risky here. Maybe I'm missing something. I was just imagining users concatenating queries. May be a misconception, yours is a legitimate use case. > Note that PostgreSQL's COPY is not file-specific, and a first-class citizen > at the protocol level, depending on a pure binary format (with text mode too). > I use COPY with STDIN / STDOUT "files", i.e. I prepare memory buffers and > send them; and read memory buffers, and decode them. No files involved. Unfortunately, that does not seem to be the case for MySQL. You issue the LOAD DATA statement via a regular query packet, and the server returns you another packet with the file path it wants. You then read it in the client and send it to the server in another packet. I've made it work with CSV files, and I'd say it's the only format allowed, AFAIK. > Maybe our use-case of very large data (with large blobs), *and* very > numerous smaller data, > that's often loaded en-masse, by scientific desktop applications, and > increasingly mid-tier services > for web-apps, is different from the more common ecommerce web-app > use-case of many people. It is good to hear different use cases than the regular web server we all have in mind. It will help me during further development. > > When I evaluate DB performance, I tend to concentrate on "IO" performance, > in terms of throughput and latency, independent of the speed of the > SQL engine itself. > There's nothing I can do about the latter, while the way one uses the Client API > (or underlying protocol features) is under my control. So I do mostly > INSERTs and > SELECTs, with and without WHERE clauses (no complex JOINs, CTEs, etc...). > > Because we are in the scientific space, we care about both many small rows > (millions, of a few bytes to KBs each at most), and a few (hundreds / thousands) > much larger rows with blobs (with MBs to GBs sizes). The truly large > "blobs" (files) are > kept outside the DB, since mostly read only (in the GBs to TBs sizes each, that > can accumulate to 2.6 PB for all a client's data I heard just > yesterday for example). > > I'll also compare inserting rows 1-by-1, with and without prepared statements, > to inserting multi-rows per-statement (10, 100, 1000 at a time), to the "bulk" > interface (COPY for PostgreSQL, LOCAL for MySQL, Direct-Path load in OCI). > For example with SQLite: > https://sqlite.org/forum/forumpost/baf9c444d9a38ca6e59452c1c568044aaad50bba… > (SQLite as no "bulk" interface, doesn't need one, since "embedded" > thus "zero-latency") > > For PostgreSQL, we also compared text vs binary modes (for binds and > resultsets). > > For blobs, throughput of reading and writing large blobs, whole and in-part, > with different access patterns, like continuous ranges, or scattered inside). > > A very important use-case for us, for minimizing round-trips, is how > to load a subset of rows, > given a list of primary keys (typically a surrogate key, like an > integer or a uuid). For that, > we bind a single array-typed value for the WHERE clause's placeholder > to the query, > and read the resultset, selecting 1%, 5%, 10%, etc... of the rows from > the whole table. > (selecting each row individually, even with a prepared query, is terribly slow). Thanks for sharing. It will definitely help me during benchmarking. Regards, Ruben. ------------------------------ Message: 3 Date: Thu, 12 May 2022 23:39:41 +0300 From: Andrey Semashev <andrey.semashev(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] Future of C++ and Boost Message-ID: <db0e5cf4-12b6-cc2f-da78-d65f76f899d2(a)gmail.com> Content-Type: text/plain; charset=UTF-8 On 5/12/22 21:48, Marshall Clow via Boost wrote: > On May 12, 2022, at 11:34 AM, Robert Ramey via Boost <boost(a)lists.boost.org> wrote: >> >> On 5/12/22 11:30 AM, Robert Ramey via Boost wrote: >>> On 5/12/22 9:55 AM, John Maddock via Boost wrote: >> >>> wow - that would be a big one. codecvt is the fundamental component to support wchar is it not? Does this mean that wchar is gone also? If so what replaced it? etc.... >> >> FWIW - I don't see any notice of such deprecation here: https://en.cppreference.com/w/cpp/header/codecvt > > Its in green - at the top: > codecvt_utf8 > <https://en.cppreference.com/w/cpp/locale/codecvt_utf8> > (C++11)(deprecated in C++17) Also here: http://eel.is/c++draft/depr.locale.stdcvt#depr.codecvt.syn ------------------------------ Message: 4 Date: Fri, 13 May 2022 13:20:24 +1200 From: Gavin Lambert <boost(a)mirality.co.nz> To: boost(a)lists.boost.org Subject: Re: [boost] Future of C++ and Boost Message-ID: <4d5d8961-85f3-979a-f69d-be9a9f02c3fc(a)mirality.co.nz> Content-Type: text/plain; charset=UTF-8; format=flowed On 13/05/2022 06:30, Robert Ramey wrote: > On 5/12/22 9:55 AM, John Maddock wrote: >> Watch out - all of <codecvt> is deprecated in C++17, I think you're >> relying only on <local> and may be OK though... > > wow - that would be a big one.? codecvt is the fundamental component to > support wchar is it not?? Does this mean that wchar is gone also?? If so > what replaced it? etc.... wchar_t is still around (although char8_t and std::u8string are the new hotness), it's just the conversion functions that are deprecated. I guess you're just not supposed to convert anything any more. More seriously, AFAIK there's no plans to actually remove it until/unless an actual replacement gets standardised. But I think in the meantime they'd rather you use something like the ICU library for conversions instead. Although it wouldn't surprise me if, in not wanting to take a dependency on an external library (and not wanting to continue using an officially deprecated standard function), a lot of libraries/apps will write their own subtly-broken conversion routines instead... ------------------------------ Message: 5 Date: Thu, 12 May 2022 23:24:19 -0300 From: Alan de Freitas <alandefreitas(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] Boost MySQL Review Starts Today Message-ID: <CAHpLXUiEEA4zjeMVO_EKgoMTGYv3t49hG0MjOrFqXx93K9SVHg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi! Here's my review. Boost.MySql is an impressive library. I would like to thank Rub?n for that. It implements the complete protocol from the ground up with async functionalities and certainly involved a lot of work. The documentation is extensive, goal-oriented, and helpful. The async operations support cancellation and the examples with coroutines are beautiful. During this review, I was impressed at how easy it works and I've noticed a few points in the API that have also been brought up in previous reviews and could be improved. Some other issues could also be better highlighted in the documentation, which would avoid many problems. The overall recommendation in this review is acceptance conditional on some fixes. ## Value > Will the library bring additional out-of-the-box utility to Boost? The library is very good news considering our recent discussions about the future of Boost, where providing more protocol implementations comes up frequently. I wish more people would make this kind of contribution. > What is your evaluation of the potential usefulness of the library? Others have questioned the benefit of the library when compared to sqlpp11 or any wrapper around the C API. The main difference is other libraries are high-level but this is a discussion still worth having from the point of view of users. I was thinking about the transition cost from Boost.MySQL to any other SQL database, since many applications have the requirement/necessity of allowing different SQL databases. In sqlpp11, the user can just change the backend. The user could use Boost.MySQL as an sqlpp11 backend and that would have the same effect. However, I think Rub?n mentioned this is not possible at some point. I'm not sure whether this is just for the async functionality. In the same line, I wonder if a library for Postgres or Sqlite would be possible with a similar API, which could also solve the problem, although I'm not sure anyone would be willing to implement that. If we did, we could have the convenience of sqlpp11 and the ASIO async functionalities of Boost.Mysql for other DBs. The library really provides ease-of-use, when we consider what it provides and how low-level it is. However, unlike in other libraries like Boost.Beast, Boost.MySql users might not be sold into the Asio way of doing things. Applications that require access to databases might be making sparse database requests where the Asio asynchronous model is not as useful. Highlighting these differences in the docs is important. Asio takes some time to learn, and I guess for a user not used to Asio, already understanding Asio does not sound like the ease of use. The docs could focus on the protocol before moving on to the asynchronous functionality. I'm also a little worried about the maintainability of the library and protocol changes and how this could impact boost as a whole. Should we really announce it as compatible with MariaDB? What direction would the library take if they diverge? How often does the protocol change or is extended? Is Ruben going to stick around if the protocol changes? How hard would it be for someone to understand the code and implement extensions? Can a user be sure it's always going to provide the same features and be as reliable as the C API? I don't have the answer to these questions, but it's something that got me wondering. I guess this kind of question is going to come up for any library that is related to a protocol. I don't know if the name "MySql" can be used for the library, as it belongs to Oracle. I'm not saying it can't. I'm really saying I don't know. I'm not a lawyer and I don't understand the implications here. But this should be considered, investigated, and evidence should be provided. The library is also compatible with MariaDB and the name "MySql" might not reflect that. Maybe there's a small probability it might be compatible with some other similar DB protocol derived from MySql in the future? As others have mentioned, the protocol is strictly sequential for a single connection, and this might have some implications for the asynchronous operations the library provides. - No two asynchronous MySql query reads can happen concurrently. While this still has value among other Asio operations, like a server that needs the DB eventually, the user needs to be careful about that. Maybe it would be safer if all MySql operations were on some special kind of strand. Or maybe the library could provide some "mysql::transaction_strand" functionality to help ensure this invariant for individual queries in the future. - A second implication is that some applications might find the asynchronous functionalities in Boost.Mysql not as useful as asynchronous functionalities in other protocols, like the ones in Boost.Beast. This depends on how their applications are structured. Since this is the main advantage over the C API, these users may question the value of the library and the documentation should discuss this more explicitly. - These implications could become irrelevant if the library provides some kind of functionality to enable a non-blocking mode. I have no idea how the MySql client achieves that. ## API > What is your evaluation of the design? Will the choice of API abstraction model ease the development of software that must talk to a MySQL database? I like how the API is very clean compared to the C API, even when including the asynchronous functionality. This would be a reason for using the library, even if I only used the synchronous functions. I'm worried about the lack of possibility of reusing memory for the results, as the interface depends on vector. This is not the usual Asio pattern. These vectors look even weirder in the asynchronous callbacks: - People have their containers/buffers and I would assume reading into some kind of existing row buffer would be the default interface, as is the case with other Asio read functions. In other words, read_many and read_all should work more like read_one. - Not returning these vectors is the common pattern in Asio: the initiating function receives a buffer for storage and the callback returns how many elements were read. Note that the buffer size already delimits how many elements we should read. - If we return vectors, async operations would need to instantiate the vector with the custom allocator for the operation. The callback wouldn't use std::vector<T> then. I would be std::vector<T, very_long_allocator_name> for every query callback, which is inconvenient. Using only std::vector<T> in the callback is not only inconvenient but dangerous because it would be the wrong allocator and everything would need to be copied. - One problem I see without the vectors is that each row would still need to allocate memory internally because of their dynamic size. I don't know the best solution for that second problem unless we have some sort of static size row/tuple, which does make sense since the user should know the number of columns at compile time. The library provides read_one, read_all, and read_many, but no "read_some". Besides the implication of a buffer to the initiating function, I would imagine reading as much as possible and parsing that to be the usual best strategy in this kind of an operation since we have a stream and we don't know how much data is available to read yet. Unfortunately, read_one, read_all, and read_many don't allow that. Unless read_many can already read less than the max number of rows in intermediary calls, which I don't think is the intention. It might also be useful to replicate the naming conventions Asio uses to read some or read all of the data. If "value" is intended to encapsulate the variant type, "value::to_variant" seems dangerous. The variant supports lots of types, which indicates the probability the internal design might need to change to fit new user demands is high. This could also need to change according to protocol extensions, and changing any of these types would break the API. If "value" already represents what it needs to represent, "value::to_variant" may not need to be exposed unless there's a lot of user demand for that. There is also an existential value/reference problem with "value": - The internal variant type includes a string_view whose string is owned by the row. This seems kind of dangerous or at least misleading. We have a reference type that's called "value", while this is more like a const "field view" or something. - At the same time, it's not a view either because I assume this is mutable, and updating numbers would not update the row. - The other values in the variant are value types, which makes "value" both a value and a reference type depending on the column type. - A reference type seems appropriate here because we don't want to copy all the data when iterating the results, but we need some other pattern for "value". A const view is especially useful because we might be able to keep value types for numbers, etc... Encapsulating the variant is also helpful here. - Calling a type "value" is a bad indication anyway. Any value is a "value". As others have mentioned, "value::get_std_optional" is unusual. It may not look problematic at first but it has a number of problems: 1) We have a dangerous precedent because we could also say we need to support all other boost/std equivalents in the library, such as the string_view the library uses at many places. 2) We are including and depending on two libraries when we know almost for sure the user is only using one of them: If there's no std::optional in the supported platform, we just need boost::optional. If you are requiring a C++ standard where std::optional is available, then we just need std::optional. 3) This is also not very useful if the user has both boost::optional and std::optional, because the code would still need to be refactored from get_optional to get_std_optional or vice-versa if the user decides to change it. This could be solved with some BOOST_MYSQL_USE_STD_OPTIONAL or BOOST_MYSQL_USE_STD_STRING_VIEW, etc., but this would also invalidate the distinction. 4) This would make the API inconsistent in case Boost moves to a C++17 minimum at some point in the future, replacing boost classes, as we have been discussing C++14 lately. Both get_optional and get_std_optional would return the same type. Also, if std::optional is the *standard* type, it should not be the one whose function needs clarification with a longer name "get_std_optional". 5) This doesn't need to be a member function, which indicates it shouldn't be a member function in this case. The class is internally representing only one of these and conversions will happen anyway. A user in the >C++17 intersection can easily implement their own to_std_optional free function outside the class. If I understood the documentation correctly, it's also problematic to use an empty optional for both a null value and an invalid result. They are simply not the same thing. Libraries always differentiate an invalid state from null in a field. This is especially relevant because the documentation warns us against using the "is_convertible_to" pattern over "get_optional" because "is_convertible_to" is unnecessarily slow. By the way, it would be nice to explain why "// WARNING!! Inefficient, do NOT do" is true. I wouldn't expect that to cost more than creating the optional value. The documentation states that the behavior of relational operators may change in the future. What do other libraries do about these comparisons? We probably don't want something like PHP, where "20" == 20 so that we need some kind of "20" === 20 in the future, but the documentation implies we also don't want "value(std::int64_t(200)) > value(std::uint64_t(200))" to fail. The library makes the whole thing particularly tricky with number types because not checking the proper number type in the variant would return invalid/null even when the number could be stored in a variable of another number type perfectly fine, which is even worse when both invalid and null are presented by the same empty optional. About the "resultset": - If "resultset" is a table, the "set" part of the name might be a little misleading in C++ as the results are in a deterministic sequence, even though this is what MySQL may call a similar concept. However, I imagine there's no equivalent concept in MySql for this specific Asio-async-lazy-fetching functionality itself. - This class is more like a "table", "frame", "vector", "list", or just "result". However, after all the steps of "connect", "prepare", and "execute", the name "result" gives the impression that the results are finally there, but this is just another stream object like a "result fetcher" or something. - Since the protocol is strictly sequential, it might be useful to not even have a resultset class at all. The connection could send the query and have some read function, like the usual read/write functions in Asio can operate on the same stream. Minor issues: - Maybe it's not clear from the examples, but why would the user need connection::handshake when connection::connection already does it? - Shouldn't `tcp_ssl_connection::connect` accept an EndpointSequence to be more like other Asio functions. - The names "tcp_ssl_prepared_statement", "tcp_ssl_<component>" are quite repetitive and verbose in the documentation. Maybe "tcp_ssl" could become a namespace? Isn't that what Asio does for the ssl related objects? Some names might be reduced if there's no alternative. For instance, "prepared_statement" might become "statement" since there's no "unprepared_statement". - Wouldn't some form of `statement::execute` with variadic args (different name perhaps) be a simpler alternative to `statement::execute(boost::mysql::make\_values(...))`. Or maybe statement::operator(), as Phil suggested. Or some `statement::execute_with(...)`. In the variadic args, the optional err/info can go into some specified positions, since they're not ambiguous with the field variant types. This is a little tricky but definitely useful, especially if suggestions of customization points are implemented in the future. ## Implementation > What is your evaluation of the implementation? I haven't analyzed the implementation very profoundly. I skimmed through the source code and couldn't find anything problematic. It would be useful if the experts could inspect the Asio composed ops more deeply. CMakeLists.txt: - I believe the CMakeLists.txt script is not in the format of other boost libraries in boost/libs so it won't work with the super-project as it is. - The example/CMakeLists.txt script refers to BOOST_MYSQL_INTEGRATION_TESTS. I don't think examples can be considered integration tests. Examples: - The examples are very nice. Especially the one with coroutines. They are also very limited. They are all about the same text queries, which shouldn't even be used in favor of prepared statements. - Many examples about continuation styles are not very useful because this is more of an Asio feature than a library feature. The library feature, so to speak, is supporting Asio tokens properly. The continuation styles could be exemplified in the exposition with some small snippets for users not used to Asio without the documentation losing any value. - Some examples are simple enough and don't require the reader to know the rest of the exposition. They are like a quick look into the library. These could come at the beginning, as in the Asio tutorials and Beast quick look section. - The first sync example could be simpler to involve just a hello world before moving on to other operations. - The page about the docker container should specify that the username and password are "root" and "". Tests: Some unit tests take a ***very*** long time. Enough to make coffee and a sandwich. And they seem to not be adding a lot of value in terms of coverage. For instance, "mysql/test/unit/detail/protocol/date.cpp(72): info: check '1974- 1-30' has passed" going through all possible dates multiple times took a long time. > Did you try to use the library? With what compiler? Did you have any problems? No problems at all. GCC 11 and MSVC 19. ## Documentation > What is your evaluation of the documentation? The documentation is complete. The main points that differentiate the library are - it's a complete rewrite of the protocol, - it's low-level and - it's based on Boost.Asio The documentation should emphasize these points as much as possible, especially the first one. This should be in the introduction, the motivation, slogans, logos, and wherever people can see it easily. The documentation should also provide arguments and evidence that these design goals are a good idea, as often discussed when the topic is the value of this library. Why is it worth rewriting the protocol? To what use cases are such a low-level library useful? Why should a person who already uses other libraries or the C API care about Asio now? Something that should also be highlighted is the difference between the library and other higher-level libraries, in particular, naming names. Minor issues: - There's no link in the documentation to the protocol specification. It would be interesting to know what the reference specification is. Or whether the protocol was inferred somehow. Is there any chance this protocol might change? What about divergences between MySql and MariaDB? How stable is the protocol? For what range of versions does it work? What's the policy when it changes? - Some links are broken (for instance, linking to https://anarthal.github.io/boost-mysql/index.html) - "All async operations in this library support per-operation cancellation". It's important to highlight this is per operation in the Asio sense of an operation but not in the MySql sense of an operation because the MySql connection is invalid after that. - "Boost.MySql has been tested with the following versions of MySQL". MariaDB is not a version of MySql. - Prepared statements should come first in the examples, to highlight them as the default pattern. - The documentation refers to topics that haven't been explained yet. Maybe "value" could be explained after "row", and "row" could be explained after "resultset" and "resultset" after "queries". - The section "Text Queries" is quite small in comparison to other sections. It could include some examples and snippets like other sections do. - "The following completion tokens can be used in any asyncrhonous operation within Boost.Mysql" -> "Any completion token..." - "When they fail, they throw a boost::system::system_error exception". Don't these functions just set the proper error_code, as usual with Asio and Beast? - The "MySQL to C++ mapping reference" section should be using a table. - A small subsection on transactions would be helpful even if there's no library functionality to help with that. - The documentation should include some comparisons that are not obvious to potential users. C/C++ APIs. The advantages of the Asio async model. Benchmarks if possible. ## Conclusion > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent one day in this review. I read all the documentation, ran the tests, experimented with the examples, and had a reasonable look at the implementation. > Are you knowledgeable about the problem domain? I'm reasonably educated about databases but not an expert. I've been working a lot with Asio. > Are there any immediate improvements that could be made after acceptance, if acceptance should happen? While it's important to have a general variant type for row values, a simpler interface for tuples of custom types would be very welcome and would simplify things by a lot, while also avoiding allocations, since columns always have the same types. This feature is too obvious since users almost always know their column types at compile time and this demand is too recurrent in applications to ignore. > Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. I believe it should be conditionally accepted with the same conditions stated in other reviews: allowing for memory reuse in the read_* functions and fixing the "value" type. Best, Em ter., 10 de mai. de 2022 ?s 04:14, Richard Hodges via Boost < boost(a)lists.boost.org> escreveu: > Dear All, > > The Boost formal review of the MySQL library starts Today, taking place > from May 10th, 2022 to May 19th, 2022 (inclusive) - We are starting one day > after the announced date and extending the period by one day to compensate. > > The library is authored by Rub?n P?rez Hidalgo (@anarthal in the CppLang > slack). > > Documentation: https://anarthal.github.io/mysql/index.html > Source: https://github.com/anarthal/mysql/ > > The library is built on the bedrock of Boost.Asio and provides both > synchronous and asynchronous client connectors for the MySQL database > system. > > Boost.MySQL is written from the ground up, implementing the entire protocol > with no external dependencies beyond the Boost library. > It is compatible with MariaDB. > > Connectivity options include TCP, SSL and Unix Sockets. > > For async interfaces, examples in the documentation demonstrate full > compatibility with all Asio completion handler styles, including: > > Callbacks:- > https://anarthal.github.io/mysql/mysql/examples/query_async_callbacks.html > > Futures :- > https://anarthal.github.io/mysql/mysql/examples/query_async_futures.html > > Boost.Coroutine :- > https://anarthal.github.io/mysql/mysql/examples/query_async_coroutines.html > > C++20 Coroutines :- > > https://anarthal.github.io/mysql/mysql/examples/query_async_coroutinescpp20… > > Rub?n has also implemented the Asio protocols for deducing default > completion token types :- > > https://anarthal.github.io/mysql/mysql/examples/default_completion_tokens.h… > > Reviewing a database connector in depth will require setting up an instance > of a MySQL database. Fortunately most (all?) Linux distributions carry a > MySQL and/or MariaDB package. MySQL community edition is available for > download on all platforms here: > https://dev.mysql.com/downloads/ > > Rub?n has spent quite some time in order to bring us this library > candidate. The development process has no doubt been a journey of discovery > into Asio, its concepts and inner workings. I am sure he has become a fount > of knowledge along the way. > > From a personal perspective, I was very happy to be asked to manage this > review. I hope it will be the first of many more reviews of libraries that > tackle business connectivity problems without further dependencies beyond > Boost, arguably one of the most trusted foundation libraries available. > > Please provide in your review information you think is valuable to > understand your choice to ACCEPT or REJECT including Describe as a > Boost library. Please be explicit about your decision (ACCEPT or REJECT). > > Some other questions you might want to consider answering: > > - Will the library bring additional out-of-the-box utility to Boost? > - What is your evaluation of the implementation? > - What is your evaluation of the documentation? > - Will the choice of API abstraction model ease the development of > software that must talk to a MySQL database? > - Are there any immediate improvements that could be made after > acceptance, if acceptance should happen? > - Did you try to use the library? With which compiler(s)? Did you > have any problems? > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > - Are you knowledgeable about the problem domain? > > More information about the Boost Formal Review Process can be found > at: http://www.boost.org/community/reviews.html > > The review is open to anyone who is prepared to put in the work of > evaluating and reviewing the library. Prior experience in contributing to > Boost reviews is not a requirement. > > Thank you for your efforts in the Boost community. They are very much > appreciated. > > Richard Hodges > - review manager of the proposed Boost.MySQL library > > Rub?n is often available on CppLang Slack and of course by email should you > require any clarification not covered by the documentation, as am I. > > -- > Richard Hodges > hodges.r(a)gmail.com > tg: @rhodges > office: +44 2032 898 513 > mobile: +376 380 212 > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- Alan Freitas https://github.com/alandefreitas ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6704, Issue 1 **************************************

6 8

The Future of C++ Modules
by Benedict Bede McNamara 13 May '22

13 May '22

On 5/13/22 5:24 AM, Peter Dimov via Boost wrote: >> John Maddock wrote: >> I'm afraid my conclusion is that modules are simply not yet ready for >> prime time. >> >> If they ever are. >> >> Modules can work for leaf libraries, but for libraries used as dependencies >> by other libraries, you'll encounter a situation where the same translation >> unit imports boost.lib or "boost/lib.hpp" in one place and then includes >> "boost/lib/something.hpp" in another, which is probably never going to >> work correctly. >This is sounds like how I thought it had to work to be effective. If I >understand this correctly, the whole modules concept is in fundamental >conflict with the anything which uses the boost inclusion/dependency >model - which is every module includes what it uses and nothing else. >In my view the whole modules idea is misconceived. One more nail in >coffin of C++ xx standard libraries. >It's time for use to seriously start moving on. >Robert Ramey You can’t be serious. I have used modules in I++ and they function perfectly. C++ was kind of dodgy with its use of the pre-processor. Modules re-establish C++ as being the predominant language of its time. It is C++ that ‘has moved on’ from where Boost is at present. Boost is running at least 2 years behind the standard and It risks becoming irrelevant if it remains there for much longer. Sent from Mail for Windows From: boost-request(a)lists.boost.org Sent: Saturday, 14 May 2022 8:19 AM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6704, Issue 5 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: cstring_view (Peter Dimov) 2. Re: cstring_view (Marshall Clow) 3. Re: cstring_view (Peter Dimov) 4. Re: cstring_view (Marshall Clow) 5. Re: cstring_view (Peter Dimov) 6. Re: cstring_view (Rainer Deyke) 7. Re: cstring_view (David Bien) 8. Re: MySql review (Rainer Deyke) 9. Re: The Future of C++ and Boost - C++ Modules (Robert Ramey) 10. Re: The Future of C++ and Boost - C++ Modules (Peter Dimov) 11. Re: cstring_view (Marshall Clow) 12. Re: cstring_view (Peter Dimov) ---------------------------------------------------------------------- Message: 1 Date: Fri, 13 May 2022 21:09:47 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <01d201d866f4$a330d710$e9928530$(a)gmail.com> Content-Type: text/plain; charset="utf-8" David Bien wrote: > I guess when I read the impl I think to myself: What this is missing is a _length > member. But then it just becomes boost::string_view. > > What value added is there to this impl except that it is smaller than > boost::string_view due to lacking a _length member? Please see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1402r0.pdf No idea why this particular implementation doesn't store the size. I would. ------------------------------ Message: 2 Date: Fri, 13 May 2022 11:14:13 -0700 From: Marshall Clow <mclow.lists(a)gmail.com> To: Boost Developers List <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <DFCD5BFF-F7CA-46CC-82DF-833CE68CB0F0(a)gmail.com> Content-Type: text/plain; charset=utf-8 On May 13, 2022, at 10:42 AM, David Bien via Boost <boost(a)lists.boost.org> wrote: > > I guess when I read the impl I think to myself: What this is missing is a _length member. But then it just becomes boost::string_view. > > What value added is there to this impl except that it is smaller than boost::string_view due to lacking a _length member? If you?re careful and don?t do much with it, it can hand you back a null terminated string. ? Marshall PS. I note that P1402 (the paper proposing cstring_view for the standard) was was reviewed by LEWG in 2019, and the resolution of that group was "We will not pursue P1402R0 or this problem space? ------------------------------ Message: 3 Date: Fri, 13 May 2022 21:18:24 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <01d301d866f5$d6cfe880$846fb980$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Marshall Clow wrote: > On May 13, 2022, at 10:42 AM, David Bien via Boost <boost(a)lists.boost.org> > wrote: > > > > I guess when I read the impl I think to myself: What this is missing is a > _length member. But then it just becomes boost::string_view. > > > > What value added is there to this impl except that it is smaller than > boost::string_view due to lacking a _length member? > > If you?re careful and don?t do much with it, it can hand you back a null > terminated string. ??? In what scenarios will it not give you a null-terminated string? ------------------------------ Message: 4 Date: Fri, 13 May 2022 11:39:37 -0700 From: Marshall Clow <mclow.lists(a)gmail.com> To: Peter Dimov <pdimov(a)gmail.com> Cc: Boost Developers List <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <F5FB00FB-3576-47CF-8BEA-FFD90C2C74F0(a)gmail.com> Content-Type: text/plain; charset=utf-8 On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > > Marshall Clow wrote: >> On May 13, 2022, at 10:42 AM, David Bien via Boost <boost(a)lists.boost.org> >> wrote: >>> >>> I guess when I read the impl I think to myself: What this is missing is a >> _length member. But then it just becomes boost::string_view. >>> >>> What value added is there to this impl except that it is smaller than >> boost::string_view due to lacking a _length member? >> >> If you?re careful and don?t do much with it, it can hand you back a null >> terminated string. > > ??? > > In what scenarios will it not give you a null-terminated string? char arr[6] = ?hello"; cstring_view csv(arr); assert(strlen(csv.data())) == 5); arr[5] = ?!?; assert(strlen(csv.data())) == 5); // boom ? Marshall PS. It promises to give you a null-terminated string, but has no way to actually guarantee that. ------------------------------ Message: 5 Date: Fri, 13 May 2022 21:57:39 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: "'Marshall Clow'" <mclow.lists(a)gmail.com> Cc: "'Boost Developers List'" <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <01df01d866fb$52ff30f0$f8fd92d0$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Marshall Clow wrote: > >> If you?re careful and don?t do much with it, it can hand you back a > >> null terminated string. > > > > ??? > > > > In what scenarios will it not give you a null-terminated string? > > char arr[6] = ?hello"; > cstring_view csv(arr); > assert(strlen(csv.data())) == 5); > arr[5] = ?!?; > assert(strlen(csv.data())) == 5); // boom The main use of cstring_view, like string_view, is as a parameter (and return) type. So if you have a function void f1( cstring_view csv ); it's true that if inside f1 you write to some random character this may invalidate csv's promise to be null-terminated, but I see little salient difference between this and void f2( char const* csv ); // pre: csv is null-terminated char seq where f2 writing to a carefully chosen char may also invalidate the precondition. Typing "cstring_view" is merely a different way of spelling out the "pre" of f2. Similarly, cstring_view g1(); is an alternative way of spelling char const* g2(); // post: the return value is a null-terminated char seq ------------------------------ Message: 6 Date: Fri, 13 May 2022 21:29:06 +0200 From: Rainer Deyke <rdeyke(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] cstring_view Message-ID: <t5mbi2$42u$1(a)ciao.gmane.io> Content-Type: text/plain; charset=UTF-8; format=flowed On 13.05.22 20:39, Marshall Clow via Boost wrote: > On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: >> In what scenarios will it not give you a null-terminated string? > > char arr[6] = ?hello"; > cstring_view csv(arr); > assert(strlen(csv.data())) == 5); > arr[5] = ?!?; > assert(strlen(csv.data())) == 5); // boom > > ? Marshall > > PS. It promises to give you a null-terminated string, but has no way to actually guarantee that. That's an issue with views in general, not just cstring_view. std::string s = "hello"; string_view sv = s; assert(sv.size() == 5); s += "!"; assert(sv.size() == 5); // boom It is the responsibility of the creator of a view to ensure that the object being viewed does not change in a way that breaks the invariants of the view while the view is in use. -- Rainer Deyke (rainerd(a)eldwood.com) ------------------------------ Message: 7 Date: Fri, 13 May 2022 18:20:40 +0000 From: David Bien <davidbien(a)hotmail.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Cc: Peter Dimov <pdimov(a)gmail.com> Subject: Re: [boost] cstring_view Message-ID: <MWHPR1801MB1934DE34D9E7AE1678101098B1CA9(a)MWHPR1801MB1934.namprd18.prod.outlook.com> Content-Type: text/plain; charset="Windows-1252" Exactly. But then it should just be called cstring_wrapper ? calling it cstring_view seems to impart qualities to it that it doesn?t have ? like I would assume that I could get a cstring_view that is a subview of an existing cstring_view for instance. Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: Peter Dimov via Boost<mailto:boost@lists.boost.org> Sent: Friday, May 13, 2022 12:19 PM To: boost(a)lists.boost.org<mailto:boost@lists.boost.org> Cc: Peter Dimov<mailto:pdimov@gmail.com> Subject: Re: [boost] cstring_view Marshall Clow wrote: > On May 13, 2022, at 10:42 AM, David Bien via Boost <boost(a)lists.boost.org> > wrote: > > > > I guess when I read the impl I think to myself: What this is missing is a > _length member. But then it just becomes boost::string_view. > > > > What value added is there to this impl except that it is smaller than > boost::string_view due to lacking a _length member? > > If you?re careful and don?t do much with it, it can hand you back a null > terminated string. ??? In what scenarios will it not give you a null-terminated string? _______________________________________________ Unsubscribe & other changes: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.boos… ------------------------------ Message: 8 Date: Fri, 13 May 2022 21:37:36 +0200 From: Rainer Deyke <rdeyke(a)gmail.com> To: boost(a)lists.boost.org Subject: Re: [boost] MySql review Message-ID: <t5mc20$87r$1(a)ciao.gmane.io> Content-Type: text/plain; charset=UTF-8; format=flowed On 13.05.22 17:23, Phil Endecott via Boost wrote: > The aim should be "secure by default". Users are lazy. The > particular danger in this case is that they do an initial test with > the password in the source, and then move it somewhere secure later, > but the password is still exposed in their revision control history. > At this point in history, there is no excuse to repeat the mistakes > that have lead to really very serious security problems in the past. > Make the default mechanism, and the first one that you describe in > the docs, the most secure one. Looking for credentials in a file on disk may be more secure than embedding the credentials in code, but it is most definitely the most secure mechanism. The most secure mechanism is to always ask the user at program start-up. Or better yet, ask each time a connection is created, and then immediately wipe the credentials from RAM in order to mitigate RAM scanning attacks. -- Rainer Deyke (rainerd(a)eldwood.com) ------------------------------ Message: 9 Date: Fri, 13 May 2022 12:33:50 -0700 From: Robert Ramey <ramey(a)rrsd.com> To: Peter Dimov via Boost <boost(a)lists.boost.org> Subject: Re: [boost] The Future of C++ and Boost - C++ Modules Message-ID: <4134c080-20bb-16d2-ff81-0c6b6dc52d75(a)rrsd.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 5/13/22 5:24 AM, Peter Dimov via Boost wrote: > John Maddock wrote: >> I'm afraid my conclusion is that modules are simply not yet ready for >> prime time. > > If they ever are. > > Modules can work for leaf libraries, but for libraries used as dependencies > by other libraries, you'll encounter a situation where the same translation > unit imports boost.lib or "boost/lib.hpp" in one place and then includes > "boost/lib/something.hpp" in another, which is probably never going to > work correctly. This is sounds like how I thought it had to work to be effective. If I understand this correctly, the whole modules concept is in fundamental conflict with the anything which uses the boost inclusion/dependency model - which is every module includes what it uses and nothing else. In my view the whole modules idea is misconceived. One more nail in coffin of C++ xx standard libraries. It's time for use to seriously start moving on. Robert Ramey ------------------------------ Message: 10 Date: Sat, 14 May 2022 00:16:26 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] The Future of C++ and Boost - C++ Modules Message-ID: <01f501d8670e$b57a64d0$206f2e70$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Robert Ramey wrote: > On 5/13/22 5:24 AM, Peter Dimov via Boost wrote: > > John Maddock wrote: > > >> I'm afraid my conclusion is that modules are simply not yet ready for > >> prime time. > > > > If they ever are. > > > > Modules can work for leaf libraries, but for libraries used as > > dependencies by other libraries, you'll encounter a situation where > > the same translation unit imports boost.lib or "boost/lib.hpp" in one > > place and then includes "boost/lib/something.hpp" in another, which is > > probably never going to work correctly. > > This is sounds like how I thought it had to work to be effective. If I understand > this correctly, the whole modules concept is in fundamental conflict with the > anything which uses the boost inclusion/dependency model - which is every > module includes what it uses and nothing else. > > In my view the whole modules idea is misconceived. One more nail in coffin of > C++ xx standard libraries. > > It's time for use to seriously start moving on. Looks like I was mistaken, though. At least with header units, i.e. `import "boost/lib.hpp"`, it all seems to "just work" under MSVC. That is, the compiler automatically merges the identical definitions from the sub-#includes. ------------------------------ Message: 11 Date: Fri, 13 May 2022 15:16:19 -0700 From: Marshall Clow <mclow.lists(a)gmail.com> To: Boost Developers List <boost(a)lists.boost.org> Cc: Rainer Deyke <rdeyke(a)gmail.com> Subject: Re: [boost] cstring_view Message-ID: <3C70E2E0-DC7A-4263-9D93-FCD8220A39BE(a)gmail.com> Content-Type: text/plain; charset=utf-8 On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost <boost(a)lists.boost.org> wrote: > > On 13.05.22 20:39, Marshall Clow via Boost wrote: >> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: >>> In what scenarios will it not give you a null-terminated string? >> char arr[6] = ?hello"; >> cstring_view csv(arr); >> assert(strlen(csv.data())) == 5); >> arr[5] = ?!?; >> assert(strlen(csv.data())) == 5); // boom >> ? Marshall >> PS. It promises to give you a null-terminated string, but has no way to actually guarantee that. > > That's an issue with views in general, not just cstring_view. > > std::string s = "hello"; > string_view sv = s; > assert(sv.size() == 5); > s += "!"; > assert(sv.size() == 5); // boom I don?t see the problem here (and when I run the code I get no error - after adding the missing ?std::'). No assertion failure; no undefined behavior (unlike the cstring_view example) ? Marshall ------------------------------ Message: 12 Date: Sat, 14 May 2022 01:19:33 +0300 From: "Peter Dimov" <pdimov(a)gmail.com> To: <boost(a)lists.boost.org> Subject: Re: [boost] cstring_view Message-ID: <01fc01d86717$873b2a60$95b17f20$(a)gmail.com> Content-Type: text/plain; charset="utf-8" Marshall Clow wrote: > On May 13, 2022, at 12:29 PM, Rainer Deyke via Boost > <boost(a)lists.boost.org> wrote: > > > > On 13.05.22 20:39, Marshall Clow via Boost wrote: > >> On May 13, 2022, at 11:18 AM, Peter Dimov via Boost > <boost(a)lists.boost.org> wrote: > >>> In what scenarios will it not give you a null-terminated string? > >> char arr[6] = ?hello"; > >> cstring_view csv(arr); > >> assert(strlen(csv.data())) == 5); > >> arr[5] = ?!?; > >> assert(strlen(csv.data())) == 5); // boom ? Marshall PS. It > >> promises to give you a null-terminated string, but has no way to actually > guarantee that. > > > > That's an issue with views in general, not just cstring_view. > > > > std::string s = "hello"; > > string_view sv = s; > > assert(sv.size() == 5); > > s += "!"; > > assert(sv.size() == 5); // boom > > I don?t see the problem here (and when I run the code I get no error - after > adding the missing ?std::'). > > No assertion failure; no undefined behavior (unlike the cstring_view example) Only because "hello!" fits into the small buffer, I suspect. If `s` reallocates, `sv` would be left dangling. ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6704, Issue 5 **************************************

1 0

Re: [boost] Review of Boost.MySql
by Ruben Perez 13 May '22

13 May '22

> > > > I was just imagining users concatenating queries. May be a misconception, > > yours is a legitimate use case. > > I've thought more about this, and I'm guessing you were thinking > about this XKCD https://xkcd.com/327/ SQL Injection. Yes, this was definitely what I was thinking of ;) > > The proper and ideal remedy is not the XKCD one though, > it is using prepared statements and binding values. > > The still proper but less ideal next remedy is a "safe" way to concatenate > user inputs into textual SQL. I.e. the equivalent of > SQLite: https://www.sqlite.org/printf.html with %q and %Q > PostgreSQL: https://www.postgresql.org/docs/current/libpq-exec.html#LIBPQ-PQESCAPELITER… > Since you want to avoid the MySQL client, which I suppose has this > too, you have to provide your own. Since not everything can be done with prepared statements (I've been shown some legitimate use cases that are not covered), I've raised https://github.com/anarthal/mysql/issues/69 to address this, and I will likely implement something like this. > > Third and finally, this XKCD hack indeed does only work is one can > execute several semi-colon separated statements. > So on second thought, it is *definitely* be a good thing to have > separate APIs, to execute single statement, as opposed from executing > "scripts" of statements, plural. With a single-statement API, *even* > the XKCD hack won't work, since it would yield an invalid single > statement. > This is what you had in mind IMHO :). The trouble with this is that multi-statement is not a separate protocol primitive, but rather something you turn on or off for the entire session. So your connections either support it or don't. If you include such a semicolon separated set of queries in your query request, and this capability is turned on, the server will happily execute it. So maybe this should be implemented as an extra value in connection_params (https://anarthal.github.io/mysql/mysql/connparams.html) with adequate security warnings.

1 0

Re: [boost] Review of Boost.MySql
by Dominique Devienne 13 May '22

13 May '22

Meant to send this to the list, not just Ruben. Re-sending. --DD On Fri, May 13, 2022 at 11:59 AM Dominique Devienne <ddevienne(a)gmail.com> wrote: > > On Thu, May 12, 2022 at 9:02 PM Ruben Perez <rubenperez038(a)gmail.com> wrote: > > > > The server sends several resultsets after that. I haven't focused a lot on > > > > this because it sounded risky (in terms of security) for me. > > > > > > Not sure what's risky here. Maybe I'm missing something. > > > > I was just imagining users concatenating queries. May be a misconception, > > yours is a legitimate use case. > > I've thought more about this, and I'm guessing you were thinking > about this XKCD https://xkcd.com/327/ SQL Injection. > > The proper and ideal remedy is not the XKCD one though, > it is using prepared statements and binding values. > > The still proper but less ideal next remedy is a "safe" way to concatenate > user inputs into textual SQL. I.e. the equivalent of > SQLite: https://www.sqlite.org/printf.html with %q and %Q > PostgreSQL: https://www.postgresql.org/docs/current/libpq-exec.html#LIBPQ-PQESCAPELITER… > Since you want to avoid the MySQL client, which I suppose has this > too, you have to provide your own. > > Third and finally, this XKCD hack indeed does only work is one can > execute several semi-colon separated statements. > So on second thought, it is *definitely* be a good thing to have > separate APIs, to execute single statement, as opposed from executing > "scripts" of statements, plural. With a single-statement API, *even* > the XKCD hack won't work, since it would yield an invalid single > statement. > This is what you had in mind IMHO :). > > So the ability to execute multi-statement is important, especially in > my DDL use-case, > but it should be a separate API from the more regular single-statement > APIs, and come > with extra warnings in the document about such SQL injections (with > obligatory link to XKCD ;) > > PS: Fourth, the XKCD hack is possible only of the SQL is executed as > the owner of the schema, > or a DBA/Superuser, which is of course a mistake and a big no-no, > yet all too common... > Users of the DB, including mid-tier services, should NOT have DDL > privileges on the schema and its objects. > Change the DROP into a DELETE, and that's still nasty, but then you > use ROLEs to restrict some DMLs, > and possibly also RLS (Row Level Security) for finer-grained > authorization. But we are getting off-topic :)

1 0

Future of C++ and Boost
by Vinnie Falco 13 May '22

13 May '22

It might be interesting to think about where C++ and Boost will be in the next 20 years and in the next 50 years. There has been an explosion of research and development into new programming languages (Rust being the most visible example). C++ is hardly the most popular language (Python is, if the TIOBE index is to be believed). But C++ is an essential language because it occupies the unique position of being as close as possible to assembly language while remaining high level. The zero-cost abstractions, metaprogramming, and powerful compositional tools of C++ still have no competitors and they are unlikely to have them any time soon. This doesn't necessarily mean that C++ is good for everything; there's an opportunity cost for all this. C++ code is generally more complex, harder to read, and harder to write than other code. Other languages are much better suited for certain tasks. No one should be implementing a content-driven website using Asio and Beast for example. But for the things that C++ is good at, it excels at them. A recent reddit post [1] provided a decent list:: * games * databases * high frequency trading * search (Google/Bing/DuckDuckGo) * web browsers (Chrome/Safari/Edge) * virtual reality headsets (Facebook) * distributed systems at big tech companies (Google/Microsoft/Facebook) * low level libraries (machine learning libraries like tensorflow and pytorch) * compilers, virtual machines, interpreters (JVM/gcc/LLVM) * robotics & hardware (ex: self driving cars, planes, missiles, space ships, etc) My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users. I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want, but also by not even keeping up feature-wise with the library ecosystem of other languages. Where is Requests [2] for C++? Python has had this for over a decade. In case you think I'm exaggerating, look at this comment from Reddit: ...a major vendor is getting ready to release a product that does not allow user applications to directly access TCP sockets so the only way to get any network access is to go through their standard library which only supports backdoored HTTPS. This vendor of course is Apple, as can be seen in P1860R0 [4]. We should not expect that wg21 will be able to deliver an important feature such as networking in a form that will be usable or recognizable to non-committee members. What does this mean for C++ and Boost? I believe there is a significant opportunity for Boost to step in and become the rational collection of actually useful libraries that the C++ standard library is not. We already have networking, some protocols, and JSON. We (the existing Boost authors and contributors) might consider looking to the list above of industries that use C++, and focus our efforts more towards providing libraries that enhance those industries. Perhaps by reaching out to leaders in those fields we might establish working relationships and build, say, the next Boost.Tensorflow or something like that. I don't know. Oh, and add "cryptocurrency" to the list above. C++ is the language of blockchain, because performance matters. What do you think? Thanks Vinnie [1] <https://www.reddit.com/r/cpp/comments/u5vjni/comment/i54qbzq> [2] <https://docs.python-requests.org/en/latest/> [3] <https://www.reddit.com/r/cpp/comments/u6z8gr/comment/i5caxr6> [4] <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1860r0.html>

22 50

Re: [boost] Review of Boost.MySql
by Ruben Perez 12 May '22

12 May '22

> Indeed. But even your imagined batch interface only works well for > queries/selects, > while for inserts (or updates), the client does not need to just send > a small textual > SQL query, but potentially a bunch of data for the rows too. A true > pipeline allows > sending the rows for a second insert while the first insert is being processed. It would work for inserts too, as values are either part of the query string or part of the statement execute packet. In both cases, part of the request. > Such a mode may be useful for schema creation OTOH. We have large schemas, > with hundreds of tables, indexes, triggers, etc... Done from C++ code > client-side, > not via a DBA manually executing on the server using SQL files and the > native CLI. > For that use-case, the ability to send many DDLs in a single batch > would definitely > save on the round-trips to the server. We try hard to minimize roundtrips! Thanks for sharing this use case, I definitely wasn't aware of it and seems a reason towards implementing multi-statement. > You don't need to necessarily use Google's protobufs library. > There's https://github.com/mapbox/protozero for example, and similarly, a > from-scratch implementation to just encode-decode a specific protocol > can also be written. I wasn't aware of this.Thanks. > > The server sends several resultsets after that. I haven't focused a lot on > > this because it sounded risky (in terms of security) for me. > > Not sure what's risky here. Maybe I'm missing something. I was just imagining users concatenating queries. May be a misconception, yours is a legitimate use case. > Note that PostgreSQL's COPY is not file-specific, and a first-class citizen > at the protocol level, depending on a pure binary format (with text mode too). > I use COPY with STDIN / STDOUT "files", i.e. I prepare memory buffers and > send them; and read memory buffers, and decode them. No files involved. Unfortunately, that does not seem to be the case for MySQL. You issue the LOAD DATA statement via a regular query packet, and the server returns you another packet with the file path it wants. You then read it in the client and send it to the server in another packet. I've made it work with CSV files, and I'd say it's the only format allowed, AFAIK. > Maybe our use-case of very large data (with large blobs), *and* very > numerous smaller data, > that's often loaded en-masse, by scientific desktop applications, and > increasingly mid-tier services > for web-apps, is different from the more common ecommerce web-app > use-case of many people. It is good to hear different use cases than the regular web server we all have in mind. It will help me during further development. > > When I evaluate DB performance, I tend to concentrate on "IO" performance, > in terms of throughput and latency, independent of the speed of the > SQL engine itself. > There's nothing I can do about the latter, while the way one uses the Client API > (or underlying protocol features) is under my control. So I do mostly > INSERTs and > SELECTs, with and without WHERE clauses (no complex JOINs, CTEs, etc...). > > Because we are in the scientific space, we care about both many small rows > (millions, of a few bytes to KBs each at most), and a few (hundreds / thousands) > much larger rows with blobs (with MBs to GBs sizes). The truly large > "blobs" (files) are > kept outside the DB, since mostly read only (in the GBs to TBs sizes each, that > can accumulate to 2.6 PB for all a client's data I heard just > yesterday for example). > > I'll also compare inserting rows 1-by-1, with and without prepared statements, > to inserting multi-rows per-statement (10, 100, 1000 at a time), to the "bulk" > interface (COPY for PostgreSQL, LOCAL for MySQL, Direct-Path load in OCI). > For example with SQLite: > https://sqlite.org/forum/forumpost/baf9c444d9a38ca6e59452c1c568044aaad50bba… > (SQLite as no "bulk" interface, doesn't need one, since "embedded" > thus "zero-latency") > > For PostgreSQL, we also compared text vs binary modes (for binds and > resultsets). > > For blobs, throughput of reading and writing large blobs, whole and in-part, > with different access patterns, like continuous ranges, or scattered inside). > > A very important use-case for us, for minimizing round-trips, is how > to load a subset of rows, > given a list of primary keys (typically a surrogate key, like an > integer or a uuid). For that, > we bind a single array-typed value for the WHERE clause's placeholder > to the query, > and read the resultset, selecting 1%, 5%, 10%, etc... of the rows from > the whole table. > (selecting each row individually, even with a prepared query, is terribly slow). Thanks for sharing. It will definitely help me during benchmarking. Regards, Ruben.

1 0

Mixing C++ language versions
by Kenneth Porter 12 May '22

12 May '22

Can one mix compilation units or libraries built with different versions of C++? If I build my DLL with C++20, can a customer use it with their C++11 app? How are compiler and library vendors dealing with this? Do/will they supply multiple binaries for each C++ version? (I'm already building for each architecture plus release/debug. Adding the compiler version explodes the number of binaries to build and test.)

3 3

Re: [boost] Mixing C++ language versions
by Glen Fernandes 12 May '22

12 May '22

On Thu, May 12, 2022 at 6:52 AM Kenneth Porter via Boost <boost(a)lists.boost.org> wrote: > > Do/will they supply multiple binaries for each C++ version? (I'm already building for > each architecture plus release/debug. Adding the compiler version explodes > the number of binaries to build and test.) The variants you have so far are: - Architecture - Release or Debug I've known library vendors to even have the following variants: - Architecture - Release or Debug - C++ standard version - Static or dynamic linking with the C++ runtime library - Single or multi threaded versions of the C++ runtime library (at one point in time) Shipping library sources to your users (instead of binaries) might be easier. Glen

1 0

[filesystem] create_directories fails on exFat formatted disk under Windows
by Chris Trueman 12 May '22

12 May '22

Using an exFat formatted disk with Windows. Start with a path: e:\tmp Call filesystem::create_directories("e:\\tmp\\boost") This should succeed, creating the boost folder in e:\tmp. It fails with boost 1.79.0. It tries to create e:\tmp which already exists. In boost 1.78.0 this works as expected. I believe the root cause is the change to status(...). It calls detail::symlink_status(...) which calls GetFileInformationByHandleEx which (at least for the params used in filesystem) doesn't work on exFat formatted disks. Chris.

2 2

SOCKS-Asio library
by Alan de Freitas 11 May '22

11 May '22

Hi, everyone! I've been writing this library for SOCKS4/5 based on Asio. The library is very embryonic but there's enough to connect to proxy servers and relay messages. I could really use some negative feedback. If anyone would like to give it a try, here are the links: Repo: https://github.com/alandefreitas/socks_proto Docs: https://develop.socks-proto.cpp.al/ #boost-socks on Slack Thanks! -- Alan Freitas https://github.com/alandefreitas

2 1

Re: [boost] Boost Digest, Vol 6699, Issue 1
by Benedict Bede McNamara 08 May '22

08 May '22

You need modules urgently. Sent from Mail for Windows From: boost-request(a)lists.boost.org Sent: Sunday, 8 May 2022 10:00 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6699, Issue 1 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Seth) 2. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Christopher Kormanyos) 3. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Bo Persson) ---------------------------------------------------------------------- Message: 1 Date: Sat, 07 May 2022 15:30:08 +0200 From: Seth <bugs(a)sehe.nl> To: "Boost List" <boost(a)lists.boost.org> Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <e76334c1-625a-4ee2-999f-75959822562b(a)www.fastmail.com> Content-Type: text/plain > Even though 14 has lotsof bug fixes, > the only real key advanced featureis relaxed constexpr constraints > anddigit separators. I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs) ------------------------------ Message: 2 Date: Sun, 8 May 2022 09:31:19 +0000 (UTC) From: Christopher Kormanyos <e_float(a)yahoo.com> To: Boost List <boost(a)lists.boost.org> Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <1679327021.415697.1652002279472(a)mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 >> Even though 14 has lotsof bug fixes, >> the only real key advanced featureis>> relaxed constexpr constraints >> and digit separators. I apologize for my perhaps unwisely chosen(or even wrong) wording. > I'd say that polymorphic lambdas, lambda> capture initializers, return type deduction,> decltype(auto) are all more important> and really felt. ... And I do respect this comment. But I'm not quite ready to give upon eleven just yet... Let's argue the controversial C++11/14baseline issue from a purely service-oriented,product-management point of view. Boost has a deep symbiosis with C++11and vice-versa. There are clients usingBoost with C++11. To drop C++11 from a product/servicepoint of view should only be allowed ifa viable option is provided --- freelyand easily obtained --- for those clientsusing Boost with C++11. So I would say, prove to the clients,prove to ourselves what this optionactually is. Which option will allowclients stuck on C++11 (maybe notby choice) to continue to use Boostwithout C++11 support? One possibility comes to mind:Freeze at 1.80 if you need C++11,but I don't like this option. Kind regards, Chris On Saturday, May 7, 2022, 03:36:26 PM GMT+2, Seth via Boost <boost(a)lists.boost.org> wrote: > Even though 14 has lotsof bug fixes, > the only real key advanced featureis relaxed constexpr constraints > anddigit separators. I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ Message: 3 Date: Sun, 8 May 2022 12:37:00 +0200 From: Bo Persson <bo(a)bo-persson.se> To: boost(a)lists.boost.org Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <t586gu$cfq$1(a)ciao.gmane.io> Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-05-08 at 11:31, Christopher Kormanyos via Boost wrote: > >> Even though 14 has lotsof bug fixes, >> the only real key advanced featureis>> relaxed constexpr constraints >> and digit separators. > I apologize for my perhaps unwisely chosen(or even wrong) wording. > >> I'd say that polymorphic lambdas, lambda> capture initializers, return type deduction,> decltype(auto) are all more important> and really felt. > ... And I do respect this comment. > But I'm not quite ready to give upon eleven just yet... > > Let's argue the controversial C++11/14baseline issue from a purely service-oriented,product-management point of view. > Boost has a deep symbiosis with C++11and vice-versa. There are clients usingBoost with C++11. > To drop C++11 from a product/servicepoint of view should only be allowed ifa viable option is provided --- freelyand easily obtained --- for those clientsusing Boost with C++11. > So I would say, prove to the clients,prove to ourselves what this optionactually is. Which option will allowclients stuck on C++11 (maybe notby choice) to continue to use Boostwithout C++11 support? It can also be argued that we might do some clients a disservice instead of a service. If the new features are *that* useful for the library authors, would they not be equally useful for the clients' code? By supporting old compilers and standards we let them procrastinate for another couple of years. Is that good? Or should we encourage them to move on? Perhaps a gentle push is all they need? "New and improved" is often used in product-marketing. Why not here? > One possibility comes to mind:Freeze at 1.80 if you need C++11,but I don't like this option. > > Kind regards, Chris > > ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6699, Issue 1 **************************************

2 1

Copy_File Method Question
by Sean B 06 May '22

06 May '22

Good afternoon, Thank you for allowing me to join the group as I a newbie to the boost c++ libraries. My question I have to the development group is based on the copy_file method. Does the copy_file do a 'bit to bit' copy using (check sums and hash) or the original file? Thanks for any information on this.

2 1

C++ package managers
by Adam Getchell 06 May '22

06 May '22

For what it’s worth, having tried Biicode (Conan’s predecessor), Conan, Spack, Conda, and vcpkg, vcpkg is the only package manager for which I’ve been able to consistently (i.e. since I started using it a few years ago) build combinations of {macOS, Linux, Windows } x { gcc, clang, msvc}. As my research project includes CGAL which includes Boost, Eigen, and TBB, that ends up being 100+ libraries. Manifest mode just works, and vcpkg artifacts looks promising: https://devblogs.microsoft.com/cppblog/vcpkg-artifacts/ -- Adam Getchell acgetchell(a)ucdavis.edu https://adamgetchell.org

2 2

Boost Community Maintenance Team Repository List
by James E. King III 28 Apr '22

28 Apr '22

Is the list of current CMT repositories accurate? I have been updating them with the latest GitHub Actions + Appveyor builds: https://svn.boost.org/trac10/wiki/CommunityMaintenance For reference, I maintain a spreadsheet on the current CI state of the CMT repositories as well as others I maintain and some I have assisted with - specifically to track their CI status: https://docs.google.com/spreadsheets/d/1aFdTMdJmmD9L5IyvJx-nj3BrMVztmlNo8Qw… Thanks, Jim

3 4

[dynamic_bitset] commit review - assist
by James E. King III 27 Apr '22

27 Apr '22

I could use some additional eyes on a few commits from a new submitter, if anyone wants to take a look. Hopefully I am going down the right path in my pedanticism. Thanks, - Jim

2 1

[release] Boost 1.79.0
by Marshall Clow 26 Apr '22

26 Apr '22

Release 1.79.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.79.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.79.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Michael Caisse, Glen Fernandes

9 17

Cross-compile for Apple Silicon on an x86 Mac
by Ian Emmons 26 Apr '22

26 Apr '22

I am trying to build Boost 1.79.0 shared libraries on an x86-based Mac running the latest MacOS (Monterey, 12.3.1) using the latest Xcode (13.3.1, with Apple’s clang 13.1.6). Everything works great for building shared libraries that run on an x86-based Mac. My ideal would be to build a single set of universal (a.k.a. “fat”) binaries that include both x86 and ARM code, but Boost.Build does not seem to contain an option to do that. (Such options existed in the past for Intel/PowerPC combinations and then later for 64-bit/32-bit Intel combinations.) Second best is to build two sets of binaries, one for x86 and another for ARM. I tried to do this using the option architecture=x86,arm on the b2 command line, and it does in fact build two sets of binaries with the expected file names. For instance, for filesystem it builds these two: libboost_filesystem-clang-darwin13-mt-a64-1_79.dylib libboost_filesystem-clang-darwin13-mt-x64-1_79.dylib But when I use the “file” command to inspect the types of these files, they both are reported as "Mach-O 64-bit dynamically linked shared library x86_64”. Am I doing something wrong, here? Or is there a bug in Boost.Build regarding cross-compiling? Thanks, Ian

3 2

Re: [boost] JSON parser error handling
by Vinnie Falco 26 Apr '22

26 Apr '22

On Mon, Apr 25, 2022 at 1:55 PM Kenneth Porter via Boost <boost(a)lists.boost.org> wrote: > I don't see any information on where in the source string the > parse error happened so I have to set a breakpoint in my tag_invoke > functions to figure out where the syntax errors lie. You have two potentially throwing lines: boost::json::value jv = boost::json::parse(contents); and axes = boost::json::value_to<std::vector<AxisProperties> If your exception is coming from the call to parse() and you want to know where in the string you are, then you need to change your code to create an instance of json::parser and call parser::write or parser::write_some to feed in the input. These functions return the number of characters consumed, which will be less than the amount passed in if an error occurs. In this case, the number of characters parsed successfully can be used to calculate an offset into the input buffer to determine where the syntax error happened. If your exception is coming from the call to value_to<>(), things are not so simple. The original JSON string is no longer available, and information about which json::value came from what part of the string is not stored (that would slow down the library and take up unnecessary memory). The best you can do in this case is to set up BOOST_THROW_EXCEPTION to get a breakpoint at the moment an exception is thrown, and then use a debugger to inspect the state of the program. You can also attach source file and line number information to exceptions when they are thrown (the library already does this). Boost.JSON throws all exceptions from these functions; alternatively, you could set a breakpoint in each of them to inspect the state of the program when an error is encountered: <https://github.com/boostorg/json/blob/83c364afaf31b58cfe8b97ab159c406c508f4…> Thanks

2 1

JSON parser error handling
by Kenneth Porter 25 Apr '22

25 Apr '22

I'm using Boost.JSON to load some static data into a tree of structures. The parser throws exceptions on parse errors, and I print the std::exception::what() string. (I throw them up in a messagebox in my GUI.) I see things like "not a number" when parsing a string where a number was expected. But I don't see any information on where in the source string the parse error happened so I have to set a breakpoint in my tag_invoke functions to figure out where the syntax errors lie. Is there some way to get the library to report the offset in the source string to where the parse error happens as part of the exception? Here's my top-level invocation: #include <fstream> #include <stdexcept> #define BOOST_DLL_USE_STD_FS 1 // tell program_location to return a std::filesystem::path #include <boost/dll/runtime_symbol_info.hpp> // program_location #include <boost/json/src.hpp> // header-only implementation std::ifstream is(boost::dll::program_location().replace_extension("json")); std::string contents; contents.assign(std::istreambuf_iterator<char>(is), std::istreambuf_iterator<char>()); boost::json::value jv = boost::json::parse(contents); axes = boost::json::value_to<std::vector<AxisProperties> >(jv.as_object().at("axis")); Library source and background: <https://github.com/boostorg/json>

1 0

[dynamic_bitset] Add at(size_type) & Support unsiged long long since C++11.
by Nya Nya 23 Apr '22

23 Apr '22

I would like to add two member functions, `at(size_type)` and `to_ullong()`, and since C++11, the constructor is promoted from `unsigned long` to `unsigned long long`. 1. at(size_type) I think it's necessary to have a member function that does bounds checking and throws exceptions. 2. dynamic_bitset(size_type, unsigned long long, const Allocator&) & to_ullong() The constructor of std::bitset is unsigned long long since C++11, and a new member function `to_ullong()` has also been added. I know this library needs to be compatible with C++03, but I think it can be solved with the macro `BOOST_NO_LONG_LONG`. Now I have submitted a pull request for the member function `at(size_type)`. If allowed, I will submit a pull request for unsigned long long later. Thanks!

1 0

Boost.URL Proposal
by Alan de Freitas 20 Apr '22

20 Apr '22

Hi, again! Now that the Boost 1.79 has shipped, I'm just passing by to remind you folks that Vinnie and I are looking for a review manager for the library that we hope will become Boost.URL. As usual, we are available to answer questions about the library on the list, on the GitHub repository page <https://github.com/CPPAlliance/url>, via email <alandefreitas(a)gmail.com>, or on Slack (in #boost-url). Thanks, -- Alan Freitas https://github.com/alandefreitas

3 5

Build Boost Back Better
by Vinnie Falco 20 Apr '22

20 Apr '22

Well, now that I have everyone's attention just before the release, I'd like to draw attention to the elephant in the room. That is, the declining level of activity on the Boost mailing lists and the declining level of participation in the Boost formal review process. Both in terms of the number of reviewers, and in terms of the difficulty in finding a review manager. Clearly, a website update is necessary and along with it some type of campaign to highlight once again the important role that Boost serves in the C++ community for both professionals and amateurs alike. But what more can we do? This came up before but it is worth mentioning again; in addition to a website update to make boost.org modern and relevant, how do we feel about a transition to forum-based discussion instead of the mailing list? I realize this will ruffle some feathers but surely the alternative, a descent into irrelevance due to steady declining activity is worse? Discuss. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

29 68

Changes in buildable components over time
by Tim Haines 19 Apr '22

19 Apr '22

I've recently needed to understand which components need to be built, which are header-only, and what versions correspond to each component (i.e., when was it introduced, when was it removed). Combining the outputs from 'bootstrap.sh --show-libraries' since 1.39.0 and scraping the library listings on the website as of 1.78.0, I was able to identify everything I needed. Surprisingly, though, it appears that coroutine2 and metaparse started out as buildable components, but then switched to being header-only. coroutine2 - introduced in 1.59.0 - first buildable in 1.59.0 - last buildable in 1.64.0 - available as of 1.78.0 metaparse - introduced in 1.61.0 - first buildable in 1.61.0 - last buildable in 1.65.1 - available as of 1.78.0 I cross-referenced the release notes, but I didn't see any mention of these components being made header-only. Is this intended behavior? Thanks. - Tim

2 3

New Boost Website: Open to Volunteers!
by Vinnie Falco 19 Apr '22

19 Apr '22

The C++ Alliance is putting together a working prototype of a new website to replace what is currently at boost.org. We could use help with exposition on most of the new pages. And feedback could be helpful to refine some of the interfaces and layouts. If there is consensus and the site replaces boost.org, there will be at least one or more revisions. So it is not necessary to get everything "perfect" on the first pass (or else it will never be finished). Note that this is not a design-by-committee project. There are specific goals that are thought essential to refresh the foundations of Boost's social technology. For example, we are building a forum as the primary means of message-based interaction. However we are also building a connector so that users who want to use a mailing-list style interface can continue to do so with no interruption of service. If you would like to participate in the process of building this site then feel free to subscribe to this new mailing list: <https://lists.boost.org/mailman/listinfo.cgi/boost-www> Thanks Vinnie

9 23

Does Anyone Need Help?
by Vinnie Falco 19 Apr '22

19 Apr '22

The C++ Alliance is receiving many applications with qualified C++ candidates, but we are having a hard time matching them up with long-term projects which are aligned with our organization's goals. Is there a list of libraries that need help or does anyone know of one or more particular libraries that are in need of improvement and work? -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

8 13

ignore_unused
by Vinnie Falco 18 Apr '22

18 Apr '22

Isn't it better to just write (void) x; instead of including a whole header file: #include <boost/core/ignore_unused> just to write boost::ignore_unused( x ); ? -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

4 3

Is there a design reason why beast static_string uses size_t for length?
by Ivan Matek 16 Apr '22

16 Apr '22

Internally as a member, not talking about template argument. I would naively assume that performance overhead of having conversion from uint8_t/uint16_t(and uint32_t if you want to allow "insanely" large static_strings) to size_t is not big enough to justify "large"(in context of microoptimizations for space) overhead due to alignment and size requirements of size_t(on 64b machines). Recently I other context I complained that there is no way to nicely embed godbolt/source examples in here :), so here is a link with example: https://godbolt.org/z/Y4Y5zKj86 regards, Ivan

3 4

Boost.Text is looking for a (mini-)review manager
by Mateusz Loskot 15 Apr '22

15 Apr '22

Hi, A reminder from the review wizards: The Boost.Text library developed by Zach Laine is still looking for a (mini-)review manager, see details at: https://lists.boost.org/Archives/boost//2020/08/249594.php and https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

MySQL library scheduled for review
by Mateusz Loskot 15 Apr '22

15 Apr '22

Hi, A brief announcement from the review wizards: Following the proposal [1] and search for the review manager, formal review of the MySQL library [2] has been scheduled to take place between May 9, 2022 - May 18, 2022. Details and links available here https://www.boost.org/community/review_schedule.html We'd like to thank Richard Hodges for volunteering to act as the review manager, again! [1] https://lists.boost.org/Archives/boost/2022/03/252584.php [2] https://github.com/anarthal/mysql/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[release] Master branch is now open for merging
by Glen Fernandes 14 Apr '22

14 Apr '22

Master is open again, with no restrictions. Next milestone: June 22, Boost 1.80.0 closed for new libraries and breaking changes Release calendar: https://boost.org/development Glen

1 0

[release] Boost 1.7.0 beta 1 released
by Marshall Clow 13 Apr '22

13 Apr '22

Boost release 1.77.0 beta 1 is now available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.78.0.beta1/source/> The SHA256 checksums are as follows: 7a3a025451dfa2923129214eef7d16b03c02310a353d02158a549f6caa4284b0 boost_1_78_0_b1.tar.bz2 c491b1dcb916195598aa6581d6708d57fcc750516641c22511c088d572de9c07 boost_1_78_0_b1.tar.gz 35e7a3b0eb412a3933e57c72ba96374eb7d88ff1f89dbec62a16d67ffea2105a boost_1_78_0_b1.7z e6b68feb2f63401c96ca9fe25e939b409189fbe526a6e784e4bd69832c8f09cb boost_1_78_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_78_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

Is Boost interested in a Redis client library?
by Marcelo Zimbres Silva 13 Apr '22

13 Apr '22

Hi, I am the author of Aedis, a Redis client library built on top of Boost.Asio that provides communication with the Redis Server over its native and most recent protocol RESP3 [1]. It is an implementation from scratch that depends only on other Boost Libraries (Asio, Variant2, Optional, etc.) and targets C++14. I would like to propose it for inclusion in Boost in the near future if there is enough interest, at the moment I am interested in early feedback as I finish writing it (writing docs, improving tests etc.) - Do you think this library would be valuable to Boost? - Was the documentation helpful to understand what Aedis provides? - Does the design look good? - Any feedback is welcome. Link to Aedis Documentation: https://mzimbres.github.io/aedis/ Link to the github project: https://github.com/mzimbres/aedis If you never heard about Redis, this is the best place to start: https://redis.io Regards, Marcelo [1] https://github.com/antirez/RESP3/blob/master/spec.md

6 17

Proposing a MySQL client library for inclusion in Boost
by Ruben Perez 08 Apr '22

08 Apr '22

Hi all, I would like to propose my MySQL client library for inclusion in Boost. The library features asynchronous communication with MySQL and MariaDB servers, allowing the user to use txt queries and prepared statements. The library is based on Boost.Asio and follows its asynchronous model (in a similar way Boost.Beast does). The library is specific to MySQL and MariaDB systems, and is not intended as a SQL framework or ORM. It fits use cases like HTTP servers (possibly already using Beast), ETL pipelines or any other application that needs to access a MySQL database and wants to benefit from Asio's asynchrony. Please note that the library is a full implementation of MySQL wire protocol and does not use libmysqlclient under the hood. I'm looking for people who officially endorse the library. You can see the code in this GitHub repository <https://github.com/anarthal/mysql>, and the documentation is here <https://anarthal.github.io/mysql/index.html>. Many thanks, Ruben.

4 11

[release] Boost 1.79.0 Release Candidate 1 is available
by Marshall Clow 08 Apr '22

08 Apr '22

https://boostorg.jfrog.io/artifactory/main/release/1.79.0/source/ The first release candidates for the 1.79.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.79.0/source/> The SHA256 checksums are as follows: 3634f9a85759311f321e587eace21799c0d0c946ff933e477a2f98885c54bbff0 boost_1_79_0_rc1.zip 273f1be93238a068aba4f9735a4a2b003019af067b9c183ed227780b8f36062c boost_1_79_0_rc1.tar.gz 475d589d51a7f8b3ba2ba4eda022b170e562ca3b760ee922c146b6c65856ef39 boost_1_79_0_rc1.tar.bz2 6c97cf4f4a0eb00ed776c88065ab3f59e183fa5e65f6464ff94f92328352d9d6 boost_1_79_0_rc1.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

5 6

Master branch now closed for 1.79.0 release
by Marshall Clow 07 Apr '22

07 Apr '22

Please do not make any commits to the master branch. — Marshall

1 0

Time delay Issue with async_write_some and async_read_some
by Daggumati, Rajesh 07 Apr '22

07 Apr '22

Hi Team, We can see two different behaviours in communication when we tested in windows and Linux with same hardware .Windows responded slowly compared to Linux. We are using async_write_some and async_read_some methods from boost library for RS-232 communication with hardware(COM1). m_serialPort.async_write_some(boost::asio::buffer(toSend), boost::bind(&SerialPortAsync::HandleSentData, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); m_serialPort.async_read_some(boost::asio::buffer(m_RecvBuffer), boost::bind(&SerialPortAsync::HandleReceive, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); Comparison Linux Vs Windows for same application : Linux Sending Time ---> 2020/11/23 17:34:56.678585,1064, , <-- (+0.000151) (11)[010B0557,0D0001E8,03C40F] [tx-queue:24] Send Receiving Time ---> 2020/11/23 17:34:56.680490,1064, , --> (+0.001905) (8)[060B0557,040D00E8] [tx-queue:24] Turnaround time : 0.001905 Windows Sending Time ---> 2022/03/28 14:41:28.662338,5388, , <-- (+0.000000) (11)[010B0457,0D0001E8,035BDA] [tx-queue:40] Receiving Time --> 2022/03/28 14:41:28.693591,5388, , --> (+0.031253) (9)[06090457,0D0001B0,1F] [tx-queue:40] Turnaround time : 0.031253 We want to know why windows takes more time as compared to Linux. We cannot put more debug logs in the application code. Below this layer, boost library play the role to transfer the data to the Serial port Regards, Rajesh D Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

1 1

[release] 1.79.0 post-beta merges
by Marshall Clow 06 Apr '22

06 Apr '22

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy>> Reminder: The master branch closes for the release on Wednesday, April 6th. Full calendar here: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall P.S Doc changes and test changes do NOT require release manager approval to be merged.

7 12

So.... what are we going to do about modules?
by John Maddock 06 Apr '22

06 Apr '22

The title says it all really, but in more detail: 1) Is there any existing best practice we should follow yet? 2) Can we share code content effectively between headers and modules? And by modules I mean "proper" ones: we should be able to write "import boost.whatever;" rather than importing a header. 3) What directory structure should we all be using for module definition files? 4) Do we have Boost.Build support yet? 5) What file extensions should we be using? 6) I presume we would all use the boost.libraryname and boost.libraryname.sub_feature naming convention with boost.libraryname pulling in the whole library? 7) Does anyone have a handle on the current state of std library modularization? 8) Is there demand for this? And no doubt lots of other things I haven't thought of. Curiously yours, John.

11 27

Permission to merge bug fix to Outcome
by Niall Douglas 06 Apr '22

06 Apr '22

Issue being fixed is https://github.com/ned14/outcome/issues/259 where enabling of move assignment was not calculated correctly. (To be specific, if both T and E implement move assignment and default construction, but not move nor copy construction, we did not enable move assignment before and with this fix now we do) Code fixing it is at https://github.com/ned14/outcome/pull/260 Fix passes on develop branch at https://www.boost.org/development/tests/develop/developer/outcome.html Niall

2 4

Should boost have ofind(_if), that returns boost::optional<T&>?
by Ivan Matek 06 Apr '22

06 Apr '22

Hi, I have been thinking for this for a long time so I wanted to get the feedback from others. As you probably know better than me there is a bit of a drama <https://brevzin.github.io/c++/2021/12/13/optional-ref-ptr/>when it comes to std::optional<T&> and from what I see it will not be in C++23 for sure. I believe this gives an opportunity to boost to provide something nice for the users. Now the issues are the following: AFAIK boost only has old ranges and iterator based algorithms, ideally we would just have something like std:: ranges and add the ofind/ofind_if to those, but AFAIK those do not exist. So I think best thing would be to add it to boost::algorithm <https://github.com/boostorg/algorithm/tree/develop/include/boost/algorithm> . There are further questions like, should boost containers like map/unordered_map gain similar functionality, but I think deciding if we want the general algorithm is the first step. Another option I can think of is that those algorithms return something like a 0 or 1 element view(so you could access the optional value with range based for loop). This seems weird to me, so I would prefer boost::optional<T&>. There is s a short example on godbolt <https://godbolt.org/z/W9K3na9Gc>, but don't look at implementation too much, it was just something I hacked quickly, I am mostly interested in in feedback on if functionality would be nice addition to boost. regards, Ivan

5 9

regarding performance of boost::recursive_mutex::scoped_lock
by Daggumati, Rajesh 04 Apr '22

04 Apr '22

Hi Team, boost::recursive_mutex::scoped_lock behavior is same in linux and windows? I am getting some delay in my project which is in windows but same project in linux is not getting delayed. Regards, Rajesh D Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

2 1

[release][multi_index] permission to merge to master
by Joaquin M López Muñoz 03 Apr '22

03 Apr '22

Hi, the following PR is absolutely trivial https://github.com/boostorg/multi_index/pull/57 but seems like it's important to Bitcoin guys in connection with an effort to prune internal Boost dependencies they're carrying out. Can I merge to master or should I wait till Boost 1.80? Thank you, Joaquín M López Muñoz

2 2

Re: [boost] Proposing a MySQL client library for inclusion in Boost
by Marcelo Zimbres Silva 02 Apr '22

02 Apr '22

Hi Ruben, I have had a look into your library and some questions arise > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__resultset/async_re… > The handler signature for this operation is void(boost::mysql::error_code, std::vector<boost::mysql::row>). > etc. Having a std::vector in the signature of the completion handler is unusual in ASIO. In general large objects should be passed as parameters in the async operation e.g. socket::async_read gets a dynamic_buffer which is a lightweight view to storage. Additionally, there is not support for custom allocators. That wouldn't be a big problem to me if I could reuse the same memory for each request but the interface above prevents me from doing so. > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__connection/async_q… > The handler signature for this operation is void(boost::mysql::error_code, boost::mysql::resultset<Stream>) Hier the completion handler is returning an io object i.e. boost::mysql::resultset, which is also unusual as far as I can see. Does that play nice with executors? I would prefer having the completion handler return config parameters with which I can instantiate a boost::mysql::resultset myself in my desired executor. > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__connection.html I don't see a reason for this class, or at least I fail to see what state does the mysql protocol imposes on you that would justify this class. I would prefer free funcitions much more here, for example, in the same way as beast::http::async_read. > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_std_opti… > https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_optional… Sounds also unusual to have two member functions for the different versions of optional. Regards, Marcelo

3 7

Boost.URL Proposal max_size
by Alan de Freitas 26 Mar '22

26 Mar '22

Hi! We're deciding on the max size for URLs in our Boost.URL proposal. The spec doesn't suggest a limit but the reasonable trade-off <https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-…> is: - 2^16 chars: More than all browsers, servers, and search engines support (~2000 chars). More than the HTTP minimum of 8000 octets. - 2^32 chars: "414 Too long request" in practice everywhere. Maybe supports experiments using URLs as a container for something else. Any suggestions? -- Alan Freitas https://github.com/alandefreitas

6 6

Determine interest in a possible library submission
by Keith Hiatt 21 Mar '22

21 Mar '22

Hi All, I was wondering about interest in some derived vector classes which support full vector functionality while adding the capabilities of mathematical operations on the datasets including matrix-based computations. Any thoughts would be appreciated. Thank you, Keith

3 2

Re: [boost] Boost Digest, Vol 6661, Issue 1
by Keith Hiatt 21 Mar '22

21 Mar '22

Hi Vinnie, It is almost complete. Is there a GIT repository where I can upload it? I have not been using a repository for my code and would like to do so. Thank you On Mon, Mar 21, 2022 at 8:00 AM <boost-request(a)lists.boost.org> wrote: > Send Boost mailing list submissions to > boost(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.boost.org/mailman/listinfo.cgi/boost > or, via email, send a message with subject or body 'help' to > boost-request(a)lists.boost.org > > You can reach the person managing the list at > boost-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost digest..." > The boost archives may be found at: http://lists.boost.org/Archives/boost/ > Today's Topics: > > 1. Re: [release] Boost 1.79.0 beta 1 released (Sal Pamukcu) > 2. Re: [release] Boost 1.79.0 beta 1 released (Jeff Trull) > 3. Determine interest in a possible library submission (Keith Hiatt) > 4. Re: Determine interest in a possible library submission > (Vinnie Falco) > > > > ---------- Forwarded message ---------- > From: Sal Pamukcu <salimp2009(a)gmail.com> > To: boost(a)lists.boost.org > Cc: > Bcc: > Date: Sun, 20 Mar 2022 19:40:51 +0300 > Subject: Re: [boost] [release] Boost 1.79.0 beta 1 released > On Fri, Mar 18, 2022 at 1:53 AM Andrey Semashev via Boost < > boost(a)lists.boost.org> wrote: > > > On 3/18/22 00:26, Sal Pamukcu via Boost wrote: > > > On Thu, Mar 17, 2022 at 11:24 PM Andrey Semashev via Boost < > > > boost(a)lists.boost.org> wrote: > > > > > >> On 3/17/22 22:31, Sal Pamukcu via Boost wrote: > > >>> - Compiled on Win 11 MSVC 2002 x64 toolchain with c++20 using > > >>> b2 cxxstd=20 --build-type=complete stage > > >>> > > >>> failed 5 target ; (mostly related to python) > > >>> The full built message are on gist ; > > >>> boost179b1_MSVC (github.com) > > >>> <https://gist.github.com/salimp2009/074cf168b4dd1231aa92fcc3845e2df7 > > > > >>> > > >>> I will do another build on windows with gcc-11.2 with MSys; > > >>> > > >>> ``` > > >>> ...failed updating 5 targets... > > >>> ...skipped 9 targets... > > >>> ...updated 8376 targets... > > >>> ``` > > >>> > > >>> Failures are like this ; > > >>> `...failed msvc.link.dll > > >>> > > >> > > > bin.v2\libs\python\build\msvc-14.3\debug\address-model-32\cxxstd-20-iso\python-3.10\threading-multi\boost_python310-vc143-mt-gd-x32-1_79.dll > > >>> > > >> > > > bin.v2\libs\python\build\msvc-14.3\debug\address-model-32\cxxstd-20-iso\python-3.10\threading-multi\boost_python310-vc143-mt-gd-x32-1_79.lib > > >>> > > >> > > > bin.v2\libs\python\build\msvc-14.3\debug\address-model-32\cxxstd-20-iso\python-3.10\threading-multi\boost_python310-vc143-mt-gd-x32-1_79.pdb...` > > >> > > >> Looks like the problem is that you're building 32-bit Boost.Python and > > >> linking with 64-bit Python libraries. I'm not sure if Boost.Python is > > >> supposed to find the correct libraries or this is just a user > > >> configuration error. > > > > > > Do you mean my configuration mistake; > > > i installed python 3.10 64 bit > > > and checked from MSVC VS 2022 64 bit command line using this ; > > > It looks like my Python is 64 bit; > > > > > > C:\Program Files\Microsoft Visual Studio\2022\Community> > > > C:\Program Files\Microsoft Visual Studio\2022\Community>python > > > Python 3.10.0 (tags/v3.10.0:b494f59, Oct 4 2021, 19:00:18) [MSC v.1929 > > 64 > > > bit (AMD64)] on win32 > > > Type "help", "copyright", "credits" or "license" for more information. > > >>>> import struct > > >>>> version = struct.calcsize("P")*8 > > >>>> print(version) > > > 64 > > >>>> > > > > > > is there a way to configure when building with b2 > > > I used this ; b2 cxxstd=20 --build-type=complete stage > > > > By default both 32 and 64-bit Boost binaries are built. To build only > > 64-bit binaries you can add address-model=64 to the b2 command line. If > > you want to build 32-bit libraries, use address-model=32 and also make > > sure 32-bit Python libraries are found by the build process. > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > I did another build on Windows 11 ; this time using gcc-11.2 (via MSys2 > MinGW), c++20 > I did 2 runs one on command line and one on x64 Native Tool MSCV 2022 > Also used address-model=64 to avoid Python 32-bit > No errors but compiled way less files this time ; typically it was around > ~8000+ > this time "...updated 3693 targets.." > command line i used ; > b2 cxxstd=20 address-model=64 toolset=gcc --build-type=complete stage > > as usual got warning for auto_ptr and this one ; > > C:/msys64/mingw64/include/c++/11.2.0/ext/new_allocator.h:145:26: warning: > 'void operator delete(void*, std::size_t)' called on unallocated object > 'boost::wave::util::SimpleStringStorage<char, std::allocator<char> > >::emptyString_' [-Wfree-nonheap-object] > 145 | ::operator delete(__p > | ~~~~~~~~~~~~~~~~~^~~~ > 146 | #if __cpp_sized_deallocation > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 147 | , __t * sizeof(_Tp) > | ~~~~~~~~~~~~~~~~~~~ > 148 | #endif > | ~~~~~~ > 149 | ); > > If needed I can put the whole build outputs on gist. > > Only one question is it normal to use address-model=64 or should this be > detected thru b2 or CMake and if it causes any other needed > libraries skipped because there was quite a bit of difference in the > updated amount > > Salim Pamukcu > > > > > ---------- Forwarded message ---------- > From: Jeff Trull <linmodemstudent(a)gmail.com> > To: Boost Developers List <boost(a)lists.boost.org> > Cc: > Bcc: > Date: Sun, 20 Mar 2022 10:21:18 -0700 > Subject: Re: [boost] [release] Boost 1.79.0 beta 1 released > On Sun, Mar 20, 2022 at 9:41 AM Sal Pamukcu via Boost < > boost(a)lists.boost.org> > wrote: > > > On Fri, Mar 18, 2022 at 1:53 AM Andrey Semashev via Boost < > > boost(a)lists.boost.org> wrote: > > > > > On 3/18/22 00:26, Sal Pamukcu via Boost wrote: > > > > On Thu, Mar 17, 2022 at 11:24 PM Andrey Semashev via Boost < > > > > boost(a)lists.boost.org> wrote: > > > > > > > >> On 3/17/22 22:31, Sal Pamukcu via Boost wrote: > > > >>> - Compiled on Win 11 MSVC 2002 x64 toolchain with c++20 using > > > >>> b2 cxxstd=20 --build-type=complete stage > > > >>> > > > >>> failed 5 target ; (mostly related to python) > > > >>> The full built message are on gist ; > > > >>> boost179b1_MSVC (github.com) > > > >>> < > https://gist.github.com/salimp2009/074cf168b4dd1231aa92fcc3845e2df7 > > > > > > >>> > > > >>> I will do another build on windows with gcc-11.2 with MSys; > > > >>> > > > >>> ``` > > > >>> ...failed updating 5 targets... > > > >>> ...skipped 9 targets... > > > >>> ...updated 8376 targets... > > > >>> ``` > > > >>> > > > >>> Failures are like this ; > > > >>> `...failed msvc.link.dll > > > >>> > > > >> > > > > > > bin.v2\libs\python\build\msvc-14.3\debug\address-model-32\cxxstd-20-iso\python-3.10\threading-multi\boost_python310-vc143-mt-gd-x32-1_79.dll > > > >>> > > > >> > > > > > > bin.v2\libs\python\build\msvc-14.3\debug\address-model-32\cxxstd-20-iso\python-3.10\threading-multi\boost_python310-vc143-mt-gd-x32-1_79.lib > > > >>> > > > >> > > > > > > bin.v2\libs\python\build\msvc-14.3\debug\address-model-32\cxxstd-20-iso\python-3.10\threading-multi\boost_python310-vc143-mt-gd-x32-1_79.pdb...` > > > >> > > > >> Looks like the problem is that you're building 32-bit Boost.Python > and > > > >> linking with 64-bit Python libraries. I'm not sure if Boost.Python > is > > > >> supposed to find the correct libraries or this is just a user > > > >> configuration error. > > > > > > > > Do you mean my configuration mistake; > > > > i installed python 3.10 64 bit > > > > and checked from MSVC VS 2022 64 bit command line using this ; > > > > It looks like my Python is 64 bit; > > > > > > > > C:\Program Files\Microsoft Visual Studio\2022\Community> > > > > C:\Program Files\Microsoft Visual Studio\2022\Community>python > > > > Python 3.10.0 (tags/v3.10.0:b494f59, Oct 4 2021, 19:00:18) [MSC > v.1929 > > > 64 > > > > bit (AMD64)] on win32 > > > > Type "help", "copyright", "credits" or "license" for more > information. > > > >>>> import struct > > > >>>> version = struct.calcsize("P")*8 > > > >>>> print(version) > > > > 64 > > > >>>> > > > > > > > > is there a way to configure when building with b2 > > > > I used this ; b2 cxxstd=20 --build-type=complete stage > > > > > > By default both 32 and 64-bit Boost binaries are built. To build only > > > 64-bit binaries you can add address-model=64 to the b2 command line. If > > > you want to build 32-bit libraries, use address-model=32 and also make > > > sure 32-bit Python libraries are found by the build process. > > > > > > _______________________________________________ > > > Unsubscribe & other changes: > > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > > > I did another build on Windows 11 ; this time using gcc-11.2 (via MSys2 > > MinGW), c++20 > > I did 2 runs one on command line and one on x64 Native Tool MSCV 2022 > > Also used address-model=64 to avoid Python 32-bit > > No errors but compiled way less files this time ; typically it was around > > ~8000+ > > this time "...updated 3693 targets.." > > command line i used ; > > b2 cxxstd=20 address-model=64 toolset=gcc --build-type=complete stage > > > > as usual got warning for auto_ptr and this one ; > > > > C:/msys64/mingw64/include/c++/11.2.0/ext/new_allocator.h:145:26: warning: > > 'void operator delete(void*, std::size_t)' called on unallocated object > > 'boost::wave::util::SimpleStringStorage<char, std::allocator<char> > > >::emptyString_' [-Wfree-nonheap-object] > > 145 | ::operator delete(__p > > | ~~~~~~~~~~~~~~~~~^~~~ > > 146 | #if __cpp_sized_deallocation > > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 147 | , __t * sizeof(_Tp) > > | ~~~~~~~~~~~~~~~~~~~ > > 148 | #endif > > | ~~~~~~ > > 149 | ); > > > > If needed I can put the whole build outputs on gist. > > > This looks like the same issue as > https://github.com/boostorg/wave/issues/159. > I think it's a new analysis in gcc 11 that we haven't seen before (and > therefore not > a regression). > > > > > Only one question is it normal to use address-model=64 or should this be > > detected thru b2 or CMake and if it causes any other needed > > libraries skipped because there was quite a bit of difference in the > > updated amount > > > > Salim Pamukcu > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > > > ---------- Forwarded message ---------- > From: Keith Hiatt <keith.x.hiatt(a)gmail.com> > To: boost(a)lists.boost.org > Cc: > Bcc: > Date: Sun, 20 Mar 2022 21:55:50 -0400 > Subject: [boost] Determine interest in a possible library submission > Hi All, > > I was wondering about interest in some derived vector classes which support > full vector functionality while adding the capabilities of mathematical > operations on the datasets including matrix-based computations. > > Any thoughts would be appreciated. > > Thank you, > Keith > > > > > ---------- Forwarded message ---------- > From: Vinnie Falco <vinnie.falco(a)gmail.com> > To: "boost(a)lists.boost.org List" <boost(a)lists.boost.org> > Cc: > Bcc: > Date: Sun, 20 Mar 2022 22:48:54 -0700 > Subject: Re: [boost] Determine interest in a possible library submission > On Sun, Mar 20, 2022 at 10:03 PM Keith Hiatt via Boost > <boost(a)lists.boost.org> wrote: > > I was wondering about interest in some derived vector classes which > support > > full vector functionality while adding the capabilities of mathematical > > operations on the datasets including matrix-based computations. > > If this is already written, could you please share a link? > > Thanks > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Boost 1.78.0 build issue
by Daggumati, Rajesh 21 Mar '22

21 Mar '22

Hi Team, I have built 1.76.0 sucessfully in my visual studio 2019 but when I try to build boost 1.78.0, I am facing some linker issue like below. Please help me to fix it. Severity Code Description Project File Line Suppression State Error LNK1104 cannot open file 'libboost_filesystem-vc142-mt-gd-x64-1_78.lib' checksum-writer-xml C:\Projects\Abba\src-cpp\src\apps\checksum-writer-xml\LINK 1 Error LNK1104 cannot open file 'libboost_filesystem-vc142-mt-gd-x64-1_78.lib' IPLUtilityTest C:\Projects\Abba\src-cpp\src\modules\IPLUtilityTest\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' FoundationQtTest C:\Projects\Abba\src-cpp\src\modules\FoundationQtTest\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' FoundationTest C:\Projects\Abba\src-cpp\src\modules\FoundationTest\LINK 1 Error LNK1104 cannot open file 'libboost_program_options-vc142-mt-gd-x64-1_78.lib' console-test-harness C:\Projects\Abba\src-cpp\src\apps\console-test-harness\LINK 1 Error LNK1104 cannot open file 'libboost_filesystem-vc142-mt-gd-x64-1_78.lib' InstrumentTest C:\Projects\Abba\src-cpp\src\modules\InstrumentTest\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' InstrumentQtTest C:\Projects\Abba\src-cpp\src\modules\InstrumentQtTest\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' widget-test-harness C:\Projects\Abba\src-cpp\src\apps\widget-test-harness\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' cytiva-aktaflux C:\Projects\Abba\src-cpp\src\apps\cytiva-aktaflux\LINK 1 Regards, Rajesh D Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

1 0

Boost 1.78.0 build issue
by Daggumati, Rajesh 21 Mar '22

21 Mar '22

Hi Team, I have built 1.76.0 sucessfully in my visual studio 2019 but when I try to build boost 1.78.0, I am facing some linker issue like below. Please help me to fix it. Severity Code Description Project File Line Suppression State Error LNK1104 cannot open file 'libboost_filesystem-vc142-mt-gd-x64-1_78.lib' checksum-writer-xml C:\Projects\Abba\src-cpp\src\apps\checksum-writer-xml\LINK 1 Error LNK1104 cannot open file 'libboost_filesystem-vc142-mt-gd-x64-1_78.lib' IPLUtilityTest C:\Projects\Abba\src-cpp\src\modules\IPLUtilityTest\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' FoundationQtTest C:\Projects\Abba\src-cpp\src\modules\FoundationQtTest\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' FoundationTest C:\Projects\Abba\src-cpp\src\modules\FoundationTest\LINK 1 Error LNK1104 cannot open file 'libboost_program_options-vc142-mt-gd-x64-1_78.lib' console-test-harness C:\Projects\Abba\src-cpp\src\apps\console-test-harness\LINK 1 Error LNK1104 cannot open file 'libboost_filesystem-vc142-mt-gd-x64-1_78.lib' InstrumentTest C:\Projects\Abba\src-cpp\src\modules\InstrumentTest\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' InstrumentQtTest C:\Projects\Abba\src-cpp\src\modules\InstrumentQtTest\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' widget-test-harness C:\Projects\Abba\src-cpp\src\apps\widget-test-harness\LINK 1 Error LNK1104 cannot open file 'libboost_thread-vc142-mt-gd-x64-1_78.lib' cytiva-aktaflux C:\Projects\Abba\src-cpp\src\apps\cytiva-aktaflux\LINK 1 Regards, Rajesh D Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

1 0

[release] Boost 1.79.0 beta 1 released
by Marshall Clow 20 Mar '22

20 Mar '22

Boost release 1.79.0 beta 1 is now available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.79.0.beta1/source/> The SHA256 checksums are as follows: 8985105623f48d55be01076d98ca4e7a8cb548a8d7f9ad0e1fc3c710d2c75fcf boost_1_79_0_b1.tar.bz2 4b58e4d3b6ff1176b3c6cb9eec496c1f6d2535270e97ec140da533d68766ca39 boost_1_79_0_b1.tar.gz 4d05b458cd039afe86003cf7e1e6c3a358b5b2d031892e620eedc344ab200246 boost_1_79_0_b1.7z 768875ad5c77763445e8b119072cfa1e64854b071a353dd44c3c73ff46df910b boost_1_79_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_79_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 6

numeric_cast should work with enum's
by Frederick Virchanza Gotham 16 Mar '22

16 Mar '22

(Sometimes Gmail takes out white space so I'm hoping this post is indented properly.) I think that "numeric_cast" should be able to cast to and from enum types, so that it can be used as follows: #include <cstdint> #include <iostream> using std::cout; using std::endl; enum class Toad : std::uint8_t { Purple, Orange = 0x7f }; enum class Frog { Blue, Yellow, Pink = 0xFFFFu }; int main(void) { try { numeric_cast<Toad>( Frog::Pink ); } catch(std::exception const &e) { cout << e.what() << endl; } std::uint32_t my_32_bit_var = 0xffffffffU; try { numeric_cast<std::uint16_t>(my_32_bit_var); } catch(std::exception const &e) { cout << e.what() << endl; } try { numeric_cast<std::uint8_t>( Frog::Pink ); } catch(std::exception const &e) { cout << e.what() << endl; } try { numeric_cast<Toad>(0x1FFu); } catch(std::exception const &e) { cout << e.what() << endl; } } In order to achieve this behaviour, I've created my own "numeric_cast" in the global namespace as follows: #include <type_traits> // is_enum, underlying_type #include <boost/numeric/conversion/cast.hpp> // numeric_cast template<bool T_is_an_enum, typename T> struct numeric_cast_helper { typedef T type; }; template<typename T> struct numeric_cast_helper<true, T> { typedef typename std::underlying_type<T>::type type; }; template<typename A, typename B> A numeric_cast(B const b) // This function takes its argument by value, and also returns by value -- which is fine for arithmetic types { return static_cast<A>( boost::numeric_cast<typename numeric_cast_helper<std::is_enum<A>::value, A>::type> ( static_cast<typename numeric_cast_helper<std::is_enum<B>::value, B>::type>(b) ) ); }

1 0

Fwd: Boost Digest, Vol 6656, Issue 1
by Sal Pamukcu 11 Mar '22

11 Mar '22

---------- Forwarded message --------- From: <boost-request(a)lists.boost.org> Date: Fri, Mar 11, 2022 at 3:00 PM Subject: Boost Digest, Vol 6656, Issue 1 To: <boost(a)lists.boost.org> Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: [Graph] Attempt to resolve open issue (Anne van de Graaf) 2. Master branch now closed for 1.79.0 beta release (Marshall Clow) 3. [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available (Marshall Clow) 4. Re: [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available (Marshall Clow) 5. Re: [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available (Andrey Semashev) 6. Re: [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available (Marshall Clow) 7. Re: [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available (Andrey Semashev) 8. Re: [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available (Tom Kent) 9. Re: [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available (Matt Borland) 10. Re: [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available (Andrey Semashev) ---------- Forwarded message ---------- From: Anne van de Graaf <A.vandeGraaf(a)dianafea.com> To: Jeremy Murphy <jeremy.william.murphy(a)gmail.com> Cc: "boost(a)lists.boost.org" <boost(a)lists.boost.org>, John Maddock < jz.maddock(a)googlemail.com> Bcc: Date: Thu, 10 Mar 2022 13:17:37 +0000 Subject: Re: [boost] [Graph] Attempt to resolve open issue > This is fixed on the develop branch, btw, have you verified that it works as expected now? Apologies for my late reply. Yes, I have verified that the fix on the develop branch works as expected. Thank you very much for the work that you have done. Best regards, Anne On Fri, 10 Dec 2021 at 18:56, Anne van de Graaf <A.vandeGraaf(a)dianafea.com <mailto:A.vandeGraaf@dianafea.com>> wrote: > Hi Anne, > which issue or pull request # is it? Hi Jeremy, It is issue # 268: https://github.com/boostorg/graph/issues/268 Best regards, Anne > Jeremy On Sun, 5 Dec 2021 at 02:20, Anne van de Graaf via Boost < boost(a)lists.boost.org<mailto:boost@lists.boost.org>> wrote: > Hello all, > > I am trying to get an open issue in Boost.Graph resolved. Since I haven't received any response at the corresponding GitHub page nor from the Boost Users mailing list (where I posted the below message last Monday), I am reaching out to you. My aim is to get in touch with the maintainer(s) of Boost.Graph in order to discuss what is the preferred/most efficient way to fix the issue. Since this is my first post to this mailing list, please accept my apologies if you feel this is not the right way to get in touch with the maintainers. In that case, I would appreciate it very much if you could kindly explain what I should have done instead. Please find below a copy of my message that I sent last Monday to the Boost Users mailing list. Thank you very much for your attention and any replies. > Unfortunately, Graph has no current maintainer. I have done some > maintenance on that library in the past, and I know Jeremy Murphy will > be trying to do some this next week, so hopefully one of us can get that > one fixed! Thanks a lot for your reply, John. I didn't know that Boost.Graph doesn't have a current maintainer. It would be great if you or Jeremy could do some maintenance on it. Feel free to contact me if I can help you in any way to get things done. We could then discuss in what way I can contribute. Thanks. Kind regards, Anne > Best, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ---------- Forwarded message ---------- From: Marshall Clow <mclow.lists(a)gmail.com> To: Boost Developers List <boost(a)lists.boost.org> Cc: Bcc: Date: Thu, 10 Mar 2022 06:31:06 -0800 Subject: [boost] Master branch now closed for 1.79.0 beta release Please do not make any commits to the master branch. — Marshall ---------- Forwarded message ---------- From: Marshall Clow <mclow.lists(a)gmail.com> To: Boost Developers List <boost(a)lists.boost.org> Cc: Bcc: Date: Thu, 10 Mar 2022 07:27:19 -0800 Subject: [boost] [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available are now available at: <https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source < https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source>> The SHA256 checksums are as follows: 8985105623f48d55be01076d98ca4e7a8cb548a8d7f9ad0e1fc3c710d2c75fcf boost_1_79_0_b1_rc1.tar.bz2 4b58e4d3b6ff1176b3c6cb9eec496c1f6d2535270e97ec140da533d68766ca39 boost_1_79_0_b1_rc1.tar.gz 768875ad5c77763445e8b119072cfa1e64854b071a353dd44c3c73ff46df910b boost_1_79_0_b1_rc1.zip 4d05b458cd039afe86003cf7e1e6c3a358b5b2d031892e620eedc344ab200246 boost_1_79_0_b1_rc1.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers It fails on Window 11 using GCC-11.2 command line ; b2 cxxstd=20 toolset=gcc --build-type=complete stage here is the error message ; FailBoost1.79.0 Beta 1 Release Candidate 1 (github.com) <https://gist.github.com/salimp2009/854b3c74295b2487c4585be35f8bfbd0> Salim (a new bee in devel :) ---------- Forwarded message ---------- From: Marshall Clow <mclow.lists(a)gmail.com> To: Boost Developers List <boost(a)lists.boost.org> Cc: Bcc: Date: Thu, 10 Mar 2022 08:03:12 -0800 Subject: Re: [boost] [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available On Mar 10, 2022, at 7:27 AM, Marshall Clow <mclow.lists(a)gmail.com> wrote: > > are now available at: > <https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source < https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source>> > > The SHA256 checksums are as follows: > > 8985105623f48d55be01076d98ca4e7a8cb548a8d7f9ad0e1fc3c710d2c75fcf boost_1_79_0_b1_rc1.tar.bz2 > 4b58e4d3b6ff1176b3c6cb9eec496c1f6d2535270e97ec140da533d68766ca39 boost_1_79_0_b1_rc1.tar.gz > 768875ad5c77763445e8b119072cfa1e64854b071a353dd44c3c73ff46df910b boost_1_79_0_b1_rc1.zip > 4d05b458cd039afe86003cf7e1e6c3a358b5b2d031892e620eedc344ab200246 boost_1_79_0_b1_rc1.7z > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. I have successfully built the libraries: * On Mac OS 10.15, using Apple clang version 11.0.3, and and c++03/11/14/17/2a — Marshall ---------- Forwarded message ---------- From: Andrey Semashev <andrey.semashev(a)gmail.com> To: boost(a)lists.boost.org Cc: Bcc: Date: Thu, 10 Mar 2022 20:17:42 +0300 Subject: Re: [boost] [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available On 3/10/22 18:27, Marshall Clow via Boost wrote: > are now available at: > <https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source < https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source>> > > The SHA256 checksums are as follows: > > 8985105623f48d55be01076d98ca4e7a8cb548a8d7f9ad0e1fc3c710d2c75fcf boost_1_79_0_b1_rc1.tar.bz2 > 4b58e4d3b6ff1176b3c6cb9eec496c1f6d2535270e97ec140da533d68766ca39 boost_1_79_0_b1_rc1.tar.gz > 768875ad5c77763445e8b119072cfa1e64854b071a353dd44c3c73ff46df910b boost_1_79_0_b1_rc1.zip > 4d05b458cd039afe86003cf7e1e6c3a358b5b2d031892e620eedc344ab200246 boost_1_79_0_b1_rc1.7z > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. I'm trying to download the source package now, and the download speed is terrible, ~30-60 KB/s. Is this expected? ---------- Forwarded message ---------- From: Marshall Clow <mclow.lists(a)gmail.com> To: boost(a)lists.boost.org Cc: Bcc: Date: Thu, 10 Mar 2022 09:53:08 -0800 Subject: Re: [boost] [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available On Mar 10, 2022, at 9:17 AM, Andrey Semashev via Boost < boost(a)lists.boost.org> wrote: > > On 3/10/22 18:27, Marshall Clow via Boost wrote: >> are now available at: >> <https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source < https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source>> >> >> The SHA256 checksums are as follows: >> >> 8985105623f48d55be01076d98ca4e7a8cb548a8d7f9ad0e1fc3c710d2c75fcf boost_1_79_0_b1_rc1.tar.bz2 >> 4b58e4d3b6ff1176b3c6cb9eec496c1f6d2535270e97ec140da533d68766ca39 boost_1_79_0_b1_rc1.tar.gz >> 768875ad5c77763445e8b119072cfa1e64854b071a353dd44c3c73ff46df910b boost_1_79_0_b1_rc1.zip >> 4d05b458cd039afe86003cf7e1e6c3a358b5b2d031892e620eedc344ab200246 boost_1_79_0_b1_rc1.7z >> >> As always, the release managers would appreciate it if you download the >> candidate of your choice and give building it a try. Please report both >> success and failure, and anything else that is noteworthy. > > I'm trying to download the source package now, and the download speed is > terrible, ~30-60 KB/s. Is this expected? That’s not what I’m seeing. I’m getting > 1 MB/sec — Marshall ---------- Forwarded message ---------- From: Andrey Semashev <andrey.semashev(a)gmail.com> To: boost(a)lists.boost.org Cc: Bcc: Date: Thu, 10 Mar 2022 21:25:53 +0300 Subject: Re: [boost] [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available On 3/10/22 20:53, Marshall Clow via Boost wrote: > On Mar 10, 2022, at 9:17 AM, Andrey Semashev via Boost < boost(a)lists.boost.org> wrote: >> >> On 3/10/22 18:27, Marshall Clow via Boost wrote: >>> are now available at: >>> <https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source < https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source>> >>> >>> The SHA256 checksums are as follows: >>> >>> 8985105623f48d55be01076d98ca4e7a8cb548a8d7f9ad0e1fc3c710d2c75fcf boost_1_79_0_b1_rc1.tar.bz2 >>> 4b58e4d3b6ff1176b3c6cb9eec496c1f6d2535270e97ec140da533d68766ca39 boost_1_79_0_b1_rc1.tar.gz >>> 768875ad5c77763445e8b119072cfa1e64854b071a353dd44c3c73ff46df910b boost_1_79_0_b1_rc1.zip >>> 4d05b458cd039afe86003cf7e1e6c3a358b5b2d031892e620eedc344ab200246 boost_1_79_0_b1_rc1.7z >>> >>> As always, the release managers would appreciate it if you download the >>> candidate of your choice and give building it a try. Please report both >>> success and failure, and anything else that is noteworthy. >> >> I'm trying to download the source package now, and the download speed is >> terrible, ~30-60 KB/s. Is this expected? > > That’s not what I’m seeing. > I’m getting > 1 MB/sec Possibly, some regional restrictions on JFrog side? I'm not seeing bandwidth issues on other sites, including GitHub, which I assume is US based. BTW, building with gcc 11.2 in C++17 mode on Kubuntu 21.10 succeeds. There are quite a few warnings about auto_ptr being deprecated, and also some suspicious warnings about freeing non-heap-allocated objects in Boost.Wave: https://github.com/boostorg/wave/issues/159 ---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> To: Boost Developers List <boost(a)lists.boost.org> Cc: Bcc: Date: Thu, 10 Mar 2022 15:33:30 -0600 Subject: Re: [boost] [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available On Thu, Mar 10, 2022 at 9:27 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > are now available at: > <https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source < > https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source>> > > The SHA256 checksums are as follows: > > 8985105623f48d55be01076d98ca4e7a8cb548a8d7f9ad0e1fc3c710d2c75fcf > boost_1_79_0_b1_rc1.tar.bz2 > 4b58e4d3b6ff1176b3c6cb9eec496c1f6d2535270e97ec140da533d68766ca39 > boost_1_79_0_b1_rc1.tar.gz > 768875ad5c77763445e8b119072cfa1e64854b071a353dd44c3c73ff46df910b > boost_1_79_0_b1_rc1.zip > 4d05b458cd039afe86003cf7e1e6c3a358b5b2d031892e620eedc344ab200246 > boost_1_79_0_b1_rc1.7z > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release Managers > Looks good on Windows/Visual Studio. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X msvc-14.3 32 X X X msvc-14.3 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full build logs can be found here: https://gist.github.com/teeks99/acf919a716deeb001acaa2b4f12cb757 Tom ---------- Forwarded message ---------- From: Matt Borland <matt(a)mattborland.com> To: boost(a)lists.boost.org Cc: Bcc: Date: Fri, 11 Mar 2022 10:57:15 +0000 Subject: Re: [boost] [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available > As always, the release managers would appreciate it if you download the > > candidate of your choice and give building it a try. Please report both > > success and failure, and anything else that is noteworthy. > > -- The Release Managers > > _______________________________________________ Boost.Filesystem fails to build using Apple Clang 13 with C++11/14/17/20 on M1 Pro Architecture. An issue has been opened here ( https://github.com/boostorg/filesystem/issues/231) Matt ---------- Forwarded message ---------- From: Andrey Semashev <andrey.semashev(a)gmail.com> To: boost(a)lists.boost.org Cc: Bcc: Date: Fri, 11 Mar 2022 14:09:22 +0300 Subject: Re: [boost] [release] Boost 1.79.0 Beta 1 Release Candidate 1 is available On 3/11/22 13:57, Matt Borland via Boost wrote: >> As always, the release managers would appreciate it if you download the >> >> candidate of your choice and give building it a try. Please report both >> >> success and failure, and anything else that is noteworthy. >> >> -- The Release Managers >> >> _______________________________________________ > > Boost.Filesystem fails to build using Apple Clang 13 with C++11/14/17/20 on M1 Pro Architecture. An issue has been opened here ( https://github.com/boostorg/filesystem/issues/231) As replied in the issue, your build is picking up headers from a different Boost version in /usr/local/include. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Salim Pamukcu

1 0

[release] Boost 1.79.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 11 Mar '22

11 Mar '22

are now available at: <https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source <https://boostorg.jfrog.io/ui/native/main/beta/1.79.0.beta1/source>> The SHA256 checksums are as follows: 8985105623f48d55be01076d98ca4e7a8cb548a8d7f9ad0e1fc3c710d2c75fcf boost_1_79_0_b1_rc1.tar.bz2 4b58e4d3b6ff1176b3c6cb9eec496c1f6d2535270e97ec140da533d68766ca39 boost_1_79_0_b1_rc1.tar.gz 768875ad5c77763445e8b119072cfa1e64854b071a353dd44c3c73ff46df910b boost_1_79_0_b1_rc1.zip 4d05b458cd039afe86003cf7e1e6c3a358b5b2d031892e620eedc344ab200246 boost_1_79_0_b1_rc1.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers

4 8

Master branch now closed for 1.79.0 beta release
by Marshall Clow 10 Mar '22

10 Mar '22

Please do not make any commits to the master branch. — Marshall

1 0

[Graph] Attempt to resolve open issue
by Anne van de Graaf 10 Mar '22

10 Mar '22

Hello all, I am trying to get an open issue in Boost.Graph resolved. Since I haven't received any response at the corresponding GitHub page nor from the Boost Users mailing list (where I posted the below message last Monday), I am reaching out to you. My aim is to get in touch with the maintainer(s) of Boost.Graph in order to discuss what is the preferred/most efficient way to fix the issue. Since this is my first post to this mailing list, please accept my apologies if you feel this is not the right way to get in touch with the maintainers. In that case, I would appreciate it very much if you could kindly explain what I should have done instead. Please find below a copy of my message that I sent last Monday to the Boost Users mailing list. Thank you very much for your attention and any replies. Original message: When I remove a vertex from a graph, I occasionally experience a crash (on a system running Red Hat Enterprise Linux 8.5). I have been able to replicate the behavior with the following test program: #include <vector> #include <boost/graph/adjacency_list.hpp> int main() { using MyGraph = boost::adjacency_list<boost::setS, boost::vecS, boost::undirectedS>; using MyVertexDescriptor = boost::graph_traits<MyGraph>::vertex_descriptor; using MyVertexDescriptorVec = std::vector<MyVertexDescriptor>; MyGraph g; MyVertexDescriptorVec vertices{ boost::add_vertex( g ), boost::add_vertex( g ), boost::add_vertex( g ) }; boost::add_edge( vertices[0], vertices[1], g ); boost::add_edge( vertices[1], vertices[2], g ); boost::clear_vertex( vertices[0], g ); boost::remove_vertex( vertices[0], g ); return 0; } Also on a Windows platform, I observe similar behavior. When I build the above code with Microsoft Visual Studio 2019 (MSVC 14.27.29110) and run it with a debugger, a debug assertion is triggered ("cannot increment value-initialized map/set iterator"). In both cases (on Linux and Windows platforms), the debugger reveals that the problem is at line 2071 of boost/graph/detail/adjacency_list.hpp. For clarity, I have copied the involved template function below: template < class EdgeList, class vertex_descriptor > inline void reindex_edge_list( EdgeList& el, vertex_descriptor u, boost::disallow_parallel_edge_tag) { for (typename EdgeList::iterator ei = el.begin(); ei != el.end(); ++ei) // line 2071: increment operator fails { if (ei->get_target() > u) { typename EdgeList::value_type ce = *ei; el.erase(ce); --ce.get_target(); el.insert(ce); } } } While I was searching for a proper place to post my question, I found the following issue at GitHub (which was opened on July 1 of this year): https://github.com/boostorg/graph/issues/268. This appears to be the exact same issue. So last week, I added a comment saying that I am facing the exact same problem. Unfortunately, so far no one has responded yet. To me, it seems that the problem is well-understood. Also, some have proposed a bug fix to resolve the issue (including a pull request). Nevertheless, no progress has been made over the past months. So I was just wondering what is the best way to proceed if we want to fix the issue in Boost itself? Is there anything that I can do (apart from starting this thread) to help in resolving the issue? Any feedback is greatly appreciated. Kind regards, Anne van de Graaf

3 6

Windows Build Issue for Boost Wave
by Tom Kent 09 Mar '22

09 Mar '22

In preparation for the lockdown today, I did a dry run of the windows build based on the latest snapshot. During this build I encountered errors with wave on the msvc-12.0 compiler (both 32 & 64 bit). Roughly the following is repeated several times during the build: compile-c-c++ D:\RB\bin.v2\boost\bin.v2\libs\wave\build\msvc-12.0\debug\address-model-32\threading-multi\token_ids.obj token_ids.cpp D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(335) : error C2146: syntax error : missing ';' before identifier 'token_id' D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(335) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(341) : error C2146: syntax error : missing ';' before identifier 'token_id' D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(341) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(341) : error C2086: 'int boost::wave::constexpr' : redefinition D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(335) : see declaration of 'boost::wave::constexpr' D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(347) : error C2144: syntax error : 'bool' should be preceded by ';' D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(347) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(347) : error C2086: 'int boost::wave::constexpr' : redefinition D:\RB\boost_1_79_0\boost/wave/token_ids.hpp(335) : see declaration of 'boost::wave::constexpr' call "D:\RB\bin.v2\boost\bin.v2\standalone\msvc\msvc-12.0\address-model-32\architecture-x86\msvc-setup.bat" x86 >nul cl /Zm800 -nologo "libs\wave\src\token_ids.cpp" -c -Fo"D:\RB\bin.v2\boost\bin.v2\libs\wave\build\msvc-12.0\debug\address-model-32\threading-multi\token_ids.obj" -TP /wd4675 /EHs /GR /Z7 /Od /Ob0 /W3 /MDd /Zc:forScope /Zc:wchar_t /Zc:inline -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE "-I." ...failed compile-c-c++ D:\RB\bin.v2\boost\bin.v2\libs\wave\build\msvc-12.0\debug\address-model-32\threading-multi\token_ids.obj... Hope this helps, if not fixed it will be blocking the beta rc when it gets rolled. Tom

1 0

Boost 1.79.0 closed for breaking changes and new libraries today
by Glen Fernandes 02 Mar '22

02 Mar '22

We are closed for new libraries and breaking changes today. We will close for all major changes this Friday (2022-03-04). And will close for the beta the following Wednesday (2022-03-09). The Release Managers

1 0

std::numeric_limits<__float128>::signaling_NaN + __float128-Type
by Gero Peterhoff 26 Feb '22

26 Feb '22

Hello, please see https://godbolt.org/z/Ksshxvhaj 1) std::numeric_limits<__float128>::signaling_NaN always returns 0 but gcc-__builtin_nansq doesn't. I think __builtin_nansq is correct as it is also distinct from std::numeric_limits<__float128>::quiet_NaN (__builtin_nanq). 2) The types __float128, __extension__ __float128 (gcc) and _Quad (intel) are identical, but there are different definitions in boost/config/detail/suffix.hpp and boost/math/cstdfloat/cstdfloat_types.hpp. I think it would make sense to have just one definition or is there a reason why it was done that way? If yes, which one is it? You could always use __float128 directly and/or adjust boost/config/detail/suffix.hpp so that it also works with clang/intel. Which way would be better? I would like to help consolidate this but without having to deal with different typedef's or long #define's. thx Gero

3 13

Boost.URL Proposal
by Alan de Freitas 21 Feb '22

21 Feb '22

Hi! My name is Alan Freitas. Vinnie Falco and I are looking for a review manager for the library that we hope will become Boost.URL. I've taken over the project and in addition to introducing myself I would like to update you guys as to where we are on this in terms of progress: - Path segments can be represented as views of the underlying path - Query parameters can be represented as views of the underlying query - Percent-decoding methods return lazy constant strings with small buffer optimization and shared ownership - The library implements the specification as in RFC3986 <https://datatracker.ietf.org/doc/html/rfc3986> + its errata <https://www.rfc-editor.org/errata/rfc3986> - Non-ASCII characters are not considered valid URLs - Other specifications such as RFC3492 <https://datatracker.ietf.org/doc/html/rfc3492>, WhatWG <https://url.spec.whatwg.org/>, or any other form of relaxed parsing are out of the scope of the library Both Vinnie and I are available to answer questions about the library on the list, on the GitHub repository page <https://github.com/CPPAlliance/url>, via email <alandefreitas(a)gmail.com>, or on Slack (in #boost-url). -- Alan Freitas https://github.com/alandefreitas

5 7

Understanding the code base.
by Rahul Sharma 21 Feb '22

21 Feb '22

So far I have been reading multiple documentations and reading the projects from past year GSoC and exploring some modules given on the GitHub and I came to understand now that in order to contribute to this organization the knowledge of only C++ and data structures is not enough. I have some questions which are halting my progress so far, it would be very generous of you if someone could address these issues I am facing…… 1. I am unable to understand the code base in the repositories on GitHub. 2. In order to contribute or to understand things in a better way do I need to learn how Boost libraries work. 3. What are some packages I need to install. It would be very kind of you if you could provide some useful resources for the same and also for the things you think could be of use to understand things clearly and for making some PRs. When I read the code base of some repositories and some documentations I got excited as I think there are many things and skills I need to learn, the skills, it takes to be a decent developer. Sent from [1]Mail for Windows References 1. https://go.microsoft.com/fwlink/?LinkId=550986

2 1

[PATCH] futex: fix build on 32-bit architectures using 64-bit time_t
by Khem Raj 21 Feb '22

21 Feb '22

Fix the following build failure on 32-bit architectures using 64-bit time_t (e.g. riscv32): | ./boost/fiber/detail/futex.hpp:31:23: error: use of undeclared identifier 'SYS_futex' | return ::syscall( SYS_futex, addr, op, x, nullptr, nullptr, 0); | ^ | 1 error generated. Signed-off-by: Khem Raj <raj.khem(a)gmail.com> --- boost/fiber/detail/futex.hpp | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/boost/fiber/detail/futex.hpp b/boost/fiber/detail/futex.hpp index e64bd5990..d0353e9e5 100644 --- a/boost/fiber/detail/futex.hpp +++ b/boost/fiber/detail/futex.hpp @@ -12,6 +12,10 @@ #include <boost/fiber/detail/config.hpp> +#ifndef SYS_futex +#define SYS_futex SYS_futex_time64 +#endif + #if BOOST_OS_LINUX extern "C" { #include <linux/futex.h> -- 2.35.1

1 0

unordered_map implementation
by Peter Dimov 19 Feb '22

19 Feb '22

I've been helping Christian Mazakas maintain Unordered, and we've been looking into trying to improve its performance on the synthetic benchmarks we have for it (https://github.com/boostorg/unordered/tree/develop/benchmark) One of the things that are hurting us is that we need to do a double indirection in order to find an element, because Unordered uses a singly-linked list for all its nodes, with the bucket array pointing at the element before the first one (in order to be able to support erasing.) There's also the option of using a doubly-linked list, which however increases the memory footprint. I'm looking at the iterator invalidation rules for std::unordered_map, and iterators are invalidated on every rehash. This makes me wonder why is it necessary to have all the elements in a single list, as every implementation seems to do. It seems to me that it's possible to just have singly- linked lists for each bucket, and then have a "fat" iterator that contains the bucket index and the pointer to the element. On increment, when the end of the bucket list is reached, the iterator can just go to the next non-empty bucket. Is there something I'm missing in the requirements that renders this implementation non-conforming?

2 2

std::launder and its usage in Boost
by Mikhail Kremniov 18 Feb '22

18 Feb '22

Hi, Initially, I posted this question to the boost-users list, but then I was advised to repost it here. I wonder, what is the Boost community's opinion of std::launder? In particular, of its necessity when accessing an object that was created via placement-new in an aligned_storage. As I can see, it's used by Boost.Beast in its implementation of the variant type, but not in other parts of Boost. The reason I'm asking this is that I'm working on a C++14 code-base that uses Boost.Variant and Boost.Optional extensively (as well as other parts of Boost that use Variant and Optional internally). Now we're trying to switch to C++17 at least, and I worry whether it could potentially break things. To put things into context, C++ standard states in the [basic.life] section that if you had an object and then created a new one in the same location, you can use the pointer to the old object to refer to the new one only if (among other things) "the new object is of the same type as the original object (ignoring the top-level cv-qualifiers)". This means, as I understand it, that it's technically illegal to reinterpret_cast the pointer to aligned_storage to the pointer to the actual type of the object created via placement-new, because placement-new has already ended the lifetime of the aligned_storage object. So, implementations of Boost.Optional and Boost.Variant are illegal then (?). But it's been like that since C++03 and Boost worked fine all that time, so it looks like this UB existed only "on paper". But C++17 then added "Note: If these conditions are not met, a pointer to the new object can be obtained from a pointer that represents the address of its storage by calling std::launder". So now the language has the ability to deal with that UB, and a question arises, is it possible that compilers could start to use the UB to perform additional optimizations and make it a real UB? Also, I've seen a couple of times on stackoverflow.com people saying that it's actually fine to reinterpret_cast the storage in C++14, but in C++17 it's not (they didn't explain why though). So, can switching from -std=c++14 to -std=c++17 be a breaking change when using Boost? The fact that Boost.Variant and Boost.Optional don't use std::launder - is it an oversight or a conscious decision? Regards, Mikhail.

5 18

Diagnostic improvements in 1.78/1.79
by Peter Dimov 15 Feb '22

15 Feb '22

This is a quick summary of some 1.78 and 1.79 changes in Assert, ThrowException, and System related to error reporting. In Boost 1.73, Assert acquired a new component, boost::source_location. This is a class encapsulating a source location (a collection of source file name, line number, column, and function name) that is modeled after C++20's std::source_location, except of course it doesn't require C++20. In 1.79, the macro that creates the current source location, BOOST_CURRENT_LOCATION, is now usable in a function default argument, similarly to std::source_location::current(). This enables functions to be declared like this: T& my_vector::at( size_t i, boost::source_location const& loc = BOOST_CURRENT_LOCATION ) { if( i >= size() ) { boost::throw_exception( std::out_of_range( "at" ), loc ); } return data_[ i ]; } Since functions such as `at` are called from many places in the program, it's more useful for the source location in the thrown exception to point at the call site, rather than inside of `at` (which doesn't provide much information.) See for example https://godbolt.org/z/6o9e187a1. Note that the location returned by diagnostic_information(x) points to line 35, which is the call to `v.at(5);` inside `main`. Recommendation one: add source_location default arguments to your throwing functions so that the information logged at the catch site points to the call that threw. In case you find boost::throw_exception too heavyweight, as it adds a boost::exception base class and support for boost::exception_ptr, and this would prevent you from applying the technique above, there is now an alternative function, boost::throw_with_location, in <boost/throw_exception.hpp>. It doesn't integrate with Boost.Exception or boost::exception_ptr, but does add a source location to the exception that can later be retrieved with boost::get_throw_location(x). The above example using boost::throw_with_location can be seen at https://godbolt.org/z/Pcj1xad3v. In 1.78, boost::system::error_code had also acquired support for source locations, although it's not as automatic as the above technique where the default argument automatically adds a location without the user needing to do anything. Since there's no space in error_code for the entire boost::source_location struct, it can only store a pointer to it. This requires the following incantation BOOST_STATIC_CONSTEXPR boost::source_location loc = BOOST_CURRENT_LOCATION; ec.assign( ENOENT, boost::system::generic_category(), &loc ); which can be wrapped in a macro. See the documentation of Boost.System: https://www.boost.org/doc/libs/1_78_0/libs/system/doc/html/system.html#usag… Unlike the case with exceptions, when working with error codes, the situation is reversed and we want to store the source location immediately after discovering the error, rather than the one of the user call that failed. That's both because this location gives the most information as to the source of the error (ENOENT on its own doesn't say much), and because error codes are generally checked close to the user call, so the call location isn't as useful. Recommendation two: add source locations to your error_codes if using Boost.System. Finally, when providing dual APIs, that is, APIs that can signal an error using both error_code or by throwing an exception, you can combine the above two approaches and store both the "deep" source location in the error_code and the "shallow" (user call) location in the system_error exception. I hope you find those useful. Further reading: https://www.boost.org/doc/libs/develop/libs/assert/doc/html/assert.html#sou… https://www.boost.org/doc/libs/develop/libs/throw_exception/doc/html/throw_… https://www.boost.org/doc/libs/develop/libs/system/doc/html/system.html

6 33

Proposed BoostBook fix for invalid <h7> and <h8> elements
by Evan Lenz 14 Feb '22

14 Feb '22

Hello, The DocBook stylesheets used by BoostBook occasionally will output invalid heading elements (<h7> or <h8>). Some (but not all!) areas of the stylesheets properly cap the output to <h6>. In particular, the rule for <bridgehead> fails to do this. The consequences are described in this BoostBook issue: https://github.com/boostorg/boostbook/issues/12 And (originally) in this issue in the docca tool, which depends on BoostBook: https://github.com/boostorg/docca/issues/79 I have created a pull request that fixes the DocBook issue by overriding the bridgehead rule. Although the ideal fix would be in the DocBook stylesheets themselves, these stylesheets are no longer being regularly updated. Also, my proposed fix conforms to the pattern of other BoostBook-specific stylesheet overrides. Is there someone familiar with BoostBook who would be willing to review my pull request (and raise any questions or concerns as desired)? https://github.com/boostorg/boostbook/pull/13 Thanks very much for your time! Evan Lenz

3 3

Building Boost, eventually
by Alain O' Miniussi 09 Feb '22

09 Feb '22

Hi, I finally got some time time to work on a Boost library and I am, as usual, fighting with bjam. === 14:58:08 [alainm@pollux boost]# ./bootstrap.sh --with-toolset=intel-linux Building B2 engine.. ... icpx (ICX) 2021.1 Beta 20200304 # why not icpc ? ... > icpx -x c++ -std=c++11 -O3 -s -static -DNDEBUG .... -o b2 ld: cannot find -lstdc++ ld: cannot find -lstdc++ === The problem here is the -static option, as libstdc++ is not available as an archive on linux (not on the ones I use). I submitted a fix, with no effect: https://github.com/bfgroup/b2/pull/133/files Also apparently some good soul (thank you!) started working on a CMake alternative that just work (checked twice). Its only issue is that the tests don't seems to have moved to CMake. So my question is: 1) Am I better off trying to port the testing of Boost.MPI to CMake and just forget about bjam or, 2) Try to invoke some demonic entity to get bjam working with intel-linux. What is the recommended build method recommended for libraries developers at this point ? Best regards ---- Alain Miniussi DSI, Pôles Calcul et Genie Log. Observatoire de la Côte d'Azur Tél. : +33492003009 (Mont-Gros) +33483618544 (Sophia Antipolis) +33609650665

3 4

boost::throw_exception potential changes
by Peter Dimov 07 Feb '22

07 Feb '22

Currently, `boost::throw_exception(x)` automatically throws an exception derived from `x` that (1) injects a boost::exception base class if there's none, and (2) injects a base class that enables boost::exception_ptr support (boost::current_exception and boost::rethrow_exception.) This is convenient, but the downside is the amount of generated code, e.g. https://godbolt.org/z/5T8T8GEqP (422 lines) compared to https://godbolt.org/z/1zr1odf7n (36 lines.) This is not the end of the world as this code is only generated once per exception type, not on every call to throw_exception, but it's still unpleasant to see. It so happens that boost::exception_ptr has recently acquired the ability to work under C++11 without the need for the supporting base class, by using the standard std::exception_ptr infrastructure. So if we also remove the automatic injection of boost::exception as a base class, and ask users to derive their exceptions from it if they desire having it as a base, it's possible to simplify boost::throw_exception considerably. The normal call now can be almost the same as the naked throw, https://godbolt.org/z/WssWzfrfW (47 lines.) And if BOOST_THROW_EXCEPTION is used, which still adds the source location (file/line/function) to the exception, the result is 97 lines. (https://godbolt.org/z/nETnqrsx8) However, there is a downside. Due to the way std::exception_ptr works under GCC/Clang (and all compilers using the same ABI), the exception is never copied, not when it's captured with std::current_exception (and consequently boost::current_exception), nor when it's rethrown with boost/std::rethrow_exception. This causes problems if an exception is captured, rethrown, caught and modified, then rethrown again using the same exception_ptr. The second rethrow throws the modified exception. This problem can be seen in https://godbolt.org/z/K9eh71ovP. So... what do we do? Should I go ahead with these changes to throw_exception (having a macro to revert to the old behavior, of course)? Or is that too much of a break? We can of course offer the same functionality as part of Boost.Exception, like boost::exception::raise, or similar, but would that be enough to offset the inconvenience?

4 11

[concept_check][ublas] Fixing deprecated copy warnings
by Antony Polukhin 07 Feb '22

07 Feb '22

Hi, There are two PR that fix deprecated copy warnings for GCC and Clang: * https://github.com/boostorg/concept_check/pull/35 * https://github.com/boostorg/ublas/pull/153 Please review those. They make the intent explicit and the code becomes more portable. Trivial sample that causes the warning https://godbolt.org/z/YaPvGfedv -- Best regards, Antony Polukhin

1 0

Primary test compilers in Boost release notes
by Peter Dimov 01 Feb '22

01 Feb '22

We have an issue, https://github.com/boostorg/boost/issues/610, that points out that the "Primary test compilers" section in the Boost 1.78 release notes is misleading, because it doesn't actually reflect whether a Boost library works with a specific compiler or not. The specific example cited is Multiprecision. The release notes say that on Linux, the following C++11 GCC compilers are "primary": GCC, C++11: 4.7.3, 4.8.5, 11 However, Multiprecision doesn't work with GCC 4.7.3 or 4.8.5, and likely never will, because these compilers do not actually implement the C++11 standard. (They don't implement reference qualified member functions and don't have a conforming <type_traits> header.) It would be better for everyone involved if the primary test compilers are somewhat aligned with (a) what Boost libraries actually support or require, and (b) what Boost libraries actually test with. The section historically lists what's in our test matrix, but nowadays most libraries depend on CI for testing, specifically on Github Actions (after the untimely death of open source Travis) and Appveyor. There's a fair bit of discussion in the linked issue above, but what I think is reasonable to list as primary test compilers as far as GCC is concerned is something like C++03: 4.8, 4.9, 5 C++11: 4.8(*), 4.9(*), 5 I would start with 4.8, because this is what GHA has on its 18.04 image. C++03 needs to have GCC up to 5 because this is the default -std level for these versions (GCC 6 is -std=c++14 by default), and the system- provided Boost is compiled with the default. 4.8 has enough of C++11 so it's possible for C++11 libraries to support it without much heroics, but we could go either way on this one, hence the asterisk.

2 1

[GSoC 2022] [Graph] Potential mentors
by Dev Jain 15 Jan '22

15 Jan '22

Hello everyone. I am Dev Jain, a sophomore student pursuing a Bachelors in Computer Science and Engineering from IIT Jammu. I am passionate about discrete mathematics, and in particular graph theory and graph algorithms. I would like to contribute to the Boost Graph Library. I can't find any project ideas for the BGL in recent years of GSoC. Are there any people active with BGL, and any prospective mentors? I understand that, it is recommended to come to the mailing list asking for mentors by describing an idea, but I wanted to ask this since for many years a BGL project hasn't been proposed in the ideas list. Thanks.

1 0

Does anybody know why boost::array does not support multiple dimensions?
by Ivan Matek 10 Jan '22

10 Jan '22

I don't know much about library development, but with variadic templates does not seem so hard, although every library development is much harder than regular user code. Sure boost::array probably wants to support ancient compilers, but variadic version could exist only for "modern"(I do not consider >10y old standards modern) C++. I found this std:: proposal http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3794.html#Ch05 from 9 y ago, also author seemed to have some working impl on github https://github.com/CTMacUser/ArrayMD/tree/master/include/boost/container But I guess none of it ever progressed. Does anybody knows more about this? It is not trivial since there are probably a ton of edge cases, typdefs, semantics(what should size return?, I would say array of dims) to deal with, but I think it would be a nice extension since I find nested std::array hideous (with current syntax), e.g.: std::array<std::array<int,3>, 4> arr; I would like to have this boost::array<int,4,3> arr; P.S. I know I can use Eigen or some other library, but I think if not std then at least boost should support simple way to have multidim arrays.

10 35

Error with geometry buffer?
by KL 10 Jan '22

10 Jan '22

Hi, Boost Geometry 1.78, linux Â I was getting bad results with my calculations so I decided to narrow down the implementation up to the point I got the following problematic code: Â typedef boost::geometry::model::point <double, 2, boost::geometry::cs::cartesian> Vector2d; Â int main (){ Â Â Â Â Â Â Â Â multi_polygon <polygon <Vector2d> > mp; Â Â Â Â Â Â Â Â /*{ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â polygon <Vector2d> poly; Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â poly.outer().push_back( {0, 0} ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â poly.outer().push_back( {0, 4} ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â poly.outer().push_back( {4, 4} ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â poly.outer().push_back( {4, 0} ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â correct( poly ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â mp.push_back(poly); Â Â Â Â Â Â Â }*/ Â Â Â Â Â Â Â { Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â polygon <Vector2d> poly; Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â poly.outer().push_back( {10, -1} ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â poly.outer().push_back( {14, -1} ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â poly.outer().push_back( {10, -2} ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â poly.outer().push_back( {14, -2}Â ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â correct( poly ); Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â mp.push_back(poly); Â Â Â Â Â Â Â } Â Â Â Â Â Â Â Â Â boost::geometry::strategy::buffer::join_miter join_strategy; Â Â Â Â Â Â Â boost::geometry::strategy::buffer::end_flat end_strategy; Â Â Â Â Â Â Â boost::geometry::strategy::buffer::side_straight side_strategy; Â Â Â Â Â Â Â boost::geometry::strategy::buffer::point_square point_strategy; Â Â Â Â Â Â Â Â boost::geometry::strategy::buffer::distance_symmetric <double> distance_strategy( 2 ); Â Â Â Â Â Â Â boost::geometry::model::multi_polygon <polygon <Vector2d> > result; Â Â Â Â Â Â Â Â boost::geometry::buffer( mp, result, distance_strategy, side_strategy, join_strategy, end_strategy, point_strategy ); Â Â Â Â Â Â Â Â cout << dsv( result ) << endl; Â Â Â Â Â Â Â Â return 0; Â } Â and the result I get is: ((((13.7169, -3.13232), (13.5149, -3.94029), (12, -3.56155), (10.4851, -3.94029), (10.2831, -3.13232), (9.51493, -2.94029), (0.0749244, 0.221833), (10, 1), (14, 1), (23.9251, 0.221833), (14.4851, -2.94029), (13.7169, -3.13232)))) Â Notice the two points: (0.0749244, 0.221833) and (23.9251, 0.221833) Â I have multiple complex (concave) shapes which behave worse than that simple rectangle. But it is a starting point here. Â Did I do something wrong? I need to get my job done, any alternative or helping code massaging ? Â Thanks --Â MKL Â

1 0

[ASIO] Need help reading the documentation
by Andrzej Krzemienski 01 Jan '22

01 Jan '22

Hi Everyone, I need some help in reading the ASIO docs. I am looking at the following example from the docs https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/example/cpp17/cor… It calls one of the overloads of async_write in line co_await async_write(socket, boost::asio::buffer(data, n), use_awaitable); The reference section lists eight overloads: https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/async_w… But it is still impossible for me to figure out which one it is. `use_awaitable` is documented as "completion token" in https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/use_awa… There is some mention of completion token at https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/asynchr… So I would expect the name `CompletionToken` to appear in the documentation of `async_write`. Am I missing something? Regards, &rzej;

2 1

[ASIO] Do I have to use shared_ptrs with ASIO?
by Andrzej Krzemienski 29 Dec '21

29 Dec '21

Hi Everyone, I am looking at an example implementation of an asynchronous TCP echo server in Boost.ASIO library: https://www.boost.org/doc/libs/1_77_0/doc/html/boost_asio/example/cpp11/ech… It uses a shared_ptr in the implementation to store the things related to session: socket handle, data buffers. I tried to modify it in a number of ways to avoid the usage of shared_ptr (and any form of shared ownership), but they all failed. It looks like I have to use a shared_pointer (or equivalent) when I use ASIO sockets. But conceptually, there is never a point in time where two tasks have to access members of this `session` concurrently: they are always sequenced. So, at least conceptually, there should be a way to do this with a session type that is only movable, with unique ownership: a task does its job with the session and then moves it to the subsequent task. So is this necessity to use a shared pointer an unnecessary and suboptimal design choice? Or is there something fundamental that prevents the unique ownership of buffers and socket handles? Or maybe is there a way to do it in ASIO that I overlooked? I am not trying to solve any specific problem. It just strikes me that a shared_ptr is used in a demo example for the library. I was always of the opinion that a shared_ptr is often abused as a way of doing an ad-hoc GC. Regards, &rzej;

8 21

Seeking help for kickstart
by Rahul Sharma 23 Dec '21

23 Dec '21

Hello everyone, I read all the information given on the blog pages and websites sent to me via email which I received when I subscribed to this mailing list, but I am too confused and I am not able to figure out from where to start and how to find some beginner friendly issues and projects to work on. Hoping for help and guidance to kickstart this journey. Accept my apologies if this is not the proper way to communicate about such problems. Sent from [1]Mail for Windows References 1. https://go.microsoft.com/fwlink/?LinkId=550986

1 0

To contribute to this community.
by Rahul Sharma 22 Dec '21

22 Dec '21

Hello everyone, I am Rahul Sharma currently a sophomore at IIT Guwahati pursuing my B.Tech with major in Civil Engineering. I am very much enthusiastically inclined towards technology and want to pursue my carrier in the field of technology. And also I am very much interested in the open source communities and would really like to be part of such a community and to work with other peers with the same vision and to work with dedication on some really cool real world projects. My tech stack comprises of programming languages like c and c++ and am also a front end web developer and currently learning the back end web development with react. Seeking for the guidance from the other experienced peer developers and mentors. Sent from [1]Mail for Windows References 1. https://go.microsoft.com/fwlink/?LinkId=550986

2 1

[release] Boost 1.78.0
by Marshall Clow 09 Dec '21

09 Dec '21

Release 1.78.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.78.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.78.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse, Glen Fernandes

3 2

[release] Master branch is now open for merging
by Marshall Clow 08 Dec '21

08 Dec '21

No restrictions; the release calendar is up to date. https://boost.org/development Next milestone: 23-Feb Boost 1.79.0 closed for new libraries and breaking changes — Marshall

1 0

boost.spawn: review requested
by Oliver Kowalke 06 Dec '21

06 Dec '21

Hi, I'd like to propose the new library boost.spawn (https://olk.github.io/) for review. boost.asio's boost::asio::spawn() uses the deprecated and inefficient boost.coroutine library. boost.spawn provides the same functionality while using boost.context's fiber directly. Oliver

12 49

Boost::any typecasting issue(bad_any_cast)
by Daggumati, Rajesh 05 Dec '21

05 Dec '21

Hi Team, While doing typecasting from boost::any to DecodeErrorPayload_t, its throwing bad_any_cast .. class RegisterIONotification { public: enum NotifyType { TypeUnknown, TypeRegTx, TypeRegRx, TypeDecodeError }; NotifyType Type; boost::any Payload; typedef boost::tuple<std::string, BinaryBuffer_t> DecodeErrorPayload_t; RegisterIONotification(NotifyType type;,boost::any payload) { Type(type); Payload(payload); } }; I have called RegisterIONotification from other class function. void RegisterIOThreaded::OnDecodeError( const std::string& error, BinaryBuffer_t data ) { RegisterIONotification notify(RegisterIONotification::TypeDecodeError ,make_tuple(error, data)); ..... .... ... } While testing, I am getting bad_any_cast exception. TEST_F(...,...) { RegisterIONotification notify = sink.GetDataById(ID::NOTIFY_COMMS_STATUS, 0).GetValue<RegisterIONotification>(); ASSERT_EQ(RegisterIONotification::TypeDecodeError, notify.Type); //passed RegisterIONotification::DecodeErrorPayload_t payload; ASSERT_NO_THROW(payload = boost::any_cast<RegisterIONotification::DecodeErrorPayload_t>(notify.Payload));// Here its got failed...Please help me to fix this. } Regards, Rajesh D Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

3 2

[release] Boost 1.78.0 Release Candidate 1
by Marshall Clow 03 Dec '21

03 Dec '21

The first release candidates for the 1.78.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/> The SHA256 checksums are as follows: 94ced8b72956591c4775ae2207a9763d3600b30d9d7446562c552f0a14a63be7 boost_1_78_0_rc1.tar.gz f22143b5528e081123c3c5ed437e92f648fe69748e95fa6e2bd41484e2986cc3 boost_1_78_0_rc1.zip 090cefea470bca990fa3f3ed793d865389426915b37a2a3258524a7258f0790c boost_1_78_0_rc1.7z 8681f175d4bdb26c52222665793eef08490d7758529330f98d3b29dd0735bccc boost_1_78_0_rc1.tar.bz2 As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

3 3

[release] Master branch now closed for 1.78.0 release
by Marshall Clow 02 Dec '21

02 Dec '21

Please do not make any commits to the master branch. — Marshall

1 0

[release] 1.78.0 post-beta merges
by Marshall Clow 01 Dec '21

01 Dec '21

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy>> Reminder: The master branch closes for the release on Wednesday, December 1st. Full calendar here: https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall P.S Doc changes and test changes do NOT require release manager approval to be merged.

11 36

[Release] The release branch will close for the 1.78.0 release TOMORROW
by Marshall Clow 01 Dec '21

01 Dec '21

As always, calendar is here: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> — Marshall

1 0

Re: [boost] boost.spawn: review requested
by Boris Kolpackov 30 Nov '21

30 Nov '21

Oliver Kowalke <oliver.kowalke(a)gmail.com> writes: > Am Mo., 29. Nov. 2021 um 15:54 Uhr schrieb Boris Kolpackov < > boris(a)codesynthesis.com>: > > > FWIW (and I may be out of context), but "spawn" seems like a > > too generic of a name. I, for example, thought this is about > > posix_spawn(). Maybe call it spawn_fiber or some such? > > > > boost.asio named the function spawn() - boost.spawn named it spawn_fiber() Sorry, looks I wasn't clear enough: I am talking about the library name being too generic: Boost.Spawn can mean spawning all kinds of things (processes, threads, fibers, etc). The fact that you called the function spawn_fiber() in a sense confirms this.

1 0

[fusion] add support for view construction from movable view
by herve martin 28 Nov '21

28 Nov '21

Hi, When working with view of boost::fusion I feel something frustrated because of the limited set of possible constructors. Indeed, apart from copy constructor, views usually only provide constructors taken l-value reference on sequence as input. I would like to extend the constructors set of views with some new ones which would also accept r-value references on view as input. This would allow some fancy combination at construction time as for example: vector <https://www.boost.org/doc/libs/1_77_0/libs/fusion/doc/html/fusion/container…><bool> v0(true);vector <https://www.boost.org/doc/libs/1_77_0/libs/fusion/doc/html/fusion/container…><int, char> v1(3, 'x');vector <https://www.boost.org/doc/libs/1_77_0/libs/fusion/doc/html/fusion/container…><std::string, int> v2("hello", 123); using view1 = joint_view< vector <https://www.boost.org/doc/libs/1_77_0/libs/fusion/doc/html/fusion/container…><int, char> , vector <https://www.boost.org/doc/libs/1_77_0/libs/fusion/doc/html/fusion/container…><std::string, int>>;using view = joint_view< vector <https://www.boost.org/doc/libs/1_77_0/libs/fusion/doc/html/fusion/container…><bool> , view1>; view aview = view(v0, view1(v1, v2));std::cout << aview << std::endl; I would be glad to contribute to the boost library by updating the boost::fusion views with some new constructors bu I'm not familiar with development in boost. What would be the next step to give a chance to my proposal to integrate boost ? Best regards, Herve

1 0

Adding my sorting algorithm, ska_sort, to boost, attempt 2
by Malte Skarupke 24 Nov '21

24 Nov '21

Hi everyone, I started a discussion about this in October, but at the time the maintainer of the sort library was busy, then I was busy, so now it's January... I wrote a generalized version of radix sort a couple years ago and gave a talk about it here: https://www.youtube.com/watch?v=zqs87a_7zxw I would like to get a new version of that sorting algorithm into boost. It's faster than what I showed several years ago. It's also even more general and has a new interface that should be easier to extend. I uploaded the code here: https://github.com/skarupke/sort/tree/master The documentation is also already updated with new benchmark results. Let me know what's required to get this into boost. Would you like this in the form of a pull request? One of the big things that probably needs review is the interface, since radix sorting works differently than comparison based sorting. For most normal uses you just need to provide a sort key, but more complicated cases can get more complicated. I tried very hard to make everything easy, but I'd also be curious if others can come up with better ways of doing the interface. Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

8 10

[release] 1.78.0 post-beta merges
by Oliver Kowalke 20 Nov '21

20 Nov '21

Hi, I'd like to merge several fixes for boost.context, boost.coroutine, boost.coroutine2 and boost.fiber to branch master. Oliver

2 1

Boost::any bad_any_cast issue
by rajesh daggumati 18 Nov '21

18 Nov '21

Hi Team, While doing typecasting from boost::any to DecodeErrorPayload_t, its throwing bad_any_cast .. class RegisterIONotification { public: enum NotifyType { TypeUnknown, TypeRegTx, TypeRegRx, TypeDecodeError }; NotifyType Type; boost::any Payload; typedef boost::tuple<std::string, BinaryBuffer_t> DecodeErrorPayload_t; RegisterIONotification(NotifyType type;,boost::any payload) { Type(type); Payload(payload); } }; I have called RegisterIONotification from other class function. void RegisterIOThreaded::OnDecodeError( const std::string& error, BinaryBuffer_t data ) { RegisterIONotification notify(RegisterIONotification::TypeDecodeError ,make_tuple(error, data)); ..... .... ... } While testing, I am getting bad_any_cast exception. TEST_F(...,...) { RegisterIONotification notify = sink.GetDataById(ID::NOTIFY_COMMS_STATUS, 0).GetValue<RegisterIONotification>(); ASSERT_EQ(RegisterIONotification::TypeDecodeError, notify.Type); //passed RegisterIONotification::DecodeErrorPayload_t payload; ASSERT_NO_THROW(payload = boost::any_cast<RegisterIONotification::DecodeErrorPayload_t>(notify.Payload));// Here its got failed…Please help me to fix this. } Regards, Rajesh D

2 1

ASIO problem with boost 1.78.0.beta1 ?
by Stefan Heinzmann 13 Nov '21

13 Nov '21

Hi all, I'm observing a problem with boost::asio that has surfaced with the newest beta relative to version 1.77.0, using MSVC 16.11.6. I'm getting the following errors: 1>...src\libs\asio\include\boost/asio/impl/any_io_executor.ipp(26,18): error C2039: 'any_io_executor': is not a member of 'boost::asio::executor' 1>...src\libs\asio\include\boost/asio/executor.hpp(48): message : see declaration of 'boost::asio::executor' 1>...src\libs\asio\include\boost/asio/impl/any_io_executor.ipp(26,34): error C2059: syntax error: ')' 1>...src\libs\asio\include\boost/asio/impl/any_io_executor.ipp(28,1): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ...and so on. The errors seem rather weird to me, so I might be doing something wrong myself, but the exact same code compiles fine with 1.77.0, using the same compiler. Has anyone got an idea what's wrong? Should I raise an issue in github? Cheers Stefan Heinzmann

1 1

union support in describe
by Gero Peterhoff 12 Nov '21

12 Nov '21

Hello, first of all, thank you very much for the great work. But I miss the support for unions. Is that correct? namespace boost { namespace describe { #define BOOST_DESCRIBE_UNION(C, Public) \ static_assert(std::is_union<C>::value, "BOOST_DESCRIBE_UNION should only be used with union types"); \ BOOST_DESCRIBE_PUBLIC_MEMBERS_(C BOOST_DESCRIBE_PP_UNPACK Public) \ BOOST_DESCRIBE_PROTECTED_MEMBERS_(C) \ BOOST_DESCRIBE_PRIVATE_MEMBERS_(C) } // describe } // boost This version only supports public members. I also miss the support for std::get. Is that correct? namespace boost { namespace describe { #define BOOST_DESCRIBE_GET(C) \ template <std::size_t Index> \ inline constexpr const auto& get(const C& arg) noexcept \ { \ static_assert(std::is_class<C>::value || std::is_union<C>::value, "BOOST_DESCRIBE_GET should only be used with class, struct or union types"); \ using members = boost::describe::describe_members<C, boost::describe::mod_any_access>; \ static_assert(Index < boost::mp11::mp_size<members>()); \ return arg.*boost::mp11::mp_at_c<members, Index>().pointer; \ } \ template <std::size_t Index> \ inline constexpr auto& get(C& arg) noexcept \ { \ static_assert(std::is_class<C>::value || std::is_union<C>::value, "BOOST_DESCRIBE_GET should only be used with class, struct or union types"); \ using members = boost::describe::describe_members<C, boost::describe::mod_any_access>; \ static_assert(Index < boost::mp11::mp_size<members>()); \ return arg.*boost::mp11::mp_at_c<members, Index>().pointer; \ } } // describe } // boost However, the access rights are not taken into account. E.g.: struct A { int i; float f; }; BOOST_DESCRIBE_STRUCT(A, (), (i, f)) namespace std { BOOST_DESCRIBE_GET(A) } // std This also solves a very special problem, provided the compiler supports it: active member of a constexp union. Problem: union U { int64_t i; double d; }; constexpr U u{.d{3.1415}}; constexpr auto i=u.i; -> error In short: namespace std { template <typename Type> inline constexpr bool is_constant_initialized(const Type& arg) noexcept { #if __has_builtin(__builtin_constant_p) return __builtin_constant_p(arg); #elif defined(BOOST_MSVC) ??? #else static_assert(false, "is_constant_initialized not supportet"); return false; #endif } template <typename Type> inline constexpr bool is_constant_initialized_front(const Type& arg) noexcept { return is_constant_initialized(arg); } template <typename Type, size_t Size> inline constexpr bool is_constant_initialized_front(const Type(&arg)[Size]) noexcept { static_assert(Size > 0); return is_constant_initialized(arg[0]); } template <typename Type, size_t Size> inline constexpr bool is_constant_initialized_front(const std::array<Type, Size>& arg) noexcept { static_assert(Size > 0); return is_constant_initialized(arg[0]); } } // std namespace boost { namespace describe { template <typename Type> inline constexpr std::size_t active_index(const Type& arg) noexcept { static_assert(std::is_union_v<Type>); using any = describe_members<Type, mod_any_access>; std::size_t result{0}, index{0}; bool first{true}; boost::mp11::mp_for_each<any>([&](const auto& desc) constexpr noexcept { const auto& elem{arg.*desc.pointer}; if (std::is_constant_initialized_front(elem)) { if (first) { first = false; result = index; } } ++index; }); return first ? 0 : result; } template <auto Value> inline constexpr std::size_t active_index_v = std::integral_constant<std::size_t, active_index(Value)>::value; } // describe } // boost union __mm128_emu { float m128_f32[4]; double m128_f64[2]; int64_t m128_i64[2]; int32_t m128_i32[4]; int16_t m128_i16[8]; int8_t m128_i8[16]; uint64_t m128_u64[2]; uint32_t m128_u32[4]; uint16_t m128_u16[8]; uint8_t m128_u8[16]; }; BOOST_DESCRIBE_UNION(__mm128_emu, (m128_f32, m128_f64, m128_i64, m128_i32, m128_i16, m128_i8, m128_u64, m128_u32, m128_u16, m128_u8)) namespace std { BOOST_DESCRIBE_GET(__mm128_emu) } // std constexpr __mm128_emu m128{.m128_u32{4711}}; constexpr auto arr = std::to_array(std::get<boost::describe::active_index_v<m128>>(m128)); // works with gcc, clang, intel Do you have an idea how to implement __builtin_constant_p for all compilers? thx Gero

2 2

Update on the 1.78.0 beta
by Marshall Clow 11 Nov '21

11 Nov '21

The beta was supposed to be released yesterday. It’s done, but there’s an issue on Jfrog that seems to make it hard to download. I’m talking to the JFrog folks to get this resolved, and when that’s done, I’ll announce that the beta is released. — Marshall

1 0

[release] Boost 1.78.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 09 Nov '21

09 Nov '21

The first release candidates for the 1.78.0 beta release are now available at: <https://boostorg.jfrog.io/ui/native/main/beta/1.78.0.beta1/source <https://boostorg.jfrog.io/ui/native/main/beta/1.78.0.beta1/source>> The SHA256 checksums are as follows: 7a3a025451dfa2923129214eef7d16b03c02310a353d02158a549f6caa4284b0 boost_1_78_0_b1_rc1.tar.bz2 c491b1dcb916195598aa6581d6708d57fcc750516641c22511c088d572de9c07 boost_1_78_0_b1_rc1.tar.gz 35e7a3b0eb412a3933e57c72ba96374eb7d88ff1f89dbec62a16d67ffea2105a boost_1_78_0_b1_rc1.7z e6b68feb2f63401c96ca9fe25e939b409189fbe526a6e784e4bd69832c8f09cb boost_1_78_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

3 5

How to get started with contribution
by Anmol Singh 09 Nov '21

09 Nov '21

Respected Sir/Madam, I am Anmol Singh, an Information Technology undergrad. I have just entered my second year at ADGITM, IP University. I am new to open source contributions but I am well aware of C++,C and javascript. I would love to contribute to your organisation but could you please tell me how to get started? Regards Anmol

1 0

conversion of catched exception to shared_ptr
by rajesh daggumati 08 Nov '21

08 Nov '21

rajesh daggumati <rajeshdaggumati9999(a)gmail.com> 09:59 (4 hours ago) to boost-users HI, please help me to solve below issue. Shared pointers are used in my code. class Exception : public virtual std::exception,public virtual boost::exception { --- }; class ExceptionTestException : public Exception { --- }; boost::shared_ptr<Exception> exceptionptr_t; try { Boost_Throw_function(ExceptionTestException("Hiii")); } catch(...) { boost::exception_ptr exceptionptr = boost::current_exception(); try { boost::rethrow(exceptionptr) } catch(boost::exception &e) { //here i need to assign this 'e' to shared pointer but this e is not in heap so then how to assign this e to sharedptr(exceptionptr_t). 1 way is : boost::exception *ep = new ExceptionTestException(e); exceptionptr_t(ep); here we know that exception_ptr is having ExceptionTestException but in some cases, we dont know which type of excepiton we have in exception_ptr in runtime. then how to assign to shared_ptr

4 4

Library category error handling
by Emil Dotchevski 07 Nov '21

07 Nov '21

Should we add a formal category for error handling libraries in https://www.boost.org/development/library_metadata.html?

5 6

Does boost have a way to get type name at compile time?
by Ivan Matek 04 Nov '21

04 Nov '21

I am aware of hacks/magic with __PRETTY_FUNCTION__ <https://stackoverflow.com/questions/69624128/parameter-pack-sorting-or-equi…>but I wonder if there is a portable boost way to do that?

2 1

Header-only libraries linking to compiled libraries...
by Peter Dimov 03 Nov '21

03 Nov '21

... create problems (at least) for CMake users, because a project using a header-only library must link to its compiled dependencies by hand. (Important Note: this is not about the CMake build of Boost. It's about the b2 build of Boost, and the CMake configuration files it generates.) Compiled libraries don't have this problem, because they have CMake targets, and linking to the library target automatically links to the dependencies. For instance, linking to Boost::filesystem would automatically link to Boost::atomic (and on Windows, to bcrypt.lib) as needed. However, as pointed out in https://github.com/boostorg/boost_install/issues/54, header-only libraries such as Process or UUID have no CMake targets. Consequently, it's not possible for the CMake project to link to Boost::uuid and automatically inherit the dependency to bcrypt.lib, or to link to Boost::process and automatically acquire a dependency to Boost::filesystem. Since the CMake configuration files that are generated by `b2 install` define CMake targets based on the b2 targets, it's not possible to fix this just on the boost-install side. If we want Boost::process to appear as a target in CMake, we need boost_process to appear as a target in b2, that is, we need libs/process/build/Jamfile to exist. The easiest way to fix it - if we decide to do something about it - is to create dummy compiled libraries for each such header-only library that isn't really header-only because of dependencies. A number of Boost libraries are already header-only with a stub library for backward compatibility (System, DateTime, Regex), so this wouldn't be something novel.

6 17

Reminder: The master branch will be closing for the 1.78.0 beta release TOMORROW
by Marshall Clow 02 Nov '21

02 Nov '21

If you have changes for the beta, they need to be merged to master before the end of day tomorrow. See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar — The Release managers

1 0

Boost libraries packaged for build2
by Boris Kolpackov 02 Nov '21

02 Nov '21

We have added support for the build2 build systems to 136 out of 145 Boost libraries and version 1.77.0 is now available from the cppget.org package repository. For details, see: https://build2.org/blog/build2-boost.xhtml Folks on this mailing list may be particularly interested in the "Implementation Details" section where we go deeper into how this conversion was accomplished: https://build2.org/blog/build2-boost.xhtml#impl-details (There is also the README-DEV file in the repository linked from this section which has even more details.) Also, let me add that this is not a call to convert Boost to build2. While we would gladly assist with this effort if the Boost community so wishes, we are also happy to continue our work out of tree.

1 0

boost::trim_copy(boost::string_view()); // error
by Olaf van der Spek 31 Oct '21

31 Oct '21

Hi, Why does the overload for boost::string_view not work? The std one works. Could it be made to work? #include <boost/algorithm/string.hpp> #include <boost/utility/string_ref.hpp> #include <boost/utility/string_view.hpp> #include <iostream> #include <string_view> int main() { boost::trim_copy(boost::string_view()); // error boost::trim_copy(std::string_view()); } $ g++ t0.cpp In file included from /usr/include/boost/algorithm/string.hpp:19, from t0.cpp:1: /usr/include/boost/algorithm/string/trim.hpp: In instantiation of ‘SequenceT boost::algorithm::trim_copy_if(const SequenceT&, PredicateT) [with SequenceT = boost::basic_string_view<char, std::char_traits<char> >; PredicateT = boost::algorithm::detail::is_classifiedF]’: /usr/include/boost/algorithm/string/trim.hpp:343:49: required from ‘SequenceT boost::algorithm::trim_copy(const SequenceT&, const std::locale&) [with SequenceT = boost::basic_string_view<char, std::char_traits<char> >]’ t0.cpp:10:19: required from here /usr/include/boost/algorithm/string/trim.hpp:319:20: error: no matching function for call to ‘boost::basic_string_view<char, std::char_traits<char> >::basic_string_view(const char*, const char*&)’ 319 | return SequenceT( | ^~~~~~~~~~ 320 | detail::trim_begin( | ~~~~~~~~~~~~~~~~~~~ 321 | ::boost::begin(Input), | ~~~~~~~~~~~~~~~~~~~~~~ 322 | TrimEnd, | ~~~~~~~~ 323 | IsSpace), | ~~~~~~~~~ 324 | TrimEnd | ~~~~~~~ 325 | ); | ~ In file included from t0.cpp:3: /usr/include/boost/utility/string_view.hpp:97:9: note: candidate: ‘template<class Allocator> boost::basic_string_view<charT, traits>::basic_string_view(const std::__cxx11::basic_string<charT, traits, Allocator>&) [with Allocator = Allocator; charT = char; traits = std::char_traits<char>]’ 97 | basic_string_view(const std::basic_string<charT, traits, Allocator>& str) BOOST_NOEXCEPT | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:97:9: note: template argument deduction/substitution failed: In file included from /usr/include/boost/algorithm/string.hpp:19, from t0.cpp:1: /usr/include/boost/algorithm/string/trim.hpp:319:20: note: mismatched types ‘const std::__cxx11::basic_string<char, std::char_traits<char>, Allocator>’ and ‘const char*’ 319 | return SequenceT( | ^~~~~~~~~~ 320 | detail::trim_begin( | ~~~~~~~~~~~~~~~~~~~ 321 | ::boost::begin(Input), | ~~~~~~~~~~~~~~~~~~~~~~ 322 | TrimEnd, | ~~~~~~~~ 323 | IsSpace), | ~~~~~~~~~ 324 | TrimEnd | ~~~~~~~ 325 | ); | ~ In file included from t0.cpp:3: /usr/include/boost/utility/string_view.hpp:110:23: note: candidate: ‘constexpr boost::basic_string_view<charT, traits>::basic_string_view(const charT*, boost::basic_string_view<charT, traits>::size_type) [with charT = char; traits = std::char_traits<char>; boost::basic_string_view<charT, traits>::size_type = long unsigned int]’ (near match) 110 | BOOST_CONSTEXPR basic_string_view(const charT* str, size_type len) | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:110:23: note: conversion of argument 2 would be ill-formed: In file included from /usr/include/boost/algorithm/string.hpp:19, from t0.cpp:1: /usr/include/boost/algorithm/string/trim.hpp:324:17: error: invalid conversion from ‘boost::range_detail::extract_const_iterator<boost::basic_string_view<char, std::char_traits<char> >, true>::typ’ {aka ‘const char*’} to ‘boost::basic_string_view<char, std::char_traits<char> >::size_type’ {aka ‘long unsigned int’} [-fpermissive] 324 | TrimEnd | ^~~~~~~ | | | boost::range_detail::extract_const_iterator<boost::basic_string_view<char, std::char_traits<char> >, true>::type {aka const char*} In file included from t0.cpp:3: /usr/include/boost/utility/string_view.hpp:107:23: note: candidate: ‘constexpr boost::basic_string_view<charT, traits>::basic_string_view(const charT*) [with charT = char; traits = std::char_traits<char>]’ 107 | BOOST_CONSTEXPR basic_string_view(const charT* str) | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:107:23: note: candidate expects 1 argument, 2 provided /usr/include/boost/utility/string_view.hpp:78:23: note: candidate: ‘constexpr boost::basic_string_view<charT, traits>::basic_string_view(const boost::basic_string_view<charT, traits>&) [with charT = char; traits = std::char_traits<char>]’ 78 | BOOST_CONSTEXPR basic_string_view(const basic_string_view &rhs) BOOST_NOEXCEPT | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:78:23: note: candidate expects 1 argument, 2 provided /usr/include/boost/utility/string_view.hpp:73:23: note: candidate: ‘constexpr boost::basic_string_view<charT, traits>::basic_string_view() [with charT = char; traits = std::char_traits<char>]’ 73 | BOOST_CONSTEXPR basic_string_view() BOOST_NOEXCEPT | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:73:23: note: candidate expects 0 arguments, 2 provided In file included from /usr/include/boost/algorithm/string.hpp:19, from t0.cpp:1: /usr/include/boost/algorithm/string/trim.hpp: In instantiation of ‘SequenceT boost::algorithm::trim_copy_if(const SequenceT&, PredicateT) [with SequenceT = std::basic_string_view<char>; PredicateT = boost::algorithm::detail::is_classifiedF]’: /usr/include/boost/algorithm/string/trim.hpp:343:49: required from ‘SequenceT boost::algorithm::trim_copy(const SequenceT&, const std::locale&) [with SequenceT = std::basic_string_view<char>]’ t0.cpp:11:19: required from here /usr/include/boost/algorithm/string/trim.hpp:324:17: error: invalid conversion from ‘boost::range_detail::extract_const_iterator<std::basic_string_view<char>, true>::type’ {aka ‘const char*’} to ‘std::basic_string_view<char>::size_type’ {aka ‘long unsigned int’} [-fpermissive] 324 | TrimEnd | ^~~~~~~ | | | boost::range_detail::extract_const_iterator<std::basic_string_view<char>, true>::type {aka const char*} In file included from /usr/include/c++/11/bits/basic_string.h:48, from /usr/include/c++/11/string:55, from /usr/include/boost/algorithm/string/std/string_traits.hpp:15, from /usr/include/boost/algorithm/string/std_containers_traits.hpp:19, from /usr/include/boost/algorithm/string.hpp:18, from t0.cpp:1: /usr/include/c++/11/string_view:137:56: note: initializing argument 2 of ‘constexpr std::basic_string_view<_CharT, _Traits>::basic_string_view(const _CharT*, std::basic_string_view<_CharT, _Traits>::size_type) [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]’ 137 | basic_string_view(const _CharT* __str, size_type __len) noexcept | ~~~~~~~~~~^~~~~ -- Olaf

2 1

VS2022 release date is Nov 8
by Peter Dimov 30 Oct '21

30 Oct '21

The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.

9 12

The deadline for new libraries and breaking changes in Boost 1.78.0 is Friday, October 29
by Marshall Clow 27 Oct '21

27 Oct '21

Sorry for the late notice; the deadline was supposed to be today, but I'm extending it to Friday. See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar Next deadline: Boost 1.78.0 closed for beta Wednesday, Nov 3, 2021 — The Release Managers

1 0

Header-only Boost.System
by Ashish Singh 25 Oct '21

25 Oct '21

Hi All, In my application, I'm trying to use Boost ASIO via boost 1.66 and defining the following two macros in the Makefile. Basically trying to use the header-only approach. CFLAGS += \ -DBOOST_ERROR_CODE_HEADER_ONLY \ -DBOOST_SYSTEM_NO_DEPRECATED But then I came across this thread: https://lists.boost.org/Archives/boost/2017/10/239106.php "In header only mode, multiple instances may appear and thus no longer be proper singletons. Stuff breaks in this situation, badly." Is the above applicable to 1.66 too?How can I safely use the header-only approach in boost 1.66? Thanks,Ashish

2 8

Boost.URL: Something Wicked This Way Comes! (Was: Needs Review)
by Vinnie Falco 21 Oct '21

21 Oct '21

Folx: Well, I was on a pause but I picked Boost.URL back up and whipped it into shape. The good news, this Belle is ready for the Ball ! I invite you to kick the tires and light the fires on the next major component in my line of network and protocol libraries: Repository <https://github.com/CPPAlliance/url/> Documentation <https://master.url.cpp.al/> Docs are still being worked on, of course (docs are never "done"). `url_view`, `url`, `static_url`, and `authority_view` should be completely solid and ready to get beat up. And I'm ready for all that lovely negative feedback !!! If a kind soul would like to volunteer to be the review manager, that would be swell. I'm very happy to answer any questions about the library, and happy to get feedback regarding the design and implementation. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

12 79

Opinions on introduction of string_view in Core
by Andrey Semashev 21 Oct '21

21 Oct '21

Hi, Recently, a new implementation of string_view was introduced in Boost.Core: https://github.com/boostorg/core/blob/d5bd40e5280487fb29a108eb42e6c4f0bef69… Most of you probably know there is also a string_view implementation in Boost.Utility: https://github.com/boostorg/utility/blob/05e0d1688dcfcd3fdd65bdb6884b7edd1a… The main motivation for introducing the new implementation is adding conversions to/from std::string_view, which were proposed to Boost.Utility and rejected a while ago: https://github.com/boostorg/utility/pull/51 Another notable deviation of boost::core::string_view from std::string_view and boost::string_view is that it only accepts the character type in template parameters and not char_traits. This choice was made to simplify implementation. I have concerns that introducing yet another string_view type (3rd in Boost, after boost::string_ref and boost::string_view, not counting std::string_view) is not good for the ecosystem and interoperability, as this will require adding explicit support in some code bases. One example that I readilly have is Boost.Log: https://github.com/boostorg/log/blob/4c54e4ca4c31f18ce2e451e8d0abf88054242d… std::string_view was supposed to make user's code simpler by removing the need to provide a multitude of function overloads accepting string arguments. boost::string_view (and boost::string_ref before it) was a prototype implementation before introduction of std::string_view and served a similar purpose. In the age with std::string_view, boost::string_view is still useful as a drop-in replacement for std::string_view to lower C++ requirements in libraries and projects, like this: #if !defined(BOOST_NO_CXX17_HDR_STRING_VIEW) using std::basic_string_view; using std::string_view; using std::string_view; #else using boost::basic_string_view; using boost::string_view; using boost::string_view; #endif Introducing boost::core::string_view, which is not a drop-in replacement, does not make users' code simpler as it requires adding yet another set of overloads and specializations to users' APIs. I should stress that I'm not opposing because I don't want to make changes to Boost.Log, I'm opposing because I don't think those changes will be for the better, and because I view this as potentially destructive to the wide adoption of one common string_view type (be it std::string_view or boost::string_view, depending on the conventions taken in the project) to accept string arguments. Please, express your opinions on this matter, in particular: - Do you think it is good/ok/bad to have yet another string_view in Boost? - Is it ok that boost::core::string_view is not a drop-in replacement for std::string_view? Should it be changed to be one? - Should we, perhaps, do something with boost::string_view from Boost.Utility? Deprecate? - Should we reopen the discussion to add conversion to/from std::string_view to boost::string_view, which led to this fork? Perhaps, hold a vote to make this change as widely requested? - Any other course of action or thoughts? Thanks. PS: This post was made after an initial discussion in this commit: https://github.com/boostorg/core/commit/95924b1329da49e70c9c8485b87e066895d…

12 57

hash_value( complex<T> )
by Peter Dimov 19 Oct '21

19 Oct '21

At the moment, boost::hash_value for complex<T> is specified as When T is a built in type and val.imag() == 0, the result is equal to hash_value(val.real()). Otherwise an unspecified value, except that equal arguments shall yield the same result. This is a bit odd; the natural implementation for a two-argument point/tuple type is std::size_t seed = 0; boost::hash_combine( seed, v.real() ); boost::hash_combine( seed, v.imag() ); return seed; Can anyone offer an opinion on whether or why the original behavior is preferable?

3 6