6 ms·
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<De
by 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 agoOne 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 agoA 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 agoLike implementing the compilers used by C devs.
- uecker 4mo agoGCC 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 agoClang/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 agoHow is this relevant? (also wider use for C I would doubt)
- lelanthran 4mo agoClang usage is a fraction of GCC usage. Regards, an embedded dev.
- pjmlp 4mo agoA 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.
- uecker 4mo agoThe license is indeed the big reason for many proprietary forks (not so much that llvm is written in C++). This is not a good thing though.
- bluGill 4mo agoMoving to new C++ is a non event, change the compiler / flags and done. Using the new features requires some learning but not a big deal since you can figure out what you need from a summary and learn what is useful for your problem. The problems of the code I'm writing far exceeds the complexity of the language. Your complaint about complexity fall flat to me, unless you are working on a trivial program you need to deal with things far more complex than any language.
- 01100011 4mo agoIt's really not. For us, changing compiler versions has noticeable effects throughout our codebase. I'm glad you don't have to deal with that though.
- IncreasePosts 4mo agoIf 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 agoC++ 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 agoSee my reply to a similar objection: https://news.ycombinator.com/item?id=48520416 https://news.ycombinator.com/item?id=48520416
- rfgplk 4mo agoBut 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 agoSee my reply to a similar objection: https://news.ycombinator.com/item?id=48520416 https://news.ycombinator.com/item?id=48520416
- dwattttt 4mo agoTo 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 agoJust like any C function without looking into the translation unit, don't say you blindly believe on the function name.
- jstimpfle 4mo agoTrust 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 agoThe 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 agoYou 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.
- 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 agoC 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 agoI 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 agoAny 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 agoThere 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 agoI 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 agoRight. 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 agoc 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 agoAll the foot guns in C are still in C++, and C++ adds a significant multiple more.
- ReactiveJelly 4mo agoThe regular table saw is still in the new workshop, and the new workshop adds a SawStop and another regular table saw.
- fluoridation 4mo agoLiterally untrue. Two words: stronger typing.
- flohofwoe 4mo agoMemory 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 agoLLVM 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 agoImplementing STL iterators are a bloody PITA
- flohofwoe 4mo agoYou 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 agoIf it's a contiguous array, then sure.
- t0mpr1c3 4mo agostd::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 agoYour 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 agoHow 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.