H. S. Teoh 
| On Sat, Aug 24, 2013 at 01:01:12PM +0200, Artur Skawina wrote:
> On 08/24/13 08:30, Piotr Szturmaj wrote:
> > H. S. Teoh wrote:
> >> I've written up a proposal to solve the partially-constructed object problem[*] in D in a very nice way by extending scope guards:
> >>
> >> http://wiki.dlang.org/DIP44
>
> > 2. allow referring to local variables and create the closure. This causes additional memory allocation and also reference to the closure must be stored somewhere, perhaps in the class hidden field. Of course, this is a "no go", I'm writing this here for comparison.
>
> That is what he's actually proposing. And, yes, it's not a good idea. Implementing it via runtime delegates, implicit captures/allocs and extra hidden fields inside aggregates would work, but the cost is too high. It's also not much of an improvement over manually registering and calling the delegates. Defining what happens when a ctor fails would be a good idea, having a cleanup method which defaults to `~this`, but can be overridden could help too.
The issue with that is that the initialization code and the cleanup code has to be separated, potentially by a lot of unrelated stuff in between. The genius of scope guards is that initialization and cleanup is written in one place even though they actually happen in different places, so it's very unlikely you will forget to cleanup correctly.
> There are other problems with that DIP, like making it harder to see what's actually going on, by splitting the dtor code and having it interleaved with another separate flow.
I think it's unhelpful to conflate scope(this) with dtors. Yes there is
some overlap, but if you treat them separately, then there is no
problem (assuming that a dtor is actually necessary).
> It *is* possible to implement a similar solution without any RT cost,
> but it would need:
> a) flow analysis - to figure out the cleanup order, which might not be
> statically known (these cases have to be disallowed)
> b) a different approach for specifying the cleanup code, so that
> implicit capturing of ctor state doesn't happen and it's not
> necessary to read the complete body of every ctor just to find
> out what a dtor does.
I think that's an unhelpful way of thinking about it. What about we think of it this way: the ctor is acquiring X number of resources, and by wrapping the resource-releasing code in scope(this), we guarantee that these resources will be correctly released. Basically, scope(this) will take care of invoking the release code whenever the object's lifetime is over, whether it's unsuccessful construction, or destruction.
It's just like saying scope guards are useless because it's equivalent to a try-catch block anyway (and in fact, that's how the front end implements scope guards). One may even argue scope guards are bad because the cleanup code is sprinkled everywhere rather than collected in one place. But it's not really about whether it's equivalent to another language construct; it's about better code maintainability. Separating the code that initializes something from the code that cleans up something makes it harder to maintain, and more error-prone (e.g. initialize 9 things, forget to clean up one of them). Keeping them together in the same place makes code correctness clearer.
On Sat, Aug 24, 2013 at 02:48:53PM +0200, Tobias Pankrath wrote: [...]
> Couldn't this problem be solved by using RAII and destructors? You would (only) need to make sure that every member is either correctly initialised or T.init.
How would you use RAII to solve this problem? If I have a class:
class C {
Resource1 res1;
Resource2 res2;
Resource3 res3;
this() {
...
}
}
How would you write the ctor with RAII such that if it successfully inits res1 and res2, but throws before it inits res3, then only res1 and res2 will be cleaned up?
On Sat, Aug 24, 2013 at 09:31:52PM +0400, Dmitry Olshansky wrote: [...]
> Instead of introducing extra mess into an already tricky ctor/dtor situation. (Just peek at past issues with dtors not being called, being called at wrong time, etc.)
>
> I'd say just go RAII in bits and pieces. Unlike scope, there it works just fine as it has the right kind of lifetime from the get go. In function scope (where scope(exit/success/failure) shines) RAII actually sucks as it may prolong the object lifetime I you are not careful to tightly wrap it into { }.
>
> Start with this:
>
> class C {
> Resource1 res1;
> Resource2 res2;
> Resource3 res3;
>
> this() {
> res1 = acquireResource!1();
> res2 = acquireResource!2();
> res3 = acquireResource!3();
> }
>
> ~this() {
> res3.release();
> res2.release();
> res1.release();
> }
> }
>
> Write a helper once:
>
> struct Handler(alias acquire, alias release)
> {
> alias Resource = typeof(acquire());
> Resource resource;
> this(int dummy) //OMG when 0-argument ctor becomes usable?
> {
> resource = acquire();
> }
>
> static auto acquire()
> {
> return Handler(0); //ditto
> }
>
> ~this()
> {
> release(resource);
> }
> alias this resource;
> }
>
>
> Then:
>
> class C{
> Handler!(acquireResource!1, (r){ r.release(); }) res1;
> Handler!(acquireResource!2, (r){ r.release(); }) res2;
> Handler!(acquireResource!3, (r){ r.release(); }) res3;
> this(){
> res1 = typeof(res1).acquire();
> res2 = typeof(res2).acquire();
> res3 = typeof(res3).acquire();
> }
> }
I don't see how code solves the problem. Suppose this() throws an Exception after res1 and res2 have been initialized, but before res3 is uninitialized. Now what? How would the language know to only clean up res1 and res2, but not res3? How would the language know to only invoke the dtors of res1 and res2, but not res3?
On Sat, Aug 24, 2013 at 12:27:37PM -0700, Walter Bright wrote: [...]
> Not a bad idea, but it has some issues:
>
> 1. scope(failure) takes care of most of it already
>
> 2. I'm not sure this is a problem that needs solving, as the DIP points out, these issues are already easily dealt with. We should be conservative about adding more syntax.
>
> 3. What if the destructor needs to do more than just unwind the transactions? Where does that code fit in?
I think it's unhelpful to conflate scope(this) with dtors. They are
related, but -- and I guess I was a bit too strong about saying dtors
are redundant -- if we allow both, then scope(this) can be reserved for
transactions, and you can still put code in ~this() to do non-trivial
cleanups.
> 4. The worst issue is the DIP assumes there is only one constructor, from which the destructor is inferred. What if there is more than one constructor?
This is not a problem. If there is more than one constructor, then only those scope(this) statements in the ctor that were actually encountered will trigger when the object reaches the end of its lifetime. You already have to do this anyway, since if the ctor throws an Exception before completely constructing the object, only those scope(this) statements that have been encountered up to that point will be triggered, not all of them. Otherwise, you'd still have the partially-initialized object problem.
T
--
Without geometry, life would be pointless. -- VS
|
Permalink
Reply
