Re: [boost] [iostreams] please vote on template names

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
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