19

Been brushing up on my C++ lately, on Ubuntu QQ. I love the Qt framework for everything, especially building GUI's. I became quite familiar with it when using PyQt over the last few years.

When using PyQt, I had some issues that are now more pronounced when using C++ with Qt: Qt has many extensions to C++ that are Qt specific - QString being just one common example, not to mention automated garbage collection. It is possible to write Qt applications using C++ without knowing much at all about C++ and the STL.

I may have to hit the job market again soon and I'd like to be able to consider C++ positions - but I'm afraid binding myself too much to Qt will limit my abilities to work with generic C++, which were once quite formidable but are now long dormant and rusty.

Should I avoid Qt? Would I be better off using WxWidgets or GTK++ for building GUI's?

What's the best GUI framework to use that allows/requires the most use of generic C++ and the STL? How do I make myself most marketable as a C++ programmer when it comes to GUI frameworks, etc?

Vector
  • 3,241

3 Answers3

15

I wouldn't refrain from using Qt just for those reasons. You are not required to use all of Qt's utility classes; for the ones that replace the STL, you'll at most be forced to use QString and, possibly, QStringList. Also, there's usually much more to a program than the GUI. You can always use exclusively generic C++ for the rest of your program, and use Qt just for the GUI.

In my opinion, working with STL is more about understanding what underlying data structures are used and their complexities, and consequently at which times you should use each container. And when it comes to C++ programming, it's especially about knowing how to use the very essential < algorithm > header, which should also work on Qt's containers, since they're STL-compatible.

I don't see much harm in using all those extensions Qt provides, as long as you know (or ate least have a general idea of) how they are internally implemented. Make sure you know that things like Q_OBJECT, SIGNAL(), SLOT(), foreach(), aren't magic, but macros that expand to valid C++ statements. For instance, it's not all that complicated to understand how the implicitly shared classes and parent-child relationships that make Qt feel more Java-like are implemented. You can always try to recreate some functionality in a separate project just to see if you could do it with generic C++, and then not feel bad for using them in Qt.

Also, take a look at the Boost libraries. They provide extra utilities that the standard C++ library doesn't, and are a really good way to get a little closer to generic C++, since they essentially follow the same conventions as generic C++. Some of the libraries have fairly complex templated classes, and simply trying to understand how they work is, in itself, a good study in C++. Boost has many utilities that cannot be found in Qt, and others that implement the same or similar concepts as some of Qt's classes and can be used in their stead.

If you do hit the job market working with C++, chances are you're going to be working with Qt or another framework that, similarly to it, will have it's own utility classes that try to make C++ simpler.

LLLL
  • 296
  • 2
  • 4
5

I agree with most of high praise of Qt, but the question was What's the best GUI framework to use that allows/requires the most use of generic C++ and the STL? In this respect Qt is a little schizophrenic: it duplicates STL containers and algorithms with it's own twists. It also provides containers, which are different than STL. Interoperability between Qt and STL is not always smooth sailing. In some cases it takes a few function calls to get from std::string to QString and back.

wxWidgets has an option for STL build, which uses STL containers exclusively - there is no parallel universe with home grown replacements as in case of Qt. It also compiles with a standard C++ compiler without needing non-standard extensions. It is a quality GUI framework worth considering.

You can also have a look a gtkmm, which is a C++ wrapper around GTK+. It is closer to fulfilling your first requirement than Qt.

Paul Jurczak
  • 151
2

I would not worry too much about not using specific STL librarys like std::string or std::iostream or std::vector. The QT-equivalents come in a different flavour but they are not so far off to make any problem.

The more idiomatic difference in my opinion seems to be the programming style heavy on using new for allocation. While for a QT program this might be fine for the Gui part, the virtue of C++ and RAII is, that you can actually keep lots of data on the stack instead of the heap. When switching to writing non-GUI code you should recall that.

wirrbel
  • 3,068
  • 2
  • 23
  • 34