I sincerely hope this man is a professor somewhere. He's an amazing lecturer and definitely someone you want to learn a lot from. I like how he keeps people engaged, manages the room, and even made me laugh out loud all while covering some pretty technical material that's mostly new to me.
Excellent presentation, very educational while being somehow entertaining. As a C fanboy this is one of the few c++ features I genuinely want, though I'm sure I can kind of get it with stateful functions.
He wants to highlight the fact that the function definitions are meant to be Inline and that he didn't inline them (by defining the function in the class definition) just so it's easier to see on the slide.
The functions are inlined by default, so there's no need for the inline keyword - the compiler will error if you try to insert an extraneous 'inline', since it's not possible to have a non-inline allocator.
I was also initially deeply confused by this, and none of the comments above were particularly satisfying / filled me with confidence. What the c++ reference pages are clear on is that explicitly adding "inline" here is *unnecessary*, because definitions for these member functions are included directly in the class definition (and are therefore already implicitly inline). That said, unnecessary does not mean forbidden. I couldn't find from the reference pages whether "inline" is definitely allowed to be specified explicitly or not. Having actually gone to the effort of testing on MSVC and clang, can verify it does not appear to be a "syntax error" to mark those functions inline explicitly (on those compilers). It is possible that it isn't technically guaranteed to be allowed in the spec, that the presenter previously worked with some compiler that complained. I don't know, I don't care. If you look at the class definition for Allocator, you'll see that the destructor declaration is wrong (should be ~Allocator not ~allocator), which indicates to me that this code was possibly never compiled before the presentation.
Geometric growth with no reserve(). 2^n (GCC and Clang default libraries) or 1.5^n (MS visual studio default library) approximate number of allocations it with log₂N (or log₁.₅N) where N = 1,000,000,000. (30 and 52 allocations respectively.)
Yeah it's always reassuring when someone deemed fit to give a presentation on custom allocators, is completely ignorant of a basic compiler feature dealing with memory alignment. Way to go.
I understand not knowing about a non standard pragma and personally I don't like the pragma anyway. However, the speaker is clearly misinformed about unaligned data hurting performance, or is programming in non-x86 environment. Google "lemire unaligned x86" for nice blog post with benchmarks. (Might not apply to floating point)
This is probably one of the best talks ever given at CppCon.
@39:36 lol
The clarity blew me away.
I sincerely hope this man is a professor somewhere. He's an amazing lecturer and definitely someone you want to learn a lot from. I like how he keeps people engaged, manages the room, and even made me laugh out loud all while covering some pretty technical material that's mostly new to me.
Lakos's talks are always a stream of consciousness :P
Excellent presentation, very educational while being somehow entertaining. As a C fanboy this is one of the few c++ features I genuinely want, though I'm sure I can kind of get it with stateful functions.
Oh man. That guy is really good. Thank you.
Talking "this is very important" should be at the end of part 2 not because "you said so/I am here" but because people already saw this is important.
Pure joy! ❤
Thank you, great talk
Glad you enjoyed it!
34:25 Can someone explain me what the problem / purpose of the inline specifier is ? Or what he is trying to show ?
He wants to highlight the fact that the function definitions are meant to be
Inline and that he didn't inline them (by defining the function in the class definition) just so it's easier to see on the slide.
The functions are inlined by default, so there's no need for the inline keyword - the compiler will error if you try to insert an extraneous 'inline', since it's not possible to have a non-inline allocator.
@@tomcheng3903 Nope. He's lying. You can have extra 'inline' specifier on an inline class function. There will be no error.
I was also initially deeply confused by this, and none of the comments above were particularly satisfying / filled me with confidence.
What the c++ reference pages are clear on is that explicitly adding "inline" here is *unnecessary*, because definitions for these member functions are included directly in the class definition (and are therefore already implicitly inline).
That said, unnecessary does not mean forbidden. I couldn't find from the reference pages whether "inline" is definitely allowed to be specified explicitly or not. Having actually gone to the effort of testing on MSVC and clang, can verify it does not appear to be a "syntax error" to mark those functions inline explicitly (on those compilers).
It is possible that it isn't technically guaranteed to be allowed in the spec, that the presenter previously worked with some compiler that complained. I don't know, I don't care.
If you look at the class definition for Allocator, you'll see that the destructor declaration is wrong (should be ~Allocator not ~allocator), which indicates to me that this code was possibly never compiled before the presentation.
Excellent talk.
GREAT TALK
This guy is cool
What a fucking GEM
great talk
Death by powerpoint, John. Every. Single. Time. You have great talent, but massive information overload.
I love it.
@@prateekpatil4845 me too ^^
just a long presentation imo, not overloaded
49:58 How to determine allocation density is low for billion integers when reserved memory or capacity() is not given.
On my machine vector allocates (1.5 * sizeOfCurrentMemory) each time it runs out of space. should be similar on yours so, I guess u could use that?
Geometric growth with no reserve().
2^n (GCC and Clang default libraries) or 1.5^n (MS visual studio default library) approximate number of allocations it with log₂N (or log₁.₅N) where N = 1,000,000,000. (30 and 52 allocations respectively.)
"we meaning me" :-)
23:37
@56:00 How has he not heard #pragma pack(push, 1).
You put it around a specific struct, and disable it after w/ #pragma pack(pop)
Yeah it's always reassuring when someone deemed fit to give a presentation on custom allocators, is completely ignorant of a basic compiler feature dealing with memory alignment. Way to go.
I'd imagine it's because this is a talk about standard C++, not compiler-specific extensions.
I understand not knowing about a non standard pragma and personally I don't like the pragma anyway.
However, the speaker is clearly misinformed about unaligned data hurting performance, or is programming in non-x86 environment. Google "lemire unaligned x86" for nice blog post with benchmarks. (Might not apply to floating point)
Useful for stuff like loading binary file headers like BMP and WAV though.
you just a stupid fool if your think what hi has newer heard about it, its a trick
arena.h needs a forum.h
Otherwize, floating atomics will extinguish humanity.