The open source Chromium code has libcef.dll. This project is running your chrome browser.
Its project has a cpp to c and then c to cpp wrapper projects. But why are they required ?
Could we just not talk with libcef.dll exported class directly ?
Yes we could but there is a catch.
A DLL has address of its functions in it.
A C-DLL's functions are not name-mangled. The addresses of its functions are attached directly with its address.
C++ has a lot of features like inheritance, virtual functions. Therefore, its DLL is also complex. Its virtual functions are taken as a offset in the virtual table of its class. So, if you add one more virtual function, then offset of previous functions may change. This would trigger undefined behavior for previous executables.
That's fine. But i still do not get it.
Ok, dlls are used across many executables. Now what would happen if changes in a dll would force you to rebuild your executable ? If its your dll, you might think that is ok, but what about if Microsoft changes its system dlls. Would all of those products already written have to be rebuild and redeployed. Forget the developer, it would be a nightmare for the users too to uninstall and install all software every next fort-night.
Yaa.. you got the problem. A C++ DLL can not be easily changed so as to avoid correct working of the executables using it.
A c wrapper is used to expose all the c++ DLL public functions to the user like
And now everybody is happy :)
Its project has a cpp to c and then c to cpp wrapper projects. But why are they required ?
Could we just not talk with libcef.dll exported class directly ?
Yes we could but there is a catch.
A DLL has address of its functions in it.
A C-DLL's functions are not name-mangled. The addresses of its functions are attached directly with its address.
C++ has a lot of features like inheritance, virtual functions. Therefore, its DLL is also complex. Its virtual functions are taken as a offset in the virtual table of its class. So, if you add one more virtual function, then offset of previous functions may change. This would trigger undefined behavior for previous executables.
That's fine. But i still do not get it.
Ok, dlls are used across many executables. Now what would happen if changes in a dll would force you to rebuild your executable ? If its your dll, you might think that is ok, but what about if Microsoft changes its system dlls. Would all of those products already written have to be rebuild and redeployed. Forget the developer, it would be a nightmare for the users too to uninstall and install all software every next fort-night.
Yaa.. you got the problem. A C++ DLL can not be easily changed so as to avoid correct working of the executables using it.
A c wrapper is used to expose all the c++ DLL public functions to the user like
// CPP class
class Bar {
public :
virtual void foo();
void bar();
};
// in c wrapper
void Bar_foo(Bar *bar) {
// Now it the work of this interface to convert this bar to actual Bar and
// call the foo function on it.
(some_magic_here(bar))->foo();
}
void Bar_bar(Bar *bar) {
bar->bar();
}
So now this c wrapper dll would have functions that would never change their address. So, its great for you, your dll, others using your dll. NOOO!!! not for them... You can not expect other developers to use this C interface. so here comes that Cpp Interface that comes over this c wrapper to provide you with the cpp interface to code to. Since, it is providing interface for all c functions it also does not have any complexity of actual C++ DLL code.
// Cpp to C wrapper
Class Bar {
public:
void foo() {
Bar_foo(this);
}
void bar() {
Bar_bar(this);
}
};
And now everybody is happy :)
Comments
Post a Comment