Re: A design problem associated with STL streams

On Mar 7, 2:51 am, Steven Woody <narkewo...@gmail.com> wrote:


No. I meant a decorator for your class. Or rather, as many
decorators as you have representations. Thus, for example, I
have a decorator for std::string, ParsableString, which will
output quotes around the string if it contains white space,
convert anything non printable to an escape notation, etc., and
parse in consequence on input. Or one could easily imagine a
PolarCoordinates decorator for complex.

Writing such decorators to be bi-directional may be overly
complicated, since the input decorator has to contain a
non-const reference, where as the output decorator needs to be
able to output const objects (and thus, will normally contain a
const reference). One solution is to just have two decorators,
using whichever one is appropriate. Another is to implement one
type of decorator for const objects, which only supports output,
and a second one for non-const objects, supporting input or
output, then provide an overloaded function to get whichever one
is needed, e.g.:

    class PolarCoordConst
    {
    public:
        explicit PolarCoordConst( Complex const& obj )
            : myObj( obj )
        {
        }
        friend std::ostream&
                        operator<<( std::ostream& dest,
                                    PolarCoordConst const& obj )
        {
            printUsingPolarCoords( dest, obj.myObj ) ;
            return dest ;
        }

    private:
        Complex const& myObj ;
    } ;

    class PolarCoordNonConst
    {
    public:
        explicit PolarCoordNonConst( Complex& obj )
            : myObj( obj )
        {
        }
        friend std::ostream&
                        operator<<( std::ostream& dest,
                                    PolarCoordNonConst const& obj )
        {
            printUsingPolarCoords( dest, obj.myObj ) ;
            return dest ;
        }
        friend std::istream&
                        operator>> ( std::istream& source,
                                     PolarCoordNonConst const& obj )
        {
            parseUsingPolarCoords( source, obj ) ;
            return source ;
        }

    private:
        Complex& myObj ;
    } ;

    PolarCoordConst
    polar( Complex const& z )
    {
        return PolarCoordConst( z ) ;
    }

    PolarCoord
    polar( Complex& z )
    {
        return PolarCoordNonConst( z ) ;
    }

Client code simply writes:
    std::cin >> polar( someComplex ) ;
or:
    std::cout << polar( someComplex ) ;
(Note that unless someComplex is a non-const lvalue, the first
will fail to compile.)


Manipulators are really easy. If they don't need an argument,
just define a function with the signature "std::ostream& (
std::ostream& )" (for an output manipulator), "std::istream& (
std::istream& )" (for an input manipulator), or "std::ios& (
std::ios& )"( for a bidiretional manipulator. Pass the name of
a function with those signatures to the corresponding type of
stream, and it will be called. For manipulators with arguments,
the simplest solution is just to define a class with an
overloaded >> and/or << operator, and a constructor which takes
and stores the arguments, for use when the << or >> operator is
called.

If you need formatting flags or arguments in addition to those
provided, you can use ios::xalloc, ios::iword and ios::pword to
get and access them. Something like:

    int
    polarFlag()
    {
        static int result = std::ios::xalloc() ;
        return result ;
    }

    std::ios&
    polar( std::ios& stream )
    {
        stream.iword( polarFlag() ) = 1 ;
        return stream ;
    }

    std::ios&
    cartesian( std::ios& stream )
    {
        stream.iword( polarFlag() ) = 0 ;
        return stream ;
    }

    std::ostream&
    operator<<( std::ostream& dest, Complex const& obj )
    {
        if ( dest.iword( polarFlag() ) ) {
            // output polar...
        } else {
            // output cartesioan...
        }
        return dest ;
    }

(You'd probably want to add functions to allow saving and
restoring the state as well.)


The question is whether you can distinguish in the >> operator.
If you can't, you'll have to count on the user calling the
correct manipulator or using the correct decorator.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34