🚀 go-pugleaf

Hi,
Robert Buren (erarobu@era-t.ericsson.se) wrote:
: John Max Skaller wrote:
: > 
: >   For example, how would you do a graphics library
: > after seeing STL? [The same way STL is done]. How about
: > doing a matrix library with optimisation opportunities
: > for parallel execution? [The same way as STL]
: 
: Could you give just a tiny example of what you mean here?
: I think STL is great, but I feel that I can still only imagine
: STL as a set of container utilities. How would you make an
: STL-like graphics library?

I'm not that much concerned with graphic rather with graphs (I'm
currently constructing a [small] "STL-like" algorithm library for flow
problems). Thus the example my not be a real abstraction for
graphics... Apart from this, it would take far to long to explain the
details I have in mind while writing the scetch below.

The main part is something like identifying the common and essential
properties of the objects manipulated (viewed from the algorithms). In
case of a graphics library this could be something like a "screen": The
screens of the graphics library becomes what are the containers in the
current STL. The screens may differ in how the coordinates are
represented, how lines are drawn, and how drawing style (color, line
width, etc.) are choosen: The algorithms are not interested at these
details at all. To make such a screen useful some sort of accessor
objects are used e.g. something like a "LOGO-turtle": A turtle has a
current position and a direction it is looking. It can turn and it can
move forward in the given direction. A turtle is the equivalent to the
STL iterators. There may be different classes of turtles e.g.  simple
ones which can only move forward on a line (the "input/output
iterators) and others (more complex ones) which can move along a spline
(the random access iterators). However, the "turtles" are the objects
the algorithms work on. Finally, there can be algorithms taking
different turtles which can draw quadrangles, triangles, circles,
characters,... in different variations.

Such a "screen" abstraction together with a set of algorithms can
easily be used to implement output for different devices, e.g.
plotters, postscript-printers, rastered displays, or an in-memory
representation. It may even be used for some application is was
never intended to be used for e.g. moving a roboter.

While the graphics library could be useful I see more chances that
there will be a STL-like matrix library soon: For matrices there could
be a need to have a more precise representation of the values than
'double', the matrix can store 'int's instead of doubles, or some
interval arithmetic may be desirable. In addition the matrices can
easily vary in their representation (columnwise/rowwise,
sparse/full,...).

By identifying the abstraction used by the algorithms these libraries
can become very reusable: You can apply the algorithms to everything
which fullfills some minimal requirements. By indirection (the
iterators in STL) you can even apply algorithms to data structures
which where not designed with the given algorithms in mind!

PS: This discussion seems to become somewhat off-topic: Maybe it should
be moved somewhere else where it fits better than comp.std.c++...
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]