[gecode-users] status of Space* in Branching::copy

[Christian Schulte]

Hmmm, actually the copying is already a two stage process (and a extremly
delicate one). One of the key invariants in the process is that no new
actors (actually, no new anything) can be created during cloning!

It is already now the case that when the constructor Space::Space is
finished, the space is not yet fully initialized, however all data
structures in the newly created space can be inspected (with const member
functions). When moving things around the way you suggest that would not
work aný longer. Some const member functions would be not allowed (as they
just would segfault). I really would like to keep this invariant: everything
can be inspected but nothing can be changed. Even though this only matters
for constructors.

So, the idea to store the data in the space does not look that good after
all. We kind of know what to do but as we have no example we could use to
shape the right abstractions I don't know what to do. If you yourself want
to experiment, we could tell you how to massage the code for copying to hack
around.

Christian

--
Christian Schulte, http://www.imit.kth.se/~schulte/ 

-----Original Message-----
From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
Of Filip Konvicka
Sent: Thursday, September 06, 2007 10:10 AM
To: Guido Tack
Cc: users at gecode.org
Subject: Re: [gecode-users] status of Space* in Branching::copy


Guido Tack (5.9.2007 21:10):
> Filip Konvička wrote:
>
>> one thing that keeps me occupied: when a branching or propagator is 
>> cloned, the space instance it is passed is just partially 
>> constructed. This makes it difficult to make references to any data 
>> inside the space (which is simply not there yet in e.g. 
>> Branching::copy). Is there no other way? I understand that the 
>> branching/propagator cloning takes place in Space copy ctor, but it 
>> would be far more convenient for me to get a fully-constructed space 
>> in Branching::copy. (For example, I'm unable to construct some 
>> non-trivial references to space's data in my branching, as this 
>> initialization can't be moved out of the
>> constructor.)
>
> That's just not possible in the current architecture.  If I understand
> you correctly, you need to make sure that some object is cloned before 
> all actors (propagators & branchings) are. That way, you can be sure 
> that that object is initialized when your Branching::copy is called.  
> I have something like that in a private branch, I'll dig a bit and let 
> you know.
Thanks!

The thing is that the cloning of actors is (my guess) done in 
Space::Space. So say that I have derived my own space class Space2. My 
actors are passed, during cloning, a pointer to the new clone of Space2, 
but since the cloning of the actors is done in Space::Space, the Space2 
object is not fully initialized yet and I can not static_cast it to 
Space2 there.

Note that in the Space2::Space2() constructor (when creating the root 
space), I can make sure that the needed parts of Space2 are already 
constructed before posting the actor. So it came as a surprise to me 
that I got a runtime error in cloning, because things worked just fine 
for the root space. The space I saw being passed to the actor looked 
invalid, and it was not immediately obvious what was happening.

One way that I think this could be handled is cloning in 2 steps: first 
create a copy of the space, then re-create the actors. Since, from the 
user's point of view, a space does not have explicit access to its 
actors (yet :-)), I don't see how this could be a problem (maybe just 
that it should be explicitly prohibited to create actors during 
cloning). The only thing is, who and how would trigger the cloning of 
the actors. Maybe Space::clone() could be "protected" and renamed to 
"getClone", and there could be a public non-virtual

Space* Space::clone() const {
  Space *pClone=getClone();
  pClone->copyActorsFrom(this);
  return pClone;
}

That's many maybes :-) Just wanted to explain what problems I am facing. 
But there are workarounds, so nothing serious.

Otherwise, the library works extremely well, bravo!

Cheers,
Filip


_______________________________________________
Gecode users mailing list
users at gecode.org
https://www.gecode.org/mailman/listinfo/gecode-users