Re: backslash-issues

In article <1120120509.941022@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Bart Vandewoestyne <MyFirstName.MyLastName@xxxxxxxxxx> wrote:

> So actually, where you can't be sure that you are using the ASCII
> collating sequence if you interpret CHAR according to the Fortran95
> standard, you *can* be sure you are using the ASCII collating sequence
> if you're using F. So that would make this solution portable in F:

While perhaps literally correct as worded, that's not a way that I would
normally use the word "portable". ACHAR is the same as CHAR on many
systems. The whole point of ACHAR is that it is more portable than CHAR
if you specifically want the ASCII collating sequence.

One could just as well say that CHAR is portable in Sun's compiler. (I
assume that ASCII is the default character set in all versions of Sun's
compiler; anyway, it seems likely.)

In general, yes, it is portable to the set of compilers that it works
on. That seems like a safe statement.

Indeed, I'd lay odds that CHAR is the same as ACHAR on the huge majority
of current Fortran implementations, so you can probably get by with it
in practice. But ACHAR is still more portable by design. Because of
that, it is more certain to be portable to future systems as well as
current ones. For a very specific example, what happens if F ever gets
ported to an EBCDIC system? I suspect that the odds of that are low, but
I don't really know. Are you confident that the F spec won't be updated
to say that CHAR does EBCDIC on that system? Maybe the spec just says
ASCII now because that is simpler than talking in abstract about default
character sets and then mentioning elsewhere that it happens to always
be ASCII.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.

Relevant Pages

  • Re: CFile::Read problem ???
    ... As far as the C compiler is concerned, ... you can pretty much always assign a char ... > as ASCII and wchar_t as Unicode. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: ASCII value of a character
    ... >> character. ... In other words I'm looking for the reverse of char(). ... AFAIK ANSI is an extension of ASCII, ...
    (alt.comp.lang.borland-delphi)
  • Re: Blowfish Sign Extension bug still exists
    ... > of the compiliers I have used), it seems, given the set you ... I have used compilers where plain char is unsigned, ... in ASCII they are all positive. ...
    (sci.crypt)
  • Format of the initialization string does not conform to specification starting at index 5."
    ... (ASCII 127 and ASCII 157). ... where index 5 is the '' char in the user name. ... connectionString, Int32 currentPosition, String& key, Charvaluebuf, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: backslash-issues
    ... For as far as i understand, both intrinsics do the same but CHAR is less portable then ACHAR because it does not depend by definiton on the ASCII character table? ... collating sequence if you interpret CHAR according to the Fortran95 ... But unfortunately, if i compile this as being Fortran95, i still cannot ...
    (comp.lang.fortran)