Re: [boost] Review of Daryle Walker's "More IO" library begins today, August 21, 2004.

From: Daryle Walker (darylew_at_[hidden])
Date: 2004-08-29 23:53:21

On 8/28/04 4:05 PM, "Jonathan Turkanis" <technews_at_[hidden]> wrote:

> "Daryle Walker" <darylew_at_[hidden]> wrote in message
> news:BD55AC50.E831%darylew_at_hotmail.com...
>> On 8/26/04 1:38 AM, "Jonathan Turkanis" <technews_at_[hidden]> wrote:
[SNIP]
>>> However, if one has written a custom stream buffer, the name
>>> basic_wrapping_xstream is not what most people want for the matching
>>> streams. If the streambuf is called mapped_filebuf, a matching i/o
>>> stream might be named mapped_fstream. This could be solved with
>>> template aliases:
> 
>>> The problem with this is that one has to write new constructors, since
>>> they are not inherited. If one wants to follow the example of the
>>> standard library file and string streams, one should also repeat the
>>> typedefs char_type, traits_type, pos_type, etc. As a result, the above
>>> is scarcely easier than writing mapped_fstream from scratch, since
>>> writing the constructors (and typedefs) is the principle difficulty.
>> 
>> You didn't notice the extra "rdbuf" and "is_using_internal_streambuf" helper
>> member functions?  I admit that the examples basically are doing the
>> repetition you're complaining about.  But, it's better than nothing, right?
> 
> Only marginally, I think. And for such a small benefit, I'm not sure it's
> worth making someone reading the code familiarize himself with a new template.

It's like the dilemma:
    "It's so easy, you can write it yourself."
    "If it's so easy, why can't you include a version?"

If everyone has to do it themselves, then we'll get a whole bunch of
slightly different version.  And some may have bugs.  If the original source
does it, then only that source has to do debugging.  And everyone benefits
from the one set of source code improving.

[SNIP]
>>> 2. basic_array_streambuf should be implemented as a thin wrapper
>>> around basic_pointerbuf. Otherwise, you've got unnecessary code bloat,
>>> since all the code is duplicated for each value of N.
>> 
>> That's the inherent trade-off using compile-time arrays.
> 
> There's no trade-off, that I see. Using a wrapper around pointerbuf reduces
> code bloat but should have no adverse performance impact. Right?

But you would have to manually define a pointer-stream and an array as two
separate objects, then connect them together.  Using a class to automate the
process would give similar results to my array-stream.  Forcing the user to
manually create code as an alternative to having a piece of pre-existing
"bloat"-like code is _not_ generally a gain.

[SNIP]
>>> 1. Having separate classes for const and non-const pointers leads to
>>> far too many templates. Const-correctness can be enforced by
>>> the stream buffer by not allowing constructors taking const char* to
>>> set the put area.
>> 
>> I deliberately didn't want that.  The old std::strstream class has at least
>> three distinct modes.  It can act like std::stringstream, like
>> pointerstream, or like iconstpointerstream.  And I think it can sometimes
>> switch between those behaviors in mid-use.  I wanted separate classes for
>> those uses, especially after the Standard only included one separation.
> 
> I know. The problem with strstream is that it does too much. It's good to get
> rid of allocation functions. But the didea of a stream which can be opened in
> read-only, write-only or read-write mode is very familiar. It's much better
> than multiplying the number of templates by 2.

The pointer stream and its pointer-to-const variant have different
semantics.  Shoving the const variant into the main one would be a repeat of
the std::strstream mess.  Wouldn't you want a mistake in building
constructor arguments cause an error directly instead of activating a
different, unwanted set of semantics?

[SNIP]
>> The "?count" member functions can return the seek positions in a much faster
>> way.
> 
> Faster because there's no virtual function call?

Yes.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com