Subject: Re: [boost] boost::filesystem::path frustration
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2013-01-28 08:34:09
In a previous job, I had to work very heavily with file systems and Windows
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
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?
On Sun, Jan 27, 2013 at 9:22 PM, David Hagood <david.hagood_at_[hidden]>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
> 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/**
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk