[Top][All Lists]
[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.