Re: [boost] Minor iostreams change request (was: Plans for 1.33.1?)

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-08-19 21:06:35

George M. Garner Jr. wrote:
> Johnathan,
>
>>> component_impl() returns a void*.  What
>>> am I supposed to do, cast it?  :-(
>>
>> Of course ;-) What else can you do with a void*?
>
> I must have missed that day in OOP design class.  :-)  And I don't
> see what that get's me even assuming that I cast it.  The branch in
> the execution
> path that I want to intercept occurs in basic_streambuf<>::_Xsgetn_s()
> (Microsoft SL v8.0) or basic_streambuf<>::xgetn() (other SL).  Even
> assuming that I cast your void pointer I won't get a chance to do so
> unless I replace _Xsgetn_s/xsgetn in the basic_streambuf<> vtable.

I'm not following this. I thought you wanted me to make component_impl()
protected so you could override it. My only point was that you can already do
this.

> The only (legitimate) way to do that is by derivation.  Derivation is
> still a respectable means of specialization so far as I know.
>
>> Even better, if you can show that your implementation is superior to
>> the current one, I can simply use yours instead. <
>
> Well you could do that of course.  But what happens in 6 months when
> I want to specialize something else?  I don't see what advantage
> there is to making the typedefs private rather than protected.  You
> could provide an accessor for pback_size_.  I don't see why that
> shouldn't be provided in any case.

Because it relies on implementation details. How would you know what invariants
to maintain? How would I know what aspects of the implementation I'm free to
change in later versions? Instead of making all this internal machinery
accessible -- which implies that I have to document it and promise to keep it
stable -- why not encapsulate the buffering policy in a template parameter?

As I said before, the reason I didn't do this is that I wasn't convinced that
there wasn't a single best buffering policy; however, I'll be glad to look at
any data you have.

>> I'll have to review the old messages to remember what the sticking
>> points were.
>> I seem to remember there was a problem with STLPort requiring a
>> larger putback
>> buffer than other libraries.
>
> After some subsequent testing I found that I didn't need to modify
> that part of the code.

Okay.

> Regards,
>
> George.

Jonathan