I have a project that goes like this: C++ -> C++/CLI wrapper -> C# app.
I have an exported class called Drawing in the C++ dll, .h contains a static std::vector<void*>, the vector is defined in the .cpp file.
The problem is that I'm getting the following errors:
Errors
C++'s native dll .lib file is linked to the wrapper, and generally the wrapper works with other stuff, but once I add the std::vector, it starts throwing linker errors.
I tried creating a function in the C++ dll that has void* as an argumument and added to the list "internally", but I still got the same errors kind of:
Errors
Any kind of help is appreciated
Answer extending my comment.
You could try to wrap the std::vector<void*> into simpler structure with functionalities you really need like following:
class YourClass
{
private:
std::vector<void*> _vec;
public:
// implement functionalities you need
void add(void* elem)
{
_vec.add(elem);
}
// etc.
};
or by inheritance:
class YourClass : public std::vector<void*>
{
public:
YourClass(int size)
: std::vector<void*>(size) {}
};
Related
Preface and the problem
I'm currently studying C++ programming language and game programming.
At the moment, I'm working on a simple game engine just to practice 'consistency' and architecture of the API, and due to this reason the idea of mimicing C# 'Program' class appeared.
C# Entry point:
class Program
{
static void Main(string[] args)
{
// Do stuff.
}
}
C++ analogue required:
class Program
{
public:
static void Main()
{
// Do stuff. 'args' analogue can be ignored, if necessary.
}
};
Is it possible to somehow, using linker options, redefine entry point to be a static class method?
Related experience and my theories on this topic
The main reason, why I think, this should be possible is described in the following piece of code (that was successfully compiled using mingw-w64).
#include <iostream>
class Main
{
public:
static void Foo() { std::cout << "Main::Foo\n"; }
};
void localFoo() { std::cout << "localFoo\n"; }
void callFunc(void(*funcToCall)())
{
funcToCall();
}
int main()
{
callFunc(localFoo);
callFunc(Main::Foo); // Proves that Main::Foo has the same interface as localFoo.
return 0;
}
(Refers to Win32 API) I abstracted Win32 API into classes and used window procedure as a static member of class. It was absolutely correct to Win32 WNDCLASS and I could even use static members of my class inside this procedure.
Conslusion I made: static fields and methods technically have no differences between global variables and functions, and, since that, they can replace some code, that dates back to C (default entry point, for example).
Notes
Both MinGW and MSVC (Visual Studio or cmd) solutions are acceptable.
The author of the post is extremely grateful for any information provided :3
Is it possible to somehow, using linker options, redefine entry point to be a static class method?
No. Not if you want to use the C++ runtime library, at any rate. main (or WinMain) is called by the runtime library once it has completed initialising itself, and that call is hard-coded in the runtime library itself.
The MSVC linker lets you specify an alternative entry point with the /ENTRY switch (see here), but if you do that you will bypass the runtime library initialisation code and that will break things.
I've been trying to come up with a means of generating a C interface for a C++17 project of mine. The project produces an executable that loads plugins on the fly. I played with clang for a while before discovering SWIG, and I'm wondering if SWIG is up to the task, or if there's a trivial amount of work that I can do to make it suitable for this scenario.
Here's my vision of the plugin interface. Suppose the source code of my program looks like this:
header.h
namespace Test {
struct TestStruct {
int Data;
};
class TestClass {
public:
virtual ~TestClass() = default;
void TestMethod(TestStruct&) const;
virtual void TestVirtual(int);
};
}
then the following code should be generated:
api.h
// opaque structs
typedef struct {} Test_TestStruct;
typedef struct {} Test_TestClass;
typedef struct {
void (*Test_TestClass_destructor)(Test_TestClass*);
void (*Test_TestClass_TestVirtual)(Test_TestClass*, int);
} Test_TestClass_vtable;
typedef struct {
Test_TestStruct *(*Test_TestStruct_construct)();
void (*Test_TestStruct_dispose)(Test_TestStruct*);
int *(*Test_TestStruct_get_Data)(Test_TestStruct*);
int *(*Test_TestStruct_set_Data)(Test_TestStruct*, int);
Test_TestClass *(*Test_TestClass_construct)();
Test_TestClass *(*Test_TestClass_construct_derived(const Test_TestClass_vtable*);
void (*Test_TestClass_dispose)(Test_TestClass*);
void (*Test_TestClass_TestMethod)(const Test_TestClass*, Test_TestStruct*);
void (*Test_TestClass_TestVirtual)(Test_TestClass*, int);
} api_interface;
api_host.h
#include "api.h"
void init_api_interface(api_interface&);
api_host.cpp
#include "header.h"
#include "api.h"
// wrapper class
class _derived_TestClass : public Test::TestClass {
public:
_derived_TestClass(const Test_TestClass_vtable &vtable) : _vtable(vtable) {
}
~_derived_TestClass() {
if (_vtable.Test_TestClass_destructor) {
_vtable.Test_TestClass_destructor(reinterpret_cast<Test_TestClass*>(this));
}
}
void TestVirtual(int v) override {
if (_vtable.Test_TestClass_TestVirtual) {
_vtable.Test_TestClass_TestVirtual(reinterpret_cast<Test_TestClass*>(this), v);
} else {
TestClass::TestVirtual(v);
}
}
private:
const Test_TestClass_vtable &_vtable;
};
// wrapper functions
Test_TestStruct *_api_Test_TestStruct_construct() {
return reinterpret_cast<Test_TestStruct*>(new TestStruct());
}
void _api_Test_TestStruct_dispose(Test_TestStruct *p) {
auto *phost = reinterpret_cast<TestStruct*>(p);
delete phost;
}
int *_api_Test_TestStruct_get_Data(Test_TestStruct *p) {
return &reinterpret_cast<TestStruct*>(p)->Data;
}
...
...
// sets the values of all function pointers
void init_api_interface(api_interface &iface) {
iface.Test_TestStruct_construct = _api_Test_TestStruct_construct;
iface.Test_TestStruct_dispose = _api_Test_TestStruct_dispose;
iface.Test_TestStruct_get_Data = _api_Test_TestStruct_get_Data;
...
...
}
When I compile the host program, I compile all these files into an executable, and call init_api_interface() to initialize the function pointers. When other people compile plugins, they only include api.h, and compile the files into a dynamic library with a certain exposed function, say init_plugin(const api_interface*). When the user loads a plugin, the host program only needs to pass a pointer to the struct to init_plugin in the dynamic library, and the plugin can set off to use all these functions.
The benefits of using such a scheme is that:
Plugins compiled using different toolchains than the host program should work fine.
The list of API functions can be extended without breaking existing plugins, as long as new function pointers are added after existing ones.
This approach allows full access to routines in the host program, while it's also easy to hide certain aspects.
It allows plugins to inherit from classes in the host program, which is kinda important for my case.
Plugin developers don't need the source of the host program.
It's convenient since the API interface doesn't need to be manually maintained.
Of course, this is just a gist of the approach and many more details need to be considered in practice.
So my questions are:
Is this kind of plugin interface good practice? Are there existing examples of this approach? Are there better solutions to this problem? Is there any critical drawbacks of this approach that I don't see?
Can SWIG accomplish this task? If not, can SWIG be modified to do so?
If SWIG must be modified, which is easier, modifying SWIG or starting from scratch using clang?
I have a struct defined in Managed.h and I would like to be able to use it inside a different project, which is unmanaged C++ (let's call it Unmanaged.h).
I tried referencing the dll, a few different #includes, but I couldn't make it work. Is there a simple way to do this ?
For information : I am quite new to C++ programming (I do C# usually), and I use Visual Studio 2015.
It would be useful to see some code and the error message that you are seeing. But as a basic example:
CLR file containing the struct. Call it MyStruct.h:
using namespace System;
namespace ManagedNameSpace {
public value struct MyStruct {
void f() {
System::Console::WriteLine("test");
}
};
}
The unmanaged class includes the CLR struct and as an explicit example I have called the object in the constructor but you can easily move this to an implementation file (Remember to include the file in the header):
#include "MyStruct.h"
class UnManagedClass {
public:
explicit UnManagedClass() {
ManagedNameSpace::MyStruct clrObj;
clrObj.f();
std::cout << "This compiles fine";
}
};
Take note that certain CLR types require marshalling. For example String will need to be marshalled. Here is an example of converting a string to LPCWSTR
LPCWSTR lpcwStr = (LPCWSTR)(Marshal::StringToHGlobalUni(clrString)).ToPointer()
I use a native C++ code base from C#, with a C++/CLI wrapper built around it (with Visual Studio 2013). There are two projects:
NativeCodeBase: simple C++ project set to be built into a static lib.
ManagedWrapper: C++/CLI project referencing NativeCodeBase.
I have the following native "interface" in NativeCodeBase:
class ITest {
virtual void Foo(const std::string& str, MyEnum me) = 0;
}
For which I have a native implementation in the ManagedWrapper project.
In the header:
class TestManaged : public ITest {
virtual void Foo(const std::string& str, MyEnum me) override;
}
In the cpp:
void TestManaged::Foo(const std::string& str, MyEnum me) {
int length = str.length();
}
The MyEnum enum is used both in native and managed code, so in its implementation I use a conditionally compiled C++/CLI extension, to make it usable from C#:
#ifdef _MANAGED
public
#endif
enum class MyEnum : unsigned char
{
Baz = 0,
Qux = 1
};
In my native code I have a reference to ITest and call its Foo function with a local std::string variable. When Foo is called, I can see in the debugger that the string passed as an argument is a valid string object.
The call is similar to this:
void Bar(ITest& test) {
std::string str = "test";
test.Foo(str, MyEnum::Baz);
}
However, if I put a breakpoint at the beginning of TestManaged::Foo, the debugger says that str has <undefined value>, and the length() call crashes with undefined reference error in the <xstring> header in the following function:
size_type length() const _NOEXCEPT
{ // return length of sequence
return (this->_Mysize);
}
The debugger displays <undefined value> for the this pointer as well.
What can be the reason for this? References somehow get corrupted when passed between the two libraries?
(Additional info: I used not to build the NativeCodeBase project as a separate lib, but linked all the source files from it into the CLI project, and the same code base worked without any problem. It started failing since I configured it to be built into a separate lib and added a reference in the CLI project to the native one.)
The problem wasn't with the reference itself. The problem was with the second enum parameter. The implementation of the enum class looked like this:
#ifdef _MANAGED
public
#endif
enum class MyEnum : unsigned char
{
Baz = 0,
Qux = 1
};
The #ifdef directive was put there in order to create a native enum when built for native C++, but create a CLI enum when built for C++/CLI.
This worked well when all the source files were linked to the CLI project and every piece of source was built again for the CLI project. However, this approach does not work any more when I want to use the native lib from the CLI side.
I guess the problem was that the same header was built differently in the two libraries, so the caller and the calle saw a different binary interface of the object, thus the arguments got garbled when passed. Is this correct?
I got rid of the conditionally compiled public keyword and it started working properly again.
Prior to refactoring my previous question, which I believe was a little bit off...
The title pretty much asks my question.
How can I keep a class definition on it's own without giving it methods & producing the error below?
The reason for this is because I want to create an object in a separate DLL (which contains the methods), but only return a reference pointer to my main program.
This is explicit exporting by the way.
Error 1 error LNK2001: unresolved external symbol "public: int
__thiscall ObjTest::getValue(void)" (?getValue#ObjTest##QAEHXZ)
class ObjTest
{
private:
int x;
public:
int getValue();
};
Since you need to load the .dll with LoadLibrary(), you can expose a pure virtual class, and have the .dll return a sub class of it:
You separate them in two files:
File ObjTest.h:
class ObjTest
{
public:
virtual int getValue() = 0;
};
ObjTest *CreateObjTest();
File ObjTest.cpp:
#include "ObjTest.h"
class ObjTestImpl : public ObjTest
{
int x;
public:
virtual int getValue();
};
int ObjTestImpl::getValue()
{
return x;
}
ObjTest *CreateObjTest()
{
return new ObjTestImpl();
}
You compile ObjTest.cpp and create a .dll out of it. Your main executable program will need to LoadLibrary() your .dll, use GetProcAddress() to extract the CreateObjTest as a function pointer and call it to return a new ObjTest .
(You might have to create a DeleteObjTest() function too - if your main executable and .dll end up with a different CRT, they'll have different heaps, so you need to call into the .dll instead of just doing delete myObj.)
The other approach is to wrap everying in a C API, and just pass opaque handles to C functions across the .dll instead of dealing with C++ objects.
You are confusing definition and implementation. You have the method defined but not implemented. Hence, the compiler compiles the code without error, as the method is defined, the linker creates an error as there is no implementation for the method (undefined symbol).
The DevStudio compiler does let you import classes from DLLs into an application:-
class __declspec (dllimport) ClassName
{
// members, etc
}
and in the DLL source, change the 'dllimport' to 'dllexport'.
See this MSDN article for more information.
If you want to hide the data members and the private methods then you'd need to look into the pimpl idiom.