🚀 go-pugleaf

In article <3C87D1AC.1521FAB0@vernier.com>,
 Christopher Corbell <ccorbell@vernier.com> wrote:

>The reason I want that is also simple, I think: I develop 
>a cross-platform application, and use standard C++.
>Our file io code is shared across platforms.
>I think that's what the standard library is for.

Then you shouldn't use std::endl, either, because there are no 
guarantees what character (or characters!) it will produce.

>We have one text-based file format, and files 
>saved from one platform must open fine on the other 
>platform.  The newline issue as whitespace in the XML
>file is a convenience: we want users to be able to 
>look at the file in a native text editor.

If you want users to be able to look at the file in a native text 
editor, then you must use native newlines. That means that your files 
need to be converted when going from platform to platform. But you say 
that you don't want that?

>Internally,
>however, some elements contain text in which 
>whitespace is significant, including newlines; 

Encode the newlines when you write them to the file. That way you will 
know what the file contains, always, and it will not be translated, 
ever. Oh, but then your users need to know to do that when they edit the 
file in an editor.

>Thanks for the information on what it's really doing.
>However on this issue, I do believe that CodeWarrior 
>has it wrong; there should always be a way to turn
>off literal substitutions and have an ANSI character
>escape sequence mean what it means.

There is. Don't turn on CR/LF remapping, and don't open files in text 
mode (see what Howard said).

>Also, I don't quite see why you don't recognize
>the inconsistency in the terminology.  If the 
>functionality is "Reverse CR and LF", that is 
>what it should be called - "Map newlines to CR" 
>indicates a one-way translation.  It is also 
>inconsistent in that when the setting is -not- 
>checked, LF's output to an fstream still get 
>mapped to CR, and CR's inside a std::string get
>mapped to LF when the std::string is output via <<.

Yes, the name is awkward. 

>Of course I can still make it work and have managed to
>fix the crucial problems, but it involves more complication 
>and inconsistency, e.g. using a different newline for output
>to an fstream than to a stringstream, which is unfortunate -
>being able to treat iostream subclasses equivalently whenever
>possible is a big deal in projects like this one.
>And being able to count on CR==CR and LF==LF would have
>just made it all a lot easier.

Like we said, open the stream in binary mode.

hth

meeroh
-- 
Hire me: <http://meeroh.org/hire.html>