Sylvester-Bradley, Gareth wrote (in private email):
Jonathan Turkanis wrote:
I guess streambuf_wrapper / stream_wrapper suffer from the same lack of to/from clarity as streambuf_adapter / stream_adapter?
To me they sound unambiguous, but with the wrong meaning.
7. stream_buffer /stream 8. buf /stream
The problem with stream_buffer is that it doesn't match the std:: names, for no good reason.
The reason, of course, is to avoid duplicating the standard name. It's basically like std::mem_fun/boost::mem_fn.
The problem with stream is that it's only fluke that it doesn't conflict with the std:: names.
I don't mind flukes. ;-)
On the other hand, IMO buf is definitely too generic because it doesn't make it clear that it's about iostreams. If we're "using boost::iostreams" or Boost.Iostreams was considered for promotion to the standard library, that's a problem.
I'm aware of this problem.
Can I offer another suggestion, taking inspiration from several other Boost libraries, like enable_if, result_of, etc?
How about streambuf_from / stream_from (or _with, _of, _on, _over, ...)?
Iostreams also uses this type of name: category_of, char_type_of and mode_of. streambuf_from / stream_from look pretty good when they are specialized: streambuf_from<array> stream_from<socket> but I'm afraid they will look funny in documentation. E.g., The fundamental component provided by the Iostreams library is the class template streambuf_from, a derived class of std::basic_streambuf which performs i/o by delegating to a contained Device. I'll definitely consider it, though.
Gareth
Jonathan