C++ Features You Might Not Know - Jonathan Müller - C++ on Sea 2023
Vložit
- čas přidán 14. 05. 2024
- cpponsea.uk/
---
C++ Features You Might Not Know - Jonathan Müller - C++ on Sea 2023
C++ is a big language - the upcoming C++23 standard will be over 2000 pages long. This talk will cover some obscure features you might not know. We will cover strange syntax like commutative array indexing and complicated declarators, surprising cases of undefined behavior in frequently used operators contrasted with a surprising lack of undefined behavior in operations that really shouldn't work, overlooked language facilities - some of them actually useful, and half-forgotten standard library functions - some of them for good reason.
For each feature, we will talk about the what, the why, and how you can use it to write better (or much, much worse) C++ programs.
---
Slides: github.com/philsquared/cppons...
Sponsored by think-cell: www.think-cell.com/en/
---
Jonathan Müller
Jonathan is a library developer at think-cell. In his spare time, he works on various C++ open source libraries for memory allocation, cache-friendly containers, or parsing. He also blogs at foonathan.net and is a member of the C++ standardization committee.
---
C++ on Sea is an annual C++ and coding conference, in Folkestone, in the UK.
- Annual C++ on Sea, C++ conference: cpponsea.uk/
- 2023 Program: cpponsea.uk/2023/schedule/
- Twitter: / cpponsea
---
CZcams Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#cpp #cpponsea #cppprogramming - Věda a technologie
Possibly the best C++ talk I've ever seen.
The most definitely the best...🙂
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
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.
The man is a farmer.
Outstanding in his field. 👍
finally a decent “WAT” talk for C++ ;)
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..
These sorts of talks are always my favourite. Cursed code, great humour, but still teach deep (maybe even useful) things about the language
it seems sizeof(+a)["12345"] == '1' but (sizeof(+a))["12345"] == '4'. Built on MSVC
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!
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.
Great talk, very entertaining!
This is now my favorite "grammatically correct but what the hell are you doing with the language" talk :D
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
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
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* .
Excellent talk! I definitely learned a thing or two.
The rounding to nearest even number is to avoid errors growing too much
Awesome pres! :)
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
Nice!
Great talk! I learned way more new and curious stuff than I expected to.
Very pleased to hear that you enjoyed this presentation!
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.
Thanks, comrade.
This is so cool. I liked the switch stuff.
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, 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.
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
Wow some of these tricks seem quite useful
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;`
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 still cannot believe C++ programmers make fun of javascript with a straight face
also, great talk xD
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 🤦
4:22 looks like a math expression, I liked it
"long thread_local unsigned extern long d;" made my eyelid twitch when I read it... which is, I suppose, the point.
36:26 there is a technical reason , you didn't say if it was implemented as column major or row major matrices
Before watching, here is my guess: it will print compiler error
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
This is underrated
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.
C++ : never start, there is no cure !
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.
That floating point stuff (@18:38) must be so un-threadsafe...
The floating point environment is thread-local.
I learned things I wish I didn't have to.
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 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?
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.
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 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.
I'm so looking forward to std simd.
This fancy but a bit complicated :(
Aaaaaaah, white background!
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".
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.
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?