"Daryle Walker" <darylew@hotmail.com> wrote in message:
On 8/28/04 4:05 PM, "Jonathan Turkanis" <technews@kangaroologic.com> wrote:
"Daryle Walker" <darylew@hotmail.com> wrote in message news:BD55AC50.E831%darylew@hotmail.com...
On 8/26/04 1:38 AM, "Jonathan Turkanis" <technews@kangaroologic.com> 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