Is there a Goto statement in Halcon? I was not able to find it in the documentation. What I would need is to jump back about 50 lines of code in a certain condition.. Since it happens rarely I'd like to avoid doing it with a loop. Is there a goto statement or something similar that allows me to jump back to a previous point in the same procedure?
No there is not the GOTO statement.
The reason can be: "Code that relies on goto statements is generally harder to understand and to maintain than code without gotos. Although we are not dogmatic about the matter, it does seem that goto statements should be used rarely, if at all." (Brian Kernighan & Dennis Ritchie, The C Programming Language)
https://en.wikipedia.org/wiki/Goto
Related
I would like to know Why we need to compile the program of progress 4GL? Really what is happening behind there? Why we are getting .r file after compiled the program? When we check the syntax if its correct then we will get one message box 'Syntax is correct' how its finding the errors and showing the messages.Any explanations welcome and appreciated.
Benefits of compiled r-code include:
Syntax checking
Faster execution (r-code executes faster)
Security (r-code is not "human readable" and tampering with it will likely be noticed)
Licensing (r-code runtime licenses are much less expensive)
For "how its finding the errors and showing the messages" -- at a high level it is like any compiler. It evaluates the provided source against a syntax tree and lets you know when you violate the rules. Compiler design and construction is a fairly advanced topic that probably isn't going to fit into a simple SO question -- but if you had something more specific that could stand on its own as a question someone might be able to help.
The short answer is that when you compile, you're translating your program to a language the machine understands. You're asking two different questions here, so let me give you a simple answer to the first: you don't NEED to compile if you're the only one using the program, for example. But in order to have your program optimized (since it's already at the machine language level) and guarantee no one is messing with your logic, we compile the code and usually don't allow regular users to access the source code.
The second question, how does the syntax checker work, I believe it would be better for you to Google and choose some articles to read about compilers. They're complex, but in a nutshell what they do is take what Progress expects as full, operational commands, and compare to what you do. For example, if you do a
Find first customer where customer.active = yes no-error.
Progress will check if customer is a table, if customer.active is a field in that table, if it's the logical type, since you are filtering if it is yes, and if your whole conditions can be translated to one single true or false Boolean value. It goes on to check if you specified a lock (and default to shared if you haven't, like in my example, which is a no-no, by the way), what happens if there are multiple records (since I said first, then get just the first one) and finally what happens if it fails. If you check the find statement, there are more options to customize it, and the compiler will simply compare your use of the statement to what Progress can have for it. And collect all errors if it can't. That's why sometimes compilers will give you generic messages. Since they don't know what you're trying to do, all they can do is tell you what's basically wrong with what you wrote.
Hope this helps you understand.
With PL/SQL will there ever be a situation, say in the case of an exception, where an implicit cursor will fail to close?
I understand that an implicit cursor is supposed to close itself after use, but just want to know if there's ever a situation where this might not be the case, and if this is possible, what kind of remediation will be a good idea.
When COMMIT or ROLLBACK fails the cursor will not close automatically
It is recommended to use route bellow when using cursors:
-- before using the cursor
IF your_cursor %ISOPEN THEN
CLOSE your_cursor;
END IF;
OPEN your_cursor;
-- after using the cursor
CLOSE your_cursor;
-- when exception
IF your_cursor %ISOPEN THEN
CLOSE your_cursor;
END IF;
I'm going to assume that you're talking about implicit cursors, i.e. a SELECT INTO... or a DML statement executed within a PL/SQL block as opposed to a FOR loop.
As with explicit cursors implicit cursors have attributes; you can use SQL%NOTFOUND (instead of CURSOR_NAME%NOTFOUND for instance.
To quote from the 11.1 documentation on implicit cursor attributes for SQL%ISOPEN:
Always returns FALSE, because the database closes the SQL cursor
automatically after executing its associated SQL statement.
This should, I believe, be taken to mean that the cursors will be closed after execution, whether an exception is raised or not. After all, an execution halted due to an exception is still a executed SQL statement.
The reason has been removed from the 11.2 documentation.
SQL%ISOPEN always has the value FALSE.
It appears to have been added to the chapter on implicit cursors instead:
SQL%ISOPEN always returns FALSE, because an implicit cursor always
closes after its associated statement runs.
Whether the cursor closes or not doesn't really matter due to the answer to your final question, "what kind of remediation will be a good idea.". To quote from the same chapter:
You cannot control an implicit cursor, but you can get information
from its attributes.
So, no. There's no remediation possible; it is impossible to explicitly close an implicitly opened cursor.
The one thing you might want to test is whether you can raise ORA-0100: Maximum open cursors exceeded using solely implicit cursors as this is the worst consequence I can think of.
Let's define an "implicit cursor" as a SELECT statement executed in a FOR loop.
Looking at it from a practical point of view - regardless of whether or not it's possible for an implicit cursor to be left open, the important question is "What can you do about it?". To the best of my knowledge, the answer to that question is "Nothing". You don't have a cursor variable to work with, there's no way (that I know of) to access the implicit cursor, and thus you really can't affect it.
There's two things you can do. The first is to completely avoid the use of implicit cursors. Only use explicit cursors, go through all the steps of opening, fetching, closing, etc. This gives you the maximum level of control. If you're into this sort of thing, go for it.
On the other hand, you can use implicit cursors and just not worry. I'm good with not worrying. :-) Seriously, though, implicit cursors are IMO hugely better than explicit cursors. There's less code to write, and therefore less code to screw up. The system can, in certain circumstances, optimize the use of implicit cursors without requiring you to write a pile of extra code. The code you write is cleaner and more easily understood - not a concern if you're working in a one man shop where you write and maintain all the code, but out here in Corporateville we often have to write code others will maintain and vice versa, and it's considered polite to hand over the cleanest, clearest code we possibly can. There are times (such as when handing a cursor variable back to a caller from outside of Oracle) when explicit cursors are necessary, but for most code I'm using implicit FOR-LOOP cursors - and LOVING it! (And extra bonus points for those who can recall where that comes from :-)
Share and enjoy.
My questions is basically all in the title. I have no real application in mind, I'm just trying to make sure I use generally accepted good coding practices, and I remember my CS professor saying that breaks are generally avoided when possible, but he never told us why.
I would ask him myself, but he's out of his office this summer.
This is a theological issue. People who are opposed to the use of break (or continue for that matter) say that it makes the control flow of the program harder to follow and thus makes the program less readable. But an easier way to make readable code is simply to make shorter functions, use meaningful variable names, comment appropriately, etc.
Sometimes professors are wrong.
He may object to skipping out of a loop right in the middle of it. This is akin to using a return statement in the middle of a function...some consider that blasphemy.
What ever is the simplest, and produces the most easily maintainable code, is what should be used.
Generally speaking, you will use 'break' to get out of cycles when a certain condition is met (for instance, when you've found what you're looking for, etc.); I don't consider it 'evil' such as the infamous GOTO statement, but reasonable people will differ.
What Dijkstra said was harmful about goto statements - http://drdobbs.com/blogs/cpp/228700940
and https://softwareengineering.stackexchange.com/questions/58237/are-break-and-continue-bad-programming-practices
Your professor was saying "breaks should be avoided" because they are similar to the now-taboo goto statement. However to say "breaks should be avoided whenever possible" is just wrong.
Break exists for readability. You can do anything without break that you can with it, but that doesn't mean you should. Sometimes it just makes sense to make a statement like "In this condition, break out of this loop." or "In this condition, return from this function."
It's a bad idea to use break for program flow in a nested for loops in a way that might give a casual reader some confusion.
Simple rule of thumb: Does using break here (instead of additional if/thens, another boolean, etc.) make this easier to understand or harder to understand? It's that simple.
Ask your professor to try writing a switch statement in any C-style language without break. It can be done I'm sure, but the resulting code is not going to be any more readable.
switch (someExpression) {
case enumVar.CaseA:
// do things here, but don't you dare break!
case enumVar.CaseB:
// do other things - possibly unrelated or contradictory to CaseA
// ... and so on
}
I am a beginner in Ada and I have come across a piece of code which is shown below:
procedure Null_Proc is
begin
null;
end;
Now as per my knowledge the procedure in Ada doesn't return anything. My doubt is what does this procedure Null_proc do? I mean I am not clear with the definition of the procedure.
It does nothing.
It might be useful when a procedure must be called but nothing must be done; otherwise, it has little value. (I am working from memory; I assume that Ada does allow functions or procedures as parameters to other functions - in terms of C, pointers to functions.)
I've been known to write main routines that way when all the "real code" was in the withed packages. This is particularly likely if your program uses tasking, as the main routine cannot accept rendezvous like a task can, so it often ends up with nothing useful to do. Your entire program will stay active until all tasks complete, so the main routine really doesn't have to do anything.
Another possible use would be for implementing some kind of default routine to supply to callbacks.
This question already has answers here:
Closed 14 years ago.
This question is a duplicate of Goto Still Considered Harmful. If you wish to discuss this further please use the original question.
Why exactly is GOTO poor programming practise? It makes sense on some occasions to use it.
Note that Djkstra wrote "GOTO Considered Harmful", not "GOTO Considered Deadly". It has its places. Unfortunately, the judgement to know when to use it comes after you've got some experience in maintaining other people's code, especially code that was written years ago by people who no longer work in your company. Thus, it's best to avoid goto as much as you can until you have that experience.
It encourages bad coding style, basically. See: Goto Considered Harmful [pdf]
It can rapidly lead to spaghetti code.
It means you haven't designed the code procedurally.
If you build your whiles and ifs properly, you should rarely ever need goto.
Rarely is the key word. There are times where it's useful. In that sense, many people nowadays just explicitly throw and catch exceptions, just to avoid the dreaded goto.
Because the structure of the code can be difficult to follow.
This
y:
// do more stuff
goto x
p:
// do stuff
// then done
goto y;
x:
// do a bunch of stuff
if (...)
goto y;
else
goto p;
done:
is much less clear than
int main()
{
x();
}
function p()
{
if (...)
{
return;
}
}
function x()
{
if (...)
{
return;
}
else
{
p();
}
}
GOTO short circuits your control flow, thereby undermining your design and opening the door to debug and maintenance nightmares.
Readability becomes a problem, and flow of logic can have unintended effects by the use of goto.
I think its funny that the .net compiler will change some case/switch statements to use goto.
In some cases it makes sense. But, in the majority of cases use of it it considered poor practice because it can make the execution path of code tricky to read compared to using structured code such as for loops and while loops.
When you look at a goto or a label, you don't really know where is goes to or comes from without reading or searching through the code for the label name. This is tricky especially if the goto doesn't fit on the same screen as the label. Compare this to a for loop or a while loop or an if.. you can tell from the structure (i.e. indenting of the code) what the execution path is.
Having said this, it sometimes is useful, especially for example when jumping out of some nested for loops that are digging for a particular value inside a multi-dimensional array. You could use a goto here to jump out of the for loops when the correct value is found.