5 ms·

> Manual memory management is the most popular misconception of C++. Since C++11, it is now recommended to use std::shared_ptr or std::unique_ptr for automatic

• steveklabnik 11y ago
  It's true that stack allocation is often better, and should be preferred, but that doesn't mean the heap isn't useful.
• drderidder 11y ago
  Well said! Dynamic memory allocation is a really big performance hit, and in a lot of cases you can pre-allocate data structures on the stack for serious speed improvements. Avoiding DMA was one of the secrets for writing blazing fast real time systems stuff when I was in telecom. I don't think those benefits have gone away.
  • kristoffer 11y ago
    You and I can't possibly have the same definition of DMA. It is essential to low latency data communication both in the embedded and server domain.
    • bitwize 11y ago
      "Dynamic memory allocation", not "direct memory access".
      • kristoffer 11y ago
        Ah never seen dynamic memory allocation written as DMA before. Maybe obvious from the context but DMA really only has one meaning for me :)
    • emcq 11y ago
      I think he was using a new acronym for Dynamic Memory Allocation rather than Direct Memory Access. I also was confused the first time I read it.
    • vram22 11y ago
      I thought he meant the hardware-related meaning of DMA too, for a second. But the first line of his comment is: >Well said! Dynamic memory allocation is a really big performance hit
• pjc50 11y ago
  Because copying the entire in-memory database you're using on every function call is kind of expensive?
  • gct 11y ago
    C++ has perfect move semantics since C++11, and you can always use a reference to pass things around if you need.
  • petke 11y ago
    Most often you can pass stack values to and from functions without copying. This is because of move constructors, and named return value optimization. Often its slower to use pointers (the indirection). For instance this does not do any expensive copies: std::string getStr() { auto huge_str = getDatabaseDump(); return huge_str; } void readStr(const std::string& str ){ //read str.. } int main() { auto str = getStr(); readStr(str); }
    • pjc50 11y ago
      But std::string is a wrapper for a heap allocation, and a reference also incurs the same indirection cost as a pointer?
      • petke 11y ago
        Yes that's true. Internally a lot of library types use heap allocation. Most well designed libraries avoid it if they can, but sometimes the object is simply too large for the stack. For many library types its a undocumented implementation detail we dont know about. We as users of that library type should not additionally put that object on the heap though, if we dont have too. Its simply unnecessary. Its makes for one extra unnecessary pointer indirection, it adds unnecessary reference counting if using smart pointers, or unnecessary manual memory management if we use raw pointers. It complicates the interface for our functions if we have to wrap types in smart pointers. As for c++ references. Yes that's true. As I understand it they are implemented as pointers internally by compilers. But in important ways they behave more like values, rather than pointers. As in if you copy or assign to them, they copy or assign the value (not the pointer). If you take their address they give the address of the value (not the pointer). Because of this there are not as many pitfalls to using them as there is with pointers. I see them mostly just as aliases for values. In the example above I could have passed the string by value (instead of by reference) to the function. It would still not have done a expensive copy, because of copy elision optimisation. I probably should have done that. It looks a bit funny, and takes some getting used too. Relevant: https://web.archive.org/web/20140205194657/http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ https://web.archive.org/web/20140205194657/http://cpp-next.c...
• srean 11y ago
  You mean C++ programmers allocate n object on the heap even when its lifetime is the same as the scope of the containing block ? Unless its such a large huge object that stackoverflow is a possibility I cant imagine why would one do that.
  • petke 11y ago
    Many programmers have this idea. Oh, this is a big object. I better wrap it in a smart pointer to avoid doing expensive copies when I pass it around. They do it as an optimisation. However because of named return value optimisation and move constructors no expensive copies are done when passing stack values to and from functions. Using smart pointers is actually slower (because of the indirection and reference counting).
  • yongjik 11y ago
    I don't think C++ supports variable length arrays? So, if you want to allocate N objects, where N is not known at compile time, (I think) you have to use heap allocation anyway. Normally I just use vector<>, and call reserve() if I feel like extra performance-y. Sure, it's much slower than C99-style variable length arrays, but 99% of the time it's still fast enough. More importantly, it plays nice with other C++ functionalities. For example, zero-copy construction using emplace_back() inside a for loop. (And if you throw an exception in the middle you're guaranteed that destructors are called exactly for those that are already constructed.)
    • en4bz 11y ago
      > I don't think C++ supports variable length arrays? VLAs are not part of the standard but GCC supports them. Clang however does not, at least not without a compiler flag I think.
    • petke 11y ago
      std::array exists. But it isnt variable length. We might get a dynarray in the next standard. I saw a standards committee panel talk where someone asked about it. Ville Voutilainen promised to write standards proposal. I dont miss it much. Usually std::array does what I want.
• lbrandy 11y ago
  Pointers (smart or raw or whatever) get used when you need reference semantics. It's true that value semantics are usually better but not always (eg inheritance). To be sure, though, being able to make proper value types is a strength of C++. Also we should point out most non-trivial value types make extensive (and necessary!) use of the heap under the hood (eg string, vector)
  • palunon 11y ago
    And then, you have Small String Optimization that put the string data back on the stack ;)