11 ms·

Orthodox C++ (2016)

108 points by signa11 4mo ago

yyx 4mo ago
At this point, if you want better C, just use Zig.
- pjmlp 4mo ago
  Except it is years away of being 1.0, with the industry support of C++.
PaulDavisThe1st 4mo ago
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<Derived> (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.
- rfgplk 4mo ago
  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 acknowledge that a huge chunk of "pure C" does HEAPS of magic behind the scenes (that the developer has no idea about) unless they've actually studied the spec in detail. Malloc and memory allocation methods are at least 10k+ lines of code for instance.
  - 01100011 4mo ago
    A lot of us are too busy solving problems. Learning about the latest language features, which we often won't be able to use anyway due to the trouble of moving a large dev environment to a newer standard, feels like academic masturbation. C++ folks are very much into their language, and can't seem to understand that most folks don't want to dedicate significant amounts of mental resources purely to language details.
    - pjmlp 4mo ago
      Like implementing the compilers used by C devs.
      - uecker 4mo ago
        GCC was implemented in C and there are plenty of other C compilers written in C. GCC has been converted to C++ at some point, but large parts are still essentially C and I do not think the change to C++ was actually helpful (but others may disagree). In any case, the idea that one needs C++ to have C compilers is certainly simply wrong.
        delta_p_delta_x 4mo ago
        Clang/LLVM with its more permissive licence sees _much_ wider use and is written purely in C++. PlayStation, automotive, platforms and runtimes like Chromium/V8, Android, etc. are all built with Clang.
        uecker 4mo ago
        How is this relevant? (also wider use for C I would doubt)
        lelanthran 4mo ago
        Clang usage is a fraction of GCC usage. Regards, an embedded dev.
        pjmlp 4mo ago
        A decade ago surely, in 2026 I doubt it. With Android, iDevices, PlayStation, Switch, and everyone that had proprietary compilers down using downstream forks from clang, due to the more appealing license. Who is left still using GCC, other than existing projects lacking a clang backend for a snowflake embed CPU? In any case, if it is a modern GCC release past 2012, it was compiled with C++ as well.
  - IncreasePosts 4mo ago
    If we accept the maximum that "any sufficiently advanced technology is indistinguishable from magic", then c++ is indeed magic. It's so advanced that one of the worlds foremost experts in the language(herb sutter) has determined that the language is too complex and we need a whole new language(confront) which is simpler and can be converted to c++.
    - rfgplk 4mo ago
      C++ is actually obscenely complex, I don't deny that. Just mastering object lifetime rules is crazy difficult due to all the edge cases, but it comes with the territory.
      - tialaramex 4mo ago
        > it comes with the territory In the sense that C++ is complicated because it's C++, which is complicated? That's just a tautology. If you mean "the territory" in some other sense there's no reason to believe this.
  - lelele 4mo ago
    > y'know you can check if an operator has been overloaded And there lies the problem with C++: to be sure, you have to check. C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb.
    - LoganDark 4mo ago
      > C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb. You can't take C code at face value either. The name of a method or type doesn't tell you what it does. It could longjmp for all you know.
      - lelele 4mo ago
        See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416 https://news.ycombinator.com/item?id=48520416
    - rfgplk 4mo ago
      But isn't this a problem with all code? Looking at a Rust function signature how can you be sure that it does what it says it does? Or python?
      - lelele 4mo ago
        See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416 https://news.ycombinator.com/item?id=48520416
      - dwattttt 4mo ago
        To the extent that one doesn't try to suppress compiler warnings & errors / actively break the language, you get what the compiler confirms is true about a function signature. For Python, it's very little (nothing?). For Rust, you get more than most; lifetimes tell you whether it holds onto a pointer you give it.
    - pjmlp 4mo ago
      Just like any C function without looking into the translation unit, don't say you blindly believe on the function name.
  - jstimpfle 4mo ago
    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.
    - rfgplk 4mo ago
      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.
      - wavemode 4mo ago
        You can't really separate the two, firstly because some parts of the standard library interact directly with the language's syntax (e.g. <initializer_list>), 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 <unordered_map> is not allowed to invalidate references to keys or elements within the map. That makes it impossible for any standards-compliant C++ implementation to use a high-performance implementation in which keys and elements are stored contiguously in a flat array.
        gpderetta 4mo ago
        Which sucks... unless you really need reference stability.
        jstimpfle 4mo ago
        std::vector has left the chat.
        nly 4mo ago
        Your map example only concerns the standard library, not the language.
  - deleted 4mo ago
    [deleted]
  - flohofwoe 4mo ago
    > Malloc and memory allocation methods are at least 10k+ lines of code for instance. Only the really big ones, e.g. here is Emscripten's allocator that focuses on small binary size and is implemented in about 1.5 kloc (ignoring comments and whitespace it's actually under 1 kloc), and that allocator is perfectly fine for most use cases (especially C code bases which typically don't have a high allocation frequency): https://github.com/emscripten-core/emscripten/blob/main/system/lib/emmalloc.c https://github.com/emscripten-core/emscripten/blob/main/syst... ...and Seb Aaltonen's offset allocator (used for allocating GPU buffers in his Vulkan API wrapper) has under 500 lines of code: https://github.com/sebbbi/OffsetAllocator/blob/main/offsetAllocator.cpp https://github.com/sebbbi/OffsetAllocator/blob/main/offsetAl... Right tool for the job etc... big general-purpose allocators like jemalloc or mimalloc are usually a bandaid to somewhat salvage a failed memory management strategy.
  - Chaosvex 4mo ago
    [dead]
  - EPWN3D 4mo ago
    C programmers aren't complaining about the "magic" being tens of thousands of lines of code. They're complaining about the magic including bizarre side effects that brazenly violate the principle of least astonishment. In C++, you can overload the comma operator to do shit. I've seen it done. There's no reason to do it, and no reasonable person would ever expect it in a code base they're unfamiliar with. To find bug in that ultimately roots back to that implementation, you have to go eliminate every other whack-job possibility before it even occurs to you that maybe the weirdo who wrote this code chose to overload the comma operator. I'm not going to argue with anyone who wants to use C++ in their own projects, you do you. But let's be real about what C programmers are complaining about. It's not line count. It's syntactic obfuscation. I don't just level this criticism at C++ either. Basically every major new language has its own byzantine syntactic constructs to some degree.
  - uecker 4mo ago
    I was programming in C++ before switching to C and I would say that C++ adds a huge amount of mental load compared to C. I think one can understand how much of a relieve it is to not worry about everything C++ does only after not using C++ for a quite a while.
    - PaulDavisThe1st 4mo ago
      Any time I go back to C from C++, it's only comfortable if I've got a C utility library that replaces most of std:: And that utility library (there are dozens of them) is just as subject to debate and issues as libstdc++ I am not going to implement my own C versions of 90% of the stuff std:: provides, sorry.
      - uecker 4mo ago
        There is a difference between "needing a library" and "implement my own". One can just pick one. And even when implementing things yourself, one has to do this just once.
  - fasterik 4mo ago
    I don't think "refusing to learn C++" is the right way to frame it. I want to use the language features that are actually useful to me, without being forced into a specific programming style. I can't speak for every "orthodox C++" programmer, but for me that means using exclusively plain-old-data structs, non-member functions, and "dumb" pointers. I have no issue with learning to use a C++ feature when it's directly useful to a problem I'm trying to solve. As one example, I recently found templated lambdas useful in making animations. https://www.youtube.com/watch?v=cw-h0dePYZM https://www.youtube.com/watch?v=cw-h0dePYZM
    - rramadass 4mo ago
      Right. Use/Choose those features you are most knowledgeable/comfortable with. That is why C++ has such a smorgasbord of features and supports multiple paradigms. Over time, as one learns "better ways" (for a certain definition and one is convinced of it) of doing something change/modify as needed. That is all there is to it.
  - nuc1e0n 4mo ago
    c memory allocation functions can be implemented in 1000 lines or so. I've done it myself. Maybe more are needed to handle strange operating systems or architectures, as glib does.
  - lelanthran 4mo ago
    All the foot guns in C are still in C++, and C++ adds a significant multiple more.
    - ReactiveJelly 4mo ago
      The regular table saw is still in the new workshop, and the new workshop adds a SawStop and another regular table saw.
    - fluoridation 4mo ago
      Literally untrue. Two words: stronger typing.
      - flohofwoe 4mo ago
        Memory corruption magnets like iterator invalidation, std::string_view or std::span are on a whole different level than the footguns that were inherited from C. At least with C style raw pointers you know that you have to be careful when you see one, in C++ the unsafety is lurking in hidden places sprinkled all over the stdlib and comes in all shapes and forms.
  - amomchilov 4mo ago
    “It’s so much magic! Now if you’ll excuse me, I have to go use my generic container library rewritten in 50 layers of preprocessor macros.”
- cyber_kinetist 4mo ago
  LLVM uses a hand-rolled version of RTTI for the best performance (the parent constructor accepts its runtime type as an enum), and it seemed that the maintenance costs for it aren't that high. (See https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html) Or if you're even lazier, you can easily make a more automatic RTTI system with some templates / macros that works much faster than dynamic_cast! (See https://github.com/royvandam/rtti https://github.com/royvandam/rtti)
- my-next-account 4mo ago
  Implementing STL iterators are a bloody PITA
  - flohofwoe 4mo ago
    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/eb08cffe1b1cb6b05ed14ec692bca9372cef064e/code/Modules/Core/Containers/Array.h#L127-L134 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)
    - my-next-account 4mo ago
      If it's a contiguous array, then sure.
  - t0mpr1c3 4mo ago
    std::range fixes this
- flohofwoe 4mo ago
  > for (auto const & ess : esses) { This is allowed by Orthodox C++ > dynamic_cast<Derived> (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 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 ;)
  - PaulDavisThe1st 4mo ago
    > 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
    - forrestthewoods 4mo ago
      Your level of vitriol and anger at someone expressing an opinion is really weird. Literally everyone who uses C++ decides which features to use/embrace and which to avoid. Someone sharing their particular preference is pretty normal and fine. > Appeals to authority don't really work for me. I've been writing a cross-platform DAW (0) for 25+ years, in C++ I love how you reject appeal to authority and then try to establish yourself as an authority. That’s cute.
- badsectoracula 4mo ago
  > for (auto const & ess : esses) { The problem with this is that whoever is reading the code as-is does not know what type "ess" is. Sometimes you get the definition somewhere nearby, in which case it is probably fine - assuming it is close enough that it'll be included in a diff - but more often than not you don't know. Yes, an IDE can probably tell you (probably, depends on the IDE and assuming everyone uses one) but even that requires some extra action like moving the mouse over the definition and hoping it'll give you something. However this wont show up in diffs, PRs, code reviews, etc. IMO `auto` is one of those C++ features that really needs discipline to use - and when in doubt, i'd rather ban its use (except where you cannot do otherwise) than rely on everyone doing the right thing.
  - wk_end 4mo ago
    How important is that, the ability to be certain of the type of some iterated value from a container from one line in total isolation? The odds are very good that it's clear from the context, which is why the compiler can infer it easily enough too. And then the consequence of not inferring correctly would be...the code doesn't compile? Of course some discipline is required - as with just about everything in programming, especially in C++ - but developers in just about every other statically-typed language lean on type inference (including far more extensive type inference) and don't wring their hands about it. It's hard not to see this as a case of Blub - if you learned about typing with `Foo foo = new Foo()`, anything different might seem scary. ...anyway, in this case the real win probably is the range-based for loop, rather than the auto. `for (const Foo& foo : foos)` isn't so bad, but `for (std::vector<Foo>::const_iterator it = foos.begin(); it != foos.end(); ++it)` is pretty rough.
    - badsectoracula 4mo ago
      > How important is that, the ability to be certain of the type of some iterated value from a container from one line in total isolation? As important as the code to be readable. > The odds are very good that it's clear from the context As i wrote, if the actual type can be seen somewhere nearby (close enough to be included in diffs) then that's fine - it is already in the context. Though that is not usually the case and i personally had to work with code with which i was not familiar and which used `auto` all over the place and had to go hunting for the actual container declaration to see what it is (Visual Studio was not helpful in its tooltips). So my actual experience is that i'd rather see the actual type. However... > anyway, in this case the real win probably is the range-based for loop ...yes, the range-based for loop is often the better choice when it comes to readability. And when compared with the iterators, it is pretty much always more readable than them :-P. `for (const Foo& foo : foos)` is basically what i'd prefer to see. It is the use of `auto` i pointed out.
nasretdinov 4mo ago
Such a missed opportunity to call it C <orthodox cross emoji>
- undershirt 4mo ago
  that's one way to combine three plus signs!
- deleted 4mo ago
  [deleted]
- deleted 4mo ago
  [deleted]
- greenbit 4mo ago
  Was thinking "Hesitance C" could work
aw1621107 4mo ago
Submitted a fair few times previously. HN's search turned up these submissions with some additional discussion: https://news.ycombinator.com/item?id=40445536 https://news.ycombinator.com/item?id=40445536 (2 years ago, 63 points, 66 comments) https://news.ycombinator.com/item?id=25554018 https://news.ycombinator.com/item?id=25554018 (5 years ago, 70 points, 102 comments) https://news.ycombinator.com/item?id=13751244 https://news.ycombinator.com/item?id=13751244 (9 years ago, 29 points, 14 comments) Looks like the page was moved from a GitHub gist to a github.io page in October of last year.
- rramadass 4mo ago
  Yep, the article is a old one and not particularly well written. As somebody who has been using C++ from the early 90s and not particularly a fan of (all of) "Modern C++", there is not much information here.
sudosteph 4mo ago
And here I was thinking this was going to be about a schism from Holy C [1] [1] https://en.wikipedia.org/wiki/TempleOS#HolyC https://en.wikipedia.org/wiki/TempleOS#HolyC
gpderetta 4mo ago
Don't follow dogma.
rfgplk 4mo ago
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) is second only to Lisp, but few people make use of it. With some of C++26 features you can almost even replicate most of Rusts safety features in pure C++ (via function tagging + reflection)
- undershirt 4mo ago
  have you written about this anywhere, or hosting any examples?
  - rramadass 4mo ago
    You might find Functional Programming in C++ by Ivan Cukic relevant.
  - rfgplk 4mo ago
    Not yet, I might one day.
- unnah 4mo ago
  C++ template metaprogramming is in some ways more powerful than Common Lisp macros, because it works at the type level: you can generate new types and dispatch into separate implementations by type. In contrast, Common Lisp type declarations are not available at macro expansion time unless you implement a full source-to-source translator in macros.
- cyber_kinetist 4mo ago
  The problem with metaprogramming-heavy C++ codebases is always compilation times and obtuse error messages... Template metaprogramming is sometimes very useful to get around C++'s language restrictions, but I tend to use it sparingly.
badlibrarian 4mo ago
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 your own destiny and care about velocity and code quality, many of these choices eventually become self-evident. If you are messing around with the latest and greatest esoteric C++ stuff in 2026, bless you, you beautiful nerd. But it may be time to start evaluating where you are in life, and how you got here. (And if you're on a C++ committee, I revoke those blessings.) For those who remain: if you have a C++ code base yet somehow have enough time and energy to write opinionated blog posts, it's really hard to imagine why you think you'd have a better take on this than Google. https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html
- dataflow 4mo ago
  > 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 write opinionated blog posts, it's really hard to imagine why you think you'd have a better take on this than Google. "Given that Google's existing code is not exception-tolerant [...] Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. [...] Things would probably be different if we had to do it all over again from scratch."
  - badlibrarian 4mo ago
    [flagged]
  - patrick451 4mo ago
    > 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.
rfgplk 4mo ago
This is gonna be a long critique, I'll try to keep it concise. > C-like C++ is good start, if code doesn’t require more complexity don’t add unnecessary C++ complexities. C is almost obsolete nowadays. Not to mention that C++ is effectively a strict superset of C (nearly 99% of the C standard is in C++) and the few features that aren't are included as compiler extensions (VLA, restrict keyword, nested functions). There are a handful of C features that aren't in C++, and for very good reason (most of them suck). When was the last time you ran into a C library that a pure C++ compiler couldn't compile? Only if someone decided to spam the new keyword all over the codebase (or something similar). > In general case code should be readable to anyone who is familiar with C language. Most C++ already is? Even very template heavy C++. > Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”. A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming. > Don’t use exceptions. Optional but irrelevant. > Don’t use RTTI. .. Why? Reimplementing RTTI in C will give you almost the same overhead. > Don’t use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.) .. Why? Those wrappers all include the "raw C runtime" under the hood (literally they do #include <stdio.h|xx>. Near 0 compiletime overhead? > Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead. This is a design decision. > Don’t use metaprogramming excessively for academic masturbation. Use it in moderation, only where necessary, and where it reduces code complexity. There are many programs that are _impossible_ to write in a finite time without metaprogramming. How will you (with zero runtime overhead) dispatch a function with a variable arity of random types to a handler that requires exactly that type of function? Arbitrarily? In C++ it's possible, in C it isn't.
- AnimalMuppet 4mo ago
  > > Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”. > A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming. So? Is your goal to make C++ shine, or is it to produce useful, understandable code? My goal is good code, not being a showoff.
- ndiddy 4mo ago
jstimpfle 4mo ago
Orthodox C++, to me, is C plus the one good feature of C++: you don't have to type struct all the time.
- maxvu 4mo ago
  How about one of the C unorthodoxies that use typedef everywhere? (Namespaces seem suitable, too.)
  - jstimpfle 4mo ago
    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.
    - PaulDavisThe1st 4mo ago
      tell me you never use platform-provided or third party libraries without actually telling me.
      - jstimpfle 4mo ago
        I won't, because obviously I have. Coincidentally, I've just spent more than a day to find a sane way to setup basic windowing and rendering on Windows for the 1000st time -- this time based on Direct3D compute shader and DirectComposition. Going to integrate the Direct2D/DirectWrite backend of my UI library with those technologies in a bit. And I'm working on this project because the material removal simulation library that my company has been paying insane amounts of money for in the last 10 years just doesn't "cut" it for our grinding purposes (independently of the cruelfully bad C++ API, and the ~10x worse performance in their debug build because of all those dumb C++ objects inside), and it requires an insane amount of BS architecture around on our part to even use it, so I've concluded (after my own short periods of serious well-meaning suffering with this library on and off during the last 2 years), it should actually be way easier to make our own grinding simulation in a short time after running the numbers and concluding a realistic magnitude. Guess what, I still see no reason why my little project shouldn't succeed, I've seriously come closer to realizing it, but COM Objects by Microsoft are once again not the reason why that is so. On the contrary, they are annoying to use (I'm not a newcomer to them), even though there are a lot of nice things to say about Microsoft APIs as well (and OpenGL should just die), it seems like a layer of bullshit to wade through for no obvious reason. The nicest libraries in terms of usability have always been those with a simple & straightforward plain C interface.
BiraIgnacio 4mo ago
Holly bananas, that Boost Design Rationale post is, what's the word I'm looking for, intense.
greenbit 4mo ago
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?
- badlibrarian 4mo ago
  [flagged]
- blashyrk 4mo ago
  That's simply because we live in a world where UFCS is restricted to niche languages and we're stuck with "methods" instead. At least Rust/Kotlin/Swift support type extensions (with a thousand papercuts, i. e orphan rules)
- rramadass 4mo ago
  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.
asveikau 4mo ago
The criticisms of STL and allocation are fair, though move constructors improved the shallow vs deep copy problem on resize. Smart pointers are good. People were doing them outside the standard in the late 90s. Lambdas are a good feature.
kabdib 4mo ago
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)
- usrnm 4mo ago
  A defer is just a dozen lines of code nowadays, if you really need it, but in most cases you don't if you're doing RAII
- AnimalMuppet 4mo ago
  In embedded, I like wrapping a class around a set of registers. Nobody else gets to write to that piece of hardware except that class. As far as avoiding things... avoid basically everything you don't need. Don't add language features that don't actually help you, just because they're there. Keep the subset you use small. But pick that subset to match your problem well, rather than out of dogma.
- wglb 4mo ago
  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.
  - kabdib 4mo ago
    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.
    - wglb 4mo ago
      Agree but nowhere as easy as what we did https://ciex-software.com/coroutines.html https://ciex-software.com/coroutines.html
Martin_Silenus 4mo ago
Nothing surprising here. People who view C++ as just a better C always outnumbered those who view it as another language. That's exactly how democratic governments make their decisions… you might think it's stupid, and you'd be right, but that's democracy. It's the majority that counts, not what's right. At least you can have a little fun with their arguments, they're pretty inventive you know.
netbioserror 4mo ago
Man, all of the confusion and gnashing of teeth in the C++ world really makes me grateful for my job. Smaller company, I solo develop a central module on the product stack, and I was able to evaluate languages for the project. Nim became the obvious choice, and I wasn't a fanboy before. Simple semantics, in a very functional style oriented around data's value. References and identity have to be trapdoored. Everything is single-owner unique lifetimes by default, no annotations or best-practices required. You end up writing extraordinarily functional/procedural code that produces very fast and memory-safe binaries, it fits right into C++'s niche. The only objection I could steel man was that the standard library and most packages are composed of relatively pure functions that return new values, so allocations are happening there. But when types as complex as data frames can be semantically used as just values, and you know they have scoped lifetimes by default, the benefits are obvious. With all of C++'s insanely specific, subtle, implicit, compiler- and platform-dependent behaviors, I've often wondered when the industry will finally consider its dominance an artifact of first-mover inertia and simply move on. There are vastly better ways to do all of the things it does, while easily exposing levers for the the things it's considered to do exceptionally well.
fithisux 4mo ago
I wish the site listed compiler flags for the most popular compilers.
aleksiy123 4mo ago
Somewhere within c++ there is a subset of c++ that is a great language. The problem of course is that no one agrees on which subset that is.
ok123456 4mo ago
stringstreams and fmt are a godsend compared to printf/scanf, which have historically led to most memory bugs in the first place! Printf/scanf are implemented as variadic functions without type checking and rely on the compiler to perform its own internal metaprogramming to inspect and warn about format mismatches. Anyone advocating the use of the old cstdio as a primary design decision about which C++ language features to use is not serious. No exceptions or RTTI make sense in an embedded system that needs to ensure determinism, but are arbitrary and unnecessarily hobbling for high-level systems and application programming. How do you do runtime method dispatch without creating vtables and RTTI from first principles? How do you propagate a runtime error deep from the bowels of a component all the way to some top-level event loop? The "orthodox" approach would be a mess of integer return codes with associated enums (and none of that enum class nonsense!). No Thanks. It's clear the author has no idea what he's talking about.
canyp 4mo ago
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-been-walking-itself-back-for-fifteen-years-and-the-receipts-are-public 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 the happy path inexpensive (not more expensive than a branch checking for errors, which should be the baseline for comparison, not an implementation with zero error checking.) So to say that they are "expensive" doesn't really make a useful argument. And there are more things that could be done in this camp, like proposing a set of compiler flags, and a linter to enforce the subset you are subscribing to. Unfortunately the post offers none of that.
- gpderetta 4mo ago
  [from the linked article] > <deque>: 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.
  - canyp 4mo ago
    I'm not sure about the standard part, but it does call out MS' STL in the sentence prior to what you quoted. And why is the latter nonsense? lists have had terrible cache performance for decades now and vector is the better default choice of container.
- PaulDavisThe1st 4mo ago
  > 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.
einpoklum 4mo ago
I'm not opposed to the concept, but the definition is problematic: > Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++. It’s exactly opposite of what Modern C++ suppose to be. "Modern C++" is usually considered to mean the significant changes to the language in 2011, or 2011 and later. The thing is, that a "small subset improving over C", and without "unnecessary things" will not necessarily avoid 2011-and-later language features, and splurge with pre-2011 features. And this becomes clear as you read the recommendation. So, it's recommand to avoid: * exceptions * STL objects which allocate memory * C++ streams all C98 features. On the other hand, it's not recommended to avoid constexpr, and it is in fact hinted it is useful. ----- C++ is a multi-paradigmatic language. It has lots of features, in the language and via the standard library. It is perfectly reasonable and legitimate to pick feautres which are well-tested enough; or well-regarded by, say, embedded or game developers, or doesn't seem too outlandish coming from C. Of course, different people will quibble over what exactly to adopt or discard, but I'm sure that different flavors of "orthodox C++", "sane C++", etc. are in fact used by many groups of developers.
wseqyrku 4mo ago
Might as well use Rust. Basically if you have a choice, using C++ over Rust is kind of stupid in 2026, to be honest.
amomchilov 4mo ago
No benefits to modules? Oh come on. Hard to take seriously.
Panzerschrek 4mo ago
> Don’t use RTTI. That's the core feature of the language. Not using it doesn't make any sense. > Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead. printf is type-unsafe and bug-prone. Also modern C++ standards have better formatting utilities. > Don’t use anything from STL that allocates memory, unless you don’t care about memory management. In 99.9% of the time one should not care. Using something like std::vector is perfectly fine. Overall I find such "Orthodox" C++ harmful. I call it "pure C heresy".

Orthodox C++ (2016)

108 points by signa11 4mo ago

yyx 4mo ago

At this point, if you want better C, just use Zig.

pjmlp 4mo ago
Except it is years away of being 1.0, with the industry support of C++.

PaulDavisThe1st 4mo ago

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

rfgplk 4mo ago
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 acknowledge that a huge chunk of "pure C" does HEAPS of magic behind the scenes (that the developer has no idea about) unless they've actually studied the spec in detail. Malloc and memory allocation methods are at least 10k+ lines of code for instance.
- 01100011 4mo ago
  A lot of us are too busy solving problems. Learning about the latest language features, which we often won't be able to use anyway due to the trouble of moving a large dev environment to a newer standard, feels like academic masturbation. C++ folks are very much into their language, and can't seem to understand that most folks don't want to dedicate significant amounts of mental resources purely to language details.
  - pjmlp 4mo ago
    Like implementing the compilers used by C devs.
    - uecker 4mo ago
      GCC was implemented in C and there are plenty of other C compilers written in C. GCC has been converted to C++ at some point, but large parts are still essentially C and I do not think the change to C++ was actually helpful (but others may disagree). In any case, the idea that one needs C++ to have C compilers is certainly simply wrong.
      - delta_p_delta_x 4mo ago
        Clang/LLVM with its more permissive licence sees _much_ wider use and is written purely in C++. PlayStation, automotive, platforms and runtimes like Chromium/V8, Android, etc. are all built with Clang.
        uecker 4mo ago
        How is this relevant? (also wider use for C I would doubt)
        lelanthran 4mo ago
        Clang usage is a fraction of GCC usage. Regards, an embedded dev.
        pjmlp 4mo ago
        A decade ago surely, in 2026 I doubt it. With Android, iDevices, PlayStation, Switch, and everyone that had proprietary compilers down using downstream forks from clang, due to the more appealing license. Who is left still using GCC, other than existing projects lacking a clang backend for a snowflake embed CPU? In any case, if it is a modern GCC release past 2012, it was compiled with C++ as well.
- IncreasePosts 4mo ago
  If we accept the maximum that "any sufficiently advanced technology is indistinguishable from magic", then c++ is indeed magic. It's so advanced that one of the worlds foremost experts in the language(herb sutter) has determined that the language is too complex and we need a whole new language(confront) which is simpler and can be converted to c++.
  - rfgplk 4mo ago
    C++ is actually obscenely complex, I don't deny that. Just mastering object lifetime rules is crazy difficult due to all the edge cases, but it comes with the territory.
    - tialaramex 4mo ago
      > it comes with the territory In the sense that C++ is complicated because it's C++, which is complicated? That's just a tautology. If you mean "the territory" in some other sense there's no reason to believe this.
- lelele 4mo ago
  > y'know you can check if an operator has been overloaded And there lies the problem with C++: to be sure, you have to check. C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb.
  - LoganDark 4mo ago
    > C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb. You can't take C code at face value either. The name of a method or type doesn't tell you what it does. It could longjmp for all you know.
    - lelele 4mo ago
      See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416 https://news.ycombinator.com/item?id=48520416
  - rfgplk 4mo ago
    But isn't this a problem with all code? Looking at a Rust function signature how can you be sure that it does what it says it does? Or python?
    - lelele 4mo ago
      See my reply to a similar objection: https://news.ycombinator.com/item?id=48520416 https://news.ycombinator.com/item?id=48520416
    - dwattttt 4mo ago
      To the extent that one doesn't try to suppress compiler warnings & errors / actively break the language, you get what the compiler confirms is true about a function signature. For Python, it's very little (nothing?). For Rust, you get more than most; lifetimes tell you whether it holds onto a pointer you give it.
  - pjmlp 4mo ago
    Just like any C function without looking into the translation unit, don't say you blindly believe on the function name.
- jstimpfle 4mo ago
  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.
  - rfgplk 4mo ago
    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.
    - wavemode 4mo ago
      You can't really separate the two, firstly because some parts of the standard library interact directly with the language's syntax (e.g. <initializer_list>), 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 <unordered_map> is not allowed to invalidate references to keys or elements within the map. That makes it impossible for any standards-compliant C++ implementation to use a high-performance implementation in which keys and elements are stored contiguously in a flat array.
      - gpderetta 4mo ago
        Which sucks... unless you really need reference stability.
        jstimpfle 4mo ago
        std::vector has left the chat.
      - nly 4mo ago
        Your map example only concerns the standard library, not the language.
- deleted 4mo ago
  [deleted]
- flohofwoe 4mo ago
  > Malloc and memory allocation methods are at least 10k+ lines of code for instance. Only the really big ones, e.g. here is Emscripten's allocator that focuses on small binary size and is implemented in about 1.5 kloc (ignoring comments and whitespace it's actually under 1 kloc), and that allocator is perfectly fine for most use cases (especially C code bases which typically don't have a high allocation frequency): https://github.com/emscripten-core/emscripten/blob/main/system/lib/emmalloc.c https://github.com/emscripten-core/emscripten/blob/main/syst... ...and Seb Aaltonen's offset allocator (used for allocating GPU buffers in his Vulkan API wrapper) has under 500 lines of code: https://github.com/sebbbi/OffsetAllocator/blob/main/offsetAllocator.cpp https://github.com/sebbbi/OffsetAllocator/blob/main/offsetAl... Right tool for the job etc... big general-purpose allocators like jemalloc or mimalloc are usually a bandaid to somewhat salvage a failed memory management strategy.
- Chaosvex 4mo ago
  [dead]
- EPWN3D 4mo ago
  C programmers aren't complaining about the "magic" being tens of thousands of lines of code. They're complaining about the magic including bizarre side effects that brazenly violate the principle of least astonishment. In C++, you can overload the comma operator to do shit. I've seen it done. There's no reason to do it, and no reasonable person would ever expect it in a code base they're unfamiliar with. To find bug in that ultimately roots back to that implementation, you have to go eliminate every other whack-job possibility before it even occurs to you that maybe the weirdo who wrote this code chose to overload the comma operator. I'm not going to argue with anyone who wants to use C++ in their own projects, you do you. But let's be real about what C programmers are complaining about. It's not line count. It's syntactic obfuscation. I don't just level this criticism at C++ either. Basically every major new language has its own byzantine syntactic constructs to some degree.
- uecker 4mo ago
  I was programming in C++ before switching to C and I would say that C++ adds a huge amount of mental load compared to C. I think one can understand how much of a relieve it is to not worry about everything C++ does only after not using C++ for a quite a while.
  - PaulDavisThe1st 4mo ago
    Any time I go back to C from C++, it's only comfortable if I've got a C utility library that replaces most of std:: And that utility library (there are dozens of them) is just as subject to debate and issues as libstdc++ I am not going to implement my own C versions of 90% of the stuff std:: provides, sorry.
    - uecker 4mo ago
      There is a difference between "needing a library" and "implement my own". One can just pick one. And even when implementing things yourself, one has to do this just once.
- fasterik 4mo ago
  I don't think "refusing to learn C++" is the right way to frame it. I want to use the language features that are actually useful to me, without being forced into a specific programming style. I can't speak for every "orthodox C++" programmer, but for me that means using exclusively plain-old-data structs, non-member functions, and "dumb" pointers. I have no issue with learning to use a C++ feature when it's directly useful to a problem I'm trying to solve. As one example, I recently found templated lambdas useful in making animations. https://www.youtube.com/watch?v=cw-h0dePYZM https://www.youtube.com/watch?v=cw-h0dePYZM
  - rramadass 4mo ago
    Right. Use/Choose those features you are most knowledgeable/comfortable with. That is why C++ has such a smorgasbord of features and supports multiple paradigms. Over time, as one learns "better ways" (for a certain definition and one is convinced of it) of doing something change/modify as needed. That is all there is to it.
- nuc1e0n 4mo ago
  c memory allocation functions can be implemented in 1000 lines or so. I've done it myself. Maybe more are needed to handle strange operating systems or architectures, as glib does.
- lelanthran 4mo ago
  All the foot guns in C are still in C++, and C++ adds a significant multiple more.
  - ReactiveJelly 4mo ago
    The regular table saw is still in the new workshop, and the new workshop adds a SawStop and another regular table saw.
  - fluoridation 4mo ago
    Literally untrue. Two words: stronger typing.
    - flohofwoe 4mo ago
      Memory corruption magnets like iterator invalidation, std::string_view or std::span are on a whole different level than the footguns that were inherited from C. At least with C style raw pointers you know that you have to be careful when you see one, in C++ the unsafety is lurking in hidden places sprinkled all over the stdlib and comes in all shapes and forms.
- amomchilov 4mo ago
  “It’s so much magic! Now if you’ll excuse me, I have to go use my generic container library rewritten in 50 layers of preprocessor macros.”
cyber_kinetist 4mo ago
LLVM uses a hand-rolled version of RTTI for the best performance (the parent constructor accepts its runtime type as an enum), and it seemed that the maintenance costs for it aren't that high. (See https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html) Or if you're even lazier, you can easily make a more automatic RTTI system with some templates / macros that works much faster than dynamic_cast! (See https://github.com/royvandam/rtti https://github.com/royvandam/rtti)
my-next-account 4mo ago
Implementing STL iterators are a bloody PITA
- flohofwoe 4mo ago
  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/eb08cffe1b1cb6b05ed14ec692bca9372cef064e/code/Modules/Core/Containers/Array.h#L127-L134 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)
  - my-next-account 4mo ago
    If it's a contiguous array, then sure.
- t0mpr1c3 4mo ago
  std::range fixes this
flohofwoe 4mo ago
> for (auto const & ess : esses) { This is allowed by Orthodox C++ > dynamic_cast<Derived> (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 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 ;)
- PaulDavisThe1st 4mo ago
  > 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
  - forrestthewoods 4mo ago
    Your level of vitriol and anger at someone expressing an opinion is really weird. Literally everyone who uses C++ decides which features to use/embrace and which to avoid. Someone sharing their particular preference is pretty normal and fine. > Appeals to authority don't really work for me. I've been writing a cross-platform DAW (0) for 25+ years, in C++ I love how you reject appeal to authority and then try to establish yourself as an authority. That’s cute.
badsectoracula 4mo ago
> for (auto const & ess : esses) { The problem with this is that whoever is reading the code as-is does not know what type "ess" is. Sometimes you get the definition somewhere nearby, in which case it is probably fine - assuming it is close enough that it'll be included in a diff - but more often than not you don't know. Yes, an IDE can probably tell you (probably, depends on the IDE and assuming everyone uses one) but even that requires some extra action like moving the mouse over the definition and hoping it'll give you something. However this wont show up in diffs, PRs, code reviews, etc. IMO `auto` is one of those C++ features that really needs discipline to use - and when in doubt, i'd rather ban its use (except where you cannot do otherwise) than rely on everyone doing the right thing.
- wk_end 4mo ago
  How important is that, the ability to be certain of the type of some iterated value from a container from one line in total isolation? The odds are very good that it's clear from the context, which is why the compiler can infer it easily enough too. And then the consequence of not inferring correctly would be...the code doesn't compile? Of course some discipline is required - as with just about everything in programming, especially in C++ - but developers in just about every other statically-typed language lean on type inference (including far more extensive type inference) and don't wring their hands about it. It's hard not to see this as a case of Blub - if you learned about typing with `Foo foo = new Foo()`, anything different might seem scary. ...anyway, in this case the real win probably is the range-based for loop, rather than the auto. `for (const Foo& foo : foos)` isn't so bad, but `for (std::vector<Foo>::const_iterator it = foos.begin(); it != foos.end(); ++it)` is pretty rough.
  - badsectoracula 4mo ago
    > How important is that, the ability to be certain of the type of some iterated value from a container from one line in total isolation? As important as the code to be readable. > The odds are very good that it's clear from the context As i wrote, if the actual type can be seen somewhere nearby (close enough to be included in diffs) then that's fine - it is already in the context. Though that is not usually the case and i personally had to work with code with which i was not familiar and which used `auto` all over the place and had to go hunting for the actual container declaration to see what it is (Visual Studio was not helpful in its tooltips). So my actual experience is that i'd rather see the actual type. However... > anyway, in this case the real win probably is the range-based for loop ...yes, the range-based for loop is often the better choice when it comes to readability. And when compared with the iterators, it is pretty much always more readable than them :-P. `for (const Foo& foo : foos)` is basically what i'd prefer to see. It is the use of `auto` i pointed out.

nasretdinov 4mo ago

Such a missed opportunity to call it C <orthodox cross emoji>

undershirt 4mo ago
that's one way to combine three plus signs!
deleted 4mo ago
[deleted]
deleted 4mo ago
[deleted]
greenbit 4mo ago
Was thinking "Hesitance C" could work

aw1621107 4mo ago

Submitted a fair few times previously. HN's search turned up these submissions with some additional discussion: https://news.ycombinator.com/item?id=40445536 https://news.ycombinator.com/item?id=40445536 (2 years ago, 63 points, 66 comments) https://news.ycombinator.com/item?id=25554018 https://news.ycombinator.com/item?id=25554018 (5 years ago, 70 points, 102 comments) https://news.ycombinator.com/item?id=13751244 https://news.ycombinator.com/item?id=13751244 (9 years ago, 29 points, 14 comments) Looks like the page was moved from a GitHub gist to a github.io page in October of last year.

rramadass 4mo ago
Yep, the article is a old one and not particularly well written. As somebody who has been using C++ from the early 90s and not particularly a fan of (all of) "Modern C++", there is not much information here.

sudosteph 4mo ago

And here I was thinking this was going to be about a schism from Holy C [1] [1] https://en.wikipedia.org/wiki/TempleOS#HolyC https://en.wikipedia.org/wiki/TempleOS#HolyC

gpderetta 4mo ago

Don't follow dogma.

rfgplk 4mo ago

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) is second only to Lisp, but few people make use of it. With some of C++26 features you can almost even replicate most of Rusts safety features in pure C++ (via function tagging + reflection)

undershirt 4mo ago
have you written about this anywhere, or hosting any examples?
- rramadass 4mo ago
  You might find Functional Programming in C++ by Ivan Cukic relevant.
- rfgplk 4mo ago
  Not yet, I might one day.
unnah 4mo ago
C++ template metaprogramming is in some ways more powerful than Common Lisp macros, because it works at the type level: you can generate new types and dispatch into separate implementations by type. In contrast, Common Lisp type declarations are not available at macro expansion time unless you implement a full source-to-source translator in macros.
cyber_kinetist 4mo ago
The problem with metaprogramming-heavy C++ codebases is always compilation times and obtuse error messages... Template metaprogramming is sometimes very useful to get around C++'s language restrictions, but I tend to use it sparingly.

badlibrarian 4mo ago

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 your own destiny and care about velocity and code quality, many of these choices eventually become self-evident. If you are messing around with the latest and greatest esoteric C++ stuff in 2026, bless you, you beautiful nerd. But it may be time to start evaluating where you are in life, and how you got here. (And if you're on a C++ committee, I revoke those blessings.) For those who remain: if you have a C++ code base yet somehow have enough time and energy to write opinionated blog posts, it's really hard to imagine why you think you'd have a better take on this than Google. https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html

dataflow 4mo ago
> 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 write opinionated blog posts, it's really hard to imagine why you think you'd have a better take on this than Google. "Given that Google's existing code is not exception-tolerant [...] Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. [...] Things would probably be different if we had to do it all over again from scratch."
- badlibrarian 4mo ago
  [flagged]
- patrick451 4mo ago
  > 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.

rfgplk 4mo ago

This is gonna be a long critique, I'll try to keep it concise. > C-like C++ is good start, if code doesn’t require more complexity don’t add unnecessary C++ complexities. C is almost obsolete nowadays. Not to mention that C++ is effectively a strict superset of C (nearly 99% of the C standard is in C++) and the few features that aren't are included as compiler extensions (VLA, restrict keyword, nested functions). There are a handful of C features that aren't in C++, and for very good reason (most of them suck). When was the last time you ran into a C library that a pure C++ compiler couldn't compile? Only if someone decided to spam the new keyword all over the codebase (or something similar). > In general case code should be readable to anyone who is familiar with C language. Most C++ already is? Even very template heavy C++. > Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”. A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming. > Don’t use exceptions. Optional but irrelevant. > Don’t use RTTI. .. Why? Reimplementing RTTI in C will give you almost the same overhead. > Don’t use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.) .. Why? Those wrappers all include the "raw C runtime" under the hood (literally they do #include <stdio.h|xx>. Near 0 compiletime overhead? > Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead. This is a design decision. > Don’t use metaprogramming excessively for academic masturbation. Use it in moderation, only where necessary, and where it reduces code complexity. There are many programs that are _impossible_ to write in a finite time without metaprogramming. How will you (with zero runtime overhead) dispatch a function with a variable arity of random types to a handler that requires exactly that type of function? Arbitrarily? In C++ it's possible, in C it isn't.

AnimalMuppet 4mo ago
> > Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”. > A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming. So? Is your goal to make C++ shine, or is it to produce useful, understandable code? My goal is good code, not being a showoff.
ndiddy 4mo ago

jstimpfle 4mo ago

Orthodox C++, to me, is C plus the one good feature of C++: you don't have to type struct all the time.

maxvu 4mo ago
How about one of the C unorthodoxies that use typedef everywhere? (Namespaces seem suitable, too.)
- jstimpfle 4mo ago
  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.
  - PaulDavisThe1st 4mo ago
    tell me you never use platform-provided or third party libraries without actually telling me.
    - jstimpfle 4mo ago
      I won't, because obviously I have. Coincidentally, I've just spent more than a day to find a sane way to setup basic windowing and rendering on Windows for the 1000st time -- this time based on Direct3D compute shader and DirectComposition. Going to integrate the Direct2D/DirectWrite backend of my UI library with those technologies in a bit. And I'm working on this project because the material removal simulation library that my company has been paying insane amounts of money for in the last 10 years just doesn't "cut" it for our grinding purposes (independently of the cruelfully bad C++ API, and the ~10x worse performance in their debug build because of all those dumb C++ objects inside), and it requires an insane amount of BS architecture around on our part to even use it, so I've concluded (after my own short periods of serious well-meaning suffering with this library on and off during the last 2 years), it should actually be way easier to make our own grinding simulation in a short time after running the numbers and concluding a realistic magnitude. Guess what, I still see no reason why my little project shouldn't succeed, I've seriously come closer to realizing it, but COM Objects by Microsoft are once again not the reason why that is so. On the contrary, they are annoying to use (I'm not a newcomer to them), even though there are a lot of nice things to say about Microsoft APIs as well (and OpenGL should just die), it seems like a layer of bullshit to wade through for no obvious reason. The nicest libraries in terms of usability have always been those with a simple & straightforward plain C interface.

BiraIgnacio 4mo ago

Holly bananas, that Boost Design Rationale post is, what's the word I'm looking for, intense.

greenbit 4mo ago

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?

badlibrarian 4mo ago
[flagged]
blashyrk 4mo ago
That's simply because we live in a world where UFCS is restricted to niche languages and we're stuck with "methods" instead. At least Rust/Kotlin/Swift support type extensions (with a thousand papercuts, i. e orphan rules)
rramadass 4mo ago
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.

asveikau 4mo ago

The criticisms of STL and allocation are fair, though move constructors improved the shallow vs deep copy problem on resize. Smart pointers are good. People were doing them outside the standard in the late 90s. Lambdas are a good feature.

kabdib 4mo ago

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)

usrnm 4mo ago
A defer is just a dozen lines of code nowadays, if you really need it, but in most cases you don't if you're doing RAII
AnimalMuppet 4mo ago
In embedded, I like wrapping a class around a set of registers. Nobody else gets to write to that piece of hardware except that class. As far as avoiding things... avoid basically everything you don't need. Don't add language features that don't actually help you, just because they're there. Keep the subset you use small. But pick that subset to match your problem well, rather than out of dogma.
wglb 4mo ago
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.
- kabdib 4mo ago
  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.
  - wglb 4mo ago
    Agree but nowhere as easy as what we did https://ciex-software.com/coroutines.html https://ciex-software.com/coroutines.html

Martin_Silenus 4mo ago

Nothing surprising here. People who view C++ as just a better C always outnumbered those who view it as another language. That's exactly how democratic governments make their decisions… you might think it's stupid, and you'd be right, but that's democracy. It's the majority that counts, not what's right. At least you can have a little fun with their arguments, they're pretty inventive you know.

netbioserror 4mo ago

Man, all of the confusion and gnashing of teeth in the C++ world really makes me grateful for my job. Smaller company, I solo develop a central module on the product stack, and I was able to evaluate languages for the project. Nim became the obvious choice, and I wasn't a fanboy before. Simple semantics, in a very functional style oriented around data's value. References and identity have to be trapdoored. Everything is single-owner unique lifetimes by default, no annotations or best-practices required. You end up writing extraordinarily functional/procedural code that produces very fast and memory-safe binaries, it fits right into C++'s niche. The only objection I could steel man was that the standard library and most packages are composed of relatively pure functions that return new values, so allocations are happening there. But when types as complex as data frames can be semantically used as just values, and you know they have scoped lifetimes by default, the benefits are obvious. With all of C++'s insanely specific, subtle, implicit, compiler- and platform-dependent behaviors, I've often wondered when the industry will finally consider its dominance an artifact of first-mover inertia and simply move on. There are vastly better ways to do all of the things it does, while easily exposing levers for the the things it's considered to do exceptionally well.

fithisux 4mo ago

I wish the site listed compiler flags for the most popular compilers.

aleksiy123 4mo ago

Somewhere within c++ there is a subset of c++ that is a great language. The problem of course is that no one agrees on which subset that is.

ok123456 4mo ago

stringstreams and fmt are a godsend compared to printf/scanf, which have historically led to most memory bugs in the first place! Printf/scanf are implemented as variadic functions without type checking and rely on the compiler to perform its own internal metaprogramming to inspect and warn about format mismatches. Anyone advocating the use of the old cstdio as a primary design decision about which C++ language features to use is not serious. No exceptions or RTTI make sense in an embedded system that needs to ensure determinism, but are arbitrary and unnecessarily hobbling for high-level systems and application programming. How do you do runtime method dispatch without creating vtables and RTTI from first principles? How do you propagate a runtime error deep from the bowels of a component all the way to some top-level event loop? The "orthodox" approach would be a mess of integer return codes with associated enums (and none of that enum class nonsense!). No Thanks. It's clear the author has no idea what he's talking about.

canyp 4mo ago

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-been-walking-itself-back-for-fifteen-years-and-the-receipts-are-public 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 the happy path inexpensive (not more expensive than a branch checking for errors, which should be the baseline for comparison, not an implementation with zero error checking.) So to say that they are "expensive" doesn't really make a useful argument. And there are more things that could be done in this camp, like proposing a set of compiler flags, and a linter to enforce the subset you are subscribing to. Unfortunately the post offers none of that.

gpderetta 4mo ago
[from the linked article] > <deque>: 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.
- canyp 4mo ago
  I'm not sure about the standard part, but it does call out MS' STL in the sentence prior to what you quoted. And why is the latter nonsense? lists have had terrible cache performance for decades now and vector is the better default choice of container.
PaulDavisThe1st 4mo ago
> 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.

einpoklum 4mo ago

I'm not opposed to the concept, but the definition is problematic: > Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++. It’s exactly opposite of what Modern C++ suppose to be. "Modern C++" is usually considered to mean the significant changes to the language in 2011, or 2011 and later. The thing is, that a "small subset improving over C", and without "unnecessary things" will not necessarily avoid 2011-and-later language features, and splurge with pre-2011 features. And this becomes clear as you read the recommendation. So, it's recommand to avoid: * exceptions * STL objects which allocate memory * C++ streams all C98 features. On the other hand, it's not recommended to avoid constexpr, and it is in fact hinted it is useful. ----- C++ is a multi-paradigmatic language. It has lots of features, in the language and via the standard library. It is perfectly reasonable and legitimate to pick feautres which are well-tested enough; or well-regarded by, say, embedded or game developers, or doesn't seem too outlandish coming from C. Of course, different people will quibble over what exactly to adopt or discard, but I'm sure that different flavors of "orthodox C++", "sane C++", etc. are in fact used by many groups of developers.

wseqyrku 4mo ago

Might as well use Rust. Basically if you have a choice, using C++ over Rust is kind of stupid in 2026, to be honest.

amomchilov 4mo ago

No benefits to modules? Oh come on. Hard to take seriously.

Panzerschrek 4mo ago

> Don’t use RTTI. That's the core feature of the language. Not using it doesn't make any sense. > Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead. printf is type-unsafe and bug-prone. Also modern C++ standards have better formatting utilities. > Don’t use anything from STL that allocates memory, unless you don’t care about memory management. In 99.9% of the time one should not care. Using something like std::vector is perfectly fine. Overall I find such "Orthodox" C++ harmful. I call it "pure C heresy".