Re: Extend streams in C++
On Jan 14, 7:26 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <6de450ee-01bf-4ccf-895b-
b34c0cebc...@m77g2000hsc.googlegroups.com>,
giannis.papadopou...@gmail.com says...
[ ... ]
I'm not talking about actually changing where std::cout directs
whatever it's written into it. I want my::cout and this will be
handled by a runtime system. The user should be able to use std::cout
as before and expect the same behavior. However, the behavior of
my::cout will be whatever the runtime wants.
I want to make my::cout as interoperable with current functions and
classes as possible - that is I don't want my user to implement any
new >> and << operators for his/her classes.
You've told us one part of what you want: to allow the user's insertion
and extraction operators to work with your stream object(s).
The only other thing you've said is:
cout will redirect anything from files to sockets and this redirection
will be handled by a runtime system without used intervention.
To make this work, you'll probably have to do what James has advised
against (i.e. create your own stream class) as well as creating your own
socket-based stream buffer class.
Not at all:
namespace my
{
std::ostream cout( (getDesiredStreambuf()) ) ;
}
About the only reason to create a new ostream class would be to
provide convenience initializers, so that the user can create an
ostream using your streambuf in a single declaration (along the
lines of ofstream).
Making it happen entirely transparently may be a bit difficult
though. When you you write to a file, you normally only need
to supply the name of the file, and then you can put data into
it. Writing to a socket requires a bit more information: the
name/address of the server, the type of protocol to use (e.g.
TCP vs. UDP) and the socket number to write to (and possibly a
few more things specifying such things as timeouts and such).
Actually, it wouldn't be too difficult if an implementation of
filebuf recognizeds URL's. (At one point I experimented with
one which would create a separate process, and read or write to
a pipe connected to the process, if the filename started with a
"!". So you could do things like:
std::ifstream input( "! gunzip < gzippedData.gz" ) ;
. I don't think handling URL's would be much more difficult,
conceptually.)
You _could_ create a buffer object specifying all that, then
attach it to an object of one of the existing stream classes,
but if you're using it much, you probably want a new stream
class that allows you to specify all that and pass it through
when it creates the buffer object.
There are quite a few existing samples of how to do this. One that's
relatively small and simple is Socket++, available from:
http://www.cs.utexas.edu/users/lavender/courses/socket++/
Another that's well known is ACE, though it's far from small or simple.
Available from:
http://www.cs.wustl.edu/~schmidt/ACE.html
If you want something to download and use as-is, ACE may be a better
choice as it's in current development (whereas Socket++ doesn't seem to
have been touched in years, though that may just be because it's fine
the way it is). If you just want some guidance as to the basics of how
to do the job, Socket++ is probably better due to its smaller size and
relative simplicity.
One last note: I've used things like this a few times, and while they
initially seem like a great idea, they haven't worked out very well in
the long run, at least for me. For building simple clients they aren't
too bad, but for servers (especially) they're pretty close to useless.
The problem is that streams are built around the idea that you
decide when to read or write a stream. A server mostly doesn't
have that luxury -- rather, it waits for a client, and then
reacts to the client's request.
Typically, the server has two different levels: in the main
thread, it "accepts", with no streams involved. Once it has a
TCP connection, however, the input can often be read as a
stream, at least if each connection is handled in a separate
thread. It input has to be active while processing previous
input (not necessary in a lot of protocols), then you just spawn
another thread for the processing, and you're still OK.
--
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