[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...
Cheers,
Max
More information about the Scummvm-devel
mailing list