From: Robert F. <ro...@fe...> - 2009-11-18 16:57:10
|
Hi, could anyone perhaps shed some light on a peculiar interface design of certain function templates I found in VIL... There are multiple templates which look like this: template <class outP> inline vil_image_view_base_sptr vil_convert_stretch_range(outP /*dummy*/, const vil_image_view_base_sptr &src) { ... } What is the purpose of the first 'dummy' argument? It is apparently unused, and I find it rather strange that I have to write vil_convert_stretch_range(vxl_uint_32(), view) instead of vil_convert_stretch_range<vxl_uint_32>(view) (in addition to that, the current format produces a temporary value that is _perhaps_ kicked out during optimisation, but that's not guaranteed). It is of course no big deal, but I have absolutely no idea why it is designed like this. My only guess is that this could be an old compiler workaround of some sorts, but I have never seen anything like it. So, could someone please enlighten me? Maybe I am not seeing the wood for the trees... Regards, Robert |
From: Ian S. <ian...@st...> - 2009-11-19 09:08:27
|
If I remember correctly, it is because some compilers used not to consider different template instantiations to be different functions, and would then complain that we had tried to overload on the basis of return type. The only reason now to create new code with this pattern is that, in general, it is easier to create an object of type T if all you have is type T, than to create a type T if all you have is an object of that type. However, a traits pattern would be a more modern way to solve this rare problem. Ian. Robert Fendt wrote: > Hi, > > could anyone perhaps shed some light on a peculiar interface design of certain function templates I found in VIL... > > There are multiple templates which look like this: > > template <class outP> > inline vil_image_view_base_sptr vil_convert_stretch_range(outP /*dummy*/, const vil_image_view_base_sptr &src) > { > ... > } > > What is the purpose of the first 'dummy' argument? It is apparently unused, and I find it rather strange that I have to write > > vil_convert_stretch_range(vxl_uint_32(), view) > > instead of > > vil_convert_stretch_range<vxl_uint_32>(view) > > (in addition to that, the current format produces a temporary value that is _perhaps_ kicked out during optimisation, but that's not guaranteed). It is of course no big deal, but I have absolutely no idea why it is designed like this. My only guess is that this could be an old compiler workaround of some sorts, but I have never seen anything like it. > > So, could someone please enlighten me? Maybe I am not seeing the wood for the trees... > > Regards, > Robert > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users |
From: Ian S. <ian...@st...> - 2009-11-19 10:42:49
|
Robert Fendt wrote: > > I think I found the answer after a bit of archaeological digging. > Pre-ANSI-C++ did simply not support explicit template argument > specification on function templates, thus always relying on automagic > resolution. In other words, code like > > template <typename T> > T foo(); > > was illegal in pre-ANSI-C++, since there was no way to deduce the return > type from an empty argument list. The obvious workaround for this is to > include the return type as a dummy parameter. However, since > standardisation of C++ happened quite a while ago, this should not be an > issue anymore. You might be surprised how recently people were still using VC6 which suffered from this issue, and lacked a great deal of standards support in general. But you are correct - I'll add it to my ToDo List. Feel free to submit a patch if you would like it fixed soon:-) Ian. |