Re:Memory management in C programs (2014)
by robotresearcher on Monday July 18, 2016 @11:58PM
(#12119512)
Constructors are resource allocation, so they can always fail.
You can't really tell if the stack overflowed in a constructor though, plus that will essentially /never/ happen, so I think it's okay to exclude stack overflows when creating stack allocated objects as failure conditions. In that case no, a lot of constructors won't be able to fail.
Any function can overflow the stack. If the object is constructed on the heap, 'new' can fail but will always throw an exception; if you aren't using exceptions it will just crash the process.
Yeah. That's why I don't say it's a failure condition for a stack-allocated object to overflow the stack. Notice my parent comment said:
> Constructors are resource allocation, so they can always fail.
Which is false.
Re:Memory management in C programs (2014)
by robotresearcher on Tuesday July 19, 2016 @01:45PM
(#12123359)
Can you explain why this is false? If I run out of stack or heap by exceeding the process limit, the constructor must fail. Is this incorrect?
I see your comment above that stack overflows essentially never happen, but having watched it happen, I disagree.
This is not an error that you can reasonably recover from. If you are out of stack, even constructing an exception to throw is likely to fail.
Because the only correct behavior here is to terminate the program immediately, it doesn't matter in the discussion of whether to use exceptions or not.
new can and does fail when you're out of memory, and this is a condition that many programs do need to handle (for some programs crashing is appropriate and in that case sure, you can live without exceptions). In a pedantic technical sense that's not the constructor failing, but your options for handling it are much the same.
std::optional is now confirmed for C++17, which can make the API a bit nicer. Using factory functions as pseudo-constructors also lets you name them, which is often nicer than having to rely on argument types to disambiguate constructors with different purposes.
Note: I don't actually know C++ very well. It's possible there's a more idiomatic way to accomplish this. In particular, another wrapper class could be created that owns an instance of the trivially-constructed instance mentioned above. The factory function could then take an instance of the wrapper class and then modify and return an instance of the class you actually want to obtain.