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
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...),
template
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.htm... 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.