19 ms·
C++ is the next C++
- tialaramex 4y agoSo, the context for these "... is the next C++" talks, blog posts and papers is largely Chandler Carruth's CppNorth talk: https://www.youtube.com/watch?v=omrY53kbVoA https://www.youtube.com/watch?v=omrY53kbVoA "C++: What comes next?" which is also the "coming out" for the Carbon language.
- steveklabnik 4y agoAs well as https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
- SleepyMyroslav 4y agoI might get totally misunderstood ^^ but I will try to post an opinion from gamedev side. I have spent lots of time thinking on all proposals that came up this year. And only one idea felt seriously better. No not the 'secure rust'. The idea behind Circle compiler described by author in one of podcasts I think. That compile time language should stop being ugly magic and should become normal full fledged programming language that can do everything. Recently I have investigated some failures in builds that were happening only on one platform only in one branch only when specific change was applied. And I came to conclusion that gamedev does not have people who understand what C++ does at compile time. And to fix it we don't need more more magic in C++. So no, next C++ will not be C++ for us if we will have any other sane alternative. Most likely we are stuck with old C++ until new platforms are out.
- noobermin 4y agoZig does this although zig is more geared towards systems programming I think, not complex software (like games) as C++ is.
- deleted 4y ago[deleted]
- chrsig 4y agoI think in 10-20 years the C++ community will regret enshrining "modern" into so much of the literature.
- simplotek 4y ago> I think in 10-20 years the C++ community will regret enshrining "modern" into so much of the literature. In other circumstances I would agree, but cmake coined the term "modern cmake" when they released cmake 3.0 and with it their support for target-based projects, and after a couple of decades of "modern cmake" a sizeable portion of the cmake community still failed to update their code.
- fluoridation 4y ago"Modern" has a shifting definition, and means that the code uses current as opposed to obsolete techniques. Something that was once modern may cease to be so in the future.
- rurban 4y agoAbsolutely not. Modern and modernism is clearly defined and nothing to do with recent or latest fad. It rather means nowadays old-fashioned and reduced. * Form follows function. * Minimalism principle, there's only one best way. (vs postmodern, there are many) * Stanford, not New Jersey. C++ is clearly a postmodern language, because instead of reducing competing features, it rather adds more and more variants of almost the same thing. Modernism means to reduce this syntax and library bloat.
- chrsig 4y agoYou're reminding me of Tony Van Eerd's 'Postmodern C++' talk[0] from a past cppcon. I think you're both right. There are people that will interpret modern as temporal versus modern as in design. I was referring to the temporal interpretation, and thinking in terms that either "modern cpp" becomes fixed in time to mean '>= c++11', or evolves to mean '>= c++23' and beyond. In the former case, you'll have people unhappy because cpp style will surely continue to change, and people will complain that 'modern cpp' is the bad way. In the latter case, you'll have people complaining that "good style" is a shifting target, and feeling like they'll be accosted by trend setters no matter how they write their code. [0] https://www.youtube.com/watch?v=QTLn3goa3A8 https://www.youtube.com/watch?v=QTLn3goa3A8
- rapsey 4y agoI wonder how much C++ is being learned by new generations of programmers. I suspect Rust is taking over there but that is a completely baseless assumption on my part.
- AtlasBarfed 4y agoI was shocked to read in a thread today that C++ programmers are paid WORSE than javascript/python/webshit/scriptcrap. Which blew my mind, but the comments basically proved the case. That's the death knell. C++ will COBOL, not because it sucks (which I do think it kind of does due to feature overload and too much long history of different feature generations), but because it isn't even worth the money to learn.
- synergy20 4y agoAs one of the data points, I compared rust and c++ and started learning c++ seriously one year ago, modern c++ is much safer and simpler as far as I can tell.
- rapsey 4y agoA different data point. In the November HN hiring thread, Rust has more mentions than C++.
- karmakurtisaani 4y agoI'd be very eager to jump to a well-paying rust job that didn't involve web3 in any way. Sadly not too many of those near me yet, but one can hope..
- guardian5x 4y agoModern C++ is safer than old C++, but i doubt it is safer than Rust.
- P5fRxh5kUvp2th 4y agowhy do you doubt that? safe rust is organized just like safe C++.
- kensai 4y agoThe "Core Guidelines" site hidden in the references is a gem. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
- eklitzke 4y agoPro tip: clang-tidy understands pretty much all of the cpp core guidelines, and if you're using clangd it can emit clang-tidy warnings for violations (and in some cases even provide fixits). Not to mention a bunch of other really useful style rules. You should definitely be using it if you're not already.
- ephimetheus 4y agoRunning this on header-heavy or header-only code is still an unsolved problem however.
- account42 4y agoCan't you just pass your headers as "source files" to clang-tidy? Or create dummy source files that include them if your build system can't do that?
- ephimetheus 4y agoKind of, if you happen to have the right include paths and compiler flags, which even a compile command database from e.g. CMake doesn't give you (by default)
- boundchecked 4y ago>// Hard-to-read CaMeLcAsEvArIaBlE Absolutely.
- ChrisMarshallNY 4y agoCan't get better authors.
- 4y ago
- bugfix-66 4y agoThe successor to C is Go. Go inherits from Oberon through Robert Griesemer, and from C through Ken Thompson (father of Unix) and Rob Pike (Bell Labs). I don't bother with C anymore, except in small parts of code where every cycle counts. Just about anything you write in C can be mechanically translated to Go. C++ shows us what NOT to do. I've used C++ for most of my professional programming career and it's simply an impediment. Huge waste of time and energy.
- chungy 4y agoGo is the successor to C++, maybe Java also. Rust is the successor to C.
- wheelerof4te 4y agoLiterally, the opposite is true. If anything builds upon C++, it would be Rust.
- deltasevennine 4y agoIn terms of zero cost abstractions, yes. In terms of OOP. No.
- tmtvl 4y agoDoes that mean that you don't consider code like... std::args().skip(1).next().unwrap(); ...to be OOP? Because that looks remarkably like some Java code I've written.
- deltasevennine 4y agoThat's the same as a deeply nested data structure. A product type. It's not exclusively an OOP concept but it could be to someone who hasn't really delineated the concept of what OOP is. What I mean by OOP is the smallest unit of programming being an Object with mutating data. These objects are basically combinations of mutable data and methods tied together into entities. Imagine a graph of a bunch of mini-programs with mutating state, moving around, getting injected into one another and talking to one another. This is OOP. This is opposed to another style of programming where data flows through pipelines from input to output rather then a bunch of entities messaging each other and changing each others state. Both Rust and Go are moving away from this OOP paradigm of programming by putting less emphasis on OOP based syntax.
- deleted 4y ago[deleted]
- wheelerof4te 4y agoRust is the next C++. There, I said it.
- Kukumber 4y agoRust can't be the next C++ since it can't consume the C++ ecosystem
- marcosdumay 4y agoWell, "the next C++" won't be one language. But yes, to the extent that C++ still had some niche before Rust matured, that last niche doesn't exist anymore. I disagree even that Rust was the largest C++ killer, but it seems to really be the last one.
- eklitzke 4y agoThe problem with Rust is that it's not compatible with C++ other than at a C FFI level. Rust code can't really interact with C++ code that uses templates, which is pretty much all of it. That makes it a non-starter for companies that have millions of lines of C++. Incidentally this is why there's basically no Rust in the Google monorepo. Rust might be slightly better than C++, but it's not a lot better, and bifurcating the entire ecosystem for something that is marginally better isn't worth it.
- dang 4y agoPlease don't post unsubstantive or flamebait comments or take HN threads on generic flamewar tangents. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- beeforpork 4y ago> This static analyzer causes programmers to use 2 extra characters when using smart pointers, -> vs (*)., since the overloaded -> operator returns a pointer. This renders it completely impractical -- sorry. You need to figure out a way to make it work, otherwise this is, errrm, useless. And what is 'this' static analyzer anyway. I thought this is about a language extension introducing possible general static analyzers. Is this a concrete one now? Or why do you already know that it cannot handle '->'? Did I miss something? What is this?
- amluto 4y agoIt’s worse than useless. This guideline says that one should not write code in the straightforward, idiomatic way, and should instead write ugly code. If the language spec is such that operator -> can’t have a sensible signature, then FIX IT. Or teach the analyzer to recognize the idiomatic use. (And the * approach still eventually sticks a raw pointer into this.) I think this one is problematic too: > Using the union keyword produces an error. … It was replaced by std::variant, which is safer. Union is horribly unsafe, but at least union identifies its fields by name. Variant identifies its fields by position (unergonomic, error prone, and horrible for refactoring) or by type (unpleasant or useless when the type has no name or an unstable name, and even worse when two choices have the same type). C++ needs an actual sum type, and variant isn’t it. Sorry.
- kllrnohj 4y ago> C++ needs an actual sum type, and variant isn’t it. Sorry. Don't disagree at all, but in the meantime I'd still avoid union and use variant instead but wrapped in a class that exposes named accessors. You don't have to actually expose the orderings of a variant to anything that way. It's a bunch of annoying boilerplate to be sure, though. If the metaclasses proposal ever happens then it could be generated which would be cool.
- amluto 4y agoThis is yet another step on the slippery slope toward extremely slow compilation. I once timed this little program: #include <boost/variant.hpp> on a machine that was very fast for its time. It took seven seconds to compile! Now modern variadic templates are quite an improvement, but not enough of one. A metaclass generating an instantiation of an n-element variant which, in turn, instantiates the n-1 element tail, etc is quite a log of generated code and types, and anything using it needs to contend with all that complexity to resolve method calls, etc. In contrast, any language with native sum types can handle this efficiently. Furthermore, native sum types make it obvious to the compiler, type checker, static analyzers, etc that the type in question is actually a sum type. Getting a compiler to understand a metaclass-based variant well enough to do something like Rust’s sentinel value optimizations sounds miserable.
- deleted 4y ago[deleted]
- daveslash 4y agoI know this is off topic, but right out of the gate, this really irks me... Re >> "Software companies have a problem. There’s not enough candidates that can code C++. " Should be written "There're not enough candidates who can code C++."
- draw_down 4y ago
- richardwhiuk 4y ago"There're" is technically correct - but deeply non-standard usage. "There's not enough" is used much more in practice, and given language is defined by usage, it's not wrong.
- Eupraxias 4y agoIsn't this just a matter of plurality? e.g.s: "There is not enough talent" "There are not enough talented developers" "There's" is not correct when used to refer to multiple things.
- daveslash 4y agoGrowing up, my family was always correcting my grammar. (e.g. "I have a friend at school that.." and my mom would immediately interrupt with "You have a friend who"). I still screw up all the time, but many of these little things like this catch my eye. In every-day speak or in internet comments (Including here on HN), it doesn't bother me at all when the wrong form is used. Casual speak is casual. When I see it in an article, I assume that the author is ostensibly a writing professional; that's when the misuse really irks me. Doubly-so when it's in the opening statements. First impressions and all that....
- Eupraxias 4y agoHear hear - we are alike. My comment was basically yours, aimed at another person who was correcting someone, with incorrect information. That said, I had parents like that too, _and_ I did a comp-lit degree, so I'm basically hopeless.
- photochemsyn 4y agoGeneralized rules for how to use C++ in all situations are aspirational and unlikely to be adopted widely. More practically, the large projects that rely on C++ should just have their own rule on what elements / styles are used in that particular project, and then use a linter to enforce those specific rules, and have good documentation that explains the rules.
- davedx 4y agoAh, "make C++ better by adding more features", we meet again
- simplotek 4y ago> Ah, "make C++ better by adding more features", we meet again What's your plan to improve something that does not involve adding improvements?
- UncleMeat 4y agoC++ is famous for being bloated. It desperately needs to be able to remove stuff but it can't because of its desire to maintain ABI compatibility with binaries compiled on older versions.
- simplotek 4y ago> C++ is famous for being bloated. No, it isn't. If anything, it's famous for its spartan standard library. It only received smart pointers in C++11 and a file system library in C++17. > It desperately needs to be able to remove stuff but it can't because of its desire to maintain ABI compatibility with binaries compiled on older versions. This is outright wrong. Some standards already deprecate and remove features, like std::auto_ptr going away in C++17 or volatile in C++20. You're trying to pass off too many baseless assertions as undisputed facts.
- TillE 4y agoYes? Features are great. I do not miss writing C++ without smart pointers, lambdas, span, etc. If you don't want comfortable, common features enshrined in the language, you can just write C. Personally, I think using C for anything complex is torture.
- AtlasBarfed 4y agoTHe issue with C++ is that progressive generations of totally new truckloads of features don't auto-port legacy code forward. So "idiomatic C++" is a hilarious moving target, and the body of code (one of C++'s advantages) is a hodgepodge of idioms, feature usage, interfaces, etc. That said, C++ is what it is, and it is kind of proud of it, so I say to C++, keep C++ing.
- Kukumber 4y agoMore static analyzers is the way to go Similarly, D also is pushing for more static analysis to enforce safeties I feel like D already is the next C++, it feels like C++ catching up on D, they went with the same syntax as D for modules, it's quite telling
- 29athrowaway 4y agoThe obsession with backwards compatibility killed C++.
- runevault 4y agoC++ should probably look at the Epochs rust is using to manage compat issues so old code still compiles but they aren't completely bound to old things (see how they added keywords for async in 2018 as an example).
- tialaramex 4y agoThe Rust feature you're thinking of is named Editions. The proposal (from Vittorio) to do this in C++ 20 was named Epochs, and the committee rejected it, taking the position that while this is maybe a good idea they're not interested in figuring out how to do it and will meanwhile make it harder. It would definitely be very difficult to do Epochs in C++ 20. It got harder, and will continue to get harder. In my view, if it was possible in 2020, it won't be possible in 2026. Accordingly I think C++ is doomed. Get out while you still can (or, you know, size up lucrative consulting gigs as maintenance, it's not as though existing C++ code will all rust out [pun not intended] before you retire)
- steveklabnik 4y agoSomeone did write up a paper for this, but it isn’t happening; I can’t remember if it was rejected formally or what exactly happened, all I remember is it’s not happening.
- runevault 4y agoThat is unfortunate to hear, but I've already started learning rust and not doing c++ for the day job so I guess it doesn't impact me terribly.
- steveklabnik 4y agoHere's the paper, if anyone is curious: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18...
- Asooka 4y agoI have a couple of gripes with these guidelines, not because I love writing unsafe programs, but because this way of writing C++ conflicts with the reality of how C++ is implemented. 1. shared_ptr is very slow. It makes it safe to share data, but at the expense of many tiny allocations for each object type. C++'s memory manager isn't geared towards that kind of abuse, this is something that can really only be performant in a garbage-collected language where allocation is an atomic pointer increment and deallocation happens "later". Pushing people towards using this abstraction is wrong most of the time, it is often much better to use arena-style allocations for most cases in C++. I've seen libraries written in modern C++ where malloc and free account for 80% of the runtime. I don't see a way to fix this without radically altering the memory manager. 2. The impact on code compiled in debug mode is often unacceptable. I expect programs compiled with minimal to no optimisations to be slower, but layering all these abstractions usually produces a lot of runtime junk that gets in the way. For example, std::for_each can often be optimised to a regular for loop, which can then be vectorised, but in debug mode it is compiled to a function call which in turn calls the passed in lambda for each element and operator++ on the iterator. The difference in speed between the two is several orders of magnitude and makes this abstraction unacceptable for hot loops. This is a more minor gripe that can probably be solved by marking some functions as "function-like macros" similar in intent to LISP's macros, so the compiler knows they can be always inlined and optimised. GCC's -Og flag also helps a lot here. Still, the world isn't just GCC and the standard should probably bequeath more library functions with special status, like how memcpy &al can be always optimised to inlined machine code instead of a function call. You'll notice both of those concern speed. If the loss of performance from said abstractions is not a deal-breaker for you, then you probably shouldn't be writing C++. D, C#, go, Java, maybe even JavaScript, Python or Lua would be a better choice for your project. The reason to use C++ for a new project is because you want to build really complex programs made up of operations that closely match the semantics of the machine on which they run, for the purpose of going very fast. Or you're stuck using C++ because you have to interface with C++.
- tomjakubowski 4y agoshared_ptr is compatible with arena allocation - look up the "aliasing constructor".