Scope exit in C++11 (2012)
the-witness.net
the-witness.net
For your "release resources" point: fclose() can fail, yet in fstream::~fstream() that must be ignored. So that's not great.
For your "execute after prior operations in LIFO manner" point... what is the purpose except to clean up resources? If it isn't about scoped resources, then what is it about, given that defer(...) is explicitly about scope? I mean, if "defer" wasn't about that, we'd just write a few more statements doing the thing and not bother with the whole defer(...) thing?!?
No, fclose() cannot fail to close the file. The return code merely tells you whether any pending write operations have failed in the meantime, which is unrelated to the releasing of the FILE. The FILE will be closed either way. The C standard is explicit about this: Whether or not the call succeeds, the stream is disassociated from the file and any buffer set by the setbuf or setvbuf function is disassociated from the stream (and deallocated if it was automatically allocated). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#pa...
> For your "execute after prior operations in LIFO manner" point... what is the purpose except to clean up resources?
Well, fflush() is an easy example. Or, any logging that must occur at the end of a function call regardless of its success or failure. Or, really, anything else that isn't releasing a resource...
> The FILE will be closed either way.
That doesn't matter. It only matters in a resource-accounting way -- the resource will be freed, but that program does the wrong thing (partial write, 50-50 whether write happens, whatever).
> > For your "execute after prior operations in LIFO manner" point... what is the purpose except to clean up resources?
> Well, fflush() is an easy example. Or, logging that must occur at the end of a function call regardless of its success or failure. Or, really, anything else that isn't releasing a resource...
fflush() can also fail (see above). Logging can also fail, disastrously, if it's going through a serial port -- though, it technically doesn't necessarily break the program's semantic meaning -- nobody wants to wait for N hours for the next log statement to be sent before continuing on with the program's execution.
Do you see, now, what I mean?
(EDIT: I think HN screwed up the quoting on my reply, but I think I've fixed it. Please yell if I quoted you or me(!) badly.)
You're not reading carefully. I never said fclose() flushes anything. Please go back and read what I wrote.
>> The FILE will be closed either way.
> That doesn't matter. It only matters in a resource-accounting way. The resource will be freed, but that program does the wrong thing (partial write, 50-50 whether write happens, whatever). fflush() can also fail. Logging can also fail, disastrously [...]
Yes, you are only confirming what I wrote. Again, please go back and read what I wrote; it seems you are not reading carefully and are very confused what I have been saying (and what you yourself were asking).
Here, I'll quote myself again. I said: "Destructors are meant to release resources, whereas finally/scope(exit) are meant to execute after prior operations in a LIFO manner."
You were surprised these are distinct categories and wanted examples of the operations that would need to occur in a LIFO order but which are not releasing any resources. I cited flushing and logging as easy examples of such operations. You then proceeded to object that fflush and logging can... fail? Yes, I agree; of course they can -- indeed that was half of my entire point as to why they are inappropriate for destructors/RAII, but appropriate for finally/scope(exit).
To repeat even more explicitly: both flushing and logging would need to occur in finally{} blocks, as they are not releasing any resources. In addition, neither of them is appropriate for a destructor, because these operations can fail, and destructors cannot propagate the corresponding exceptions. By contrast, closing a file needs to occur in a destructor, because is releasing a resource (which inherently cannot fail). And indeed, this implies fclose() would need to be called in a destructor and have its return value ignored, as it always succeeds in closing the file.
I did read, thanks.
AFAICT, the POSIX standard mandates that fclose() must flush pending output, so what you said is immaterial.
That is, it can fail to flush in exactly the way I mentioned, and so any destructor-like behavior is faced with a decision as to "what to do".
Now, you're technically right in that the RESOURCE representing the file will be closed, but my counter-point was that it doesn't matter. Either the destructor swallows the error yielding silent incorrect behavior, or the destructor must throw and abort the program.
Neither is very helpful, though I guess aborting the program doesn't play havoc with the program's meaning.
My question is really: What does scope(exit) actually do if a fflush() fails, for example? Any non-built-in equivalent of "scope(exit)" in C++ would have to use a destructor to function reliably, I think, so what to do?
Does it throw? When does it throw? Is it allowed to throw if we're already unwinding the stack due to another exception?
This is horribly complicated... and that's my overall point, really. Just the fact that a resource was technically freed is moot if the program does the wrong thing.
The horrible complicatedness of all of this is an indicator that something is deeply wrong.
(Incidentally, in Java the try-with-resources statement actually seems to do at least a semi-sane thing which is that an exception during a "finally" clause attaches that exception to the already "active" exception in case it happens during unwinding from a thrown exception. Or the other way around, can't be arsed to look it up. The point is that unwinding happens, but errors are not lost. I'm not sure if it actually does the right thing wrt. file descriptors, but one hopes so.)
Every C++ project I've worked on has turned them off both for this and for the RTTI savings(less of an issue these days).
The exception case is much nastier and a lot less explicit.
let mut failed = Ok(())
{
let object = create_it(..., &mut failed);
// ...
} // destructor runs
failed?;
In any case, in either language, an object storing a reference to fill in later restricts how the object can be used, since it can no longer escape from the stack frame which owns the data to which the reference points.
Compared to the above I at least know from an API signature that there's the possibility of an error.
Additionally, the C++ solution for returning errors from destructors is also explicit in the signature.
(To be clear, I'm very firmly a fan of Rust, but I'm also a fan of accurate representations of it.)
According to the spec current_exception() returns a smart pointer which the storage isn't specified. Part of that is implied allocation(returning bad_alloc for instance) which means you may be making a heap allocation for a pointer that could have been handled on the stack. That's going to rule out cases like the embedded space and gamedev where allocations during runtime is a big no-no.
I'm no stranger to C++ but I've been bitten so many times by exceptions. Either in libraries that didn't say they'd throw them(but then did), ABI pollution and having to get new binary drops from vendors because turning them on bloated RTTI which caused binary sizes that didn't fit. They really have no place if you plan to use the language at any sort of scale.
1. using the outpointer is clunky and error prone
2. C++ can do the same thing (both with exceptions enabled, and with them disabled, the latter of which is pretty much the same as Rust)
(The current_exception stuff even makes it possible to handle it fairly generically in C++, so even calling arbitrary code with exceptions-on can be the normal code wrapped in catch_and_write_exception(&exceptionSlot, [&] { ... });, which works for any library code, whether it throws or not.)
> According to the spec current_exception() returns a smart pointer which the storage isn't specified
Exceptions often allocate anyway; current_exception() isn't creating a new problem.
If exceptions allocate that's not the same as Rust, full-stop. I'm sorry if it seems like I'm being pedantic about this point but it's a huge issue of contention for those of us who used C++ to squeeze every ounce of performance out of a platform.
Yes I can manipulate a value through pointers/refs to return a result in both, but in the Rust case I can guarantee that the value lives on the stack by passing in a reference because A: I know the full type up-front(no virtuals unless I use Box<Trait>, no std::exception* opaque types) and B: exception_ptr() makes no such claims.
> Exceptions often allocate anyway; current_exception() isn't creating a new problem.
For those of us who ship codebases with exceptions disabled by default it definitely is a problem. Unchecked exceptions make this a problem which pollutes every one of your destructors and forces you to pay the above cost.
You're being pedantic about something I'm not saying.
I 100% agree with what you're saying in that comment, but that isn't what this thread is about. It has now become clear that your "big gripe" with exceptions is not the inability to throw them out of destructors (which is what causes the problem with scope(exit)), but all the other problems with them.
As my previous comment said, there's lots of reasons why Rust's approach is better (I'm intimately familiar with Rust, and also work on a large C++ codebase... with exceptions disabled ;) ), but that's not what we're talking about here.
> For those of us who ship codebases with exceptions disabled by default it definitely is a problem
No, you're misreading me again: it isn't a new problem. As in, the problems with current_exception() are just the normal problems with exceptions, they aren't something specific to that function. If exceptions are okay (which they're often not; yes, I know, I get that, but that's not the point here), then using current_exception to return errors from destructors is fine.
My point is Rust and C++ both handle returning errors from destructors equally well/badly. (Your point is you, in general, prefer Rust's error handling to C++ exceptions, which is a different point.)
Read what I wrote carefully:
>> destructors invoked via exceptions can't throw their own exceptions
i.e. if you are in a block where an exception is thrown, and a destructor is called during the exception's propagation, then that destructor cannot throw its own exception, as it will terminate the program. (This is unrelated to noexcept.) See here for more info: https://stackoverflow.com/a/130123
I guess the saving grace is that most C++ devs are aware of what could throw in a destructor because it is rare and C++ 11 made this more difficult. Just don't and design around it. If the destructor fails use it as a choice to terminate or ignore.
It's use in C++ implies that you are worrying about something at the wrong abstraction level too.
With that though, I would think that the default > c++11 implicit noexcept is proper. Crash hard when an exception is thrown and maybe even static assert on the result of noexcept( on_exit_cb ) so that it gives a compile error, lambda's can be noexcept and c functions cannot throw(thinking fclose and friends)
If that’s not possible, they have to use a different approach.
`finally`, in languages that have it (and presumably, scope(exit) too), face fundamentally the same problem with exceptions that destructors do: if an exception is already propagating, and you throw another one, what happens?, since you (presumably) can't have two exceptions. C++ says tough / don't do that / you're terminated. Other languages just forget about the other exception, and you lose the context (which can be a pain to debug; though I think more recent versions of Python, for example, will attach the original exception as a "context" to the new one) but your program continues execution.
Languages that expose a result object, e.g., Result in Rust, force you to deal with the issue yourself, essentially, by deciding at the site what to do with it. (The downside being the increased amount of code, though to some extent I believe the language can supply tooling to help there; Rust is again a good example. The upside is you get to choose what happens.)
(I see these more as a tradeoff, that different languages have different opinions about.)
In Python this is a very recent construct and few libraries use it, unfortunately.
The design document for Java try-with-resources says that Sun’s own programmers working on the standard Java libraries got it wrong a third of the time. I find it interesting that C#, Java and Python have each created some kind of automatic cleanup mechanism even though they already had “finally.” That suggests to me that “finally” has some big drawbacks.
(This is only referring to use cases other than resource release.)
Another issue is that people generally don’t test failures as much as they should. They’ll generally get “everything must be rolled back” but mess up “only some things should be rolled back.”
This person is describing an error-prone reimplementation of std::unique_ptr with a custom deleter. I could understand the value of an article like this if the use of C++11 were not allowed, but given that the article is written with C++11 in mind, I fear the author has totally missed the point of RAII-style resource management that the newer language-level constructs provide.
Deterministic destruction and associated logic, as well as the RAII strategies that follow, are perhaps the greatest strength of C++. Languages like Rust have gone on to improve this even further by eliminating some of the greatest sources of error. Capabilities like this don't seem accurately described as C++ learning from D; indeed, if D provides hooks for running logic when names fall out of scope, that seems more accurately described as vice versa.
I think that D is kind of like Mercurial: both less popular than some other wildly popular alternative, but we still hope that at least some of their ideas trickle back into the more popular sibling.
The kinds of features that eventually hit C++, D actually had for at least ten years. I think of D as a clean break. A major version upgrade with an API break. Whereas C++ has committees that move incredibly slowly, D has two architects who are decades long professionals and considered experts in their fields. It has focus, and it's not concerned with making code from the 70's compile on a modern compiler.
I simply cannot enumerate all of the features I use from D that I use every day that have become second-nature. Until I try to code in C++ again and I'm like, "The !@$@!ing order of declarations matter?! I can't make circular references without manually writing forward declarations?!" It feels like banging rocks together to make a 747.
D is probably more like, hmm, Esperanto? Carefully designed but few people know about it.
Haskell would probably be Lojban...
Java's even more verbose, so it probably has the stronger claim on German,* which I guess makes C++ Danish and Perl English. :)
#define SCOPE_EXIT(...)\
struct SE##__LINE__##_{~SE##__LINE__##_(){__VA_ARGS__;}}se##__LINE__##_The version in Facebook Folly was cleaned up because of C++11, but this wasn’t a new technique five years ago.