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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-08-30 00:49:03

"Daryle Walker" <darylew_at_[hidden]> wrote in message:
> 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:

> > 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?"

Right. :-)

> 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.

Maybe. Looking at the implementation of streambuf_wrapping, I'm not sure why it
has to be so complicated. Could you explain why you need  basic_wrapping_ios and
virtual inheritance?

> [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.

I was thinking of something like this (simplified and untested):

     template<size_t N>
     class arraybuf : pointerbuf {
     public:
          arraybuf() : pointerbuf(data, data + N) { }
          arraybuf(const char* first, const char* last)
              : pointerbuf(data, data + N)
              {
                    assert(last - first <= N);
                    std::copy(first, last, data);
              }
         template<typename InIt>
         arraybuf(InIt first, InIt last);

         [some other stuff, but no need to override the virtual functions]
     private:
         char data[N];
     };

This doesn't require the user to create the array separately.

> The pointer stream and its pointer-to-const variant have different
> semantics.

Is there any difference other than the fact that you can't write to a const
char*?

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

But is this something that needs to be optimized? My heuristic for i/o is that
any operation which might be performed for each character in a sequence must be
highly optimized, but that operations which occur only once in a while, say each
time a buffer fills up, can afford a virtual function call or two. Can you think
of a scenario in which pubseekoff would be called so frequently that it would
become a performance bottleneck?

If so, I still think gcount and pcount are poorly named, since for streams the
members with these names return the number of characters processed in the most
recent i/o operation. I'd prefer if they were called tellg and tellp.

Best Regards,
Jonathan