Reading and writing with files using WinAPI in C++

Question

This problem is quite "a classic", but I can't find a good solution to it.

I am using CreateFile to open a file. Sometimes I would want it to be read-only, sometimes write-only and sometimes I would want the same file to support both read and write. Of course I would like to follow RAII principles.

I am trying to accomplish multiple goals and not so sure how:

1. If a file was opened only for reading, I don't want it to be possible to write to it (which will result in a runtime error/undefined behaviour). In other words, if file1 was opened with read-only permissions I want file1.write_to_file() to not even compile. What that means is that I can't have one large File class with both read and write operations.

2. I don't want to expose the handle that is returned in CreateFile. The handle absolutely cannot be a public field nor can it be returned from a public getter in the class where it will be stored.

I think it is pretty evident that a basic File class will be necessary. File will call CreateFile and hold the handle returned from it. How should I proceed from there?

1. If I define ReadFile and WriteFile that inherit from File, how would I define ReadWriteFile? I would like to avoid multiple inheritance and virtual inheritance.

2. If I try to go for composition (making File a field of ReadFile), how will ReadFile get the handle to the file from File?

3. A third way is to not define File. Only ReadFile, WriteFile and ReadWriteFile, however that introduces some code duplication because the constructor and destructor of ReadFile and WriteFile would be very similar.

Please do not offer to use fstream or other methods that do not rely on WinAPI.

Answer 1

If I define ReadFile and WriteFile that inherit from File, how would I define ReadWriteFile?

Exactly the same: as a direct derivation from File.

And your next question will be probably how to avoid the code duplication. This can be achieved by moving all common code to File as protected methods, and let ReadFile, WriteFile and ReadWriteFile contain only methods which delegate to them, like

// public
void WriteFile::write_to_file()
{
    // defined in base class File
    write_to_file_internal();
}

Now you may wonder what about ReadWriteFile::write_to_file - yes, the method will exactly look the same as WriteFile::write_to_file - but this is only delegational code, no duplicated logic, and the DRY principle is about how not to duplicate any logic.

All the other methods (as well as the constructor, which should be protected for File as well) works the same way: accept the little amount of boilerplate, but the common logic will only exist once, in File.

Up to this point, there is no MI and no virtual inheritance involved. However, you may want instances of ReadWriteFile to be usable in places where some code does something with instances of WriteFile or ReadFile. The canonical solution then is to introduce two common interface classes, with pure virtual methods. So ReadWriteFile and ReadFile will both inherit from IReadFile and File, ReadWriteFile and WriteFile will both inherit from IWriteFile and File.

So yes, this extended solution requires MI, but with only one implementation inheritance (from File), and all other derivations using interface inheritance. This is a common way how MI can be used in a mostly unproblematic fashion.

Answer 2

I think it is pretty evident that a basic File class will be necessary. File will call CreateFile and hold the handle returned from it. How should I proceed from there?

Taking some inspiration from fstream, I would add some very basic file operations to File: Just reading and writing single characters, maybe also an array of characters but nothing more fancy.

Then, have the classes ReadFile and WriteFile that use composition to hold a File object, but they can also accept a File object from external using a protected constructor. ReadFile and WriteFile offer a user-friendly interface for respectively reading and writing a file.

The ReadWriteFile would use multiple inheritance (non-virtual) to inherit from both ReadFile and WriteFile and provides both base classes with the same File instance for the composition.

This would accomplish both your stated goal, as well as the unstated goal that you can pass a ReadWriteFile instance to a function that expects a ReadFile or WriteFile reference.

Answer 3

You say you don't want to use fstream, but have you considered that you can write your own istream/ostream implementations that use whatever you like? e.g. https://stackoverflow.com/questions/13703823/a-custom-ostream

More simply, I think you'd benefit from making a distinction between file and stream. C# does this with its File class. You'd still need three different File classes to do it the way you want, but you only need a read stream and a write stream. There would then be a way of making both a read stream and a write stream given a ReadWriteFile().