Spirit rover OS problems

Three returns from one function?

I do this quite often:

if ((pHandle = fopen(szFilename, "r"))) { // ... do stuff with pHandle fclose(pHandle); } else { // Bugger! - handle error }

The assignment and the if could be split onto separate lines, but is the above so hard to understand?

Other than the extra set of parens? No. I should have been clearer: you can't justify it as _necessary_. And it does hide the fopen a little deeper than it needs to go.

But the only way I know of to re-write the little loop I posted earlier without the embedded assignment:

while ( (key = get_key()) != EXIT_KEY ) process(key);

requires a break, a goto, or a duplication of the function call. If you're trying to avoid those, the embedded assignment is necessary.

while (1) { key = get_key(); if (key == EXIT_KEY) break; process(key); }

Regards,

-=Dave

Lots of people disagree with Skinner. Most of them are psychologists.

Did Skinner actually do much research on human learning?

I tend to make this a bit more obvious by taking advantage of the defined return from fopen on failure: if (( pHandle = fopen( szFilename, "r" )) == NULL ) { // handle error }

That's the point, of course - clarity. That should be the crux of any coding standard, but often sadly isn't.

Steve

learn?

Actually, both work fine. Reward == positive reinforcement. Consequence of mistake == negative reinforcement. These are equally powerful. If you are prevented from making mistakes, you do not get the negative reinforcement that comes from having to locate and fix them. Therefore you do not learn as well if you are prevented from making mistakes. "Working without a net" can also lead to operant conditioning, where the programmer discovers that by performing certain actions (i.e. adopting certain forms of self discipline with regard to coding practices), positive reinforcement increases, and negative reinforcement decreases. I guess the choice is whether you prefer to prefer to achieve results through self discipline, or through externally imposed discipline. Often the answer depends on whether you are applying the theory to yourself, or someone else. :-)

Tanya

Not really - structurally it's the same return, just appearing in three different places. And in this kind of case (simple or no return value), it meets my requirements of a) clarity and b) simplicity. The alternative is an extra level of indentation until the final line (more eye clutter), and generated code that amounts to: jmp label ..... :label ret

It also suits the way my brain works: by a process of elimination. Less for me to worry about at as I work through the rest of the function. I use this technique quite a bit (also with "break" within loops and cases) - it helps keep things simple and clear, which are always my main criteria in such things...

Steve

... stuff about using "if (p = ...)" vs separate statements.

I had never really considered the likelihood of a bug showing up in testing, but I think it is a valid point. Of course it is subsumed by the likelihood of creating a bug in the first place, which in turn is controlled by the style used, and that again is effectively the understandability of the code in the first place.

I think we can generally say that redundancy is bad, because it requires correlation of (possibly) widely separated items. This militates against such things as the above split expression, and the use of pointless prototypes, and encourages complete define before usage techniques.

When stuck with C and the plethora of possible biting insects this encourages careful thinking out of the style used. Such habits can only help with other languages. In this particular case most other relatively safe languages ban the testing of an assignment. So the original problem needs to be couched differently in, say, Pascal:

PROCEDURE foo ......

FUNCTION xalloc(VAR p : ptr; sz : integer) : boolean; BEGIN (* whatever *) xalloc := ptr = NIL; END;

BEGIN (* foo *) ... IF xalloc(pp, N) THEN ...

... snip ...

Look back in this thread to Monday, and among other things you will find a posting of mine which says in part:

which in turn led to some replies and a surprising (to me) conclusion about incipient bugs when isolating the assignment from the test, and the likelihood of catching such.

It is not hard to understand, but you lose the ability to distinguish from this...

if ((pHandle == fopen(szFilename, "r")))

Typing a single equals when a double equals is a mistake that is very easy to make and hard to spot. Since it is legal syntax and produces a meaningful result (just the wrong meaning when a comparison is intended), it is hard to detect... unless you avoid the use of an assignment in conditional evaluations on purpose and allow the compiler to check for the mistaken case for you.

Of course some people have little trouble with this and others a lot. So it comes down to a matter of style. Just like some people can juggle eggs and others perfer to keep them in an omlet!

Funny, they still teach Skinner in the schools around here. I can show you many examples of operant conditioning in people. And I don't really belive anyone seriously doubts its application to humans either. It may not explain all of human behavior, but it is certainly a significant component.

That is an assumption on your part and was proven to not be the case by Skinner's work. Negative reinforcement is not a good teaching tool. Do teachers yell at kids to get them to learn? Do they punish students when they make mistakes? No, they correct them, but offer encouragement to minimize the negative aspects of failure. But the absence of positive reinforcement is very different from negative reinforcement.

You can still make mistakes and learn debugging skills even if your programming language prevents you from making a class of mistakes (the preventable ones). And you ideas about negative reinforcement are not valid (see above).

Again, this does not apply. If you use a language that prevents certain types of errors, then how is working "without" a net a better way to learn? Learning that there are languages that let you make preventable mistakes is no great revelation.

Ok, if you think stopping you from making preventable mistakes is a bad idea, then maybe we should do away with things like hand rails on stairs. Then lots of mistakes could be made and people would learn to not be so "undisciplined" when walking on stairs.

Do you not see how silly this rational is?

I actually took a class in school on "Software Engineering" where they taught "Structured Programming" (this may be dating me, I don't know). One of the things in the list of no-nos was multiple returns from a routine. But when I coded up my work using the guide as an abosolute, I often found that my code was much more complex by trying to design the structure to allow a single "return". But then I realized that a major part of the rational for a single return was to allow the placement of a single breakpoint for debugging. Well, even with a hundred "return" statements, I can still put a breakpoint at the final '}'. So I gave up treating this rule as an abosolute. I use it as a guide and try to keep the meaning of the code clear. One of the best rules I learned was to keep the routines short. But not many of my coworkers like that. They all think there are way too many subroutines.

So I have given up trying to please others and I code to please myself. :)

... snip ...

However "safer" languages, such as Pascal, apply that negative reinforcement as close to the point of error as possible, i.e. on the next compile, or possibly the next test run when the 'out of range' error appears. In unsafe languages, such as C, the crash may occur far removed from the foulup, and the frantic casting about for a clue does not teach much (apart from methods of frantically casting about for a clue). C programs are even more in need of thorough regression tests than those "safer" languages, although all should use them.

Contrast this with housebreaking puppies, and you will soon see parallels. If you just come home and yell at the poor beastie hours after the dirty deed, you will simply train him or her to hide when you come home. The C tyro applies a cast if he can't hide.

... snip ...

I don't know if you consider this duplication of the function call. It is an alternative to the embedded assignment.

key = get_key(); while (key != EXIT_KEY) { process(key); key = get_key(); }

but that is a method suited to languages that do not allow assignments to have a value. C allows us to express many such "loop and a half"s as simple loops. Thus I would much prefer the one liner:

while (EXIT_KEY != (key = get_key())) process(key);

and, if you are willing to have process(key) return 0 only when passed EXIT_KEY (which might be a good defensive move), you can also use:

while (process(get_key)) continue;

eliminating temporary variables, and my preference, if feasible.

This test should be if(!p->cp)...

Testing these cascading memory allocations in C can be very painful.

John

Ah, pedantic mode on.

No, its both. Reread your C grammar. Expression is one of the legal statements.

How many C compilers have you written ?

Yes, I would agree with that definition.

On Thu, 19 Feb 2004, John Williams wrote: |>>What is wrong with this? |>>

|>> p = malloc(sizeof *p); |>> if (!p) return errnomem; |>> else { |>> p->cp = malloc(strlen(s) + 1); |>> if (!p) { |>> free(p); | |This test should be if(!p->cp)... | |Testing these cascading memory allocations in C can be very painful.

Then do it in assembly language. (Geeze!)