3 ms·

I really doubt this sort of hypothetical source of memory leaks was either significant or its root cause could be pinned to this. As this hypothetical scenario

by rualca 5y ago

I really doubt this sort of hypothetical source of memory leaks was either significant or its root cause could be pinned to this. As this hypothetical scenario depends on an exception being thrown, your code would need to throw exceptions repeatedly for the memory leak to be a problem. If your code throws so many exceptions that not freeing the memory allocated during that code point becomes a problem then you have far more serious problems to fix than discussing language lawyer corner cases.

dataflow 5y ago
> As this hypothetical scenario depends on an exception being thrown It doesn't. Exercise for the reader: detect evaluation interleaving without exceptions. > If your code throws so many exceptions that not freeing the memory allocated during that code point becomes a problem It need not manifest itself as a mere memory leak. Exercise for the reader: make something happen beside a memory leak.
- OskarS 5y ago
  > It doesn't Yes it does. Of course you can detect different evaluation orders using side effects, but the fact that evaluation order is unspecified isn't generally a problem: if you write code like `a() + b()` and a() and b() has side-effects that depend on the order they're evaluated in, that is just a bad way of writing code. In any language. The point here is that the compiler is allowed to interleave subexpressions of the two different arguments which causes a memory leak in seemingly safe code. That is a very unreasonable thing for the compiler to do, which is why it is a footgun. But not that it can ONLY happen if the second function throws in between the construction of the object with "new" and the construction of the shared_ptr: if the second function doesn't throw an exception, the construction of shared_ptr is guaranteed to happen. Incidentally: those "exercise for the reader" comments are incredibly obnoxious.
  - dataflow 5y ago
    > isn't generally a problem generally is the key word here. > if you write code like `a() + b()` The code doesn't have to look like that. Add e.g. some arguments...

by rualca 5y ago

dataflow 5y ago

> As this hypothetical scenario depends on an exception being thrown It doesn't. Exercise for the reader: detect evaluation interleaving without exceptions. > If your code throws so many exceptions that not freeing the memory allocated during that code point becomes a problem It need not manifest itself as a mere memory leak. Exercise for the reader: make something happen beside a memory leak.

OskarS 5y ago
> It doesn't Yes it does. Of course you can detect different evaluation orders using side effects, but the fact that evaluation order is unspecified isn't generally a problem: if you write code like `a() + b()` and a() and b() has side-effects that depend on the order they're evaluated in, that is just a bad way of writing code. In any language. The point here is that the compiler is allowed to interleave subexpressions of the two different arguments which causes a memory leak in seemingly safe code. That is a very unreasonable thing for the compiler to do, which is why it is a footgun. But not that it can ONLY happen if the second function throws in between the construction of the object with "new" and the construction of the shared_ptr: if the second function doesn't throw an exception, the construction of shared_ptr is guaranteed to happen. Incidentally: those "exercise for the reader" comments are incredibly obnoxious.
- dataflow 5y ago
  > isn't generally a problem generally is the key word here. > if you write code like `a() + b()` The code doesn't have to look like that. Add e.g. some arguments...