4 ms·

>In the hands of someone who knows what's going on, programs get much simpler I never really got this argument. With RAII types that have value semantics (ala

>In the hands of someone who knows what's going on, programs get much simpler I never really got this argument. With RAII types that have value semantics (ala shared_ptr) what is so difficult about memory management in C++? I guess there are reference cycles, but weak_ptr can help there. Manual ref-counting (like a COM AddRef/Release pattern) can be tricky, but that is where attention to detail, code reviews and basic competence come in. RAII wrappers with value semantics help here too. Most problems I have seen with that have been people simply not bothering to learn even the basics or using "smart" objects without understanding how they work or how to use them properly, which really isn't that hard, honestly. >that isn't IMHO a good reason to dislike the "magic" behaviour of exceptions. Agreed, my primary pain point around exceptions is people that write functions that mutate some state and are interrupted in the middle via an exception and stack unwind leaves objects in some franken-state. Transactional semantics in the face of exceptions don't just happen except in trivial cases (i.e. functions that don't mutate state or have trivial unwind semantics where they must only restore say a single mutated value). That said the same problem exists anytime there is state mutation and multiple, failure exit paths. For some reason I guess the code I have seen using error code return style tends to handle this better. Could just be some kind of selection bias.

agentS 14y ago
> With RAII types that have value semantics (ala shared_ptr) what is so difficult about memory management in C++? For me, C++ memory management becomes challenging in the face of concurrency. Particularly when you write applications that are event-driven, instead of thread-based, and you've surrendered to an event loop. It becomes challenging to keep track of object lifetimes. Just my 2c.
fauigerzigerk 14y ago
The problem with shared_ptr is that you can't use it for fine grained stuff because it's terribly inefficient. It also has problematic concurrency implications. But more importantly, what makes C++ memory management difficult is that different libraries do it in completely different ways. Bridging that mess is error prone and a huge mental burden.
barrkel 14y ago
In my experience of web server apps, it's been fairly easy to guarantee that either the whole request succeeds, or - if there was an exception - every change is rolled back. Both user state and database state has been transactional, and state that lived on in memory in between requests was either read-only or caches. In UI apps, it's much much harder to guarantee transactional semantics unless you're using persistent data structures or similar techniques that make in-memory transactions / undo trivial to make correct. So it makes more sense for exceptions there to save user data where possible, log the error (potentially back to the vendor), and restart the app. (I don't want to talk about C++. I think both C++ exception handling and memory allocation are broken by C++'s design. You can only make it sort of work with coding standards, and even then it's labour intensive. If you don't yet understand why GC increases productivity, it's an epiphany you'll need to look forward to. Bonus: GC also makes exception safety far easier. For example, you can write a stack.pop() that returns the value popped - one of my favourite examples of C++ being broken.)
- ryanmolden 14y ago
  >If you don't yet understand why GC increases productivity, it's an epiphany you'll need to look forward to. Oh I fully understand/agree with that, I just don't find C++ memory management to be too hard. The concurrency concerns pointed out by others are true, though. Whether they (the concerns) are offset by the lack of deterministic destruction and the extreme triviality of creating reference chains that root things far longer than needed due to the root being live while the rest of the chain should be dead, is another question. As you pointed out, in some domains transactional code is fairly straightforward, or at least tractable without inducing massive depression. In some other domains, not so much :)
  - barrkel 14y ago
    The domain of programs for which C++ memory management is not hard has only a partial intersection with programs that are small, expressive and easy to understand. That is, if you take C++'s techniques for memory management for granted, simpler approaches to problems won't even occur to you.

agentS 14y ago

> With RAII types that have value semantics (ala shared_ptr) what is so difficult about memory management in C++? For me, C++ memory management becomes challenging in the face of concurrency. Particularly when you write applications that are event-driven, instead of thread-based, and you've surrendered to an event loop. It becomes challenging to keep track of object lifetimes. Just my 2c.

fauigerzigerk 14y ago

The problem with shared_ptr is that you can't use it for fine grained stuff because it's terribly inefficient. It also has problematic concurrency implications. But more importantly, what makes C++ memory management difficult is that different libraries do it in completely different ways. Bridging that mess is error prone and a huge mental burden.

barrkel 14y ago

In my experience of web server apps, it's been fairly easy to guarantee that either the whole request succeeds, or - if there was an exception - every change is rolled back. Both user state and database state has been transactional, and state that lived on in memory in between requests was either read-only or caches. In UI apps, it's much much harder to guarantee transactional semantics unless you're using persistent data structures or similar techniques that make in-memory transactions / undo trivial to make correct. So it makes more sense for exceptions there to save user data where possible, log the error (potentially back to the vendor), and restart the app. (I don't want to talk about C++. I think both C++ exception handling and memory allocation are broken by C++'s design. You can only make it sort of work with coding standards, and even then it's labour intensive. If you don't yet understand why GC increases productivity, it's an epiphany you'll need to look forward to. Bonus: GC also makes exception safety far easier. For example, you can write a stack.pop() that returns the value popped - one of my favourite examples of C++ being broken.)

ryanmolden 14y ago
>If you don't yet understand why GC increases productivity, it's an epiphany you'll need to look forward to. Oh I fully understand/agree with that, I just don't find C++ memory management to be too hard. The concurrency concerns pointed out by others are true, though. Whether they (the concerns) are offset by the lack of deterministic destruction and the extreme triviality of creating reference chains that root things far longer than needed due to the root being live while the rest of the chain should be dead, is another question. As you pointed out, in some domains transactional code is fairly straightforward, or at least tractable without inducing massive depression. In some other domains, not so much :)
- barrkel 14y ago
  The domain of programs for which C++ memory management is not hard has only a partial intersection with programs that are small, expressive and easy to understand. That is, if you take C++'s techniques for memory management for granted, simpler approaches to problems won't even occur to you.