On 1/29/2024 8:24 AM, Simon Clubley wrote:
$ set response/mode=good_natured
Don't be too hard on David, Dan. He still likes to use line numbers
in his BASIC code... :-)
That is a filthy slander ...
Line numbers can be used in place of labels for GoTo statements, which you'll also probably also slander. But they can be useful. Other than that, line numbers can be useful for appending boiler plate code to a program. Line numbers are used in handling error exceptions and handling.
Your implication that I use numbers on every line is just false.
If I'm going to have:
On Error GoTo 32000
Ahhh, what's the use, you're probably just laughing ...
On the plus side, and to take the opportunity to vent my anger at something that I get more angry about whenever more details are revealed, at least
you know how to reverse the sign of a variable without having to write a function to do it. :-( :-(
See:
https://news.ycombinator.com/item?id=38926582
Original reference:
https://www.postofficehorizoninquiry.org.uk/evidence/fuj00080690-report-eposs-pinicl-task-force
See page 17 onwards of the PDF. :-(
Innocent people went to jail because of the system this code is
a part of, and because of the coverup around it, and it took
a TV drama to really get things moving. :-(
So, yes, I may make fun of your line numbers, but at least you most
certainly know what you are doing, unlike the above people.
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out
there.
I have worked with people who could write spaghetti Fortran in any programming language available.
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out
there.
PS: Good compilers may have detected the unreachable code. But it
is still good vs bad compiler not good vs bad language.
Did you know that LISP has a goto?
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out
there.
I have worked with people who could write spaghetti Fortran in any
programming language available.
"A real Fortran programmer can write Fortran in any language"
Every time this comes up I post this Fortran/Pascal code:
PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.
:-)
Arne
On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out >>>> there.
I have worked with people who could write spaghetti Fortran in any
programming language available.
"A real Fortran programmer can write Fortran in any language"
Every time this comes up I post this Fortran/Pascal code:
PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399; >> L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.
:-)
Arne
I'm amused every time the GoTo bashing begins.
Not only is there nothing wrong when using a branch operation, when appropriate, just look at the assembler listings after compilation.
Branching is just about all assembler does, as required.
Now, I won't defend what I and most consider improper use of the poor misunderstood GoTo statement.
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out
there.
I have worked with people who could write spaghetti Fortran in any
programming language available. Did you know that LISP has a goto?
It does.
PS: Good compilers may have detected the unreachable code. But it
is still good vs bad compiler not good vs bad language.
The exciting part is when they tell you not to remove the unreachable
code,
because the program crashes at runtime when you do that.
Many moons ago I had to try to fix a number of programs that
crashed whenever run. Back in those days a common method was
to add statements to display variables during execution. I
had many cases where adding those statements made the program
work.
bill
On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
I have worked with people who could write spaghetti Fortran in any
programming language available.
"A real Fortran programmer can write Fortran in any language"
Every time this comes up I post this Fortran/Pascal code:
PROGRAM GOTOFUN(INPUT,OUTPUT);
I'm amused every time the GoTo bashing begins.
Not only is there nothing wrong when using a branch operation, when appropriate, just look at the assembler listings after compilation.
Branching is just about all assembler does, as required.
Now, I won't defend what I and most consider improper use of the poor misunderstood GoTo statement.
Many moons ago I had to try to fix a number of programs that
crashed whenever run. Back in those days a common method was
to add statements to display variables during execution. I
had many cases where adding those statements made the program
work.
On 30/01/2024 07:06, Dave Froble wrote:
On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out >>>>> there.
I have worked with people who could write spaghetti Fortran in any
programming language available.
"A real Fortran programmer can write Fortran in any language"
Every time this comes up I post this Fortran/Pascal code:
PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.
:-)
Arne
I'm amused every time the GoTo bashing begins.
Not only is there nothing wrong when using a branch operation, when
appropriate, just look at the assembler listings after compilation. Branching
is just about all assembler does, as required.
Now, I won't defend what I and most consider improper use of the poor
misunderstood GoTo statement.
But unless used very carefully, it can create horrible spaghetti like code, and
is also easy to screw up.
Using proper structured constructs is much better - easier to read as well, hence better maintainability.
On 1/30/2024 7:16 PM, Scott Dorsey wrote:
bill <bill.gunshannon@gmail.com> wrote:
Many moons ago I had to try to fix a number of programs that crashed
whenever run. Back in those days a common method was to add
statements to display variables during execution. I had many cases
where adding those statements made the program work.
Yes, this is a sign of a fandango on core. In Fortran it is likely
exceeding array bounds or bad parameter passing, but in C the
possibilities to screw up with pointers are endless.
Bingo!!!
It was mostly Fortran but every once in a while some idiot would do it
in COBOL, too.
On 1/30/2024 9:40 AM, Chris Townley wrote:
On 30/01/2024 07:06, Dave Froble wrote:
On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers >>>>>> out
there.
I have worked with people who could write spaghetti Fortran in any
programming language available.
"A real Fortran programmer can write Fortran in any language"
Every time this comes up I post this Fortran/Pascal code:
PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.
:-)
Arne
I'm amused every time the GoTo bashing begins.
Not only is there nothing wrong when using a branch operation, when
appropriate, just look at the assembler listings after compilation.
Branching
is just about all assembler does, as required.
Now, I won't defend what I and most consider improper use of the poor
misunderstood GoTo statement.
But unless used very carefully, it can create horrible spaghetti like
code, and
is also easy to screw up.
Using proper structured constructs is much better - easier to read as
well,
hence better maintainability.
Prey tell, what structured construct will perform cleanup and exit? I always expected a return from routines and such.
Prey tell, what structured construct will perform cleanup and exit?
I always expected a return from routines and such.
On 1/30/2024 9:40 AM, Chris Townley wrote:
On 30/01/2024 07:06, Dave Froble wrote:
On 1/29/2024 8:02 PM, Arne Vajhj wrote:
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out >>>>>> there.
I have worked with people who could write spaghetti Fortran in any
programming language available.
"A real Fortran programmer can write Fortran in any language"
Every time this comes up I post this Fortran/Pascal code:
PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.
:-)
Arne
I'm amused every time the GoTo bashing begins.
Not only is there nothing wrong when using a branch operation, when
appropriate, just look at the assembler listings after compilation. Branching
is just about all assembler does, as required.
Now, I won't defend what I and most consider improper use of the poor
misunderstood GoTo statement.
But unless used very carefully, it can create horrible spaghetti like code, and
is also easy to screw up.
Using proper structured constructs is much better - easier to read as well, >> hence better maintainability.
Prey tell, what structured construct will perform cleanup and exit? I
always expected a return from routines and such.
On 1/30/2024 9:40 AM, Chris Townley wrote:
On 30/01/2024 07:06, Dave Froble wrote:
I'm amused every time the GoTo bashing begins.
Not only is there nothing wrong when using a branch operation, when
appropriate, just look at the assembler listings after compilation.
Branching
is just about all assembler does, as required.
Now, I won't defend what I and most consider improper use of the poor
misunderstood GoTo statement.
But unless used very carefully, it can create horrible spaghetti like
code, and
is also easy to screw up.
Using proper structured constructs is much better - easier to read as
well,
hence better maintainability.
Prey tell, what structured construct will perform cleanup and exit? I always expected a return from routines and such.
The third option, the one I like least (an understatement) is use of >exceptions. Despite my personal preferences, it's quite popular.
For the not VB.NET knowledgable:
Using o1 As New X("A")
...
End Using
calls o1.Dispose() when the block is exited no matter how it
is exited - normal or exception does not matter Dispose is
always called.
On 2024-01-31, Arne Vajhøj <arne@vajhoej.dk> wrote:
For the not VB.NET knowledgable:
Using o1 As New X("A")
...
End Using
calls o1.Dispose() when the block is exited no matter how it
is exited - normal or exception does not matter Dispose is
always called.
Unless there is a power failure or a system crash.
I wonder how many people think of that one when assuming that their
state reset code will _always_ run after execution of the routine
has started. :-)
On 31/01/2024 04:28, Dave Froble wrote:
On 1/30/2024 9:40 AM, Chris Townley wrote:
On 30/01/2024 07:06, Dave Froble wrote:
On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out >>>>>>> there.
I have worked with people who could write spaghetti Fortran in any >>>>>> programming language available.
"A real Fortran programmer can write Fortran in any language"
Every time this comes up I post this Fortran/Pascal code:
PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399; >>>>> L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.
:-)
Arne
I'm amused every time the GoTo bashing begins.
Not only is there nothing wrong when using a branch operation, when
appropriate, just look at the assembler listings after compilation. Branching
is just about all assembler does, as required.
Now, I won't defend what I and most consider improper use of the poor
misunderstood GoTo statement.
But unless used very carefully, it can create horrible spaghetti like code, and
is also easy to screw up.
Using proper structured constructs is much better - easier to read as well, >>> hence better maintainability.
Prey tell, what structured construct will perform cleanup and exit? I always
expected a return from routines and such.
It would depend on what is needing to be done
Michael S <already5chosen@yahoo.com> wrote:
The third option, the one I like least (an understatement) is use of
exceptions. Despite my personal preferences, it's quite popular.
Exceptions can be very elegant or very inelegant... and it is entirely possible to have an exception that doesn't clean anything up at all and
just exits and lets the operating system deal with the memory. On many systems this is a great idea because being able to exit quickly on a failure is more important than people give it credit for. On some other systems
that have memory management issues it can lead to leakage.
On 1/31/2024 11:17 AM, Scott Dorsey wrote:
Michael S <already5chosen@yahoo.com> wrote:
The third option, the one I like least (an understatement) is use of
exceptions. Despite my personal preferences, it's quite popular.
Exceptions can be very elegant or very inelegant... and it is entirely
possible to have an exception that doesn't clean anything up at all and
just exits and lets the operating system deal with the memory. On many
systems this is a great idea because being able to exit quickly on a failure >> is more important than people give it credit for. On some other systems
that have memory management issues it can lead to leakage.
It is probably a bit easier to implement exceptions in languages
with garbage collection and a lot easier for developers to avoid
memory leak bugs.
$ type mem.cpp
#include <iostream>
#include <string>
using namespace std;
class X
{
private:
string id;
public:
X(string id) { this->id = id; cout << "Allocate " << id << endl; }
virtual ~X() { cout << "Deallocate " << id << endl; }
};
void f2()
{
throw "Houston we have a problem";
}
void f1()
{
X o2("o2");
X *o3 = new X("o3");
f2();
delete o3;
}
int main()
{
try
{
X o1("o1");
f1();
}
catch(char *ex)
{
cout << ex << endl;
}
return 0;
}
$ cxx mem.cpp
$ cxxlink mem
link mem
$ run mem
Allocate o1
Allocate o2
Allocate o3
Deallocate o2
Deallocate o1
Houston we have a problem
$
We see that o2 did get deallocated, but o3 did not get deallocated.
We had a machine that ran FORTRAN for the physics department. One guy
had a program that crashed the machine. As in, the microcode halted.
That was an array bounds error.
Full story:
http://www.bobeager.uk/anecdotes.html#hwhack
For the not VB.NET knowledgable:
Using o1 As New X("A")
...
End Using
calls o1.Dispose() when the block is exited no matter how it is exited - normal or exception does not matter Dispose is always called.
One option is named construct and named break.
On 31 Jan 2024 09:54:15 GMT, Bob Eager wrote:
We had a machine that ran FORTRAN for the physics department. One
guy had a program that crashed the machine. As in, the microcode
halted. That was an array bounds error.
Full story:
http://www.bobeager.uk/anecdotes.html#hwhack
We contacted ICL, but we never seemed to reach anyone who either
understood what the problem was, or had the power or inclination
to get it fixed ...
If this was not after the Fujitsu acquisition, I assume it wasn’t
long before ...
On Wed, 31 Jan 2024 10:20:35 -0500, Arne Vajhøj wrote:
For the not VB.NET knowledgable:
Using o1 As New X("A")
...
End Using
calls o1.Dispose() when the block is exited no matter how it is exited -
normal or exception does not matter Dispose is always called.
Python has “context managers” which are a generalization of this. It also has “try/finally” blocks, which are good for one-off cases.
I have never written a goto in C code (not production code, anyway). These days, you need to do so much dynamic allocation, there is nearly always
some need for cleanup when exiting an inner block anyway, so you can’t
just jump directly somewhere else first. The overall pattern looks like
this:
MyPtr obj = NULL;
do /*once*/
{
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
break;
... possible other stuff using obj ...
}
while (false);
free(obj);
You can confirm, just by inspection, that there is no path out of the
block that does not pass through the free() call precisely once.
(Not that I prefer to have to implement manual cleanup, much as I'd like
to avoid explicitly deallocating memory in C.
On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
I have never written a goto in C code (not production code, anyway). These >> days, you need to do so much dynamic allocation, there is nearly always
some need for cleanup when exiting an inner block anyway, so you can’t
just jump directly somewhere else first. The overall pattern looks like
this:
MyPtr obj = NULL;
do /*once*/
{
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
break;
... possible other stuff using obj ...
}
while (false);
free(obj);
You can confirm, just by inspection, that there is no path out of the
block that does not pass through the free() call precisely once.
And the difference compared to:
MyPtr obj = NULL;
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
goto lbl_freeobj;
... possible other stuff using obj ...
lbl_freeobj:
free(obj);
are?
Arne
On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
I have never written a goto in C code (not production code, anyway). These >> days, you need to do so much dynamic allocation, there is nearly always
some need for cleanup when exiting an inner block anyway, so you can’t
just jump directly somewhere else first. The overall pattern looks like
this:
MyPtr obj = NULL;
do /*once*/
{
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
break;
... possible other stuff using obj ...
}
while (false);
free(obj);
You can confirm, just by inspection, that there is no path out of the
block that does not pass through the free() call precisely once.
And the difference compared to:
MyPtr obj = NULL;
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
goto lbl_freeobj;
... possible other stuff using obj ...
lbl_freeobj:
free(obj);
are?
On 1/31/2024 4:24 PM, Lawrence D'Oliveiro wrote:
On Wed, 31 Jan 2024 10:20:35 -0500, Arne Vajhøj wrote:
For the not VB.NET knowledgable:
Using o1 As New X("A")
...
End Using
calls o1.Dispose() when the block is exited no matter how it is exited - >>> normal or exception does not matter Dispose is always called.
Python has “context managers” which are a generalization of this. It also
has “try/finally” blocks, which are good for one-off cases.
C# was born with using (2002), Python got with in 2.5 (2006)
and Java got try with resource in 1.7 (2011).
MS got a good idea and the rest copied it.
On Wed, 31 Jan 2024 17:13:26 -0500, Arne Vajhøj wrote:
On 1/31/2024 4:24 PM, Lawrence D'Oliveiro wrote:
On Wed, 31 Jan 2024 10:20:35 -0500, Arne Vajhøj wrote:
For the not VB.NET knowledgable:
Using o1 As New X("A")
...
End Using
calls o1.Dispose() when the block is exited no matter how it is exited - >>>> normal or exception does not matter Dispose is always called.
Python has “context managers” which are a generalization of this. It also
has “try/finally” blocks, which are good for one-off cases.
C# was born with using (2002), Python got with in 2.5 (2006)
and Java got try with resource in 1.7 (2011).
MS got a good idea and the rest copied it.
That is also true of async/await. But note that Python is the only one
of the three that tries to use reference-counting as an alternative to garbage collection.
And now it looks like C# might be shuffling off into those retirement pastures <https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/>.
On 1/31/2024 7:03 AM, Chris Townley wrote:
On 31/01/2024 04:28, Dave Froble wrote:
On 1/30/2024 9:40 AM, Chris Townley wrote:
On 30/01/2024 07:06, Dave Froble wrote:
On 1/29/2024 8:02 PM, Arne Vajhøj wrote:
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad
programmers out
there.
I have worked with people who could write spaghetti Fortran in any >>>>>>> programming language available.
"A real Fortran programmer can write Fortran in any language"
Every time this comes up I post this Fortran/Pascal code:
PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO >>>>>> L399;
L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END; >>>>>> L399: GOTO L761;
L601: END.
:-)
Arne
I'm amused every time the GoTo bashing begins.
Not only is there nothing wrong when using a branch operation, when
appropriate, just look at the assembler listings after
compilation. Branching
is just about all assembler does, as required.
Now, I won't defend what I and most consider improper use of the poor >>>>> misunderstood GoTo statement.
But unless used very carefully, it can create horrible spaghetti
like code, and
is also easy to screw up.
Using proper structured constructs is much better - easier to read
as well,
hence better maintainability.
Prey tell, what structured construct will perform cleanup and exit?
I always
expected a return from routines and such.
It would depend on what is needing to be done
Final cleanup, if required, and exit the program.
Knew a guy that would us a gosub to go to the END statement. Drove me
nuts.
On Wed, 31 Jan 2024 17:08:44 -0500, Arne Vajhøj wrote:
On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
I have never written a goto in C code (not production code, anyway). These >>> days, you need to do so much dynamic allocation, there is nearly always
some need for cleanup when exiting an inner block anyway, so you can’t >>> just jump directly somewhere else first. The overall pattern looks like
this:
MyPtr obj = NULL;
do /*once*/
{
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
break;
... possible other stuff using obj ...
}
while (false);
free(obj);
You can confirm, just by inspection, that there is no path out of the
block that does not pass through the free() call precisely once.
And the difference compared to:
MyPtr obj = NULL;
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
goto lbl_freeobj;
... possible other stuff using obj ...
lbl_freeobj:
free(obj);
are?
Nesting.
Try to scale up to something like
static PyObject * discipline_makedict
(
PyObject * self,
PyObject * args
)
{
PyObject * result = NULL;
PyObject * tempresult = NULL;
br_PyObject * items;
const br_char * msg = NULL;
do /*once*/
{
const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
if (not parsed_ok)
break;
fprintf(stdout, "makedict says: “%s”\n", msg);
if (not PyTuple_Check(items))
{
PyErr_SetString(PyExc_TypeError, "expecting a tuple");
break;
} /*if*/
const ssize_t nr_items = PyTuple_Size(items);
if (PyErr_Occurred())
break;
tempresult = PyDict_New();
if (tempresult == NULL)
break;
for (ssize_t i = 0;;)
{
if (i == nr_items)
break;
br_PyObject * const item = PyTuple_GetItem(items, i);
if (item == NULL)
break;
if (not PyTuple_Check(item) or PyTuple_Size(item) != 2)
{
PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
break;
} /*if*/
br_PyObject * const first = PyTuple_GetItem(item, 0);
if (first == NULL)
break;
br_PyObject * const second = PyTuple_GetItem(item, 1);
if (second == NULL)
break;
if (first == (PyObject *)&ExceptMe_type or second == (PyObject *)&ExceptMe_type)
{
PyErr_SetString(PyExc_ValueError, "ExceptMe object found");
break;
} /*if*/
if (PyDict_SetItem(tempresult, first, second) < 0)
break;
++i;
} /*for*/
if (PyErr_Occurred())
break;
/* all done */
result = tempresult;
tempresult = NULL; /* so I don’t dispose of it yet */
}
while (false);
Py_XDECREF(tempresult);
return
result;
} /*discipline_makedict*/
More details here <https://gitlab.com/ldo/a_structured_discipline_of_programming/>.
On 1/31/2024 6:21 PM, Lawrence D'Oliveiro wrote:
On Wed, 31 Jan 2024 17:08:44 -0500, Arne Vajhøj wrote:
On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:[snip]
Nesting.
Goto work fine with nested loops. In fact it is one of the cases
where it really makes sense.
Try to scale up to something like
static PyObject * discipline_makedict
(
PyObject * self,
PyObject * args
)
{
PyObject * result = NULL;
PyObject * tempresult = NULL;
br_PyObject * items;
const br_char * msg = NULL;
do /*once*/
{
const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg); >> if (not parsed_ok)
break;
fprintf(stdout, "makedict says: “%s”\n", msg);
if (not PyTuple_Check(items))
{
PyErr_SetString(PyExc_TypeError, "expecting a tuple");
break;
} /*if*/
const ssize_t nr_items = PyTuple_Size(items);
if (PyErr_Occurred())
break;
tempresult = PyDict_New();
if (tempresult == NULL)
break;
for (ssize_t i = 0;;)
{
if (i == nr_items)
break;
br_PyObject * const item = PyTuple_GetItem(items, i);
if (item == NULL)
break;
if (not PyTuple_Check(item) or PyTuple_Size(item) != 2)
{
PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
break;
} /*if*/
br_PyObject * const first = PyTuple_GetItem(item, 0);
if (first == NULL)
break;
br_PyObject * const second = PyTuple_GetItem(item, 1);
if (second == NULL)
break;
if (first == (PyObject *)&ExceptMe_type or second == (PyObject *)&ExceptMe_type)
{
PyErr_SetString(PyExc_ValueError, "ExceptMe object found"); >> break;
} /*if*/
if (PyDict_SetItem(tempresult, first, second) < 0)
break;
++i;
} /*for*/
if (PyErr_Occurred())
break;
/* all done */
result = tempresult;
tempresult = NULL; /* so I don’t dispose of it yet */
}
while (false);
Py_XDECREF(tempresult);
return
result;
} /*discipline_makedict*/
That code would look a lot cleaner if the do while(false) loop got
removed and the relevant breaks got replaced by goto's.
A well named goto label is much more informative than a plain break.
More details here
<https://gitlab.com/ldo/a_structured_discipline_of_programming/>.
Truly bad design.
All the code examples would look better with the do while(false) loops >removed and appropriate goto's.
I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
My question is, why? If the need is a simple and rather easy to understand
branch, why get complex,
C# is primarily for business applications.
That code would look a lot cleaner if the do while(false) loop got
removed and the relevant breaks got replaced by goto's.
In article <upejl0$1nkl5$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
My question is, why? If the need is a simple and rather easy to understand >> branch, why get complex,
`goto` by itself is a sharp tool; sometimes incredibly useful,
but dangerous if misused. Our industry is littered with example
after example of `goto` misused. For instance, https://dwheeler.com/essays/apple-goto-fail.html
That said, `goto` obviously _does_ have a place when used
judiciously.
On 1/31/2024 6:21 PM, Lawrence D'Oliveiro wrote:
On Wed, 31 Jan 2024 17:08:44 -0500, Arne Vajhøj wrote:
On 1/31/2024 4:28 PM, Lawrence D'Oliveiro wrote:
I have never written a goto in C code (not production code, anyway). These >>>> days, you need to do so much dynamic allocation, there is nearly always >>>> some need for cleanup when exiting an inner block anyway, so you can’t >>>> just jump directly somewhere else first. The overall pattern looks like >>>> this:
MyPtr obj = NULL;
do /*once*/
{
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
break;
... possible other stuff using obj ...
}
while (false);
free(obj);
You can confirm, just by inspection, that there is no path out of the
block that does not pass through the free() call precisely once.
And the difference compared to:
MyPtr obj = NULL;
... possible other stuff ...
«allocate memory for obj»;
if («error occurred»)
goto lbl_freeobj;
... possible other stuff using obj ...
lbl_freeobj:
free(obj);
are?
Nesting.
Goto work fine with nested loops. In fact it is one of the cases
where it really makes sense.
Try to scale up to something like
static PyObject * discipline_makedict
(
PyObject * self,
PyObject * args
)
{
PyObject * result = NULL;
PyObject * tempresult = NULL;
br_PyObject * items;
const br_char * msg = NULL;
do /*once*/
{
const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg); >> if (not parsed_ok)
break;
fprintf(stdout, "makedict says: “%s”\n", msg);
if (not PyTuple_Check(items))
{
PyErr_SetString(PyExc_TypeError, "expecting a tuple");
break;
} /*if*/
const ssize_t nr_items = PyTuple_Size(items);
if (PyErr_Occurred())
break;
tempresult = PyDict_New();
if (tempresult == NULL)
break;
for (ssize_t i = 0;;)
{
if (i == nr_items)
break;
br_PyObject * const item = PyTuple_GetItem(items, i);
if (item == NULL)
break;
if (not PyTuple_Check(item) or PyTuple_Size(item) != 2)
{
PyErr_SetString(PyExc_TypeError, "expecting a 2-tuple");
break;
} /*if*/
br_PyObject * const first = PyTuple_GetItem(item, 0);
if (first == NULL)
break;
br_PyObject * const second = PyTuple_GetItem(item, 1);
if (second == NULL)
break;
if (first == (PyObject *)&ExceptMe_type or second == (PyObject >> *)&ExceptMe_type)
{
PyErr_SetString(PyExc_ValueError, "ExceptMe object found"); >> break;
} /*if*/
if (PyDict_SetItem(tempresult, first, second) < 0)
break;
++i;
} /*for*/
if (PyErr_Occurred())
break;
/* all done */
result = tempresult;
tempresult = NULL; /* so I don’t dispose of it yet */
}
while (false);
Py_XDECREF(tempresult);
return
result;
} /*discipline_makedict*/
That code would look a lot cleaner if the do while(false) loop got
removed and the relevant breaks got replaced by goto's.
A well named goto label is much more informative than a plain break.
More details here
<https://gitlab.com/ldo/a_structured_discipline_of_programming/>.
Truly bad design.
All the code examples would look better with the do while(false) loops removed and appropriate goto's.
Arne
GoTo can be dangerous ...
Learn good programming habits ...
On Wed, 2024-01-31 at 22:57 -0500, Dave Froble wrote:
GoTo can be dangerous ...
Learn good programming habits ...
Linux uses goto in the kernel a lot. Should I throw it in the bin?
On 1/31/2024 8:26 PM, Dan Cross wrote:
In article <upejl0$1nkl5$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
My question is, why? If the need is a simple and rather easy to understand
branch, why get complex,
`goto` by itself is a sharp tool; sometimes incredibly useful,
but dangerous if misused. Our industry is littered with example
after example of `goto` misused. For instance,
https://dwheeler.com/essays/apple-goto-fail.html
Cars are dangerous, should we go back to horses?
Horses are dangerous, should we go back to walking?
Walking is dangerous ...
Flying is dangerous ...
Boats are dangerous ...
Crossing the street is dangerous. But we're taught to look before stepping in >front of the bus.
GoTo can be dangerous ...
Learn good programming habits ...
That said, `goto` obviously _does_ have a place when used
judiciously.
Yes, that ...
I would argue this is more idiomatic, shorter, simpler, easier
to both read and to reason about, and uses fewer variables.
On 1/31/2024 8:26 PM, Dan Cross wrote:
In article <upejl0$1nkl5$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
I've seen code that did all kinds of confusing things, just avoid a GoTo branch.
My question is, why? If the need is a simple and rather easy to understand
branch, why get complex,
`goto` by itself is a sharp tool; sometimes incredibly useful,
but dangerous if misused. Our industry is littered with example
after example of `goto` misused. For instance,
https://dwheeler.com/essays/apple-goto-fail.html
Cars are dangerous, should we go back to horses?
Horses are dangerous, should we go back to walking?
Walking is dangerous ...
Flying is dangerous ...
Boats are dangerous ...
GoTo can be dangerous ...
Learn good programming habits ...
On 2024-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
I would argue this is more idiomatic, shorter, simpler, easier
to both read and to reason about, and uses fewer variables.
I agree and this is the general style I use, but with one difference.
In my code, I always, always, use braces in an if() statement, even
if the conditional code is only a single statement. For example:
const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
if (!parsed_ok)
{
return NULL;
}
I think that makes it more clear and removes any possibility of future
code changes accidentally not adding the braces at that time.
[And yes, about the above indentation, Simon _is_ indeed a Whitesmiths >person. :-)]
On Wed, 31 Jan 2024 19:29:14 -0500, Arne Vajhøj wrote:
That code would look a lot cleaner if the do while(false) loop got
removed and the relevant breaks got replaced by goto's.
Show us how you would do it. I can take you through my code step by step, >block by block, if that will help.
On 2024-01-31, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
I would argue this is more idiomatic, shorter, simpler, easier
to both read and to reason about, and uses fewer variables.
I agree and this is the general style I use, but with one difference.
In my code, I always, always, use braces in an if() statement, even
if the conditional code is only a single statement. For example:
const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);
if (!parsed_ok)
{
return NULL;
}
I think that makes it more clear and removes any possibility of future
code changes accidentally not adding the braces at that time.
const bool parsed_ok = PyArg_ParseTuple(args, "Os", &items, &msg);That is a common coding convention.
if (!parsed_ok)
{
return NULL;
}
On 1/31/2024 11:17 AM, Scott Dorsey wrote:
Michael S <already5chosen@yahoo.com> wrote:
The third option, the one I like least (an understatement) is use of
exceptions. Despite my personal preferences, it's quite popular.
Exceptions can be very elegant or very inelegant... and it is entirely
possible to have an exception that doesn't clean anything up at all and
just exits and lets the operating system deal with the memory. On many
systems this is a great idea because being able to exit quickly on a failure >> is more important than people give it credit for. On some other systems
that have memory management issues it can lead to leakage.
It is probably a bit easier to implement exceptions in languages
with garbage collection and a lot easier for developers to avoid
memory leak bugs.
On Wed, 2024-01-31 at 22:57 -0500, Dave Froble wrote:
GoTo can be dangerous ...
Learn good programming habits ...
Linux uses goto in the kernel a lot. Should I throw it in the bin?
On Wed, 31 Jan 2024 19:42:50 -0500, Arne Vajhøj wrote:
C# is primarily for business applications.
Never heard of it being used for anything important. For example,
Microsoft would never use it itself in Office.
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
On 1/31/2024 11:17 AM, Scott Dorsey wrote:
Michael S <already5chosen@yahoo.com> wrote:
The third option, the one I like least (an understatement) is use of
exceptions. Despite my personal preferences, it's quite popular.
Exceptions can be very elegant or very inelegant... and it is entirely
possible to have an exception that doesn't clean anything up at all and
just exits and lets the operating system deal with the memory. On many
systems this is a great idea because being able to exit quickly on a failure
is more important than people give it credit for. On some other systems >>> that have memory management issues it can lead to leakage.
It is probably a bit easier to implement exceptions in languages
with garbage collection and a lot easier for developers to avoid
memory leak bugs.
True, but "dispose of all memory belonging to this process" should not be
a big deal on a demand-paged machine. There are some architectures where
it can be, though.
On Wed, 31 Jan 2024 19:29:14 -0500, Arne Vajhøj wrote:
That code would look a lot cleaner if the do while(false) loop got
removed and the relevant breaks got replaced by goto's.
Show us how you would do it. I can take you through my code step by step, block by block, if that will help.
On 2/1/2024 9:49 PM, Arne Vajhøj wrote:
It gets even more clear in the nested case.
do {
allocate(o1);
...
if(...) break;
...
flag = FALSE;
do {
allocate(o2)
...
if(...) {
flag = TRUE;
break;
}
...
}
deallocate(o2)
if(flag) break;
...
} while(false);
deallocate(o1);
vs:
allocate(o1);
...
if(...) goto cleanup_1;
...
allocate(o2);
...
if(...) goto cleanup_1_and_2;
...
cleanup_1_and_2:
deallocate(o2);
cleanup_1:
deallocate(o1);
The nested do while loop is a big mess. The goto solution
is still simple.
Well, I'd use:
Select <something>
Case = "1"
Some code
Case = "2"
Some other code
End Select
But even that can be abused.
Got a friend that got carried away with Select and indenting.
When the Select statements got nested a dozen times, and indents became
8-10 tabs, and the code for each CASE was several pages long ...
If the damn code was going to be so massive and complex, he should have
just branched/performed/whatever to a separate place to do all that work.
On 1/31/2024 9:49 PM, Lawrence D'Oliveiro wrote:
On Wed, 31 Jan 2024 19:29:14 -0500, Arne Vajhøj wrote:
That code would look a lot cleaner if the do while(false) loop got
removed and the relevant breaks got replaced by goto's.
Show us how you would do it. I can take you through my code step by step,
block by block, if that will help.
It is pretty simple.
do {
allocate(o1);
...
if(...) break;
...
} while(false);
deallocate(o1);
can be done as:
allocate(o1);
...
if(...) goto cleanup;
...
cleanup:
deallocate(o1);
The first piece of code is pretty bad as it confuses the
reader by using a loop and the break is not very
self documenting.
The second piece of code is straight forward to read
despite using goto.
It gets even more clear in the nested case.
do {
allocate(o1);
...
if(...) break;
...
flag = FALSE;
do {
allocate(o2)
...
if(...) {
flag = TRUE;
break;
}
...
}
deallocate(o2)
if(flag) break;
...
} while(false);
deallocate(o1);
vs:
allocate(o1);
...
if(...) goto cleanup_1;
...
allocate(o2);
...
if(...) goto cleanup_1_and_2;
...
cleanup_1_and_2:
deallocate(o2);
cleanup_1:
deallocate(o1);
The nested do while loop is a big mess. The goto solution
is still simple.
Arne
The nested do while loop is a big mess.
To quote from Linux kernel coding style doc:
<quote>
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you’re screwed anyway, and should fix your program.
On 1/31/2024 9:50 PM, Lawrence D'Oliveiro wrote:
On Wed, 31 Jan 2024 19:42:50 -0500, Arne Vajhøj wrote:
C# is primarily for business applications.
Never heard of it being used for anything important. For example,
Microsoft would never use it itself in Office.
It is correct that MS never rewrote MSO from C++ to C#.
They did port VS to C# though.
But C# is all over. Finance, e-commerce, government etc..
GoTo can be dangerous ...
Learn good programming habits ...
Linux uses goto in the kernel a lot. Should I throw it in the bin?
Pitch it because it's Linux, not because of the goto
On 2/1/2024 11:48 PM, Lawrence D'Oliveiro wrote:
On Thu, 1 Feb 2024 22:11:20 -0500, Arne Vajhøj wrote:
It is correct that MS never rewrote MSO from C++ to C#.
They did port VS to C# though.
Maybe, but VS Code takes an entirely different tack, using Electron (the
Chromium engine + TypeScript/JavaScript) instead. Wonder why?
VSC was intended to compete with Atom on Windows/Linux/macOS. VSC
was released before .NET Core. So MS did not have much of a choice.
On Thu, 1 Feb 2024 22:11:20 -0500, Arne Vajhøj wrote:
On 1/31/2024 9:50 PM, Lawrence D'Oliveiro wrote:
On Wed, 31 Jan 2024 19:42:50 -0500, Arne Vajhøj wrote:
C# is primarily for business applications.
Never heard of it being used for anything important. For example,
Microsoft would never use it itself in Office.
It is correct that MS never rewrote MSO from C++ to C#.
They did port VS to C# though.
Maybe, but VS Code takes an entirely different tack, using Electron (the Chromium engine + TypeScript/JavaScript) instead. Wonder why?
But C# is all over. Finance, e-commerce, government etc..
All that stuff that’s now in the cloud?
On Thu, 1 Feb 2024 22:44:56 -0500, Arne Vajhøj wrote:
To quote from Linux kernel coding style doc:
<quote>
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you’re screwed anyway, and should fix >> your program.
I think this is a load of nonsense.
On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
The nested do while loop is a big mess.
Looks like you are adding a whole lot more lines of code in the form of
jumps and places to jump to, and flags to control what to do when you get >there. Adding a bit of a combinatorial explosion in possible cases that
have to be verified somehow.
In short, you are making a bigger mess.
On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
The nested do while loop is a big mess.
Looks like you are adding a whole lot more lines of code in the form of
jumps and places to jump to, and flags to control what to do when you get there. Adding a bit of a combinatorial explosion in possible cases that
have to be verified somehow.
In article <uphsad$2fg0v$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
The nested do while loop is a big mess.
Looks like you are adding a whole lot more lines of code in the form of
jumps and places to jump to, and flags to control what to do when you get
there. Adding a bit of a combinatorial explosion in possible cases that
have to be verified somehow.
In short, you are making a bigger mess.
Again, for this example, the code needs neither goto nor
the abstruse loop structure you wrote. See my earlier
post for details.
On 2/2/2024 8:49 AM, Dan Cross wrote:
In article <uphsad$2fg0v$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
The nested do while loop is a big mess.
Looks like you are adding a whole lot more lines of code in the form of
jumps and places to jump to, and flags to control what to do when you get >>> there. Adding a bit of a combinatorial explosion in possible cases that
have to be verified somehow.
In short, you are making a bigger mess.
Again, for this example, the code needs neither goto nor
the abstruse loop structure you wrote. See my earlier
post for details.
He cut so much that the context was not obvious.
But his post was a reply to my post with generic
... blocks.
It is true the first specific example he provided
did not need to solve this problem if it was
restructured a little.
On Wed, 31 Jan 2024 11:05:22 -0500, Stephen Hoffman wrote:
(Not that I prefer to have to implement manual cleanup, much as I'd
like to avoid explicitly deallocating memory in C.
Note that free(3) is defined as idempotent; freeing a NULL pointer is a harmless no-op. That simplifies things a lot.
On 2/1/2024 8:44 PM, Scott Dorsey wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
On 1/31/2024 11:17 AM, Scott Dorsey wrote:
Michael S <already5chosen@yahoo.com> wrote:
The third option, the one I like least (an understatement) is use of >>>>> exceptions. Despite my personal preferences, it's quite popular.
Exceptions can be very elegant or very inelegant... and it is entirely >>>> possible to have an exception that doesn't clean anything up at all and >>>> just exits and lets the operating system deal with the memory. On many >>>> systems this is a great idea because being able to exit quickly on a failure
is more important than people give it credit for. On some other systems >>>> that have memory management issues it can lead to leakage.
It is probably a bit easier to implement exceptions in languages
with garbage collection and a lot easier for developers to avoid
memory leak bugs.
True, but "dispose of all memory belonging to this process" should not be
a big deal on a demand-paged machine. There are some architectures where
it can be, though.
The issue is not if the process goes away but if the process
continue after execution flow has dropped back a number of levels
on the call stack.
No, that free ignores a null doesn't simplify the bookkeeping.
On 1/29/2024 7:50 PM, kludge@panix.com wrote:
=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:
The code is VB6.I have worked with people who could write spaghetti Fortran in any
But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.
So it just shows that there are some really really bad programmers out
there.
programming language available. Did you know that LISP has a goto?
It does.
PS: Good compilers may have detected the unreachable code. But itThe exciting part is when they tell you not to remove the unreachable
is still good vs bad compiler not good vs bad language.
code,
because the program crashes at runtime when you do that.
Many moons ago I had to try to fix a number of programs that
crashed whenever run. Back in those days a common method was
to add statements to display variables during execution. I
had many cases where adding those statements made the program
work.
bill
On 2/1/2024 11:48 PM, Lawrence D'Oliveiro wrote:
On Thu, 1 Feb 2024 22:11:20 -0500, Arne Vajhøj wrote:
But C# is all over. Finance, e-commerce, government etc..
All that stuff that’s now in the cloud?
A lot of it.
But C# does not care if if the hardware it runs on is bought or rented.
On 2/1/2024 11:51 PM, Lawrence D'Oliveiro wrote:
On Thu, 1 Feb 2024 22:44:56 -0500, Arne Vajhøj wrote:
To quote from Linux kernel coding style doc:
<quote>
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you’re screwed anyway, and should
fix your program.
I think this is a load of nonsense.
Apparently Linus doesn't think so.
And while few may have worded is this blunt, then it is generally
accepted that deep nesting is a code smell and should be refactored and
code moved out to functions/methods.
On 2/1/2024 11:50 PM, Lawrence D'Oliveiro wrote:
On Thu, 1 Feb 2024 21:49:56 -0500, Arne Vajhøj wrote:
The nested do while loop is a big mess.
Looks like you are adding a whole lot more lines of code in the form of
jumps and places to jump to, and flags to control what to do when you
get there. Adding a bit of a combinatorial explosion in possible cases
that have to be verified somehow.
I "added" lines so that the total number of lines "increased" from 7 to
6 in the one-level example and from 20 to 12 in the two-level example.
Final cleanup, if required, and exit the program.
Knew a guy that would us a gosub to go to the END statement. Drove me
nuts.
Cars are dangerous, should we go back to horses?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 439 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:24:25 |
| Calls: | 9,147 |
| Files: | 13,433 |
| Messages: | 6,041,154 |