From: "Jonathan Turkanis" <technews@kangaroologic.com>
Rob Stewart wrote:
From: "Jonathan Turkanis" <technews@kangaroologic.com>
Rob Stewart wrote:
From: Thorsten Ottosen <nesotto@cs.aau.dk>
Jonathan Turkanis <technews <at> kangaroologic.com> writes:
You may find these a bit redundant, but what about "iostream" and "iostreambuf?"
'iostream' suffers the same problem as 'streambuf': it already names a type in namespace std.
Right. Same problem/same opportunity to ignore until standardization.
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.")
I think I need to keep stream and streambuf as components of the names, because I don't want to rename filtering_stream/filtering_streambuf.
Well, whatever you call generic_stream and generic_streambuf, can't filtering_stream and filtering_streambuf follow suit?
Maybe a departure from "stream" is in order: pipe, pipeline, formatter, ...?
'pipeline' is already used for the return type of expressions like
gzip_compressor() | base64_encoder() | file_sink(...)
Yeah, I was just trying to find something that might work or trigger a thought in your head.
I may use the name 'pipe' for wrappers for operating system pipes, or portable
Sure.
replacements. 'formatter' seems in appropriate, since for now the library handles only unformatted i/o, relying on the standard iostreams library to provide a formatting layer.
Agreed.
Maybe I could go Alexandrescuesque:
flex_stream, flex_streambuf
Well, due to the PBD, they are flexible.
Or black separatist:
xstream, xstreambuf
Actually, this looks pretty good. Maybe it would run afoul of the prohibition against cryptic names; there's a precedent, however, in xtime from Boost.Threads.
The "x" can imply "extension" or "extended," so that does work pretty nicely. Besides, it keeps the names short. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;