Error C2711 building DLL from a C++ project that uses tbb - c++

I'm trying to build some dll to wrap some Computer Vision methods in a c++ software to use them a c# software, and I need to call some tbb (Threading Building Blocks) methods from the c++ methods to process some frame. I'm developing in CLR using Charset Unicode, in visual studio, and once I call the tbb header
#include <tbb/tbb.h>
The compiler give me the error:
error C2711: 'tbb::internal::concurrent_vector_base_v3::concurrent_vector_base_v3' try use #pragma unmanaged;
I've correctly imported and linked libraries and headers files, and the required dlls.
I've looked for some helps on Intel's forums but I found nothing.

This sounds like you're trying to build an application using CLR, but it doesn't like some of the code in tbb's header. Error C2711 happens when trying to compile code as managed that it is unable to manage (for example, using inline assembly).
If you don't need CLR, you should just be able to disable it (remove /clr) -- which should fix this warning. Otherwise, you can use #pragma unmanaged as recommended in the warning to disable it -- I'm guessing before the inclusion of the tbb/tbb.h header. Something like:
#pragma managed(push, off)
#include <tbb/tbb.h>
#pragma managed(pop)
This should tell the project that any code in tbb.h (such as potentially inline functions that use assembly) should not emit IL.
Possibly related are some answers to this question which describes how interfacing with native code in CLR projects is commonly done

Related

C++/CLI usage with unmanaged code - Boost, <future>

I am trying to compile a C++ library for use with C# on Windows (the library is Vanetza).
The library uses CMake, I am building from Microsoft Visual Studio Community 2022 (64-bit). I can build the library as shared DLL no problem. For use with C#, I thought of compiling the library as C++/CLI (common language runtime support enabled). At first, I could not compile it because the project uses Boost, but some compilation issues were solved by surrounding every Boost include with #pragma managed(push, off) and #pragma managed(pop).
Issue which blocks me now is that <future> header cannot be used with C++/CLI - I am getting this compilation error from lot of different places:
Severity Code Description Project File Line Suppression State
Error C1189 #error: <future> is not supported when compiling with /clr or /clr:pure. geonet C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\future 13
and I cannot solve this. I think that some Boost module that is used needs this header.
Is there any solution to this or is there another approach that could be used?
I need not only to get to some C++ functions of the library, but also to use some of its classes and to see some of its structures.
I tried compiling the library as normal C++ and then make an interfacing C++/CLI library which would be called from C#, but the header is again used somewhere.
I think that using P/Invoke (DLLImport) is impractical for me as it is only making possible to use C/C++ functions, but for classes and structures it cannot be used (as I understand it).
Is only possible solution to rewrite the parts that need <future> myself using C# constructs as mentioned in this question?
As per other similar questions, it seems that sometimes the project can be built such that Boost works without any problems and sometimes major code rewrite is needed. Could someone recommend me what would a usable approach would be in my case? I could use older Boost version (namely 1.58.0), but I do not know if it would help.
Write a class in c++/cli that connects to your C++ code. The code will call the router which I presume will return a future. Then in manged/cli you create a task that hooks up to that future. So you have the original code compile to a static C++ lib and link that into your managed C++/cli dll

How to get error.h in visual studio or equivalent?

I have large C++ project that I inherited and am trying to transfer it from Linux to Visual Studio on Windows. Managed to link required libraries, but one build error just baffles me.
In Linux, someone was including a header <error.h> everywhere, and I can't even find a documentation page to see what it is. First I thought is part of standard library, but I am now beginning to see it's a specific header for Linux OS.
So, how do I include it in Visual studio? I can't even find what it is and am tempted to just rearrange code to use stdexcept header, as the only thing these codes do is abort compilation and printout error messages by using some error(...) function from error.h.
error.h is a header from the GNU C Library. It is not specific to Linux, it is specific to glibc.
It is documented right here (search on the page for error.h).
The functions declared in error.h should not be used in portable code, so getting rid of code that uses them is not a bad idea. Alternatively, it is not difficult to implement them.

How to implement a unmanaged thread-safe collection when I get this error: <mutex> is not supported when compiling with /clr

I have a C++ application which consists of unmanaged C++, managed C++ and c#. In the unmanaged part I'm trying to create a thread safe collection using std::mutex.
However when I use the mutex I get the following error;
error C1189: #error : <mutex> is not supported when compiling with /clr or /clr:pure.
Any idea why I can't use the mutex?
Can someone recommend a replacement for it so that I can create a thread-safe unmanaged collection?
It is not supported because the std::mutex implementation uses GetCurrentThreadId(). That's a winapi function that is not supposed to be use in managed code since it might be running on a custom CLR host that doesn't use threads to implement threading.
This is the good kind of problem to have, it shows that you are building your code wrong. Your native C++ is being compiled with /clr in effect. Which works rather too well, all C++03 compliant code can be compiled to MSIL and get just-in-time compiled at runtime, just like managed code. You don't want this to happen, your native C++ code should be compiled to machine code and get the compile-time code optimizer love.
Turn off the /clr option for this source code file, and possibly others, in your project. Right-click + Properties, General. If the mutex appears in the .h file that you have to #include in a C++/CLI source file then you have a bigger problem, use an interface or pimpl to hide implementation details.

Are there cases when code is compiled with Visual C++ but Visual C++ runtime is not available?

I need to make changes to some (very) cross-platform code and add calls to _CrtSetDbgFlag() function that is implemented in Visual C++ runtime. Obviously the function is only available when the code is being compiled against Visual C++ runtime headers.
I want to use _MSC_VER macro to conditionally include those calls.
#ifdef _MSC_VER
_CrtSetDbgFlag(value);
#endif
Now is there any reasonable configuration under which this wouldn't compile? Maybe I can use Visual C++ to compile code against some runtime other than Visual C++?
Is it possible that code is compiled with Visual C++ so that _MSC_VER is defined, but Visual C++ runtime debugging stuff is not available during compilation?
In theory, yes.
If the program is compiled (by MSVC) using dynamic runtime library (e.g., MSVCRTxx.DLL) AND the runtime DLL has been modified for any reason (patching, instrumentation, hook, etc), then some APIs may not work properly. The program would mostly crash. But, I don't think this is a common case.
So, if you're really concerned about this issue, you'd better compile and link this code statically (See /MT compiler option). This will guarantee the correct implementation of _CrtSetDbgFlag to be embedded in a binary.

Windows library inclusion in CMake Project

I have a growing project in CMake. It is time to link to a library, which at this time exists only in Windows, Linux functionality will have to wait. I am attempting to do this with preprocessor directives as recommended in an answer to this question:
// MyLibHeader.hpp
#ifdef WIN32
#include <windows.h>
#define ProcHandle HINSTANCE
#define LoadLib LoadLibraryA
#define LoadSym GetProcAddress
#else
// ... I'll fill these in with dlopen etc. when necessary
This is the first platform specific inclusion I have had to put in my code, and It seems there is more to it than this. This is generating this error:
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\include\intrin.h(944) : error C2733: second C linkage of overloaded function '_interlockedbittestandset' not allowed
The error is repeated four times, twice in intrin.h, and twice in winnt.h. So here's my question. Are there other includes or preprocessor steps I need to take to get this to work inside windows (up to now it has been a basic console application) and is there something in CMake I can leverage to make this easier.
From what I've been able to scrape up with some help and some google, one solution is indeed to comment out the duplicate definitions of _interlockedbittestandset in initrin.h
This may have been fixed in later versions of Visual Studio.
You could look at the source code of CMake, there is a C++ class that does cross platform library loading. It is a BSD style license so you could just copy the code. Works on lots of platforms. The code is here:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/kwsys/DynamicLoader.cxx;h=c4ee095519fe27742a0a9a9e392be4ce095af423;hb=HEAD