Stephen R. van den Berg wrote: >Stephen R. van den Berg wrote: >>Now I see IOBuffer arrive. In order to avoid code bloat, wouldn't it >>be a better idea to integrate the functionality of IOBuffer into Buffer >>and just keep one? >>Or is the performance difference so strikingly great that this sounds >>like a bad idea?
I've been tracking IOBuffer extensions back to String.Buffer, I'll present what I have shortly. I suspect (but benchmarks will have to tell) that the String.Buffer implementation is not significantly slower than the current IOBuffer one (whilst supporting the full range of character widths). However, reviewing the IOBuffer interface, I wonder about the following issues: - Isn't it prudent to drop set_error_mode() and simply implement this functionality (the throw()) using a custom range_error() override? - Why insist on lock()ing the buffer when subbuffers are active? Couldn't the code figure out by itself when a subbuffer exists and then decide on-demand and automatically when a copy needs to be made to transparently support the desired operation? And, in order to make the code throw errors when unintended copies are being made, we could implement a prohibit_copy() method (like read_only()) which makes the object throw errors as soon as it would need to make a copy to support some requested action. -- Stephen.
