5 ms·

Why would you heap allocate something that you're deleting in the same function? Isn't there some equivalent length example that isn't so contrived?

• EpicEng 12y ago
  There are numerous cases when one would do exactly that, which all boil down to "this thing is too big for stack allocation." Ever done any image processing?
  • bmm6o 12y ago
    Even in cases like that it's uncommon for the object to actually take up a lot of stack space. Since member variable's sizes have to be known at compile time it only applies to fixed-size (or parametrized) buffers.
    • vodik 12y ago
      As far as I know, using `new` or not has nothing to really do if it goes onto the stack or not. That's simply a common implementation details. What its really saying is if the lifetime is automatic or manual. Maybe I'm confusing C with C++ or just outright confused, but to my understanding, nothing says that: int foo[] = <massive amount of data>; actually has to live on the stack.
      • EpicEng 12y ago
        Well, in practice, it's both. Sure, stacks and heaps are an implementation detail, but they're pervasive. You simply can't write int x[10000][10000]; and expect it to not cause a stack overflow in any real world implementation. It's an implementation detail you absolutely need to be aware of.
      • bmm6o 12y ago
        > nothing says that [...] actually has to live on the stack. This might be possible in theory but I've never seen it in practice.
  • mkale 12y ago
    In addition, RAII is useful for more than just memory [de]allocation: database connections, resource handles, anything that you have to get/create and then cleanup/release.
    • czinck 12y ago
      As someone that works 90% with python and 10% with C++, that's something that gets missed in the debates about GC/manual memory management. It's a lot easier to leak resources in python programs because the whole point is you aren't sure what the lifetime is of some objects; if you knew, you wouldn't need a GC. So I end up putting a with block pretty high in the call stack holding the DB handles (most of the time) which is just a weaker form of RAII, as you can't "allocate" anything further down the call stack. I prefer working in python to C++, I just wish I had a lot more control over things like this. And no, __del__ isn't a good solution as that opens a whole can of worms (for one, it's not guaranteed to ever be called).
      • tstack 12y ago
        Python has context managers, which were added for exactly this purpose. with alloc_resource() as resource: resource.use()
        • czinck 12y ago
          I mentioned those. They work, but they're just a weak form of RAII without any extra power.
          • tstack 12y ago
            Can you elaborate on "extra power"? A c++ constructor/destructor pair is equivalent to __enter__ and __exit__. I fail to see how this grants a significant amount of power. There's certainly differences, but the gap is probably not as large as your weasel words make it out to be. You complain about having to put initialization into 2 constructors, but there's the flip-side with things like mutexes. In c++, you have to have 2 classes, one for the lock and one for the guard. Whereas with a context-manager, you have one class and the locking code is in the __enter__ and __exit__. with self.lock: self.do_stuff() In that case, I would say that the context-manager is nicer.
• TheCoelacanth 12y ago
  There's also such a thing as move constructors, so that you can pass ownership to somewhere else and have it be deleted there. For instance, std::unique_ptr<X> f () { return std::make_unique<X>(); } void h (std::unique_ptr<X> x) { x->doSomething(); // x is released after this function returns } void g () { auto x = f(); h(std::move(x)); }