- Boost-users - lists.preview.boost.org

Re: [Boost-users] [release] Boost 1.82.0
by Damien 14 Apr '23

14 Apr '23

FYI the link does to the new sql library does not work: https://www.boost.org/doc/libs/1_82_0/libs/msyql/ On 4/13/2023 9:37 PM, Marshall Clow via Boost-users wrote: > Release 1.82.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 contain numerous enhancements and bug fixes for existing libraries. > > For details, including download links, see > <http://www.boost.org/users/news/version_1.82.0> > > You can also download directly from: > <https://boostorg.jfrog.io/artifactory/main/release/1.82.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 > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[release] Boost 1.82.0
by Marshall Clow 14 Apr '23

14 Apr '23

Release 1.82.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 contain numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.82.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.82.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

1 0

New video on TCP/IP Networking with Boost.Asio
by Richard 13 Apr '23

13 Apr '23

Utah C++ Programmers has released a new video on TCP/IP Networking with Boost.Asio <https://www.youtube.com/watch?v=tyDWXT8-Ykc> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

1 0

Format a JSON string
by Markus Pieper 13 Apr '23

13 Apr '23

Hi there, I convert a std::vector<std::vector<float>> to a JSON string. Basically it works, but the format is scientific: "[[1.017E3,1.017E3,1.017E3 ... ]]" My method looks now like this: std::string Class::convertFieldAsJSON(std::vector<std::vector<float>> field) { return boost::json::serialize(boost::json::value_from(field)); } It works, but my colleagues want to see a 1017 and not 1.017E3 in the output. Is there a way to format the string? Thanks in advance, Markus

4 3

ASIO: Support for SQPOLL in io_uring backend
by Cyan Reddish 05 Apr '23

05 Apr '23

I was wondering if anything like that is planned. I am also interested in other general io_uring options like setting affinity masks for IO worker threads. As far as I can see there is no way to pass parameters from io_context to io_uring_service.

1 0

Re: [Boost-users] Cannot compile Boost JSON under Visual Studio 2022 with /clr
by Gavin Lambert 05 Apr '23

05 Apr '23

On 5/04/2023 12:08, Kevin Frey wrote: > This works fine on X86 and X64 builds, but when I try a .NET /clr > compile, I get errors coming out of parser.ipp and a few other places, > all of this type: > > Error C2679 binary '=': no operator found which takes a right-hand > operand of type 'boost::json::error_code' (or there is no acceptable > conversion) > > The code producing the error is trying to convert the > boost::system::error_code to a std::error_code, via a simple assignment, > so clearly relying on a conversion operator. > > It appears that the conversion to std::error_code is conditionally > included based on the BOOST_SYSTEM_HAS_SYSTEM_ERROR macro, but if I > manually define this macro I get a whole lot of other errors instead > (mainly relating to Mutex). > > Is this a bug in the library, or a misconfiguration on my part in order > to compile correctly for /clr? Several of the STL facilities (including std::error_code, sadly) react poorly to /clr. For best results you're recommended to compile code that run into these sorts of things as pure native, by putting them into a separate .cpp that's compiled without /clr, and wrapping any header includes from /clr .cpps with #pragma managed(...) to switch to native mode. In some cases you will have to hide the native code entirely from your /clr code (e.g. behind PIMPL) where even the headers aren't safe to include. (Anything that uses <atomic> tends to fall into this.) Unfortunately it appears Microsoft has put C++/CLI onto life support so this is not likely to improve much in the future. The Way of the Future™ is apparently to write all managed code in C#, all native code in C++, and either entirely avoid C++/CLI (via p/invoke) or write only the most minimal interop glue layer in it between the other two.

1 0

Cannot compile Boost JSON under Visual Studio 2022 with /clr
by Kevin Frey 05 Apr '23

05 Apr '23

Hello Boosters, I have a simple file to compile the Boost JSON source (Boost 1.81) to avoid creating a library: #define BOOST_CONTAINER_NO_LIB #include "boost\json\src.hpp" This works fine on X86 and X64 builds, but when I try a .NET /clr compile, I get errors coming out of parser.ipp and a few other places, all of this type: Error C2679 binary '=': no operator found which takes a right-hand operand of type 'boost::json::error_code' (or there is no acceptable conversion) The code producing the error is trying to convert the boost::system::error_code to a std::error_code, via a simple assignment, so clearly relying on a conversion operator. It appears that the conversion to std::error_code is conditionally included based on the BOOST_SYSTEM_HAS_SYSTEM_ERROR macro, but if I manually define this macro I get a whole lot of other errors instead (mainly relating to Mutex). Is this a bug in the library, or a misconfiguration on my part in order to compile correctly for /clr? Thanks in advance Kevin

1 0

[compute] test_constant_iterator.cpp fails on msvc 2022 (boost 1_81_0)
by Ran Regev 03 Apr '23

03 Apr '23

Hi, The file in the subject fails to compile under MSVC 2022. Does someone have any idea why and how to fix it? Details: This file: boost_1_81_0\libs\compute\test\test_constant_iterator.cpp With these errors: Build started... 1>------ Build started: Project: BoostTests, Configuration: Debug x64 ------ 1>test_constant_iterator.cpp 1>C:\Externals\boost_1_81_0\boost\compute\iterator\constant_iterator.hpp(114,17): error C2440: 'return': cannot convert from 'const T' to 'int &' 1> with 1> [ 1> T=int 1> ] 1>C:\Externals\boost_1_81_0\boost\compute\iterator\constant_iterator.hpp(114,17): message : Conversion loses qualifiers 1>C:\Externals\boost_1_81_0\boost\compute\iterator\constant_iterator.hpp(112,1): message : while compiling class template member function 'int &boost::compute::constant_iterator<int>::dereference(void) const' 1>C:\Externals\boost_1_81_0\boost\iterator\iterator_facade.hpp(550,11): message : see reference to function template instantiation 'int &boost::compute::constant_iterator<int>::dereference(void) const' being compiled 1>C:\Externals\boost_1_81_0\libs\compute\test\test_constant_iterator.cpp(30,59): message : see reference to class template instantiation 'boost::compute::constant_iterator<int>' being compiled 1>Done building project "BoostTests.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== ========== Build started at 4:39 PM and took 03.713 seconds ========== Ran.

1 0

Boost configuration errors and problems
by Raivo Rebane 20 Mar '23

20 Mar '23

Hi, I have installed boost by conda and it install correctly. The following packages will be downloaded: package | build ---------------------------|----------------- boost-1.78.0 | py310h220cb41_4 555 KB conda-forge ------------------------------------------------------------ Total: 555 KB The following NEW packages will be INSTALLED: boost conda-forge/win-64::boost-1.78.0-py310h220cb41_4 But CMake gives configuration errors : CMake Error at C:/Users/Raivo/miniconda3/Library/lib/cmake/Boost-1.78.0/BoostConfig.cmake:141 (find_package): Found package configuration file: C:/Users/Raivo/miniconda3/Library/lib/cmake/boost_filesystem-1.78.0/boost_filesystem-config.cmake but it set boost_filesystem_FOUND to FALSE so package "boost_filesystem" is considered to be NOT FOUND. Reason given by package: No suitable build variant has been found. The following variants have been tried and rejected: * boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) Still Boost is useless for me as I wanted to build Point CLoud Lib, bud CMake stops on these errors. What I have to do ? And how to go forward ? Can anybody help me ? Regards Raivo

1 0

Re: [Boost-users] Boost.DLL on MacOS (Intel) building Universal Binary ?
by Bo Zhou 18 Mar '23

18 Mar '23

It might not be the issue on Boost but macOS, the*.dylib file to be signed if you want it to run it as distribution. https://developer.apple.com/library/archive/documentation/Security/Conceptu… On Sat, Mar 18, 2023 at 12:49 PM Nicholas Yue via Boost-users < boost-users(a)lists.boost.org> wrote: > Hi, > > I have an application which uses Boost.DLL > > I have built and run them successfully on Linux, Windows and MacOS. > > I have an Intel Mac running Big Sur and have built Boost 1.81.0 > successfully as a universal binary with both arm64 and x86_64 libraries > combined. > > However, while other parts of boost library runs fine, I have found that > Boost.DLL will fail to load the plugins (also built as universal binary). > > Is there additional steps we need to take when building DLL plugins via > Boost.DLL as universal binary so that the loading mechanism is able to pick > the correct portion of the *.dylib that is for the current architecture of > the host application ? > > Cheers > -- > Nicholas Yue > https://www.linkedin.com/in/nicholasyue/ > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >

2 1