smart pointer issue with file

[leo2008]

Hi

I am facing a problem while trying to create file manager using smart pointers.
Which option (unique_ptr, shared_ptr, auto_ptr, weak_ptr) is more optimal here?
1) File manager needs to cache the resources, but only if people are using those resources.
I plan to use unique_ptr?

2)The manager must allocate resources locally.
Can be done using unique_ptr?

3)Multiple objects require access to the same file.
Resolve using shared_ptr?

[jonnin]

something is missing here.
you said:
I want to build an airplane.
what wrench should I use?
The airplane will seat 75 people, does that mean my wrench should be metric?

your internal data structures and tools have little bearing on the fact that you are dealing with disk-files. I am completely guessing, but it sounds like your program needs to be like a code repo -- you want to check files out from a server, copy them to the local disk, allow user to edit them, track the changes, and push the changes back up to the server once done, with no mention of what if multiple people want to do this at one time without awareness of each other and how that would work. (Am I close??)

say exactly what you are doing, as best you can.

[leo2008]

File manager basically deals with files and perform various operations like listing, reading, writing, opening, closing etc on it. These files store data permanently on storage device. So there is a need to cache those resources and use it only if someone needs it and file manager does this allocation of resources. When there are multiple objects that tries to access to these files, need to find a way to resolve it. Which smart pointers are ideal in this context?

[Peter87]

If you sometimes want to remove cached resources, but only if they are not currently in use, then it sounds like shared_ptr could help you with this. If you want to free the resources as soon as possible I imagine the file manager could store weak_ptrs to the resources. If you want the file manager to hang on to the resource for longer it would have to store shared_ptrs and you have to decide when you should get rid of them (perhaps based on the time since the resource was last requested?).

[Cubbi]

leo2008 wrote:

So there is a need to cache

if there's a need to cache, then you need a cache.

access to the same file.

Define "same" and that's your cache key type.

those resources

define "resources", and that's your cache value type (and if there's a type hierarchy, that's where unique_ptr<ResourceBase> comes in)

Then you can start prototyping with std::unordered_map<key type, value type>, while you decide what the retention policy is.

Speaking of which,

only if people are using those resources

- so retention is while "using", however that is defined. Given that file manager's API consists of "operations like listing, reading, writing, opening, closing" I'll guess that "using" here means "the open API was called, but close API with the same file key was not called". There are a few ways to arrange that without any additional pointers.

[jonnin]

Maybe I am just slow today, but I hope you understand this, and maybe you do:
- smart pointers can prevent your one program from messing up internally.

- they do not prevent opening the file more than once, or other programs from opening the file when you also have it open. They offer NOTHING that protects your disk files; your objects need to do that on the side.

- for example, you can have 3 file objects open the same file and read it at the same time, and each one edit the buffer and write it back. The last one to write is the copy that is kept!

smart pointers CAN help with issues like the above, yes, but you may also want additional protections so that a bad code edit or bug can't mutilate your data now or in the future.

I guess what I am saying is that a smart pointer can keep you from doing something bad to the SAME object, but it can't prevent having multiple objects that look at the same disk file. If you can manage your code so that is done safely, it may be what you are really wanting (?).