I heard Qt API is written in pretty outdated C++ language. Is it true?
Are there any plans to make it use more modern C++ language? Are there any official information on this?
Are there any projects with the aim to wrap current Qt API constructs with more modern C++?
UPDATE
That's more to this question than templates and that's not the question only about the current state of affairs (that's why I tagged it with the future tag).
UPDATE
I'm especially concerned with Qt API as this is what users of this framework work with.
Using modern C++ language in API makes it more robust, flexible and easier to use.
What kind of C++ is used inside Qt is far less important to me.
Qt is known not to use templates, one very useful modern c++ feature. But that does not mean that there is a need for a wrapper to Qt's API. Qt uses in-house precompilers to address the same issues. Some don't like this approach, but Qt's API is very simple and efficient, and i don't believe there is a real need to modernize it.
In particular, signals&slots, a very impressive feature from Qt, can be achieved using templates (see boost.signals library), but the way Qt has implemented it is still much more efficient.
I'd say "don't worry and use Qt as is".
EDIT:
Sorry i forgot about template containers provided with Qt. But still, Qt's API makes very little use of template classes. This does not mean that they don't use them inside Qt though or that their way of coding is obsolete.
Boost.Signals are probably more powerful than Qt signals/slots but, as far as i can tell, there is no arguing about which is simpler to use. One very convincing implementation of the KISS principle.
Qt uses modern variants of the C++ language - currently C++98, and yes Templates are also used where it's appropritate. Qt has some support for STL. See e.g. http://qt-project.org/doc/qt-5.1/qtcore/containers.html - and convenience functions for e.g. std::string. It's all in the docs: http://qt-project.org/doc/qt-5.1/qtdoc/index.html ;) The question about templates vs moc is one we get so often we have added it to our documentation; http://qt-project.org/doc/qt-4.8/templates.html
Qt sources contain the pattern "template <" 1280 times in src/corelib alone. I fail to see how this can be mistaken as "Qt is known not to use templates"
Unlike Boost.Signals, Qt's implementation of signals/slots is thread-safe via the use of queued connections. On May 2nd, 2009, however, Boost.Signals2 was released and brought with it the much-desired thread-safety. From the developer point of view, Qt's implementation of signals/slots is much easier to use, mostly due to the fact that it does not use templates. For an in depth read of why Qt uses moc instead of templates for signals and slots, here's a page from their documentation.
For those wondering why Qt has its own set of container classes, I'm pretty sure that the main motivation was to offer implicit sharing. All of the container classes are implicitly shared, so whenever a QList is copied, only a pointer to the data is copied. See here for more information on shallow copying within Qt.
To directly answer your question,
Qt's API is comprehensive. I'm pretty sure they'll come out with a QApp::ParkMyCar() function some time. They sometimes implement multiple ways of doing the same thing, with different positions on efficiency vs ease of use. Check out their (excellent) documentation. It is as comprehensive, and has saved my ass more than once.
From what I've seen of the Qt source code, the code is highly efficient.
Take a look at the features in the install configuration - you can turn on/off support for various features (including STL, threading and even the GUI). Further, when the Trolls made Qt 4 ground-up, they did not trade off features against code-jazz -they just delivered more of both. Given the quality of their programmers and their way of updating major versions, I don't think we need to worry about Qt (or parts) getting outdated.
Qt's target market (for desktops) is the MamaPapa company that makes Hello Kitty desktop alarm clocks, and wants to Code once and rest assured that it runs on all "sane" systems - Windows 98 and above, popular Linux distros and Mac OS X. This means pandering to the LCD of all the main compilers in each kind of system. If this means keeping template-wizardry in their code to a minimum, so be it.
Throughout the Qt 4.x lifetime, I doubt that it makes sense to rewrite parts of Qt to use e.g. "more modern" C++. This is because of the premise that all releases in the same major version of Qt should still be binary compatible. We also can not just obsolete or deprecate classes that the customers still use (although it is perfectly fine to introduce new stuff, even for a limited set of supported compilers).
If finally Qt 5 is almost out of the door, and the modern C++ constructs and features are finally available in the targeted supported platforms and compilers, and doing so will help C++ developers and customers to write better and more powerful code, then why not?
I really don't like the way Qt managed to implement its signals/slots mechanism. Their 'moc' precompiler really smells like a hack to me, and it doesn't even support standard C++.
I think it would be great if Qt could modernize itself to use at least the STL classes. What would be really awesome would be for Qt to use Boost whenever possible (especially Boost.Signals).
I, too, don't like the way Qt adds voodoo magic to C++. It uses so many macros that it awfully reminds me of C. At the moment, there is nothing to indicate that Qt would be kinder to C++ features in the future. I would really like to see it be more like C++ and not a language of its own (e.g. Why do we need std::vector<> and QVector<>? Or Qt signals, Boost.Signals and sigc++?)
Qt is a library and needs to support a wide range of compilers. It still supports MSVC6, e.g. (I think Qt Software is phasing out support for this, though). This limits the more modern C++ features, Qt is able to use.
But this does not mean that you can't use them in your Qt program.
Related
I am producing a piece numerical software in C++ and want to add a GUI (mainly for Windows). I know how to produce GUIs using comfortable editors in modern languages like Java or .NET. Now my question is what is the easiest and most comfortable way to add a GUI frontend for my program. In the choice of the tools am completely free (open source and portability would be nice), but please also keep in mind how much boilerplate code and interfaces that have to be maintained are required if the GUI is implemented in another language (Like C#).
Please don't suggest switching the whole project from C++! And note that the program does not require not much interaction between the C++ code and the GUI.
The statements about ISO C++ in this answer's comments are poorly edited. None of the solutions presented here would impose on the computational code a requirement of changing to a different dialect of C++. The GUI code itself might be another story.
The answers about using Windows Forms with managed C++ are probably the most practical. A lot of the UI-related code would be in a dialect (extension) of C++ where the .NET-garbage-collected pointers would be living alongside the traditional ISO C++ pointers. I haven't used this method but from what I read it might be better than what I have used.
MFC might be more practical if you don't want to invest in .NET knowledge for this task. It uses standard C++ constructs to wrap the Windows API. The Windows API uses a particular calling convention which C++ doesn't normally use, and it takes an extension to C++ to work with that, but this is no different than having a C++ program that calls some functions that are extern "C". Visual Studio has a GUI layout tool that is really good at layout of dialogs and at interfacing the dialog widgets to variables that reflect the state of the widgets. I've used this. If you can boil your GUI down to a dialog box then this would be a great option, otherwise you'd be using one of MFC's layout-managed windows.
Obviously the above options do not handle other platforms you might have in mind.
There are also various toolkits that were born on other platforms and have been decently ported to Windows. GTK, QT, FLTK, and WxWindows come to mind. I haven't used any of the dialog-layout/application designer tools that work with those, and I haven't used QT at all. When I last reviewed QT it had a special preprocessing pass for the GUI code. Other than that these portable tool kits are pure ISO C++ as far as I know.
As a really-out-there option one could program to the X Window System protocol using "libx". As far as I know this would involve no non-ISO C++ code.
Qt is a decent choice. It's stable, has a wonderful C++ interface (as opposed to MFC) and has a convenient designer tool.
The overhead of learning it from scratch might however be more that what you're willing to invest. It does have a certain learning curve.
wxWidgets would a good choice for a cross platform GUI for C++
As much as I love C++, it's difficult to build a GUI with. I'd build a quick C# WinForms application which would let you use things like Visual Studio's visual designers (Drag and drop buttons and such), and call your C++ application using P/Invoke.
C++ will often produce smoother and nicer GUIs, but it takes a bit more work out of the box.
If it's going to be just a simple GUI consisting mostly of standard controls I would do it with MFC. It may be outdated and was never really good, but it's still useful to get a native Windows GUI up and running quickly.
I have to chuckle at all the ways to skin this cat. Life is good. My response is a product I manage. XVT can do it for you. The easiest way is let us do it for you or give you a template to get there. It's just a matter of if you have more money than time. Then I'd look at us. It would be the fastest and least amount of effort on your part.
MFC Dialog Based application could answer the needs.
Depending on what you need, there's a nice imgui made by Mikko floating around that you can simply plug-in and use fairly quickly. It's done in opengl though so it won't be your standard windows-gui but it's really small and really easy to work with. You can download r'lyeh's version from here: http://code.google.com/p/colony9/source/browse/include/goo/imgui.h.
That's the easiest and most comfortable way I know, it is dependent on SDL though.
As well-known, C++ has steeper learning curve than most of the mainstream languages, which results in better performance . But, does using C++ over other languages[like Java,Ruby,Python] for Qt development have still (major) advantages,let's say about Qtopia? If any, what are they?
Qt is natively a C++ API, so any other languages have to have wrapper code around it which needs to be maintained, etc. The primary documentation will also be for the C++ API.
I'm not sure if there are any "official" bindings to other languages which are maintained and released together with Qt.
If you are looking at Qtopia, you are probably looking into embedded systems. In that case, C++ will likely be the one you want to choose, specifically for those performance reasons.
Otherwise, Trolltech maintains a Java binding, and I imagine that some of the other language bindings aren't too bad either, since those languages can interact directly with c/c++ code. However, those bindings are likely to always be a little out of date.
it's easier to create a single executable.
don't know if that will be for long...
I am a C# programmer who started using ubuntu about 2 years ago. I'm wanting to learn GUI programming in either C or C++. I don't really like mono, it tends to crash on my system. I have a basic understanding of C++. I have never worked in C, but it looks cool. Which toolkit should I learn/use? Give Pro/Cons of each. Thanks!
I could be accused of bias since I do help contribute to gtkmm, but I was a user first, so... In any case, I would highly recommend gtkmm if you're comfortable with C++. Memory management is much easier with gtkmm than with GTK+ because reference-counted objects are managed automatically with smart pointers. You can also instantiate objects as auto variables (e.g. on the stack) and have their lifetime determined by their scope. So in practice, it's much easier to avoid memory leaks with gtkmm than with GTK+.
Another huge advantage of gtkmm over GTK+ (in my opinion) is the use of a type-safe signals framework. In GTK+, you constantly need to pass things as void pointers and then cast them around to the type you think they should be. In gtkmm, you dont need to do this, and can take advantage of the compiler enforcing type-safety on your signal handlers.
Another big advantage over C/GTK+ is the ease of deriving new classes. In GTK+, you need to write a lot of boilerplate code and basically re-implement things that you get for free in C++ as part of the language (e.g. inheritance, constructors, destructors, etc). This is more tedious and error-prone.
greyfade mentioned that gtkmm is incomplete, and he's right to a certain extent -- gtkmm does not cover absolutely everything in the GTK+ API (though it gets awfully close). But in practice this is not a problem because you can always use the C/GTK+ API directly from your gtkmm code. This C compatibility is a huge advantage of C++ over something like C# or python bindings where you would have no alternatives if the binding didn't cover part of the API.
The only real reasons to choose GTK+ over gtkmm (IMO) are that gtkmm has a little additional overhead since it is a wrapper on top of the C library (but this is generally just a single function call, which is going to have negligible impact), or if you hate or can't use C++.
If you're a C# programmer, why don't you take a look at Vala?
I use pygtk for most of my Linux GUI applications, but Python was simply too slow for the project I'm working on right now, so I was trying to pick one of GTK+ and GTKmm. Then I met Vala.
It's a pretty new language, and therefore documentation is pretty limited at the moment, but I think it has the best of both worlds: C# syntax with C speed.
Since C++ is more familiar to you, you may find GTKmm to be a better fit, since you can use idioms like RAII. Unfortunately, GTKmm is a little incomplete and is missing a few of the lesser-used parts of GTK.
GTK+ on its own, however, essentially exposes an object model similar to what you find in C++, but with only C functions. Things like construction and destruction in C++ are done explicitly in the C API and instances of widgets are handled via pointers exclusively.
Try both and see which fits your project better.
Like many have said, Gtkmm does provide you with good memory management, reference counted objects, etc. It does fall down in one department, though. Documentation. The whole of the Gtkmm project suffers from the "undocumentation" phenomena, where the posted (and reposted on 3rd party sites) documentation is simply a javadoc scan of the header files.
Just wanted you to know what you'd be getting into. For instance, the Scrolled Window is one of the better documented classes in Gtkmm.
I would suggest to learn vala with gedit.
http://www.valaide.org/doku.php : vala
https://launchpad.net/valable : Eclipse
http://code.google.com/p/vtg/ : Gedit
http://abderrahim.arablug.org/blog/ : anjuta
I think the best way to go would be first learn gtkmm! After you are done with the basics of gtkmm, GTK+ should be fairly straightforward to learn(provided you know C and are comfortable with pointers).
In case you don't know C, you can learn it quickly by reading The C Programming Language by Dennis Ritchie
I recommend you to learn gtkmm first because it is specially designed for C++, which is somewhat similar to C# since both are Object Oriented, so gtkmm will be relatively easy to learn first than GTK+.
After gtkmm, you can move on to GTK+
Most of the open source companies use GTK+ rather than gtkmm, so GTK+ is worthwile to learn!
Have you looked at Qt?
It's nice C++ design, cross platform and LGPL
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.
With all the fuss about opensource projects, how come there is still not a strong standard that enables you to make portable code (I mean in C/C++ not Java or C#)
Everyone is kind of making it's own soup.
There are even some third party libs like Apache Portable Runtime.
Yes, there is no standard but libraries like Qt and boost can make your life much easier when you do cross-platform development.
wxwidgets is a great abstraction layer on the native GUI widgets of most window managers.
I think the main reason there isn't any single library anyone agrees on is that everyone's requirements are different. When you want to wrap system libraries you'll often need to make some assumptions about what the use cases will be, unless you want to make the wrapper huge and impossible to work with. I think that might be the main reason there's no single, common cross platform runtime.
For GUI, the reason would be that each platform has its own UI conventions, you can't code one GUI that fits all, you'll simply get one that fits just one or even none at all.
There are many libraries that make cross-platform development easier on their own, but making a complete wrapper for all platforms ends up being either small and highly customized, or massive and completely ridiculous.
Carried to it's logical conclusion, a complete wrapper for all aspects of an operating system becomes an entire virtual runtime. You might as well make your own programming language.
The ADAPTIVE Communication Environment (ACE) is an excellent object oriented framework that provides cross-platform support for all of the low level OS functionality like threading, sockets, mutexes, etc. It runs with a crazy number of compilers and operating systems.
C and C++ as languages are standards languages. If you closely follow their rules when coding (That means not using vendor-specific extensions) you're code should be portable and you should be able to compile it with any modern compiler on any OS.
However C and C++ don't have a GUI library, like Java or C#, however there exist some free or commercial GUI libraries that will allow you to write portable GUI applications.
I think the most populars are Qt (Commercial) and wxWidgets (FOSS). According to wikipedia there is a lot more.
There is also boost, while not a GUI library boost is a really great complement to C++'s STL. In fact some of the boost libraires will be added in the next C++ standard.
If you make sure it compiles cleanly with both GCC and MS VC++, it will be little extra effort to port to somewhere else.