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

[Mumit Khan]

On Tue, 12 Nov 2002, John W. Eaton wrote:

> 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?

With the state of affairs stabilizing, this is probably a good time as
any.

> 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?

HPUX. It also happened under SunOS and DUX assemblers when debugging was
turned on.  GNU C++ had a tendency of creating ridiculously long symbol
names, something that has been rectified as of 3.0, causing these
problems. This particular problem is fixable with a better mangling
algorithm, but that should not excuse the large body of development
code that still uses fixed sized buffers (this is one of those cases
where GNU dev tools shine over the commercial alternatives).

> 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 agree, standalone ones are the best ones to start off with.

>
> 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.

The order was arbitrary, so either way works fine.

> 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.

The C++ standard library container classes are not designed to be derived
from, so containment is usually the preferred approach. When I converted
a large body of code a year or so ago, I faced essentially the same
problem, and it took a few iterations to get it right (this particular
piece of code, roughly the same size of Octave C++ code, is quite old
-- I first started it with Cfront, then modified it over time just enough
to get it to work with newer compilers).

Regards,
Mumit