Re: gfortran diagnostics and so on
- From: Gary Scott <garylscott@xxxxxxxxxxxxx>
- Date: Fri, 23 Nov 2007 17:23:24 GMT
Craig Dedo wrote:
"Richard Maine" <nospam@xxxxxxxxxxxxx> wrote in message news:1i7zirl.hdl6kepl696lN%nospam@xxxxxxxxxxxxxxxxHow about something unique in the way the string is quoted to cause it to be interpreted differently. Normal quotes (double or single/apostrophe) mean literal interpretation. Use some other quoting scheme to indicate substitution. You could even add an additional procedure containing text string arguments to substitute.
Tobias Burnus <burnus@xxxxxxxx> wrote:
I don't know how to handle this best. Backslashes are difficult as
some people expect that "\" prints a backslash, others want to have
"\n" as new line -- and both want to have their choice as default.
With either choice, you have unhappy users. But I am open to
suggestions.
Well, in f0003, backslash is part of the standard Fortran character set.
So I'll find it awfully hard to accept as reasonable a default that
doesn't conform to the standard. But then I'm one of those who has
always thought that doing backslash processing on Fortan code was an
unreasonable default, so just consider me biased.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
I wholeheartedly agree with Richard. Because the backslash is part of the standard Fortran character set, the default behavior should be the printable character, **NOT** some kind of magic introductory character that transforms the interpretation of following character(s). Compiler defaults should always follow the Fortran standard, wherever applicable.
Just because C uses backslash as a magic introductory character does not mean that Fortran should follow that practice. Although some may disagree, I have always thought that part of the spirit of Fortran is that it is designed to make life easy for the application developer. What you write on the blackboard is what you write in the source code. Among other things, that means that printable characters are exactly that, no more and no less.
There are reasonable alternatives for programmers who want the C language behavior. The one I like best is to use one of the popular extensions to designate a particular literal string according to the C language.
If a programmer wants control characters in character strings, the programmer can always use the CHAR() or ACHAR() intrinsic functions. The programmer also can define a module that defines all of the control characters as named constants. I have done that and it works very well.
string = "Literal String" ! A literal string
string = 'Literal String" ! A literal string
call stringargs(["to ","a ","on") !maybe better as an array
string = \"A string \1 perform \2 \n substitution \3."\
So prior to this example, you might call a procedure (stringargs) which defines the substitution strings for \1, \2, and \3; if undefined, substitute a null (nothing, effectively delete "\1" from the string).
I don't particularly like "\" and i don't know all the \ formatting needed for c compatibility if required, I'm thinking \<number> is an argument to be substituted so maybe those need a different character, maybe a % or an &.
Need to define whether blank terminates or whether an additional terminator is required for each argument (\1.) to accommodate spaces.
Of course you can easily write something like this if you need it (i'm sure it exists in various forms already).
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows it can't be done.
-- Henry Ford
.
- Follow-Ups:
- Re: gfortran diagnostics and so on
- From: Craig Dedo
- Re: gfortran diagnostics and so on
- References:
- gfortran diagnostics and so on
- From: James Van Buskirk
- Re: gfortran diagnostics and so on
- From: Tobias Burnus
- Re: gfortran diagnostics and so on
- From: Richard Maine
- Re: gfortran diagnostics and so on
- From: Craig Dedo
- gfortran diagnostics and so on
- Prev by Date: Re: gfortran diagnostics and so on
- Next by Date: Re: gfortran diagnostics and so on
- Previous by thread: Re: gfortran diagnostics and so on
- Next by thread: Re: gfortran diagnostics and so on
- Index(es):
Relevant Pages
|