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
Related
I recently read an OOP book (Robert Martin I think) that emphasized using a core object that calls interfaces of the things it uses. The point here is that the peripheral objects depend on the core rather than the other way around. This allows better modularity, flexibility, distribution of binaries, build time, etc. Supposedly you can also allow your program to be independent of any particular framework, eg GUI, database, etc. But I'm having a hard time separating the framework from the core.
For example the Qt framework provides class QTreeView; some functions take instances of QAbstractItemModel.
It's conceivable I find or write a different model/view I want to use that is not part of the Qt world, or use some immediate-mode api for the graphics part, etc.
So how do I write my core to be agnostic of Qt entirely?
Do I make up an ITreeView with similar functions as QTreeView, with similar-sounding non-Qt arguments and then delegate to a real QTreeView instance after converting all arguments to real Qt types? It seems silly to recreate so much of the framework just to make it generic.
Or in the real world are people fully absorbed into Qt and it's not realistic to keep it separated?
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.
I am building a QtQuick app, and i need a TCPSocket that polls a device and fills the data structures I want to show. I've found a lot of samples about sockets and Qt 5 widgets, but i'm not able to create the socket as a C++ class that's not derived from QObject.
My understanding is that I only need to derive from QObject if I want to exchange data with my QML view. I wrote an additional class that does that, so my socket class doesn't have a need to pass any data to my QML code.
The question almost doesn't seem to be a Qt question, but a C++ network programming question. I gather that you basically dislike explicitly using custom QObject-derived classes since you don't want to run moc as a part of your build process. While one might argue what's so bad about it, since moc is run a whole lot during the building of Qt proper, let's go with what's asked for the moment.
If you're looking for non-Qt-based pure-C++ networking, then Boost ASIO is a very solid solution.
If you wish to use Qt networking without a custom QObject-derived class, then you can run the code in a separate thread and only use blocking QTCPSocket calls. After all, it's a QIODevice and offers blocking interface.
Eventually, you end up with some data structure that's filled and should be passed on to QML.
Logically your data is a data model, and the view is in the QML code. You can use QStandardItemModel for that - that is, if you are writing true model-view code, like you would if the data will change over time. Again, you're re-using an existing QObject-derived class, without deriving your own, without writing any custom signals nor slots.
A really poor-man's workaround is to take a naked QObject and put data in it using the dynamic property system via QObject::setProperty. I don't recall offhand if dynamic property changes are seen via the QML engine, you'd need to verify that or simply treat such objects as constants.
All of this seems to be a lot of workarounds for a rather silly reservation. Code generators are good, they save time. The build process of a complex C++-based product may use several different code generators, such as lexer/parser generators, state machine generators, remote procedure call generators, table generators, test case generators, etc. As C++ matures, ways are found to coax the compiler to replace some of those generators, but that's merely pushing the problem to a different executable, and sometimes pushing it through a very small needle hole as well.
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 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 :)