3 ms·

> Sticking with C++11 means you do not have std::make_unique, and any claim that these "best software engineers" not only fail to use smart pointers Pretty muc

• bipson 4y ago
  Which doesn't mean that they are any better than the provided standard implementations. They are there because it makes sense to have them. Now you don't have build and maintain your own ship.
  • Const-me 4y ago
    > Which doesn't mean that they are any better than the provided standard implementations. That standard implementation is a thin wrapper over malloc(). That standard malloc() is not necessarily good enough. The performance is not great, but worst of all when you have many small objects, they are scattered all over address space. Chasing many random pointers is expensive. While it’s technically possible to use custom memory management with std::unique_ptr with that that second template argument with custom deleter, it complicates things. The code often becomes both simpler and faster when using custom smart pointers instead. That’s not specific to videogames, applies to all performance-critical C++. These standard smart pointers are good for use cases with a small count of large long-lived objects. For large count of small things, the overhead is too large, people usually do something else instead.
    • arinlen 4y ago
      > That standard malloc() is not necessarily good enough. The operative word is "it enough". Let's not fool ourselves by claiming that all memory allocations take place in hot paths, and that all conceivable applications require being prematurely optimized to the extreme because they absolutely need to shave off that cycle from an allocation. Meanwhile people allocate memory in preparation of a HTTP request, or just before the application is stuck in idle waiting for the user to click on the button that closes the dialog box. It makes absolutely zero sense to proselytize about premature optimization when no real world measurements are on the table.
      • Const-me 4y ago
        Let’s not pretend all conceivable applications are, or should be, written in C++. People mostly stopped using C++ to develop web servers which handle web requests, because they moved to Java, C#, PHP, Ruby, Python, etc. People mostly stopped using C++ to develop GUI apps which handle these buttons, because they moved to Java, C#, and now JavaScript/TypeScript. What’s left for C++ is software (or sometimes individual DLLs consumed from other languages) which actually need it to achieve the required performance. Even despite the language is unsafe, low-level, and relatively hard to use which directly affects software development costs.
        • int_19h 4y ago
          But at the same time, straightforward C++ code with no tricks is still orders of magnitude faster than Python or PHP, and usually faster than Java and C#. So you still don't need custom allocators etc to be "good enough" most of the time.
          • Const-me 4y ago
            I agree about Python or PHP. However, for Java or modern C#, in my experience the performance is often fairly close. When using either of them, very often one doesn’t need C++ to be good enough. Here’s an example, a video player library for Raspberry Pi4: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo As written on that page, just a few things are in C++ (GLES integration, audio decoders, and couple SIMD utility functions), the majority of things are in C#. Still, compared to VLC player running on the same hardware, the code uses same CPU time, and less memory.
            • arinlen 4y ago
              > However, for Java or modern C#, in my experience the performance is often fairly close. Aren't you contradicting yourself? You started off complaining malloc of not being good enough, but now it's suddenly ok to tolerate Java and C#'s performance drop when compared to C++? Which one is it?
  • enjoy-your-stay 4y ago
    For the longest time I've written my own smart pointers to manage the lifetime of pretty much anything that needs a cleanup - database connections, query objects, file handles, threads, mutexes and yes raw pointers. All of this code built just fine on pre c++11 compilers, ran reliably, was performant and easy to maintain. Rolling your own smart pointers is not something I'd discourage.
    • int_19h 4y ago
      It might be easy to maintain to you. Somebody who has to pick up that codebase later would have to spend time and effort figuring out all those custom smart pointers and their idiosyncrasies. If all they do in the end is the same as unique_ptr & shared_ptr, it's all wasted time.
      • badsectoracula 4y ago
        > Somebody who has to pick up that codebase later would have to spend time and effort figuring out all those custom smart pointers and their idiosyncrasies. If we're still on the topic of game engines, someone who cannot easily figure out a smart pointer implementation has no place working with the game engine's code in the first place. Unreal Engine has its own implementation for that stuff and it took me literally minutes to get to grips with it - same with the custom engines in companies i worked at before. This has absolutely never been a real problem in practice.