It seems to be that people seem to apply a higher bar to being a master of C++ than they do to other languages.

Yes, it's possible to come up with "gotcha" questions that are hard to answer for C++. There are dark corners of any language, C++ has more than many to be sure.

Yet it seems that C++ detractors love to roam around in these dark corners far more often than actual serious users of the language do. It's very, very rare that I have run into a misunderstanding of the language that has caused a bug. What you almost always get is a compile error, which in fact, is exactly what you want.

It's not the new features causing the bugs, it's the old ones.

It's uninitialised variables, dangling pointers, undefined behavior, etc etc etc.

And guess what, it's the new C++ features that are making those kinds of problems rarer and rarer as time goes on. It's starting to get pretty damn hard to use-after-free or leak memory.

I love to bring up Python examples, as it is thought of being a beginners friendly language, yet many seem unaware how big the language, standard library and behaviour changes across releases actually are.

My biggest issue with python is distribution: it’s a much worse headache to try to ensure your product works on other people’s machines (Python versions, dependencies, and anything with Cython just makes things worse) than just requiring a C++14-compliant compiler.

Moreover the sources written for versions >= 3 are serioosly not guaranteed to work on different 3.x versions.

Yeah, I'm learning Python now and was working through the book Learning Python which covers Python 2 and 3 there are plenty of differences to trip you up.

I used to be on the c++ committee and contributed to both gcc and clang. That T&& r-value mess, along with c++ still having no built in method to print a vector, are the straws which persuaded me to abandon c++. It seems designed to be confusing.

> c++ still having no built in method to print a vector

This a thousand times. All the best languages have a good way to print out a structure, and allow interactive inspection. Instead with C and C++ we have to suffer with debuggers rather than just using good old print statements.

Enjoying the productivity of debuggers since mid-90's, with ability to graphically display data structures.

Printf debbuging is the actual suffering.

I think both are good tools and in many cases using printf or writing to a log file are very good options instead of loading a debugger.

That is what trace points allow for, without having to touch the original source code.

Nah, sometimes using a debug build changes too many things, and being able to debug a release build is still valuable.

Who said you need a debug build?

You think that print debugging is wrong and debuggers are the way to go?

Yes.

There is a time and space for print debugging or its equivalents, like when debugging very low level code, or when debugging rarely occurring problems.

However, using a real debugger is extremely powerful when it's available.

Definitely, printf debugging is a tool left for the few cases where a proper debugger, jtags, intelitrace, dtrace, jmx, flight recorder, and other similar technology isn't available.

With a graphical debugger, how do you produce a log-trace of what your program did?

How do you show a table of just the information you need, to help you find a bug? What if the table is a join of multiple datastructures from distinct locations?

How do you, after stepping forward through the code until you reach a certain configuration, make a small modification to the logic, so that you can replay from the start with the intent to reach a slightly modified configuration?

Are graphical debuggers on par with simply print debugging to notify when a particularly complicated situation occurs that can only be described by a complex logic?

I mentioned already a few possibilities, as I was expecting that question.

Edit: Since you edited your question after I replied, all those use cases are still covered by intellitrace, dtrace, flight recorder, jtags, with the benefit of not having to recompile the code.

Naturally you can come up with wicked examples that those tools don't cover, then again they will be most likely irrelevant for the large majority of devs.

Which raises the question, how are these not print debugging? How are they better than print debugging?

I admit I don't know any of these tools, but I hope (1) they don't introduce another language than the one the project is coded in, (2) they let you put the logging statements inline in the code since otherwise the debug setup would be hard to synchronize to the actual code.

The situations I described are not particularly wicked, but rather normal debugging. If the bug is not trivial (in which case an interactive debugger can help finding it quickly), then the process is always to start with a global but coarse view, decide where the bug likely is, and zoom in on that partial view, requesting more details.

I doubt any automated system can help much there. Automatic structure printing might already not work for many cases since it prints too much data, or formats the data in a way that is too mechanical and not fitted to the task. Or in case of object-languages, the system does not now how "deep" it should print these structures.

I think automatic structure printing is a nice to have for simple situations with few structure fields. In practice I'm almost always fine with typing a printf line manually. I don't think that typing and modifying the line as I go would take the majority of my debugging time.

I use interactive debuggers myself, and I think they are faster in simple cases since there is no edit-compile-rerun cycle. But like all interactive GUIs, they are not (or only badly?) scriptable and automizable.

They are better than print debugging because they allow to even instruct applications in production without having to do any change to the application.

Stuff like DTrace and Intellitrace have OS level support to integrate with the application being instrumented, execute whatever actions are required and interoperate with the debugger. Intellitrace even goes as further as supporting time travel debugging.

Yes some of them, e.g. DTrace, do have their own little scripting languages.

c++20 gets a new formatting library based on fmtlib which is able to print data structures.

    std::vector<int> v = {1, 2, 3, 4}

    std::copy(v.begin(), v.end(), std::ostream_iterator<int>(std::cout,” “));

Kinda long but gets the job done.

Now do it when v is a vector of vectors.

A single template implementation of vector allows vectors of vectors in the first place. Just add a single template print function.

The actually confusing part is that && has two different meanings:

Rvalue reference, the passed value either has no memory location yet or has a memory location that won't be accessed anymore (e.g. Marked with std::move)

     void foo(int&& a)

Universal reference. `a` is inferred as an rvalue reference if it is initialized with an rvalue and a normal reference otherwise:

    template <class T>  void foo(T&& a)

So && with type deduction tries to forward rvalue-ness. It does a terrible job, though, which is why std::forward exists.

Not claiming it's easy, but see http://jlebar.com/2016/5/28/A_Practical_Introduction_to_C%2B...

Side steps the perfect forwarding part.

I thought the post was kind of long enough as is. :)