We have a lot of business logic written in cross-platform C++. We want to write cross-platform UI for our application and use this business logic to create whole cross-platfrom application.
Is it possible to expose native module purely written in C++ to react-native?
We don't want to create wrappers around C++ code in native language (Java or Objective-C). Such wrappers will add more complexity it will make debugging and investigation much harder.
I am also looking for a way to do this directly in C++ without writing JNI for Android and Obj-C for iOS. I have found the CxxNativeModule class in the react native source. See the sample implementation SampleCxxModule.
The last thing to figure out is how to register that module in C++. In the JNI for React Native Android, implementation of NativeModule says
NativeModules whose implementation is written in C++ must not provide
any Java code (so they can be reused on other platforms), and instead
should register themselves using CxxModuleWrapper.
Then implementation of CxxModuleWrapper says
This does nothing interesting, except avoid breaking existing code.
So, this may help you get started. The last thing to figure out is how to register a CxxNativeModule so that it can be used in JS.
It seems as though you would need to find the code which is os dependent and write different versions of this code for different operating systems.
Here is a link which suggests how this might be done:
How do I check OS with a preprocessor directive?
I'm making a student project called "C++ Game Development". It's a card game with client and server. Client application contains few windows which I've already made with Windows Forms in Visual Studio 2013. For client/server communication I decided to use Internet Communications Engine (ICE). During Build in client's project I had errors in auto-generated code by ICE. I found that ICE doesn't support C++/CLI, only native C++ or C# (that I can't use).
So now I am at a crossroads, whether make the whole client application in native C++ (that means for ex. use MFC which I'm not familiar with) or use both native C++ and C++/CLI (put the work I've done with Windows Forms to CLR Class Library and link to it from native C++ project with entry point) which is also not trivial.
I'm trying to choose the less time-consuming option. I'm asking to help me estimate the complexity of these approaches. I like the second much more but I'm not sure it's the easiest.
It depends how much complexity is already in your GUI. If you have a hundred dialogs/controls then rewriting it in native C++ might be the wrong answer. In this case, making your GUI into a library makes more sense.
However, its probably a better option to keep your GUI as a process and build a proxy library in native C++ that passes the ICE calls onto your server. (so C++/CLI exe calls a function in a new C++ library that makes a ICE call to the server and vice-versa).
If your GUI is small, then rewriting it in a modern (and better supported that C++/CLI) system is the best thing. Qt is probably the ultimate in native GUIs nowadays (but there are alternatives such as MFC, or wxWidgets). Even in these cases, its still probably better to code your networking subsystem as a native library anyway. Then you can change your GUI and try out a load of the GUI stacks as you like, porting your game to Android or iOS with just 1 presentation layer change.
The third alternative is to choose a different comms system. Whilst RPC like ICE are nice, the 'where its at' today is web-based comms via REST services (try an embedded c++ webserver like Mongoose or NxWeb), if you need to push data back to the client, these support WebSockets, so will provide all the functionality you need. And then, you can rewrite your GUI to be HTML based!
So: put your comms in a native C++ library.
C++/CLI can use native C++ code just fine.
Stick the generated code into a "static library project" that builds without /clr. Then list that static library as a dependency of your C++/CLI DLL.
The linker will figure out the rest. The result is called a "mixed-mode assembly".
Note that your comm library may not accept managed types. That's ok, C++/CLI can perfectly well mix unmanaged data model and managed view (UI) classes.
How do I add a MySql.Data.dll file to a Qt C++ project?
For QT, check out QSQL instead to connect to a database.
Or use the C++/C connectors:
For C++: MySQL++
For C: MySQL C API
Judging from the naming of the DLL and a little searching, I suspect that it is a .NET assembly, not a regular win32 dll. Unless you have a good reason to do so, you shouldn't try to use a .NET assembly in a native C++ application. It can be done, but it's messy.
Qt has an SQL module which should be sufficient in 99% of the cases. If you have questions about how to use it (e.g. connecting to a database, doing queries etc.), ask them as separate, specific questions.
The MSDN documentation for WMPLIB states that syncing to device is not supported in .NET programming, only C++.
Is there, however, a simple wrapper class or DLL that can be used to interface between a .NET program and the nescessary C++ code?
Or is there a better way to sync files to a device using VB.NET? Are all devices suited/compatible with just a simple filesystem.copyfile ?
I don't know of any existing wrapper. Maybe others can help out with that.
Have you tried C++/CLI? You can write a simple C++/CLI project that can interop with C/C++, but its functions are visible from other .NET languages, just like C# or VB.NET. We've had a lot of success wrapping C++ code using C++/CLI, I recommend it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
What are your tips on implementing a plugin style system?
In C (and I think C++ too although I haven't done it myself), this is most typically done using dynamically loaded modules. The API:s for such are platform-dependent.
On POSIX (Linux), you use the dlopen() family of functions. Basically you build your plugin separately, then load it at run-time, look up its symbols by name, and can then call them.
For Win32, there is LoadLibrary() which does something very similar, you build your code into a DLL.
For a handy wrapper that makes all of these easy and transparent, check out GLib's GModule API.
In the '92/'93 time frame I worked on a plugin architecture for Aldus PageMaker, which was coded in C++. PageMaker was built on a C++ OOP framework called VAMP, which assisted its portability between Mac OS and Windows.
So we tried to use the features of C++ to build a plugin architecture. This proved to be very problematic for C++ classes due to the so-called brittle base class problem. I proceeded to write a paper that was published in journals and that I presented at OOPSLA '93 in a reflection workshop. I also made contact with Bjarne Stroustrup at a Usenix conference in Portland and proceeded to dialog with him for several months, where he championed the issue of dealing with the brittle base class problem on my behalf. (Alas, other issues were deemed more important at that time.)
Microsoft introduced the COM/DCOM system and for that platform that was looked on as a viable solution to the problem. C++ could be used as an implementation language for COM via abstract classes used to define COM interfaces.
However, these days developers shun away from COM/DCOM.
In contrast, NeXT devised a plugin architecture using Objective C in the early 90s in the NeXT Step framework. Today that lives on vibrantly in Mac OS X on Apple's computers and important platforms such as the iPhone.
I submit Objective C enabled solving the plugin problem in a superior manner.
I personally regard the brittle base class problem of C++ to be it's most fatal flaw.
If were building a plugin architecture with the C-based family of languages, would do so using Objective C.
The best platform and language neutral advice I can give is this:
Design your entire app around the plugin SDK.
IMO, a plugin SDK should not be an afterthought. If you design your app to basically be an empty shell which loads plugins, then the core features are implemented in your own SDK, you get the following benefits:
High modularity of components, and clear separation of purpose (it kind of forces your architecture to be good)
It forces your SDK to be really good
It allows other third party developers to make extremely powerful, core-level features as well
New developers/hires can easily start work on a major new feature without having to touch the main app - they can do all their work in a plugin (which prevents them screwing up anything else)
In C/C++, you probably use dynamic link libraries and either function pointers (C) or interfaces (classes solely consisting of pure virtual methods, for C++). However even if you use Javascript, I'd still recommend the above architecture.
Qt provides QPluginLoader:
http://qt-project.org/doc/qt-4.8/qpluginloader.html
If you need/want more fine grained control, Qt also provides a means to load libraries on the fly with QLibrary:
http://qt-project.org/doc/qt-4.8/qlibrary.html
Even better, these are portable across platforms.
This may not be what you're looking for, but you could embed a scripting language in your application, such as Lua. Lua was designed to be embedded in other programs and used as a scripting language for writing plugins. I believe it's fairly easy to add the Lua interpreter to your program, though I don't know Lua so I can't vouch for how effective of a solution this would be. Others with more experience with Lua, please add comments about your experience with embedding Lua in another application.
This would, of course, mean that your plugins need to be written in Lua. If you don't like Lua then the de-facto standard Perl, Python and Ruby interpreters are all written in C, and can be embedded in a C program. I know of a number of programs that use these languages as scripting language extensions.
However, I don't know what you're looking for, as your question is a little vague. Perhaps more information about what you want people to be able to do with said plugins would be appropriate. For some tasks, a full-blown scripting language may be a bit overkill.
I have written an article about how to implement a plugin system using Dynamic Linking Libraries. The article is written from the point-of-view of a Windows programmer but the technique can be applied to a Linux/Unix type environment.
The article can be found here: http://3dgep.com/?p=1759
The main point is, you should create a "common" DLL that is implicitly linked by both the main application (the core application) and by the plugin implementations. The plugins can then be explicitly linked and loaded dynamically at run-time by the core application.
The article also shows how you can safely share static (singleton) instance of a class across multiple DLLs by using the "common" DLL.
The article also shows how you can export a "C" function or variables from a DLL and use the exported functions in the application at run-time.
It's best to use a framework like ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) that shields you (as good as possible) from platform specific coding.
ACE contains a plugin framework that is based on shared libraries that you can use to create dynamically assembled applications.
For a higher level abstraction check out CIAO (http://www.cs.wustl.edu/~schmidt/CIAO.html) the Open Source C++ implementation of the CORBA Component Model.
Look at Poco Class Loader, it can be interesting for you.
I have written a plugin library Pugg that loads C++ classes from dll files and here is the logic I used:
User exports a c function from dll that has a unique name. This name has to be unique enough as functions cannot be distinguished using their arguments while loading from dlls.
C function registers one or several factory classes called "Driver". Every Driver class is associated with a string. When the main application wants to create a class, it gathers the related factory class using the associated string. I also implemented a version checking system to not load old plugins.
Dll loading is accomplished using the LoadLibraryA and GetProcAddress functions (Pugg currently works on windows).
One thing worth mentioning is that main application and dlls should be compiled using the same compiler and using the same compilation options (release/debug modes, optimization settings, stl versions etc...). Otherwise there might be issues with mapping of classes.
I have had some success using a fairly naive system:
Create API Specification for plug-ins
Use a singleton plug-in manager
Use LoadLibrary/GetProcAddress based run time dynamic linking
Implement Inversion of control based event handling for notifying the plug-ins
This podcast on plugin architectures might also be interesting.