Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Orthodox C++ (2016)

bkaradzic.github.io

Post reply on HN
Print view View original

61–70 of 238 posts

Re: Orthodox C++ (2016)

#61

Post by rramadass »

greenbit wrote: post #26

Sometimes I actually want objects that are transparent, fully public, and 'struct' is perfect for that. But if I then go and put methods into those structs, does that make me unorthodox?

No, it is perfectly valid if your design demands it.

For example, the Windows MFC framework had classes whose data members were all public. Some of reasons were;

1) MFC was a wrapper over lower-level Windows API/structs and therefore unnecessary getter/setter methods were avoided. The C++ class could be a simple wrapper over the underlying C-style POD.

2) The framework classes were supposed to be used by implementation inheritance to build one's skeleton application which led to tight coupling between base and derived classes. Hence the designers decided to make all members public which meant that users were not limited by any omissions in the basic design.

I actually used these ideas in a project where i implemented a C++ api over C state machines for H.323 protocols.

Re: Orthodox C++ (2016)

#62

Post by kabdib »

wglb wrote: post #52
kabdib wrote: post #31

I've been doing embedded systems in C++ since rocks were young, and this is a great summary of what to avoid. I would sure love a good coroutine runtime, and first-class support for defer. You can do these manually, but language/toolchain/debugger support is nice to have. (Pragmatically, I will be retired by the time they would be useful)

It is still a bit amazing to me that it was significantly easier to do coroutines in Sigma 5 assembly and likely most any assembly than in C or C++. Two languages supposedly close to the machine.

I have seen a pure C/C++ implementation of coroutines (it used setjmp/longjmp, and memcpy to copy stacks in and out of the native arena). Not the most portable of constructions, but it worked absurdly well.

Being able to write "async" code essentially in-line is a superpower.

Re: Orthodox C++ (2016)

#63

Post by otabdeveloper4 »

badlibrarian wrote: post #13

If you're in a market that requires using C++, many of these decisions are made for you by the platform above you, and you're screwed. Turn on RTTI, build a fort to deflect the random exceptions they'll throw at you, and may the gods allow you to recoup your R&D before some well-intentioned yokel in some media or game vertical changes everything and requires you to change everything. On the other hand, if you control…

I interview C++ developers often, and here in 2026 it seems pretty much everyone is using modern (C++20 and up) language versions.

Maybe the tooling finally caught up.

Re: Orthodox C++ (2016)

#64

Post by kartoffelsaft »

rfgplk wrote: post #7

I've developed a style that I legitimately call Heterodox C++ (mainly due to the popularity of Orthodox C++), it is effectively a purely functional & metaprogramming heavy style of C++. Quite the opposite of this, not everyones cup of tea, and it won't fit into every codebase but it is incredibly powerful. The template metaprogramming C++ offers is the most powerful of any imperative language, and (subjective opinion…

> The template metaprogramming C++ offers is the most powerful of any imperative language

I'm curious what languages you're comparing to here. Feels like it's only slightly more expressive than pure generics, but I admittedly haven't done much template metaprogramming myself. How does it compare to, say, Zig's comptime?

Re: Orthodox C++ (2016)

#65

Post by gpderetta »

wavemode wrote: post #58
rfgplk wrote: post #45

Earlier quoted context omitted.

The standard library implements really do suck (in some cases), but this should be separated from C++ (the language). Even the standard splits the language grammar from the standard library cleanly.

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.

Re: Orthodox C++ (2016)

#66

Post by flohofwoe »

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 stdlib features that allocate under the hood are all justified by painful experience with those things in the context of game development.

In general, the restrictions outlined in the post make a lot of sense when considering that Branimir (of BGFX fame: https://github.com/bkaradzic/bgfx) is coming out of the game dev hemisphere, and from that PoV none of the restrictions are controversial - on the contrary, it would be highly controversial to suggest going all in on Modern C++ features ;)

Re: Orthodox C++ (2016)

#67

Post by [deleted] »

rfgplk wrote: post #8
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.

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…

[deleted]

Re: Orthodox C++ (2016)

#68

Post by patrick451 »

dataflow wrote: post #23
badlibrarian wrote: post #13

If you're in a market that requires using C++, many of these decisions are made for you by the platform above you, and you're screwed. Turn on RTTI, build a fort to deflect the random exceptions they'll throw at you, and may the gods allow you to recoup your R&D before some well-intentioned yokel in some media or game vertical changes everything and requires you to change everything. On the other hand, if you control…

> 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.

Re: Orthodox C++ (2016)

#69

Post by gpderetta »

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…

[from the linked article]

> : Needs a major performance overhaul", acknowledging that the standard's mandated block size is too small and the design needs to be rebuilt at the next ABI break

Except of course the standard does not mandate a block size. That's purely msvc picking a wrong block size and being stuck with it.

The rant about lists is also nonsense.

Re: Orthodox C++ (2016)

#70

Post by flohofwoe »

my-next-account wrote: post #40
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.

Implementing STL iterators are a bloody PITA

You don't need iterators for the range-based for loop, just a .begin() and .end() method which returns a raw pointer is enough.

E.g.:

https://github.com/floooh/oryol/blob/eb08cffe1b1cb6b05ed14ec...

(don't use that project though because it's been archived, I've switched back to plain old C in the meantime)

Post reply on HN