IReadFile - Should it really force a user to open a file?

[Halifax]

Well this seems a little disturbing to me. IReadFile does not allow you to close a file by yourself, it does it in the destructor, and it doesn't allow you to create an IReadFile to read multiple files. This doesn't necessarily follow the rules of a FILE, and it also doesn't allow a user to free up memory if it isn't used anymore, and forces them to use more memory if they don't plan on reading files sequentially.

My proposal is the take the opening and closing out of the constructor and destructor, respectively. Then add those to functions named openFile(), and closeFile(). This would allow the user to read multiple files with only one IReadFile, e.g.:

Code: Select all

IReadFile* myFile;
myFile->openFile("test.txt");
myFile->closeFile();
myFile->openFile("test2.txt");
myFile->closeFile();

instead of

Code: Select all

IReadFile* myFile = new IReadFile("test.txt");
IReadFile* myFile2 = new IReadFile("test2.txt");
... etc ...

IReadFile* myFile = new [/code]

[bitplane]

Hmm wouldn't that tie the interface to actual physical files, or force it to have a link to the IFileSystem?
For example, openFile and close have no meaning on a memory file, like if it exists inside a zip file and the memory was allocated by the zip loader.

[hybrid]

Moreover, IReadFile does not mean IFileReader. It's just one file, you can read it. If you want to read another file, create another IReadFile. No memeory overhead, because you can close the first one. Only minor allocation/deallocation, but neglectable when looking at reading times of the actual file.

[Halifax]

Alright, fair enough, thanks for explaining.