Prof A Olowofoyeku (The African Chief) wrote:
On 15 Dec 2003 at 23:35, CBFalconer wrote:
[...]
This focus on ParamCount is a red herring. That was just a trivial test program (as Frank always emphasises) that shows the problem. ParamCount is not the problem here. Rather, it is the warning about a ";" following a "then" that was being highlighted.
My point, which I probably did not make clear, is that the only use for a null statement after a then is to discard something in the conditional part. Having discarded the need for this by using clearer methods, such a null THEN clause is clearly a programmatic error and a warning can only be useful.
I am not sure how something is an error, if it is something that I intend to do, does not cause my program to behave in a manner that I do not expect or want, and does not violate the language.
(I suppose "programmatic error" was meant as "bad style".)
IMHO having to create any number of junk variables just for the purpose of discarding things is undesirable. I don't see how it is "clearer" either. It ought to be pretty clear to anyone that the value is being deliberately discarded when a "then" is followed by a semi-colon.
In this case yes. But people (including myself ;-) sometime make mistakes and put an semicolon after `then' or `else' where it doesn't belong. The compiler can't distinguish the cases, and the resulting bugs are often hard to find (because one tends to overlook the semicolon even when checking again). That's why I (and probably others) appreciate such a warning. But if you don't, you can always turn it off (`-Wno-semicolon').
In this example, all I want is to try to go somewhere before doing something else, and I don't need to know (or care) whether it happens successfully or not, because it is of no real consequence either way. I of course want to clear IOResult, and I don't want any complaints. This scenario is of course contrived.
I guess "If ioresult = 0 then begin end;" is the way to go in order to satisfy all compilers ...
In this case I'd recommend `InOutRes := 0' which says what you actually want to do -- clear the state, not query it. This will avoid the issue here, but not in general.
What I could imagine is a built-in procedure `Ignore', `IgnoreValue', `Discard' or so which takes one parameter of arbitrary type and does nothing.
Or perhaps (but less preferable IMHO) a type-cast to `Void' (as in C) ...
Do any other compilers have something like that?
FWIW, Delphi has something called a Variant, which is type-compatible with all sorts.
I don't think that's suitable. We don't actually want to declare such a dummy variable (which would have to be global, so assignments could not even be optimized away). And since it doesn't accept all types (as stated in the Delphi description), it wouldn't be general enough.
I still prefer the built-in procedure.
Adriaan van Os wrote:
CBFalconer wrote:
As far as an extended throw-away syntax is concerned, I have seen far too many C failures due to ignoring a return value (especially malloc/realloc, but including fclose, printf, etc) than is comfortable, and I see no need to encourage such bad C habits in Pascal.
I agree with that. Worse -- the whole Win32 API (and some of the later parts of Mac OS) are based on this bad habit. Many Win32 functions return values that are useless in most situations, simply because in C they can be ignored. Some functions return an error result code, but never consistently. The result is of course instable software, because very few programmers pay attention to all the details if tricky and variable from situation to situation.
Bad habits in programming tend to get worse all the time and then the final result is invariably a total mess.
I beg to differ. Error status results (as in `malloc', I/O functions etc. in C) are serious indeed. But in GPC many of them cause runtime errors instead anyway (which can be caught, but only by explicit action, not by ignoring a function result).
There are other functions which really return unimportant results -- e.g., some of the CString routines return a pointer passed as an argument back. This is to facilitate chaining them, but ignoring the result is perfectly safe as well. GPC now allows declaring such functions with the `ignorable' attribute, and many such functions in the RTS and included units are declared so now. So there's no problem either -- GPC will simply accept both procedure and function style use.
(Typical C functions fall in one of these categories, and when writing a Pascal interface it's useful to distinguish the cases by giving or not giving this attribute. Of course, this can never be automated by any header converter, since it depends on the semantics of the C functions ...)
But it occasionally happens that you want to ignore another function's result (or some other value, for that matter) -- of course, after due consideration whether it's safe to do. That's where a built-in ignore procedure would come handy.
Frank