From -4702686468483420020 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,4a10029849950019 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-08-08 23:17:22 PST Newsgroups: comp.std.c++ From: Philip@storcomp.demon.co.uk (Philip Hugh Hunt) Path: bga.com!news.sprintlink.net!news.onramp.net!convex!news.duke.edu!news-feed-1.peachnet.edu!emory!swrinde!pipex!demon!storcomp.demon.co.uk!Philip Subject: Re: strstreams and string classes References: Organization: Storage Computers Ltd Reply-To: Philip@storcomp.demon.co.uk X-Newsreader: Demon Internet Simple News v1.27 Lines: 30 Date: Tue, 9 Aug 1994 01:42:09 +0000 Message-ID: <776396529snz@storcomp.demon.co.uk> Sender: usenet@demon.co.uk In article matt@physics.berkeley.edu "Matt Austern" writes: > strstream, istrstream, and ostrstream allow formatted I/O to and from > strings, instead of output devices. They require a fairly complicated > memory allocation protocol, though, which is related to the fact that > the "strings" they use are C-style strings, i.e., arrays of chars > terminated by '\0'. > It would be a pity if the iostream hierarchy doesn't include something > like strstreams, but using class string; this would mean that programs > will have to continue using both kinds of strings, and do a fair > amount of work to convert between them. Ideally the class library will replace 'strstream' with 'string', so that string will understand operator<< just like ostream. It'd also be nice if ostream had a virtual putchar(char c) operator so you could write subclasses of it easily. (Incidently why isn't it *virtual*? Efficiency reasons, I'd guess). The present implementation requires you to write a subclass of streambuf, I tried and gave up as I felt it was too complex. In the end I wrote my own 'OStream' class hierarchy which IMO is much easier to use and understand than ostream (especially for subclassing). It's also got some good functions for reading input, eg for implementing lexical analysers. -- Phil Hunt