33

The problem I have, is that most of the C++ books I read spend almost forever on syntax and the basics of the language, e.g. for and loops while, arrays, lists, pointers, etc.

But they never seem to build anything that is simple enough to use for learning, yet practical enough to get you to understand the philosophy and power of the language.

Then I stumbled upon QT which is an amazing library!

But working through the demos they have, it seems like I am now in the reverse dilemma. I feel like the rich man's son driving round in a sports car subsidized by the father. Like I could build fantastic software, but have no clue what's going on under the hood.

As an example of my dilemma take the task of building a simple web browser. In pure C++, I wouldn't even know where to start, yet with the Qt library it can be done within a few lines on code.

I am not complaining about this. I am just wondering how to fill the knowledge void between the basic structure of the language and the high level interface that the Qt framework provides?

PersonalNexus
  • 2,989
  • 5
  • 27
  • 42
user866190
  • 539
  • 1
  • 5
  • 6
  • I'm not familiar with programming in Qt. Does it actually introduce any new syntax or change the language, or is it just some very sophisticated libraries? – FrustratedWithFormsDesigner Jan 06 '12 at 20:47
  • @FrustratedWithFormsDesigner It doesn't QT is the GUI Framework http://qt.nokia.com if you're interested – Karlson Jan 06 '12 at 20:50
  • Qt also offers an alternative to standard classes and containers (e.g. QString, QList, and so on) and a lot of other facilities. Some of them I find even more intuitive than the standard ones. I think it is a nice programming environment, but I would advise learning the core C++ language separately. – Giorgio Jan 06 '12 at 20:58
  • 3
    If you want to learn how Qt is implemented, just download and look at its source code. – user16764 Jan 07 '12 at 00:47
  • 1
    @Karlson Qt does add some things to the language, hence the need for the moc aka metaobject compiler. This adds some reflection and forms the basis of Qt's signals/slots system. – Tamás Szelei Jan 07 '12 at 14:13
  • It is nice to have an easy to use GUI library, which standard C++ and Boost don't have. The biggest single drawback to Qt is the cost of development, since the commercial use of Qt can be very expensive if your project needs to statically link to the Qt libraries. And if you don't statically link, welcome to dll hell. – Jim In Texas Jan 07 '12 at 16:08
  • See my very similar question @ http://programmers.stackexchange.com/questions/195568/qt-c-vs-generic-c-and-stl – Vector Apr 21 '13 at 07:51

8 Answers8

19

The most damage you will be doing to yourself, if you want to put it that way, is that you will not be learning to use the standard C++ data structures, iterators, algorithms and strings at all. Qt has libraries of its own for all those purposes, and you are all but forced to use them instead of standard C++ entities because Qt APIs only accept data structures of its own.

One could argue that learning to use one algorithms library after mastering other is a trivial task. Before going to an interview where the interviewers expect you to master C++, make sure you deal with that triviality beforehand.

otto
  • 1,184
  • 8
  • 14
  • 4
    Agreed- Qt uses an entirely different toolset altogether to Standard C++. – DeadMG Jan 06 '12 at 22:37
  • In our company there was a long debate whether one should use the standard containers and iterators or the Qt ones and we haven't come up with a solution yet: we ended up using both, even though we do not mix the two styles in a given module. I have the feeling that moving from Qt to standard is conceptually very easy, even though it will take some time. – Giorgio Jan 07 '12 at 13:17
  • 9
    I use the standard containers and algorithms inside my engineering models - i.e. my business logic. I use Qt containers inside my GUI code. This way my engineering models are protected against changes in Qt and vice versa. Qt has ways of connecting standard containers and their containers. – emsr Jan 08 '12 at 19:16
  • 2
    I don't care that much about containers anyway. They're not the most useful part of the STL; algorithms are far more important. Due the STL's design, its algorithms can easily work with other containers, and Qt containers are designed to work with STL algorithms. Win-win, really. – MSalters Jan 09 '12 at 12:49
13

Considering that Qt has its own meta-compiler that you have to process your source files with, it's hard to consider Qt code to be "just C++".

But more importantly, the style of C++ that Qt uses and encourages is something that, to the rest of us, was last seen around 1995.

Really, it's an attempt at making C++ as Java-like as at all possible. It misses out on, or discourages, all the amazing things that actually make C++ worth using today. Instead, you're locked into a subset which most of all feels like an inferior Java.

So if the goal is to learn C++, I'd say no, stay away from Qt. Perhaps take a look at Boost instead, if you want to use an established library as a starting point. Boost embodies the practices that are considered good today.

But honestly, if you want to learn the C++ language, then pick up a good textbook, and focus on the language.

Writing a web browser, no matter how you do it, will at best teach you about web browsers. It won't teach you much about the language you're using.

C++ as a language does not have a WebBrowser class built in. If you read the C++ standard, it says nothing about browsers. It doesn't even mention GUI applications.

That's because those things are built on top, provided by libraries such as Qt. C++, like any programming language, is about logic, about how to express that logic. And yes, that means working with arrays and pointers and loops and all those things.

Would you be able to write a web browser using just those built-in tools, given sufficient time? Would you know how to express the program logic involved? If not, then you need to spend more time on loops and pointers, and less calling new QWebKit() and just piggybacking off ready-made libraries.

The "philosophy and power of the language" is in arrays and lists and loops, not in web browsers.

gnat
  • 21,442
  • 29
  • 112
  • 288
jalf
  • 2,192
  • 1
  • 18
  • 22
  • 1
    I do not agree on one point: I do not think that certain programming techniques are _better_ just because they are _new_. I do not see a problem if one wants to continue to use a style of programming that was invented in 1995 because it fits his way of working. Of course, there are new, _alternative_ (not necessarily _better_, even though some could be) practices and they are welcome. But I do not think that one should drop a practice just because it is 15 years old and adopt another one just because it is new. Programming is not about fashion. Just my 2 cents. – Giorgio Jan 07 '12 at 13:31
  • 4
    I never said they were better *because they are new*. They are new and they are better. The point is that C++ as a language is just not very well suited for this Java-like approach. In C++, inheritance and runtime polymorphism is a pain, because it practically requires you to heap-allocate objects all over the place, which is what gave the language its reputation for memory leaks in the first place, because it's prone to slicing errors, because it makes copying objects harder. It's also inefficient, less extensible and requires more tedious boilerplate code. – jalf Jan 07 '12 at 15:47
  • 2
    Heck, Qt needs its own meta-compiler *just to make their style of programming bearable*. Doesn't that tell you something? – jalf Jan 07 '12 at 15:47
  • 2
    "Really, it's an attempt at making C++ as Java-like as at all possible." Then at least give the Qt team credit for great foresight, since Qt predates Java. – Jim In Texas Jan 07 '12 at 16:04
  • 4
    I was not defending Qt in itself (I see a lot of limitations in it myself). Your statement "the style of C++ that Qt uses and encourages is something that, to the rest of us, was last seen around 1995." With this formulation it is not clear what is bad with this style (other that it is 15 years old) and what the current, better alternatives are. Maybe if you are more specific what you mean will become clearer. – Giorgio Jan 07 '12 at 16:05
  • 1
    I also do not understand why one should be locked into a subset of C++ by using Qt. I have started using Qt three years ago and in the non-Qt parts of my code I use any additional technique or library if I find it good for the job. I would say that 10, 15 % of the application is Qt. – Giorgio Jan 07 '12 at 16:11
  • 2
    @jalf, do you work with Qt? Because if you do, then you know that memory leaks are a non-issue. You can either choose to use the QObject hierarchy or one of the many smart pointer classes for memory management. – Tamás Szelei Jan 07 '12 at 17:00
  • 3
    @JimInTexas: it also predates C++. Your point? In the early-mid 90's, C++ was a very different beast. It was much closer to what eventually became Java than it is today. – jalf Jan 08 '12 at 02:43
  • 2
    @Giorgio, Qt isn't exception-safe. You have no guarantee that Qt objects will behave nicely if an exception is thrown. How does that not lock you into a subset of C++? But what I really meant was that Qt is built on the assumption that *everything should be inside a QObject, and every function must be a member function". Those are absurd and pointless restrictions which are similar to those enforced in Java, but the certainly don't aid productivity. – jalf Jan 08 '12 at 02:44
  • @TamásSzelei: I do. And I know that their smart pointers are hardly ever actually used in most Qt code, they're recent additions, and they're based on the smart pointers that have existed in sane modern C++-style libraries for years. They're an admission by Qt that, frankly, modern C++ got it right, and 1992-style C++ did not. The QObject hierarchy is an ugly kludge to pretend that it's not necessary to think about object ownership or lifetime. And allocating every object with `new` incurs a major performance penalty. – jalf Jan 08 '12 at 02:47
  • "it also predates C++. Your point?" My point is that to say it's an attempt to make C++ 'Java like' is just wrong. It would be more correct to say that Java is an attempt to make a Qt like language. – Jim In Texas Jan 08 '12 at 18:51
  • 3
    @JimInTexas: Yes, it's wrong, but it should also hopefully be fairly clear what I mean. It is an attempt to achieve the design goals of Java, in C++. It's an attempt at implementing the same *flawed* OOP model that java implements. – jalf Jan 09 '12 at 08:02
  • @jalf - your 'flawed object model' has been implemented by virtually every modern programming language... Maybe on 21st century hardware, in large, complex systems, it's not so 'flawed' after all.... – Vector Apr 21 '13 at 07:46
  • @Mikey: or maybe there's just a lot of flawed code around. Are you seriously pretending that there isn't? (And perhaps all those complex systems would be less complex if they'd chosen a better programming language) And if your best argument is an appeal to popularity, then pardon me for not, well, being impressed. Perhaps you could instead tell me what's not-flawed about it. Why it is better than the alternatives. – jalf Apr 21 '13 at 08:34
  • @jalf - you are making some good points. But let's do it this way: you contended that the Java/Delphi/C# object model is flawed. I assume from you other remarks that your problem is that they all require the use of object references, which are essentially pointers to objects allocated from the heap. WHY do you consider this WRONG? According to your answer I will see what I can come up with. Maybe I'll agree with you. I know that when I use C++, sometimes the ability to quickly instantiate a class locally in a function on the stack is very convenient and quick. – Vector Apr 21 '13 at 09:57
  • 1
    @Mikey: I said nothing about object references or the heap being the problem, and I never claimed that C++ has a less flawed OOP model. It doesn't. It uses fundamentally the same model, but with a more half-assed implementation. Java (and C++ and the rest of this family) fundamentally misunderstood what OOP was supposed to be. Look at Smalltalk, or for a more modern example, Objective-C. Those (more or less) got OOP *right*. They have countless other flaws, of course, but they actually implement something like what the inventor of OOP says OOP *is*. – jalf Apr 21 '13 at 11:48
  • 2
    The other part of my point can basically be summarized as "screw OOP". Not everything has to be OOP, and OOP is far from always the best paradigm. C++ has realized this, and while it was born out of a desire to "OOP-ify C", it quickly turned into a multi-paradigm language, one in which OOP is not especially prominent, not for ideological reasons, but because when other paradigms are feasible to use, programmers naturally gravitate towards the best, most convenient, powerful, flexible and expressive option. And in practice, this means modern C++ is rarely very OOP. – jalf Apr 21 '13 at 11:51
  • At the same time, Qt clings to the idea that C++ *must* be OOP and nothing else, and not even *correct* OOP at that, because it tries to emulate Java, rather than SmallTalk. – jalf Apr 21 '13 at 11:51
  • @jalf - OK, I am not too familiar with Smalltalk or Objective C, but I do know that function calls work differently in those languages: message based,not type based. OOP not always being the best solution? I agree. So I love Delphi/C++ - support OOP but don't bind you to it. You can write procedural or functionally oriented applications and not use objects AT ALL. I take advantage of this, although I've found more recently that I prefer static class members instead of plain vanilla functions-for organizational/structural considerations mostly. BTW: C# and the CLR are FULL of static members. – Vector Apr 21 '13 at 12:07
  • @jalf: the 3 pillars of OOP are inheritance, polymorphism and encapsulation. Why do you say Smalltalk and Objective C 'got it right' more than Java/C++/C#/Delphi etc? How about Eiffel - I believe (been years since I tried messing with it) it is similar to Java/C# etc - and it is a pioneering OOP language. – Vector Apr 21 '13 at 12:12
  • 1
    Well, the simple answer is "because the guy who invented OOP says that it is what SmallTalk (and Obj-C) does and which Java does *not* (primarily being based on message-passing). I could also say that Java's approach is flawed because it fails to achieve the goals you mention. If I want polymorphism, Java is pretty much the *last* language I'd choose to use. Inheritance is an implementation detail, not a "pillar of OOP". It is one (not very good) way in which some of the OOP goals can be achieved. – jalf Apr 22 '13 at 11:33
  • @Vector The reason most modern languages use the heap-allocated object model is that some data structures require it. Therefore, if you only implement a single model, it has to be that one. Mostmodern languages are designed with simplicity as a key goal, so they tend to prefer having a single model. Simplicity is not one of C++'s goals. – Jules Feb 02 '15 at 08:16
  • Also, most modern languages that have high performance as a goal use a JIT compiler. Such a system can transform heap allocation operations to stack allocations on the fly, and undo the transformation if a reference to the object escapes the stack frame it was created in. C++ cannot do this, so using stack allocation is more important in C++ than, say, C#. – Jules Feb 02 '15 at 08:16
  • @Jules - I have to agree with you on that. One of the major things that complicates C++ design for me is deciding when to use pointers and references and when to use the stack. There are some broad guidelines out there but it's always an additional thing you have to think about when there's already enough on the table. That's one reason I prefer Delphi or C# for work that brings in money. :) I have even been messing around with GoLang, which **severely** limits your choices. But they didn't come up with reasonable limits. No exceptions? No inheritance? Lame IMO - a time machine back to 1990! – Vector Feb 02 '15 at 13:18
11

Do you want to know how stepping on the accelerator makes the car go faster, or do you only care that stepping on the accelerator makes the car go faster?

You are seeing the benefit to black box programming, which is a great way to design a system when all the boxes work. Someone has to make the black boxes though and if you want to be that guy/girl then you need to know more about the language than the guy using the box.

There are jobs that are good jobs in each style, so its up to you what you want to program. IMO you would be doing yourself a disservice though if you didn't put forth the effort to peel back some of the abstraction QT is giving you eventually.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Ryathal
  • 13,317
  • 1
  • 33
  • 48
  • 2
    "IMO you would be doing yourself a disservice though if you didn't put forth the effort to peel back some of the abstraction QT is giving you eventually." Your right and thats the gut feeling I have – user866190 Jan 06 '12 at 22:56
9

Is Learning C++ Through The Qt Framework Really Learning C++

Maybe.

I'd have to see the code you're putting in your event handlers.

Really though, don't be obsessed with how much you "know". We all use windowing frameworks and we're all still learning. Just keep coding/reading new things and you'll continue learning C++. Learning a new windowing framework is a great addition to your skills even if it might not mean you can implement a neural network or a quicksort in C++.

brian
  • 3,579
  • 1
  • 20
  • 22
5

Don't worry; at first most of your code will just use the framework, but after a while you'll have to extend it, even if just a bit. Then you'll have to use more and more of C++.

Also remember that you have the whole source of Qt available, the IDE will happily take you to the definition of any function/method/class you want. The deeper you go, the more C++ you'll see.

Others have mentioned about the difference between Qt C++ and standard C++. These fall in two camps:

  • different library: Qt includes all the usual containers: arrays, lists, sets, hashmaps, etc. They fit together very well and are good implementations, but they're not the STD variety. Still, in recent versions (4.1 and later, I think) they have 'STD-like' APIs in addition to the old variety (and a Java-like API). In the end, the design choices (when to use an array, when to use a hashmap) are the same, so changing to STD for non-Qt projects is not so hard.

  • moc syntax additions: mostly for signal-handling, but also a couple of nicer loop constructions. Lots of people feel this tool means it's not C++ anymore; but IMHO, they feel just like slightly smarter macros. A good loosely-coupled signal handling is a huge advantage of a good framework, and it's notoriously hard to do on a static typed language. In modern C++, it's doable with a heavy dose of templates; but that was far from standard when Qt first got moc. In the end, if you later want to do non-Qt projects, first check if you'll be using any framework and if it has signals. If yes, then most of what you're used to do with Qt will apply, so no 'harm' in learning Qt first.

Javier
  • 9,888
  • 1
  • 26
  • 35
  • What loop improvements are given by `moc`? – Basile Starynkevitch Jan 07 '12 at 12:42
  • @Basile Starynkevitch: Maybe he refers to the foreach loop (which I use heavily). This is a syntax addition but, ASAIK, this has nothing to do with moc. So you are right that maybe the answer should be formulated in a different way. – Giorgio Jan 07 '12 at 12:55
  • `foreach` is just a macro.... (actually an "alias" to `Q_FOREACH` defined in ``). I don't think that `moc` is processing it. And C++11 has the `for (auto it : container)` construct! – Basile Starynkevitch Jan 07 '12 at 13:06
  • @Basile Starynkevitch: Probably Qt would need a deep re-engineering if it had to move to C++11: Qt was designed for C++ (and also tried to overcome some of its limitations) therefore some of its solutions are not needed with C++11. – Giorgio Jan 07 '12 at 13:51
  • Moc is not only signals-slots and the foreach loop. It also adds metadata (reflecting slots and properties is possible). – Tamás Szelei Jan 07 '12 at 14:16
  • 1
    I use both Qt and Boost. There is a lot of overlap between the two libraries, but Qt is much easier to learn. – Jim In Texas Jan 07 '12 at 16:02
4

Qt is widely used in the commercial world because it provides a full cross platform toolset and development environment, including a good GUI library.

It also fully supports internationalization, including the excellent 'Linguist' tool.

If you plan an academic career then I wouldn't bother with Qt. If, on the other hand, you like C++ and want to learn a marketable skill then Qt is worth learning.

And yes, Qt is C++, and you can mix in the standard and boost libraries to your hearts content if that makes you feel better.

Jim In Texas
  • 1,453
  • 1
  • 11
  • 12
3

It is a bad idea to learn C++ through Qt. First you have to learn the language concepts independant of any framework and that is what c++ books will teach you and they are right. Basically, 'for and loops while, arrays, lists, pointers' are what programming languages are all about. Additional functionalities are provided by frameworks. Once you learn a programming language, you can learn any framework like Qt or MFC that is built using the language, so that applications can be developed quickly. Regarding Qt, once you learn c++, it is an excellent framework which makes you as productive as any Java or .Net developers. Shortly you will be able develop ios and Android apps using Qt.

Jaak
  • 39
  • 1
2

Well, I think the best way to learn C++ is by using its own syntax ONLY(Standard C++), so you will be able to use the LANGUAGE stuff, and NOT the Qt(or any other frameworks, libraries ...etc).

Why? because as a beginner, when you look at any C++ code mixed with other Non-C++ code(Qt in this case) you will not be able to see what is C++'s things and what is not, rather it will be more complex process.

CVist
  • 47
  • 1