This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: binary-io, opposable-thumb, pack/unpack (was Re: binary-io (was Re: rfc 2045 base64 encoding/decoding module))


Telford Tendys <telford@eng.uts.edu.au> writes:

> One thing that made me finally decide that C++ had major design flaws
> was the way the << operators knew how to format floating points in a
> bunch of useful ways but if you wanted to write your own ``stream''
> style IO that also worked with << operators (e.g. you want to send
> to a function rather than sending to a file) then you couldn't just
> patch a new back-end onto the existing formatting functions you have to
> either rewrite the formatting, or send everything to temporary strings
> so you can copy it out again or unravel the low level library
> implementation code and patch the back-end into the undocumented
> internal hooks.

You've fallen pray to a common misunderstanding.  If you want to send
to a function rather than a file, when you extend the streambuf class,
not the ostream class.  You then construct an ostream, passing it your
function_streambuf object.  The istream/ostream set of classes handle
formatting, using non-virtual function; the streambuf classes handle
getting/putting at the char level, using non-virtual operators.

People are all to quick to critize C++ as having major design flaws
without understanding what the language has to offer.

> The upshot is a language with heaps of powerful library functions that
> you can only use in exactly the way the authors thought of -- i.e.
> no flexibility at all and minimal reuse of code.

That is not the case for the standard C++ library.  Both the standard
I/O library and the Standard Template Library (STL) are extremely
flexible.

> So here we are wanting more functionality in the ports... they are
> already responsible for read-ahead buffering and write buffering, plus
> formatting of objects and now encoding and decoding of character
> streams too.

That is why you have two different sets of ports:  Byte ports do
buffering but no formatting or encoding/decoding.  Character ports
handle formatting of objects.  Both kinds of ports can be defined to
have prgrammer-defined sources/sinks of bytes or characters, respectively.
A specific kind of source/sink is a character port that indirects to
a byte port, and handles decoding/encoding.

It is quite clean and modular, assuming you use inheritance (or
or something similar) properly.

> Guile is supposed to be everything to all people, that is its biggest
> failing and what is holding it back at the moment. One quite sensible
> option is that the guile core simply doesn't handle binary IO at all
> and there is a .so library of handy binary readers that do all the specific
> jobs that people commonly use. That keeps 90% of users happy and the
> rest can take the trouble to learn C and write their own shared objects.

That is reasonable.  But note that the Guile core does have to convert
from the external byte representation to internal strings internally,
so some the functionality has to be in the core.  However, the
core functionality does not have to be very general or extensible.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]