Scope exit in C++11 (2012)

http://the-witness.net/news/2012/11/scopeexit-in-c11/

by noch • 8 years ago

39 49 8 years ago

the-witness.net

jwilk2• 8 years ago

The site doesn't load for me. Here's an archived copy:

https://archive.is/srQvw

jordigh• 8 years ago

It's nice to see some D ideas make it into C++.

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.

katastic• 8 years ago

I absolutely agree. C++ is at least a decade behind D. Literally.

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.

w8rbt• 8 years ago

I think that's mainly because C++ is an ISO standard used all over the world by big business and governments. So its standards are released less often and with a great deal of testing and care. I bet you will be able to specify -std=c++Whatever for the next 50 to 100 years, maybe longer.

klipt• 8 years ago

C++ is like English - widely used, and steals like hell from other languages.

D is probably more like, hmm, Esperanto? Carefully designed but few people know about it.

Haskell would probably be Lojban...

smitherfield2• 8 years ago

While I'm a C++ fan, I'd readily concede it's much closer kin to (verbose) German than (laconic) English.

Java's even more verbose, so it probably has the stronger claim on German,* which I guess makes C++ Danish and Perl English. :)

* https://en.wikipedia.org/wiki/Andy_Bechtolsheim

joejev• 8 years ago

This pattern was possible with a scoped class in c++ 98.

maxlybbert5• 8 years ago

I’m pretty sure D got the idea from C++: http://www.drdobbs.com/article/print?articleId=184403758&sit... (note that there are three pages).

favorited• 8 years ago

This is pretty similar to std::lock_guard (and similar RAII types). Except instead of unlocking (or tearing down a resource, etc.) upon destruction, it invokes a lambda.

lyricaljoke• 8 years ago

This type of construct is unnecessary in C++11; the presence of RAII containers and structures totally obviates it. C++ provides a language-level construct for logic performed at the end of object lifetime (i.e., when value types fall out of scope or when heap-allocated objects are deleted): the destructor!

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.

emsy• 8 years ago

That's if you program "object oriented". In my experience object orientation in C++ often means something entirely different than in a GCed language like Java or C#. It's totally reasonable to program data-oriented in C++, especially for time critical applications like games. Unfortunately, this rules out many abstractions and mechanisms that make sense in a modern C++ application.

mehrdadn8• 8 years ago

What everybody seems to miss (including in the other comments here) is the fact that no kind of hackery with destructors will ever make them equivalent to scope(exit) or finally{}, because of the simple reason that destructors invoked via exceptions can't throw their own exceptions. And this makes sense, because destructors are meant to release resources, whereas finally/scope(exit) are meant to execute after prior operations in a LIFO manner. Not all operations that need to occur in a LIFO manner are inherently tied to resource acquisition. More fundamentally, one is inherently about data, and the other is inherently about control-flow... simply put, they're different tools with different use cases, even though people don't bother to make the distinction. Nevertheless, if people insist on using the same hammer for both nails, the language needs to address this fundamental issue before people can claim it's possible to do scope(exit) or the equivalent in C++.

lomnakkus3• 8 years ago

I'm not sure I understand what you mean.

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?!?

mehrdadn8• 8 years ago

For your "release resources" point: fclose() can fail, yet in fstream::~fstream() that must be ignored. So that's not great.

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...

vvanders5• 8 years ago

This is my big gripe with exceptions and why I'm happy that Rust doesn't have them(yes I know there's panics but that's a separate thing).

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).

dbaupp5• 8 years ago

To be fair, Rust doesn't solve the errors-in-destructors thing any better: Drop::drop can't return anything.

mehrdadn8• 8 years ago

This is your biggest gripe with exceptions? So you're saying you'd be using them if only the language supported a native finally/scope(exit) that avoided this particular edge case?

beached_whale3• 8 years ago

I don't think I understand, you can throw from a destructor. However, in C++11 it gets tricky because destructors are implicitly declared noexcept, so if you want to do so you need to mark them noexcept(false). As for implementing scope(exit) yeah, apparently this isn't possible.

mehrdadn8• 8 years ago

I don't think I understand, you can throw from a destructor

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

deathanatos• 8 years ago

destructors invoked via exceptions can't throw their own exceptions

`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.)

cjalmeida• 8 years ago

Java from the beginning allows you to chain exceptions and that is a core part of debugging.

In Python this is a very recent construct and few libraries use it, unfortunately.

maxlybbert5• 8 years ago

That’s funny, because I really dislike “finally,” because it isn’t much better than doing all the cleanup yourself.

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.

mehrdadn8• 8 years ago

The drawback is that the finally block is far away from the set-up block, which makes it painful to maintain and allows them to get out of sync pretty easily. It's a syntactic issue rather than a semantic issue.

(This is only referring to use cases other than resource release.)

uep• 8 years ago

Andrei Alexandrescu has a fun talk about implementing scope_exit using a new C++17 function: std::uncaught_exceptions (which is a tweak to std::uncaught_exception). Fundamentally, it doesn't really solve the destructor throwing exceptions issue though.

https://www.youtube.com/watch?v=WjTrfoiB0MQ

smitherfield2• 8 years ago

You can do the same thing with no C++11 features other than C99 variadic macros. (IMO cleaner, too).

  #define SCOPE_EXIT(...)\
  	struct SE##__LINE__##_{~SE##__LINE__##_(){__VA_ARGS__;}}se##__LINE__##_

saagarjha• 8 years ago

I'm curious: is __VA_ARGS__ part of the standard, or just widely used?

tzahola2• 8 years ago

It is.

jwilk2• 8 years ago

It's part of the standards since C99 and C++11.

tzahola2• 8 years ago

Yeah but that’s kinda cheating

mehrdadn8• 8 years ago

No, you can't generally put anything useful in there. The whole point of a lambda is the [&]. If you can't capture local variables then it's practically useless.

maxlybbert5• 8 years ago

Alexandrescu managed to do it in 2000: http://www.drdobbs.com/article/print?articleId=184403758&sit... (note that there are three pages).

The version in Facebook Folly was cleaned up because of C++11, but this wasn’t a new technique five years ago.

EgoIncarnate• 8 years ago

(2012)

laythea• 8 years ago

Wow, so much debate over the specific manner in which to solve a problem. More needed on the which problems to solve, I think.

Scope exit in C++11 (2012)

Related Stories