From bug-octave-request at bevo dot che dot wisc dot edu  Wed May 16 15:30:14 2001
Subject: I/O operators in octave class library
From: Brook Milligan <brook at biology dot nmsu dot edu>
To: bug-octave at bevo dot che dot wisc dot edu
Date: Wed, 16 May 2001 15:30:09 -0500

In the process of using the octave class library in a programming
project, I have come across what I consider to be a bug in the
design with regard to I/O operators (i.e., << and >>).  Specifically,
a number of classes declare these operators for the purposes of I/O
following standard C++ conventions.  The problem is that they are
implemented in the same objects that implement the remainder of the
class.  For example, within liboctave the following files implement
both the class and the I/O operators:

     CColVector.cc:815:operator >> (istream& is, ComplexColumnVector& a)
     CMatrix.cc:3824:operator >> (istream& is, ComplexMatrix& a)
     CRowVector.cc:725:operator >> (istream& is, ComplexRowVector& a)
     Range.cc:137:operator >> (istream& is, Range& a)
     dColVector.cc:344:operator >> (istream& is, ColumnVector& a)
     dMatrix.cc:2685:operator >> (istream& is, Matrix& a)
     dRowVector.cc:318:operator >> (istream& is, RowVector& a)

This makes it impossible to replace these operators with ones more
useful for specific applications.  In many cases it is trivial to
write appropriate improved functions, but this results in multiply
defined symbols because the library forces the implementation of the
I/O operators to be resolved to the same object as the remainder of
the class.

The solution to this problem is to move the implementation of these
I/O functions to files distinct from the implementation of the
corresponding class.  For full granularity, each of the I/O functions
would have to be in a separate file.  If the user does not provide a
replacement, the library versions will be linked (current behavior);
however, if the user provides a version appropriate to his/her
application, the library ones will not cause multiply-defined symbol
errors.

Because the details of the external format are only loosely connected
to the class itself, it would make a great deal of sense to reflect
that fact in the design of the library.  Allow users, if necessary, to
create the bridge between internal and external format to match the
application at hand.

Cheers,
Brook



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------