
Ask HN: Which parts of C++ do I need to learn in order to use Qt? - bakery2k
I am looking to write a cross-platform GUI to sit on top of, and display the results of, some number-crunching algorithms. (The code to do the number-crunching calculations has already been written in C.) The consensus seems to be that Qt is the best toolkit for such cross-platform user interfaces.<p>Unfortunately, using Qt requires writing C++, a language I have very little experience with. Which parts of C++ do I need to learn in order to use Qt?<p>For example, it seems I will not need to learn the details of exception-safety in C++, as Qt does not use exceptions [1]. Similarly it will not be necessary to learn the details of the standard library containers, because Qt provides its own versions [2].<p>Are there any other parts of C++ which I can safely ignore if I only intend to use the language with Qt? Is there agreement on a subset of the language which forms &quot;Qt-flavoured&quot; C++?<p>[1] http:&#x2F;&#x2F;doc.qt.io&#x2F;qt-5&#x2F;exceptionsafety.html<p>[2] http:&#x2F;&#x2F;doc.qt.io&#x2F;qt-5&#x2F;containers.html
======
EliRivers
Inheritance; many Qt provided objects can (and should) be extended by you, to
provide more functionality while still being Widget objects that can be
displayed as expected and interact with other Qt objects. Coupled with this,
how to feed an object of derived type to something expecting an object of base
type, without slicing it or otherwise shooting yourself in the foot. Qt tends
to pass QObjects around with pointers, which does make it harder to get this
wrong.

Objects; they're all objects. Understand objects.

RAII/Constructors and destructors; managing object and resource lifetimes, and
suitably ensuring that visual widgets and other such Qt objects are created
and disposed of properly.

Threads; Qt Widgets (and your own objects) spark actions in Qt objects through
signals and slots (fancy Qt meta-programming that takes care of a lot of
boilerplate for you), that have rules about working across threads.
Understanding threads is needed to understand these restrictions, and the GUI
rule of "stay off the GUI thread" applies always, if you don't want to lock up
the GUI. This means you'll need to create other threads to do the heavy
lifting. You don't have to use standard C++ threads, but you'll need to
understand threading.

Don't use QList unless you really have a good reason, even if you find old
documentation saying you should.

~~~
bakery2k
Thanks for your reply. What little C++ experience I have is from several years
ago - do you think (again, purely in the context of Qt) that any of the new
C++11 features are worth using or should I stick to C++98?

~~~
EliRivers
As a rule of thumb, they're all worth using. C++11, to repeat something that's
becoming a cliché, is like a whole new language.

Even in the context of Qt, it's worth using some C++11. auto, lambda
functions, shared and unique pointers, (although QT has always provided its
own versions of these), C++ 11 threads. I code heavily with Qt and I use these
C++11 features daily. C++11 changes some things that used to be almost
impossible into possible, and some things that used to be awkward maintenance
headaches into natural and flowing code.

This is great; this is an opportunity for you to get to grips with some modern
C++.

------
Davidbrcz
\- I would advise you to focus on classes and object oriented programming. You
will be able to catch up with the C++ imperative part if you already know any
other imperative programming language. Keep in mind that you rarely ever need
to deal with manual memory management. The STL (or Qt's) does it for you.

For a book about C++, I'll would go with C++ Primer.

\- Qt by itself is a little bit weird, because it introduces its custom build
process and it mainly uses a signal/slot mechanism for communication (thinks
callback). Have also a look at Qt Quick, you can design an GUI without writing
a single line of C++. There is a list of books about Qt there :
[https://wiki.qt.io/Books](https://wiki.qt.io/Books)

------
brudgers
Irrespective of technology, at some point the backend, C in this case, has to
speak to the front end through some middle layer. Hopefully the middle layer
and the front end will be self contained for the sake of modularity,
separation of concerns, and avoiding the big ball of mud.

Charged with the task of making a GUI, I'd start with HTML, CSS, Javascript
and REST. Absent some compelling reason to pursue another course, that's where
I'd end.

Good luck.

------
dkersten
You can write your UI in QML and only use c++ to wrap your c code in qobjects
that you can access from QML.

This requires you to write a class that derives from QObject but that's almost
it.

Your UI logic in QML is written in JavaScript but you don't usually need much
and it's pretty straightforward to pick up as you go.

------
malux85
Depends on how complex your UI needs to be, but have you considered libui?

[https://github.com/andlabs/libui](https://github.com/andlabs/libui)

------
mponw
What about PySide or PyQt?

~~~
bakery2k
I considered using one of these libraries and writing the Qt GUI for my
application in Python rather than C++.

However, I would like to build the application into a standalone binary for
end-users to run on their own systems. This seems to be difficult with Python,
and when I was able to build such a binary (using PyInstaller on Windows) it
was large and slow to start-up.

(Qt itself is ~10MB (QtCore4.dll + QtGui4.dll) and (when using C++) can be
made smaller by static linking, but PyQt doubles the size (python27.dll +
PyQt4.QtCore.pyd + PyQt4.QtGui.pyd).)

