From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-08-19 21:06:35
George M. Garner Jr. wrote:
>>> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk