6 ms·

Games (I am talking about AAA here, have no idea about all possible games) are not written in the style that leaves place for constructors/desturctors. The data

Games (I am talking about AAA here, have no idea about all possible games) are not written in the style that leaves place for constructors/desturctors. The data is better in tables (i.e. arrays) than spread all over the memory and accessible through a pointer network. The reasons being: a) walking an array is orders of magnitude faster than walking a pointer chain and b) heap allocation wastes more memory This, in turn, makes no sense for polymorphism since you already have uniform data in the arrays there is no need to do an expensive indirect jump to figure its type.

gregstula 11y ago
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.
- pandaman 11y ago
  You could, but why? To compensate for the lack of construction/destruction of the array's elements? Practically these arrays never go away so there is little point in deallocation anyways.
  - autoreleasepool 11y ago
    If you're using C++ you're still using default destructors even if you don't write them. In C, you at least get deterministic destruction for variables and structures on the stack. This isn't something you really opt out. It's there by default. 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.
    - pandaman 11y ago
      Default destructors are fine since they don't produce any code as long as you don't have any real destruction going on. >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.
      - gregstula 11y ago
        > I don't know anybody who would agree with this. 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?
        pandaman 11y ago
        >std::array<int,ARR_SIZE> is better than int arr[ARR_SIZE] I don't know how you could disagree with that... 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).

gregstula 11y ago

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.

pandaman 11y ago
You could, but why? To compensate for the lack of construction/destruction of the array's elements? Practically these arrays never go away so there is little point in deallocation anyways.
- autoreleasepool 11y ago
  If you're using C++ you're still using default destructors even if you don't write them. In C, you at least get deterministic destruction for variables and structures on the stack. This isn't something you really opt out. It's there by default. 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.
  - pandaman 11y ago
    Default destructors are fine since they don't produce any code as long as you don't have any real destruction going on. >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.
    - gregstula 11y ago
      > I don't know anybody who would agree with this. 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?
      - pandaman 11y ago
        >std::array<int,ARR_SIZE> is better than int arr[ARR_SIZE] I don't know how you could disagree with that... 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).