boost.future causing problems with clr - c++

I am using visual studio 2012 with a clr library that needs to link to a native library.
My library which is using boost::future.
I am having this problem when I use future::then(F &&) function against the managed project:
Error 910 error LNK2022: metadata operation failed (8013119F) : A TypeRef exists which should, but does not, have a corresponding TypeDef: (dummy): (0x0100003e). D:\ClrProject\somefile.obj
I tried, as suggested in other questions, to make the dummy types in the library complete, since I cannot forward declare a nested struct from inside a template, as can be done with boost::thread::dummy struct.
This did not solve the problem.
My setup is the following:
Boost 1.55.
Using boost .dlls.
define BOOST_RESULT_OF_USE_DECLTYPE
define BOOST_THREAD_PROVIDES_FUTURE
define BOOST_THREAD_PROVIDES_FUTURE_CONTINUATION
I am using these very defines on the dependent .dll as well, to make sure that all parts of the API are exposed correctly.

Solved.
#Hans Passant your suggestion was right. I just wasn't putting the #pragma the correct way.
I had to put the pragmas so that my headers are compiled as unmanaged code. Once that was done, it seems that template instantiations for my code were emitted as unmanaged. At that point, problems disappeared.
So what I did is something like this:
#pragma managed(push, off)
#include "MyHeaderWithFutures.h"
#pragma managed(pop)
void f() {
//
f = myObject.Something().then(...);
}

Related

OpenCASCADE 7.6.0 not compiling with a .NET 6.0 class library with Visual Studio 2022 (Windows 10)

Steps to reproduce:
Install a version of Visual Studio (I used VS Community 2022). Install OpenCASCADE 7.6.0.
Create a C++ .NET CLR project using Visual Studio 2022 targeting .net6.0.
Change settings to include OpenCASCADE header and library files.
Edit the main header by replacing the code within it with below:
#pragma once
//for OCC graphic
#include <OpenGl_GraphicDriver.hxx>
//wrapper of pure C++ classes to ref classes
#include <NCollection_Haft.h>
namespace ClrClsLibDotNetCoreMwe {
public ref class Class1
{
// TODO: Add your methods for this class here.
};
}
Attempt to build.
Issue: The build fails with the following complain:
1>C:\OpenCASCADE-7.6.0-vc14-64\opencascade-7.6.0\inc\NCollection_DefaultHasher.hxx(34,1): error C2872: 'HashCode': ambiguous symbol
1>C:\OpenCASCADE-7.6.0-vc14-64\opencascade-7.6.0\inc\NCollection_DefaultHasher.hxx(34,1): message : could be 'HashCode'
1>C:\OpenCASCADE-7.6.0-vc14-64\opencascade-7.6.0\inc\NCollection_DefaultHasher.hxx(34,1): message : or 'System::HashCode'
What fixes the problem:
Either Targeting .NET Framework instead of .NET Core (/clr instead of /clr:netcore).
Or removing one of the headers.
Please see if there is a way where I can keep both the headers and target .NET Core?
I have looked around for a possible solution before posting this question here. A promising solution was to disable implicit usings. However, that didn't pan out.
I had the same problem.
In my case, the "using namespace System;" included in the header file. The text caused the problem.
Thanks!

"#using" requires C++/CLI mode

My code starts off like this:
#include "stdafx.h"
#include <string>
#using <mscorlib.dll>
#using <System.Data.dll>
#using <System.dll>
using namespace System;
using namespace System::Data::OleDb;
but ends up with the compile error "#using" requires C++/CLI mode
I had this problem initially and managed to solve this through following this post IntelliSense: "#using" requires C++/CLI to be enabled. Updated VS2017 to ver 15.3.0 yesterday and now it is broken again. Project Properties are as follows:
Any assistance would be greatly appreciated.
P.
I came across the same issue and figured out that the settings(Common Language Runtime Support) were set only for Release configuration. I suggest you to check for all the configurations in your solutions Release/Debug etc.. and set the CLR support option and it should work as expected.
You can also control this setting from within the code by putting this in your files
#pragma managed
First I would search your code to be sure this #pragma isn't being used to turn OFF managed building somewhere earlier (in some #include file, perhaps?). Then try putting it in this file>
I'm not sure if this will solve your problem but it should at least eliminate the worry that the file is not being build properly. And perhaps the error message might change to give you a better idea what the problem is
https://msdn.microsoft.com/en-us/library/0adb9zxe.aspx?f=255&MSPPError=-2147217396
C++ CLI Correct way to use #pragma managed / unmanaged

How to detect declaration of class at compile-time?

I'm use some 3-rd party library at my project. After updating to new version of library I'm faced with errors.
One my class have method
virtual RTSPServer::RTSPClientSession* createNewClientSession(u_int32_t sessionId)override;
but in new version of library declaration of RTSPClientSession was moved into another class and renamed. Now correct name is
GenericMediaServer::ClientSession
I need a code which will be correctly compiles with all versions of library.
At gcc I use following code:
#ifdef RTSPServer::RTSPClientSession
using ClientSessionClass = RTSPServer::RTSPClientSession;
#else
using ClientSessionClass = GenericMediaServer::ClientSession;
#endif
class A
{
.........
virtual ClientSessionClass* createNewClientSession(u_int32_t sessionId)override;
};
but this not work in MSVC 2010.
How I can detect which declaration I should use?
UPD: code for gcc also don't work for old version of library :(
"How I can detect which declaration I should use?"
You need to introduce some discriminator for the library version you're using with your current build configuration:
#ifdef OLD_LIBRARY_VERSION // Maybe the binding headers have some information like this.
// If not you have to select this manually, and provide the
// setting with your project configuration.
using ClientSessionClass = RTSPServer::RTSPClientSession;
#else
using ClientSessionClass = GenericMediaServer::ClientSession;
#endif

Qt shared_ptr not found when including a library

I'm using Qt creator and the yaml-cpp library. I placed yaml-cpp under my source code directory and added it to the Qt project's include path like so:
INCLUDEPATH += Crypto \
Yaml
QMAKE_CXXFLAGS += -std=gnu++0x
DEFINES += __GXX_EXPERIMENTAL_CXX0X__
As you can see, I also told it to use C++ 11 because that is a requirement of this library. However, I get this error on compiling my project (this is the only error):
../ProjectName/Yaml/yaml-cpp/node/ptr.h:11:10: fatal error: 'boost/shared_ptr.hpp' file not found
#include <boost/shared_ptr.hpp>
^
I also tried, at the advice of some online resources, to replace it with #include <memory>, but this does not work. When I try this, it still cannot find shared_ptr.
I probably could compile the library and link Qt creator to it, but I would have to do this on every platform I use and on every machine that every project developer uses. It seems like a more elegant solution to put the source code inside my GitHub directory and compile it along with the project to minimize the overhead of someone compiling the project on their machine, particularly since this is an open source project.
Here is the source code of Yaml-Cpp's file in question:
#include "yaml-cpp/dll.h"
#include <boost/shared_ptr.hpp>
namespace YAML
{
namespace detail {
class node;
class node_ref;
class node_data;
class memory;
class memory_holder;
typedef boost::shared_ptr<node> shared_node;
typedef boost::shared_ptr<node_ref> shared_node_ref;
typedef boost::shared_ptr<node_data> shared_node_data;
typedef boost::shared_ptr<memory_holder> shared_memory_holder;
typedef boost::shared_ptr<memory> shared_memory;
}
}
It seems that you do not have boost installed. You would need to amend that first.
However, you could urge the yaml-cop developers to use the recent C++ standard more and more when their software is built using C++11 or later. C++11 is not a new thing anymore. It should be utilized as much as possible.

Boost build error with websocketpp and MySQL on Windows

I am trying to build a C++ app that uses both websocketpp and MySQL. I have encountered 2 build problems using VS 2010 C++ Express.
1) A problem with the boost libraries. It produces many errors like this:
1>c:\program files (x86)\boost\boost_1_50\boost\thread\win32\thread_data.hpp(210): error C2146: syntax error : missing ')' before identifier 'rel_time'
Here's the relevant snippet from thread_data.hpp starting with line 210:
inline BOOST_SYMBOL_VISIBLE void sleep(TimeDuration const& rel_time)
{
interruptible_wait(detail::pin_to_zero(rel_time.total_milliseconds()));
}
2) A conflict with the word VERSION which is documented here and I believe is independent.
To make a clear and simple example of the boost build problems, I'm using the websocketpp example: echo_server.cpp to which I added these includes:
#include "stdafx.h"
Boost lib includes recommended by "Building a program with websocketpp" on the websocketpp site.
#include <boost/regex.hpp>
#include <boost/random.hpp>
#include <boost/system/api_config.hpp>
#include <boost/system/config.hpp>
#include <boost/system/error_code.hpp>
#include <boost/system/system_error.hpp>
#include <boost/system/windows_error.hpp>
and the MySQL header includes. Adding these 2 boostincludes triggers the build errors. If I comment out these 2 includes, it builds without errors:
#include <my_global.h>
#include <mysql.h>
Any suggestions on how to deal with the boost problems?
I don't think this is the same build problem as this one, "Trying to build websocket++ with MinGW: last few linker errors — what could it be?"
Concerning the first error, check if there are any macros interfering with the code. Right-click and go to definition or #define the macro yourself at the beginning of the file and see where it gets redefined. In really hard cases, look at the preprocessor output via a compiler flag.
Concerning the rest, you don't provide any versions for Boost and MySQL. Then, there is my_global.h (or is that part of MySQL?) and stdafx.h, which are both under your control but you don't show them here. Also, try to reduce the issue to the smallest possible piece of code. In short, provide a reproducible example.