Orthodox C++ (2016) • Hacker News Board

Re: Orthodox C++ (2016)

#81

Post by dataflow » Sat, Jun 13, 2026, 7:12 PM UTC

patrick451 wrote: post #68

dataflow wrote: post #23

Earlier quoted context omitted.

> build a fort to deflect the random exceptions they'll throw at you Sounds like you hate exceptions, right? In which case why do you handle them at all? Just leave them all unhandled and suddenly every exception is a crash. Which is really no different from someone choosing to terminate. Which you have to worry about even without exceptions. > if you have a C++ code base yet somehow have enough time and energy to wr…

> Which is really no different from someone choosing to terminate. If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.

That's nice but it's certainly not guaranteed by anything, just something provided by your toolchain or platform. ("Core dumps" aren't even a thing in C++.)

If you're looking for implementation-specific guarantees then you could make that happen with exceptions too. I think on GCC replacing a function like __cxa_throw might be sufficient to let you capture a stack trace?

If you're looking for source-level-only guarantees then another option is to just replace your throw statements with one that attaches whatever extra info you want. You could literally script this to patch your external repos automatically too. Or heck, maybe you could even just define throw to be a macro that shoves your stack trace into some global variable before actually throwing.

Re: Orthodox C++ (2016)

#82

Post by pjmlp » Sat, Jun 13, 2026, 7:15 PM UTC

lelele wrote: post #78

pjmlp wrote: post #50

Earlier quoted context omitted.

Just like any C function without looking into the translation unit, don't say you blindly believe on the function name.

Not really. C++ is on another level altogether: the code could be calling implicit conversion operators, the compiler could have instantiated some template code in an unforeseen way, and so on. Years ago, I was really proficient in C++, but after a year of programming in C#, I realized that not once had the behavior of my code caught me off guard. In the following years, I only ran into quirky behavior a couple of ti…

I suppose you're aware C# also has implicit conversion operators, operator overloading, reflection, aspect oriented programming, compiler plugins, interceptors.

Seems strange to talk down C++ while praising C#, which incidentally has been getting features to increase its use where Microsoft previously might have used C++ instead.

You catch pitfalls in any language the same way, using static analysis, which C authors introduced right in 1979, acknowledging the issues with language, which they decided to outsource to another tool, instead of improving the language.

A long tradition in computing.

Re: Orthodox C++ (2016)

#83

Post by stinos » Sat, Jun 13, 2026, 7:26 PM UTC

jstimpfle wrote: post #42

rfgplk wrote: post #8

Earlier quoted context omitted.

One thing I've noticed about a lot of these "strict C" developers is that quite often they actually refuse to learn C++. One of the most common complaints of C developers regarding C++ is "it does things behind the scenes/performs magic", often with regards to operator overloading. When they refuse to actually look at the implementation (y'know you can check if an operator has been overloaded) AND they refuse to ackn…

Trust me, I know more C++ than most or all of my peers (working two jobs simultaneously), and I know a million ways that C++ features suck. Also standard library and containers. If you want I'll point out the ways in which std::deque, and even std::map, std::unordered_map, even std::vector (!) suck. IMO, just don't do it.

and even std::map, std::unordered_map, even std::vector (!) suck

It's really hard to take your comment serious because of generalization like this. Maybe they're not usable for your particular usecase but that doesn't mean they suck. Just like there's a 'million' ways that C++ sucks in your book, there's a reason there's millions of lines of code out there where these containers are valid usecases and hence work without issues whatsoever nor a need to replace them with something else.

Re: Orthodox C++ (2016)

#84

Post by jstimpfle » Sat, Jun 13, 2026, 7:27 PM UTC

gpderetta wrote: post #65

wavemode wrote: post #58

Earlier quoted context omitted.

You can't really separate the two, firstly because some parts of the standard library interact directly with the language's syntax (e.g. ), and secondly because the language standard dictates things about the behavior of the standard library that limit implementation options. For example, the standard says that adding elements to an is not allowed to invalidate references to keys or elements within the map. That make…

Which sucks... unless you really need reference stability.

std::vector has left the chat.

Re: Orthodox C++ (2016)

#85

Post by jstimpfle » Sat, Jun 13, 2026, 7:39 PM UTC

stinos wrote: post #83

jstimpfle wrote: post #42

Earlier quoted context omitted.

Trust me, I know more C++ than most or all of my peers (working two jobs simultaneously), and I know a million ways that C++ features suck. Also standard library and containers. If you want I'll point out the ways in which std::deque, and even std::map, std::unordered_map, even std::vector (!) suck. IMO, just don't do it.

and even std::map, std::unordered_map, even std::vector (!) suck It's really hard to take your comment serious because of generalization like this. Maybe they're not usable for your particular usecase but that doesn't mean they suck. Just like there's a 'million' ways that C++ sucks in your book, there's a reason there's millions of lines of code out there where these containers are valid usecases and hence work with…

They're not useable for anything serious, i.e. high throughput, low frequency, massively concurrent work. In other words, most of the things for which you shouldn't better have chosen a different language in the first place.

They're also unusable by the way because of ergonomic and software architecture factors, such as bad modularity, terrible compile times, unreadable error messages, unreadable symbol names...

Yes that is overgeneralizing a little bit but it's largely true.

The problem is typically not the containers themselves but all the other bad decisions that they push you to make in order to work around their "small issues".

The huge problem is that these containers can get you started quickly, i.e. leetcode type stuff and single threaded stuff, but at some point you'll realize your architecture ended up completely in the wrong place because of that.

If you haven't been thinking deeply about memory management and concurrency, you won't be able to understand, no offense meant. I've just fixed another subsystem that was completely overwhelmed, seeing 8x bandwidth gains already on a small testsystem, but the factor is basically unbounded when moving to bigger systems, when it's about contended vs uncontended.

Re: Orthodox C++ (2016)

#86

Post by PaulDavisThe1st » Sat, Jun 13, 2026, 7:54 PM UTC

flohofwoe wrote: post #66

PaulDavisThe1st wrote: post #2

You can take for (auto const & ess : esses) { ... } from my cold dead hands. Also, you can fight me if you want to take dynamic_cast (base_ptr) and force me to implement my own typing system every time I need to upcast. Basically, stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.

> for (auto const & ess : esses) { This is allowed by Orthodox C++ > dynamic_cast (base_ptr) This isn't because it requires RTTI, but dynamic_cast is also a typical code smell. Orthodox C++ isn't generally against new C++ features, it only advices to wait about 5 years (or at least one C++ version) for stabilization and to apply some common sense before adopting them. The notes about not using RTTI, exceptions and st…

> This is allowed by Orthodox C++

I can see no rationale for this whatsoever. It is nothing but syntactic sugar.

> Branmir (of BGFX fame

Appeals to authority don't really work for me.

I've been writing a cross-platform DAW (0) for 25+ years, in C++, and what a game dev has to say about the language in their own work might be of passing interest but not much more.

Being aware of the pitfalls of particular features of a language is an important task for anyone programming in that language. But that doesn't mean that the language is fundamentally broken or that programmers cannot make their own choices about which features to use.

(0) on at least the same level of complexity as a modern game

Re: Orthodox C++ (2016)

#87

Post by lelele » Sat, Jun 13, 2026, 7:54 PM UTC

pjmlp wrote: post #82

lelele wrote: post #78

Earlier quoted context omitted.

Not really. C++ is on another level altogether: the code could be calling implicit conversion operators, the compiler could have instantiated some template code in an unforeseen way, and so on. Years ago, I was really proficient in C++, but after a year of programming in C#, I realized that not once had the behavior of my code caught me off guard. In the following years, I only ran into quirky behavior a couple of ti…

I suppose you're aware C# also has implicit conversion operators, operator overloading, reflection, aspect oriented programming, compiler plugins, interceptors. Seems strange to talk down C++ while praising C#, which incidentally has been getting features to increase its use where Microsoft previously might have used C++ instead. You catch pitfalls in any language the same way, using static analysis, which C authors…

Yes, C# is becoming more and more complex, but IMO C++ is still in a class of its own. Just compare how many different, sometimes competing ways there are to initialize variables in C++, each with its own subtleties.

I guess we'll have to agree to disagree here. And of course, even if C++'s user base seems to be shrinking, it still works well for some categories of programmers.

Re: Orthodox C++ (2016)

#88

Post by PaulDavisThe1st » Sat, Jun 13, 2026, 7:57 PM UTC

canyp wrote: post #56

My codebase uses a fairly dumbed down version of C++, but I would have liked to see more depth in this post. As it is, it is not very useful. There are many more things to avoid than just iostream. HFT university has a good recap: https://hftuniversity.com/post/the-c-standard-library-has-be... The point on exceptions I think is also misleading. Compilers typically make throwing an exception the expensive part, and th…

> There are many more things to avoid than just iostream.

But even "avoiding iostream" is stupid. The author presumably really means "avoid operator>> and operator<< for I/O". Even using type-safe printf-like stuff ultimately still sits on top of iostream.

Re: Orthodox C++ (2016)

#89

Post by wavemode » Sat, Jun 13, 2026, 7:58 PM UTC

nly wrote: post #75

wavemode wrote: post #58

Earlier quoted context omitted.

You can't really separate the two, firstly because some parts of the standard library interact directly with the language's syntax (e.g. ), and secondly because the language standard dictates things about the behavior of the standard library that limit implementation options. For example, the standard says that adding elements to an is not allowed to invalidate references to keys or elements within the map. That make…

Your map example only concerns the standard library, not the language.

Its behavior is dictated by the language.

The context of this thread is that someone stated that the C++ standard library sucks, and someone replied to them saying that it's just some implementations that suck, but that's separate from the language. The point I'm trying to make, in response, is that it is about the language. It's not just "some" implementations - there is no implementation of the C++ standard library that doesn't have these inefficiencies, because the language's own standard requires them.

(This is tangential but - this is why I often say that C++ is not actually the most complex language in the world, it's just over-specified. If you took almost any popular programming language and wrote a document dictating the behavior of every single feature and library to the same level of detail, you would end up with a document similar in length or even longer than the C++ standard.)

Re: Orthodox C++ (2016)

#90

Post by PaulDavisThe1st » Sat, Jun 13, 2026, 8:00 PM UTC

jstimpfle wrote: post #38

maxvu wrote: post #37

Earlier quoted context omitted.

How about one of the C unorthodoxies that use typedef everywhere? (Namespaces seem suitable, too.)

typedef is a little bit of a hassle but you can do it, even in a very strict mechanical way if writing plain C. But it's a hassle. And namespaces suck too, so much noise for little gain. You know what, a big part of programming is naming. You just have to come up with good names. Namespaces don't magically make names better, if anything, they make them worse. And they add a lot of syntax noise.

tell me you never use platform-provided or third party libraries without actually telling me.