RFC: Using Standard C++ library components in Octave

[John W. Eaton]

On  2-Jul-2001, Mumit Khan <address@hidden> wrote:

| [ I'm not subscribed to this list, so please copy me if appropriate ]
| 
| This issue of using more of the standard C++ library has been in the back
| of my mind for a while now, and probably a good time to see how JWE and 
| others feel about replacing Octave's "foundation classes" with C++ library 
| components.
| 
| Octave was written well before the advent of STL and then the standard
| C++ library, and like any long-lived C++ projects, it has tons of code
| that have somewhat direct equivalents in the new library. This includes 
| various data structures such as lists, etc as well as algorithms such 
| as std::sort, std::copy, std::unique, etc.
| 
| I believe it will be beneficial in the long run to replace some/most of
| Octave's code with equivalent components in the C++ library, if possible.
| The only issue I see is with gcc-2.8.x, which used a hacked version of
| the original HP STL, but nobody who does C++ should be using 2.8.x
| anyway. 
| 
| I know that for some of my own older code, the executable code size stayed 
| about the same (this was a surprise, given the templates used), and the 
| performance actually increased in the process.
| 
| Is this something we want to do? If so, it could be a reasonably slow
| and incremental process:
| 
| 1. Make use of the standard algorithms first. liboctave/idx-vector.cc
|    for example stands to lose a bit of code if that happens.
| 2. Replace the data structures -- start with the various list structures
|    and go from there.

OK, a year and a half has passed and gcc 3.2 is available with an
increasingly standard and complete implementation of the standard C++
library (though many people are still using gcc 2.95.x, with an
incompatible and non-standard library).  Maybe it is time to start
working on this project?

The last time I tried to use the STL containers, I thought I was doing
something quite trivial, but had trouble on some systems with
extrememely long mangled names that the linker then rejected (I think
it was on HP systems, but it could have been on Alpha systems with
Digital Unix, I can't remember for sure).  Have those problems been
solved with gcc 3.2?

I think that the trivial program I was working with was
doc/interpreter/munge-texi.cc, which only uses the non-standard Map
class.  So perhaps we should start by converting that, and making sure
that we can build it on all of the kinds of systems on which we expect
to build Octave.

I would actually like to reverse the order of your list above so that
we replace the data structures first, but if you have a good reason
for choosing the above order, please leet me know what it is.

A step in that direction (without actually replacing the data types)
would be to convert classes that are derived from the container
classes to have the container as a data member.  That way, instead of
inheriting the interface from the container, the interface of the
Octave classes are stated explicitly.  I think that would be a good
first step, and something that I can do without having to first become
an STL expert.  Then it would be easier for an STL expert to convert
the Octave classes that use containers, one at a time and without
causing errors all over the rest of the code.

Comments?

Thanks,

jwe