Sign in to follow this  
Quat

File Loading

Recommended Posts

Quat    568
This question depends on the program, but I am interested in general thoughts. 1) Do you think it is good practice to put file loading in one place in your code, and then pass pointers to the loaded data to object constructors? 2) Or do you prefer to pass the file names to the constructors, and let the objects do the loading? (2) seems reasonable (objects know how to load themselves from file), but if several objects need copies of the same data, then you load the data several times with this approach. It also means you may have file error handling code in several places instead of one localized place. Thoughts?

Share this post


Link to post
Share on other sites
krez    443
i also prefer #1 because it makes it relatively simple to swap out the files for, say, a file package (i.e. zip file, PAK, etc) or in-memory buffer.

Share this post


Link to post
Share on other sites
Aressera    2919
#1, because it separates the disk representation of a class from it's actual implementation. i.e. you could have different representations of the same class for different applications (loader.loadFooFromNetwork(&foo) vs. loader.loadFooFromDisk(&foo)).

Obviously, you have to allow the necessary accessor methods to be able to truly externally load any class.

Share this post


Link to post
Share on other sites
nife87    520
#1, since you cannot decouple the systems with #2.
Try to search for virtual file systems (also named VFS) here on GameDev.
I have made a little VFS for my own project, and it really gives me a great deal of new opportunities regarding many aspects of resource loading.
Not that your project needs anything as complicated as a VFS, but it will give you an idea of the possibilities, when file loading gets decoupled from the actual resource loading.
As for the loading of data several times, you might also want to take a look at resource management systems, also available by searching for it on GameDev.

Share this post


Link to post
Share on other sites
Hodgman    51220
#1 is the best from a maintainability perspective.

But if you also like #2, then you can reconcile these two ideas by passing the filename AND a reference to a "file-system object" to the constructor.

The constructor can then use file-system object to load the data stored at the filename. The filesystem object can keep track of which files are already loaded to avoid multiple loading, etc...

The filesystem object could just be a wrapper for fopen/fclose, or it could be a wrapper for a ZIP/package format.

Share this post


Link to post
Share on other sites
random_thinker    282
If you're talking about C++, then for item 1, you've got to really be careful about the pointers, this approach could seriously crash your program. Also, files and file streams have their own problems associated with the stream state, so again you must be careful if applying pointers and reusing file data from a file stream.

For Item 2, you can use RAII approaches, as illustrated here, to wrap fstream and handle errors, so that you don't need provide error messages all over the place.

As for me, if the files are relatively small then I don't overly concern myself with the cost of opening them more than once. If the file data is used a lot, then I'll open them once and read them into a file_image variable (or a container) and use this repeatedly.

However, if the files are very large, as is often the case for numerical analysis, then there may be no choice but to use approach 1 above.

To me, the less that file (disk) access is used, the better, so loading the data into a buffer or data holder of some sort and then closing the file stream as soon as you can is the better option.

--random

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this