🚀 go-pugleaf

meeroh wrote:

> >What I'd really like is to have std::endl always
> >be the same thing regardless of whether it's
> >going to an fstream or a stringstream, and
> >also have '\r' in code always mean '\r' in
> >the byte and its subsequent i/o, and sim. for
> >'\n' to always mean '\n', with no translation
> >other than what the programmer does explicitly.
> >If this is possible in MSL C++, what does
> >it involve other than the newlines-to-CR setting?
> 
> Why do you want that? The underlying principle here is simple: the
> representation of a newline in memory is a LF character, and on disk is
> a CR character. If you use text mode to open files (which fstream does
> by default), the conversion is done on the way from memory to disk and
> back.

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.

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.  Internally,
however, some elements contain text in which 
whitespace is significant, including newlines; here 
(precisely because the file could have come from another 
platform)  we need to test and translate newlines to 
see if they match the current platform's native 
linebreak before handing the text off to a native
text-display object or edit field.

It isn't enough to say, "I'm a Mac app and I want
\n to be \r, always".  The general solution would be,
"I'm a platform with newline sequence x+ and if
I encounter newline sequence y+ I want to translate
it to x+", and have this to hold true for both
input and output to any iostream.  But to implement
this in cross-platform code, you need consistency
from the development environment.

VC++6 maps std::endl to "\r\n" when writing to
a file, but if you substitute a literal "\r\n" you get
exactly what you asked for - you don't get "\r\r\n".
Needless to say it never gives you "\n\r".

If MSL and VC++ both fudged the standard in the
same way we could still develop a general solution,
but in this one case MSL is harder to deal with.
(This -is- the exception - in almost every other
std:: issue we've run into MSL has been far more
sane and compliant than the Redmond camp).

> But, I really think that if you are
> trying to do that, you are probably doing something wrong, which is why
> I would like to know why you think it's crucial to you to make the two
> match.

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.

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 <<.

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.

Thanks for the discussion.

Chris