Iterating over a directory
in [C++]
|
From: Ulrich Eckhardt on 12 Apr 2010 18:52 Hi! I'm just musing about how to write an STL iterator that walks over a directory. There are two things that create a problem for me: 1. For iterating, I need to use OS functions that allocate a resource. 2. Iterators are generally assumed to be copyable. Holding a resource that can't be copied poses the questions of ownership, which in turn poses the question of how to handle copying. Currently, the only solution that would solve this is shared ownership using some kind of reference counting. Alternatively, I could use exclusive ownership but that would prevent copying and make the iterator less useful. I see that Boost.Filesystem uses a shared_ptr for its iteration metadata, i.e. use reference counting, any other ideas? Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mathias Gaunard on 13 Apr 2010 01:40 On 13 avr, 10:52, Ulrich Eckhardt <eckha...(a)satorlaser.com> wrote: > Hi! > > I'm just musing about how to write an STL iterator that walks over a > directory. There are two things that create a problem for me: > 1. For iterating, I need to use OS functions that allocate a resource. > 2. Iterators are generally assumed to be copyable. > > Holding a resource that can't be copied poses the questions of ownership, > which in turn poses the question of how to handle copying. Currently, the > only solution that would solve this is shared ownership using some kind of > reference counting. Alternatively, I could use exclusive ownership but that > would prevent copying and make the iterator less useful. > > I see that Boost.Filesystem uses a shared_ptr for its iteration metadata, > i.e. use reference counting, any other ideas? Use a simple reference or pointer, and leave ownership to the object you get the iterator from. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 13 Apr 2010 01:40 On 13 Apr., 11:52, Ulrich Eckhardt <eckha...(a)satorlaser.com> wrote: > I'm just musing about how to write an STL iterator that walks over a > directory. There are two things that create a problem for me: > 1. For iterating, I need to use OS functions that allocate a resource. > 2. Iterators are generally assumed to be copyable. > > Holding a resource that can't be copied poses the questions of ownership, > which in turn poses the question of how to handle copying. Currently, the > only solution that would solve this is shared ownership using some kind of > reference counting. Alternatively, I could use exclusive ownership but that > would prevent copying and make the iterator less useful. > > I see that Boost.Filesystem uses a shared_ptr for its iteration metadata, > i.e. use reference counting, any other ideas? If you don't need to support the iterator requirements, I would consider to use exclusive ownership. If you do want/need to support these requirements, shared ownership seems the one and only one possible solution to me in an ownership-controlled system. But in many situations it is possible to let a system look like a shared-ownership control system by simply lacking of the control ;-) The latter approach is simply to provide a reference/pointer to some externally controlled object in the iterator. This is basically, what std::ostream_iterator does with the delimiter and the stream or what the diverse insert iterators do with the referenced container-like object: This is also a shared object, but there is no inherent ownership control. This is a very efficient mechanism, but requires some discipline on the programmer's side. In regard to your resource-allocation problem, the different problem domains can be easily separated: 1) First define some RAII class that ensures that your OS resources will be freed at the end of the life-time of this resource holder. This can be e.g. unique_ptr or some user-defined class. 2) Decide, whether your iterator should completely auto-manage the resource - this basically enforces the shared-ownership control. If complete auto-management is not needed, provide a constructor of the iterator that accepts a reference to the RAII-controller (whichever you prefer - even unique_ptr or some other non-copyable holder will work). Now the user has to take care that if the iterator leaves the current scope, the life-time of the RAII controller is lengthened to at least the same life-type as the leaving iterator copy. In fact it is possible to support both strategies within the same iterator type. This is comparable to what std::unique_lock does via it's different mutex/lock-accepting c'tors. HTH & Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Maciej Sobczak on 13 Apr 2010 09:44 On 13 Kwi, 11:52, Ulrich Eckhardt <eckha...(a)satorlaser.com> wrote: > Holding a resource that can't be copied poses the questions of ownership, > which in turn poses the question of how to handle copying. Currently, the > only solution that would solve this is shared ownership using some kind of > reference counting. Alternatively, I could use exclusive ownership but that > would prevent copying and make the iterator less useful. > > I see that Boost.Filesystem uses a shared_ptr for its iteration metadata, > i.e. use reference counting, any other ideas? Resource descriptors: http://www.inspirel.com/articles/Avoiding_Destruction_Races.html This article is not strictly about iterating, but the problem you are facing is common. The idea in your particular case is that the iterator need not *refer* to the resource (that might be dangerous), but can still *identify* it if given enough information. This can be easily made lightweight and copyable. This approach still leaves open the question of when to actually close the resource - but the solution to this problem is not necessarily limited to the iterator design and might instead involve the whole library usage pattern. -- Maciej Sobczak * http://www.inspirel.com -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
|
Pages: 1 Prev: Why using manystatic methods in a class Next: Type traits and accessibility |