[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: memory-stream.cc
From: |
Christoph Ludwig |
Subject: |
Re: memory-stream.cc |
Date: |
Fri, 25 Feb 2005 10:00:18 +0100 |
On Thu, Feb 24, 2005 at 11:22:21PM +0100, Han-Wen Nienhuys wrote:
> address@hidden writes:
> > >did you do make clean after removing the
> > >
> > > #include <libio.h>
> > >
> > >line?
> > >
> > >
> > Sure, but the memory stream functions are cookie_io_functions_t and
> > that's declared in libio.h. Do you think I could implement the missing
> > parts for cygwin?
>
> A better approach would be to rewrite ttftool/ , Right now, it does
> output with FILE, but we want it to write to
> memory. cookie_io_functions_t is an easy way to do that, but it is
> also possible to substitute My_file for FILE and implement a
> myfprintf() which writes to memory in stead of disk. Would you want to
> try implementing that?
Sorry to butt in, but why reinvent the wheel? lily uses C++ anyway and there
are more than enough solutions for in-memory streams available that are
portable to any system with a conforming C++ standard library.
Case (a): Performance is not critical und you do not insist on the
printf-syntax.
Then the stringstreams from the C++ standard library (#include <sstream>)
are sufficient. (NB: The stream classes defined in the header strstream are
officially deprecated.)
Case (b): Performance is critical and you don't want additional dependencies
to nonstandard libraries, but you do not insist on the printf-syntax.
The memory allocation scheme used for std::string in most implementations is
not optimal if data is appended very often. Therefore solution (a) may cause
a performance bottleneck, depending on how the streams are used.
But you can implement your own stream buffer that uses a memory allocation
scheme optimized for lily's needs. You need to write a fair amount of code
(cf. chapter 13.13 in [Josuttis: The C++ Standard Library] or the book by
Langer and Kreft) but it is pretty straight forward. You don't need to worry
about the formating (that's the responsibility of the stream class, not the
stream buffer) and it's portable to any system with a conforming standard
library.
Case (c): Performance is critical but you don't mind a dependency on Boost and
you do not insist on the printf-syntax.
In the Boost CVS (http://www.boost.org) is a new library called Iostreams
that claims to simplify the creation of custom stream buffers. (It will
become part of the next boost release.) I did not review Boost.Iostreams but
the boost libraries are always worth consideration. You might search the
Boost developer list archive for the formal review of Boost.Iostreams that
took place around August / September 2004, IIRC.
Case (d): You insists on the printf-syntax but you don't mind a dependency on
Boost.
Then have a look at the Boost.Format library.
I am sure Google will reveal more solutions out there. Whatever approach you
want to pursue, I recommend *not* to redevelop memory streams from scratch.
Regards
Christoph
--
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
- memory-stream.cc, Bertalan Fodor, 2005/02/22
- Re: memory-stream.cc, Jan Nieuwenhuizen, 2005/02/22
- Re: memory-stream.cc, Bertalan Fodor, 2005/02/22
- Re: memory-stream.cc, Han-Wen Nienhuys, 2005/02/22
- Re: memory-stream.cc, Peter Leschev, 2005/02/23
- Re: memory-stream.cc, Bertalan Fodor, 2005/02/24
- Re: memory-stream.cc, Jan Nieuwenhuizen, 2005/02/24
- Re: memory-stream.cc, Han-Wen Nienhuys, 2005/02/24
- Re: memory-stream.cc, Han-Wen Nienhuys, 2005/02/24
- Re: memory-stream.cc,
Christoph Ludwig <=
- Re: memory-stream.cc, Han-Wen Nienhuys, 2005/02/25
- Re: memory-stream.cc, Jan Nieuwenhuizen, 2005/02/25
- Re: memory-stream.cc, Han-Wen Nienhuys, 2005/02/25
memory-stream.cc, Han-Wen Nienhuys, 2005/02/22