Peter Vanroose <Peter.Vanroose@...> writes:
> Ian Scott wrote:
> > It was not intended that (at least for code entering VXL core) that there
> > would be many functions taking vil2_image_view_base as arguments.
> Well, I find it an interesting argument type since it avoids the use of
> templated functions.
> E.g., all "vepl2" functions are using vil2_image_view_base as argument type.
I would guess that this is the most convenient type for vepl2, since
vipl probably had a number of if statements to check the type
anyway. (But I don't know for sure.)
However, I'm inclined to agree with Ian and Tim that code in vil2
should only have vil_image_view<T> parameters, except in exceptional
circumstances. This way, none of the routines ever need to have
type-based branch in them. Therefore, you can confidently call other
routines and be sure that the each layer is not repeating the same
type check. (This allows more optimization in theory, but probably
none in practice...)
With the T restricted to scalar types, there are realistically only 6
types that need to be instantiated. And the way it is written now,
with the inclusion model for templates, only those that the user
actually uses will be instantiated. In most cases, that would be one
There is a cost in the template processing, but I'll argue not that
much, and that the benefits out-weigh the cost. And compilers are
getting better and better at supporting templates. Already, Comeau
supports export templates, which I believe will help a lot in our
situation; Sun Workshop and Forte compilers support template
repository based instantiation, which will also help. (Provided we can
upgrade our configure script to handle this. But that's another
issue.) I think the state-of-the-art now is quite different from that
in 2000, when vxl was first written. (Or maybe not. :) ) We aren't
using the compiler as a computational engine. Our uses of templates
are fairly simple, similar to that of the standard library. We don't
try to do what some of the more esoteric Boost libraries try to do. I
think most compilers are able to cope with our simple template usage.
Having a unifrom interface also sends a clear message to the users on
what should be used. This especially important for new users, who may
not yet have grasped the subtleties in using a untyped data set. This
is vital in terms of getting new users acclimatized to research
environments that use vxl.