freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [pooma-dev] [PATCH] Fix Engine<.., MultiPatch<..> >::makeOwnC opy()


From: Richard Guenther
Subject: RE: [pooma-dev] [PATCH] Fix Engine<.., MultiPatch<..> >::makeOwnC opy()
Date: Tue, 22 Apr 2003 20:52:14 +0200 (CEST)

On Tue, 22 Apr 2003, James Crotinger wrote:

> Ah - gotcha. I missed the '-'.
>
> The right thing is to fix makeOwnCopy, of course. This looks like a traits
> problem - the MultiPatchEngine::PatchContainer_t is a RCBPtr of engines, but
> the underlying engines have shallow copy semantics. There is a traits class
> that marks shallow-copy objects appropriately and that can be used to
> implement copy correctly. In ElementProperties.h there is an
> ElementProperties base class called MakeOwnCopyProperties that is set up to
> handle this - what there should be, somewhere, is a specialization:
>
>   template <int Dim, class T, class ETag>
>   template <>
>   struct ElementProperties<Engine<Dim,T,ETag> >
>     : public MakeOwnCopyProperties<Engine<Dim,T,ETag> >
>   { };
>
> What puzzles me is that I see this specialization (a partial one) for Brick
> and several others. So this ought to work for MultiPatch<Brick> and any of
> the other engines that have done this specialization. (It will not work on
> views - we went around on this and ultimately decided that doing makeOwnCopy
> on a view should not be allowed)
>
> Hmmm. I don't see a specialization for Remote<Brick>. (Just saw your
> example.) Is this failing for both Brick and Remote<Brick>? The lack of a

It fails for multipatch engines, both MultiPatch<Tag, Brick> and
MultiPatch<Tag, Remote<Brick> >, it works for Remote<Brick>.

> ElementProperties specialization for Remote<Brick> is a bug. Any class that
> has shallow copy semantics and that implements the makeOwnCopy() function
> should specialize ElementProperties as above.

The problem is, the specialization for ElementProperties for the RCB is
somehow not working correctly. I dont have time to track this down, so I
went the route used in FieldEngine::makeOwnCopy(), do it all manually, and
this solved my problem.

> At any rate, it would probably be good to step through the old code and see
> where it is ending up in the wrong specialization of ElementProperties.
> That's a bug that could bite in other places.
>
> Looks like spotted another bug wrt the dirty flag - that deep copy is needed
> regardless of how the engines are copied.

Yes, indeed.

I'll leave it to Jeffrey, wether to apply this patch or leave the bug in.

Thanks,

Richard.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]