[sfpotter]

There are so many reasons. I'm sure others will provide their own favorites.

One that I find particularly annoying lately: if you work on a project that makes heavy use of the STL (or, really, any heavily templated library written in a similar style, with a focus on "ergonomics" :-( ), you'll quickly find that backtraces for debug builds can easily be 50-100 levels deep with most stack frames just consisting of incomprehensible layers of abstraction which get optimized away. So, debug builds are totally useless, and build times are typically long. Contrast that with something written in "C style" or simply making far fewer use of C++ features, written in a more straightline style, with fewer levels of abstraction: builds will be fast, stack traces will be small and can easily map directly onto the concepts relevant to the program or library, and debug builds are useful once more. Night and day difference.

[SleepyMyroslav]

It does not have to be night and day. In gamedev I saw over years that giving up debug builds for a set of your own abstractions has benefits. You do not have to use STL or exceptions so you can have a balance in your build times. Having abstractions in the code has a lot of value. People overestimate how hard is to do deoptimize on checkout or on demand which solves most of debugging needs.

[sfpotter]

I appreciate the sentiment of what you're saying, but I guess I'm not totally sure what you mean by "abstraction". Maybe "abstraction" is the wrong wording for my original post... For example, in boring code you can have "abstractions" in the form of data types that model high-level concepts along with high-level functionality on them. I'm not at all opposed to that. The "Sane C++ Libraries" linked seem to be a reasonable example of this style. There are no features in C++ that you absolutely need beyond what's offered in C to do this.

Maybe as an example just compare a library like Eigen to a similar imaginary library written in C.

Eigen leans heavily on C++ features to reduce line count and make something look visually more mathematical or maybe more MATLAB-style in the name of ergonomics; and obviously on the backend it relies on the behavior of the C++ compiler to simplify the elaborate template expressions and make the code efficient. If you ever try to step through code that uses Eigen in a debug build or examine a stack trace from inside Eigen where an exception has originated, the situation is not pretty! Contrast this with what will happen in the imagined C-style library. If all the heavy lifting happens in BLAS or LAPACK and the C library is basically a thin library to make things a little more automatic and easier to manage, the stack traces will be short and each stack frame will be easy to digest at a glance because of names like "mat_mat_mul" or similar, instead of "mat<double, double, 4, allocator<...>> const & operator*(mat<double, double... 159 more characters of template gobbledygook that makes the eyes glaze over)". The former will also be significantly faster to compile.

Anyway, I guess I just don't see how the latter STL/Eigen/whatever-style approach to things is an improvement over the far simpler idiot style of doing things.

I'm not trying to be argumentative here, I just want to clarify my point as much as possible.

[SleepyMyroslav]

yeah, you have it completely consistent.

My point is that one can have a lot of C++ working at scale. Reading code is very important part of large scale projects. Dropping debug builds is a reasonable tradeoff.

[sfpotter]

OK, got it... I suppose that's reasonable, but depending on what you're working on, I'm not sure seriously reducing the debuggability of your project is acceptable. For the kind of work I do, I need a debugger.

I would also argue that keeping it so that you can always easily run your project "REPL style" from a debugger exerts a very favorable downward force on all the complexities that make large projects hard to maintain.

[jeffbee]

In decades of professional C++ experience I have never noted depth of backtrace as a usability issue. Give us an example of how a 100-deep backtrace arises as a consequence of the STL.

[summerlight]

Agreed, at least for STL containers I didn't really have to dig into the implementation for 99.9% of the cases. One or two specific old cases were due to memory corruption, but nowadays address sanitizer should do the job. Of course, a lengthy symbol for heavily templatized functions/classes can sometimes be a problem, but it's a separate issue from stack trace depth.

[sfpotter]

"Functional" C++ with deeply nested loops implemented using stuff from <algorithm> and <functional> and lambda.

[o11c]

Before concepts it was certainly possible, but when it happened you just had to add some extra type assertions to make it clear where the error is.