I would like to know what is the different between this statement:
open(unit=11,file="something.TXT",status="unknown"), which is Fortran's default status (i.e., the previous statement is the same as open(unit=11,file="something.TXT")
and this statement:
open(unit=11,file="something.TXT",status="replace")
I have the impression that the unknown status behave exactly as I would expect with replace: if the file doesn't exist, it creates it. If it does exist, then it replaces it.
The Fortran standard lays down that the interpretation of status='unknown' is processor-dependent. That is, your impression is subtly incorrect.
In the draft of the 1995 standard I have at hand this is explained in section 9.3.4.2.
In the draft of the 2003 standard I have at hand this is explained in section 9.4.5.15.
Related
I know that by using 0:3 in this code in Pascal will put 3 decimal places to the result
var a,b:real;
begin
a:=23;
b:=7;
writeln(a/b:0:3);
readln;
end.
What I would like to know is if anyone has a source to learn what this : will do with other variables or if adding for example 0:3:4 will make a difference. Basically what : can do to a variable
For the exact definition of write parameters take a look at ISO standards 7185 and 10206, “Standard Pascal” and “Extended Pascal” respectively. These references are useless though if your compiler’s documentation does not make a statement regarding compliance with them. Other compilers have their own non-standard extensions, so the only reliable source of reference is your compiler’s documentation or even its source code if available.
[…] what this : will do with other variables […] Basically what : can do to a variable
As MartynA already noted this language is imprecise: The variables’ values are only read by write/writeLn/writeStr, thus leaving them unmodified.
[…] if adding for example 0:3:4 will make a difference.
To my knowledge a third write parameter is/was only allowed in PXSC, Pascal eXtensions for Scientific Computing. In this case the third parameter would indicate for the rounding mode (nonexistent or 0: closest printable number; greater than zero: round up; less than zero: round down).
I'm writing a macro for LibreOffice Calc in Basic in VBA compatibility mode. It complains when I use this line:
Const BASE = 3
BASIC syntax error.
Symbol expected.
and the syntax coloring seems to indicate that "BASE" is a keyword or reserved word. Other consts in the macro are accepted without issue. Also, this line is accepted in VBA in Excel.
I will change the name in order to avoid this problem, however I am unable to locate any documentation that references this as being any kind of reserved word. I assume it either has something to do with number bases or with the name of LO's database. However, words like "WRITER" and "CALC" don't act the same way - they seem to be accepted as names for constants. Note that my use of this word is not related to the database anyway.
Also, unfortunately, LO Basic doesn't seem to have an immediate mode (REPL) so I am unable to easily play with this word to determine what it's used for.
Can you point me toward some documentation for the keyword BASE?
Those are some good guesses, but incorrect as it turns out. The word is used as follows:
Option Base 1
It can be either 0 or 1 to denote which index refers to the first element of an array, as documented at https://wiki.openoffice.org/wiki/G11ntest/Documentation/BASIC_Guide/Arrays.
To discover this, I looked through the LibreOffice source code. The file /basic/source/inc/parser.hxx was helpful. This is the closest approximation of a list of keywords available, judging from this post.
Apparently, this statement was adopted from VBA: https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/option-base-statement
Is it legal to use variables in printf without supplying the formatting (such as %d, %f).
for example:
printf("value is ok\r\n",myvalue);
The command compiles without errors nor warning, though I am not absolutely sure if it is legal or dangerous.
This reference says
There should be at least as many of these arguments as the number of values specified in the format specifiers. Additional arguments are ignored by the function.
Base on this information, your statement is perfectly legal, however I don't thinks that this is a good idea, since you code could quickly become confusing, which might lead to bugs.
Edit: The original source does not explicitly mention the case of zero arguments. To add another source, the linux man pages states
The format string is composed of zero or more directives.
This source does not discuss what happens with additional arguments. However, combining these two sources gives a definitive answer.
Trying to debug the problem that spawned this question gave me the following thought:
Q: is there a way to tell the stub to ignore only some parameters but not the others? (in opposition to ignoring all parameters with IgnoreArguments)
The syntax for ignoring a parameter in VB.net is Arg(Of T).Is.Anything.
For example if I had:
myObj.Stub(Function(x) x.MyMethod(string1, string2)).Return(myReturn)
And I wish to ignore only string1, I could just write:
myObj.Stub(Function(x) x.MyMethod(Arg(Of String).Is.Anything, Arg(Of String).Is.Equal(string2))).Return(myReturn)
Note that in order to ignore one or more parameters this way ALL of them must be written in that notation, even the ones that you want to have a specific value (with the .Is.Equal(...) notation).
Answer found thanks to this comment
I set the culture to Hungarian language, and Chr() seems to be broken.
System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"
Chr(254)
This returns "ţ" when it should be "þ"
However, Asc("ţ") returns 116.
This: Asc(Chr(254)) returns 116.
Why would Asc() and Chr() be different?
I checked and the 'wide' functions do work correctly: ascw(chrw(254)) = 254
Chr(254) interprets the argument in a system dependent way, by looking at the System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage property. See the MSDN article about Chr. You can check whether that value is what you expect. "hu-US" (the hungarian locale as used in the US) might do something strange there.
As a side-note, Asc() has no promise about the used codepage in its current documentation (it was there until 3.0).
Generally I would stick to the unicode variants (ending on -W) if at all possible or use the Encoding class to explicitly specify the conversions.
My best guess is that your Windows tries to represent Chr(254)="ţ" as a combined letter, where the first letter is Chr(116)="t" and the second ("¸" or something like that) cannot be returned because Chr() only returns one letter.
Unicode text should not be handled character-by-character.
It sounds like you need to set the code page for the current thread -- the current culture shouldn't have any effect on Asc and Chr.
Both the Chr docs and the Asc docs have this line:
The returned character depends on the code page for the current thread, which is contained in the ANSICodePage property of the TextInfo class. TextInfo.ANSICodePage can be obtained by specifying System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage.
I have seen several problems in VBA on the Mac where characters over 127 and some control characters are not treated properly.
This includes paragraph marks (especially in text copied from the internet or scanned), "¥", and "Ω".
They cannot always be searched for, cannot be used in file names - though they could in the past, and when tested, come up as another ascii number. I have had to write algorithms to change these when files open, as they often look like they are the right character, but then crash some of my macros when they act strangely. The character will look and act right when I save the file, but may be changed when it is reopened.
I will eventually try to switch to unicode, but I am not sure if that will help this issue.
This may not be the issue that you are observing, but I would not rule out isolated problems with certain characters like this. I have sent notes to MS about this in the past but have received no joy.
If you cannot find another solution and the character looks correct when you type it in, then I recommend using a macro snippet like the one below, which I run when updating tables. You of course have to setup theRange as the area you are looking at. A whole file can take a while.
For aChar = 1 To theRange.Characters.count
theRange.Characters(aChar).Select
If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
Next aChar