Re: [Vxl-maintainers] vil_convert_cast() deprecated

[Amitha P. <pe...@cs...>]

Ian Scott wrote:
> The "wierd"ness is used elsewhere in vil_convert,

I didn't see any weirdness in any of the other functions. They all
boil down to a vil_transform2, which which never return a
self-reference.

> so I think it may be a
> good idea to replace all the non-sptr-based functions as well:
> 
> void vil_convert_XXX(const vil_image_view<S> &src,
>                      vil_image_view<T> &dest);
> changes to
> vil_image_view<T> vil_convert_XXX(T dummy,
>                                   const vil_image_view<S> &src);
> 
> There may some small cost with the extra assign, but it can probably be
> optimised away.

I agree. The one situation where this approach fails is if (1) we
need a conversion for sure, (2) we have a destination buffer of the
correct dimensions, and (3) we must use that buffer for the output. In
this case, the "functional" form above requires an additional copy:

    vil_image_view<DT> tmp = vil_convert_XXX( src )
    vil_copy_deep( tmp, dest )

I think this is rare enough that it's not worth handling. Avoiding the
issue also means that we don't have to worry about whether that should
be vil_copy_deep or vil_copy_reformat.

> > > Your description of behaviour that does let the destination view
> > > point somewhere else unless the size changes sounds ideal.

This doesn't arise in the "pure functional" approach to conversion.


> What for all of vxl? or even all of vil.

I'm thinking all vxl.

> I think that would be expensive in
> space

I'm not so sure. With static libraries, the executable can't get any
bigger, since any reasonable linker will munge any duplicate
instantiations. With shared libraries, there is potential for
explosion. However, I'm fairly confident that only having to
instantiate the functions that are used would mean that the increase
would be limited.


> but some bits of code it would be a lot faster, for example the
> vil_convolve_1d code gains significant optimisation by being able to do
> constant propagation on the size of the kernel. Inlining is also useful
> where the number of template parameters is large. I think that much of the
> code that could benefit from inlining and constant propagation is already
> written that way.

Inlining and implicit instantiation are related by orthogonal
concepts.

> > BTW, which compiler requires that template functions with implicit
> > instantiation be inlined?
> 
> I thought all did. Or at least they need to be declared static, so that
> there are not multiple identical symbols at link time.

Not as far as I know. The compiler is meant to determine that these
are templates, and resolve the issue appropriately. Templates cannot
be static. They must have external linkage.

Amitha.