filebuf extensions (was Re: feb-2002 libstdc++ outstanding)

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

On Mon, Mar 11, 2002 at 11:32:22AM -0800, Benjamin Kosnik wrote:

> Sorry, I wasn't very clear. I was attempting to point out that instead of 
> cramming extra bits into basic_filebuf, it is now my belief that 
> libstdc++ should be using derived classes for all non-standard 
> filebuf-related functionality. This is a departure from current practice, 
> but one that I think is best in the long run.
> 
> At the moment, this includes filebuf::fd. There are a lot of requests for 
> a fd-based filebuf ctor. There is a non-standard FILE* filebuf ctor. 
> There are requests for setting permissions on newly created files.
> Etcetera, etcetera, etcetera. 

I haven't seen any of the filebuf-derived classes, so this is something
of a stab in the dark, but how about using a policy-based model, as Andrei
Alexandrescu shows in Modern C++ Design?
That would allow users to extend the classes as they desire by writing a
new policy class to be used by the filebuf. I'm not sure how well it maps
to alternative constructors ... but umasks and conversions such as FILE*
to fd might be quite appropriate to that sort of design, where specific
features are delegated to a policy class. I think this would also account
for certain functionality only being available on certain platforms,
e.g. initial file modes could be set by a Umask_rwxr__r__ policy, which
simply wouldn't exist on platforms where those modes makes no sense.

As I said, this is off the top of my head, and may not be doable, or fit
the libstdc++ style, it's just an idea that occurred to me.

jon


-- 
"Convictions cause convicts"
	- Mal2