[pooma-dev] Explicit Instantiation Question

James Crotinger JimC at proximation.com
Thu Sep 6 20:32:33 UTC 2001


I've mentioned before that sv is probably not used anywhere and that it was
pretty clearly just added for clarity in the class definition. Is there any
reason not to remove it completely? That is, we currently have something
like (this is a bit old, but I don't think this stuff has changed):

  // Deduce appropriate version of implementation to dispatch to.
  
  static const bool sv = DomainTraits<SDomain_t>::singleValued;
  typedef View1Implementation<Subject_t, SDomain_t, sv> Dispatch_t;

  // The optimized domain combiner.
  
  typedef CombineDomainOpt<NewDomain_t, sv> Combine_t;


This can be changed to the more unwieldly

  // Deduce appropriate version of implementation to dispatch to.
  
  typedef View1Implementation<Subject_t, SDomain_t,
DomainTraits<SDomain_t>::singleValued> Dispatch_t;

  // The optimized domain combiner.
  
  typedef CombineDomainOpt<NewDomain_t,
DomainTraits<SDomain_t>::singleValued> Combine_t;  

Then "sv" won't have to be instantiated at all since it won't exist anymore.
sv is public, but I think that was an oversight - I don't think anyone ever
uses View1<blah>::sv. 

  Jim


> -----Original Message-----
> From: Dave Nystrom [mailto:wdn at lanl.gov]
> Sent: Thursday, September 06, 2001 2:08 PM
> To: pooma-dev
> Subject: [pooma-dev] Explicit Instantiation Question
> 
> 
> Here is another try at sending my email.  I am trying again 
> to speed up our
> compiles because it has been taking way too long on b18, the 
> SGI machine we
> are doing our classified development on.  John and I have 
> made some good
> progress on that by getting shared libraries working on b18 
> and explicitly
> instantiating all the Pooma2 assign functions in a special 
> library package
> that only needs to be rebuilt when we change Pooma 2.
> 
> In the process of doing that, I have revisited the idea of trying to
> explicitly instantiate the Pooma 2 View1 and AltView1 templates.  When
> Jeffrey was looking at the original problem there with View1 
> which had a
> circular dependency which was causing a 
> point-of-instantiation problem, he
> discovered that he could explicitly instantiate the View1 
> template with
> fairly simple template arguments by first explicitly 
> instantiating the Field
> class with those same template arguments.  Then he figured out how to
> explicitly instantiate the View1 class by adding the AltView1 class.
> However, that does not help me because now I have 2000-3000 AltView1
> templates that I need to instantiate.
> 
> So, I tried using Jeffreys original solution which I modified 
> to use with the
> AltView1 template - see the cpp macro 
> INSTANTIATE_VIEW1_AND_FRIENDS below.
> But, the simple View1.cc file below fails to compile when 
> using KCC 4.0f on
> Red Hat 7.1 Linux.  So, I'm wondering if I am doing the right 
> thing in my cpp
> macro - KCC seems to think not.  Also, I'm wondering if I 
> need to explicitly
> instantiate the whole Field class or just 1 or 2 methods of 
> the Field class.
> I think that Jeffrey might be the best person to answer this question
> although others who are intimately familiar with Pooma 2 
> might be able to
> also.
> 
> Bottom line is that I am trying to figure out some way to explicitly
> instantiate the View1 and AltView1 templates without having 
> to remove the
> circular dependency which is causing the 
> point-of-instantiation problem.
> 
> Thanks for any help,
> 
> Dave Nystrom			email: wdn at lanl.gov
> LANL X-3			phone: 505-667-7913	fax: 
> 505-665-3046
> 
> ---------------------------------------Simple View1.cc 
> File-------------------------------------
> #include "Pooma/NewFields.h"
> 
> #define INSTANTIATE_VIEW1_AND_FRIENDS(T1_CPP,T2_CPP,T3_CPP) \
> template class          Field<T1_CPP,T2_CPP,T3_CPP>; \
> template       
> AltView1<Field<T1_CPP,T2_CPP,T3_CPP>,Interval<1> >::sv; \
> template       
> AltView1<Field<T1_CPP,T2_CPP,T3_CPP>,Interval<2> >::sv; \
> template       AltView1<Field<T1_CPP,T2_CPP,T3_CPP>,Interval<3> >::sv;
> 
> #define T1 UniformRectilinear<(int)2, double, Cartesian<(int)2> >
> #define T2 Vector<(int)2, double, Full>
> #define T3 ExpressionTag<BinaryNode<OpAdd, 
> BinaryNode<OpSubtract, BinaryNode<OpMultiply, Scalar<double>, 
> BinaryNode<OpSubtract, BinaryNode<OpAdd, 
> Reference<Field<UniformRectilinear<(int)2, double, 
> Cartesian<(int)2> >, Vector<(int)2, double, Full>, 
> CompressibleBrickView> >, 
> Reference<Field<UniformRectilinear<(int)2, double, 
> Cartesian<(int)2> >, Vector<(int)2, double, Full>, 
> CompressibleBrickView> > >, BinaryNode<OpMultiply, 
> Scalar<int>, Reference<Field<UniformRectilinear<(int)2, 
> double, Cartesian<(int)2> >, Vector<(int)2, double, Full>, 
> CompressibleBrickView> > > > >, BinaryNode<OpMultiply, 
> BinaryNode<OpMultiply, Scalar<double>, 
> Reference<Field<UniformRectilinear<(int)2, double, 
> Cartesian<(int)2> >, Vector<(int)2, double, Full>, 
> CompressibleBrickView> > >, BinaryNode<OpSubtract, 
> Reference<Field<UniformRectilinear<(int)2, double, 
> Cartesian<(int)2> >, Vector<(int)2, double, Full>, 
> CompressibleBrickView> >, 
> Reference<Field<UniformRectilinear<(int)2, double, 
> Cartesian<(int)2> >, !
> Vector<(int)2, double, Full>, CompressibleBrickView> > > > >, 
> Reference<Field<UniformRectilinear<(int)2, double, 
> Cartesian<(int)2> >, Vector<(int)2, double, Full>, 
> CompressibleBrickView> > > >
> INSTANTIATE_VIEW1_AND_FRIENDS(T1,T2,T3)
> #undef T1
> #undef T2
> #undef T3
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/pooma-dev/attachments/20010906/4f31fa49/attachment.html>


More information about the pooma-dev mailing list