|
From: stephan b. <st...@s1...> - 2004-12-28 22:41:36
|
Yo!
Here are some first-draft ideas for the i/o layer. My main goals are:
- Allow interaction between IOStream and IODevice. Either consolidate
them or provide a marshaller type which can proxy data between them.
- Consolidate the various i/o interfaces (read(), write(), open(),...)
into a consistent interface.
- Structure the types such that we can apply many generic algorithms to
them (e.g., std::copy(), std::for_each()).
To be clear: i am not at all certain about any of these ideas. i only
have experience as a stream user, not a stream implementor.
My first idea is to create an abstract IOInterface type. Something like:
class IOInterface [??? : public NonCopyable] {
virtual void open() throw(IOError) = 0;
virtual void close() throw(IOError) = 0;
virtual size_t read( char * buff, size_t count ) throw(IOError) = 0;
virtual size_t write( char * buff, size_t count ) throw(IOError) = 0;
virtual bool canWrite() = 0; // read-only streams return 0
virtual bool canRead() = 0;// write-only streams return 0
...
};
IOStream should, IMO, subclass std::iostream. i would prefer to see:
class IStream : public IOInterface, public std::istream {}
class OStream : public IOInterface, public std::ostream {}
But this probably requires virtual inheritence to avoid colliding with
i/ostream members. (haven't checked yet.)
And, of course:
class IODevice : public IOInterface {
....
};
i really would prefer to see IODevice and IOStream be directly related,
but i am not certain that is really practical or desireable.
Maybe...
istream ==> extended by IDevice ==> IStream
ostream ==> extended by ODevice ==> OStream
IOStream ==> EXTENDS (IStream, OStream)
IODevice ==> EXTENDS (IOStream)
???
In that case, i don't see the real distinction between IODevice and
IOStream... what IS the difference?
How does all this apply when using IODevice for, e.g., rendering
graphics (e.g. QPaintDevice). ??? i have no idea.
???
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|