6 ms·

C++ is my daily language. Has been for my entire career since the mid 90s. About 10 years ago I gave up trying to understand it all and things have been fine. G

by jahnu 4y ago

C++ is my daily language. Has been for my entire career since the mid 90s. About 10 years ago I gave up trying to understand it all and things have been fine. Good even. Even more so since I pushed warnings to max (where possible), tooling like clang-tidy, -format, and all the other static analysers, multiple compilers on multiple platforms, and extensive use of tests and so on. You know, general best practices. To the extent I've forgotten loads of things. So what I want to say is, it's not necessary at all to understand the language completely or even mostly in order to do good, high quality, productive work with it. Not even close. Maybe with the advent of AI tools like co-pilot I can even start to forget more ;)

qwerty456127 4y ago
Real low-level assembly language probably is easier to really understand and reason about than C++, isn't it? I used to code in C++ with Borland C++ Builder and it felt almost the same like doing WinForms with C# pracrtically but once you want to really understand the language and what's going on the deeper level C++ seems infinitely obscure.
- nuancebydefault 4y ago
  Code written in the standard of C++ of 20 years ago (pre-c++11) does not even remotely look anymore like today's code conforming c++17. (let alone 20 or 23). Understanding it only got harder over time.
  - FpUser 4y ago
    Std lib level code for sure. Application level is easy to grasp if written by decent programmer.
    - badpun 4y ago
      However, Application code is calling all these nightmarish library functions which you don’t understand and have to rely heavily on documentation and experimentation to use. It’s not like that at all in e.g. Java, where reading the standard library code is a pleasant and educating practice.
      - account42 4y ago
        This is good because unlike Java, for C++ there are several standard library implementations so relying on something that happens to be guaranteed by one is not a good idea. The standard and documentation is the only place where you will find what is actually guaranteed to work.
      - FpUser 4y ago
        Please stop this FUD. I have zero trouble using std::whatever in C++ without diving into their code. Usage is very well though out and user friendly. Higher level libraries do use templates on a different level and are very readable.
- AnimalMuppet 4y ago
  > Real low-level assembly language probably is easier to really understand and reason about than C++, isn't it? No. There's no comparison. Assembly is far harder. Assembly can be completely unstructured. It can jump into the middle of a subroutine. OS permitting, it can be self-modifying. You have to have a very clear understanding of how each instruction can affect the condition flags. Instead of getting very familiar with the C++ spec, you're getting very familiar with the chip spec. You can write clean, understandable assembler. To do so, you have to have self-discipline. You have to resist using all the things that the assembler makes possible. But you can do that in C++, too - and should.
  - tialaramex 4y ago
    It's hard to judge. They're both potentially too complicated to understand, and in different ways. I think we probably have to give it to assembly as easier though. There's no IFNDR in assembly. (Ill-Formed No Diagnostic Required: the C++ get out which says well, this isn't a C++ program and so it has no defined meaning but your compiler probably won't even warn you about that, so your code does compile it just has no defined behaviour)
    - pwdisswordfishc 4y ago
      There is. It's called "undefined opcode".
      - tialaramex 4y ago
        Undefined Opcodes are just like C++ UB. They're very bad news, but they're nothing compared to how terrible IFNDR is. I think C++ programmers either don't realise how bad IFNDR is, or they just don't want to think about it. IFNDR means your entire program is always meaningless. Let's take a UB example, an IFNDR example, and an undefined Opcode example and compare the potential consequences 1. UB example. We have a program which does some work in a loop, the user can select how many times between 0 and 256 the loop should execute. Unfortunately this should have been limited to 255 times, if the user picks 256 the loop exit condition is always false. In C++ this is Undefined Behaviour and the program's behaviour is arbitrary once that arises. So long as you never select 256 in the loop iteration setting, this program is fine. 2. IFNDR example. This program only lets the user select between 0 to 200 iterations. Unfortunately if more than 10 iterations are used the arithetic inside the loop uses a std::vector of floating point values with an algorithm specifying that the values are std::totally_ordered, as a result this is IFNDR because floating point values are a structural match, so this compiles, but they aren't a semantic match for the total order concept and that's IFNDR. Even if the feature is never activated and nothing is ever processed with the std::totally_ordered algorithm, the behaviour of the entire program is undefined, the program has no meaning at all. Running this program at all could cause anything to happen. 3. Undefined Opcode. This time the program has between 1 and 100 iterations, it's written in assembly but unfortunately due to an oversight for the odd numbers of iterations the undefined Opcode GLARK R0,R0 is executed which only works on a model of CPU which you don't have. This program misbehaves, perhaps spontaneously rebooting or showing other bizarre behaviour - but only if that Opcode is executed, which for even numbers of iterations never happens. So long as you only use even numbers of iterations, this program is fine.
- jsrcout 4y ago
  > Real low-level assembly language probably is easier to really understand and reason about than C++, isn't it? I've often thought that. If nothing else, if a given opcode (say, an ADD) is being used, things like integer wraparound are going to do something specific and well defined, not cause undefined behavior and invalidate the entire execution of your program. I miss that from my 6502 assembly programming days :-).
nuancebydefault 4y ago
This comes back in comments on HN regularly: 'I use this or that daily and I like it' . Be it windows 10, linux, Android, Rust. If you use something daily for 30 years, there is a LOT you know about it. You forget how much you know about it. Probably you type and read std:unique_ptr<> as fast as you can type an asterisk. All those best practices exist for a reason, and one of the main reasons is that it is such a convoluted language that even compiler makers have trouble understanding the spec (hence multiple targets, linting etc). So kudos to you!
- jahnu 4y ago
  This is a very fair point that I agree with and in retrospect I wish I had emphasised the limits of what I was trying to get across. But your and other replies have done it for me so I'll leave it as it is.
- Kranar 4y ago
  No this is not true and it's actually a common misconception. It is not true that doing something for a long time makes you better at it or more knowledgeable about it. There is an excellent meta-analysis [1] that looks at domains such as music, games (such as chess), sports and other domains that shows that people must put in deliberate practice and make an explicit effort to improve, otherwise they simply stagnate and get into a bit of a comfort zone with little to no improvement. When it comes to programming I often say that there is a difference between someone who has ten years of actual programming experience, and someone who has two years of experience that they just repeated five times. I can state from experience that there are plenty of C++ developers who have been using it for decades who don't know basic things about it, and use it like it was still 1995. [1] Deliberate Practice and Performance in Music, Games, Sports, Education, and Professions
titzer 4y ago
What you are describing is the desire to rely on your tooling and tests, and you should be able to. Unfortunately, in the 25 years I've known C++, I feel like I've been promised this and that and the other thing was making C++ safe, correct, reliable, etc. And yet this goal seems elusive. I'm glad that you don't have to think about most of the language these days, but there are too many trapdoors and landmines waiting out there, and in C++ they have serious consequences. There are bugs in the code--probably in your code--right now. Some might be CVEs because of how little guarantees you have when you stumble into UB. I hope we get past the "works for me" and realize the downstream implications of software being riddled with potentially serious bugs that result from a ton of complexity coupled with explosive consequences.
- scoutt 4y ago
  I guess you can still write valuable software, even more complex than most people can write in a lifetime, with simple (03) C++. Like Doom 3: https://github.com/id-Software/DOOM-3-BFG https://github.com/id-Software/DOOM-3-BFG > What you are describing On the other hand, while I think you have the best intentions, I believe what you are describing is also the exact meaning of FUD. In that precise order: "in C++ they have serious consequences" is Fear, "There are bugs in the code--probably in your code--right now" is Uncertainty, and "Some might be CVEs" is Doubt.
  - kajaktum 4y ago
    I guess. The other day i created a PR to turn some macros into a variadic template and got a compilation error that can be resolved by moving some functions around. No one could figure out why so i just closed the PR. There are so many moving parts in C++ there’s a reason why there are dialects. People are manually having to choose the smaller C++ that they can manage.
  - titzer 4y ago
    Bah, 2/3rds of CVEs are buffer overruns that cause RCE. That doesn't occur in memory safe languages. I mean, you can juggle double-ended chainsaws on fire as a party trick, but probably not recommended for daily activities.
FpUser 4y ago
>"So what I want to say is, it's not necessary at all to understand the language completely" I agree. Same here been using C++ forever, first as "C with classes" and then "modern C++" and whole bunch of other languages as well. I have general understanding about "big" parts but I learn specifics on on need basics and yes tooling / internet search helps greatly. I manage to write software that works reliably and do not sweat over those FUD spreading prophets telling me that my software will self explode every other day.
blacklight 4y ago
I've also spent a decade writing almost exclusively code in C++. After a decade, there was no end in sight on all the obscure patterns and way of doing things provided by the language. After a decade I realized that the more I learned about the language, the more I needed to know. And that's when I called it a day and promised myself not to touch this pile of smoking crap even with a stick in my career. I write code because I like to build things that solve real problems, not because I like to jerk myself off on all the possible theoretical ways to initialize a variable or a pointer. If you need to read tons of fat books to be aware of all the nuances of the language, then the language has failed its goal of being a useful tool to build things. And where are the advantages given by all the possible types of memory allocation, pointer declaration and variable initialization? C++ is still a memory-unsafe language, after all. So you still have to handle most of the low-level complexity of C, while getting a language polluted by four decades of patches and crap, and having to read big books just to understand how initialization and pointers work. No wonder that C++ is increasingly becoming a relic confined to the cemetery of bad technological ideas, no new software is being built in it at all, and Rysy and Go are eating all of its cake.
- mvuksano 4y ago
  > If you need to read tons of fat books to be aware of all the nuances of the language, then the language has failed its goal of being a useful tool to build things. You should probably judge usefulness the language by how much software was produced using it. > No wonder that C++ is increasingly becoming a relic confined to the cemetery of bad technological ideas, no new software is being built in it at all, and Rysy and Go are eating all of its cake. Do you have any data to support this? Where i work (one of FAANG) we don't use Go at all and rust is limited to only certain types of applications. Other stuff is either python or c++.
  - blacklight 4y ago
    > You should probably judge usefulness the language by how much software was produced using it. Then Fortran and Cobol are probably the most useful languages (and maybe Java can be on that list too), but can we say that they're actually loved by those who program in them, or that they offer a modern and fast way of building software? Eventually, how much software was written in a language is mostly a function of how long that language has been around. > Do you have any data to support this? Just pick any news article about any large projects migrating from C/C++ to Go/Rust. C/C++ have historical issues with memory management that make it too easy for the code to blow up. The vast majority of CVEs is about vulnerabilities caused by improper memory allocation, deallocation or assignment. And, in order to mitigate some of those issues, C++ has become so complex that it makes it harder to shoot your foot, but easier to blow up your own leg. Sure, all FAANGs have been writing most of their core software in these languages, but they've also invested a lot of resources in building alternative languages that were simpler but equally performant/expressive. Keep in mind that FAANG companies have to onboard hundreds or thousands of engineers, and the cost of getting somebody to be proficient in Go, Rust, Python or Kotlin is much, much lower than getting somebody to be proficient in C++ - and, most of all, to get somebody in a position where they can reliably push code to production that doesn't blow up.
HarHarVeryFunny 4y ago
Right - the vast majority of C++ enhancements since 2017 (maybe 2014, or even 2011) arn't even targeting application developers - they are meant to support libraries.

by jahnu 4y ago

qwerty456127 4y ago

Real low-level assembly language probably is easier to really understand and reason about than C++, isn't it? I used to code in C++ with Borland C++ Builder and it felt almost the same like doing WinForms with C# pracrtically but once you want to really understand the language and what's going on the deeper level C++ seems infinitely obscure.

nuancebydefault 4y ago
Code written in the standard of C++ of 20 years ago (pre-c++11) does not even remotely look anymore like today's code conforming c++17. (let alone 20 or 23). Understanding it only got harder over time.
- FpUser 4y ago
  Std lib level code for sure. Application level is easy to grasp if written by decent programmer.
  - badpun 4y ago
    However, Application code is calling all these nightmarish library functions which you don’t understand and have to rely heavily on documentation and experimentation to use. It’s not like that at all in e.g. Java, where reading the standard library code is a pleasant and educating practice.
    - account42 4y ago
      This is good because unlike Java, for C++ there are several standard library implementations so relying on something that happens to be guaranteed by one is not a good idea. The standard and documentation is the only place where you will find what is actually guaranteed to work.
    - FpUser 4y ago
      Please stop this FUD. I have zero trouble using std::whatever in C++ without diving into their code. Usage is very well though out and user friendly. Higher level libraries do use templates on a different level and are very readable.
AnimalMuppet 4y ago
> Real low-level assembly language probably is easier to really understand and reason about than C++, isn't it? No. There's no comparison. Assembly is far harder. Assembly can be completely unstructured. It can jump into the middle of a subroutine. OS permitting, it can be self-modifying. You have to have a very clear understanding of how each instruction can affect the condition flags. Instead of getting very familiar with the C++ spec, you're getting very familiar with the chip spec. You can write clean, understandable assembler. To do so, you have to have self-discipline. You have to resist using all the things that the assembler makes possible. But you can do that in C++, too - and should.
- tialaramex 4y ago
  It's hard to judge. They're both potentially too complicated to understand, and in different ways. I think we probably have to give it to assembly as easier though. There's no IFNDR in assembly. (Ill-Formed No Diagnostic Required: the C++ get out which says well, this isn't a C++ program and so it has no defined meaning but your compiler probably won't even warn you about that, so your code does compile it just has no defined behaviour)
  - pwdisswordfishc 4y ago
    There is. It's called "undefined opcode".
    - tialaramex 4y ago
      Undefined Opcodes are just like C++ UB. They're very bad news, but they're nothing compared to how terrible IFNDR is. I think C++ programmers either don't realise how bad IFNDR is, or they just don't want to think about it. IFNDR means your entire program is always meaningless. Let's take a UB example, an IFNDR example, and an undefined Opcode example and compare the potential consequences 1. UB example. We have a program which does some work in a loop, the user can select how many times between 0 and 256 the loop should execute. Unfortunately this should have been limited to 255 times, if the user picks 256 the loop exit condition is always false. In C++ this is Undefined Behaviour and the program's behaviour is arbitrary once that arises. So long as you never select 256 in the loop iteration setting, this program is fine. 2. IFNDR example. This program only lets the user select between 0 to 200 iterations. Unfortunately if more than 10 iterations are used the arithetic inside the loop uses a std::vector of floating point values with an algorithm specifying that the values are std::totally_ordered, as a result this is IFNDR because floating point values are a structural match, so this compiles, but they aren't a semantic match for the total order concept and that's IFNDR. Even if the feature is never activated and nothing is ever processed with the std::totally_ordered algorithm, the behaviour of the entire program is undefined, the program has no meaning at all. Running this program at all could cause anything to happen. 3. Undefined Opcode. This time the program has between 1 and 100 iterations, it's written in assembly but unfortunately due to an oversight for the odd numbers of iterations the undefined Opcode GLARK R0,R0 is executed which only works on a model of CPU which you don't have. This program misbehaves, perhaps spontaneously rebooting or showing other bizarre behaviour - but only if that Opcode is executed, which for even numbers of iterations never happens. So long as you only use even numbers of iterations, this program is fine.
jsrcout 4y ago
> Real low-level assembly language probably is easier to really understand and reason about than C++, isn't it? I've often thought that. If nothing else, if a given opcode (say, an ADD) is being used, things like integer wraparound are going to do something specific and well defined, not cause undefined behavior and invalidate the entire execution of your program. I miss that from my 6502 assembly programming days :-).

nuancebydefault 4y ago

This comes back in comments on HN regularly: 'I use this or that daily and I like it' . Be it windows 10, linux, Android, Rust. If you use something daily for 30 years, there is a LOT you know about it. You forget how much you know about it. Probably you type and read std:unique_ptr<> as fast as you can type an asterisk. All those best practices exist for a reason, and one of the main reasons is that it is such a convoluted language that even compiler makers have trouble understanding the spec (hence multiple targets, linting etc). So kudos to you!

jahnu 4y ago
This is a very fair point that I agree with and in retrospect I wish I had emphasised the limits of what I was trying to get across. But your and other replies have done it for me so I'll leave it as it is.
Kranar 4y ago
No this is not true and it's actually a common misconception. It is not true that doing something for a long time makes you better at it or more knowledgeable about it. There is an excellent meta-analysis [1] that looks at domains such as music, games (such as chess), sports and other domains that shows that people must put in deliberate practice and make an explicit effort to improve, otherwise they simply stagnate and get into a bit of a comfort zone with little to no improvement. When it comes to programming I often say that there is a difference between someone who has ten years of actual programming experience, and someone who has two years of experience that they just repeated five times. I can state from experience that there are plenty of C++ developers who have been using it for decades who don't know basic things about it, and use it like it was still 1995. [1] Deliberate Practice and Performance in Music, Games, Sports, Education, and Professions

titzer 4y ago

What you are describing is the desire to rely on your tooling and tests, and you should be able to. Unfortunately, in the 25 years I've known C++, I feel like I've been promised this and that and the other thing was making C++ safe, correct, reliable, etc. And yet this goal seems elusive. I'm glad that you don't have to think about most of the language these days, but there are too many trapdoors and landmines waiting out there, and in C++ they have serious consequences. There are bugs in the code--probably in your code--right now. Some might be CVEs because of how little guarantees you have when you stumble into UB. I hope we get past the "works for me" and realize the downstream implications of software being riddled with potentially serious bugs that result from a ton of complexity coupled with explosive consequences.

scoutt 4y ago
I guess you can still write valuable software, even more complex than most people can write in a lifetime, with simple (03) C++. Like Doom 3: https://github.com/id-Software/DOOM-3-BFG https://github.com/id-Software/DOOM-3-BFG > What you are describing On the other hand, while I think you have the best intentions, I believe what you are describing is also the exact meaning of FUD. In that precise order: "in C++ they have serious consequences" is Fear, "There are bugs in the code--probably in your code--right now" is Uncertainty, and "Some might be CVEs" is Doubt.
- kajaktum 4y ago
  I guess. The other day i created a PR to turn some macros into a variadic template and got a compilation error that can be resolved by moving some functions around. No one could figure out why so i just closed the PR. There are so many moving parts in C++ there’s a reason why there are dialects. People are manually having to choose the smaller C++ that they can manage.
- titzer 4y ago
  Bah, 2/3rds of CVEs are buffer overruns that cause RCE. That doesn't occur in memory safe languages. I mean, you can juggle double-ended chainsaws on fire as a party trick, but probably not recommended for daily activities.

FpUser 4y ago

>"So what I want to say is, it's not necessary at all to understand the language completely" I agree. Same here been using C++ forever, first as "C with classes" and then "modern C++" and whole bunch of other languages as well. I have general understanding about "big" parts but I learn specifics on on need basics and yes tooling / internet search helps greatly. I manage to write software that works reliably and do not sweat over those FUD spreading prophets telling me that my software will self explode every other day.

blacklight 4y ago

I've also spent a decade writing almost exclusively code in C++. After a decade, there was no end in sight on all the obscure patterns and way of doing things provided by the language. After a decade I realized that the more I learned about the language, the more I needed to know. And that's when I called it a day and promised myself not to touch this pile of smoking crap even with a stick in my career. I write code because I like to build things that solve real problems, not because I like to jerk myself off on all the possible theoretical ways to initialize a variable or a pointer. If you need to read tons of fat books to be aware of all the nuances of the language, then the language has failed its goal of being a useful tool to build things. And where are the advantages given by all the possible types of memory allocation, pointer declaration and variable initialization? C++ is still a memory-unsafe language, after all. So you still have to handle most of the low-level complexity of C, while getting a language polluted by four decades of patches and crap, and having to read big books just to understand how initialization and pointers work. No wonder that C++ is increasingly becoming a relic confined to the cemetery of bad technological ideas, no new software is being built in it at all, and Rysy and Go are eating all of its cake.

mvuksano 4y ago
> If you need to read tons of fat books to be aware of all the nuances of the language, then the language has failed its goal of being a useful tool to build things. You should probably judge usefulness the language by how much software was produced using it. > No wonder that C++ is increasingly becoming a relic confined to the cemetery of bad technological ideas, no new software is being built in it at all, and Rysy and Go are eating all of its cake. Do you have any data to support this? Where i work (one of FAANG) we don't use Go at all and rust is limited to only certain types of applications. Other stuff is either python or c++.
- blacklight 4y ago
  > You should probably judge usefulness the language by how much software was produced using it. Then Fortran and Cobol are probably the most useful languages (and maybe Java can be on that list too), but can we say that they're actually loved by those who program in them, or that they offer a modern and fast way of building software? Eventually, how much software was written in a language is mostly a function of how long that language has been around. > Do you have any data to support this? Just pick any news article about any large projects migrating from C/C++ to Go/Rust. C/C++ have historical issues with memory management that make it too easy for the code to blow up. The vast majority of CVEs is about vulnerabilities caused by improper memory allocation, deallocation or assignment. And, in order to mitigate some of those issues, C++ has become so complex that it makes it harder to shoot your foot, but easier to blow up your own leg. Sure, all FAANGs have been writing most of their core software in these languages, but they've also invested a lot of resources in building alternative languages that were simpler but equally performant/expressive. Keep in mind that FAANG companies have to onboard hundreds or thousands of engineers, and the cost of getting somebody to be proficient in Go, Rust, Python or Kotlin is much, much lower than getting somebody to be proficient in C++ - and, most of all, to get somebody in a position where they can reliably push code to production that doesn't blow up.

HarHarVeryFunny 4y ago

Right - the vast majority of C++ enhancements since 2017 (maybe 2014, or even 2011) arn't even targeting application developers - they are meant to support libraries.