- Boost - lists.boost.org

1.80.0 issue with Clang 15
by Peter Dimov 10 Sep '22

10 Sep '22

I'm getting multiple reports that ContainerHash 1.80.0 doesn't compile with Clang 15, due to the following change to Config unfortunately not being part of the 1.80.0 release: https://github.com/boostorg/config/commit/f0af4a9184457939b89110795ae2d2935… Since the plans for 1.80.1 have been abandoned, it's not clear what we can do about that except probably updating the Known Issues section.

3 2

How to know the connected server is down ?
by Raghu Huchchannavar 07 Sep '22

07 Sep '22

Hi, I am using the boost socket for the client and server connection. i set the socket option as below boost::asio::socket_base::keep_alive option(true); tcp_socket->set_option(option); I am able to connect the client to the server. Suppose after some time the server goes down. How do I get that information without sending any read/write request? 1. Now I don't know how to check if the client is down ? 2. Do I get the signal that the client is down? (Without reading or writing at the client )? . If yes, how to handle it. Please help me with this ... -- Regards Raghavendra Huchchannavar.

3 2

[Leaf] Unable to compile with particular flags.
by Misha Doter 06 Sep '22

06 Sep '22

Hi. I have a project ( https://github.com/rokoDev/buffer/tree/develop ) where I want to use Boost.Leaf as an error handling mechanism. And in addition I need to compile it by clang compiler with flags "-Werror -Wshadow-all -Wsign-conversion -Wextra" but it turned out that Boost.Leaf was unable to compile with these flags. So I have created a git fork( https://github.com/rokoDev/leaf/tree/clang_flags ) from official Boost.Leaf ( https://github.com/boostorg/leaf ) and made minimal changes which allowed me to build it with those flags. Also I have run all unit tests for Boost.Leaf on MacOS with success. Is it possible to accept my changes(probably with appropriate corrections if either) in order to allow compilation of any project with the same compiler flags as in my project but using the official version of Boost.Leaf?

3 4

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