4 ms·

> 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 afte

> 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
  > 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. 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 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.
  - pandaman 11y ago
    As I said, the alternative is not a C array. Neither is C style malloc and free are used in games. If you want a discussion - argue over what I've said or ask questions if you don't understand something. Otherwise have fun with your own mental image of game programming yourself.
    - gregstula 11y ago
      You asked a question about the array and I answered it. 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.
- CyberDildonics 11y ago
  Disregarding the fact that std::array is allocated on the stack, you do realize that running under a debug mode means that there can be bounds checking assertions built into containers like this, not to mention iteration of the elements instead of iteration of the indices (which guarantees not going out of bounds) ?
  - pandaman 11y ago
    std::array is not necessarily allocated on the stack, it's only allocated on the stack when it's a local variable. So I realize what it is and what it does. Do you realize that you have little control over where its memory goes and there are very different types of memory available to games? Do you know what is memory alignment? Do you realize you cannot grow/shrink it? Do you realize you can still do bounds checks if you need them?
    - CyberDildonics 11y ago
      If you need to grow or shrink it use a vector. If you need different types of memory or aligned memory, make an allocator and use that. Many people do, it is a very common use of allocators. Even if you don't want to use the STL you can encapsulate all of these things for reuse and modularity. 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.
      - pandaman 11y ago
        >If you need to grow or shrink it use a vector. 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.

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
> 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. 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 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.
- pandaman 11y ago
  As I said, the alternative is not a C array. Neither is C style malloc and free are used in games. If you want a discussion - argue over what I've said or ask questions if you don't understand something. Otherwise have fun with your own mental image of game programming yourself.
  - gregstula 11y ago
    You asked a question about the array and I answered it. 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.
CyberDildonics 11y ago
Disregarding the fact that std::array is allocated on the stack, you do realize that running under a debug mode means that there can be bounds checking assertions built into containers like this, not to mention iteration of the elements instead of iteration of the indices (which guarantees not going out of bounds) ?
- pandaman 11y ago
  std::array is not necessarily allocated on the stack, it's only allocated on the stack when it's a local variable. So I realize what it is and what it does. Do you realize that you have little control over where its memory goes and there are very different types of memory available to games? Do you know what is memory alignment? Do you realize you cannot grow/shrink it? Do you realize you can still do bounds checks if you need them?
  - CyberDildonics 11y ago
    If you need to grow or shrink it use a vector. If you need different types of memory or aligned memory, make an allocator and use that. Many people do, it is a very common use of allocators. Even if you don't want to use the STL you can encapsulate all of these things for reuse and modularity. 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.
    - pandaman 11y ago
      >If you need to grow or shrink it use a vector. 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.