Re: Fwd: Concatenated input streams

From: Gavin Lambert (boost_at_[hidden])
Date: 2022-03-28 23:10:28

On 28/03/2022 19:17, Robert Dodier wrote:
> What I need is for someone to give me some advice about how to
> organize the class declarations. Of which existing Boost class should
> I be deriving from? What is the type of the underlying resources that
> are to be marshalled?
> 
> To be a more concrete, here is a snippet of code which uses existing
> Boost classes to open an input stream.
> 
>      boost::iostreams::file_source fs ("foo.txt");
>      boost::iostreams::stream_buffer <boost::iostreams::file_source> sb (fs);
>      std::istream is (&sb);
> 
> Now I'd like to say something like
> 
>      concatenated_source cs (<list of resources to be marshalled goes here>);
>      boost::iostreams::stream_buffer <concatenated_source> sb (cs);
>      std::istream is (&sb);
> 
> What seems obvious to me is to say
> 
> class concatenated_source: public boost::iostreams::source {
> ...
> }
> 
> but apparently source = device<input> and device says, according to
> the docs (https://www.boost.org/doc/libs/1_78_0/libs/iostreams/doc/classes/device.html#reference),
> 
> template<typename Mode, typename Ch = char>
> struct device {
>      typedef Ch         char_type;
>      typedef see below  category;
>      void close();
>      void close(std::ios_base::openmode);
>      void imbue(const std::locale&);
> };
> 
> Hmm. I was kind of assuming that a generic source would require
> something about reading some bytes and maybe opening or otherwise
> creating something to read bytes from, but that doesn't appear to be
> the case here.

As the doc states, the "source" class is intended as a base class, but 
only as an aid to implementation, not as a requirement.  It does not 
implement all the methods of the Source concept because (like the 
standard library) it relies on template duck-typing and not virtual 
methods.  As such, a Source need not actually derive from source.

Have a read of 
https://www.boost.org/doc/libs/1_78_0/libs/iostreams/doc/concepts/source.html 
for the full interface.  (You'll also have to read some other concept 
pages for additional methods "inherited" but not via C++ inheritance.)

In addition to the required methods, you can define additional ones as 
needed by your specific implementation.

You may also want to read the actual implementation of e.g. file_source, 
but only to compare it with the concept documentation.

Note that due to the duck-typing, to properly implement a concatenation 
of generic sources you'd have to use a templated entry method and 
heterogeneous type-erased collection mechanism, which may not be for the 
faint of heart.  Implementing a file_source-only concatenation would be 
more straightforward but less flexible.

Template concepts are powerful, but they can be quite a pain to deal 
with at the provider end.