I know they can be used together, but I'm wondering whether it's possible to replace Qt's signals and slots mechanism with Boost.Signal in the Qt parts of the program (widgets and such).
Anyone ever try it? Any gotchas?
Assuming I don't use any other MOC features and replace signals/slots with boost.signal, is it possible to do without moc entirely?
I considered it for one of my projects. One aspect that might bother you, depending on the project is the use of Qt Designer. The Qt-Designer creates signal-slots underneath for its GUI connections. So, if you happen to use the designer, you will end up with projects having both signals-slots and boost::signals. There are some issues with using them together f.e. see this blog. Though its possible for them to work together, i would refrain from mixing the two approaches.
But the biggest problem i faced was that boost::signals are not thread-safe whereas Qt's signal-slot is! So it was easy decision for me as my project was multithreaded.
You can get the relative merits and de-merits of the approach taken by boost and Qt from Page-11 of this PDF.
HTH
I don't think that is something you want to do. Qt's signals are deeply integrated in the framework and how they are generated and handled. Don't waste your time :)
Related
I'm considering two options to run asynchronous code: Qt Concurrent and std::async. Given that I'm writing a GUI app with Qt, it makes sense to go with Qt Concurrent. However std::async also seems good and supported by all major compilers.
Should I use Qt Concurrent or std::async for new code? What else should I look for when comparing the two?
Given that I'm writing a GUI app with Qt, it makes sense to go with Qt Concurrent
I would say, it is not so simple. I would personally utilize the standard library as much as I can. However, there are constraints to take into account:
Do you need to support your software on platforms not supporting at least C++11?
If the question is yes to that, using Qt solutions is a better option in a Qt based software. That being said, even for that, you could have different Qt solutions depending on your need. One is the thread weaver from KDE, but let us not go that far for now...
Another question, that you could ask from yourself:
Do you already have an existing code base where that is used throughout?
Depending on the answer, this could also provide further aspect for the decision, whether you prefer consistency, or forward thinking.
There is also another question here to be asked:
How much of QtConcurrent do I need?
Depending on the exact answer, it may or may not be a better alternative. Note that, not every functionality of QtConcurrent is in the standard library just yet, for instance something like QFutureWatcher with the Qt signal-slot mechanism.
So, yes, as a Qt user, I would suggest to use the standard library as much as possible. These days, Qt even explicitly depends on them, so will not run on platform not supporting it. Also, the general direction put seems to be this in Qt Project proper. For instance, lots of stuff got obsoleted in the QtAlgorithms, but that is just one of those.
Qt Concurrent lets you run a function in another thread using QtConcurrent::run(). So i think you can only compare QtConcurrent::run() with std::async.
Qt Concurrent is so sophisticated and has many useful features. It includes APIs for parallel list processing and lets you create multi-threaded programs without using low-level threading primitives such as mutexes or semaphores. It also adjusts the number of threads used according to the number of processor cores available.
I think using Qt Concurrent is so cool because of its high-level APIs and ease of 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
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.
Does it make sense to use Qt for increasing the productivity in an MFC app, without actually using the Qt user interface system?
I am currently looking or a good productivity library for my MFC based application, with useful container classes, string algorithmus, threading classes, I/O classes and so on. The Qt API is very nice in my opinion. However, since I don't want to switch my UI to Qt (just too much effort), I am wondering whether Qt can be used well in a MFC app without any Qt UI.
Thanks in advance for your opinions.
Fabian
Qt is divided into several modules (QtGui being one of them). You can hand pick which modules are used by your application by linking only against the libraries you need.
I cannot answer whether Qt will be interopable with MFC. But at the very least, QString offers conversion to std::string and char*/wchar, which should help you quite a bit.
The Qt documentation provides an overview over the modules.
As daniel pointed out below, you have to be aware of the event loop. It is possible however to use the event loop without the GUI module. You can call processEvents on QCoreApplication to process all queued events and then return. There is one caveat with deferred deletions, but the documentation describes the workaround.
There are some utility classes that you can use but there is a very important caveat. Qt depends very heavily on its event loop. The event loop is started by calling QApplication::exec(). Now many Qt classes depend on the signals and slots mechanism is Qt. Signals and slots are totally dependent on the event loop to function correctly.
This is totally true for the GUI modules but is also true of some of the other modules. One can expect every class derived from QObject to use signals and slots and will therefore be unusable without the event loop.
Sure, you can use QT toolkit without using it's GUI library.
Depending on your needs, you might want to consider boost libraries which provides a sane set of APIs that helps for many things. I personally use it for doing network sockets in a multi-platform way, but there is a lot more in it.
yes you can, you have just to exclude QtGui Module from your project (.pro) because it included by default.
QT -= gui
like this the Core Module only is used.
The Mumble project uses Qt for the client and server, with the server not having any UI code at all, still using the rest of the Qt API extensively.
If you only want it for the collection classes why not just use std:: library?
Does someone know of a book or tutorial explaining Qt for Delphi / C++ Builder / VCL developers?
What would be the best approach for a developer with that background to learn Qt? I'm particulary interested in how to accomplish things that I know how to do in Delphi with Qt.
For example, what is the Qt equivalent to Delphi Frames? What about Forms/Frames inheritance? Should I use Qt Designer, Qt Creator or hand code for such tasks?
Another thing is Qt Widgets and objects life cycle. Does Qt take care of widgets and objects destruction or shoul the programmer do it manually? Or may be Qt does that for some types of objects but not for other types?
As a side note I do know C++, so the language itself is not an issue. I'm concerned with the library.
One way might be to study the source for the FreeCLX open source project. It contains an implementation of the VCL using Qt. So if you are curious which Qt widget maps to a VCL type, that should get you on your way. Note, however, that Qt 2.x.x used multiple inheritance (no longer true in current Qt), so the FreeCLX interfaces to Qt via a special library to flatten this out.
To further what Javier says - concepts from one windowing toolkit to another map even less well than languages. It's especially confusing since there are only so many words (frame,window,widget etc) that get reused.
I would go through the (excellent) examples and tutorials included in the QT distribution (you might have to download the source dist) and then think - how would I have done that in VCL?
the easiest and fastest way to learn something new is to put all the old things aside. don't try to think in Delphi when developing in C++.
first learn some C++ (it's not hard, really) then pick Qt. you don't have to know ALL of C++ and STL to get to speed with Qt, just get comfortable with the syntax and fundamental concepts (like pointers, structs vs. classes, these kind of things).
If I remember correctly, Qt Assistant has some good beginner tutorials, which step you through the basic structure of an increasingly complex Qt GUI app. You also get introduced to the parent/child hierarchy, the signal/slot event system, both of which are key to understanding Qt applications.
I'm with the others who say not to try to map Delphi metaphors to Qt metaphors. However, you will likely find many similarities along the way where your Delphi experience will give you perspective.
Good luck!
EDIT: QtCentre is the best online forum for Qt development in my opinion. You'll find many knowledgeable people there.