August 2022 - Boost - lists.boost.org

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

13 Aug '24

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

49 200

Boost Governance?
by René Ferdinand Rivera Morell 09 Aug '24

09 Aug '24

A disclaimer: I write this solely as a Boost Library author. And not in any other capacity or representing any other interest. It's now been at least a year since Boost switched from the Software Freedom Conservancy to the Boost Foundation for its governance organization. But have people noticed any difference? Did you know that switch happened? Did you know that they held an election for the Board of Directors and for the Officers? Do you know when that election happened? Do you know who got elected? Do you know how they were selected? Do you know what their responsibilities are? Do you know what their bylaws are? Do you know their financials? More importantly: Did you answer "no" to any of those questions? As a library author, I can say I definitely answered no to many of those questions. This is a problem. As authors, without asking, we should know those answers from the organization that governs our work. We should have input into how that organization governs. In other words, we deserve open and transparent governance; not the closed and opaque status quo. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

10 10

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

Hi, I've written and released a (rather small) library which allows defining arrays with arbitrary index mechanisms (hence the name, indexed_array). This especially allows indexing with scoped enums, use non zero-starting indexes, or use sparse indexes. This is not a view, but an array in the sense that it owns the data, and provides the same guarantees and functionalities as std::array, such as triviality propagation, being able to reside in read-only program sections, etc. It also supports multidimensional indexing, and provides an indexed_span template class to access lower dimension content (which can be used outside indexed_array). Finally, it provides an opt-in safer way to initialize the array content, which is especially useful when using complex and/or changing indexing schemes (like based on externally generated files). The library is available here: https://github.com/Julien-Blanc-tgcm/indexed_array And the doc is here: https://julien-blanc-tgcm.github.io/indexed_array/ It requires C++17 and mp11, and has first-class support for describe-d enums. If there is some interest, i'd like to propose it for inclusion in boost. So i'm looking for people who would endorse it. Thanks and best regards, Julien

8 24

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

[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 30 Aug '22

30 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 24 Aug '22

24 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