On Mon, Feb 28, 2011 at 09:01:18AM -0800, Dave wrote:
On 2/28/2011 5:03 AM, Juraj Ivančić wrote:
The problem is that Boost.Asio is not designed to be used MS C++ managed code. It will work with a regular C++ compiler (i.e. cl.exe). I'm out on a limb here as I do not know much about MS managed C++, but ASIO (which strives to be portable C++ networking library) really does not seem to be the tool for the job in such environment, even in case this is possible. If I were you I'd consider replacing ASIO with a more appropriate framework (.NET?) for this platform.
If you are using Asio for asynchronous networking, I would recommend using System::Net::Sockets (from the .NET framework) which offer two kinds of async interfaces, both Begin/End pairs of functions that mirror the async_recv/async_send/async_whatever of Asio, and another set that is more fire-and-forget.
I don't think this is correct.
I have compiled and run a good portion of the sample ASIO code using Visual Studio without any problems.
I am successfully using ASIO in my own code which is compiling under Visual Studio.
If ASIO is really an inappropriate tool to be using under Visual Studio, I would like to know so that I don't run into some showstopper problem down the line. However, if that is the case, it should be stated loud and clear in the documentation so that people like me and Alan Vella don't make the mistake of using the wrong tool. A compile error would be nice as well.
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. Yet again, the C++/CLI language is only really intended as a bridge for wrapping native libraries or writing simple pieces of native code for use in managed projects. The language is a bit of a chimaera, with rather segregated managed and unmanaged types, with helpful types like gc_ptr and gc_new to manipulate managed types from unmanaged code. Even _if_ you could use Bind/Thread/Asio/etc. well there, you wouldn't be able to use them with any type that has been remotely tainted by managed types. That would mean no binding of callbacks into managed objects, no managed thread procedures, very little instantiation of any unmanaged class or function templates with managed types, and so on. It's a horribly scary place to be, so I understand why it is might not be considered worth supporting as a Boost library author.
Are there unit tests for Asio? Have they been run on the Visual Studio platforms? Is there a record of this online somewhere?
The test suite results for all platforms where there are test runners can be seen on the Boost developers site, at [1]. [1] http://www.boost.org/development/testing.html -- Lars Viklund | zao@acc.umu.se