lilypond-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]