- Boost-users - lists.boost.org

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

04 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 04 Apr '23

04 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 17 Mar '23

17 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

Boost.DLL on MacOS (Intel) building Universal Binary ?
by Nicholas Yue 17 Mar '23

17 Mar '23

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/

1 0

New video: Getting Started with Boost.Asio: Timers and Serial Ports
by Richard 15 Mar '23

15 Mar '23

Utah Cpp Programmers has released a new video Getting Started with Boost.Asio: Timers and Serial Ports <https://www.youtube.com/watch?v=XB3uEit5R_Y> I/O operations are inherently asynchronous -- we don't know when input will arrive and when output will be generated. Network I/O can be particularly bothersome because of the long delays between sending a request and obtaining the response. Boost.Asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach. Boost.Asio covers timers, serial ports, files, pipes and TCP/IP networking. This month, Richard Thomson will give us an introduction to Boost.Asio concepts and asynchronous programming with this library. We'll look at how to use timers to notify our application of time passing and how to talk to serial ports asynchronously. Other Utah Cpp Programmers videos: <https://www.youtube.com/@UtahCppProgrammers> -- "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

[release] Boost 1.82.0 beta 1 released
by Marshall Clow 15 Mar '23

15 Mar '23

Boost release 1.82.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/ The SHA256 checksums are: efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 boost_1_82_0_b1.7z 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 boost_1_82_0_b1.tar.gz 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc boost_1_82_0_b1.zip edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 boost_1_82_0_b1.tar.bz2 Release notes (still need updates): https://www.boost.org/users/history/version_1_82_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

1 0

ASIO: Support for SQPOLL in io_uring backend
by Cyan Reddish 15 Mar '23

15 Mar '23

Hi. 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.

1 0

Boost Asio help
by Richard, Charles 01 Mar '23

01 Mar '23

Hi, I've been tasked with trying to figure out why we are getting an error in our log file, the error is "error: End of file". I'm still fairly new to doing real-world C++ development and I struggle with understanding why the code does what it does. The errors in our log file specifically are: 2023.02.20 08:45:49.470[UTC] [19626:140486796130176] TRACE - Process::CmdRunner::AsyncReadStdout<0x7fc594013b20> len = 0 2023.02.20 08:45:49.470[UTC] [19626:140486796130176] TRACE - Process::CmdRunner::AsyncReadStdout<0x7fc594013b20> error: End of file At a high level, my understanding is that we use Boost Asio to run python scripts where our C++ process will fork a new child process to run these python scripts. What I don't understand is why the code we have like the below was chosen to implement that functionality and to handle error handling. I've looked at some Asio boost tutorials but I still have gaps between our implementation and the Boost Asio tutorials and documentation. I'm also wondering why the a_errCode == boost::asio::error::eof is not seemingly catching the end of file. The code in the method CmdRunner::AsyncReadStdout does the following: void CmdRunner::AsyncReadStdout(boost::system::error_code a_errCode, size_t a_readSize) { DoLOG(TRACE, "Process::CmdRunner::%s<%p> len = %zu", __func__, this, a_readSize); if ( a_errCode ) { DoLOG(TRACE, "Process::CmdRunner::%s<%p> error: %s", __func__, this, a_errCode.message().c_str()) } if ( a_readSize > 0 ) { DoLOG(TRACE, "Process::CmdRunner::%s<%p> - read this: %zu bytes", __func__, this, a_readSize) _stdoutBufList.Copy(_stdoutReadBuf, a_readSize); // Call user callback to push out bytes Daemon::Service::DispatchEvent([this]() { _cbHandler(_cbCtxt, false); }); } else if ( a_errCode == boost::asio::error::eof ) { // Read done, call user callback function! DoLOG(TRACE, "Process::CmdRunner::%s<%p> - Child process (%d) STDOUT reached EOF", __func__, this, _childPid) _cmdDone = _eofStdout = true; _procStdout->close(); _procStderr->close(); Daemon::Service::DispatchEvent([this]() { _cbHandler(_cbCtxt, true); }); } else { // Async-read more, until EOF seen _procStdout->async_read_some(boost::asio::buffer(_stdoutReadBuf, PROC_READ_BUF_SIZE), [this](boost::system::error_code ec, std::size_t a_readSize) { AsyncReadStdout(ec, a_readSize); }); } } Any hints or specific links to look at to further clarify my understanding would be appreciated. Thanks! Chach Internal Use - Confidential

1 0