From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-07-13 16:42:15
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
> 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:
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
I'll definitely consider it, though.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk