I am making a Gui Library on top of SDL using C++. (Don't ask me why, I am just doing it to gain some knowledge out of practice in order to understand how Gui libraries are made.) And I want to make a signal connection system like gtk+ or wxWidgets...
g_signal_connect(mybutton,"clicked",gtk_main_quit); //Gtk+
EVT_MENU(wxID_EXIT,OnQuit); //WxWidgets
I understand I can do this using function pointers. But how do I add the functions to the main loop?
Or Is there a better way to do this?
The simplest way is borrowing it from a library, for example boost::signal or boost::signal2. The next best thing is implementing your own but borrowing most of the features from libraries like boost::bind (to enable the connections) or using C++0x features that will simplify the generic connection of clients (std::function / boost::function).
I would recommend that you use boost and their signals2 library, as there are many things that you can do wrong and are already solved there.
Related
Is it possible and recommended to create custom handlers for boost::asio? Are there tutorials on how to do it? After searching for quite some time for it I didn't find anything (only custom allocators in boost::asio).
asio currently supports to provide callbacks, using use_awaitable, use_future for std::futures and more. I would like to have an implementation which works with a boost::future or another kind of future (like the one from stlab) rather than a std::future. Of course, I could study the boost source code and try to mimic it, but that seems rather cumbersome with all the portability details.
"all the portability details" aren't so many, and you want them anyways.
Yes, study the source code e.g. for use_future which has an (outdated) implementation on this site:
boost::asio and Active Object which shows how to implement boost::future support
see also Using futures with boost::asio (using futures is not the most usual approach)
I have recently been using pthreads on Linux and want to start looking into using boost threads in the near future. I have never used MS visual studio so I don't know the approach there but I (have to) use Embarcadero C++ Builder (formerly Borland) one of the few good things I find with it is that is has a built in class TThread. This is a class that you can derive from to give nicely encapsulated data and start and terminate functions. I prefer this approach than the pthread way of passing functions and void* being passed into the thread create function. I was wondering if there is some kind of design pattern or structure that is commonly used to provide a more object oriented that encapsulates the functionality of threads in this way? I can try and create it myself, but I cannot be the first person to desire this kind of approach and wondered if there was a "standard" way of achieving it.
Edit: Alternatively, if this is a very bad idea perhaps an illustration of why?
I would consider that the most standard approach would be using the standard thread library (closely related to boost::thread, not 100% the same). I would avoid redesigning what has already been designed, reviewed and verified by a committee of experts.
Also note that for the kind of operations that you mention in the comment you might want to take a look at the future part of the standard library (again similar to the boost counterpart), and in particular to the std::asynch function.
I like the way boost::thread is designed (I saw a similar design in the threading library from Rouge Wave). Basically a thread is started by passing a function to be executed and latter that thread object can be used to join that thread. pthread is very similar in design, but boost::thread is much easier to use.
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 have a multithreaded dynamic library which exposes a basic API and which I use in a
couple of applications. Currently I'm using a custom(as in legacy) implementation of some basic threading and synchronization primitives with which I'm not happy at all as it does not provide much flexibility, features and it's also a hassle to maintain(has implementations for both Linux and Windows).
I would like to replace that with some existing threading library but I would also like to provide some flexibility, meaning that I would like to be able to try out a bunch of libraries to see how they perform on different platforms I build my library for(I would like to try boost::thread, Poco::Thread and the new C++0X thread implementation) or even let the user to which I provide my library to fit it's own thread custom implementation if wanted, so that the library and the user's app would be able to use the same threading infrastructure - ideally I would have a config file or something on those lines to let the user specify its desired implementation or use a default provided one.
I was thinking of the following:
making a thin wrapper(pimpl style) to be used inside my library that will use a dynamic class loader to fit the desired implementation at runtime. But how could I handle the case of the C++0X threads? These are in the standard library which will already be linked against my library so no point in custom loading it at runtime.
using a dynamic loader coupled with the Prototype design pattern. But the pattern requires the implementation of the clone() method which would mean changing the threading library code. I might have poorly understood the pattern and I might be mistaking about this, so please correct me if I'm wrong.
As you can see I don't have many ideas to work with right now(but it's a start) so any pointers on the following would be of great help:
Is providing such a functionality a good idea? Do you see any caveats?
Is the dynamic loading facility a feasible idea? What are the downsides?
Any pointers/links on how to properly implement that?
If I'm going the "thin wrapper" way would it be a good idea to expose it as part of my library's API?
Are there any alternatives/patterns to achieve the same kind of functionality(I mean to achieve the same result but without dynamic loading)?
What is the benefit of providing the ability to dynamically or delay load of a threading solution? Ideally you would pick a threading solution and create a library which has an API interface and if the solution was later found to be insufficient you could write a new library using the same interface but a different underlying solution. I would even consider statically linking such a library although a DLL is fine as well. I wouldn't bother with the ability to make it interchangeable at runtime or anything like that.
I highly recommend Boost threads. Cross platform and based off POSIX it's very easy to implement in a variety of ways. I believe that C++0x threads were marginally based off this solution however since C++0x is not finalized or fully supported by all compilers yet I would only consider it as a replacement for boost in the future.
I think that by providing a wrapper for the threading library, and initializing it at runtime, you are limiting yourself to the lowest common denominator. That is, your interface into the thread library calls will need to include operations that are implemented by all of the libraries.
If this is acceptable, then you should look into using the Adapter Pattern to handle calls into the thread library that is chosen by the user. Basically, you would use the config file to determine which thread library is in use, and then wrap it in an adapter class that implements your threading operations methods interface and delegates the calls the appropriate methods on the underlying library. You could also use the adapter to make up for unimplemented functionality in certain library (i.e. by implementing reader/writer locks using the mutexes provided by a library, etc.)
First, I'm using Qt at the moment. However, I want the program eventually able to run without a GUI environment, leaving the graphical aspects for configuration mainly. The program makes hefty use of Qt timers and signals/slots, partially for QtScript. So if I want to make it non-GUI operable, hopefully parts of Qt can run without a GUI environment. If not, maybe I'll look into a different Javascript implementation, although QtScript is very convenient how it integrates into Qt's and C++'s OO structure. First, can parts of Qt be used in a non-GUI environment, and if not what other choices are there as far as an events and scheduling library? Preferably OO design.
If you don't use the QtGui module, you don't need a GUI. QtCore etc. will work just fine.
Have you looked at the
Boost.Signals library? (I haven't used it myself.)
libevent may be what you are looking for. This is in C, however.
The libevent API provides a mechanism to execute a callback function when a specific event occurs on a file descriptor or after a timeout has been reached. Furthermore, libevent also support callbacks due to signals or regular timeouts.
libsigc++ has a signals and slots mechanism very similar to Qt's though it's pure C++ (no extra pre-processor). It can also be used with gtkmm, a C++ binding for GTK+.
That said, I'd be surprised if Qt requires that you have a GUI, so you'll probably be able to stick with Qt.
The Poco project offers two interesting solutions:
Notification center: based on Cocoa/OpenStep's NSNotificationCenter
Events and delegates
The Boost signals library is very nice too, but it's one of the few boost libraries that need to be built and linked with.