[pooma-dev] CompressibleBrickView's makeOwnCopy

Tue May 15 21:04:22 UTC 2001

I'd just like to make it clear that I am not trying to instantiate the View1
class.  Instead, I am only trying to explicitly instantiate what the
prelinker does which is:

View1<Field<T1, T2, T3>, T4>::sv

For our source code base, the prelinker discovers 1800-2000 combinations of
these template parameters.  Also, on a source code base like ours, to get a
significant reduction in compile time through explicit instantiation, you
have to reduce the number of translation units that the prelinker is
recompiling.  If the prelinker chooses to assign even one template to a given 
translation unit, it will be recompiled.  So, it takes some tedious work to
benefit from explicit instantiation on a source code base like ours but it
does pay off based on my experience with doing this on the r1 version of our
code.

I'm not totally sure just what compilers do regarding template instantiation
of non-inline functions.  I've communicated with Arch Robison some about this 
regarding KCC.  I think this is what happens with KCC.  If you are doing a
debug compile then nothing is inlined but every function that would have been 
inlined is given internal linkage in any translation unit which references
it.  But I'm not sure what this implies if you explicitly instantiate a class 
containing these methods.  Maybe Mark could comment on this - or maybe every
compiler has there own solution.

Dave

James Crotinger writes:
 > 
 > 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
 > > 
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
 > <TITLE>RE: [pooma-dev] CompressibleBrickView's makeOwnCopy</TITLE>
 > </HEAD>
 > <BODY>
 > <BR>
 > 
 > <P><FONT SIZE=2>The change looks fine. </FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>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. </FONT></P>
 > 
 > <P><FONT SIZE=2>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. </FONT></P>
 > 
 > <P>        <FONT SIZE=2>Jim</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>> -----Original Message-----</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>> OK to commit the following patch to eliminate CompressibleBrickView's</FONT>
 > <BR><FONT SIZE=2>> makeOwnCopy()?  Will the resulting code still solve Dave Nystrom's</FONT>
 > <BR><FONT SIZE=2>> makeOwnCopy() problem?</FONT>
 > <BR><FONT SIZE=2>> </FONT>
 > <BR><FONT SIZE=2>> 2001-05-15  Jeffrey D. Oldham  <oldham at codesourcery.com></FONT>
 > <BR><FONT SIZE=2>> </FONT>
 > <BR><FONT SIZE=2>>         * Engine/CompressibleBrick.cpp</FONT>
 > <BR><FONT SIZE=2>>         (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): </FONT>
 > <BR><FONT SIZE=2>> Remove this</FONT>
 > <BR><FONT SIZE=2>>       incorrectly introduced function.</FONT>
 > <BR><FONT SIZE=2>>         * Engine/CompressibleBrick.h</FONT>
 > <BR><FONT SIZE=2>>       (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): Likewise.</FONT>
 > <BR><FONT SIZE=2>> </FONT>
 > <BR><FONT SIZE=2>> Tested on     sequential Linux gcc 3.0 by compiling library</FONT>
 > <BR><FONT SIZE=2>> Approved by   ???Jim Crotinger???</FONT>
 > <BR><FONT SIZE=2>> </FONT>
 > <BR><FONT SIZE=2>> Thanks,</FONT>
 > <BR><FONT SIZE=2>> Jeffrey D. Oldham</FONT>
 > <BR><FONT SIZE=2>> oldham at codesourcery.com</FONT>
 > <BR><FONT SIZE=2>> </FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>

-- 
Dave Nystrom			email: wdn at lanl.gov
LANL X-3			phone: 505-667-7913	fax: 505-665-3046