boost::asio from C++ Forms App in VS 2010
Hi all, I'm trying to port a C++ project from gcc (on MinGW) to Visual Studio 2010 inside a Visual C++ Windows Forms application. The code was originally written on a Windows XP 32-bit machine. Now it is being ported into a Windows 7 32-bit machine. This project uses quite a few boost libraries, including the boost::asio library. When I try to compile the code in VS2010 I get the following errors: 1> Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For example: 1> - add -D_WIN32_WINNT=0x0501 to the compiler command line; or 1> - add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions. 1> Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target). 1>C:\Program Files\boost\boost_1_44\boost/asio/detail/impl/win_thread.ipp(52): error C2664: 'QueueUserAPC' : cannot convert parameter 1 from 'void (__stdcall *)(ULONG_PTR)' to 'PAPCFUNC' 1> Address of a function yields __clrcall calling convention in /clr:pure and /clr:safe; consider using __clrcall in target type 1>C:\Program Files\boost\boost_1_44\boost/asio/detail/impl/win_thread.ipp(82): error C2664: '_beginthreadex' : cannot convert parameter 3 from 'unsigned int (__stdcall *)(void *)' to 'unsigned int (__stdcall *)(void *)' 1> Address of a function yields __clrcall calling convention in /clr:pure and /clr:safe; consider using __clrcall in target type 1>C:\Program Files\boost\boost_1_44\boost/asio/detail/win_thread.hpp(31): error C3641: 'boost::asio::detail::win_thread_function' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe 1>C:\Program Files\boost\boost_1_44\boost/asio/detail/win_thread.hpp(36): error C3641: 'boost::asio::detail::apc_function' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe 1>C:\Program Files\boost\boost_1_44\boost/asio/detail/win_fenced_block.hpp(35): error C3862: 'boost::asio::detail::win_fenced_block::win_fenced_block': cannot compile an unmanaged function with /clr:pure or /clr:safe 1> Inline native assembly not supported in managed code 1>C:\Program Files\boost\boost_1_44\boost/asio/detail/win_fenced_block.hpp(35): error C3645: 'boost::asio::detail::win_fenced_block::win_fenced_block' : __clrcall cannot be used on functions compiled to native code 1>C:\Program Files\boost\boost_1_44\boost/asio/detail/win_fenced_block.hpp(54): error C3862: 'boost::asio::detail::win_fenced_block::~win_fenced_block': cannot compile an unmanaged function with /clr:pure or /clr:safe 1> Inline native assembly not supported in managed code 1>C:\Program Files\boost\boost_1_44\boost/asio/detail/win_fenced_block.hpp(54): error C3645: 'boost::asio::detail::win_fenced_block::~win_fenced_block' : __clrcall cannot be used on functions compiled to native code 1> 1>Build FAILED. Any help would be much appreciated. Cheers, Alan Vella. _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com
On 2/25/2011 3:18 PM, Alan Vella wrote:
Hi all,
I'm trying to port a C++ project from gcc (on MinGW) to Visual Studio 2010 inside a Visual C++ Windows Forms application. The code was originally written on a Windows XP 32-bit machine. Now it is being ported into a Windows 7 32-bit machine. This project uses quite a few boost libraries, including the boost::asio library. When I try to compile the code in VS2010 I get the following errors:
If it's an option, you might try VS2008. I've had boost related compile failures on VS2010 with code that compiles and runs fine on VS2008.
On 26.2.2011 0:18, Alan Vella wrote:
I'm trying to port a C++ project from gcc (on MinGW) to Visual Studio 2010 inside a Visual C++ Windows Forms application. The code was originally written on a Windows XP 32-bit machine. Now it is being ported into a Windows 7 32-bit machine. This project uses quite a few boost libraries, including the boost::asio library. When I try to compile the code in VS2010 I get the following errors:
<snip error messages>
1>Build FAILED.
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. HTH
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.
HTH
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. Are there unit tests for Asio? Have they been run on the Visual Studio platforms? Is there a record of this online somewhere? - Dave
Dave
Are there unit tests for Asio? Have they been run on the Visual Studio platforms? Is there a record of this online somewhere?
The Asio regression tests are run on several versions of Visual Studio -> results on line @ http://www.boost.org/development/tests/trunk/developer/asio.html However, all those results are from native C++, not managed code, so the results may be different there.
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
On 2/28/2011 10:30 AM, Lars Viklund wrote:
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.
Yes, my misunderstanding. I had never heard of managed c++ before now.
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Lars Viklund Sent: Monday, February 28, 2011 6:30 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] boost::asio from C++ Forms App in VS 2010
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. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
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 --
On 28.2.2011 18:01, 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.
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.
I'm sorry for being unclear - I never intended to say that ASIO does not work with Visual Studio. On the contrary, I have been using it with VS to my great pleasure for several years. I only stated that it is not designed to be used with what I called 'MS managed C++' i.e. an interpreted C++ wannabe. As I stated - I know little about this language, but I have learned a bit from a very nicely explained reply by Lars Viklund.
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.
How are you planning on melding the windows forms event loop and the asio work queue? That's what I would see as the main challenge. For example, when an asio timeout fires, how would you get an event callback in the forms code? Run two threads and post a message to a threadsafe queue? Or Is there a windows handle you can access from asio to add it to the forms event loop? Best wishes, Matthew
participants (8)
-
Alan Vella -
Bill Buklis -
Dave -
Juraj Ivančić -
Lars Viklund -
Matthew Herrmann -
Paul A. Bristow -
Richard Webb