Re: RFC: Using Standard C++ library components in Octave

[Paul Kienzle]

On Tue, Nov 12, 2002 at 08:43:41PM -0600, John W. Eaton wrote:
> 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?

How many things can we use from STL?

If we are replacing octave_value_list, is this also a good time to 
change how Octave manages values?  Allocating objects on the stack
and returning them from functions means that Octave is spending a
lot of time in constructors, copy constructors and destructors.  If
instead we were passing around references then much of that could be
avoided.

- Paul