RE: [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  <address@hidden>
>
>         * 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
> address@hidden
>