Menu
▾
▴
pclasses-devel — P::Classes developer mailing-list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(188) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(59) |
Feb
(13) |
Mar
(4) |
Apr
(1) |
May
(15) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christian P. <cp...@se...> - 2005-01-08 10:31:16
|
Am Freitag 07 Januar 2005 18:02 schrieb stephan beal: > YES!!!!! That means i can get serialization of arbitrarily-sized data > working over http :). Is it possible now to send encoded data, zB, like > <textarea> field data? what does "<textarea> encoded field data" mean ? > Dude, you absolutely rock. :) i can't wait to get this into my client > code :). thanks ;-) > Is it possible (or feasible) to chain IOFilters? Just curious (i can't > think of a real use for it at the moment). I think it is possible, but needs some extra code in IOFilter. Greetings, Christian |
|
From: Christian P. <cp...@se...> - 2005-01-07 19:26:12
|
Am Freitag 07 Januar 2005 18:05 schrieb stephan beal: > Don't forget to update the manual ;). > (Just kidding - i'll do that if you don't want to.) if you would be so kind ;-) my documentation english sucks. > AFAIK zlib has gzip_xxx() functions, but i *think* it only has file > variants, not in-memory variants. i've used zlib "low-level" API. gz_xxx are all operating on an file descriptor. > That's exactly what i'm thinking. i have LGPL code for std::i/ostreams > which use gzip and bzip2 (i didn't write the gzip support, and bzip2 > was simply a copy/paste plus a one-line change). These should be fairly > trivial to port to FileStream subclasses. In fact, since they're > already std::i/ostream[buffers], they may be usable as-is in P, after > renaming them for P convensions. BZip2IOFilter is already in CVS. Problem with i/ostream[buffers] is .. that they only will be usable when using P::IO::IOStream. When using IOFilter's it will be transparent to IODevice and IOStream ! ZlibIOFilter gets a bit complicated... theire 3 different zlib format's out there: 1. zlib "raw" deflate format 2. zlib "deflate" format (header + zlib raw + trailer) -> RFC 1950 3. gzip format (gzip header + zlib raw + trailer) -> RFC 1952 Based on the raw ZlibIOFilter i will implement zlib deflate and gzip formats. Greetings, Christian |
|
From: stephan b. <st...@s1...> - 2005-01-07 17:07:18
|
On Thursday 06 January 2005 18:46, Christian Prochnow wrote: > Description: > IOFilters are proxies which will be called by IODevice's to serve the > actual I/O requests. The default implementation of IOFilter directly > calls the real I/O methods (_read, _write, _....). Don't forget to update the manual ;). (Just kidding - i'll do that if you don't want to.) > IOFilters work on any type of IODevice. however I/O filters may > change the return value of IODevice::isSeekable(). Therefore you > cannot rely on assumptions like "Files are always seekable". > Since this is a "raw" zlib deflate stream I/O filter it cannot be > directly used to decompress/compress gzip files. > Processing gzip files require an additional header and a trailer > (http://www.faqs.org/rfcs/rfc1952.html). AFAIK zlib has gzip_xxx() functions, but i *think* it only has file variants, not in-memory variants. > Maybe we should also add an GZipIOFilter ? > or if it isn't possible a GZipFile() ? That's exactly what i'm thinking. i have LGPL code for std::i/ostreams which use gzip and bzip2 (i didn't write the gzip support, and bzip2 was simply a copy/paste plus a one-line change). These should be fairly trivial to port to FileStream subclasses. In fact, since they're already std::i/ostream[buffers], they may be usable as-is in P, after renaming them for P convensions. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-01-07 17:04:44
|
On Friday 07 January 2005 17:11, Christian Prochnow wrote:
> I've re-worked and added the HTTPClient class.
Woo hooo!
i see you've been busy!
> straight-forwarded. Since we have IOFilter's (you gonna love them ;-)
> and HTTPResponse being a IODevice, users are now capable of reading
> Transfer-Encoded HTTP response-bodies.
YES!!!!! That means i can get serialization of arbitrarily-sized data
working over http :). Is it possible now to send encoded data, zB, like
<textarea> field data?
> std::cerr << "Sending request ..." << std::endl;
> HTTPRequest req(HTTPRequest::GET, URL("http://192.168.1.1/"));
> req.setAcceptEncoding("deflate");
> cl.sendRequest(req);
Dude, you absolutely rock. :) i can't wait to get this into my client
code :).
> IOFilter* filter = 0;
> if(resp.header().transferEncoding() == "deflate")
> {
> filter = new ZLibIOFilter();
> resp.setFilter(filter);
> }
Is it possible (or feasible) to chain IOFilters? Just curious (i can't
think of a real use for it at the moment).
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: Christian P. <cp...@se...> - 2005-01-07 16:10:53
|
Hi List !
I've re-worked and added the HTTPClient class.
Changes over P1:
HTTPResponse is now a IODevice, reading response bodies is now more
straight-forwarded. Since we have IOFilter's (you gonna love them ;-) and
HTTPResponse being a IODevice, users are now capable of reading
Transfer-Encoded HTTP response-bodies.
See how easy it can be:
--
using namespace P;
using namespace P::IO;
using namespace P::Net;
HTTPClient cl;
cl.open(Socket::Inet);
std::cerr << "Connecting to 192.168.1.1..." << std::endl;
cl.connect(InetAddress("192.168.1.1"), 80);
std::cerr << "Sending request ..." << std::endl;
HTTPRequest req(HTTPRequest::GET, URL("http://192.168.1.1/"));
req.setAcceptEncoding("deflate");
cl.sendRequest(req);
std::cerr << "Reading response ..." << std::endl;
HTTPResponse resp = cl.readResponse();
std::cerr << "Response: "
<< resp.protocol() << ' '
<< resp.responseCode() << ' '
<< resp.response()
<< std::endl;
IOFilter* filter = 0;
if(resp.header().transferEncoding() == "deflate")
{
filter = new ZLibIOFilter();
resp.setFilter(filter);
}
while(!resp.eof())
{
char tmp[1024];
size_t count = resp.read(tmp, 1024);
std::cerr.write(tmp, count);
}
if(filter)
{
resp.setFilter(0);
delete filter;
}
--
Thats it !
Any comments are welcome.
Greetings,
Christian
|
|
From: Christian P. <cp...@se...> - 2005-01-06 17:46:37
|
Hi ! I've finished the IOFilter architecture! Description: IOFilters are proxies which will be called by IODevice's to serve the actual I/O requests. The default implementation of IOFilter directly calls the real I/O methods (_read, _write, _....). Note: IOFilters work on any type of IODevice. however I/O filters may change the return value of IODevice::isSeekable(). Therefore you cannot rely on assumptions like "Files are always seekable". ZLibIOFilter ----------- Description: an IOFilter that compresses/decompresses IODevice's on the fly. Note: seek(), peek() is not supported. size() incorrectly returns the compressed size instead of the uncompressed size. Since this is a "raw" zlib deflate stream I/O filter it cannot be directly used to decompress/compress gzip files. Processing gzip files require an additional header and a trailer (http://www.faqs.org/rfcs/rfc1952.html). Maybe we should also add an GZipIOFilter ? or if it isn't possible a GZipFile() ? Greetings, Christian |
|
From: stephan b. <st...@s1...> - 2005-01-03 17:52:05
|
On Monday 03 January 2005 18:02, Christian Prochnow wrote: > > Looks like you've got a new slave, Christian! > > Hehe :) > > if i remember correctly, you did say till the 2.0 release is finished > :) You're being generous: i *think* i said something like 3 years! ;) > So everybody stay tuned for transparent compression/decompression > support with every I/O device P supports. i can't wait!!! :) -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Christian P. <cp...@se...> - 2005-01-03 17:02:26
|
Am Montag 03 Januar 2005 17:21 schrieb stephan beal: > On Monday 03 January 2005 14:43, Christian Prochnow wrote: > > Log Message: > > Added zlib compression support (decompression will follow...) > > For the record: i told Christian on IRC that if he would implement an > in-memory zlip compressor, that i'd be his coding slave for ... how > long did i say, Christian? > > Looks like you've got a new slave, Christian! Hehe :) if i remember correctly, you did say till the 2.0 release is finished :) but keep cool ... it's only a zlib wrapper (which was hardly enough to figure out how to implement it). I will now start implementing the ZLibIOFilter on top of it. The IOFilter infrastructure is already in CVS. So everybody stay tuned for transparent compression/decompression support with every I/O device P supports. Greetings |
|
From: stephan b. <st...@s1...> - 2005-01-03 16:23:29
|
On Monday 03 January 2005 14:43, Christian Prochnow wrote: > Log Message: > Added zlib compression support (decompression will follow...) For the record: i told Christian on IRC that if he would implement an in-memory zlip compressor, that i'd be his coding slave for ... how long did i say, Christian? Looks like you've got a new slave, Christian! -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-01-01 19:55:31
|
On Saturday 01 January 2005 20:51, stephan beal wrote: > If we could come up with a factory-like approach which works for all > existing compression formats i think we could do it generically. > e.g., grab the first 6 bytes of any stream and pass them to to > Factory<IOStream>::create(). If it can load a factory with that > cookie, great. That means using binary strings as cookies, but this > doesn't inherently pose a problem for std::string keys. i hit send too soon... was does pose a problem is that we don't know how many bytes we need to read to check the cookie. For gz/bz we can do it in 2 bytes. pkzip might need more. Tar? XML? This requires logic-based factories, not key-based factories, but that requires, AFAICS, explicit knowledge of each type which can check this logic (as Christian points out). -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-01-01 19:52:59
|
On Saturday 01 January 2005 18:21, Christian Prochnow wrote: > > For reading files we can auto-determine the decompression technique > > based on the first few bytes (i don't yet know how to dispatch this > > type of logic via a factory, though). > > this could be transparently done by IODevice::read(). But IODevice > must then know all IOFilter's. If we could come up with a factory-like approach which works for all existing compression formats i think we could do it generically. e.g., grab the first 6 bytes of any stream and pass them to to Factory<IOStream>::create(). If it can load a factory with that cookie, great. That means using binary strings as cookies, but this doesn't inherently pose a problem for std::string keys. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-01-01 18:27:26
|
The zip/tar ideas got me thinking about abstracting filesystem:
template <typename FileT, typename DirectoryT>
class FileSystem
{
// throw (IOError) left off for brevity...
FileT getFile( const String & path, ListT & targetList );
DirectoryT getDirectory( const String & path, ListT & targetList );
... various funcs to return iterators, etc. ...
};
That could be extended by:
TraditionalFileSystem (what you and i use)
TarFileSystem
ZipFileSystem
FtpFileSystem
...
???
i know there are existing APIs for doing this type of this (KDE and one
of the stream projects on SF (forgot the name)), but i haven't ever
used them.
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: stephan b. <st...@s1...> - 2005-01-01 18:21:59
|
On Saturday 01 January 2005 18:21, Christian Prochnow wrote: > Shall i add IOFilter's so you can start with the GZip/BZip2 Filters? There's no rush. i'm just experimenting with the existing code. The gz/bz filters i have only work for files, unfortunately. i have been unable to get the in-mem compression routines to work the way i want (my error, not the lib's). -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Christian P. <cp...@se...> - 2005-01-01 17:21:15
|
Am Samstag 01 Januar 2005 15:25 schrieb stephan beal:
> Hi, Christian!
Happy new year !
> i'm looking over the IOD/IOS code, and i would like to port in 2 LGPL
> classes a couple other guys wrote (don't remember their names) which
> provide transparent gzip/bzip2 support. Would you mind if i add an
> optional dependency on zlib/bzip2 to port these classes in?
transparent compression support sounds good ...
> i'm not yet certain how to fit them best into the architecture. They are
> implemented as i/stream[buffer] implementations and only support files
> (not, zB, stringstream). There is no FileStream class any longer - only
> a File device which gets passed to an IOStream. That means i can't
> extend/modify FileStream. Perhaps a (FileStream : public IOStream)
> convenience type would be a solution? We could then add member funcs to
> it like:
I would add "I/O Filters" to IODevice. This would allow all IODevice clients
to also use transparent compression, which would be really cool. (Remember:
Socket is also an IODevice).
> setCompressionPolicy( None|Gzip|Bzip );
> CompressionPolicy getCompressionPolicy() const;
class IOFilter {
public:
virtual size_t read(char*, size_t);
virtual size_t write(const char*, size_t);
};
void IODevice::setFilter(IOFilter*);
class GZipIOFilter : public IOFilter { ... };
class BZip2IOFilter : public IOFilter { ... };
really cool!
>
> For reading files we can auto-determine the decompression technique
> based on the first few bytes (i don't yet know how to dispatch this
> type of logic via a factory, though).
this could be transparently done by IODevice::read(). But IODevice must then
know all IOFilter's. I think we should keep out automatic filter detection
for now.
> The problem with this approach is that FileStream would need to proxy
> all IOS-related API calls to the appropriate de/compressor stream.
> That's possible to implement, i guess, but tedious.
proxying to the IOFilter is then done internally by IODevice.
> So, i guess my question is: if you were going to add GZip file support,
> where would you put it?
>
> PS: i think the IOS/IOD architecture will easily support the addition of
> Zip archive support, since we can treat a zip as a virtual filesystem.
> With s11n support on top of that we've got some really flexible object
> persistency options. :)
Keep in mind, IOS/IOD architecture is completly unrelated to the
"Network-Protocol-Transparent I/O" arch (IOManager, IOHandler, ...).
But you're right, zip, tar, what-ever-archiver support should be added also.
Shall i add IOFilter's so you can start with the GZip/BZip2 Filters?
|
|
From: stephan b. <st...@s1...> - 2005-01-01 14:27:51
|
Hi, Christian! i'm looking over the IOD/IOS code, and i would like to port in 2 LGPL classes a couple other guys wrote (don't remember their names) which provide transparent gzip/bzip2 support. Would you mind if i add an optional dependency on zlib/bzip2 to port these classes in? i'm not yet certain how to fit them best into the architecture. They are implemented as i/stream[buffer] implementations and only support files (not, zB, stringstream). There is no FileStream class any longer - only a File device which gets passed to an IOStream. That means i can't extend/modify FileStream. Perhaps a (FileStream : public IOStream) convenience type would be a solution? We could then add member funcs to it like: setCompressionPolicy( None|Gzip|Bzip ); CompressionPolicy getCompressionPolicy() const; For reading files we can auto-determine the decompression technique based on the first few bytes (i don't yet know how to dispatch this type of logic via a factory, though). The problem with this approach is that FileStream would need to proxy all IOS-related API calls to the appropriate de/compressor stream. That's possible to implement, i guess, but tedious. So, i guess my question is: if you were going to add GZip file support, where would you put it? PS: i think the IOS/IOD architecture will easily support the addition of Zip archive support, since we can treat a zip as a virtual filesystem. With s11n support on top of that we've got some really flexible object persistency options. :) -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2005-01-01 13:40:13
|
And happy New Year/Sylvester to you guys, too! Maybe next Jan 1 we can release out P 2.0 :). ---------- Forwarded Message ---------- Subject: Re: 10... 9... 8... 7... 6... Date: Saturday 01 January 2005 00:06 From: stephan beal <st...@s1...> To: s11...@li... On Saturday 01 January 2005 00:00, stephan beal wrote: > 5... 4... 3... 2... > > 1.0.0 !!! > > http://s11n.net/fanfare.php PS: this release is dedicated to granny :). -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: Marc D. <bdu...@gm...> - 2005-01-01 13:31:32
|
And maybe, just maybe I should learn how to use my damn mail program. Marc On Saturday 01 Jan 2005 14:23, Marc Duerner wrote: > Hello Stephan, > I am not sure if I can make it tomorrow. I caught an infection last > Thursday and I should stay in bed (and possibly not infect others ;) ). > I feel ok though and will be around in IRC from time to time. > > How about the weekend Jan 8th? > > Happy new year! > Marc > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > pclasses-devel mailing list > pcl...@li... > https://lists.sourceforge.net/lists/listinfo/pclasses-devel |
|
From: Marc D. <bdu...@gm...> - 2005-01-01 13:22:32
|
Hello Stephan, I am not sure if I can make it tomorrow. I caught an infection last Thursday and I should stay in bed (and possibly not infect others ;) ). I feel ok though and will be around in IRC from time to time. How about the weekend Jan 8th? Happy new year! Marc |
|
From: stephan b. <st...@s1...> - 2004-12-31 22:44:13
|
Yo!
One of the most interesting tricks serialization gives is the ability to
"cast" between "similar" types. For example, casting a list<int> to a
vector<double *>. Here's a demonstration showing how to convert a
SimplePropertyStore to or from a std::map<string,string>:
First we have to tell s11n to use a proxy for map<string,string> which
is compatible with the proxy for SimplePropertyStore. i happen to know
which proxy SPS uses, so we can use the same one. We do that with this
registration code (called from our client app):
#define PS11N_TYPE std::map<std::string,std::string>
#define PS11N_TYPE_NAME "map"
#define \
PS11N_SERIALIZE_FUNCTOR \
::P::s11n::map::streamable_map_serializable_proxy
#include <pclasses/SIO/RegisterSerializable.h>
SPS is mostly std::map compliant, and uses that same proxy:
see src/SIO/Proxy/SimplePropertyStore_s11n.h
Yes, the exact same proxy can de/serialize both SPS and a std::map (and
a std::multimap... *any* map-compliant type... even maps of maps of
maps of pointers to maps).
Now we create a SPS:
SimplePropertyStore m;
m["fred"] = "wilma";
m["barney"] = "betty";
m["days_in_december"] = 31;
m["days_in_february"] = 28.5;
m["the_letter_a"] = 'a';
save( m, std::cout );
And cast it to a std::map:
typedef std::map<std::string,std::string> OtherMap;
OtherMap m2;
if( ! s11nCast( m, m2 ) )
{
CERR << "Map conversion failed!\n";
return 1;
}
save( m2, std::cout );
Outputs:
<!DOCTYPE s11n::io::expat_serializer>
<s11n_node class="P::Util::SimplePropertyStore">
<barney>betty</barney>
<days_in_december>31</days_in_december>
<days_in_february>28.500000</days_in_february>
<fred>wilma</fred>
<the_letter_a>a</the_letter_a>
</s11n_node>
SimplePropertyStoreTest.cpp:54 : s11nCast() to map<string,string>:
<!DOCTYPE s11n::io::expat_serializer>
<s11n_node class="map">
<barney>betty</barney>
<days_in_december>31</days_in_december>
<days_in_february>28.500000</days_in_february>
<fred>wilma</fred>
<the_letter_a>a</the_letter_a>
</s11n_node>
This type of casting essentially works for any types which use
"compatible" de/serialization algos. That means, they use algos which
structure their serialized data identically.
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: Christian P. <cp...@se...> - 2004-12-31 18:42:03
|
Am Freitag 31 Dezember 2004 17:58 schrieb stephan beal: > On Friday 31 December 2004 17:57, stephan beal wrote: > > i can understand the throwing of an IOError, but LogicError seems a > > bit too strict. > > > > Why not just make it a no-op for 2nd+ close()? > > To make a real-life analogy: when closing a closed door, we don't > actually change it's state. It's a no-op. Nobody is surprised enough to > say, "hey! That's illogical!" Makes sense to me :) I'll change it. |
|
From: stephan b. <st...@s1...> - 2004-12-31 17:00:26
|
On Friday 31 December 2004 17:57, stephan beal wrote: > i can understand the throwing of an IOError, but LogicError seems a > bit too strict. > > Why not just make it a no-op for 2nd+ close()? To make a real-life analogy: when closing a closed door, we don't actually change it's state. It's a no-op. Nobody is surprised enough to say, "hey! That's illogical!" -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2004-12-31 16:58:44
|
Yo! =46rom IOTest.cpp: >> P_TEST_EXCEPTION(writePipe.close(), LogicError); i can understand the throwing of an IOError, but LogicError seems a bit=20 too strict. Why not just make it a no-op for 2nd+ close()? =2D-=20 =2D---- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2004-12-31 16:50:13
|
On Friday 31 December 2004 17:17, stephan beal wrote: > Quasi-related: please don't use IOManager at the moment. i'm still > re-thinking about whether it's really needed. i'm not certain that it > is. Ignore that - i meant the IOPluginManager. The IOManager serves URL-based requests, which we definately need. -- ----- st...@s1... http://s11n.net "...pleasure is a grace and is not obedient to the commands of the will." -- Alan W. Watts |
|
From: stephan b. <st...@s1...> - 2004-12-31 16:18:43
|
On Friday 31 December 2004 16:21, Christian Prochnow wrote:
> The new I/O code (pclasses2) should now be usable - please test it.
The IOTest runs on my box :).
> System::Pipe - Anonymous pipe's
> System::ProcessIO - Used to comminucate with child processes through
> anonymous pipes.
These will allow s11n over ssh :).
> // copy test.txt to process stdin
> File f("test.txt", File::Read);
> Process proc("tmpbin");
> proc.start(Process::RedirectAll);
>
> // copy data ...
> copy(f, proc.processIO());
> -- cut --
>
> Cool eh?
Extremely! :)
i am impressed :)
> IOStream should also work - please test it, cause documentation about
> extending std::streambuf is rare on the net, it's likely to fail.
streambuf docs are extremely rare. Josutti's "The C++ Standard Library"
are the most complete docs i've seen.
i will definately try it out - i want to get s11n-over-IO working again.
Quasi-related: please don't use IOManager at the moment. i'm still
re-thinking about whether it's really needed. i'm not certain that it
is.
> IOStream strm(f); // create I/O stream
> std::string str;
> strm >> str; // read string from test.txt
What is the default skipws handling? Same as std::istream (skip)?
Thanks for the code! :)
--
----- st...@s1... http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts
|
|
From: Christian P. <cp...@se...> - 2004-12-31 15:21:37
|
Hi !
The new I/O code (pclasses2) should now be usable - please test it.
Currently available IODevice's:
System::Pipe - Anonymous pipe's
System::File - File I/O class
System::ProcessIO - Used to comminucate with child processes through anonymous
pipes.
Net::Socket - Used for Network communication
Cause the I/O architecture is fully polymorphic, you can now write fully I/O
device independent code:
-- cut --
void copy(IODevice& src, IODevice& dest)
{
while(!src.eof())
{
char tmp[1024];
size_t read = src.read(tmp, sizeof(tmp));
dest.write(tmp, read);
}
}
// copy test.txt to process stdin
File f("test.txt", File::Read);
Process proc("tmpbin");
proc.start(Process::RedirectAll);
// copy data ...
copy(f, proc.processIO());
-- cut --
Cool eh?
Missing devices:
Memory(Mapped)File, NamedPipe, SerialDevice, ParallelDevice(?)
IOStream should also work - please test it, cause documentation about
extending std::streambuf is rare on the net, it's likely to fail.
-- cut --
File f("test.txt", File::Read); // open "test.txt" for reading
IOStream strm(f); // create I/O stream
std::string str;
strm >> str; // read string from test.txt
-- cut --
Greetings,
Christian
|
