A design problem associated with STL streams

S

Steven Woody

Hi,

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 my problem is even harder. CA, CB, CC each has five
forms of representation ( each has five valid storage format ). So,
how should I resolve this problem in STL? By defining five different
istream/ostream derivations? Or use a single pair of istream/ostream
with help of five manipulators? How?

You help will be higly appreciated!

-
woody
 
V

Victor Bazarov

Steven said:
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 my problem is even harder. CA, CB, CC each has five
forms of representation ( each has five valid storage format ). So,
how should I resolve this problem in STL? By defining five different
istream/ostream derivations? Or use a single pair of istream/ostream
with help of five manipulators? How?

Five valid storage formats - that's important when you read them.
But how is that important for overloading operators? When do you
decide what storage format to use? How do you decide? Can your
operator>> start reading and determine that it's reading format 1
(or 2, or 5)? Then no manipulators necessary. Do you need to
output them differently? What if you always output them in format
1 (or 2, or 5)? Or do they have to be output in the same format
they were input in? See, there isn't enough information.

V
 
D

dizzy

Steven said:
Hi,

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 my problem is even harder. CA, CB, CC each has five
forms of representation ( each has five valid storage format ). So,
how should I resolve this problem in STL? By defining five different
istream/ostream derivations? Or use a single pair of istream/ostream
with help of five manipulators? How?

Five different pairs of i/o streams. You don't even need to use anything
from iostreams at all for them (other than using streambufs for actual
I/O). Generally my understanding of the iostreams design (for the formatted
I/O, ie overloading of <</>>, which is what you asked, because in practice
iostreams also does unformatted I/O, that is a hole in the design but we
can ignore it in the discussion) is that:
- the stream objects represent the way the objects are serialized (so new
way of serializing stuff means new stream object types)
- the streambuf objects represent the actual I/O source/destination

So, each time I need a new way to serialize something I have new stream
objects, overload operator<</>> for those and the types I wish to serialize
in that way. But, the stream objects, use the streambuf interface, so they
can use existent iostreams streambufs (such as filebuf, stringbuf, etc) but
I also have developed network based streambufs (which can be used with
standard stream objects too btw).

So far this aproach has worked fine for me.
 
S

Steven Woody

Five different pairs of i/o streams. You don't even need to use anything
from iostreams at all for them (other than using streambufs for actual
I/O). Generally my understanding of the iostreams design (for the formatted
I/O, ie overloading of <</>>, which is what you asked, because in practice
iostreams also does unformatted I/O, that is a hole in the design but we
can ignore it in the discussion) is that:
- the stream objects represent the way the objects are serialized (so new
way of serializing stuff means new stream object types)
- the streambuf objects represent the actual I/O source/destination

So, each time I need a new way to serialize something I have new stream
objects, overload operator<</>> for those and the types I wish to serialize
in that way. But, the stream objects, use the streambuf interface, so they
can use existent iostreams streambufs (such as filebuf, stringbuf, etc) but
I also have developed network based streambufs (which can be used with
standard stream objects too btw).

So far this aproach has worked fine for me.

Glad to read your inputs because i think i basically agree with you.
Thanks.

But, i'm just afraid derivating a subclass of istream/ostream is not a
easy job to do, isn't it? So, rather than tackle the insides of STL's
streams, i am thinking there may be another options. How about to
implement five iostream classes which are not subclasses of STL
iostream but use existing iostream to do their job? That is,

+------------+ +----------+
| MyIOClassA |<*>---------->| IOStream |
+------------+ +----------+

in code,

void MyIOClassA( std::iostream& iostream ) { ... }

Because std::iostream supports raw read/write, so MyIOClassA can do
its particular formating and call iostream to do the raw input/output.

How about this?

Thanks you.

-
woody

How about it?
 
J

James Kanze

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 my problem is even harder. CA, CB, CC each has five
forms of representation ( each has five valid storage format ). So,
how should I resolve this problem in 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.

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

Steven Woody

Certainly not.


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


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.
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/
outpu, 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.
 
J

James Kanze

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::eek:stream&
operator<<( std::eek:stream& 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::eek:stream&
operator<<( std::eek:stream& 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::eek:stream& (
std::eek:stream& )" (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::eek:stream&
operator<<( std::eek:stream& 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.)
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.
 
S

Steven Woody

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::eek:stream&
operator<<( std::eek:stream& 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::eek:stream&
operator<<( std::eek:stream& 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::eek:stream& (
std::eek:stream& )" (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 ofstream, 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 ;
returnstream;
}

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

std::eek:stream&
operator<<( std::eek:stream& 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:[email protected]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Thanks your help and your code. But are you sure the class
PolarCoordConst and PolarCoordNoneConst are really decorators? You
know they don't comply with Decorator design pattern in the book "The
Gang of Four".

I feel my problem is not fully resolved. May be I need to describe it
more precisely, so just posted another article on comp.object. You may
like to read it.

Thanks again.

-
woody
 
J

James Kanze

On Mar 7, 9:24 pm, James Kanze <[email protected]> wrote:

[...]
Thanks your help and your code. But are you sure the class
PolarCoordConst and PolarCoordNoneConst are really decorators?
You know they don't comply with Decorator design pattern in
the book "The Gang of Four".

It depends on how you define Decorator. They have certain
characteristics of a decorator, but not others. Regardless of
what you call them, however, it's a frequently used and useful
idiom.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,566
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top