<html>
Hi Folks-<br>
<br>
Luis has sent a message pointing to VIGRA (generic programming image
system), and I followed up with some questions to the developer Ullrich
Koethe. I think the dialog is informative.<br>
<br>
Will<br>
---------<br>
<br>
<blockquote type=cite cite>Hi Ullrich -<br>
<br>
My name is Will Schroeder, I'm working with a group of folks developing a
segmentation and registration toolkit for the National Library of
Medicine in the US. We are in the design stage, and have been struggling
with architectural issues, mainly where to draw the line between run-time
and compile-time binding.<br>
<br>
My prior experience is with the open-source Visualization Toolkit (VTK
<a href="http://www.kitware.com/vtk.html" eudora="autourl">www.kitware.com/vtk.html</a>)
which leans towards run-time binding and a very conservative C++ design
(single inheritance, limited use of templates, etc.). Part of the reason
for this is that we wrap the C++ library with interpreted languages like
Tcl, Python, and Java. VTK is successful, it's a huge system and runs
everywhere, and people seem to be able to learn and use it pretty
well.<br>
<br>
Some of the folks on the team have been encouraging us to go the generic
programming route. We've been exploring and stumbled across the Vigra
code. While I think this technology is promising, I'm concerned about the
possible problems introduced such as code bloat, compiler difficulties,
unreadable code, proliferation of classes, lack of run-time flexibility,
etc. Part of my concern is that this toolkit has the potential to grow to
1000 classes and 250,000 lines of executable code. So it's code tha must
be usable in production, not just in the academic sense.<br>
<br>
Can you point me to any articles that discuss these issues, or do you
have any experience that you can share along these lines? I'm interested
in hearing both sides of the story. I have downloaded <i>Reusable
Software in Computer Vision</i> and will look at it today.<br>
<br>
Thank you,<br>
Will</blockquote><br>
<br>
<br>
<blockquote type=cite cite>Sender:
koethe@kogs.informatik.uni-hamburg.de<br>
Date: Fri, 25 Feb 2000 17:03:16 +0100<br>
From: Ullrich Koethe <koethe@informatik.uni-hamburg.de><br>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)<br>
X-Accept-Language: en<br>
To: Will Schroeder <will.schroeder@kitware.com><br>
Subject: Re: Could you share your experience...<br>
X-MIME-Autoconverted: from 8bit to quoted-printable by
kogs1.informatik.uni-hamburg.de id RAA02857<br>
<br>
Hi Will,<br>
<br>
this is a very interesting question indeed! As it happens I'm hoping
to<br>
get a PhD for my answer next Tuesday. <br>
<br>
Basically, i think you need both: generic programming to get
flexibility<br>
at the low-level (functions and data structures), and <br>
object-orientation for run-time flexibility.<br>
<br>
In comparison to e.g. computer graphics, image analysis is a much
less<br>
mature field (inverse problems are always much harder). So, there is
no<br>
set of standard algorithms that work most of the time (some people
claim<br>
otherwise, but don't be fooled). Instead, we keep changing all kinds
of<br>
details as circumstances (i.e. the images to be processed) and<br>
understanding evolve. These changes occur at a relatively
low-level:<br>
exchange float for byte, replace a particular formula for second<br>
derivatives by another one and the like. <br>
<br>
Using virtual functions (and perhaps dynamic_cast) to cope with
this<br>
kind of changes will result in a very inefficient system. You can't<br>
simply do a dynamic cast for each pixel, i.e. 1 million times a
second.<br>
Compile-time techniques are much more appropriate here. In
addition,<br>
generic programming gives you some techniques that are not present
in<br>
the OO part of C++:<br>
<br>
- code generation upon necessity<br>
- multiple polymorphism with powerful pattern matching (by partial<br>
ordering <br>
of overloaded functions and function templates)<br>
- meta classes (traits)<br>
<br>
So I use generic programming to write the real 'work horse<br>
functionality'. (Some of the related ideas are described in my
paper.)<br>
<br>
Now, to get runtime flexibility, I build a larger pieces of<br>
functionality from the generic building blocks and wrap them into<br>
objects. These objects are then exported to Python. So I have both:
I<br>
can change alsogrithmis details in the generic layer and
collaboration<br>
of modules in the OO layer.<br>
<br>
When implementing this in C++, some care is required to manage
compile<br>
dependencies. Since templates are usually kept in header files,<br>
visibility of these headers must be controlled. (Otherwise, a
simple<br>
implementation change could cause a huge recompile). This is part of
the<br>
benefit of wrapping genericity into objects. (Hopefully, this
situation<br>
will change when compilers start to support separate compilation
for<br>
templates).<br>
<br>
As to the choice of compiler: if your your goal is maximum
portability,<br>
you might be better of not using generic programming. However, since
the<br>
standard library depends on it, compilers are quickly catching up.
Also,<br>
one can use a subset of techniques that retains most of the benefits
and<br>
runs on most compilers. I've successfully used GNU g++, the SGI
native<br>
compiler and Microsoft Visual C++ (with some limitations). <br>
<br>
Code bloat is a problem that I havn't gone into very much (which
means<br>
it wasn't so severe as to cause trouble). Often, the main reason
for<br>
code bloat are long template names which can easily be stripped off
the<br>
final executable (on SGI, this sometimes reduces code size to 50%).<br>
<br>
I hope this helps. Please ask again if any question remain<br>
<br>
Regards<br>
Ulli<br>
-- <br>
________________________________________________________________<br>
|
|<br>
| Ullrich Koethe Universität Hamburg / University of
Hamburg |<br>
|
FB Informatik / Dept. of Computer Science
|<br>
|
AB Kognitive Systeme / Cognitive Systems Group |<br>
|
|<br>
| Phone: +49 (0)40
42883-2573
Vogt-Koelln-Str. 30 |<br>
| Fax: +49 (0)40
42883-2572
D - 22527 Hamburg |<br>
| Email:
u.koethe@computer.org
Germany
|<br>
|
koethe@informatik.uni-hamburg.de
|<br>
| WWW:
<a href="http://kogs-www.informatik.uni-hamburg.de/~koethe/%A0%A0%A0%A0%A0" eudora="autourl">http://kogs-www.informatik.uni-hamburg.de/~koethe/
</a> |<br>
|________________________________________________________________|
</blockquote></html>