RE: [pooma-dev] Strange initialization code for Particle layouts

[Julian C. Cummings]

Hi Richard,

I don't really keep up with Pooma maintenance issues anymore, but I guess I
should comment as one of the Pooma Particles developers of long ago.  You
are correct that the layout_m member is there only for convenience, so that
you don't have to cast the this pointer repeatedly.  It is fewer keystrokes
to use the layout_m reference instead, but your changes should do no harm.
The code comment below is inaccurate.  It should say that you need to call
the initialize() method if you use the default constructor.  A valid
SpatialLayout for Particles requires FieldLayout and Geometry objects.

I believe your conversion of Geometry::indexPoint() to
Mesh::vertexPosition() is right.  I never fully implemented the
Particle-Field interpolation routines for the new Field class definition
provided in Pooma 2.4 because I was not certain how to handle the issues of
run-time selection of Field centering and "mixed" Field centerings that are
not simple cell or vertex centerings.  With the wider selection of possible
Field centerings, a very general Particle-Field interpolation scheme (and
even management of the SpatialLayout itself) becomes quite complicated.

Regards, Julian C.


> -----Original Message-----
> From: Richard Guenther [mailto:address@hidden 
> Sent: Sunday, July 11, 2004 8:50 AM
> To: address@hidden
> Subject: [pooma-dev] Strange initialization code for Particle layouts
> 
> 
> Hi!
> 
> There is some strange code in the particle layout initializations:
> 
> template <class M, class FL>
> class SpatialLayout
>    : public PatchSwapLayout< SpatialLayout<M,FL> >
> {
> public:
> [...]
>    // Default constructor.  Initialize with assignment operator.
> 
>    SpatialLayout()
>      : Base_t(*this)
>      {}
> 
> 
> what is this idiom Base(*this) supposed to do!?  
> PatchSwapLayout doesn't 
> define an assignment operator, so the comment doesn't make any sense. 
> It looks like this initialization provokes undefined behavior 
> and such 
> can be dropped in favor of default-construction (which the 
> PatchSwapLayout doesn't define)?  I'm confused, so maybe 
> someone could 
> shed a light on me here.  I guess the layout_m member of 
> PatchSwapLayout 
> could be implemented as static_cast<Layout_t>(*this) rather 
> than playing 
> this "trick"?
> 
> Thanks,
> Richard.
>