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* .
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.
If it was a one-line for body then I'd see that as good. Having spurious braces when they're not needed can be annoying and make the code harder to read.
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.
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 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.
That's why we need more inference. The switch should automatically infer the namespace of an enum based on the clause and the enum should create a unique namespace both, without me having to add extra keywords.
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.
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)
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;`
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.
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 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;
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 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.
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
I agree with C++ on how division and modulo operations relating to negative numbers should work and so does C. If you want intervals you should be using unsigned types and in general you should be using unsigned integers for most things where you need integer math. When you need negative values, especially if you're doing math, it makes so much more sense to use floating point types. A lot of the complaints I see here are things intentionally, and in my view mistakenly, inherited from C. As far as operator overloading is concerned, I don't think they go far enough, and I also think overloading of operators || and && should still have short circuiting. And for sizeof, I have always hated that syntax, whether it be in C or C++ and I've always hated how it was ordered in the precedence table and I've always hated that parentheses weren't required in every instance and considered part of the "operator". The array syntax though, I've found that more than a little handy when doing weird manipulations. If you've not used it in that way then you don't know what you're missing.
An addendum, since I remembered after hitting the button, but Duff's device only made sense for the specific usage it had back then whereby the `to` pointer was to a memory mapped register and never had to be incremented at the same time as the `from` pointer. However, if you're going to copy large blocks one byte at a time between two buffers then the optimal method, if you wish to stay standard compliant, is to use an index variable and only increment it. Incrementing two pointers per loop slows it down too much, and if you're using a counter variable to count down in that way at the same time it'll be slower anyway, especially for older hardware. Of course, it'll always be better to break out the assembly and copy whole register sized amounts at a time, if you know the hardware you're on.
How would a custom short-circuit || and && even work? It definitely can't be a simple two-argument operator function. It could take 1 argument and return either a pointer to a function which takes the second argument and returns the overall result or returns a null pointer indicating that the second argument will not be evaluated. Another approach which makes the operator necessarily a template is lifting the second argument to a lambda which the operator function template is free to call or not. I actually like the first approach.
@@anon_y_mousse Or just use memcpy. Interesting to see how _that_ is implemented. I've seen the assembly language generated when in the debugger, and it does alignment of the destination and then uses large registers. The x86/x64 platform tolerates read mis-alignment and it just takes an extra cycle (maybe). I think it does unrolling too. But even as a loop, it executes ahead and unwindes the loop in speculative execution since it can easily race ahead when it waits on memory access.
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.
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.
it seems sizeof(+a)["12345"] == '1' but (sizeof(+a))["12345"] == '4'. Built on MSVC
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* .
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
Awesome pres! :)
36:26 there is a technical reason , you didn't say if it was implemented as column major or row major matrices
And we all mocked Javascript´s banana...
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. :)
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
Possibly the best C++ talk I've ever seen.
The most definitely the best...🙂
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.
If it was a one-line for body then I'd see that as good. Having spurious braces when they're not needed can be annoying and make the code harder to read.
@@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.
finally a decent “WAT” talk for C++ ;)
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
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!
I still cannot believe C++ programmers make fun of javascript with a straight face
also, great talk xD
"long thread_local unsigned extern long d;" made my eyelid twitch when I read it... which is, I suppose, the point.
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 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
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.
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
That's why we need more inference. The switch should automatically infer the namespace of an enum based on the clause and the enum should create a unique namespace both, without me having to add extra keywords.
This is now my favorite "grammatically correct but what the hell are you doing with the language" talk :D
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
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?
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 🤦
Before watching, here is my guess: it will print compiler error
The rounding to nearest even number is to avoid errors growing too much
This was extremely enlightening.
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.
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
Great talk, very entertaining!
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;`
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.
Wherever people complain about how complicated c++ is i just show them this video
This is why C++ is the worst language ever. An abomination.
Assuming an int has 32 bits on your machine, this should print 6.
This is disgusting. What the hell are the standard devs doing?
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".
This fancy but a bit complicated :(
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 wanna write some cursed cpp now
I'm so looking forward to std simd.
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.
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.
The language has become cursed. So many gotchas.
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.
C++ doesn't have features, it only has issues.
I learned things I wish I didn't have to.
4:22 looks like a math expression, I liked it
Aaaaaaah, white background!
Excellent talk! I definitely learned a thing or two.
and you thought js was bad....
C++ : never start, there is no cure !
Thanks, comrade.
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.
That floating point stuff (@18:38) must be so un-threadsafe...
The floating point environment is thread-local.
Wow some of these tricks seem quite useful
This is so cool. I liked the switch stuff.
Great talk! I learned way more new and curious stuff than I expected to.
Very pleased to hear that you enjoyed this presentation!
This is underrated
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
Nice!
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
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.
I agree with C++ on how division and modulo operations relating to negative numbers should work and so does C. If you want intervals you should be using unsigned types and in general you should be using unsigned integers for most things where you need integer math. When you need negative values, especially if you're doing math, it makes so much more sense to use floating point types. A lot of the complaints I see here are things intentionally, and in my view mistakenly, inherited from C. As far as operator overloading is concerned, I don't think they go far enough, and I also think overloading of operators || and && should still have short circuiting.
And for sizeof, I have always hated that syntax, whether it be in C or C++ and I've always hated how it was ordered in the precedence table and I've always hated that parentheses weren't required in every instance and considered part of the "operator". The array syntax though, I've found that more than a little handy when doing weird manipulations. If you've not used it in that way then you don't know what you're missing.
An addendum, since I remembered after hitting the button, but Duff's device only made sense for the specific usage it had back then whereby the `to` pointer was to a memory mapped register and never had to be incremented at the same time as the `from` pointer. However, if you're going to copy large blocks one byte at a time between two buffers then the optimal method, if you wish to stay standard compliant, is to use an index variable and only increment it. Incrementing two pointers per loop slows it down too much, and if you're using a counter variable to count down in that way at the same time it'll be slower anyway, especially for older hardware. Of course, it'll always be better to break out the assembly and copy whole register sized amounts at a time, if you know the hardware you're on.
How would a custom short-circuit || and && even work? It definitely can't be a simple two-argument operator function.
It could take 1 argument and return either a pointer to a function which takes the second argument and returns the overall result or returns a null pointer indicating that the second argument will not be evaluated.
Another approach which makes the operator necessarily a template is lifting the second argument to a lambda which the operator function template is free to call or not.
I actually like the first approach.
@@anon_y_mousse Or just use memcpy. Interesting to see how _that_ is implemented. I've seen the assembly language generated when in the debugger, and it does alignment of the destination and then uses large registers. The x86/x64 platform tolerates read mis-alignment and it just takes an extra cycle (maybe).
I think it does unrolling too. But even as a loop, it executes ahead and unwindes the loop in speculative execution since it can easily race ahead when it waits on memory access.
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.