From: "Jonathan Turkanis" <technews@kangaroologic.com>
Rob Stewart wrote:
From: Thorsten Ottosen <nesotto@cs.aau.dk>
Jonathan Turkanis <technews <at> kangaroologic.com> writes:
Hmmm. I agree that the original names are misleading. They don't create a facade over another class, they are provide the functionality directly. However, "generic_streambuf" sounds too, well, generic.
Meaning the names are pretty dull? Thats true. I guess I could call them platinum_stream and platinum_streambuf ;-)
:0) I didn't mean dull so much as redundant or even useless (as in not providing any benefit).
Is there are reason not to call them simply "stream" and "streambuf?"
I like these, except that streambuf is a typedef in namespace std for basic_streambuf<char>.
Yeah, that would be a problem if they were standardized, but there are likely to be a number of changes should they be standardized, that I'm not sure this is worth worrying about. OTOH, your concern about duplicating a name from the standard library that isn't intended as a replacement is well-founded.
If you're concerned about the possibility of typedefs or other uses of those names in either the std or boost namespace, then how about "policy_stream" and "policy_streambuf?"
These are very good, but I've tenatively decided to downplay the policy-based aspect of the design. I know at least one person who was turned off by the description of the library as involving policies. While I disagree with his view, and I hope he is not representive of users in general, his reaction made me realize that calling the library policy-based doesn't really add much.
A reasonable position, that.
Still, I like these names, and will think about using them.
You may find these a bit redundant, but what about "iostream" and "iostreambuf?" Another approach, which I like less, but might give you an idea, is "streamer" and "streambuffer." (Well, "streambuffer" is just fine, but I don't care much for "streamer.") Maybe a departure from "stream" is in order: pipe, pipeline, formatter, ...? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;