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,180
  • 3
  • 22
  • 25

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
  • 4
    +1 for "You can always use exclusively generic C++ for the rest of your program, and use Qt just for the GUI." – Md Mahbubur Rahman Apr 21 '13 at 06:49
  • @MahbuburRAaman - yes - this is excellent advice. Use Qt only for GUI and what's necessary to hook into back. Write the rest using Generic C++, STL, Boost - the tools that are used universally. – Vector Apr 21 '13 at 07:35
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
  • 4
  • 1
    'wxWidgets has an option for STL build, which uses STL containers exclusively...' - I see - this is IMPORTANT to know. 'In some cases it takes a few function calls to get from std::string to QString' - understood - I haven't investigated it yet. I am a bit familiar with GTK and Wx - but Qt seems to shine in comparison, at least from my perspective - C++ is NOT my first language - I came from the Clipper/Delphi world and then learned C++ because I had to deal with Win 32s etc. – Vector Apr 21 '13 at 09:37
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,018
  • 2
  • 21
  • 33
  • 1
    the point I was trying to make is not that heap allocation is generally bad, it is just not the best thing for local variables. GUI classes tend to live long and are best allocated on the heap, local variables that are only temporarily needed live well on the stack. in C# with Garbace Collection they will be soon destroyed, so heap is also okay. But with manual `new/delete` calls this is not so easy and error prone. In critical sections (handling big data) this can make a difference, especially `delete` calls can be quite slow. – wirrbel Apr 21 '13 at 11:08
  • 1
    this is not a problem of 10000 UI Objects but for complex tree datastructures with a million entries, etc. where once could resort to smarter ways of allocating things (Bulk allocation or lots of smartly written boost classes, etc.). Conclusion: the heap is not bad, it has to be smartly used. The Qt way sometimes does not scale for other stuff. It is still a **fabulous** toolkit in my opinion. – wirrbel Apr 21 '13 at 11:25
  • So how about C++ 11? smart pointers etc would seem to alleviate many of your concerns. I am just starting to mess with it now. As I said, I agree that Qt KICKS BUTT. My plan is to use Qt for GUI and do whatever else I can using C++ 11 - which seems to render a good deal of Boost, for example, obsolete and closes to a large extent the gaps between Java/C# and old school C++. I get the feeling (at this point from a distance admittedly) that a combination of Qt and C++ 11 can be a big winner. – Vector Apr 21 '13 at 12:22
  • 2
    I think you got my point: You have lots of options with C++, with c++ you must choose wisely. Smart pointers, etc. have problems as well. Fed up with C# you might take a look at http://www.dlang.org which does lots of things better (GCed). – wirrbel Apr 21 '13 at 12:41
  • Meanwhile I have to put together a tool chain that supports C++ 11. I use codelite right now - very nice IDE - but out of the box (GNU compiler) it doesn't support 11, as I just found out... Maybe I can plug an 11 compliant compiler into it. Not going to start in with D or Boo etc etc - as I said in question, I may have to hit the job market again fairly soon and I want to have the mainstream languages for marketability, not the 'one offs'. LOTS of Python jobs out there - too bad I can't stand Python any more! – Vector Apr 21 '13 at 12:52
  • You have lots of options with C++: I consider C++ to be 'the mother of all modern languages'. It's like the Latin of programming languages. – Vector Apr 21 '13 at 12:55
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/8448/discussion-between-holger-and-mikey) – wirrbel Apr 21 '13 at 22:13