How is Qt changing because of C++11?
I ran into the article about "implicit sharing" and started wondering how C++11 is affecting Qt's design. Implicitly shared objects are almost the same as smart pointers, except that they "copy-on-write." (This is a bad example, because C++11 smart pointers wouldn't work well for implementing this feature.) Has the design philosophy around Qt changed substantially to not try to solve the same problems that C++11 does? Or are they perhaps solving such different problems that C++11's growth of scope is irrelevant to Qt?
Only guessing here but considering Qt is trying to remain compatible with as many OSes and compilers as possible it will be quite a while before any part of Qt can rely on C++11 features being available.
And there has always been overlap between Qt and C++ features (i.e. container classes). I think compatibility is more important to Qt development than avoiding redundancy.
implicit sharing has nothing todo with C++11.
As you may have already noticed implicit sharing in Qt classes was implemented in Qt4.x. Implicit sharing is also implemented by the corresponding class itself and has also nothing todo with the pointer type which is referring to the object.
Qt5 will remain compilable with C++98 throughout its lifetime, that is certain.
Currently, Qt5 uses C++11 a lot internally (if it's available, you will notice big performance boosts throughout the framework, especially in container classes), and defines a lot of C++11 macros for convenience (so that you can benefit from C++11 if it's available, too, without compromising backward compatibility).
@raven-worx: That was only a history of how the topic came to mind. I know they are not related.
What about the flip side, libraries which are designed to allow the user to leverage them with the newer features? In the absence of the newer features, they should degrade gracefully, of course.
I'm getting the idea of C++11-oriented features in Qt creeping over the library across decades rather than a concerted effort to integrate them.
Then you are getting a wrong idea. C++11 is already used inside Qt5, and there is already support for it for example in the new connect syntax (you can use lambdas there :)). You can use C++11 together with Qt, too. Where is the problem? What APIs are you missing?
BTW, implicit sharing is not unique to Qt. It is a generic programming strategy, although it's more commonly known as "copy on write". std::string (including the C++11 variant) uses implicit sharing too.
[quote author="Jesdisciple" date="1369638738"]Has the design philosophy around Qt changed substantially to not try to solve the same problems that C++11 does? Or are they perhaps solving such different problems that C++11's growth of scope is irrelevant to Qt?[/quote]Qt extends C++, so Qt will take whatever C++ has, and then add to it. They are solving different problems because because they have different purposes -- C++ is a low-level language and Qt is a high-level toolkit that uses C++, but C++'s growth will inevitably impact Qt.
[quote author="Jesdisciple" date="1369643395"]I'm getting the idea of C++11-oriented features in Qt creeping over the library across decades rather than a concerted effort to integrate them.[/quote]On the contrary. Although Qt 5 promises compatibility with C++98, the philosophy for new API is "Implement this feature for C++11 first, then figure out how to port it back to C++98. If it takes too much effort (or is impossible) to implement a C++98 version, then this feature will only be available for developers that use C++11-compliant compilers."
Example: You can use lambda expressions as slots, but only if you have a C++11-compliant compiler.
Erm... Problem? I just had a passing curiosity. I'm somewhat familiar with both technologies (moreso C++ than Qt) and also trying to learn more about both. I think it might be a good idea for me to focus on their points of cooperation/intersection. (Maybe this should have been in the Lounge; I wasn't sure when I started it.)
Thanks for the note about connect. Lambdas are a particular focus already, as I tend to enjoy functional features and C++'s take on first-class functions is interesting.
EDIT: @JKSH: Ah, cool. I hadn't ventured to hope the situation was that good.
Yes, this is more of a Lounge discussion, but it's not a big issue :)
What do you mean by "focus on their points of cooperation/intersection"? The reason 3rd-party libraries exist is to provide functionality that the C++ language itself doesn't; a well-designed library does not go out of its way to conflict with C++ (at least without a good reason). IMHO, you'd get the most out of Qt by using its functionality that can't be done (or is harder to do) using traditional C++.
Do you have a starting project in mind? I'm sure the forum members are happy to give you pointers on which parts of Qt to try out first (it is a very large multi-purpose toolkit, after all)
P.S. I found the quote by one of Qt's maintainers about integrating C++11 into Qt: http://lists.qt-project.org/pipermail/development/2013-March/010210.html
[quote]I will not accept "C++11 isn't available for everyone" as a reason to add a
more complicated API. The API should be designed for C++11 use and later made
to work with C++98, with as little modification as possible.[/quote]
Both Qt and C++11 (as I already know C++ to competency) are fairly vast fields of knowledge; I'm imagining geometric shapes to represent them. I want to cover the whole of them both and use them together, but I can only be one place at a time. So I need to select somewhere to start, by choosing an academic topic or a practical task. I tend to do both, alternating and in tandem, but this thread is more about the academic side.
Since I want to use them together well, it makes sense to me to start at their border, inasmuch as they have one. If they both do something, figuring out which to use when is an exercise that can show me a lot of the local area. If Qt is C++11-aware in some way (as with connect), that can be a good motivator to code because it's beautiful, and it might help me think of a project.
The last time I used Qt (it was a hobby project) I got beat pretty bad by the graphics-related classes and that's once again the most natural area for me to pursue. Especially since I'm making a tech demo for my company, to show Qt running on iOS & Android & everything else. Currently we're using Unity3D and I think I would rather use Qt/C++. We primarily build games, so graphics are kind of important to this idea and it makes sense to use them in the tech demo. But the demo itself will be simple; I'm thinking I'll make a square move to four positions in response to taps/clicks.
Qt is based on C++. As long as your compiler supports the newest standard, you can use it in all Qt applications, including Qt4 apps. So, in your geometric representation I would suggest to think of Qt as a transparent blob that sits over C++ shape in space. You can see through Qt and spot every part of C++ "geometry".
I guess you still want to see some cool C++11 stuff being added to Qt APIs. The question remains: what additions are you interested in? Are any really needed?
Woah, you got your 3D all over my naive representation; I can't figure out what anything maps to in that version.
But I can't think of anything I'm particularly looking for, and you don't seem to have anything I'd obviously want to see. [awkward silence] I feel like a window-shopper at a store dedicated to special orders.
Haha, sorry, perhaps I'm not good at generalised top-level discussions ;)
Why CSS? Because a declarative language lends itself well to creating GUIs, much more naturally than a procedural language.
Have a look at the "Photo Surface demo":http://doc-snapshot.qt-project.org/qt5-stable/qtquick/demos-photosurface.html. It is an app that lets you load multiple photos onto a window, and use multitouch gestures to drag/rotate/zoom each photo individually -- all with only 90 lines of QML code. I'd imagine that your four-position-square app will take even less than that.
For chunkier demos of games and their source code, see "here":http://doc-snapshot.qt-project.org/qt5-stable/qtquick/demos-maroon.html and "here":http://doc-snapshot.qt-project.org/qt5-stable/qtquick/demos-samegame.html.
But, if you really really want to stick to C++ only, the "Graphics View framework":http://doc-snapshot.qt-project.org/qt5-stable/qtwidgets/graphicsview.html is good for interactive 2D graphics. There's also "Qt Widgets":http://doc-snapshot.qt-project.org/qt5-stable/qtwidgets/qtwidgets-index.html, which is good for creating more work-related desktop programs (e.g. document editing)
You mentioned a bad experience with graphics in your hobby project; do you remember which classes you were using?
I've read a bit about QML and thought it sounded more like HTML than CSS. I agree that declarative works better for GUIs, but I wasn't thinking of my demo as a GUI. I think the "right thing" for the demo is determined by the aspect of Qt I'm trying to demo (blitting, essentially) rather than the most elegant way to produce an effect. I'm definitely interested in QML for the GUI that overlays a game, though.
(Wow, those are a lot of QML files.)
My hobby project had used QGraphicsView etc. I was working with friends on it, and they had managed to get a spaceship moving but my implementation had stubborn bugs and then we got busy with other things. My first few posts on these forums are about that project.