This is cursed:
https://github.com/es3n1n/defendnot/blob/master/defendnot-lo...
If you're curious what's actually going on there:
https://github.com/es3n1n/defendnot/blob/master/cxx-shared/s...
https://github.com/es3n1n/defendnot/blob/master/defendnot-lo...
If you're curious what's actually going on there:
https://github.com/es3n1n/defendnot/blob/master/cxx-shared/s...
defer->void { CoUninitialize(); };
auto _defer_instance_1234 = Defer{} % [&]()->void { CoUninitialize(); };
* auto means infer the type of this local variable from the expression after the =.
* Defer{} means default construct a Defer instance. Defer is an empty type, but it allows the % following it to call a specific function because...
* Defer has an overloaded operator%. It's a template function, which takes a callable object (type is the template parameter Callable) and returns a DeferHolder<Callable> instance.
* [&]()->void { /*code here*/ }; is C++ syntax for a lambda function that captures any variables it uses by address (that's the [&] bit), takes no parameters (that's the () bit) and returns nothing (that's the ->void bit). The code goes in braces.
* DeferHolder calls the function it holds when it is destroyed.
It's subjective but some (including me!) would say it's cursed because it's using a macro to make something that almost looks like C++ syntax but isn't quite. I'm pretty confident with C++ but I had no idea what was going on at first (except, "surely this is using macros somehow ... right?"). [Edit: After some thought, I think the most confusing aspect is that defer->void looks like a method call through an object pointer rather than a trailing return type.]
I'd say it would be better to just be honest about its macroness, and also just do the extra typing of the [&] each time so the syntax of the lambda is all together. (You could then also simplify the implementation.) You end up with something like this:
DEFER([&]()->void { CoUninitialize(); });
DEFER({ CoUninitialize(); });But from my understanding (or lack thereof), the `auto _defer_instance_1234 =` is never referenced post construction. Why doesn't the compiler immediately detect that this object is unused and thus optimize away the object as soon as possible? Is it always guaranteed that the destructor gets called only after the current scope exits?
Yes, exactly. The destructor is allowed to have some visible side effect such as closing a file handle or unlocking a mutex that could violate the assumption of the code in that block. (Even just freeing some memory could be an issue for code in the block.) It is guaranteed that the destructor is closed at the end of the block, and that all the destructors called in that way happen in reverse order to the order of their corresponding constructors.
Is there any reason to use operator% instead of a normal method call? Except possibly looking cool, which doesn't seem useful given that the call is hidden away in a macro anyway.
If you don't mind that, I said that you can "simplify the implementation" - what I meant was, as you say, you don't need the overloaded Defer::operator% (or indeed the Defer class at all). Instead you could do:
template <typename Callable>
DeferHolder<Callable> _get_defer_holder(Callable&& cb) {
return DeferHolder<Callable>{std::forward<Callable>(cb)};
}
#define DEFER(my_lambda) auto COMMON_CAT(_defer_instance_, __LINE__) = _get_defer_holder(my_lambda)
Would it have looked any less cursed if it just read `defer { CoUninitialize(); };`?
Agreed that the simplest "fix" would be to just rename the macro to be all-caps.
Yes, agreed.
> Would it have looked any less cursed if it just read `defer { CoUninitialize(); };`?
It's subjective but personally I still hate it.
> Agreed that the simplest "fix" would be to just rename the macro to be all-caps.
Actually I think the bigger part of my suggestion is switching from an object-like macro to a function-like macro [1], which makes it all a bit less magical.
[1] https://stackoverflow.com/questions/36126687/function-like-m...
I think the "best" approach here would be to make it a function-like macro, and also change the name to all caps.
(Also, I tend to agree that `defer { ... };` is still cursed -- it requires the trailing semicolon, which further breaks the illusion of a keyword that takes a block scope.)
So you can abuse this mechanic to 'register' things to be executed at the end of the current scope, almost no matter how you exit the current scope.
I personally don't find it that cursed, but for many old C++ heads this may be an overwhelming smell - adding a class to implement what should be a language feature may tweak some folks' ideology a bit too far.
I think the only bit I don't like personally is the syntax. I normally implement defer as a macro to keep things clean. If done correctly it can look like a keyword: `defer []{ something(); };`.
Or you could even make a non-macro version (but then you need to think of variable names for each defer):
auto defer_uninitialise = do_defer([](){CoUninitialize();}); #define defer(body) DeferHolder COMMON_CAT(_defer_instance, __LINE__) {([&]()->void body)};
defer({
function body here;
});
scope_exit{[&]{ ... } };D (for example) has the concept of statements that trigger at end of scope built into the language.
TL;DR, not AI
The code defers a function call until the point in time that an object goes out of scope. The implementation uses C macros to create a more succinct syntax that omits parts of the necessary C lambda/unnamed function definition and to create a unique variable name for managing the deferred function call. However, the resulting syntax eschews the common convention of using UPPER CASE to denote C macros, and instead appears similar at first glance to a function call from an object pointer.
This can cause confusion if one is not familiar with this pattern and expects macros to be communicated differently. Some commenters say this is common enough, or useful enough to them, to be considered almost idiomatic in some contexts.
For technical explanation, https://news.ycombinator.com/item?id=43959403#43960905 provides a useful breakdown of how the macro works.