[Scummvm-devel] PORTERS: New OSystem API for loading/storing default config file

Max Horn max at quendi.de
Sun Aug 10 00:51:00 CEST 2008

Am 09.08.2008 um 20:21 schrieb Andre Heider:

> hi,
> a little late, but i just updated my local tree and noticed something:
> ConfigManager::loadDefaultConfigFile() contains:
> SeekableReadStream *stream = g_system->openConfigFileForReading();
> assert(stream);
> the default implementation of openConfigFileForReading returns NULL  
> if the file does not exist. scummvm now aborts if thats the case,  
> thats a different behaviour now. is this intentional?
> substituting the assert with "if (!stream) return;" restores this  
> behaviour.

Oops, good catch that was a clear mistake on my part. Thanks for  
pointing it out. I just commited a fix.

> also, system.cpp contains this comment:
> Ideally, the default OSystem::openConfigFileForReading/Writing methods
> should be removed completely.
> so should i implement these function in my port? the default (open  
> scummvm.ini in the current dir) is exactly what i want.

To be honest, I am a little bit torn on that one. For other OSystem  
methods, we deliberately wanted to phase out the default  
implementations for various reasons. For example in getTimeAndDate(),  
we relied on using localtime, which does not exist on some ports, so  
having the default implementation use that caused compilation & linker  
problems for those ports. So we opted to get rid of the default impl,  
instead of using #ifdef trickery. As #ifdef magic is IMO a bad idea on  
the long run, because it means porters have to maintain code outside  
backends/, which can become tricky and easy to overlook.

Here, things are bit different, though: The default implementation  
just needs Common::File and Common::DumpFile, which will always be  
around. So, on the one hand, seems to be no harm in keeping that  
default implementation around, I guess. On the other hand, once the  
code is switched to FSNode::openForReading & FSNode::openForWriting,  
those default methods will be one liners...


More information about the Scummvm-devel mailing list