Why couldn't you use a structure to encapsulate the table and then have the destructor to deallocate the the array?
This is how vector works.
This is how vector works.
Practically these arrays never go away so there is little point in deallocation anyways.
The parent was wrong about vector though, it won't safely free elements that do not have their own destructors to clean up their own resources. Another good reason to use RAII everywhere. It costs nothing, to encapsulate memory management.
> You could, but why?
Because there's zero overhead and you guarantee to be passively covered in the few edge cases where you do end up needing deallocation. Now you don't have to worry about special handling of edge cases and you have a more general purpose data structure.
A better question is, why not?
It's simply a better designed and more flexible container than a raw array. Other than a bias against C++isms, there's no good reason to avoid these useful features.
>There's zero overhead and you guarantee to be covered in the edge cases where you do end up needing deallocation.
If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible than have it covered. E.g. I prefer game crashing on out of memory rather soon than going on with thrashing the heap till it crashes 8 hours into the soak test due to the heap fragmentation.
>It's simply a better designed and more flexible container than a raw array.
Tastes differ. I ship games myself and almost all programmers I know do the same. I don't know anybody who would agree with this. Just to be clear, I am talking about destructor of an array. Wrapping arrays in structures is fine and everybody does this.
RAII is orthogonal to contiguous storage in memory. You are not opting into heap fragmentation by moving your "dealloc struct" function from the global namespace to a destructor. It has nothing to do with the the memory layout. It has to do with preventing memory leaks and undefined behavior.
How would this be different?
> I don't know anybody who would agree with this.
It isn't really something to agree on, in one scenario you have options for automation but don't give up anything, in the other scenario you have no ability to use ownership or scope semantics whether you want to or not.
In one case it takes 1-15 minutes to reproduce, in other - 8 hours.
>It isn't really something to agree on, in one scenario you have options for automation but don't give up anything, in the other scenario you have no ability to use ownership or scope semantics whether you want to or not.
Judging by your previous question I figure you don't ship games, do you?
> I figure you don't ship games, do you
No, I only write them, I've found it's a lot easier to let someone else handle the distribution.
That I don't know. As I said, I was only talking about deallocation of arrays that were not supposed to be deallocated.
std::array<int,ARR_SIZE> is better than int arr[ARR_SIZE]
I don't know how you could disagree with that after looking at the facts. From what you're saying here, there seems to be a culture that favors "old school" C programming in games, but the reasons behind it seem like nothing more than a fear of the unknown. I don't mean to be disrespectful, it just seems like nothing but stubbornness to me.
> Just to be clear, I am talking about destructor of an array
Can you be clear about why this is bad?
What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping.
>Can you be clear about why this is bad?
Useless code at best (if your game runs properly it will never be deallocated by your code), obscuring bugs at worst (if it starts deallocating at runtime it will take longer to fail).
Guaranteed to be contiguous, and semantically equivalent to a C array in all cases.
If you don't trust your vendor's STL implementation take a look at the intrusive containers in EA's STL implementation. It's very very good for games. It's also safe, which is a good thing that doesn't obscure bugs it all.
https://github.com/electronicarts/EASTL
> e.g. can the GPU read from it at all? Can it write? What are cache policies?
Fun fact, you can write your own template container with specific features with no additional overhead from a C "array" that's also memory safe.
> if it starts deallocating at runtime it will take longer to fail).
It can't magically deallocate at runtime. It's deterministic. I don't think you understand you give up zero control. It's just a cleaner system with less room for human error.
> obscuring bugs
What's obscure about knowing exactly where are all memory management occurs without exception? C-style malloc and free scattered all over the project is way more prone to hiding bugs.
Yeah I missed the part where you said mmap. There's libraries that make that safer, but clearly there's a preference for working with the raw tools here.
> Otherwise have fun with your own mental image of game programming yourself.
Ignorance is bliss. Have fun ignoring the progress systems programming has made in the last 30 years. Why bother even looking into it right? If what works for you works... that's all that matters.
I'm not exactly sure why you think these things aren't achievable in C++ (and because they are achievable they are relatively straightforward to wrap in a way that they can be made generic while hiding the complexity so you can be done with it). I've even made variadic templates that fuse memory allocations together like Jai's proposed feature.
I've seen people who know C and seem forever hung up on it. It isn't really rationale these days now that there are C++11 compilers that are so mature. It's almost as if there are people who work in a constantly advancing field but don't want to learn anything new.
Thank you for the advise but what if I want to shrink one array that takes 200 MB of memory by 10MB and give it to another array that takes 50 MB of memory on a system with only 256 MB of memory?
> If you need different types of memory or aligned memory, make an allocator and use that.
std::array does not have allocators.
>I'm not exactly sure why you think these things aren't achievable in C++
I have no idea why you think so. I only used C++, assembly and various shader languages in every game I worked on. I did some C in drivers but I don't think it's a good language for games.
You can't possibly think memory allocation problems that are solved by custom allocators can be dismissed because std::array doesn't take an allocator when that it integral to the entire reason it exists. Are you trying to say that not only do you want aligned static memory but that there is nothing that exists that helps over a raw C array?