Exactly! And the question is why? I think the answer is that we try to express increasingly higher-level concepts in an inherently brittle, low-level language.
@@Evan490BC I don't think that's really the case. Powerful abstractions and low-level features can co-exist (look to Rust for that lesson). C++ has the problem that very early on it made choices that fundamentally impact its ability to do that well. Most notably, it opted to be C compatable. And the tradeoffs C made *very much cut against* a coherent delivery of the abstractions C++ wants to deliver. So there can be many very pleasant subsets of C++, but C++ in the aggregate can't really be coherent.
I disagree. It’s a language for certain kinds of specialists. To the extent that you find yourself less knowledgeable in some areas of programming, it’s because either you haven’t had enough the experience yet, or you are not working in that domain. Do game programmers consider themselves experts in embedded programming on low-power devices? Probably not. Does someone writing device drivers consider themselves an expert in game programming? Again, probably not. C++ is really just a language for people who want to be close to the hardware. If that’s not your goal, then C++ is probably not the best language to use for your particular situation. Perhaps a better language would be OCaml, or TypeScript, or Kotlin. All of those languages have their own strong use cases. That said, if your goal is to have fun, then ANY programming language will work just fine. No expertise is required for that.
Most linkers will emit errors when ODR is violated, you have to overload the default flags to get a conflict to build. Though there are ways to make the error quiet, for instance by having multiple copies of the same inline function with different compile-time flags, but that is a lot more complex to trigger.
31:44 wrt #3, simple, easy to read, this is possible already with macros, templates, operator overloading, etc. Some parts are going to be complex. What I suggest is to isolate the complex parts as their own function, and call them in the simple parts.
Performance I agree with. Not having to worry about 5 years from now recompiling the same code suddenly doesn't perform as expected is extremely crucial more so than anything else on the list. After all C & C++ are the two primary languages use in writing code for OSes, and most other languages compilers. I don't want to have to rewrite thousands of lines of code in my libraries just a few people thought it was a good idea to change something. So maybe even move it to number 1 stability. Add what the hell you want but don't break what currently works.
Also, oh you're hardware is x-years old, and it's no longer compliant to "our" language so you'll have to buy new machinery... Bullshit! If I spend money on a machine and as long as it continues to physically work, any Standardized or Industrial use Language should still work on it even if it's been 100 years later! They don't see the bigger picture... How many Nuclear Power Plants are in operation that still runs on C or pre C++11 before there was any standard? What happens when newer facilities are built within the next 5-10 years and they no longer use the "older systems" and are all reliant on their proposed "newer" system of the language... Then in 20 years according to their model, that hardware is not compliant so it won't be able to use the newer versions... and then all of a sudden a massive break down... Yeah, not a good proposition at all! The backward-compatible model is there for a reason! How many power plants, water stations, sewage treatment plants, traffic control systems, avionics, etc. rely on those older systems?
@@skilz8098 A Program might no longer compile IF you are using newer language versions. But that got nothing to do with Hardware as C++ is - as most languages - fairly hardware independent.
@@ABaumstumpf Right! No one is suggesting that your code will suddenly break. Rather, the suggestion is that ABI can occasionally change with a new version of the language. E.g. if you want to upgrade to C++23, you might not be able to use hardware from 2000 and you might need to upgrade or recompile libraries on which you depend. But, if you're happy with, say, C++17, you can just continue to use C++17.
@@skilz8098 je problem seems pretty well sorted now since you cant specify the standard level you want to compile for. Anyway i sincerelly doubt there is that many programmers knowing a particular revision 40 years after it has been out.
Well if you take in account UB nonsense then this point doesn't hold. You either know by heart EVERYTHING in the standard down to the last edgecase and write all your code such as nothing that the standard deems as UB ever happens or you will risk that some day some compiler idiot will decide to optimise based on that and break your code. So if you want your code to be truly stable, you better not update your compiler to the last version unless you really know what you are doing and are ready to test your whole codebase thoroughly. Not updating your compiler is something you can do in any language, so this point simply does not apply, not until someone decides to adopt a reasonable posture towards UB. A stable language is a well defined one, C/C++ is simply not.
While I agree that C++ definitively isn't a language to be taught in CS1, the principle of teachability is very closely linked to priority no 3 " Simple, easy to ready easy to understand, easy to write" of the speakers themselves, which ranks higher than "practical safety guarantees and testing mechanisms". I'd argue that, especially the "easy to understand" is more or less the same as being easily teachable.
@@Carewolf It'll be different for most unis. Besides, there's no need to teach students C++ if the uni already teaches a nice collection like Python, C, MIPS, Haskell, Prolog and Bash. Lastly, you can obviously do most systems programming in C - in fact, most is.
Disagree, I found it excellent for my CS1 and CS2, as a student. By not hiding the mechanics it is much easier to understand what is really happening and why we do a thing the way we do it, while still having mechanisms to avoid the tedium of directly dealing with the underlying bits in normal use. "Easy" languages are completely inappropriate for CS courses and fail to give students a stable foundation.
Unfortunately, there is an error at 16:02. There are some subtle details with constant variables in C++ programming language. 7.11.6, C++2003: "A name declared in a namespace scope without a storage-class-specifier has external linkage unless it has internal linkage because of a previous declaration and provided it is not declared const. Objects declared const and not explicitly declared extern have internal linkage." So both variables in bar.cc and foo.cc has internal linkage, and speakers are wrong that this is an ill-defined program. It is well - defined, but foo.h is incorrect.
But I have to add that, notwithstanding parallel compiles and the inherently redundant work therein, there’s a LOT the linker could do to prevent ODR violations if the object file contained enough metadata. It’s not even particularly hard to do.
First language has two meanings, it is overloaded. CS 101, or the language someone who has taken no prior computer science courses, and "first language" meaning of perhaps several that one uses semi-regularly, the one knows the best or most about....C++ might be better as an every day language, than someone who usually uses something else and tries to come back to it casually from time to time...of course, recently, that probably means the language Standard in common use may have changed. Lots of newer, better, easier ways to do things...that weren't there the last time you seriously studied it.
I don't get the NDR at 16:08. MSVC 19.16.27034 gives me: bar.obj : error LNK2005: "int a" (?a@@3HA) already defined in foo.obj fatal error LNK1169: one or more multiply defined symbols found
There's much more to CS than learning a language. Having a degree would mean you took specific class that would help you out, but it's definitely not necessary.
To understand C++ as a language, no. However, if you want to have a good understanding of algorithms and data structures, computational complexity etc., you need at least some knowledge of CS.
No, but a "good" education in CS makes it a lot easier to understand why C++ behaves in weird ways. It makes it easy to understand the legacy and the hardware and ABI.
Most saws do not cut "through abrasion." Most cut like knives, literally slicing away material, one tiny bit at a time, really really fast. It's like saying "Software can do the same thing over and over again through recursion." Yes, it'll do it. But there are more efficient ways.
Another layer down abrasion is essentially taking many small cuts, much like saw teeth, microscopically chips are produced. Though there is more local crushing action and less efficient cutting geometry.
I cant stand the dual-presenter tennis match style. Two presenters can be OK if they have different specialties, but bouncing back and forth every other paragraph adds nothing and greatly detracts from the message.
this is why I love C++ and use Python for most of the work I do...
Wise move.
props for the Cryptonomicon quote. And yes, C++ does resemble the killer band saw.
I really think a more appropriate title for this would have simply been "Is C++ a language for experts?", since your conclusion seems to be "yes".
Exactly! And the question is why? I think the answer is that we try to express increasingly higher-level concepts in an inherently brittle, low-level language.
not just for experts but those who aspire to be experts
@@Evan490BC I don't think that's really the case. Powerful abstractions and low-level features can co-exist (look to Rust for that lesson). C++ has the problem that very early on it made choices that fundamentally impact its ability to do that well. Most notably, it opted to be C compatable. And the tradeoffs C made *very much cut against* a coherent delivery of the abstractions C++ wants to deliver.
So there can be many very pleasant subsets of C++, but C++ in the aggregate can't really be coherent.
I disagree. It’s a language for certain kinds of specialists.
To the extent that you find yourself less knowledgeable in some areas of programming, it’s because either you haven’t had enough the experience yet, or you are not working in that domain. Do game programmers consider themselves experts in embedded programming on low-power devices? Probably not. Does someone writing device drivers consider themselves an expert in game programming? Again, probably not.
C++ is really just a language for people who want to be close to the hardware. If that’s not your goal, then C++ is probably not the best language to use for your particular situation. Perhaps a better language would be OCaml, or TypeScript, or Kotlin. All of those languages have their own strong use cases.
That said, if your goal is to have fun, then ANY programming language will work just fine. No expertise is required for that.
Most linkers will emit errors when ODR is violated, you have to overload the default flags to get a conflict to build. Though there are ways to make the error quiet, for instance by having multiple copies of the same inline function with different compile-time flags, but that is a lot more complex to trigger.
Unless you think there's a single language that's best for all problems, skip to 11:26
31:44 wrt #3, simple, easy to read, this is possible already with macros, templates, operator overloading, etc. Some parts are going to be complex. What I suggest is to isolate the complex parts as their own function, and call them in the simple parts.
Good talk.
Performance I agree with. Not having to worry about 5 years from now recompiling the same code suddenly doesn't perform as expected is extremely crucial more so than anything else on the list.
After all C & C++ are the two primary languages use in writing code for OSes, and most other languages compilers. I don't want to have to rewrite thousands of lines of code in my libraries just a few people thought it was a good idea to change something. So maybe even move it to number 1 stability. Add what the hell you want but don't break what currently works.
Also, oh you're hardware is x-years old, and it's no longer compliant to "our" language so you'll have to buy new machinery... Bullshit! If I spend money on a machine and as long as it continues to physically work, any Standardized or Industrial use Language should still work on it even if it's been 100 years later! They don't see the bigger picture... How many Nuclear Power Plants are in operation that still runs on C or pre C++11 before there was any standard? What happens when newer facilities are built within the next 5-10 years and they no longer use the "older systems" and are all reliant on their proposed "newer" system of the language... Then in 20 years according to their model, that hardware is not compliant so it won't be able to use the newer versions... and then all of a sudden a massive break down... Yeah, not a good proposition at all! The backward-compatible model is there for a reason! How many power plants, water stations, sewage treatment plants, traffic control systems, avionics, etc. rely on those older systems?
@@skilz8098 A Program might no longer compile IF you are using newer language versions. But that got nothing to do with Hardware as C++ is - as most languages - fairly hardware independent.
@@ABaumstumpf Right! No one is suggesting that your code will suddenly break. Rather, the suggestion is that ABI can occasionally change with a new version of the language. E.g. if you want to upgrade to C++23, you might not be able to use hardware from 2000 and you might need to upgrade or recompile libraries on which you depend. But, if you're happy with, say, C++17, you can just continue to use C++17.
@@skilz8098 je problem seems pretty well sorted now since you cant specify the standard level you want to compile for.
Anyway i sincerelly doubt there is that many programmers knowing a particular revision 40 years after it has been out.
Well if you take in account UB nonsense then this point doesn't hold.
You either know by heart EVERYTHING in the standard down to the last edgecase and write all your code such as nothing that the standard deems as UB ever happens or you will risk that some day some compiler idiot will decide to optimise based on that and break your code.
So if you want your code to be truly stable, you better not update your compiler to the last version unless you really know what you are doing and are ready to test your whole codebase thoroughly. Not updating your compiler is something you can do in any language, so this point simply does not apply, not until someone decides to adopt a reasonable posture towards UB.
A stable language is a well defined one, C/C++ is simply not.
The speaker mentions 25 years of research on how to teach CS1. Can I ask for a specific study to read about it?
Type "computer science education" into Google Scholar. Easy.
While I agree that C++ definitively isn't a language to be taught in CS1, the principle of teachability is very closely linked to priority no 3 " Simple, easy to ready easy to understand, easy to write" of the speakers themselves, which ranks higher than "practical safety guarantees and testing mechanisms". I'd argue that, especially the "easy to understand" is more or less the same as being easily teachable.
It is a CS2 language, since you will need it for learning system programming.
@@Carewolf It'll be different for most unis. Besides, there's no need to teach students C++ if the uni already teaches a nice collection like Python, C, MIPS, Haskell, Prolog and Bash. Lastly, you can obviously do most systems programming in C - in fact, most is.
Disagree, I found it excellent for my CS1 and CS2, as a student. By not hiding the mechanics it is much easier to understand what is really happening and why we do a thing the way we do it, while still having mechanisms to avoid the tedium of directly dealing with the underlying bits in normal use. "Easy" languages are completely inappropriate for CS courses and fail to give students a stable foundation.
Unfortunately, there is an error at 16:02. There are some subtle details with constant variables in C++ programming language.
7.11.6, C++2003:
"A name declared in a namespace scope without a storage-class-specifier has external linkage unless it has internal linkage because of a previous declaration and provided it is not declared const. Objects declared const and not explicitly declared extern have internal linkage."
So both variables in bar.cc and foo.cc has internal linkage, and speakers are wrong that this is an ill-defined program.
It is well - defined, but foo.h is incorrect.
Presumably both .cc files #include the .h file, so they would've already declared that variable as extern.
14:10 ok jokes aside, is there an example for that?
40:30 what it really means is you can (or could in the past) look at C code and know in your head what the generated assembler code would be.
Thanks
Welcome
How did I know that ODR would come up first?
But I have to add that, notwithstanding parallel compiles and the inherently redundant work therein, there’s a LOT the linker could do to prevent ODR violations if the object file contained enough metadata. It’s not even particularly hard to do.
39:45 can _you_ confidently say you understand how copies work?
First language has two meanings, it is overloaded. CS 101, or the language someone who has taken no prior computer science courses, and "first language" meaning of perhaps several that one uses semi-regularly, the one knows the best or most about....C++ might be better as an every day language, than someone who usually uses something else and tries to come back to it casually from time to time...of course, recently, that probably means the language Standard in common use may have changed. Lots of newer, better, easier ways to do things...that weren't there the last time you seriously studied it.
I don't get the NDR at 16:08. MSVC 19.16.27034 gives me:
bar.obj : error LNK2005: "int a" (?a@@3HA) already defined in foo.obj
fatal error LNK1169: one or more multiply defined symbols found
But is that from the definition of C++, or was it additional checks implemented on top by Microsoft?
It is NDR, not NDP
Is it necessary to have a cs degree to be good at understanding c++?
no
There's much more to CS than learning a language. Having a degree would mean you took specific class that would help you out, but it's definitely not necessary.
To understand C++ as a language, no. However, if you want to have a good understanding of algorithms and data structures, computational complexity etc., you need at least some knowledge of CS.
It is needed necessary, nor sufficient.
No, but a "good" education in CS makes it a lot easier to understand why C++ behaves in weird ways. It makes it easy to understand the legacy and the hardware and ABI.
Most saws do not cut "through abrasion." Most cut like knives, literally slicing away material, one tiny bit at a time, really really fast. It's like saying "Software can do the same thing over and over again through recursion." Yes, it'll do it. But there are more efficient ways.
most FP languages use recursion for loops by utilizing tail call optimization, so your example is quite poor
@@zaleskis1991 Tail call is nothing more than iteration that superficially looks like recursion.
Another layer down abrasion is essentially taking many small cuts, much like saw teeth, microscopically chips are produced. Though there is more local crushing action and less efficient cutting geometry.
I cant stand the dual-presenter tennis match style. Two presenters can be OK if they have different specialties, but bouncing back and forth every other paragraph adds nothing and greatly detracts from the message.
There is nothing c++ is better than Rust at.
So brave 🙄
you cant do memory allocation in rust