Re: [pooma-dev] Compile Time Problems and Pooma 2

[Dave Nystrom]

Scott Haney writes:
Hi Scott,

Thanks for your response.  I think I have many problems as my last few emails
have indicated.  But I guess you are addressing the explicit instantiation
problem.  One point that needs to be clarified is that I have no scripts to
do the explicit instantiations that I am performing.  Instead, I am taking
the output of the KCC prelinker and massaging that using XEmacs keyboard
macros to generate my explicit instantiation requests.  I think that at some
point when things stabilize it would be good to write some scripts that could
facilitate this process.  I'm not sure I'm the best person to do this - Lee
Ankeny comes to mind as someone who is much more fluent with Perl than I am
and who could do this job faster.  I'd be willing to do this someday if I
can't get someone else to volunteer though.  However, my experience so far
using the XEmacs keyboard macro approach is that it may not be very easy to
write a robust script to take care of all the explicit instantiation stuff.
I often run into details in this process which require decisions to be made
that might be difficult to code into a script and cover all the possible
cases.  So, I don't think it is worth the time to invest in scripts right
now.  So, now it should be clear that I don't have a tool that I can make
smarter.

What I hear you saying is that you don't think you can guarantee that Pooma 2 
can be written in a way that guarantees no circular dependencies.  Is that
really true?  I've read books that claim that circular dependencies are bad
and indicate deficiencies in the software design.  And I confess that I tend
to believe them.  But I am not sufficiently proficient at C++ software design 
to make any kind of absolute statements on this topic and as I have indicated 
I do not know enough about the details of Pooma 2 to really know what you
guys are up against when it comes to trying to meet your design goals for
Pooma 2.  But, I thought that you solved a similar type of problem with the
Array class.  Did Jeffrey take the same approach that you did with the Array
class or is his solution somewhat different?  I did not follow his solution
very closely - I was just hoping that you guys would know how to fix the
problem and I could then update my Pooma 2 and continue on with the explicit
instantiation stuff.

You suggest that I should be able to accomplish what I want by making sure
that I first instantiate some stuff from Field before instantiating the
AltView1 stuff.  This did occur to me a few days ago but I have not thought
seriously about it.  First let me say that I don't really think the AltView1
stuff fixes anything from my perspective and that if I have do deal with this 
order dependent instantiation because of circular dependencies, I'd rather
just deal with it for View1 and get rid of AltView1.  Here is where I see a
potential complication in your suggested solution.  If I want to instantiate
View1<Field<T1,T2,T3>,T4> you are suggesting I do this as follows:

template class Field<T1,T2,T3>;
template class View1<Field<T1,T2,T3>,T4>;

or at least something similar.  For this to work, I would need to collect all 
the cases where T4 is different but T1, T2 and T3 are the same and group them 
all together because I can't have multiple instantiation requests for
Field<T1,T2,T3> in the same translation unit and really don't want to across
different translation units because of multiple symbol definition linker
warnings.  I think that greatly complicates my task - in fact I'm not sure it 
would be very feasible at all using XEmacs and keyboard macros.  I'd probably 
be forced to write a script and I really don't have time to do that now and I 
don't think it would be a simple script.  I think it is unmanageble to do
this sort of custom processing with XEmacs because of the huge number of
View1 templates - over 1800 last time I counted.

So, what do you propose?  I had not really thought it unreasonable for me to
be able to explicitly instantiate anything that the compiler could
instantiate - it seemed to work with Pooma 1.  But maybe I just don't
understand what you guys are up against.  I view the View1 template
instantiation problem as somewhat of a special case because of the huge
number of templates involved.  I would certainly be willing to jump through
some special hoops like you suggest in order to deal with a much smaller
number of templates.  But I am reluctant to believe this is feasible or a
good plan when we are already talking about 1800+ templates and the prospect
of this number growing much larger as our team contiues to add more source
code.

Well, I'm not sure what the solution is.  Maybe we can come to some sort of
solution if we continue to think about this.  Hope this helps clarify things
some from my perspective.

-- 
Dave Nystrom                    email: address@hidden
LANL X-3                        phone: 505-667-7913     fax: 505-665-3046

 > The root problem is that you want to blindly take the output from KCC 
 > and use that to guide pre-instantiation. This is certainly the easiest 
 > thing from your perspective, but it presents an almost insurmountable 
 > problem from our perspective in that we have to guarantee that every 
 > template can be instantiated in any possible order. I don't think we can 
 > do this in all cases. This means that your tool needs to get slightly 
 > smarter to handle the small set of exceptions where order does matter. 
 > For the case you're describing, you need to pre-instantiate some stuff 
 > from Field before you hit AltView1, etc. I expect that the number of 
 > exceptions is quite small and could easily be added to your scripts.
 > 
 > Scott
 > 
 > 
 > On Tuesday, May 29, 2001, at 11:53 AM, Dave Nystrom wrote:
 > 
 > >> Also, I tried out Jeffrey's fixes to allow instantiation of the View1 
 > >> class
 > >> and have some comments.  It appears that I can now instantiate the 
 > >> View1
 > >> class but now I find that I have about 1000 AltView1 templates that I 
 > >> am
 > >> unable to instantiate.  Perhaps we need a new AltAltView1 class:-).  
 > >> Well,
 > >> seriously, this fix is not solving the root problem which I have which 
 > >> is
 > >> that I need to be able to explicitly instantiate anything that the 
 > >> compiler
 > >> is able to instantiate so that I don't have to depend on the prelinker
 > >> recompiling files.  Also, I tried the following template instantiation
 > >> request which did not work.
 >