Re: Cannot compile Boost JSON under Visual Studio 2022 with /clr

From: Gavin Lambert (boost_at_[hidden])
Date: 2023-04-05 00:57:19

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.