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: [SNIP]
However, if one has written a custom stream buffer, the name basic_wrapping_xstream is not what most people want for the matching streams. If the streambuf is called mapped_filebuf, a matching i/o stream might be named mapped_fstream. This could be solved with template aliases:
The problem with this is that one has to write new constructors, since they are not inherited. If one wants to follow the example of the standard library file and string streams, one should also repeat the typedefs char_type, traits_type, pos_type, etc. As a result, the above is scarcely easier than writing mapped_fstream from scratch, since writing the constructors (and typedefs) is the principle difficulty.
You didn't notice the extra "rdbuf" and "is_using_internal_streambuf" helper member functions? I admit that the examples basically are doing the repetition you're complaining about. But, it's better than nothing, right?
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?" 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. [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. [SNIP]
1. Having separate classes for const and non-const pointers leads to far too many templates. Const-correctness can be enforced by the stream buffer by not allowing constructors taking const char* to set the put area.
I deliberately didn't want that. The old std::strstream class has at least three distinct modes. It can act like std::stringstream, like pointerstream, or like iconstpointerstream. And I think it can sometimes switch between those behaviors in mid-use. I wanted separate classes for those uses, especially after the Standard only included one separation.
I know. The problem with strstream is that it does too much. It's good to get rid of allocation functions. But the didea of a stream which can be opened in read-only, write-only or read-write mode is very familiar. It's much better than multiplying the number of templates by 2.
The pointer stream and its pointer-to-const variant have different semantics. Shoving the const variant into the main one would be a repeat of the std::strstream mess. Wouldn't you want a mistake in building constructor arguments cause an error directly instead of activating a different, unwanted set of semantics? [SNIP]
The "?count" member functions can return the seek positions in a much faster way.
Faster because there's no virtual function call?
Yes. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com