I feel that modern c++ is a game of how many times you can fit `const` in a single declaration. I usually have at least three for the simplest of functions.
Const in C++ is probably one of the biggest frustrations I have with the language. It's an API promise, but suffers from all the downfalls of "what colour are your functions". Combine that with aliasing, const_cast, mutable, you're left with a pinky promise, with code duplication that I honestly wonder sometimes if we're better off without
As someone who strongly regrets the fact that most programming languages arbitrarily restrict valid identifiers to Unicode "word characters" (ID_START and ID_CONTINUE), I was pleasantly surprised to discover the other day that, like Racket, Clojure, Julia and Swift, you can use emojis and pretty much any Unicode symbols in C++ identifiers!
Change: Previously valid identifiers containing characters not present in UAX #44 properties XID_Start or XID_Continue, or not in Normalization Form C, are now rejected.
Rationale: Prevent confusing characters in identifiers. Requiring normalization of names ensures consistent linker behavior.
Effect on original feature: Some identifiers are no longer well-formed.
why would someone learn c++ in 2024, assuming one is not about to work on legacy projects? I'm about to start a quixotic new personal project and was considering using (read: learning) c++ for it, but it feels like rust is getting all the new attention. (and I'm already spoiled by haskell and racket.)
There are big parts of the industry where Rust still doesn't have much penetration, even for new projects. Games is a big example. Highly regulated, safety-critical code is another. I think Rust will eventually get there, but it'll be a while before it's a "boring" choice for these things.
You learn a new language to write programs in that language. Few want to pay you to code in Haskell, Rust, or Racket. It will be that way for a long, long time. In 2030 your list will be different, but people will still pay to have C++ code written. Your personal project might then turn out to be in what is considered a legacy language, as Ruby is now. But C++ will continue modernizing, and getting more pleasant to code in.
But I was actually close to give up before using those two things:
- https://github.com/nlohmann/json : my plugin use a json api backend and the Juce json implementation is atrocious (apparently because of being born with a previous C++ version), but this library is GREAT.
- ChatGPT 4. I'm not sure I would have "succeeded" without it, at least not in a reasonable time frame. ChatGPT 3.5 is slow and does not give good results for my use case but 4 is impressive. And I use in a very dumb way, just posing question in the web UI. I probably could have it directly in MSVC?
Also I must say, for all its flaws, I have a renewed appreciation for doing UI on the web ;)
I’ve been using C++ since the late 80’s and for the last 15+ years it’s been reluctant and only due to the projects I’ve worked on and the people I’ve worked with.
I’d love to be in a position to work on a new project using Rust or Haskell instead.
Looks clean! Just was wondering which framework/service do you use for hosting these md files? I am asking as I find myself motivated to host my own site like this consisting of mdfile.
It's extremely hard to write good tutorials. This one is very clear, but seems to have no time budget or reader model. I appreciate the clarity and the extensiveness, but it mainly makes me wish for something different.
Today there are so many IDE's and online coding environments, godbolt, Swift playgrounds, golang interactive tutorials, etc. It would be lovely to see a C++ tutorial join that trend.
I find the tutorial unsettling from the first words: `original, self-contained`. My first step in writing a tutorial would be to link the current state of the art, and the last would be a section pointing users to further resources, if my goal were not to trap readers but to help them. (Originality is a tall claim as the internet spawns LLMs.)
Without any orientation to the landscape, the tutorial proceeds step-by-step with topologically-sorted vignettes that explain themselves verbosely.
hello-world is prefixed by a long explanation why people start with hello-world, and following by 16 paragraphs of (to me) excruciating hand-holding and suggested experiments, without re-quoting the code. It's like pair-programming with someone who tells you what to type.
The original K&R book was breathtakingly brief, mainly just showing you how to do things. Effective C++ neatly crystallized specific problems and solutions. Both benefited most by what they left out.
Outside of an interactive tutorial for newbie's, what's needed for "modern" C++ is an origin story for each feature: what motivated it, how backwards-compatibility shaped it, what design decisions were made, how well it has been implemented and used -- ideally with bonus comparisons how Rust and Swift and Go managed the same issues. I think that would help people remember the complex issues and the syntax, and how to use it.
To me most of the discussion from the C++ originators is more expository than explanatory: `for each opinion, explain in detail with cross-references to other opinions` - the political template. But readers only need to know the distinctions that make a difference in when and how they use a feature.
Actual users are busy and paid only to get things done, not sling words. Users who value their time will pay for a good resource.
Honest question here. How hard and frustrating is it to keep up with all this junk?
As someone familiar with nearly a dozen scripting languages, I keep trying for something low level like C++, but it seems like these languages are impenetrable at times. It's hard enough to learn the machine stuff and manual memory management, but having the syntax change more often than a toddler's favorite color just makes it all seem impossible.
Tried C++ once and only once. After the compiler spit pages and pages of alien and incomprehensible errors I discovered that the language was not for me (I felt like I was battling against the language and the computer). Never looked back nor regretted about it. In my opinion is way way better to learn modern C (and good C practices) a zillion times.
But in the end everyone should pick whatever programming language feel comfortable with. Sometimes if you're pursuing a career in certain directions (e.g: game development) you have literally no choice but to knee down and learn whatever the industry is pushing to use.
I am not a C++ programmer, but I try and "keep up with all this junk" and also care a lot about how people learn programming.
Programmers like really neat logical explanations for everything, but the real world is much messier. People do not acquire human language skills by learning a formal grammar, learning all the edge cases, and then finally speaking: they attempt to communicate as best they understand, and then refine their knowledge over time.
The same works with computer languages. Not just C++. You don't generally learn every single detail before you do meaningful work. You just kinda try stuff and figure things out. Sure, you may practice specific skills, but that's just not the primary method of learning. And even in those cases, you don't necessarily learn everything before you return to practicing what you've learned: it's a process where the two activities feed into each other.
You mostly just go "damn I wish there was a better way to do X" and then find out there's a paper someone wrote, and then you pay attention to its progress. Or you just keep doing what you're doing, and at some point, a blog post comes out that's a summary of what's new, and you go "ooh that sounds interesting, I should look into that." But for every feature like that, there's also features which you go "ehh I don't need to care." And that's generally fine.
> having the syntax change more often than a toddler's favorite color
No real syntax is different here, this is a function call like any other. And C++ changes on a three year timescale. Many scripting languages release new versions far faster. It's just stuff that's less familiar to you, and so it seems harder, but it's learnable.
> It's hard enough to learn the machine stuff and manual memory management
This is the bigger struggle with learning, moreso than "syntax changes." If you haven't done lower level stuff before, you also have to recon with that while learning. That does make things harder the first time you learn a new paradigm, just like if you'd never used a functional language before, you'd be learning about those concepts as well as the syntax and specific language semantics.
Varies, but it is a layer of stress. I have around 10y in a field where getting rid of C++ is close to impossible and I'm more excited about maybe changing areas than spending ten more working with C++ codebases. The things that affect me the most are:
- No standard / user friendly tooling: there is no package manager, getting dependencies "as easy as copying a header from this github repo" is messy, is a liability, generates toil, etc.
- The language is very complex, i.e. there are 7 different ways just to declare a variable (I'm not even discussing templates, optionals and what not) and more often than not C++ projects spans years or decades, there is a natural mix of styles from people across different generations on what is "modern" and it's a sore to my eyes. At every release rarely things are removed from the language, but there is always something added.
At every company, the subset of what features are reasonable to use, understood and well maintained can change drastically. That might be a company problem, not a language one, but it's something sistematic enough that I would say it's a language thing.
- Every language has its gotchas, but with beginners interested in using fancy features of the language, the surface area is just too big.
I've read once on the blog of a former member of the C++ technical steering committee, that at his best, when actively working with the committee and focused on this, he maybe knew 50% of the language spec. What are the odds of the common folk knowing the pitfalls and good practices of the language and that staying relevant in 5-10 years?
Even though C++ is the language programmed the most in my career and I can appreciate how nice it is at the right conditions, I've come to accept that the tenets of the language, the way the TSC sees it (stability, backward compatibility, performance) no longer resonate with me and I come to appreciate the consistency, simplicity and ease of use of other projects, there is a bigger world out there and the pond of C++ issues is a place I would rather leave behind.
Systems programming languages contain features most users don’t need but some users definitely require. Often those special features are needed to implement things in libraries so that ordinary user code doesn’t have to deal with certain low level details. Likewise ordinary user code doesn’t need to know about these new features!
And C++ is explicitly a multi-paradigm language so there can be affordances for multiple approaches. You can even use it as an OOP language if you want!
As far as syntax changes go, mostly they are in the direction of simplification and/or unification intended to make programming easier in the long run. So, for example, you can now in many cases write template generics without the elaborate template syntax.
But the C++ is also pretty unwilling to break old code, so old syntax and obsolete semantics are still available should you so choose. This is confusing to people who come to the language later on.
(Note that above I wrote “intended to make programming easier”. The case I cited of generics does make some things easier for me, but of course de gustibus and all that.)
I'll answer from the perspective of someone who uses C++ for work and for some personal projects.
The answer is: Effectively not hard, because:
1. When you write complicated software - especially with older-standard-version C++ - you often have the thought of "Oh, if I could only do X more easily" or "wouldn't it be good if we could skip the tedious coding to make the compiler do Y?" - and then you either grit your teeth and write something ugly which works. But then, a few years later, you hear it mentioned that X' or Y' have been standardized, and then you know "Oh, good, now I can do that more easily".
2. Stuff that you _don't_ know about, that gets introduced - you typically don't have to know about. Either it's not relevant to you, or it is, but you're just writing old-style code.
3. The "junk" gradually makes you be able to write the code you want more easily. So, unless you want to do deep guru things - you can gradually even _forget_ things you used to know how to do, since you no longer need to know about them.
I write C++ as my day job. The secret is you don’t need keep up. The standard is weird and getting weirder. And no, it’s not ”well thought out complex technical endeavour”. It’s a jury rigged pile of legacy code with tons of useless sugar, somewhat modern features, and weird omissions.
C++ is a weird combination of pragmatic features, close to the metal performance (which you can junk if you don’t actually understand what is happening on machine kevel), universally abysmal tooling (compared to other current languages), huge ecosystem of super-usefull super-nontrivial libraries… a combination of super good and super bad.
If you don’t need the super good stuff (which you don’t need unless you know you need it) all you are left with is the bad stuff.
The C++11 is okay. C++ committee is a weird combination of clown-car non-savant idiots and super talented pros.
Why do you feel the need to use every single feature? Are you constantly joining new projects that use vastly different features? Most programmers find a handful of features that gets the job done, and keep using them. Your knowledge from 10 years ago (C++11) is still valid and useful.
There's an experimental cpp2 "syntax reset" that aims to provide C++ but with just the modern/better defaults, which reduces the "junk", or needing to know what coding conventions to apply to make actual C++ not be full of foot guns.
Herb Sutter has been working on it for awhile. My only exposure to it has been watching this recent talk:
I would start with C, then take it from there. Makes you think about memory management and pointers, and the language doesn't change much. C++ and Rust is a lot easier to process now that I know C, though they don't get prettier. Use ChatGPT for learning - it's good at writing and explaining C.
From my own experience, it seems a lot and overwhelming at first, but it quickly becomes natural the more you use it, just like with any other language. Plus like others said, you don't need to use every single feature out there.
A new version of C++ comes out every 3 years, and every 3 years you will get loads of blog posts giving overviews of the changes as well as YouTube videos of conference talks on different things, which I watch in general as part of my on-going learning and development.
C++ completed a cycle of related versions with C++11/14/17 so a lot of firms have settled on C++17 for now. C++20 introduced a LOT of new language features, some of which are still being explored and implemented and is still considered bleeding edge. C++23 has been finalised but is still going through the final ratification as far as I know.
It is absolutely fine to be a few years behind the curve, as unlike other languages (typically controlled by one company) where a new version ships at the same time as compiler/library support, for C++ the spec is released first and then the many different vendors implement it (in some cases approved features are implemented ahead of release - typically Microsoft gets library features implemented quick while other compilers get language features quick. Modules are the notable exception to this rule).
C is peak C for me. I think you can better modularize in C than in C++ because with APIs build around incomplete struct types the implementation stays in the C file and does not leak into the header as with classes.
For me the only truly compelling C++ features are RAII and generics (not classes or virtual functions), and those are compelling enough for me to not consider C when I can choose C++. From what I can tell, the Rust designers seem to have felt the same way.
[+] [-] jenadine|2 years ago|reply
[+] [-] asicsp|2 years ago|reply
[+] [-] harporoeder|2 years ago|reply
[+] [-] maccard|2 years ago|reply
[+] [-] aragonite|2 years ago|reply
[+] [-] scatters|2 years ago|reply
[+] [-] tcfhgj|2 years ago|reply
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
[+] [-] mebassett|2 years ago|reply
[+] [-] fooker|2 years ago|reply
Compilers, games, all of the backends of the current LLM revolution, control systems for interesting hardware.
You would sabotage yourself if you choose not to learn how to use a possibly suboptimal tool that is an industry standard.
[+] [-] oconnor663|2 years ago|reply
[+] [-] angiosperm|2 years ago|reply
[+] [-] fulafel|2 years ago|reply
[+] [-] conradfr|2 years ago|reply
I'm currently doing a C++ audio plugin with the Juce framework.
This website has been a good resource, alongside https://www.learncpp.com
But I was actually close to give up before using those two things:
- https://github.com/nlohmann/json : my plugin use a json api backend and the Juce json implementation is atrocious (apparently because of being born with a previous C++ version), but this library is GREAT.
- ChatGPT 4. I'm not sure I would have "succeeded" without it, at least not in a reasonable time frame. ChatGPT 3.5 is slow and does not give good results for my use case but 4 is impressive. And I use in a very dumb way, just posing question in the web UI. I probably could have it directly in MSVC?
Also I must say, for all its flaws, I have a renewed appreciation for doing UI on the web ;)
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] subharmonicon|2 years ago|reply
I’d love to be in a position to work on a new project using Rust or Haskell instead.
[+] [-] csk111165|2 years ago|reply
[+] [-] AtlasBarfed|2 years ago|reply
Are string literals only 8 bit chars aka no real Unicode? The description danced around it so much it sounds like obfuscation
[+] [-] hgs3|2 years ago|reply
[1] https://en.cppreference.com/w/c/language/string_literal
[2] https://en.cppreference.com/w/cpp/language/string_literal
[+] [-] csk111165|2 years ago|reply
[+] [-] jocoda|2 years ago|reply
[+] [-] Usingless|2 years ago|reply
[+] [-] angiosperm|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] w10-1|2 years ago|reply
Today there are so many IDE's and online coding environments, godbolt, Swift playgrounds, golang interactive tutorials, etc. It would be lovely to see a C++ tutorial join that trend.
I find the tutorial unsettling from the first words: `original, self-contained`. My first step in writing a tutorial would be to link the current state of the art, and the last would be a section pointing users to further resources, if my goal were not to trap readers but to help them. (Originality is a tall claim as the internet spawns LLMs.)
Without any orientation to the landscape, the tutorial proceeds step-by-step with topologically-sorted vignettes that explain themselves verbosely.
hello-world is prefixed by a long explanation why people start with hello-world, and following by 16 paragraphs of (to me) excruciating hand-holding and suggested experiments, without re-quoting the code. It's like pair-programming with someone who tells you what to type.
The original K&R book was breathtakingly brief, mainly just showing you how to do things. Effective C++ neatly crystallized specific problems and solutions. Both benefited most by what they left out.
Outside of an interactive tutorial for newbie's, what's needed for "modern" C++ is an origin story for each feature: what motivated it, how backwards-compatibility shaped it, what design decisions were made, how well it has been implemented and used -- ideally with bonus comparisons how Rust and Swift and Go managed the same issues. I think that would help people remember the complex issues and the syntax, and how to use it.
To me most of the discussion from the C++ originators is more expository than explanatory: `for each opinion, explain in detail with cross-references to other opinions` - the political template. But readers only need to know the distinctions that make a difference in when and how they use a feature.
Actual users are busy and paid only to get things done, not sling words. Users who value their time will pay for a good resource.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] binary132|2 years ago|reply
C++ posts on HN generate drama because of C++ People bickering with C++ People.
[+] [-] klipt|2 years ago|reply
Do I contradict myself?
Very well then I contradict myself,
(I am large, I contain multitudes.)
[+] [-] synergy20|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] 7thaccount|2 years ago|reply
As someone familiar with nearly a dozen scripting languages, I keep trying for something low level like C++, but it seems like these languages are impenetrable at times. It's hard enough to learn the machine stuff and manual memory management, but having the syntax change more often than a toddler's favorite color just makes it all seem impossible.
[+] [-] liendolucas|2 years ago|reply
I think that Ken Thompson nailed it on C++: https://en.wikiquote.org/wiki/Ken_Thompson#%22Coders_At_Work...
Also Linus Torvalds is a huge detractor of C++: http://harmful.cat-v.org/software/c++/linus
But in the end everyone should pick whatever programming language feel comfortable with. Sometimes if you're pursuing a career in certain directions (e.g: game development) you have literally no choice but to knee down and learn whatever the industry is pushing to use.
[+] [-] steveklabnik|2 years ago|reply
Programmers like really neat logical explanations for everything, but the real world is much messier. People do not acquire human language skills by learning a formal grammar, learning all the edge cases, and then finally speaking: they attempt to communicate as best they understand, and then refine their knowledge over time.
The same works with computer languages. Not just C++. You don't generally learn every single detail before you do meaningful work. You just kinda try stuff and figure things out. Sure, you may practice specific skills, but that's just not the primary method of learning. And even in those cases, you don't necessarily learn everything before you return to practicing what you've learned: it's a process where the two activities feed into each other.
You mostly just go "damn I wish there was a better way to do X" and then find out there's a paper someone wrote, and then you pay attention to its progress. Or you just keep doing what you're doing, and at some point, a blog post comes out that's a summary of what's new, and you go "ooh that sounds interesting, I should look into that." But for every feature like that, there's also features which you go "ehh I don't need to care." And that's generally fine.
> having the syntax change more often than a toddler's favorite color
No real syntax is different here, this is a function call like any other. And C++ changes on a three year timescale. Many scripting languages release new versions far faster. It's just stuff that's less familiar to you, and so it seems harder, but it's learnable.
> It's hard enough to learn the machine stuff and manual memory management
This is the bigger struggle with learning, moreso than "syntax changes." If you haven't done lower level stuff before, you also have to recon with that while learning. That does make things harder the first time you learn a new paradigm, just like if you'd never used a functional language before, you'd be learning about those concepts as well as the syntax and specific language semantics.
[+] [-] DoctorDabadedoo|2 years ago|reply
- No standard / user friendly tooling: there is no package manager, getting dependencies "as easy as copying a header from this github repo" is messy, is a liability, generates toil, etc.
- The language is very complex, i.e. there are 7 different ways just to declare a variable (I'm not even discussing templates, optionals and what not) and more often than not C++ projects spans years or decades, there is a natural mix of styles from people across different generations on what is "modern" and it's a sore to my eyes. At every release rarely things are removed from the language, but there is always something added.
At every company, the subset of what features are reasonable to use, understood and well maintained can change drastically. That might be a company problem, not a language one, but it's something sistematic enough that I would say it's a language thing.
- Every language has its gotchas, but with beginners interested in using fancy features of the language, the surface area is just too big.
I've read once on the blog of a former member of the C++ technical steering committee, that at his best, when actively working with the committee and focused on this, he maybe knew 50% of the language spec. What are the odds of the common folk knowing the pitfalls and good practices of the language and that staying relevant in 5-10 years?
Even though C++ is the language programmed the most in my career and I can appreciate how nice it is at the right conditions, I've come to accept that the tenets of the language, the way the TSC sees it (stability, backward compatibility, performance) no longer resonate with me and I come to appreciate the consistency, simplicity and ease of use of other projects, there is a bigger world out there and the pond of C++ issues is a place I would rather leave behind.
[+] [-] gumby|2 years ago|reply
And C++ is explicitly a multi-paradigm language so there can be affordances for multiple approaches. You can even use it as an OOP language if you want!
As far as syntax changes go, mostly they are in the direction of simplification and/or unification intended to make programming easier in the long run. So, for example, you can now in many cases write template generics without the elaborate template syntax.
But the C++ is also pretty unwilling to break old code, so old syntax and obsolete semantics are still available should you so choose. This is confusing to people who come to the language later on.
(Note that above I wrote “intended to make programming easier”. The case I cited of generics does make some things easier for me, but of course de gustibus and all that.)
[+] [-] einpoklum|2 years ago|reply
The answer is: Effectively not hard, because:
1. When you write complicated software - especially with older-standard-version C++ - you often have the thought of "Oh, if I could only do X more easily" or "wouldn't it be good if we could skip the tedious coding to make the compiler do Y?" - and then you either grit your teeth and write something ugly which works. But then, a few years later, you hear it mentioned that X' or Y' have been standardized, and then you know "Oh, good, now I can do that more easily".
2. Stuff that you _don't_ know about, that gets introduced - you typically don't have to know about. Either it's not relevant to you, or it is, but you're just writing old-style code.
3. The "junk" gradually makes you be able to write the code you want more easily. So, unless you want to do deep guru things - you can gradually even _forget_ things you used to know how to do, since you no longer need to know about them.
[+] [-] fsloth|2 years ago|reply
C++ is a weird combination of pragmatic features, close to the metal performance (which you can junk if you don’t actually understand what is happening on machine kevel), universally abysmal tooling (compared to other current languages), huge ecosystem of super-usefull super-nontrivial libraries… a combination of super good and super bad.
If you don’t need the super good stuff (which you don’t need unless you know you need it) all you are left with is the bad stuff.
The C++11 is okay. C++ committee is a weird combination of clown-car non-savant idiots and super talented pros.
[+] [-] pompino|2 years ago|reply
[+] [-] hoten|2 years ago|reply
Herb Sutter has been working on it for awhile. My only exposure to it has been watching this recent talk:
https://youtu.be/8U3hl8XMm8c?si=phHkBNFGaroYbeb9
[+] [-] jansommer|2 years ago|reply
[+] [-] jviotti|2 years ago|reply
[+] [-] bingo3131|2 years ago|reply
C++ completed a cycle of related versions with C++11/14/17 so a lot of firms have settled on C++17 for now. C++20 introduced a LOT of new language features, some of which are still being explored and implemented and is still considered bleeding edge. C++23 has been finalised but is still going through the final ratification as far as I know.
It is absolutely fine to be a few years behind the curve, as unlike other languages (typically controlled by one company) where a new version ships at the same time as compiler/library support, for C++ the spec is released first and then the many different vendors implement it (in some cases approved features are implemented ahead of release - typically Microsoft gets library features implemented quick while other compilers get language features quick. Modules are the notable exception to this rule).
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] kajaktum|2 years ago|reply
[+] [-] uecker|2 years ago|reply
[+] [-] senderista|2 years ago|reply
[+] [-] angiosperm|2 years ago|reply
[+] [-] rlawson|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] vicss|2 years ago|reply
[deleted]