Question

I have had a template for some time which wrappers a C library FILE*. It’s a fairly classic implementation of a shared pointer to a wrapper class for the FILE*. The reasoning behind using my own custom shared pointer is to provide free function replacements for some of the C library FILE* free functions, in order to allow me to do a drop-in replacement of legacy code that works with FILE*.

The implementation that I have uses an inner wrapper that guarantees that when it is deleted, the owned FILE* is closed. RAII.

However, I’ve come into the need to create a similar system to handle the case where I want the underlying FILE* to be flushed & truncated, rather than closed when the last FILE* holder is destroyed. That is to say, I have an open FILE* of the original guaranteed-to-close type, but wish to hand out an unowned copy of the FILE* to another object that is going to guarantee that when it’s last instance is destroyed, that it will flush & truncate the FILE* rather than close it, hence leaving me with the underlying FILE* in an open state, but with the contents of the stream flushed to disk (and the file size reflecting only valid contents).

I have solved this trivially for compile time polymorphism. But I need some way to supply runtime polymorphism, and I really don’t want to put yet-another-layer-of-indirection into this scenario (i.e. if I used a polymorphic pointer to either an auto-close or auto-flush FILE* wrapper, I’d be golden – but I really want to keep the same depth I have now and hide the polymorphism inside the custom shared pointer implementation).

Basically, if I have a:

template <class WrapperT>  
class FilePointerT  
{  
public:
  // omitted: create, destroy, manipulate the underlying wrappered FILE*  
private:
  WrapperT * m_pFileWrapper;  
  ReferenceCount m_rc;  
}

Obviously, tons of details omitted. Suffice it to say that when the last one of these objects is deleted, it deletes the last m_pFileWrapper (in fact, if I were rewriting this code, I’d probably use a boost::shared_ptr).

Regardless, the real issue here is I am stumped on how to have a FilePointerT<WrapperT> whose WrapperT can vary, but can then be used in code as if they were all the same (which, after all, they are, since the implementation of WrapperT has zero affect on the structure and interface of FilePointerT (essentially a pimpl).

What can I declare that can possibly hold any FilePointerT<WrapperT> for any WrapperT?

Or, how can I change the definition of FilePointerT in order to allow me to supply specific WrapperT?

Answer 1

For what it’s worth, what I ended up doing is to embed the wrapper into the FilePointer class, instead of making it part of its type.

class FilePointer
{
public:
    // create using a file wrapper (which will handle policy issues)
    FilePointer(FileWrapper * pfw) : m_pFileWrapper(pfw) { }

protected:
    FileWrapper *   m_pFileWrapper; // wrapper has close/flush policy
    ReferenceCount  m_references;   // reference count
};

Then the file pointer just delegates the real work to the wrapper, and the wrapper implements the needed policy, and code can be written to consume FilePointer(s).

There are obviously other ways to do this, but that’s what I went with.