[pooma-dev] CompressibleBrickView's makeOwnCopy

[James Crotinger]

The change looks fine. 

I'm generally against leaving functions in with { PAssert(false); } as their
bodies. To me this indicates that we don't have the abstractions right. If
preinstantiation were a requirement I might feel differently, but I don't
think preinstantiation of Field probably buys you all that much. Indeed,
there is no Field.cpp, so everything in Field is inline, so there is nothing
to preinstantiate. 

Of course, this is also true for View1 - what exactly happens when you
"preinstantiate" a class that has no non-inline functions? Doesn't the
compiler still have to compile these functions in every file that uses them?
I'm confused. 

	Jim

> -----Original Message-----

> OK to commit the following patch to eliminate CompressibleBrickView's
> makeOwnCopy()?  Will the resulting code still solve Dave Nystrom's
> makeOwnCopy() problem?
> 
> 2001-05-15  Jeffrey D. Oldham  <oldham at codesourcery.com>
> 
>         * Engine/CompressibleBrick.cpp
>         (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): 
> Remove this
> 	incorrectly introduced function.
>         * Engine/CompressibleBrick.h
> 	(Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): Likewise.
> 
> Tested on	sequential Linux gcc 3.0 by compiling library
> Approved by	???Jim Crotinger???
> 
> Thanks,
> Jeffrey D. Oldham
> oldham at codesourcery.com
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010515/9101e3af/attachment.html>