On Fri, Apr 07, 2000 at 08:32:36AM -0400, nbecker@fred.net wrote:
> I have read with interest the discussion of c++ vs. FORTRAN. I am
> personally quite interested in generic programming in c++ for DSP and
> numeric applications. I have been heavily using c++ since the first
> version was released from ATT.
I used C++ in the early days of g++, before templates or exceptions
were included. I liked it then, although it couldn't really do
generic/abstract data types.
> In my opinion we have a serious problem with c++. It is now possible
> to write, for example, a generic matrix package such as MTL. The
> problem is, writing and comprehending this arcane code requires skill
> far beyond even most highly experienced c++ programmers level. It is
> not just that the level is advanced, in the sense of some linear
> progression. It is that the methods needed are absolutely
> nonintuitive. No FORTRAN program ever did anything asked for such
> twisted logic as the magic incantations of MTL's meta-programming.
>
> Generic programming is clearly a prize worthy of pursuit. As it
> currently stands, C++ does not support it. I say that because in it's
> current form, only the few mystic priests can write such code.
I think that there are really two issues that are commonly
intertwined here, particularly with math/matrix libraries.
C++, as it stands, is actually pretty capable of doing fine generic
classes, if you use templates in simple ways. Unfortunately, that's
not what people want out of a matrix library. There are two aspects
that seem to be demanded of a math/matrix library that simply aren't
"object orientation", and should really have their own meta-programming
mechanisms to deal with them. These are expression parsing/re-writing
and type promotion/demotion.
Most of the weirdness in the modern C++ libraries is there to
support the ability to write A = B + C * D, where these are all
matrices of some sort. That's nice, but it's not straight-forward
OO and abstract datatypes, it's syntax, loop-re-ordering and
combining, temporary storage management, temporary scalar type
promotion: lots of things that have traditionally been the
domain of the compiler.
> What we really need is direct support for generic programming with a
> language that is truly capable of representing the concepts in an
> intuitive manner.
Well, there's generic programming, which _is_ supported.
What we seem to want is a run-time meta-programming environment.
At the moment the only support is convoluted macro-style template
expansion. What would be handy, and probably make things much more
understandable, would be a fully procedural, symbol-processing
language that executed at compile time, and could be used as a
genuine compiler-extension mechanism in libraries that needed that
sort of thing.
For a different angle on this argument, have a look at Eiffel,
which has excellent support for generic programming. In fact the
language was designed to make generic programming easy and efficient.
Unlike C++ though, it has _no_ mechanisms to support the sorts of
tricks that the modern template-based matrix libraries pull, and
so you have to compose expressions out of conventional method calls,
subroutine-style.
-- Andrew--------------------- Object Oriented Numerics List -------------------------- * To subscribe/unsubscribe: use the handy web form at http://oonumerics.org/oon/ * If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:12 EST