As a very large language used for a very wide range of purposes over many decades, C++ can be written in a lot of different ways. Today we’ll look at some of the norms for “modern” C++ to get a sense of how code is normally written.
Posts Tagged allocation
We’ve covered all the individual container types, so let’s take a step back and look at the containers library as a whole. A lot of features, like support for range-based for loops and allocator customization, are supported in all container types. Today we’ll take a look at the commonalities between the containers and see what ties them together into a cohesive library.
A programming language without access to the underlying system is of little use. Even a “Hello, world!” program requires the OS to output that message. Today we’ll start looking at the system access that the Standard Library provides. We’ll see how to access the file system, so-called “smart” pointers, and check the time using various system clocks.
Last time we saw that jobs apparently have their own Temp allocator. Still, it was unclear how many of these allocators there are. One per job job? One per thread? Just one? Today we’ll run an experiment to find the answer!
Temp memory is backed by a fixed size block that’s cleared by Unity every frame. Allocations on subsequent frames return pointers to this same block. The allocated memory therefore isn’t unique. How much of a problem is this? Today we’ll do some experiments to find out!
Last week’s article came to the conclusion that allocating Temp memory from within a job was safe. This week we’ll look into that a little deeper to find out that it might not be as safe as it looks!
What do you do when a job you’re writing needs to allocate memory? You could allocate it outside of the job and pass it in, but that presents several problems. You can also allocate memory from within a job. Today we’ll look into how that works and some limitations that come along with it.
We’ve seen that Temp allocations are the fastest kind of allocations, but is this always the case? When the fixed-size block of memory they draw from runs out, are the overflow allocations just as fast? Today we’ll test to find out!
Continuing the series, today we look specifically at “overflow” allocations in the Temp allocator. We’ve seen that there’s no need to explicitly deallocate Temp memory because it all gets cleared every frame, but do we need to deallocate “overflow” allocations that didn’t fit inside the block of automatically-cleared memory? Today we’ll find out!
Last week we learned a lot about Allocator.Temp, but we left some questions open. One of them was what happens when we explicitly deallocate Temp memory. We know we don’t need to and that it’ll be deallocated at the end of the frame, but what happens when we explicitly deallocate it? Today we’ll dive in and try to find out.