Boost logo

Boost :

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
> >
> >> 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
> 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 {
          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]
         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

> [SNIP]
> >> The "?count" member functions can return the seek positions in a much
> >> 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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at