Re: template instantations

[Jaroslav Hajek]

On Thu, Nov 13, 2008 at 4:44 AM, John W. Eaton <address@hidden> wrote:
> I'd like to consider reworking the way we are managing template
> instantiations.
>
> Back when C++ compilers were first starting to handle templates, we
> used to have to instantiate all templates manually.  So that's why
> files like Array-{d,C,b,i,...}.cc, exist in the Octave sources.  With
> modern compilers, I'm not sure that is necessary, or is even the best
> approach.
>
> Should we keep the explicit instantiation files like
> Array-{d,C,b,i,...}?
>
> Should we have both Array.h and Array.cc, or combine them into a
> single file?
>

An interesting doc about instantiating in g++ is here:
http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html

It appears to say that the templates are reinstantiated and recompiled
for each compilation unit including the file (unless you use the g++
"extern template" extension). Maybe that contributes to the slow
compiling of liboctave.

The present approach compiles the non-inline member functions only
once (in Array-*.cc).

Maybe the problem is that Array<T> should not really be used for
"lightweight" arrays, where you don't need the "fat" methods (index,
assign, resize, sort).
Another point is that, IMHO, "sort" should not be part of Array<T> but
rather MArray<T>. Array<T> should only require T to be copyable and
default constructible. MArray<T> requires T to be comparable, so it's
a good place for sort. That way, we could remove the
NO_INSTANTIATE_ARRAY_SORT stuff.

> If we do keep both, maybe we should follow the lead of the GNU
> libstdc++ files and rename the .cc file .tcc, since it is not a normal
> source file, but a set of templates.  Also, the libstdc++ sources use
> (for example)
>
>  #ifndef _GLIBCXX_EXPORT_TEMPLATE
>  # include <bits/basic_string.tcc>
>  #endif
>
> so I think the basic_string.tcc file is normally included in the
> <string> header file.
>

A good suggestion.

> But some of these files like the Array.{h,cc} combo are fairly large.
> If we merge them so that Array.h contains the entire declaration and
> definition of this large template class, will that slow down
> compilation substantially?

I think so, see above.

>
> To see what changes like this might do, I took a shot at eliminating
> the files {u,}int{8,16,32,64}NDArray.cc and merging the intNDArray.cc
> file into the existing intNDArray.h header file.  I'm attaching the
> diffs below.  With these changes, all information about the
> intNDArray<T> type is in the single header file.  It is now 859 lines
> long.
>
> So, does anyone object to these changes?
>

Since intNDArray is only a thin wrapper over Array<octave_int<T> >, I
think it's OK.
Personally, I'd like to see more code formed the way intNDArray is.
For instance, having a single "Matrix" template class (say, MatrixT),
and only typedefing MatrixT<double> to Matrix, MatrixT<float> to
FloatMatrix etc. would simplify writing generic template functions
supposed to work with both (or all four) kinds of matrices.

> Should we try to remove other files that perform explicit
> instantiations?
>

I don't think so.

> Should we try to combine the .h and .cc files that define other
> template classes?
>

Dtto.

> Comments?
>
> Thanks,
>
> jwe



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz