Saks' talks are useful for re-learning all those little details that are so easily forgotten. (I programmed in C++ for over 10 years, but switched mostly to Python about 2 years ago, which has given me time to forget things.)
This all seems very important when using C++ to write complex systems. But there is also a very specific purpose to const when writing firmware that executes from non-volatile memory (flash). NVM or ROM is in the same address space as RAM. When you define an object the initial value is placed in a linker section that exists in flash. Then at program initialization all of the values in that linker section are copied to RAM and the ROM copy is never looked at again. Defining an object as const means that the initial value in ROM is THE value. It is not copied to RAM, but accessed directly in ROM. That saves RAM, which is generally a precious resource in firmware applications. It also saves time at startup, not having to do the copy. If you're writing a computer application it doesn't matter. Everything gets copied to RAM. It's an important distinction in embedded systems where the code is executing in ROM and constant data is referenced in ROM, as well. I should be clear that I use C for firmware development, but there is no distinction between C and C++ on this point, so I think there is some merit to pointing this out when introducing the significance of const.
Marking pointers as const in function _declarations_ doesn't mean much/anything, but in the function _definition_ it's a different story. Making a function pointer parameter const means I can't inadvertently change the pointer to point at some other address, and I will find out at compile time if that happens (exactly like with a regular const pointer variable). This has saved me making runtime errors more than once.
Slide 20 - but... that is not operator precedence - that is not a thing in the standard. it is just the way that "declerators" and "direct-declarators" are specified that specify what syntax matches. And the first syntax to match is the one for declaring an array: "direct-declarator1 [...]" - and then the next match is for the type-identifier making the type of the array-elements pointers.
Oh my god! typedef is a non-type declaration specifier?! Just tried some weird stuff.... volatile typedef int reg; int set_reg(reg * dest, int val) { return *dest = val; } reg * is indeed a pointer to a volatile int...
For value semantics of non-intrinsics I view const-correctness as a waste of time. Only use it in copy constructor and copy assignment operators. The rest becomes silly for daily use.
Great talk. We need more of this kind of stuff. I don't understand slide 20. He states that [ ] has a higher precedence than *, but then says "therefore x is an array of pointers." That seems the OPPOSITE of what it should be. Wouldn't * having higher precedence result in that? Shouldn't it be the case that if [ ] has a higher precedence, that it's a pointer to an array? Higher precedence refers to the associativity of operators. If the operator has higher precedence, it's more "closely bound" to that part of the expression, so therefore if [ ] has higher precedence, shouldn't it be "here's an array... and here is a pointer to that array?" This seems fundamentally backwards. Even the example given using addition and multiplication supports this: a + b * c = a + (b * c) Here, the b and c are more closely associated, then the a+ comes in later, all because multiplication has a higher precedence. So if [ ] has a higher precedence than pointer *, shouldn't it be "a pointer to an array?" I know that's not right however, which is why it seems like pointer * should have a higher precedence than [ ], not the other way around. It seems like he used the associativity of "of" in the grammar of English to justify this, but that's quite subtle. "x is an array OF," such that linguistically, he has "x" closer--so to speak--to "array," than to "pointer to." But that's not at all how I think about it, and I think that's because I think about it more in terms of "who contains who?" When you say [ ] has higher precedence than pointer *, to my mind that sounds like you're saying "x[ ]" first, and "*" second, with the second thing containing the first thing: (pointer to (an array)). See how the arrayness is more nested? Lower precedence operators generally "contain"/"distribute over" higher precedence after all. Super confusing. Then again, maybe that's actually correct to think more linguistically in this case. In which case I think the addition and multiplication example actually confuses more than it illuminates.
Cause there is no precedence for declarations (or for any operator for that matter) specified in the C++-language. It is a horrendous mess that basically only makes sense to people that are already too used to it. the simple "int *a[5]" shows quite nicely that there is no such thing as precedence here: Pointer-declarations must be "pointer to type" - but "[5]" is not a type and thus it is not a pointer-declaration. But for array-declaration it works - "[5]" declares and array with 5 elements of type "int *" with the name "a". and "int (*a)[5]" - the "()" is matched first, with makes "*a" "a pointer to" - then "[5]" an array of 5 elements - "int" of type int. Yeah - confusing as hell. learn.microsoft.com/en-us/cpp/c-language/declarators-and-variable-declarations?view=msvc-170
the examples seemed a little contrived, particularly as basic_string already defines size() as const-qualified and operator[] has two variants, one returning reference to const type and one returning non-qualified reference to type: reference operator[]( size_type pos ); (1) const_reference operator[]( size_type pos ) const; (2) en.cppreference.com/w/cpp/string/basic_string/operator_at size_type size() const; (until C++11) size_type size() const noexcept; (since C++11) size_type length() const; (until C++11) size_type length() const noexcept; (since C++11) en.cppreference.com/w/cpp/string/basic_string/size Dan may have been referring to non-STL implementations of string e.g., but I thought it might have been useful to point that out.
yeah, he was not taking stl approach, it was just a generic discussion. Especially if somebody makes their own string class they might not make size() const.
I don't get complaints about contrived examples. He's showing us something we are familiar with and explaining why it is the way it is. He could waste 15 minutes showing us some real world example and explaining the example and giving us context and motivation for why we would want this, but that distracts from the actual point of the talk. So great job on pointing out stl is doing it right.
God is he beating a dead horse with const value types in arguments. Almost 20 minutes of this talk consist of this one point. The rest is great and I am thankful to finally have a clear and simple summary of all these unintuitive rules. Especially the last part was very enlightening. But please, repeating something that is obviously common sense over and over has no place in a talk like this.
DIsagree. There is subtlety and tons of bugs resulting from a lack of deep understanding on these topics. C++ is hard. You've had too much coffee this morning perhaps? Use the youtube speed feature to double when you need to. Most talks are far too fast, which is far more annoying.
I think on slide 52 should be "wi(ci);" to break promise :-) Anyway great talk. Thank you Dan for clarifying such topics.
definitely
Saks' talks are useful for re-learning all those little details that are so easily forgotten. (I programmed in C++ for over 10 years, but switched mostly to Python about 2 years ago, which has given me time to forget things.)
Great talk, those consts used to give me a headache. but it is much clearer now.
This all seems very important when using C++ to write complex systems. But there is also a very specific purpose to const when writing firmware that executes from non-volatile memory (flash). NVM or ROM is in the same address space as RAM. When you define an object the initial value is placed in a linker section that exists in flash. Then at program initialization all of the values in that linker section are copied to RAM and the ROM copy is never looked at again. Defining an object as const means that the initial value in ROM is THE value. It is not copied to RAM, but accessed directly in ROM. That saves RAM, which is generally a precious resource in firmware applications. It also saves time at startup, not having to do the copy.
If you're writing a computer application it doesn't matter. Everything gets copied to RAM. It's an important distinction in embedded systems where the code is executing in ROM and constant data is referenced in ROM, as well.
I should be clear that I use C for firmware development, but there is no distinction between C and C++ on this point, so I think there is some merit to pointing this out when introducing the significance of const.
Marking pointers as const in function _declarations_ doesn't mean much/anything, but in the function _definition_ it's a different story. Making a function pointer parameter const means I can't inadvertently change the pointer to point at some other address, and I will find out at compile time if that happens (exactly like with a regular const pointer variable). This has saved me making runtime errors more than once.
The last few minutes delivered a lot of interesting examples which I hope could be more elaborated.
Thank you! I learned a lot.
Excellent!
Slide 20 - but... that is not operator precedence - that is not a thing in the standard. it is just the way that "declerators" and "direct-declarators" are specified that specify what syntax matches.
And the first syntax to match is the one for declaring an array: "direct-declarator1 [...]" - and then the next match is for the type-identifier making the type of the array-elements pointers.
I am confused too. If it's a precedence thing, then the "pointer to an array" should win.
Oh my god! typedef is a non-type declaration specifier?!
Just tried some weird stuff....
volatile typedef int reg;
int set_reg(reg * dest, int val) {
return *dest = val;
}
reg * is indeed a pointer to a volatile int...
For value semantics of non-intrinsics I view const-correctness as a waste of time. Only use it in copy constructor and copy assignment operators. The rest becomes silly for daily use.
Always appreciate dan talks 👍
great talk ... but what about const as a return from a function? what are the best practices in that case ?
operator [] overloading shows const as a return from a function
Great slides and talk! I finally really understand why I 'just know' what I know
People like Dan Saks are like guiding light in the dark forest of the C++.
Great talk. We need more of this kind of stuff.
I don't understand slide 20.
He states that [ ] has a higher precedence than *, but then says "therefore x is an array of pointers." That seems the OPPOSITE of what it should be. Wouldn't * having higher precedence result in that? Shouldn't it be the case that if [ ] has a higher precedence, that it's a pointer to an array? Higher precedence refers to the associativity of operators. If the operator has higher precedence, it's more "closely bound" to that part of the expression, so therefore if [ ] has higher precedence, shouldn't it be "here's an array... and here is a pointer to that array?"
This seems fundamentally backwards.
Even the example given using addition and multiplication supports this: a + b * c = a + (b * c)
Here, the b and c are more closely associated, then the a+ comes in later, all because multiplication has a higher precedence. So if [ ] has a higher precedence than pointer *, shouldn't it be "a pointer to an array?" I know that's not right however, which is why it seems like pointer * should have a higher precedence than [ ], not the other way around.
It seems like he used the associativity of "of" in the grammar of English to justify this, but that's quite subtle. "x is an array OF," such that linguistically, he has "x" closer--so to speak--to "array," than to "pointer to." But that's not at all how I think about it, and I think that's because I think about it more in terms of "who contains who?" When you say [ ] has higher precedence than pointer *, to my mind that sounds like you're saying "x[ ]" first, and "*" second, with the second thing containing the first thing: (pointer to (an array)). See how the arrayness is more nested? Lower precedence operators generally "contain"/"distribute over" higher precedence after all.
Super confusing.
Then again, maybe that's actually correct to think more linguistically in this case. In which case I think the addition and multiplication example actually confuses more than it illuminates.
Cause there is no precedence for declarations (or for any operator for that matter) specified in the C++-language.
It is a horrendous mess that basically only makes sense to people that are already too used to it.
the simple "int *a[5]" shows quite nicely that there is no such thing as precedence here:
Pointer-declarations must be "pointer to type" - but "[5]" is not a type and thus it is not a pointer-declaration. But for array-declaration it works - "[5]" declares and array with 5 elements of type "int *" with the name "a".
and "int (*a)[5]" - the "()" is matched first, with makes "*a" "a pointer to" - then "[5]" an array of 5 elements - "int" of type int.
Yeah - confusing as hell.
learn.microsoft.com/en-us/cpp/c-language/declarators-and-variable-declarations?view=msvc-170
Great talk
I can not find the slides of this video, anyone else?
the examples seemed a little contrived, particularly as basic_string already defines size() as const-qualified and operator[] has two variants, one returning reference to const type and one returning non-qualified reference to type:
reference operator[]( size_type pos ); (1)
const_reference operator[]( size_type pos ) const; (2)
en.cppreference.com/w/cpp/string/basic_string/operator_at
size_type size() const; (until C++11)
size_type size() const noexcept; (since C++11)
size_type length() const; (until C++11)
size_type length() const noexcept; (since C++11)
en.cppreference.com/w/cpp/string/basic_string/size
Dan may have been referring to non-STL implementations of string e.g., but I thought it might have been useful to point that out.
yeah, he was not taking stl approach, it was just a generic discussion. Especially if somebody makes their own string class they might not make size() const.
I don't get complaints about contrived examples. He's showing us something we are familiar with and explaining why it is the way it is. He could waste 15 minutes showing us some real world example and explaining the example and giving us context and motivation for why we would want this, but that distracts from the actual point of the talk. So great job on pointing out stl is doing it right.
God is he beating a dead horse with const value types in arguments. Almost 20 minutes of this talk consist of this one point. The rest is great and I am thankful to finally have a clear and simple summary of all these unintuitive rules. Especially the last part was very enlightening. But please, repeating something that is obviously common sense over and over has no place in a talk like this.
its a back to basics talk, the whole point is to go slow with these.
DIsagree. There is subtlety and tons of bugs resulting from a lack of deep understanding on these topics. C++ is hard. You've had too much coffee this morning perhaps? Use the youtube speed feature to double when you need to.
Most talks are far too fast, which is far more annoying.