4 ms·

Memory management in modern C++ is considerably easier than it used to be. Bespoke memory managers aren't really needed, you can do almost anything you need to

Memory management in modern C++ is considerably easier than it used to be. Bespoke memory managers aren't really needed, you can do almost anything you need to without ever using new or delete.

stevenwoo 7y ago
Out of curiosity, what is the field for which you find this to be true?
- wffurr 7y ago
  If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
  - berkut 7y ago
    std::shared_ptr uses CAS atomics, which in heavy multithreaded code (multiple threads operating on the same pointers), can have surprising overhead in some situations.
    - usrnm 7y ago
      On the other hand, not using atomics in heavy multithreaded code is just a recipe for disaster. The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill.
      - jcelerier 7y ago
        > The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill. On the other hand imagine the security issues if shared_ptr was not thread-safe - you could just not reliably destroy a shared_ptr in any thread. If you really know that you're going to get a graph of shared_ptr that do not move of a single thread, you can use boost::local_shared_ptr explicitely.
        masklinn 7y ago
        One of the advantages of rust is its ability to segregate safe-to-share (between concurrent contexts) and not so, at compile time. While it can’t (yet?) be generic over them, it lets you use the non-atomic Rc in thread-bound structures and know this is never going to be shared between threads, whereas the more expensive Arc can have handles be moved from one thread to an other.
        safercplusplus 7y ago
        Counterparts for Rc [1] and Arc [2] (and compiler enforcement of their safe use [3]) are available in C++, though not standard. [1] https://github.com/duneroadrunner/SaferCPlusPlus#reference-counting-pointers https://github.com/duneroadrunner/SaferCPlusPlus#reference-c... [2] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncsharedv2readwriteaccessrequester https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare... [3] https://github.com/duneroadrunner/scpptool https://github.com/duneroadrunner/scpptool
  - kccqzy 7y ago
    C++ shared_ptr unfortunately is artificially slowed down by multithreaded synchronizations. The count in the control block is always updated atomically. But I frequently need to use them not because my data is shared by multiple threads, but because the ownership situation isn't static. Consider for example implementing a single-threaded persistent tree. This means people frequently need to reinvent their own reference counting mechanisms. Rust does this right. Rc and Arc.
    - rumanator 7y ago
      To be fair, std::shared_ptr is just a high-level component that's a part of the STL. Although it's defined in the C++ standard, it's just a generic shared pointer implementation designed to be as robust and bullet-proof as possible. As with everything in the C++ STL, if you care about bleeding edge performance then you should be prepared to use more perform any (and less generic) components, whether it's data structure implementations or shared pointers.
  - sillysaurusx 7y ago
    This is the quickest way to kill your performance in C++. I guarantee it wasn’t what Carmack was talking about. I used sharedptr extensively in a game engine. Whoops: suddenly 20% of the frame time was gone, never to be recovered. Once that performance is gone it’s almost impossible to get it back, short of rewriting every system.
    - deleted 7y ago
      [deleted]
    - naniwaduni 7y ago
      On the bright side, you didn't lose 200% of the frame time!
    - paulddraper 7y ago
      Yes shared_ptr is relatively expensive; avoid it in your inner loops, but know that it's there for the other 80% of your code.
    - wffurr 7y ago
      Only use shared_ptr when you actually want shared ownership. If you stick to unique_ptr for owning references and then "borrow" that raw pointer in functions, then you get speed without sacrificing too much safety and still no new/delete.
      - slavik81 7y ago
        Additionally, shared ownership should be rare. Most objects should have a single owner that is responsible for them. This is not only better for performance, but also makes the system easier to understand.
  - mianos 7y ago
    And, use unique pointers where possible. I see a lot of code using shared ptr where unique would suffice, even in my own code.
easytiger 7y ago
> Memory management in modern C++ is considerably easier than it used to be It was never actually an issue
- einpoklum 7y ago
  ... until you got the segmentation fault, that is.

Memory management in modern C++ is considerably easier than it used to be. Bespoke memory managers aren't really needed, you can do almost anything you need to without ever using new or delete.

stevenwoo 7y ago

Out of curiosity, what is the field for which you find this to be true?

wffurr 7y ago
If you are writing C++, any field! Just use std::shared_ptr and std::unique_ptr from the standard library, along with std::make_shared and std::make_unique.
- berkut 7y ago
  std::shared_ptr uses CAS atomics, which in heavy multithreaded code (multiple threads operating on the same pointers), can have surprising overhead in some situations.
  - usrnm 7y ago
    On the other hand, not using atomics in heavy multithreaded code is just a recipe for disaster. The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill.
    - jcelerier 7y ago
      > The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill. On the other hand imagine the security issues if shared_ptr was not thread-safe - you could just not reliably destroy a shared_ptr in any thread. If you really know that you're going to get a graph of shared_ptr that do not move of a single thread, you can use boost::local_shared_ptr explicitely.
      - masklinn 7y ago
        One of the advantages of rust is its ability to segregate safe-to-share (between concurrent contexts) and not so, at compile time. While it can’t (yet?) be generic over them, it lets you use the non-atomic Rc in thread-bound structures and know this is never going to be shared between threads, whereas the more expensive Arc can have handles be moved from one thread to an other.
        safercplusplus 7y ago
        Counterparts for Rc [1] and Arc [2] (and compiler enforcement of their safe use [3]) are available in C++, though not standard. [1] https://github.com/duneroadrunner/SaferCPlusPlus#reference-counting-pointers https://github.com/duneroadrunner/SaferCPlusPlus#reference-c... [2] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncsharedv2readwriteaccessrequester https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare... [3] https://github.com/duneroadrunner/scpptool https://github.com/duneroadrunner/scpptool
- kccqzy 7y ago
  C++ shared_ptr unfortunately is artificially slowed down by multithreaded synchronizations. The count in the control block is always updated atomically. But I frequently need to use them not because my data is shared by multiple threads, but because the ownership situation isn't static. Consider for example implementing a single-threaded persistent tree. This means people frequently need to reinvent their own reference counting mechanisms. Rust does this right. Rc and Arc.
  - rumanator 7y ago
    To be fair, std::shared_ptr is just a high-level component that's a part of the STL. Although it's defined in the C++ standard, it's just a generic shared pointer implementation designed to be as robust and bullet-proof as possible. As with everything in the C++ STL, if you care about bleeding edge performance then you should be prepared to use more perform any (and less generic) components, whether it's data structure implementations or shared pointers.
- sillysaurusx 7y ago
  This is the quickest way to kill your performance in C++. I guarantee it wasn’t what Carmack was talking about. I used sharedptr extensively in a game engine. Whoops: suddenly 20% of the frame time was gone, never to be recovered. Once that performance is gone it’s almost impossible to get it back, short of rewriting every system.
  - deleted 7y ago
    [deleted]
  - naniwaduni 7y ago
    On the bright side, you didn't lose 200% of the frame time!
  - paulddraper 7y ago
    Yes shared_ptr is relatively expensive; avoid it in your inner loops, but know that it's there for the other 80% of your code.
  - wffurr 7y ago
    Only use shared_ptr when you actually want shared ownership. If you stick to unique_ptr for owning references and then "borrow" that raw pointer in functions, then you get speed without sacrificing too much safety and still no new/delete.
    - slavik81 7y ago
      Additionally, shared ownership should be rare. Most objects should have a single owner that is responsible for them. This is not only better for performance, but also makes the system easier to understand.
- mianos 7y ago
  And, use unique pointers where possible. I see a lot of code using shared ptr where unique would suffice, even in my own code.

easytiger 7y ago

> Memory management in modern C++ is considerably easier than it used to be It was never actually an issue

einpoklum 7y ago
... until you got the segmentation fault, that is.