[Scummvm-devel] File handling revamp

Pawel Kolodziejski aquadran at xtr.net.pl
Fri Aug 1 19:37:46 CEST 2008

On 2008-08-01, at 16:23, Max Horn wrote:

> Am Fr, 1.08.2008, 13:30, schrieb Torbjörn Andersson:
>> Max Horn wrote:
>>> Hu? No, the String class has nothing to do with it. The only thing  
>>> that
>>> is
>>> relevant here is that currently we alreays open files in binary  
>>> mode,
>>> never in text mode, hence the system does not perform automatic  
>>> endline
>>> conversion for us.
>> I probably misunderstood him. (Or maybe he was talking about  
>> residual,
>> but that might not make any difference either.)
> I just checked the logs. I guess what he meant was that writeString is
> simply using the same code as writeByte, so that it doesn't make a
> difference whether you write the char '\n' or the string "\n". True  
> enough
> :)

Right, I thought it was cut in string class because I used only "\n",  
but actualy it's not enought.
This way is good writeByte('\r'); and writeByte('\n');

>>> Could you remind me again why we need to support this for anything  
>>> but
>>> config files? :)
>> I can't think of anything. I was thinking of a separate function  
>> because
>> the config manager writes newlines in a couple of places.
> OK...
> Well then the quick&dirty and practical fix would be to just augment
> config-manager (and config-file ?). A more generic but still simple
> solution would be to add a new method
> int WriteStream::writeEndline() {
> #ifdef WIN
>  return writeString("\r\n"); // or was it the other way around?  
> Anyway,
> you get the idea
> #else
>  return writeByte('\n');
> }
> That way we can still write clean code.
> Or, well, we introduce text mode for this, which of course would be  
> the
> most generic and flexible solution (e.g. you could then just write
> arbitrary strings with newlines in them, w/o worrying about using
> writeEndline()). We could do that by either adding a new "textmode"  
> flag
> to the open() method, or by adding a new TextFile class, which
> automatically enables this. Ports which don't have a separate  
> textmode, or
> just don't want to worry about this, would have to implement no extra
> code.
> An intermediate solution would be to add a new wrapper stream class:
> TextWriteStream, which could encapsulate arbitrary streams, and when  
> it
> detects a '\n' being written, it automatically converts it to another
> sequence (for systems which don't need it, it would just call  
> through, so
> adding very little overhead).
> It would be easy to implement, and requieres nothing else to be  
> changed.
> Finally, for the default config file: If we apply my patch from that  
> other
> thread, then it is up to the backend to create the config file read/ 
> write
> streams, so it would be easy enough for a backend to use "fopen" in  
> text
> mode (e.g. on Windows). Of course that doesn't cover custom config  
> files.
>> The reason I brought it up here was because you said IRC wasn't a  
>> good
>> place to discuss bugs/missing features. ;-)
> Yes, that was perfectly right. Thanks for doing it!
> Cheers,
> Max
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel

More information about the Scummvm-devel mailing list