I jave the following interface that must be implemented by a set of DLL libraries I want to dynamically import later:
class ToolboxInterface {
public:
struct ToolboxInfo {
std::string name;
};
virtual void process() = 0;
virtual void clear() = 0;
};
I want to dynamically load the DLL's as in here, and for that reason I have to force this interface to all my DLLs, as a way of being sure I can use GetProcAddress in all DLL's.
What is the best way of forcing this interface into a DLL project? SHould I not use a class and use some other strategy instead? Or how can I use the class interface?
Related
I am trying to create a multi-platform library in C++ for use by C++ consumer applications. Call my library A. I want to ship a dynamic library file per target platform, and a header file (call this export.h) that the consumer app could use to compile and execute. My library depends on a third-party open-source library, written in c, which is difficult to link to correctly; call this library B.
In order to save my consumers the pains of linking to B, I want to abstract every call to it so that the consumer need not even have a single header file from B. Consumer app (C) should be able to compile with only A.dll, B.dll and export.h; and run with only A.dll and B.dll as dependencies (substituting the platform-specific suffix for a shared library as needed).
B defines a great many types, mostly structs. (B is not written in objective c, although it probably should have been.) Part of A's job is to produce classes that contain and manage groups of structs around logical lines, which are readily apparent. C needs to call functions belonging to classes in A, so the function prototypes need to be in export.h, but the B types cannot be in export.h or else C will need to include headers from B.
Is there a syntax that lets me define the public members of a class (in A) without also defining all the private members?
Obviously, there are no public members in A that rely on types from B. The closest thing I've found so far is this question. Opaque pointers may be part of the solution, but C needs access to functions of classes in A. I really don't want to write a helper function for every public A class member, though that would probably work. Any ideas?
Edit: As requested, explanation code.
Worker.h:
#include <SomeThirdPartyLib.h>
class Worker {
public:
Worker();
~Worker();
void DoWork();
private:
Truck t;
}
SomeThirdPartyLib.h:
typedef struct TruckS {
char data[200];
char* location;
} Truck;
Worker.cpp:
#include "worker.h"
Worker::Worker() {}
Worker::~Worker() {}
Worker::DoWork() {
t.location = "Work";
}
main.cpp:
#include <export.h>
int main(int argc, char** argv) {
Worker w();
w.DoWork();
}
Now I'm looking for the syntax to put in export.h that would allow this external application to be compiled using that header and my dll, but without requiring access to SomeThirdPartyLib.h.
Here is a technique that may be close to what you want to achieve.
You can define an interface that relies only on public interfaces from A, and therefore lacks any dependency on B. The interface class includes a factory. This interface would be part of the header file for your library.
class Interface {
public:
virtual void foo () = 0;
virtual void bar () = 0;
static std::unique_ptr<Interface> make ();
virtual ~Interface () = default;
};
In a source file of your library, you would include header files for both A and B, and create an implementation of the interface as well as a definition of the factory.
class Implementation : public Interface {
//...
};
std::unique_ptr<Interface>
Interface::make () {
return std::make_unique<Implementation>();
}
So, users of your library get access to the interface, and can call the public methods without any knowledge of private members or private methods.
Try it online!
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) {}
};
Everytime I look at plugin's tutorial, they look incredibly complex for the (conceptually) simple thing I'd like to do.
Let's say we are on Windows and I want to create a program with an interface, which I'd like to use to implement plugins as dynamic external libraries (dll).
So I have a header like this :
Interface.h:
class Interface
{
public:
virtual void overrideMe() = 0;
};
Which I use from another code (the plugin), so that I can create a DLL:
MyPlugin.cpp
#include "Interface.h"
class MyPlugin: public Interface
{
public:
void overrideMe()
{
std::cout << "Hey, I am a specific MyPlugin DLL!" << std::endl;
}
};
// DLL creation code blabla
So imagine I create from this code a library named MyPlugin.dll
Now I'd like to use the Interface in a generic program, but not by including headers and using traditionnal polymorphism, but by dynamically calling/loading/charging it from my dll :
MyProgram.cpp:
#include "Interface.h"
int main()
{
// Interface* i = new MyPlugin; // nope!
Interface* i = chargeMe("MyPlugin.dll"); // How to do this?
i->overrideMe(); // display: "Hey, I am a specific MyPlugin DLL!"
}
Now the questions are:
What is the simplest way to do it using C++?
Is there any fuction like chargeMe("MyPlugin.dll") in the real world?
Do I necessarily need an external framework (like Qt) to do so or can the standard be enough?
I am currently working on a project that uses a DLL and an application that uses the DLL. The DLL is exported as an abstract base class header and a concrete implementation derived from the abstract base, as usual:
---- TaskInterface.h ----
class Task {
public:
virtual int func1(void) = 0;
virtual int func2(void) = 0;
};
extern "C" __declspec(dllexport) Task * APIENTRY newTask();
--- Task.h ---
class TaskImpl : public Task
{
public:
virtual int func1(void);
virtual int func2(void):
};
Task * APIENTRY newTask()
{
return static_cast<Task*>( new TaskImpl );
}
--- Task.cpp ---
int TaskImpl::func1(void)
{
// ...
}
int TaskImpl::func2(void)
{
// ...
}
This works so far as intended, the application includes "AbstractTask.h" and then calls the respective function defined by class TaskImpl:
--- TheApplication.cpp ---
Task aTask = newTask();
aTask->func1();
aTask->func2();
// ...
However, now the Application discovers that what the default implementation in class TaskImpl does is not enough and therfore defines within its own scope a new derived class, like so:
--- AppImpl.h ---
#include "TaskInterface.h"
class AppImpl : public Task
{
int func1(void) = { /* new stuff */ }
int func2(void) = { /* new stuff */ }
};
and then defines in TheApplication.cpp:
--- TheApplication.cpp ---
#include "AppImpl.h"
ApplImp * aNewTask = static_cast<Task*>(newTask());
aNewTask->func1();
aNewTask->func2();
In what context do you think func1() and func2() are called? Correct: It's still the concrete implementation inside the DLL class TaskImpl and not the derivates defined by class AppImpl.
And basically this is my problem: I want to use a default implementation from inside a DLL, but I want to be able to expand it on the Application side, so unless I have explicitly overriden a function in ApplImp.h, I fall back to the one defined in TaskImpl inside the DLL.
Is this possible? If so, what am I doing wrong? If not, how could I accomplish something equivalent?
I already toyed with exporting both "TaskInterface.h" and "Task.h" and then have ApplImp.h include the concrete class in the DLL, but the compile doesn't like that for obvious reasons => can't export newTask() twice.
Any help is appreciated!
As you need to allocate and deallocate via the DLL anyway, I'd suggest providing a wrapper class alongside the DLL. This wrapper class then could be designed to be inherited from.
class Task {
public:
virtual int func1(void) = 0;
virtual int func2(void) = 0;
};
// v~~~~v probably dllimport in the header you ship
extern "C" __declspec(dllexport) Task * APIENTRY newTask();
class TaskWrapper {
public:
TaskWrapper() : m_ptr( newTask() ) {}
virtual ~TaskWrapper() { deleteTask(m_ptr); }
virtual int func1(void) { m_ptr->func1(); }
virtual int func2(void) { m_ptr->func2(); }
protected: // implementation omitted for brevity
TaskWrapper(TaskWrapper const&);
TaskWrapper(TaskWrapper&&);
TaskWrapper& operator= (TaskWrapper const&);
TaskWrapper& operator= (TaskWrapper&&);
private:
Task* m_ptr; // preferably a unique_ptr
};
You could also let TaskWrapper derive from Task.
If I understand the question correctly, you want ApplImp to derive from TaskImp, and call into TaskImpl member implementations as needed, using standard C++ syntax..
You can't do that directly because the application and DLL are linked separately and have no compile-time knowledge of each other. The application doesn't know about TaskImpl at compile time, thus the compiler cannot derive from it and cannot create a Vtable that may be a combination of funcitons from application and DLL.
You chould compose the objects, i.e. create an instance of TaskImp inside ApplImp and delegate all functions to the TaskImp instance inside of ApplImp. That's inconvenient in many cases.
A more convenient way is to export the implementation of TaskImpl from the DLL: declare the whole class as __dllexport. Unfortunately, that's the least portable way to do it and in a large project, it may lead to a huge dll export section with 10000 C++-name-mangled entries. But you might be able to use TaskImpl as a base class in other DLLs or the application.
Btw, this won't compile because ApplImp is derived from Task, and Task* cannot be cast implicitly to ApplImpl.
ApplImp * aNewTask = static_cast(newTask());
I have a main app which has an interface(abstract class) and this interface need to have implementations both in main app and an external dll.
I will be using the pointer to this interface to access the methods, so i will be assigning pointer to address of the any one of the implementations based on some condition.
How can this be achieved?
I came across a question in stack overflow where the answer marked as solution says
An interface in main app
class IModule
{
public:
virtual ~IModule(); // <= important!
virtual void doStuff() = 0;
};
can be implemented in main app
class ActualModule: public IModule
{
/* implementation */
};
And can export a function from dll to return pointer to implementation in dll
__declspec (dllexport) IModule* CreateModule()
{
// call the constructor of the actual implementation
IModule * module = new ActualModule();
// return the created function
return module;
}
How will dll come to know that something like IModule exists?
Can i mark the IModule as extern and use in dll?
'How will dll come to know that something like IModule exists?'
Because the dll code will include the header file where IModule is declared. Header files are the way to share declarations between different source files. Dlls make no difference to this, and there is no need to mark IModule as extern.
BTW I would do this
virtual ~IModule() {} // <= important!