Re: Newline in Text Property

From: Armin Zingler (az.nospam_at_freenet.de)
Date: 04/20/04


Date: Tue, 20 Apr 2004 20:25:45 +0200


"Tom Shelton" <tom@mtogden.com> schrieb
> In article <408551a9$0$26139$9b622d9e@news.freenet.de>, Armin Zingler
> wrote:
> > "Tom Shelton" <tom@mtogden.com> schrieb
> >>
> >> New lines are platform specific.
> >
> > There is no platform specific standard.
>
> I'm not sure what you mean be standard?

I guess, by saying "platform specific" you want to say that on platform X
char Y is always used as the line separator. This is what I'd call a
"standard".

> If your talking about a
> formal standards body - then no, there isn't. But traditionally on
> *nix a newline is a single lf (I know I said CR earlier). It's one
> of those issues that tends to bite people when writing cross platform
> code. *nix progams will almost always assume that a line terminates
> on LF, windows/dos expects a cr/lf.

Where does "it" expect it? This sounds as if on my system everywhere CRLF is
always used, but this is not true. Consequently I can not always expect
CRLF. Consequently it doesn't make sense to prefer one of the constants over
the others because you have to decide it in each individual case. Moreover,
even if you read the /same/ file (e.g. using CRLF as the seperator) on two
different platforms, and on both systems Environment.newline is expected as
the seperator when reading the file, it doesn't help you at all. The
opposite is the case because on one system the wrong char is expected and
the file will be read wrong. Consequently, you always have to know which
seperator has been used for writing exactly this file that you are reading.
In addition, even if you know that CRLF had been used, do you know that the
programmer writing the file used Environment.Newline? Or did he use
vbNewLine? In the end it is out of interest. The only reason to prefer one
constant over the other is that you defined your own standard or your
company's standard that says that "we use environment.newline to write
files". But you could also say "we use vbNewline" - or whatever. None is
preferrable. Also, other companies might use other standards - or other
platforms. That's why I think that saying "new lines are platform specific"
is not right.

> I'm really not sure what the argument is about. The fact is that
> it unless you have specific reasons, I find that it is better not
> to hardcode your line termination to a specific value -
> ControlChars.CrLf - but to use System.Environment.NewLine. That way,
> I don't have to worry about the difference because it will just do
> the right thing based on the underlying platform. Look in the VB6
> docs for vbNewLine - it is essentially the same thing.

-- 
Armin


Relevant Pages

  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... These days I don't do compiler maintenance, but I HAVE done in the past, so ... You had a chance to point out how adherence to the standard can improve ... >> compile it WITH MINOR MODIFICATIONS for a specific platform. ... > platform-specific extension to COBOL ...
    (comp.lang.cobol)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > implementations that purport to conform to a COBOL standard is to write ... I DID think any old compiler would be able to ... compile it WITH MINOR MODIFICATIONS for a specific platform. ... >> Portability depends on where you plan to port (or more likely where ...
    (comp.lang.cobol)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... I DID think any old compiler would be able to ... > compile it WITH MINOR MODIFICATIONS for a specific platform. ... > not going to go to the Standard to see what SHOULD work. ... If you write your COBOL code avoiding the things that are marked as ...
    (comp.lang.cobol)
  • Re: C portability is a myth
    ... > solicitation for the availability of a compiler for a given platform. ... If the source is pure Standard C ... can be successfully ported to all implementations. ...
    (comp.lang.c)
  • Re: These are identical, right? char const* and const char*
    ... >> You gain working directly with the platform API in your code and thus ... I believe changing the default character set to UTF-8 would be ... >> platform specific APIs for those things not covered by the standard. ...
    (comp.lang.cpp)