Re: A design problem associated with STL streams
On Mar 7, 2:51 am, Steven Woody <narkewo...@gmail.com> wrote:
On Mar 6, 6:08 pm, James Kanze <james.ka...@gmail.com> wrote:
On Mar 5, 2:21 pm, Steven Woody <narkewo...@gmail.com> wrote:
Supposing I have three types: class CA, CB and CC, and I
need to implement input/output of these types agains STL
ostream/istream. I know the ussual method would be
overloading >> and << operators on these types, but
myproblemis even harder. CA, CB, CC each has five forms
of representation ( each has five valid storage format ).
So, how should I resolve thisproblemin STL? By defining
five different istream/ostream derivations?
Certainly not.
Or use a single pair of istream/ostream with help of five
manipulators?
More likely.
A lot depends on context, but basically, you have two options:
define manipulators (using ios::xalloc() and ios::pword or
ios::iword), or use the decorator pattern. Which is preferred
depends on the semantics of the object; I've used both on
different occasions.
when you said decorator, did you mean something like i
illustrated in previous post as blow?
+------------+ +----------+
| MyIOClassA |<*>---------->| IOStream |
+------------+ +----------+
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.)
Currently, i've not yet get enought knowledge on details of
stl manipulators, streambuffs, etc, it be difficute to me to
implement them. I am just a little afraid. So decorator may
be my current choice. But i am totally not sure about where
to go.
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.)
And as Victor pointed out, it's generally better if you can
automatically distinguish the representation on input,
rather than requiring the manipulator/decorator (and running
the risk of a mismatch).
On one hand, it's hard to distinguish the representation on input,
becuse that depends on other contexts. But when I ready to input/
output, i do know what representation on hand. On the other hand, i
need to output different representations for a same object, for
example, the presentation on network and the presentation on disk.
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