Hacker News Reader

Comment by keikobadthebad | Hacker News Reader

> The comment in question begins “My take on C++ is that the best programs only use a fraction of the features.” The commenter further states that he is weary of operator overloading and templates.

> In my experience, people who make comments like the above tend to be people who think they are C++ experts but who are actually only novices. I do not know the commenter personally, so I’m not trying to say anything about him specifically.

> I only have 4 years of experience with C++

... I am only a C expert, but I agree with the Slashdot guy. After spending years as a believer like the author, I realized all this class-ification effort was pure waste, since most of it would never be reused. Same with all the idiomatic conversions. Don't get me started on boost.

I withdrew from the cult and get just as much done with high quality C in half the time.

View on HN

I went from "c++ fondness" to "c++ distaste" over the years. The newest c++ standards fix a lot of issues, but at the same time increase complexity. The backwards-compatibility nature is the classic double-edged sword. If we could avoid it, c++ would be at least significantly nicer (not really less complex).

That being said, a good team using a dab of c++ will beat "high quality C" any time of the year for me. Getting away from the preprocessor alone is huuuuuuuge. Everybody complains about memory safety, and the truth is that with even the dumbest string/buffer class it's actually pretty trivial to do the right thing. c++ _does_ really fix most of the c issues IMHO.

A big problem IMHO is that we "learned" to use c++ properly late. The newest standard revisions came late. The feature abuse it receives is still somewhat rampant, and yes a newcomer to c++ would probably find a use for every single feature in a simple usage scenario.

Reading large c++ codebases is hard due to the intermixing of old/new and simply different styles. It has a huge cognitive load, and that is my primary reason for the growing distaste: I want code to be clear and coherent. I can take the complexity if that's used consistently, but it can change massively between even just PARTS of a project.

> It has a huge cognitive load

This. Its like trying to keep three distinct languages (C, old C++, new C++) in one's head at the same time. It is much better use of one's mental energy to spend that effort on three actually distinct languages that are, e.g., tuned to different domains and use cases.

Imho the C++ community needs to address this or eventually become irrelevant as people gravitate to more sane and user-friendly ecosystems. Not sure how that can be done without breaking some eggs. My preference would be for a simplified and streamlined C+++ that tackles this complexity head on.

> or eventually become irrelevant

That's exactly what it should do. Stop adding features, keep the standard stable, let new languages slowly take over. The C committee's approach is quite close to what I would like to see.

In my opinion there are two C++'s:

1) the version used by people writing things like the STL/Boost

2) the version used by people writing apps.

A huge amount of the updates to the language are to make the lives of people in category 1 easier.

The people who fall into category 2 really don't need to use all the template headachery that the language allows. They can if they want, but they probably don't have to.

I've noticed that the Boost people are now deprecating old versions of C++. I look forward to hopefully quicker build times. To be fair, the Boost codebase is a masterpiece of working around decades of C++ versions and compiler bugs/missing features. Obviously that makes the code largely incomprehensible to newcomers.

Templates are amazing at helping to extract performance from things by moving run time decisions to compile time when done well. I usually only go there when the profiler points me somewhere is either acting as a bottleneck or something requires to perform better. You can then even decide to go even further through branching to cases you can go into SIMD intrinsics.

I believe the same is applicable in other languages. Complicated types and class structures quickly become unwieldly, it's much better to use simple types and not rely on polymorphism too much.

> I realized all this class-ification effort was pure waste, since most of it would never be reused.

I don't think this is a valid take. Classes are not about reuse at all. They are about encapsulation and specifying types/providing interfaces.

> Same with all the idiomatic conversions.

What's your complain about idiomatic conversions?

> Don't get me started on boost.

Why is Boost, or any library at all, relevant in a discussion about C++? Should our opinions on C++ vary if we mention POCO, Abseil, or even Qt?

Frankly, I don't think your personal takes are well informed. It sounds like you struggled to use something different than something you knew expecting that you could simply keep writing the same code in any other programming language, and subsequently started complaining that other languages are not like the one you used. That's hardly a critique of any other language, and instead it's insight on how developers who succumbed to crystallizing their expertise end up suffering from their inability to adapt.

> Why is Boost, or any library at all, relevant in a discussion about C++?

I don't have a dog in this fight, but I've been following the scene since early 2000s, a lot of boost made it into the standard. FYI.

Yes, but it is for the better. Although it had the side effect of making boost less relevant.

> (...) a lot of boost made it into the standard. FYI.

Some components that have been proposed to be admitted to the C++ standard were also contributed to Boost, but that's about it. There are far more components in Boost that were never even considered for the standard than the ones that were.

Nevertheless, the relevant part is that Boost is not nor it ever was C++, or representative of C++. Conflating third-party libraries and frameworks with the C++ programming language is at best a pointless straw man.

> Some components that have been proposed to be admitted to the C++ standard were also contributed to Boost, but that's about it.

Reality is: boost libraries were created, widely adopted, and once interfaces stabilized, we got technical reviews from wg21. Not the other way around.

So the point is moot.

> Why is Boost, or any library at all, relevant in a discussion about C++?

It’s what the article uses to make its point. Did you read it?

Worth noting that the article is from 2007. As of C++11 (from 12 years ago) you can write the equivalent code with just C++ and the standard library (range-based for loops, std:function).

Class composition is about reuse. Class inheritance isn't.

That may be the case in practice but it is not literally true, since semantically, inheritance is effectively a form of copy-and-paste in the compiler. It is literally about reusing components written elsewhere. I would argue that both are forms of code reuse, with the latter also having consequences for type checking.

> That may be the case in practice but it is not literally true, since semantically, inheritance is effectively a form of copy-and-paste in the compiler.

No, not really. The whole point of inheritance is declaring new types by implementing specifying interfaces in a way that specify type hierarchies.

If your goal was code reuse and "copy-and-paste" then nothing would beat composition. If you decide instead to go with inheritance, you have far more requirements to meet that go way beyond code reuse.

> get just as much done with high quality C in half the time.

Bullshit. C++ may have plenty of warts, and sometimes people go way OTT with templates (90% of Boost), but there's no way you're writing code as fast in C as C++ unless it involves no string manipulation, pointers, containers, etc.

String manipulation alone is so awful in C that there's no way you're right. But throw in smart pointers, collections, JSON, regex, etc... All of which are much easier to use in C++ and either built in, or in JSON's case, easy to add.

If you're literally just doing basic maths, then maybe. But how many programs are like that?

This. C++ is awful in many ways, but it can be much nicer than C for writing _application_ code. Use RAII, avoid deep class hierarchies, restrict yourself to the STL and use smart pointer types for lifecycle management. That’s it for starters, you will write much better code than in C.

Then you opt in to certain features like templates or operator overloading based on your bike shedding level.

>Bullsh*t.

Please keep the quality of conversation high here. Thank you.

> Bullshit. C++ may have plenty of warts, and sometimes people go way OTT with templates (90% of Boost), but there's no way you're writing code as fast in C as C++ unless it involves no string manipulation, pointers, containers, etc.

For many of those things, maybe he already has existing libraries (strings, containers) that have been tested in the field?

Sure, it won't make him faster than in C++, but his speedup could come from needing to allocate less cognition to the language and more to the problem he is solving.

Even expert C++ programmers, who have been doing it for decades, still need to lookup language stuff for C++ in the odd corners. Someone who hasn't been focusing on C++ in depth, but has instead been focusing on the problems over their career might be faster in C than in C++.

It's a trade-off (isn't everything?): lookup everything in the language as you develop vs lookup nothing, or already know a lot and develop faster vs know very little and develop slower.

(I use "know" to mean "knowing the language and libraries")

Reply on news.ycombinator.com