I have been doing some research on the rules engines that would be more appropriate run on a embedded system. The system will collect information from sensors and according to that information, make specific C/C++ calls. An example would be:
IF RainSensor.value > RainSensor.threshold
THEN call( GarageWindow::close())
Being GarageWindow a C++ class, living in the binary that links to the Rules Engine library.
I cannot make assumptions on the capabilities of said embedded system. The requirements for it are:
Minimum footprint.
Portable
Able to make function calls (make C/C++ calls from its RHS).
Should accept new rules at runtime.
I would need to give alternatives according to its capabilities (to be defined in the future), the assumptions are:
1) The embedded system supports nothing(no JVM, no python, etc):
CLIPS as C library or clipsmm as C++ library. Both usable in commercial applications (GPL for clipsmm).
Advantages: Open Source. Very well tested/documented. Portable and can run on low memory footprint. It’s possible to call C or C++ functions from its RHS section. Most likely the Rules Engine will need to interact with a C or C++ software.
Disadvantages: It is not thread safe. It supports only forward chaining.
2) The system supports python:
PyClips:
Python interface to CLIPS. Functionality remains the same as in the previous case. Using this would only benefit if python calls need to be made in the RHS section. Any advantage/disadvantage I miss?
3) System supports JVM:
Jess:
Advantages: Nice integration with Java objects. CLIPS-like scripting language. Forward and backward chaining. Automatic listening to Java objects to modify slots.
Disadvantages: Licensed. Can only define new classes at compile time.
Drools:
Advantages: Open source. Documented. Java integration. Forward and backward chaining.
Disadvantages: It is more designed to work on the web (that's my impression).
What would be the advantage of Drools vs Jess in an embedded environment?
Both can only add new classes at compile time. CLIPS can at runtime. On the other hand,if the C++ code that updates clips instances is old, any new class created directly in CLIPS will not be matched to any other class in the calling C++ code. Therefore, the disadvantage of recompiling of the Java options is not such.
Is there any other appropriate engine for embedded systems that I am totally missing?
What are effective code-sharing/code-reuse practices or other development gotchas one should be aware of when developing a standard native C++ desktop application for Windows 7 (and earlier) with the intent of providing a side-by-side Windows 8 (and later) version of the application (universal C++ and/or Windows Store-friendly, if those aren't the same thing) in the near future?
The main issue with windows desktop apps (using Win32, .net, etc on Win8 and Win7) compared to windows store app (based on WinRT/XAML, only Win8) is the different approach regarding UI. One solution would be to isolate UI related functions.
Article Windows store apps using C++ and XAML recommends this architecture:
When possible, use C++11 and the standard C++ libraries (for example,
the STL and CRT) for your core app logic and the C++/CX syntax only at
the boundary where you interact with the Windows Runtime.
If you follow this recommendation, you'll be able to share a lot of code between the two (business/back office logice) as well as common utility functions.
One way to achieve this:
Use the pimpl idiom ("pointer to implementation") to hide
implementation, minimize coupling, and separate interfaces. ...
implementation details to a .cpp ... a smart pointer to that
implementation in the private section of the class declaration in the
.h.
So all your platform specific objects would be regrouped in an implementation object, and your common code could remain platform independent.
I'd like to make dynamic (i.e. reflection-based) calls to WinRT objects, from C or C++. I will assume that I have winmd files available at run-time, so that I can find out what the methods are and what parameters they take.
In OLE Automation, IDispatch was then available to make the actual calls. However, WinRT objects don't support IDispatch. How can I then make calls? Do I need some kind of FFI library that will allow to dynamically pass the parameters, according to the COM calling convention of the processor? Or do I really need "static" class/struct declarations (for C/C++)?
Edit: The target system is a metro-style app. That precludes solutions involving banned APIs.
It is certainly possible to build what you're describing - under the covers that's exactly what the Chakra Javascript engine does with winrt metadata and is similar to what the CLR does. Both of these language projections discover the APIs at runtime and build up the low level assembly to make this happen.
It's a lot of work and isn't particularly pleasant but it's absolutely technically possible. The windows metadata contains all the information needed to create stubs for the APIs and structures.
I want to write a native application that can be extended with plugins, perferabily in the form of dynamic libraries. I have an idea of what to do, but I would like some ideas, especially best practice tips on what to do and not to do. I worked with similar things on java and php, so I hope I don't bring any bad habits in to my C++.
I'm thinking of allowing developers to implement certain functions like "on_recieve_data(App* app, void* data)" and my application will load all the plugins and call their on_recieve_data function with a pointer to itself (dlsym?).
There are a few things that I consider very important for plugins:
Language support
If you want to reach the most number of platforms/languages/compilers then you should write the plugin interface in C and not in C++. The plugin developers can still write their functions in C++, of course, it is just the interface that is C. The problem is that each C++ compiler mangles symbol names in its own way, so if you use C++ you will be forcing plugin developers to use the same compilers and tools that you use. On the other side, there is only one way to export C symbols, so using a C interface for the plugin will allow developers to pick whatever tools they like, and as long as they can produce standard .so/.dll libraries they'll be fine.
Memory allocation
In some platforms there are problems when memory allocated by the application is released by a DLL or viceversa. If the plugin has functions that are supposed to allocate memory, then make sure you also require the plugin to provide a corresponding function to release that memory. Likewise, if the plugin can call a function in the application to allocate memory, you should also expose a release function for that memory.
Versioning
It is likely that you will have to revise the plugin API after plugins have been written. So your application needs to be prepared to load plugins developed for an older version. You should require an 'init' function in the plugin that the application calls to determine what version of the API the plugin implements and any other information the app might need to know, like the plugin type (if there are different types), what is implemented and what isn't, etc.
Also you have to be very careful when you have to revise the plugin API. You can't change existing functions, since that would break older plugins. Instead you will need to add alternative versions of those functions that have the improvements. Then the problem comes of how to name the new version of an existing function. Typically they'll get the same name plus some suffix ('Ex', a number, etc.). I haven't seen this problem solved in a way that I like.
Likewise, you have to take precautions for structures that are passed between the application and plugins. A common approach is to make the first member of all structures the size of the structure. This works as sort of a versioning mechanism, so that the application can determine what the structure looks like from its size.
Here are a few links that might be of interest:
C-Pluff, a general purpose plug-in framework in C (MIT license)
lighttpd's plugin.h header file
This page has a discussion on how to implement a plugin architecture under Mac OS X, including a short overview of a how to create a C interface for plugins.
Blender is an interesting one. The application is written in C++, but plugins are written in Python. Not a bad idea really, it makes it a lot easier for developer to write plugins.
There are plenty of applications written in scripting languages that support plugins (Wordpress, Drupal, Django, and many more). You can look at any of those that are closer to the kind of application you are writing for ideas.
I believe that this post -> Design Pattern for implementing plugins in your application? does answer your question I guess. It has a lot of refernce for plugin model.
Perhapse, the Eclipse architecture can serve as example:
http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
I'm pretty there is a book from Eclipse's creator, but I can't remember neither the author nor the name of the book.
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.