That's *because* we've been handed down the wisdom to ignore it, and this gets repeated instead of going over it, whenever std library features are being explained.
Lol I got called out in a code review last week for an 'else for'. Rounding to even is also called Bankers' Rounding, and is a tiny bit more stable because half of the .5s are rounded down and half are rounded up.
Thank you for providing a use case for Banker's rounding, I instinctively thought when he defined it "why would you do that?" but it makes a lot of sense with that observation.
i'd like a proof for this "because half of the .5s are rounded down and half are rounded up." ... ex periment, enter a shop, ANY shop, look at the sales price of things.. and count how many up and down you would do for the whole shop I'm willing to bet it's not 50/50..
@moestietabarnak That's not the usecase. It's more about making sure your statistical calculations don't drift. ETA: For storing prices, you're better off storing an int number of cents.
Re 4:20 and 7:40. The (overloaded) comma operator can be useful to deal with function returns in template code where the return type might be void. Because void is an incomplete type, you can't assign it to a local variable. However, void is allowed as an operand for the comma operator. You can't overload the comma where one of the operands is void, but we can use that to our advantage. This allows you to do something like: template struct wrapped { T value; }; template struct wrapped { }; template T unwrap(wrapped t) { return t.value; } void unwrap(wrapped) { } // the trick: template wrapped operator,(T t, wrapped) { return { t }; } template auto foo(T t) { // call some unknown overloaded function that *might* return void // auto r = bar(t); // This won't work if bar(t) returns void auto r = (bar(t), wrapped()); // But this will // do something else, otherwise we could've just done 'return bar(t)' return unwrap(r); // return the original value, or void } When bar(t) is not void, the template operator,() is invoked, returning the result of bar(t) wrapped in a wrapped as per its implementation. If bar(t) is void, you get the built-in operator,(), which returns the second operand, a wrapped in this case. We can then copy this around safely, do some other stuff, and then finally unwrap the original value. Unwrapping a wrapped just returns void, and you are in fact allowed to return the result of an expression of type void in a function that returns void. This code was just to get the idea across btw, it can use some perfect forwarding love. Of course there are other ways to solve this problem (e.g., constexpr if or specializations), but they usually involve code duplication.
I feel a way simpler version would be using std::any (Yay, actually a scenario where that one is useful) You declare your var that Stores the return value to be a std::any and with type traits you detect if your function returns something or not. If yes, save it in the any and use any_cast to get its actual value, if not, just call your callable without saving it anywhere
Another use case of dynamic_cast is when you overload delete operator. Because you need to pass the exact same address to the free that was returned from malloc in your overloaded new operator.
re valarray: Back in the day, like right after C++98 was published, the word was that valarray was a goofup and we should just ignore it. There was no streaming videos, but there were talks given with people listening, just like they do today to go over all the new features when an updated standard is published. The insight from those talks were published in the major programming magazines as this was just before the ubiquity of Internet access and the demise of magazines, and also a few blog posts. I also don't remember _why_ . Perhaps it was fixed at some point, e.g. C++11? I have some vague memory that this might be the case. Browsing a bit, I'm reminded that it proved inferior to 3rd part libraries that used *expression templates* .
static actually has two meanings in C. The second one is for declaring the minimum size of arrays in function parameters, but every known compiler so far simply ignores this. (C11 6.7.6.3/7, was 6.7.5.3/7 in C99)
Just this week I ended up on the valarray cppreference page from something else and found the trace for matrix explained, sort of what I've wanted to do, use vector algebra in code. What a coincidence.
You need the thing that closes each function down all neatly by clicking on the greater than symbol like in dark basic & Java. Pull out the MASM64 debugger with the void object.
I love the talk. However, I think there's a mistake at 13:55. The first line of Duff's device should be: auto n = (count + 7) / 8; not: auto n = (count + 7) % 8;
I am not surprised that Rust is getting momentum. C++ could have been a good language but its "golden goose" (C compatibility) shows its strings, more and more. And its template design, while being cool in the theory, shows the massive explosion of complexity which is hard to manage by compiler builders and users as well. Same for operator overloading -> looks cool but creates a potential hell of complexity and dangers in the usage. While, at the same time, the fluent API style which feels more natural is often too hard to implement due to random quirks (const rules, move rules weirdness, etc., which are ALSO partly a consequence of the language legacies).
As a developer, I'd rather have these features and advise against their misuse then to simply be told I'm not allowed to have them at all, I've used numerous languages, and I will always unequivocally say the worst experiences are from the expectation by the language designers that I should not be allowed to do something at all. For example there are absolutely functionality provided by templates and such operator overloading that literally cannot be provided in any other language out of lack of support for said features, and every alternative is absolutely worse and 90% of the time violated DRY. (and if we had either perfect compile time introspective reflection, especially the capacity to get type and function names, or language integrated macros, I wouldn't have to rely upon the C preprocessor to follow DRY at all in C++23) Unopinionated languages are honestly just superior as far as I'm concerned. As an aside it took longer for them to implement modules in an experimental state then it did a bug free template system, honestly I don't think the maintaining of templating has been nearly as much a problem as modules have been.
It is for macro hygiene, otherwise code surrounding `tc_scope_exit` could interfere. For example if `tc_scope_exit` contained an operator with precedence lower than `+`, and a user overloaded + to do something else, then tc_scope_exit would apply after their `+`. `tc_scope_exit { CloseHandle(hfile); } + dummy;`
Great talk, thanks! Wanted to point out that at time t=797, Duff's Device code, on slide 27, has a small typo, first line should be `auto n = (count + 7) / 8;`
I've once had a use case where it was actually required for short circuit to not happen because expression could execute in two modes - calculative mode (where it was necessary). and dependent argument recording mode (which had to execute in full once). so overloading && and || can have its use
Is it 56? Like some rarely used offset expression? (Edit: 😊 or 456 tricked by +😄 Edit2: ahhhhhh I started watching the video, I didn’t know that). I’m usually using i16_t = short; It feels irresponsible to express a type without specifying the size even if defined elsewhere. I can imagine a short to be 12, 18, or 24 bit on any LLP64 LP64 system, especially if a design found a better sweet spot for their industry. Edit2 continued: I use the sequence operator to express something that must happen in sequence. I like “return something, result;” I use semicolons for expressions which a compiler can reorder, or even parallelise if it sees a way.
The thing I loved about C and C++ is they were small. The various committees added stupid features which made the language large. Of course no one needs to use these features, but try maintaining someone else’s code that has some of these useless features.
Yeah, codebases from entirely different teams looked pretty much the same 20 years ago, the only differences were stylistic ones like whether braces go on the same line or a new line. Nowadays, different codebases in C++ look like different languages, especially with the chaotic mishmash of features added in C++17 and onwards.
C++ has become way too verbose. Too many things you have to remember. I switched from Pascal to C because Pascal was too verbose. It can be very hard to look at a small segment of code and have no idea what it is doing.
I think you used exactly the wrong word there. "Verbose" means using a lot of words to say something. The point of C++ having many "words" available, is that you use very few to "say" what you want. Using few words is "terse", not "verbose".
I use + for char for streams.
char c = 65;
std::cout
Good point, also unary plus help to shorten that ugly static_cast out. Not the way it designed, but hey, i know what i am doing with my code)
This is beautiful and cursed.
Possibly the best C++ talk I've ever seen.
The most definitely the best...🙂
4:35 C++ making it’s debut in 1998. 22 years later, technology has advanced so much, we found out that inequality means not being equal.
still undefined behavior on integer operations, even thou all processors that still run uses IEEE754
The man is a farmer.
Outstanding in his field. 👍
I thought he was a miller...
These sorts of talks are always my favourite. Cursed code, great humour, but still teach deep (maybe even useful) things about the language
finally a decent “WAT” talk for C++ ;)
The reason nobody uses valarray is nobody knows of its existence
I know about it but I want a linear algebra vector 😅
I used valarray a lot when I took the C++ course at my university.
That's *because* we've been handed down the wisdom to ignore it, and this gets repeated instead of going over it, whenever std library features are being explained.
@@henrikholst7490 You use boost then. :)
Lol I got called out in a code review last week for an 'else for'.
Rounding to even is also called Bankers' Rounding, and is a tiny bit more stable because half of the .5s are rounded down and half are rounded up.
@@anon_y_mousse Yes, another speaker pushed back with, "why _isn't_ it one line?"
Thank you for providing a use case for Banker's rounding, I instinctively thought when he defined it "why would you do that?" but it makes a lot of sense with that observation.
i'd like a proof for this "because half of the .5s are rounded down and half are rounded up." ... ex periment, enter a shop, ANY shop, look at the sales price of things.. and count how many up and down you would do for the whole shop
I'm willing to bet it's not 50/50..
@moestietabarnak That's not the usecase. It's more about making sure your statistical calculations don't drift.
ETA: For storing prices, you're better off storing an int number of cents.
Great talk, I learned some interesting tidbits. I'm surprised I didn't know about the dynamic_cast feature, that's pretty nifty.
Pleased to hear that you found the presentation helpful!
Re 4:20 and 7:40. The (overloaded) comma operator can be useful to deal with function returns in template code where the return type might be void. Because void is an incomplete type, you can't assign it to a local variable. However, void is allowed as an operand for the comma operator. You can't overload the comma where one of the operands is void, but we can use that to our advantage. This allows you to do something like:
template struct wrapped { T value; };
template struct wrapped { };
template T unwrap(wrapped t) { return t.value; }
void unwrap(wrapped) { }
// the trick:
template wrapped operator,(T t, wrapped) { return { t }; }
template auto foo(T t)
{
// call some unknown overloaded function that *might* return void
// auto r = bar(t); // This won't work if bar(t) returns void
auto r = (bar(t), wrapped()); // But this will
// do something else, otherwise we could've just done 'return bar(t)'
return unwrap(r); // return the original value, or void
}
When bar(t) is not void, the template operator,() is invoked, returning the result of bar(t) wrapped in a wrapped as per its implementation. If bar(t) is void, you get the built-in operator,(), which returns the second operand, a wrapped in this case. We can then copy this around safely, do some other stuff, and then finally unwrap the original value. Unwrapping a wrapped just returns void, and you are in fact allowed to return the result of an expression of type void in a function that returns void.
This code was just to get the idea across btw, it can use some perfect forwarding love. Of course there are other ways to solve this problem (e.g., constexpr if or specializations), but they usually involve code duplication.
This is amazing.
@@BolpatOr rather cursed
damn both cursed AND amazing
I feel a way simpler version would be using std::any (Yay, actually a scenario where that one is useful)
You declare your var that Stores the return value to be a std::any and with type traits you detect if your function returns something or not. If yes, save it in the any and use any_cast to get its actual value, if not, just call your callable without saving it anywhere
Another use case of dynamic_cast is when you overload delete operator. Because you need to pass the exact same address to the free that was returned from malloc in your overloaded new operator.
At 4:00, the comma operator is very useful when defining macros, since it allows you to run multiple statements in the place of one.
This was extremely enlightening.
it seems sizeof(+a)["12345"] == '1' but (sizeof(+a))["12345"] == '4'. Built on MSVC
This is now my favorite "grammatically correct but what the hell are you doing with the language" talk :D
Great talk, very entertaining!
re valarray: Back in the day, like right after C++98 was published, the word was that valarray was a goofup and we should just ignore it. There was no streaming videos, but there were talks given with people listening, just like they do today to go over all the new features when an updated standard is published. The insight from those talks were published in the major programming magazines as this was just before the ubiquity of Internet access and the demise of magazines, and also a few blog posts.
I also don't remember _why_ . Perhaps it was fixed at some point, e.g. C++11? I have some vague memory that this might be the case.
Browsing a bit, I'm reminded that it proved inferior to 3rd part libraries that used *expression templates* .
static actually has two meanings in C. The second one is for declaring the minimum size of arrays in function parameters, but every known compiler so far simply ignores this. (C11 6.7.6.3/7, was 6.7.5.3/7 in C99)
in gcc at least it detects null with static 1
The rounding to nearest even number is to avoid errors growing too much
About those negative % operations: Ada has both *rem* and *mod* operators, so one can choose.
But not compatible with C heritage.
i think rust has the same
I love that this guy taught me so much about c++ and that I could probably teach him kinda of the same thing on template and compile time c++ xD
Just this week I ended up on the valarray cppreference page from something else and found the trace for matrix explained, sort of what I've wanted to do, use vector algebra in code. What a coincidence.
Wherever people complain about how complicated c++ is i just show them this video
I still cannot believe C++ programmers make fun of javascript with a straight face
also, great talk xD
You need the thing that closes each function down all neatly by clicking on the greater than symbol like in dark basic & Java. Pull out the MASM64 debugger with the void object.
Great talk! I learned way more new and curious stuff than I expected to.
Very pleased to hear that you enjoyed this presentation!
Excellent talk! I definitely learned a thing or two.
Awesome pres! :)
Thanks, comrade.
I love the talk. However, I think there's a mistake at 13:55. The first line of Duff's device should be:
auto n = (count + 7) / 8;
not:
auto n = (count + 7) % 8;
"long thread_local unsigned extern long d;" made my eyelid twitch when I read it... which is, I suppose, the point.
4:22 looks like a math expression, I liked it
I am not surprised that Rust is getting momentum. C++ could have been a good language but its "golden goose" (C compatibility) shows its strings, more and more. And its template design, while being cool in the theory, shows the massive explosion of complexity which is hard to manage by compiler builders and users as well. Same for operator overloading -> looks cool but creates a potential hell of complexity and dangers in the usage. While, at the same time, the fluent API style which feels more natural is often too hard to implement due to random quirks (const rules, move rules weirdness, etc., which are ALSO partly a consequence of the language legacies).
skill issue
As a developer, I'd rather have these features and advise against their misuse then to simply be told I'm not allowed to have them at all, I've used numerous languages, and I will always unequivocally say the worst experiences are from the expectation by the language designers that I should not be allowed to do something at all. For example there are absolutely functionality provided by templates and such operator overloading that literally cannot be provided in any other language out of lack of support for said features, and every alternative is absolutely worse and 90% of the time violated DRY. (and if we had either perfect compile time introspective reflection, especially the capacity to get type and function names, or language integrated macros, I wouldn't have to rely upon the C preprocessor to follow DRY at all in C++23) Unopinionated languages are honestly just superior as far as I'm concerned.
As an aside it took longer for them to implement modules in an experimental state then it did a bug free template system, honestly I don't think the maintaining of templating has been nearly as much a problem as modules have been.
On slide 15 it says that the overloadable binary operator must have high precedence... why?
It is for macro hygiene, otherwise code surrounding `tc_scope_exit` could interfere.
For example if `tc_scope_exit` contained an operator with precedence lower than `+`, and a user overloaded + to do something else, then tc_scope_exit would apply after their `+`.
`tc_scope_exit { CloseHandle(hfile); } + dummy;`
Great talk, thanks!
Wanted to point out that at time t=797, Duff's Device code, on slide 27, has a small typo, first line should be `auto n = (count + 7) / 8;`
And of course, all occurrences of `*to` should be `*to++`.
Unless there's a weird overload of the `*` operator, I guess...
Or maybe not. In a thread below, @anon_y_mousse mentions a special case where Duff's device is useful without incrementing the `to` pointer.
Wow some of these tricks seem quite useful
36:26 there is a technical reason , you didn't say if it was implemented as column major or row major matrices
Nice!
This is so cool. I liked the switch stuff.
24:46 ```
using fp = int (*)(int);
operator fp() { /* ... */ }
```
😄
edit: Oh, it's explained 10 seconds later that it's the only way to do it 🤦
Here's another funny corner of the language:
#include
int main() {
volatile char const * s = "Hello, world!";
std::cout
#include
void foo(const char*) {
std::cout
Nothing beats a good old printf
apparently in c++23 they've added a const volatile void* overload for the operator
Before watching, here is my guess: it will print compiler error
This is underrated
I've once had a use case where it was actually required for short circuit to not happen because expression could execute in two modes - calculative mode (where it was necessary). and dependent argument recording mode (which had to execute in full once). so overloading && and || can have its use
If you do *(arr + value) please stop. Older compilers output different assembly or regalloc when you do that.
@MegaMech Why wouldn't a compiler handle that just the same? What old compiler?
I learned things I wish I didn't have to.
I wanna write some cursed cpp now
C++ : never start, there is no cure !
It’snt Sea, it s oCean 🌊; as mathematician I see it’s very closer to mathematics language; i hope and i m working on it.
That floating point stuff (@18:38) must be so un-threadsafe...
The floating point environment is thread-local.
Assuming an int has 32 bits on your machine, this should print 6.
Most of these features are cancer except for the trick of putting "using enum" inside the switch statement.
still cancer because if the enum's member gets renamed or deleted it can lead to a runtime error instead of a compile time
Is it 56? Like some rarely used offset expression? (Edit: 😊 or 456 tricked by +😄 Edit2: ahhhhhh I started watching the video, I didn’t know that).
I’m usually using i16_t = short; It feels irresponsible to express a type without specifying the size even if defined elsewhere. I can imagine a short to be 12, 18, or 24 bit on any LLP64 LP64 system, especially if a design found a better sweet spot for their industry.
Edit2 continued:
I use the sequence operator to express something that must happen in sequence. I like “return something, result;”
I use semicolons for expressions which a compiler can reorder, or even parallelise if it sees a way.
I'm so looking forward to std simd.
This fancy but a bit complicated :(
And we all mocked Javascript´s banana...
Aaaaaaah, white background!
The thing I loved about C and C++ is they were small. The various committees added stupid features which made the language large.
Of course no one needs to use these features, but try maintaining someone else’s code that has some of these useless features.
Yeah, codebases from entirely different teams looked pretty much the same 20 years ago, the only differences were stylistic ones like whether braces go on the same line or a new line. Nowadays, different codebases in C++ look like different languages, especially with the chaotic mishmash of features added in C++17 and onwards.
C++ doesn't have features, it only has issues.
If I was your boss and you come up with code like this, you rewrite it, so everyone understands it on first sight or you get fired.
C++ has become way too verbose. Too many things you have to remember. I switched from Pascal to C because Pascal was too verbose. It can be very hard to look at a small segment of code and have no idea what it is doing.
I think you used exactly the wrong word there. "Verbose" means using a lot of words to say something. The point of C++ having many "words" available, is that you use very few to "say" what you want. Using few words is "terse", not "verbose".
and you thought js was bad....
The language has become cursed. So many gotchas.
This is disgusting. What the hell are the standard devs doing?
This is why C++ is the worst language ever. An abomination.