On Sun, Apr 5, 2009 at 01:53, Adam Nielsen
I'm wondering whether a good approach would be to extend the Boost Filesystem library so that it can open these files as if they were folders. That would allow the users of this library to work with the contents of the archive files in the same way they might work with "real" files in a directory on the local system.
Can the Boost Filesystem library be extended in this manner? If so, does anyone have any pointers as to what classes would need to be implemented to achieve something like this? Would it still remain somewhat independent of the underlying filesystem code, so that it would still be cross-platform?
I don't think there's any nice way to extend boost.filesystem, since it's all just global functions. The only thing I could think of would be making your own namespace and wrapping the normal functions in ones that check for archives. That requires changing all your code that currently uses the old namespace, but I think that's unavoidable unless you re-write the library. I do think there'd be something to be said for making filesystem a class instead of a namespace. There's already the concept that path operations should be independent of the filesystem, so this would allow it to be separated out nicely. For example, path would have just string(), file_string and directory_string would need a filesystem context, and the external_ versions would be removed. The status, predicate, attribute, and operation functions would also be members of the class, while the convenience functions would be global, making their categorization obvious. Of course, the context would always default to the native filesystem, so the changes would be hidden by default. But that's more than you'd want to do just now, I'd bet.