Re: [Boost-users] boost::asio from C++ Forms App in VS 2010

Subject: Re: [Boost-users] boost::asio from C++ Forms App in VS 2010
From: Bill Buklis (boostusr_at_[hidden])
Date: 2011-03-01 13:09:14

>> You are probably misunderstanding the situation. The OP is using
>> C++/CLI, the Microsoft C++ dialect used for gluing C and C++ code to the
>> managed world. He is not using the usual native C++ projects, which are _very_
>> well supported by Boost.
>>
>> Most of Boost (thread, asio, shared_ptr, heck - most of it) does not build or
>> work cleanly under C++/CLI. I guess that it's implicitly assumed to be known that
>> C++/CLI isn't C++, and shouldn't be expected to compile most of modern C++
>> code, particularly not something as workaround-happy as Boost.
> FWIW It's not quite as bad as you are painting.
>
> The large Boost.Math  library *does* compile,
> and compiles under managed C++/CLI to build a Boost.Math dll.
>
> A .Net project in C# and using VS net framework links with the Boost.Math dll to provide the windows display feature for a Statistical Distribution Explorer Windows utility (so you can look up students_ts etc to your heart's content).
>
> To my surprise, /CLI worked without any trouble at all did what it said on the tin.
>
> But other Boost libraries may well not work at all with /CLI.
>

I would expect that most if not all Boost libraries should work just 
fine in a mixed-mode (a.k.a managed + native) C++/CLI application. The 
key thing is to have a clear separation between the managed functions 
and the native functions. If all of the Boost uses are within the native 
sections and only work with native types, there should be no issue 
whatsoever. You just have to be careful of not calling boost functions 
with manage types. That probably won't work.

That being said, however, there is some STL support for managed 
types/code. It's quite possible that anything that is compatible with 
managed STL may be compatible with similar boost functions. The key word 
here is "maybe".

But, like I said - Boost within native functions should be just fine 
regardless if the app is managed.

-- Bill --