The first problem that comes to mind is that you're executing arbitrary code inside a destructor. If that code throws an exception during stack unwind then your program could turn into a big puddle of goo.
Did not even think about that as exceptions are not relevant for me. Exceptions are usually disabled in my projects (well, depends) - currently writing a system driver for some personal stuff. Exceptions are completely and utterly useless there:
* memory allocation cannot throw exceptions.
* all inputs must be validated all error conditions must be checked etc.
* there are no meaningful c++ exceptions.
* ... leaving only inherently unrecoverable exceptions via SEH (just catch the exception via first chance handler and try to teardown the driver - is the only sane thing i can do).
... but the point is valid. Speaking of which:
that would actually be what i am most interested in. I am wary of using questionable new stuff i have come up with ... debugging bluescreens is not fun (especially as i do not have kernel debugging capabilities right now - it is just not worth it).
Without commenting on the potential technical pitfalls of your implementation...
Neither am i, to be honest - "There be dragons".
The only "advantage" your approach has is that lets you execute an arbitrary block of code defined at the scope's point in the source code. I'm not actually sure that's a good thing, though:
"It suggests to me that the abstraction you are working with is poor; that the objects in question don't have properly written destructors or related cleanup semantics"
If it would be correct/convenient to use destructors of related objects - i would do that. My interest for "defer" came from run-once initialization functions where there were no meaningful objects for encapsulation. Nor convenient or meaningful ways to compartmentalize in functions ... which reminding me Go for an alternative.
PS. Do not confuse "interest" with "burning need" here - in case i am not being clear. The wast majority of time destructors/constructions/std-helpers are correct and/or convenient.
"It implies you have to violate the general recommendation to declare variables as close to their first use as possible in C++, if you want those variables to subject to the cleanup code that the "defer" mechanism provides, making for potentially sloppier code."
Sorry, could you rephrase that? I think i hit a language barrier (my English is actually fairly poor) - however many times i read it, i just can not follow.
"I think it hurts readability to put code outside it's execution order like that"
One of my golden rules: a system should try to prevent accidental mistakes and not intentional ones (without a bloody good and clear reason). One can easily write some unbelievably unreadable spaghetti using whatever language construct - or improve readability when using the same construct sensibly. So: yes and no. Blame the user and not the system.
"and I certainly find the macro hackery to introduce a new "syntax element" offensive."
Interesting. Is it because of macro usage in principle or because there is some legitimate problem with the macro (ie. opportunity for likely accidental mistakes)?
I agree. It is quite similar to try/finally, but not interchangeable from readability/use standpoint ("finally" block is not necessarily related to what is immediately before "try", whereas that is the only sane option for "defer" - ie. "defer" keeps the closely related code together).
I can't really see a great use-case for this that isn't about cleanup code.
You are being facetious. Or at least seem to.
You have seen it before. Anything that wraps a resource and destroys it when the wrapping object goes out of scope is effectively doing the same thing.
Which bit are you amazed by? Destructors? Function pointers?
One once said that "Whiles, procedures and case structures are mental masturbation. They're all compiled to a bunch of goto's anyway."
What i am talking about, as i said, is "defer" as in http://golangtutorials.blogspot.com/2011/06/control-structures-go-defer-statement.html in C++, wondering about its usefulness and most importantly - does it break somewhere? ie. Arbitrary finalization code without needing a special separately described object for the occasion and keeping the one-of closely related code together.
C++ does not have any comparable language construct (closest match would be try/finally [non-standard] and, less so, RAII). My facsimile seems to fit the bill.