What is PocoCapsule current status? Is it evolving? Has it been forked
with some other product?
What is about the whole idea of IoC for C++? If PocoCapsule is not
evolving, is it because IoC was considered not useful for C++, unsafe,
other patterns appeared or something else?
As far as I understand there are 2-3, maybe few more products, that
implement IoC for C++, available and
PocoCapsule is the most mature of them.
I see several disadvantages in current version (as I see it's 1.1 from
google code):
No separate namespace.
Header files are required to be right in INCLUDE folder - better to place them in subfolder.
Generation Tools depend on Java.
No static linking libraries are built by default.
Cannot generate source code out of setup.xml for compilation and link with my app if I don't need reconfiguration feature.
Does anybody have the same thoughts? Does anybody work on something of
this list? Are there any barriers to start working, like patents?
I emailed Ke Jin (maintainer) and his response was that it is not under current, active development as of Jul 14, 2011. He did not give a reason.
I have been looking for this myself for some time now, and came realize that there are no good IoC Containers in C++. There are a lot of problems implementing this. Getting something like the C# IoC Containers (Castle Windsor, Unity, etc.) is out of reach. My guess is that if you require something like this, you don´t do c++. And if you do C++, you roll your own or use singleton factories (little joke) ;)
An easy shortcut is to use Qt´s QML. It was build for declarative UIs but can be used for building any QObject based tree.
Another good look are CORBA Systems for C++, they may have some of the things you require.
Just my hints for other places to look...
I think that you can successfully use Qt metaobject system by reusing QtCore library and moc-compiler in your application.
With metaobject system you can create fully isolated modules by calling any method of module's interface via QMetaObject::invokeMethod().
And all will work without QCoreApplication object instance! Define your modules as subclasses of QObject, provide Q_OBJECT macro and mark all interface methods with Q_INVOKABLE ( of course, you should add moc-compiler as build step ).
Related
I am planning a c++ project using dependency injection via boost di. In my opinion I will need a mechanism for dynamically loading libraries too, to be able to realy benefit of dependency injection.
Therefore I consider using boost dll to use a platform independent shared library mechansim.
For dependency configuration I think about using INI-files via boost property tree.
Do you see any major drawback in this approach?
Or is there another platform independent mechanism/library?
Thanks for your opinions
Andreas
There is a mechanism to decide during runtime what implementation to use. But due to the compile time approach of Boost DI it seems by design not intended to use it with dynamic libraries.
For a pure compile time injection it looks very smart and nice to use. For my problem, it seems not the right solution.
During C++ projects development, I had to find a C++ DI framework.
After some investigation and evaluations and based on our requirements (detailed below), we found out that Hypodermic framework suits our needs.
Our criterions (except the basic one that the framework shall recursively inject instances !!) were:
Non-intrusive (do not require to dirty existing code with 'decorations' macros...) as Google fruit and or other libs require.
Support singleton instance
Support of configurable instantiation (using a lambda)
Support of container\injector composition
Generic Shareable container\injector in order to support modules (static or dynamic). BTW, I agree with
Boost-DI, as answered by Andreas, is not suitable because it is heavily templated and as answered in this question.
Boost-DI does not allow real composition of containers at run-time and even not at compile-time unless you share the header files with the root injector. It violates the 'privacy' of modules (as you need to publish them to be able to inject them).
Hypodermic allows to configure containers and create sub-containers. Container is agnostic to type (not template) therefore it is possible to share it at run-time.
BTW, this solves also this question
Background
I need to implement a dynamically-configurable data-processing toolkit. There will be several data processing entities, which can be combined to a data-flow graph by using a GUI tool.
The idea is similiar to Direct Show filter graphs (GraphEdit) or Apple's Quartz Composer.
The GUI tool will store graph definitions in a file. When the actual processing is started, this definition file will be read, and data processing objects have to be created and connected at runtime.
I have used Qt's signals and slots for similiar problems before, but this time the main program does not have any GUI. So I'd like to use something less bloated.
Question
What is the easiest way to have signal/slot functionality with basic reflection, without using Qt?
I need to define a fixed number of slot types (each with a certain predefined function signature).
For example, there will be an image-consuming slot, taking an image object as parameter, or a slot just taking an int as parameter.
At runtime, I need to iterate through all signals/slots and connect them dynamically.
I do not need to inspect Slot/Signal Parameters at runtime. It sufficient to have a fixed number of parameter sets. It would be ok to put some kind of hint in the slot's name to identify the signature type.
I know that boost ships with signal2, which provides signal/slot functionality. But whats the fastest way to implement reflection? Should I build my own set of macro-hacks?
I haven't used it, but it seems cpgf has all features you need (reflection and signal/slot).
I believe you can use Qt to develop non-GUI tool. AFAIR, doxygen uses Qt. But I didn't use Qt by myself yet.
Also a suggestion is that you should NOT implement you reflection system unless you are ready to invest a lot of your time and energy. You may implement a dirty and quick reflection system in your app but then you may find you need more time to maintain or improve it as your app growing.
Also forget macros for reflection. Macros are too ugly and too error prone.
For my cpgf library (I'm the author), I'm not ready to promote it yet because it's quite new (less than one year) and not as mature as other library. However, I really appreciate if any real projects use it to verify it works in real world than just works in unit tests. And I would like to give necessary assistance to the projects for bug fixing or something like that.
Boost also has an implementation of signal and slots
http://www.boost.org/doc/libs/1_49_0/doc/html/signals.html
I know it's possible to write your code in C++ and use Objective C to make native Mac UI and Visual C++ to make native Windows UI.
Can someone please point me to a tutorial or write a sample code that teaches how to do this?
NOTE
I know about Qt or wxWidgets but that isn't the solution I want. I really really want to give a native feeling.
Although you say you know about Qt and wxWidgets, I still recommend you use them. You can do native-feeling apps with them.
You will always have to implement some kind of abstraction layer since the Windows and Mac are vastly different in how their UIs are implemented. You would need to find common patterns, find ways on how to abstract things so that different things can be accessed in a similar way. For this, you need to know both Windows and Mac programming very well. You will spend a lot of time trying to find workarounds and searching bugs. With every new iteration of Windows or Mac OS X, you would need to start working around bugs and/or integrating new behavior yet again.
Using a cross-platform library will save you lots of time and trouble and thus money, if you're writing a commercial application.
Edit: Well, if you're forced to go that route, I'd recommend to do it like this:
Separate the app into two parts: a backend that doesn't know anything about UI which does all the business logic and then the UI part. You would need to implement the UIs completely separate from each other and wouldn't be able to share much code between them. After all, if you would try to find common grounds (for example, if you would like to unify creating and using a button) you could as well use a cross-platform UI library again...
The upside would be that you could use every obscure UI feature available to each OS. The downside would be that you need to maintain two UIs, so if you add a feature to one UI you'd need to reimplement it in the other as well.
But you might want use a cross-platform library for the backend to unify things like file handling, networking and threading.
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.
I'm about to write a program in C++, but I'm unsure as to how to go about it. I want to create a program that can be used with a command line frontend but also a GUI frontend as I don't want to bind a user to a specific interface such as a widget toolkit for dependencies' sake.
How would be the best way to do this? I know some programs like RSync and SSH have frontends in GUIs, but I'm not sure how this is done. Wouldn't it be hacky to have a program that just uses system() to run it all while having a pretty GUI?
You implement your program's algorithms in a library, carefully avoiding any UI stuff. The API to your algorithms is specified in header files.
Then you can write several applications that use this library, one implementing a GUI front end and one a command line interface. They include the headers and compile against the API, and you link the library to it.
Be careful to not to compile the library and the GUI with inconsistent settings.
IME the separation of algorithms from UI can be achieved best when you first implement a command line UI. You might have to employ callbacks for that separation.
Without knowing any other requirements, the simplest answer is just to compile your "backend" as a library, and then link your various "frontends" against it.
More complex answers involve setting your backend up as a daemon/server.
You shouldn't need system-calls to do any of this (unless you have very specific requirements).
You can inspire yourself on the MVC design pattern. The differing front-ends are the views on your model-controller. The controller can be a library which will factor the common tasks of your application. The GUI part and the shell part (or another language integration part for example) all use this "headless" library. Having a clear separation from the start will help enforcing modularity and decoupling.
You could use QT for the GUI front end. But I'd actually just write your library first. Then do your GUI last.
Some helpful advice
Be sure to write unit tests WHILE writing your code.
Be sure to use a code coverage tool to evaluate your unit tests while writing your code.
Be sure to avoid BOOL types since those are usually defined in the platform API (like win32). Use bool instead.
Forward declare as many types as you can in your header files. Include as few as possible header files in each library header file.
Expose as minimal an interface as possible.
Be sure to follow good coding practices for c++. Herb Sutters Book C++ coding standards is excellent in this regard.
Once you do write your gui, put as little business logic in your GUI event handlers as possible. Basically you want your library to be agnostic towards your GUI. Someone else mentioned the MVC pattern here. That is excellent advice.