3 ms·
From glossing over the spec, it seems as if this does not include a file system abstraction. Operations are based on `path` objects; there's no additional state
by Nitramp 12y ago
From glossing over the spec, it seems as if this does not include a file system abstraction. Operations are based on `path` objects; there's no additional state or context that'd allow e.g. implementing a virtual in memory file system without support from the operating system, or an additional user context to be used for a networked file system that needs user credentials, etc.
In effect this looks a lot like Java's java.io.File (modulo some of the design warts in that), which in Java land people are trying to replace with FileSystem and Path (http://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html http://docs.oracle.com/javase/7/docs/api/java/nio/file/FileS...). Java's Path is specific to a file system, so that users can implement their own FileSystemProvider (http://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html http://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/F...).
I wonder why they went that way? Or am I missing something?
- tedunangst 12y agoLooks like they're just including posix semantics. But it is weird and I don't see the point. The only platforms likely to offer this interface already offer the posix interface. If I'm on a posix system, I can just call stat(). Calling filesystem::is_socket() would only make my code less portable by restricting it to the latest c++ runtimes.
- roel_v 12y ago"Looks like they're just including posix semantics." No they're not. Filesystem is an abstraction of paths, directories, file status and the like. For example, posix doesn't have a notion of 'platform native display format' (i.e. slash as directory separator on Windows), so without a library like filesystem you have to write your own abstraction layer for that sort of stuff.
- tedunangst 12y agoThe particular set of file types recognized (character device? block device?) are clearly ripped straight from posix. It even says implementations should try to match posix. But ok, yes, this is more than just posix. This is posix plus directory separator character. FWIW, I've found automagic backslash handling more trouble than its worth. Everything seems to just work until it doesn't. A pathname is inevitably "pretty printed" on Windows which then makes its way as input to a unix system where it's interpreted incorrectly. Of course, back then we called this boost.
- roel_v 12y agoThe scope is just to provide a way to write cross-platform path manipulation code. C++ is a much more stable (for better or for worse) language than Java is. Filesystem has been developed for 10+ years, and now that the current version works well, it's promoted to the standard. Whoever will want to write virtual file systems isn't going to bother with std::filesystem anyway.
- sedeki 12y agoNewbie here. Just curious, why wouldn't someone use std::filesystem to write virtual file systems?
- roel_v 12y agoNot sure I understand the question - std::filesystem is 'just' a (mostly) cross-platform abstraction of files and directories, it doesn't know or deal with the concept of 'filesystem'. (maybe the problem is in terminology - 'filesystem' in std::filesystem doesn't have anything to do with 'filesystem' as in ext4, zfs etc.)