freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [pooma-dev] Explicit Instantiation Question


From: James Crotinger
Subject: RE: [pooma-dev] Explicit Instantiation Question
Date: Thu, 6 Sep 2001 14:32:33 -0600

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:address@hidden]
> 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: address@hidden
> 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
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]