File Loading
Author
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?
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.
#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.
Obviously, you have to allow the necessary accessor methods to be able to truly externally load any class.
#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.
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.
#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.
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.
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement