Can anyone verify this crash too?

[luis]

Luis, now I disagree

No problem

You see, Goto is evil

I don't think so.

Seriously, there's little need for Goto.

I agree. Or better: there is no often need for the goto.

Thus far, I've never ever felt the need for Goto.

It's fine. I know you can do what you have explained, I wrote about that myself. I simply don't like it, I find it clumsy, bad to read and worst to maintain (error prone).

Moreover, your code must continually check if it's right for him to do what it's supposed to do.
Imagine a fairly long procedure, calling apis who can fail, doing disk i/o who can fail, doing memory allocation who can fail. When a call of the above fails, there is no point in continue, you should exit returning some informative code.
Using the "goto" (try/catch) approach, you can write all the code supposing it will actually work. No tests, flags, breaks, or whatever trying to transfer the information that something went wrong from a level to another.
When something go bad, you simply leave the proc jumping to a common exit point, where you can gracefully exit closing file, deallocating memory and so on.

The resulting code is easier to follow, the linear sequence from up to down (when all is going as it supposed to go) is free from the burden of testing unneeded flags, the exit point deal with the rest.

Using some macros you can "hidden" the actual gotos from the eyes of sensitive people, like all the languages in the end do. Break is a goto. Continue is a goto. Exceptions handling is a sophisticate form of goto.

Anyway, no need to repeat myself, so:

http://www.purebasic.fr/english/viewtop ... 32#p310632

http://www.purebasic.fr/english/viewtop ... 92#p310692

[djes]

The main problem with goto/gosub is spaghetti code. By now, I see often really hard to follow spaghetti code in object programming, stacking thousand plates of glue needles, wondering for hours where this damn redefined function could be in this mess. IMHO, a unique goto is a fast and clean way to jump, but it should be used by experienced programmers who knows what is the stack! Millions of goto are hell, like are millions of "if" or nested loops (as I do myself when I'm not coding for weeks)

[luis]

The main problem with goto/gosub is spaghetti code.

Yes, but it's the programmer who write spaghetti code. And then this is inevitable only if the language give you only GOTO/GOSUB and nothing more. It's not the case with PB.
I don't write spaghetti code, for example. Even if I use GOTO.

IMHO, a unique goto is a fast and clean way to jump, but it should be used by experienced programmers who knows what is the stack!

I don't think it's needed for a goto to be a single goto to be considered acceptable. As I wrote just above, that is an example of using many gotos along a complex procedure, all used to exit safely and skip code that has no more reason to be executed.

Millions of goto are hell

Millions of goto jumping back and forth are hell, IMHO. Especially back.

like are millions of "if"

That's one of the problems the example above try to mitigate. Or better, to hide.

[djes]

Totally agree. GOTO is a way to do things, like is SELECT/CASE, or IF. Correctly used, the resulting code could be perfectly clean and readable. And I prefer to have the choice!

[netmaestro]

Hehe this reminds me of a very long time ago when I was a student. Our class was given an assignment to create a reporting tool that used a dbms. We could choose the application ourselves, either solve a real-world problem or make one up. I was friends with a couple of profs and they used to bitch to me over the chessboard how much of a pain keeping track of student marks was. So I chose that for my project. I remember sitting at that terminal, seeing my program logic in my mind and following its every track. I thought I was such a genius! GOTO made up about one in four of the total commands used. That logic darted and flitted all over the (very long) code and in the end it was a miracle that the final submission had no serious bugs. It just worked. It worked so well that the school bought it from me and implemented it. Sixteen years later I ran into a kid I knew who was a student there and he asked me to give him a bit of help with a homework assignment. When he opened his notebook I almost had a litter of kittens. There was my spaghetti code in all its brilliant glory! The assignment, and they could take the whole semester if they needed to, was to rewrite my GOTO-ridden sack of sh*t in proper procedural form. Turned out that three or four years after I left, they wanted to modify it somewhat and were left scratching their heads and so every semester for 20 more years, that was a standard assignment for the course

[KJ67]

I will part with Luis here. Goto/Gosub etc is perfectly ok to use as long as you have a clear system, most of my bad code is due to nested if's with complexes statements – nothing to do with spaghettification due to jumps, I would probably need more of those.
Using Goto/gosub for flow control can actually both give a (according to my opinion) easier code to read and better performance since the overhead is a little less.
The thing that is still missing her in my which list is local labels for use inside macros.
Above is a few links to good examples on Goto’s, but since Gosub is closely related as both basically dates back to pure assemble I like to include this also.
For performance, compare the same with Gosub and Procedural below. Then tell me is they are not also equally readable.

Code: Select all

Declare.i Add_3_times(x)
Define.l  a
#LIMIT=#MAXLONG/2

;- GoSub
e0=ElapsedMilliseconds()
For i=0 To #LIMIT
  Gosub Add_a_3_times
Next i

;- Procedural
e1=ElapsedMilliseconds()
For i=0 To #LIMIT
  a=Add_3_times(a)
Next i

e2=ElapsedMilliseconds()
MessageRequester("Result","Gosub ="+Str(e1-e0)+" msec."+Chr(10)+"Procedural ="+Str(e2-e1)+" msec.")
End

; Procedure
Procedure Add_3_times(x)
  ProcedureReturn x+x+x
EndProcedure

;- Subroutine
Add_a_3_times:
  a+a+a
Return

[luis]

Well, this is quite different from my original line of thoughts, this is a little more extreme

Here the focus is on speed, mine was especially in readability and maintenance.

But again, there is nothing wrong in using gosub too. Here the advantage is clearly due to the fact there is no stack overhead for the procedure. Same concept of using macros, in a way.

At the cost of stating the obvious, everyone should use the way he found more productive and less error prone for him.

Talking of speed above all, sometimes you can get more speed duplicating the code three times in a row instead of executing it in a loop three times, thanks to the way modern cpus works

But I digress...

[Christian Uceda]

@Luis

I'm starting to feel what you describe too, proper error handling in PB is a #pain# in the ass without per procedure labels.

I also agree that using goto as a way to do exception handling (jumping to the same point with no intention to come back) is not the same as using goto to replace function calling.

Using gotos in certain situations does not mean writting spaghetti code.

[luis]

without per procedure labels.

Hi Christian, Fred told one time he was going to make the labels locals to procedure, I hope it will happen

In the meantime I use the @@ FASM anon labels in a library I'm developing.

As I wrote here: http://www.purebasic.fr/english/viewtop ... =3&t=42555

All of this could be avoided if it would possible to generate a unique (and so local-like) label using #PB_Compiler_Procedure as the base for the name but for what I know it's not possible. Right ?

I was not able to do it. I tried with macros but no joy, I don't recall exactly why but probably was due to the order followed by the PB preprocessor in expanding #PB_Compiler constants and macros. Or maybe it was my fault ?

I asked about that in that post as you see, but nobody answered so I assumed there is no way to do it.

[Christian Uceda]

@Luis

Just being able to do this without crashes will be fine for me (and in line with any other language out there)

in pseudocode:

Code: Select all

procedure test()
onerrorgoto(?FAILED)

...do something messy that can fail due to the OS, like file operations...

...do something even more messier with the memory...

if something went wrong without the onerror lib noticing
 goto LOCALFAILED
endif

...more code here...

procedurereturn #true
LOCALFAILED:
procedurereturn #false
endprocedure

Right now this kind of code will crash PB once the execution jumps to the label and hits the "procedurereturn #false" statement.

I know purebasic aims for simplicty and IMHO there is no easier or simpler way to handle system errors and being able to continue program execution than what I wrote above.

I hope that when using local labels the above code works, heck even the old VB supports that kind of error handling just fine.

NOTE: Maybe I'm terribly wrong about the above, if I am, and if anyone could point me out to the right way to do it I will be thankful for all eternity.

Unfortunately if the answer is going to be like this:

Code: Select all

procedure test()
onerrorgoto(?FAILED)

...code goes here...

procedurereturn #true
LOCALFAILED:
end <------------ That is called terminating execution not error handling.
endprocedure

I'm sorry but it does not work for me as I need to terminate and exit the procedure.

[eesau]

Hehe this reminds me... [snip]

That was a brilliant story, thanks maestro

[luis]

Just being able to do this without crashes will be fine for me (and in line with any other language out there)

Using gotos is not a problem and works fine (or the @@ fasm trick), using the onerror library as I said is another thing.
I left that road for the reasons I have explained. Maybe it's ok for others, I prefer avoid that.

[Little John]

There are so many discussions about GOTO. Who talks about COMEFROM?
This is just a joke with no particular meaning.

Regards, Little John

[Christian Uceda]

@Luis

I thought the "goto" in onerrorgoto() behaved a regular "goto"...

I'm mistaken then.

It seems PB's gotos are a minefield to avoid at all costs.

@Little John

Yeah very funny, but please do not take this issue lightly just because you are not a fan of the goto command.

There is a case when goto / onerrorgoto is not only useful but desirable, and it is the reason why it is kept around. Languages where goto usage is non recommended or not supported are languages with exception handling, something very convenient PB does not have. (no complain about exceptions, but working goto and onerrorgoto would be nice )

Have a look at this: http://www.cprogramming.com/tutorial/goto.html

basically not having a functional goto / onerrorgoto is a #big pain in the ass#

[Christian Uceda]

@Little John

I just realized the small letter...