Note that there are some explanatory texts on larger screens.

plurals
  1. PODeriving from streambuf without rewriting a corresponding stream
    text
    copied!<p>Some days ago, I decided that it would be fun to write a <code>streambuf</code> subclass that would use <code>mmap</code> and read-ahead. I looked at how my STL (SGI) implemented <code>filebuf</code> and realized that <code>basic_filebuf</code> contains a <code>FILE*</code>. So inheriting from <code>basic_filebuf</code> is out of the question.</p> <p>So I inherited from <code>basic_streambuf</code>. Then i wanted to bind my <code>mmapbuf</code> to a fstream.</p> <p>I thought the only thing that I would have to do would be to copy the implicit interface of <code>filebuf</code>... but that was a clear mistake. In the SGI, <code>basic_fstream</code> owns a <code>basic_filebuf</code>. No matter if I call <code>basic_filestream.std::::ios::rdbuf( streambuf* )</code>, the filestream completely ignores it and uses its own <code>filebuf</code>.</p> <p>So now I'm a bit confused... sure, I can create my own <code>mmfstream</code>, that would be the exact copy/paste of the <code>fstream</code> but that sounds really not DRY-oriented.</p> <p>What I can't understand, is: <strong>why does <code>fstream</code> is so tightly coupled with <code>filebuf</code>, so that it is not possible to use anything else than a <code>filebuf</code>?</strong> The whole point of separating streams and bufs is that one can use a stream with a different buffer.</p> <p>Solutions:</p> <p>=> <code>filestream</code> should rely on the implicit interface of <code>filebuf</code>. That is, fstream should be templated by a streambuf class. That would allow everyone to provide its own streambuf subclass to a <code>fstream</code> as long as it implements <code>filebuf</code>'s implicit interface. Problem: we cannot add a template parameter to <code>fstream</code> since it would break template selectors while using <code>fstream</code> as template template parameter.</p> <p>=> <code>filebuf</code> should be a pure virtual class without any additional attributes. So that one can inherit from it without carrying all its FILE* garbage.</p> <p>Your ideas on the subject ?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload