luni
Well-known member
Frank, I think we are taking past each other. IMHO your implementation of MemFile is a valid implementation of File, it provides all methods it needs to provide. I can write a function which takes a File as parameter and it will happily accept your memFile.
One can argue if the API should enforce the implementer to explicitly define the API (that would be pure virtual) or if the API provides default values and the implementer only implements what he wants (that's the current solution with the virtual functions which provide default implementations). For me that is a matter of taste only. At the end of the day both methods provide implementations of all functions required by the interface.
One can argue if the API should enforce the implementer to explicitly define the API (that would be pure virtual) or if the API provides default values and the implementer only implements what he wants (that's the current solution with the virtual functions which provide default implementations). For me that is a matter of taste only. At the end of the day both methods provide implementations of all functions required by the interface.
That's a different story. The open is not part of the File API but belongs to the Filesystem. Of course opening a file on a SD works differently than your memory file or some file streamed via a serial interface. Personally I would remove the open functions from the FS interface since it depends on the Filesystem you are implementing. Technically, as you have seen, you don't need to implement the FS interface at all. Just generate some open function which returns a File object and it works.Plus, it needs a different open() and has no filenames.