In a previous job, I had to work very heavily with file systems and Windows registry trees. For that use-case, I took paths and put them in a structure that represented a tree view of the system. That is, I iterated over the file system and created a tree to represent all the paths. Currently, I use the file system in a very light sort of way, and I very much enjoy the use of boost::filesystem as it exists. As such, I'm not sure I'd want to change it overmuch from its current behavior. If anything, I almost wish we had a boost::registry for Windows that provided much of the same kind of functionality in boost::filesystem, but for the Windows registry. I say 'almost', though, because I don't really like to use the Windows registry at all, and use INI files for configuration information instead. If I had to return to my previous job, though, I would probably want to use a directory iterator to help build a tree, and to extract boost::filesystem::path objects out of that tree as desired. But then, I'd also want somewhat complicated algorithms that compared different trees to obtain differences (paths removed or created). Would it be helpful to have a kind of boost::tree that could be built by one or more iterators, which had properties like a container, but generali(z/s)ed such that it could be built by iterators over a file system or a Windows registry, or some other mechanism that can build trees? - Trey On Sun, Jan 27, 2013 at 9:22 PM, David Hagood <david.hagood@gmail.com>wrote:
In fact there probably ought to be an object representing the local
filesystem, so you could also (in principle) do operations on a remote filesystem.
FYI: In the Software Communications Architecture (SCA), used in various software defined radio implementations, that is how files are handled - file systems are CORBA objects, as are files.
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>