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.