C++ Weekly - Ep 359 - std::array's Implementation Secret (That You Can't Use!) 

Actually 8 overloads. You forgot rbegin, rend, crbegin, crend

Actually 🤓

And yet, SIZE_MAX/PTRDIFF_MAX are in cstdint - because C is cursed. :)

Signed counterpart of size is ssize. Ptrdiff is an unrelated type (but usually “the same” as ssize)

@@fullfungo They are the counter types of each other. There's no such type as ssize in the standard. However there's a function called std::ssize() which actually returns a std::ptrdiff_t as the result. And obviously std::size() returns a std::size_t.

@@ohwow2074 What I mean is that they are *not designed* to be compatible. ptrdiff_t can be smaller than size_t, so you cannot rely on it as “the signed counterpart” of size_t.

Because then you need a constructor to initialize it

We're relying on direct initialization, which is very important for performance and usability. See also: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-3LsRYnRDSRA.html

Destructure the public data member directly, using `const auto [a,b,c] = array.data` - this won't introduce any function calls to the final binary either, as this will just create new names / references. Which is why I prefer public-by-default design. Very rarely do I find good reason to make members private.

@@simonfarre4907 Yeah I also began designing my types with public members, it's very convenient, I also add const to mark them immutable. But the thing he used in the video is std::tuple_element which is a bit weird

@@TNothingFree Yeah I agree. As far as I understand, it's basically pre-destructuring functionality (the getters etc), meaning, pre C++-17 (if I'm not mistaken), so before it was actually standard to the language to destructure. But don't quote me on that. Yeah, I unfortunately got taught a lot of nonsense at college back in the day (where the main language used was Java, except the courses I chose because I wanted to take them, like C++ & C for instance). It took some time to shake the habit of making almost everything private. This was quite a long time ago now though, but none the less, colleges and universities here seem to teach it still, which is unfortunate.

@@TNothingFree I like public members a lot too, but not const members, I think those are an anti-pattern. You can afford to make everything public when you don't have any invariants i.e. your members are completely independent, with no binding between them. An example of an invariant is a struct named Foo with a std::vector nums and a std::size_t odd_nums_count. In this case you require setters and getters to maintain the one true value inside odd_nums_count. If you were to publicly expose those two the invariant could easily be broken. You could argue that you only need to set those at construction and so you can mark them both const but that kinda breaks both value and const semantics. If you create another class Bar which has a member Foo foo you are forced to direct initialize foo inside Bar's constructor. If you needed to acquire a resource inside the constructor and only then initialize foo (read the vector of nums from std::cin for example) you can't.With a normal value-type you could acquire a Foo temp_foo = ReatFooInput(); from somewhere and then just move it in my_foo = std::move(temp_foo); or even better my_foo = ReatFooInput(); . But instead you are forced to wrap my_foo in a type that allows deferred initialization like a std::unique_ptr (idk if you can use std::variant/optional/expected to also defer initialization). TLDR: When you mark a single class member as const, the whole class gains all the restrictions of a const type, even if it's not. Always try to write out the appropriate setters/getters if you need to maintain some invariant, don't fake it with const members. Note: Marking a class member mutable is way less bad (even if some people would tell you otherwise). If it's on a private member, then it's invisible to the class user, and if it's public, then it's at least opt-in (even tho it's bad form to mutate const variables). On the other hand if you mark a class member const, the user of that class is always reminded of it and has to constantly (get it?) work around the broken value semantics.

Yes, I don't know why they named it `_Nm`, something like `_Size` or `_Count` would be simpler perhaps.

@@Cornyfisch I mean for me it's quite obvious. They chose this design because it's obstructive and meant to be as difficult to read as possible. If i'm allowed to speculate some what in bad faith, I would think it's because they consider themselves so superior or smart, that why write code that's easy to understand for the overwhelming majority of people? No, let's just use arcane and strange abbreviations and acronyms. C++ has a long way to go here. When digging through source code of other newer languages, it's clear they've learned the lesson.

@@simonfarre4907 Haha I can see your point. All these strange conventions like Hungarian notation, LPCWSTR (or whatever it's called) and weird _Ldng_snke_case__ things can seem like magical incantations at times.

@@Cornyfisch yeah! I would be more forgiving if it was just found in stdlib stuff from the 90s - but noooo, even newer additions like ranges has to suffer from it.

@@simonfarre4907 "Never attribute to malice that which is adequately explained by stupidity".

And then it unfortunately becomes one of the worst option possible - mixed value/reference type. Semantics become much worse and you need to carry stack buffer alongside vector everywhere (in e.g. return statement). Types like static_vector/small_vector are much better replacement if you need stack-allocated/small buffer optimized vector.

@@antagonista8122 I am not saying it is a good idea in general terms (I can think of specific cases where it is), all I am saying it can be done.

@@antagonista8122 static_vector / small_vector solve a subset of the same things that PMR solves. Using that same logic, they become one of the worst options possible as well. The point about PMR is the fact that you get full control of for instance memory dealloc. Using PMR, you can "blink" (i.e. it resolves to a simple `munmap` of the memory) the collection out of memory. Poof, a no-op, essentially. As far as I know, static_vector and small_vector both run the destructors of it's types. But being able to blink away an entire collection, without even worrying about destructors, meaning, the destructors aren't even run at all, (obviously, the contained types will has to use the same allocator as well), can be extremely performant. Using PMR, you can basically build pseudo-stack allocated containers, meaning, they're not on the stack, they're on the heap, but some operations on them, quite literally behave as though they were stack allocated (referring to the blinking out of existence).

@@simonfarre4907 I'm not sure where you got your info from, but objects on the stack are always destructed unless their destructor is trivial, they never just "blink out of existence". Also, an allocator whose destroy member function doesn't actually call the destructor of the object is a really bad idea, as it could easily cause serious issues (memory not being freed, resources not being released, etc). Also, the destroy member function was deprecated in C++ 20, so in future versions of the standard it could be removed/unused entirely.

@@scarletlettersproductions4393 yes, but objects constructed on the stack can have their destructors inlined. So there is still a performance benefit there. I've seen the performance gain in GDB codebase, personally. The comparison to stack allocated objects versus heap allocated ones was just to use something as a frame of reference, although probably not the best one. As far as blinking out of existence, this is essentially what can be used in games to avoid having to spend unnecessary time destructing objects since you A: is in complete control of the objects life times and B: in complete control of the memory that is being used. I suggest you watch the Bloomberg CppCon talk on Polymorphic memory allocators. So you are absolutely, 100% wrong about it being a bad idea. It is most certainly not a bad idea if the problem domain warrants it. It can have fantastic results on memory diffusion (and fragmentation) and performance, but it has to be used correctly. I think you probably have to rethink your understanding of allocators to really understand what can be gained here and the aforementioned cppcon talk from Bloomberg on Polymorphic memory allocators is a great place to start. There are many more PMR talks on cppcon though. Specifically, watch "CppCon 2017: John Lakos “Local ('Arena') Memory Allocators" parts 1 and 2.

Because then it is no longer an aggregate type, and thus you couldn't initialize it with aggregate initialization.

​@@HitoPrl Ah, I see. Thanks.

😆 haha

Have you heard of 'deducing this'? Its a C++23 feature which does essentially this.

@@JonahFoley Thanks. I think Jason did a video on it a while back, but I had forgotten.

@@davidbell304 yeah, I'd check that out, ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-QyFVoYcaORg.html this is also a great cppcon talk which covers the matter

They must be explicitly marked constexpr if you want to use them in a constexpr context (and we do want to!)

std::array has operator[], which does not throw exception.

Yes

It is, as show, simply a wrapper around a c array. So the layout will be the same as its data, which is a c array.

How about a reference?

But you can do `f(array { 1, 2 });`!

@@TheClonerx Not as elegant. (What if "void f( array< array, 2 > )"? Things with a constructor you can specify by their elements.

@@victotronics This works. What's the problem? f( array { array { 1, 2 }, array { 3, 4 } } );

you can do f( {{1,2}} ); still annoying, but...

Honestly though when you want to do destructuring, the data should be plain old data (POD) at which point you don't need any that arcane stdlib stuff (which as far as I know, also introduces more machine code to the final binary). Destructuring the data directly is what I would prefer, i.e. `const auto [a, b, c] = array.data`.

@@simonfarre4907 not sure if this is related to my comment? auto [a, b, c] = array.data copy the data. in the array Jason did, there is no proper d-tor, but is really difficult to make it properly - you need to create base class and extend it under template condition, so to have d-tor only for non trivial types etc. If Jason do that, the point he made will be lost.

@@nmmm2000 yes you are correct, that copies the data, just like Jason did in the video. If you want references, you just say "auto& [a, b, c] = array.data" instead. But if you are not going to mutate the ints, copying them is *probably* faster than taking individual references.

@@simonfarre4907 Well, even "auto [a, b, c] = ar;" would make a, b, c references, but into a copied array with compiler-defined name (because a, b, c are defined to be references into ("into" as defined per tuple interface) a dummy thing, which would result if [a, b, c] is replaced with that generated name). Though, of course, in simple cases optimization strips such things away and sometimes could even avoid creating an array altogether.

this is undefined behavior, per the standard. so you are risking name conflicts with other objects / types / etc with these names. While it is unlikely, technically your program can get totally messed up / do random things / generate a minecraft world because you can break the standard library or have the standard library break your code. I recommend not doing that just in case, it bit me once in a program I worked on in university.

@@michaelwaters1358 it's not UB if it's an underscore followed by a non-uppercase character (or followed by nothing), in a non-global scope. so a local or member variable called just _ is fine.

@@danielb2392 oh I actually misread his comment, I didn't realize he meant a variable that is just an '_'. Never mind, thanks for the clarification

@@michaelwaters1358 _0, _1, etc are also OK, as is _lowercase, if not at global ::scope. :-)

That's just github

Looks like GitHub's file viewer

GCC is used. You have to add the flags "-Wpedantic -Wall -Wextra -Wconversion" or at least the first two (I think) to get the error

The best option in this case is something like StringLiteral class template that contains underlying char array as public member and have constructor from c array reference. You can add std::string like interface, concatenate string literals at compile time etc. You can also add templated user defined literal e.g. _sl to construct StringLiteral object directly from "some_string"_sl.

With C++23 there is! 🥳 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-QyFVoYcaORg.htmlm12s Deducing this based CRTP makes much better Mixins possible!

Thanks. I often forget which is the best header for size_t

Why Rust in particular?

@@quintrankid8045 Rust is very similar to C++ but has compile time safety checking (there are other differences but that's far and away the main reason people like rust AFAICT)

@@quintrankid8045 Because it's praised as the system programming language for the next 40 years. Personally, I think it has solid foundations to be a proper replacement for C++ regarding new software and I'd like to know more about it from the perspective of a senior C++ developer like Jason Turner.

It should not be seen as a replacement, but as a competitor - sure.

C++ doesn't make you pay for things you don't use. An extra value for use cases beyond the intended use case of std::array is an additional cost and throws off your expectations (that is, expecting that the size of a std::array is exactly equal to sizeof(T) * N).