|
From: Christian C. <chc...@cl...> - 2001-08-13 05:50:53
|
Eric Bezault wrote : > > Christian Couder wrote: > > > > If what you say is true, perhaps it could still be possible to define > > the meaning of "eof" depending both on the target platform and the > > compiler. > > So that for example eof would always be "%N" if SmallEiffel is used, and > > it would be "%N" on Unix or "%R%N" on Windows if another compiler is > > used. > > And then: > > > For example if you want to set a multi-line message in a message box, > > you can use one of the following : > > > > 1) > > > > msg_box.set_msg(error_header + eol + error_msg + eol + help_msg) > > These two suggestions seem incompatible to be. > Under Windows with some Eiffel compilers 'eol' will be > %N just to make sure that %R%N (and not %R%R%N) is actually > written to files, but then in your message box you really > want 'eol' to be %R%N because you are now dealing with > strings and not files anymore and the compilers do special > treatments for %N only in files and standard files, not > in strings. In my opinion, the compilers shouldn't cconvert "%R%N" to "%N" when reading from a file and then back from "%N" to "%R%N" when writing to a file. I think there are many good reasons why using something like "eol" would be better for them than doing this. First it's faster not to convert anything. Then it's also less disturbing for the user to see that when he reads a file into a string then the size of the string is the same as the size of the file he read. Now if they prefer to do convert, then library developers should also, if needed, convert back and forth in features like set_msg and get_msg, which is another reason why converting is bad. Regards, Christian. |