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.
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
