[gcc_programmer]

I think jupyter with C++ is an amazing idea, and I hope it will help more people to start with, in my subjective opinion, one of the most important programming languages today.

That being said, I look down on all the commentators who say that C++ has a primitive build system/package manager etc. Lets be clear: C++ has no package manager, and , in my view of the world, no compiled language has a native build system, its just that most compiled languages dont separate compilation from linking and also most languages support modules :)

C++ is hard. Throwing some fancy frontend and and a REPL will only make you realise that sooner. The complexity is mostly unjustified, but the language is so powerful that you could do anything with it: from trading strategies to power plant control systems to game engines. I have been studying C++ for 9 years, have used it for 7, and have been a professional developer for only 2.5 years, and I think I have only scratched the surface. I have used python for a lot less time but I feel like I am more comfortable with it because Python is trivial to learn (to a person with a comp sci background ofc). What you think you are cutting away (dependencies/build jnfo) is something essential to learning C++ and how everything comes together. Better learn it sooner than later imho.

Rant over

[weberc2]

> no compiled language has a native build system, its just that most compiled languages dont separate compilation from linking and also most languages support modules :)

Most modern, mainstream compiled languages have a build system that wraps around the compiler and linker. Invoking the compiler and linker are responsibilities of the build system, and frequently modules are compilation units.

Modern C++ is a neat language (I used to be a C++ developer) but it's tooling alone makes it unsuitable for any project where rapid iteration is remotely important.

[blackflame7000]

You're right about most compilers having a build system MSVC being probably the biggest.

Modern C++ when combined with Qt makes rapid iteration very doable. In my opinion Qt should be the standard c++ model.

[Matthias247]

QT follows a certain style, which is mostly object-oriented and heavily PIMPL based (it thereby compiles fast).

The consistent style is actually something nice. However lots of C++ programmers will not necessary like the OO style because it will lead to relatively slow programs. I guess with all the indirection which is going on and the metadata-based reflection and signal/slot system it might not really be ahead of even easier to use managed languages, which are even more convenient to use.

If you look at the Boost (or also C++11/14/17) libraries you will often find a very different programming style, which is heavily based on templates. This one is a lot harder to read and understand for non-experts, but it allows to achieve an even higher performance. The authors might think that this is the preferred model for C++.

[blackflame7000]

Qt is vastly more complex than the boost libraries due to the meta-object compiler and qmake build process. Furthermore the signals and slots are passed using lock free mechanisms and you will find they hold their own in benchmarks. The biggest advantage is the thread safety Qt affords. Not sure why you equate templates with expert programmer because often times template systems offer unacceptable build times on large programs. (The boost template object serialization library for example) Qt lends itself to writing more correct and simpler to digest code which any expert programmer will tell you is far more important than fast code

[Matthias247]

I didn’t imply in my post that boost is the better choice for experts. Exactly because I also don’t think that is always true. I only mentioned that lots of Boost libs are harder to use for beginners than Qt base once since one often needs to understand a good amount of templates. whereas Qt is mostly based on a sniper object oriented model with inheritance.

[weberc2]

Having been a former Qt developer, I couldn't disagree more. I have no desire to touch that dumpster fire again. To its credit, it's best in class, but that isn't saying much.

[blackflame7000]

I'm a fairly newer Qt developer so I really only have experience with QT5. Perhaps I was fortunate to miss the growing pains you seem to have endured. For me, the ease of doing cross-platform development along with the ability to create really high quality GUIs with QML made me fall in love.

[weberc2]

Qt5 is much nicer, but still a pain. QML is even better, just too coupled to Qt. Unfortunately you have a point that there isn't a better cross-platform native GUI toolkit.