Some things just shouldn't be allowed to compile...
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
What happens if they are equal...? :doh:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
-
What happens if they are equal...? :doh:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
I am sorry I will contradict you. With a pinch of sadism/bad faith. I find these statements more readable thant would the terse
c= _start < _end. They tell you a story: by default all is fine; but if you observe an inversion of the bounds, flag this as wrong. The third variant withNot _start < _endcan be seen as the best choice as it makes explicit the desired condition as opposed to the "buggy" one. But that's not all. These forms are not only more informative for humans, but also for compilers. A single assignment would be perfectly neutral and give no hint for branch prediction. On the opposite, anIfstatement is an opportunity for compiler designers to enforce branch prediction rules such as "thethenbranch is more likely to be taken than not, unless it starts with a negation". :) -
I am sorry I will contradict you. With a pinch of sadism/bad faith. I find these statements more readable thant would the terse
c= _start < _end. They tell you a story: by default all is fine; but if you observe an inversion of the bounds, flag this as wrong. The third variant withNot _start < _endcan be seen as the best choice as it makes explicit the desired condition as opposed to the "buggy" one. But that's not all. These forms are not only more informative for humans, but also for compilers. A single assignment would be perfectly neutral and give no hint for branch prediction. On the opposite, anIfstatement is an opportunity for compiler designers to enforce branch prediction rules such as "thethenbranch is more likely to be taken than not, unless it starts with a negation". :) -
I fully agree with you. In fact, I usually write code like this myself. But then how to explain those snippets which begin with
c = False? We need more context here. Also,cis a lousy variable name, unless the surrounding code makes its meaning clear.Continuing with bad faith, the variable could be named
StartLessThanEnd,ValidRange,NormalState,InputError,ThisGuyIsLoosingHisMarbles,LookingForTroubleor other, depending on context. -
I fully agree with you. In fact, I usually write code like this myself. But then how to explain those snippets which begin with
c = False? We need more context here. Also,cis a lousy variable name, unless the surrounding code makes its meaning clear.Nonsense.bas(1) : error E3401: 'c' : can't guess the meaning
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
It's so tempting to start a language flame war.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I am sorry I will contradict you. With a pinch of sadism/bad faith. I find these statements more readable thant would the terse
c= _start < _end. They tell you a story: by default all is fine; but if you observe an inversion of the bounds, flag this as wrong. The third variant withNot _start < _endcan be seen as the best choice as it makes explicit the desired condition as opposed to the "buggy" one. But that's not all. These forms are not only more informative for humans, but also for compilers. A single assignment would be perfectly neutral and give no hint for branch prediction. On the opposite, anIfstatement is an opportunity for compiler designers to enforce branch prediction rules such as "thethenbranch is more likely to be taken than not, unless it starts with a negation". :)YvesDaoust wrote:
But that's not all. These forms are not only more informative for humans, but also for compilers. A single assignment would be perfectly neutral and give no hint for branch prediction
But.. there is no branch that needs predicting.. except the gratitous one the programmer added.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
I guess there’s no way to teach a complier to look for stupid?
-
YvesDaoust wrote:
But that's not all. These forms are not only more informative for humans, but also for compilers. A single assignment would be perfectly neutral and give no hint for branch prediction
But.. there is no branch that needs predicting.. except the gratitous one the programmer added.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
As far as I know there is always one when using an Intel processor. A comparison needs to be followed by a conditional branch. The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register. Branchless expressions can be used, such as
(_end - _start) >> 31, giving-1or0, which are even less readable. -
As far as I know there is always one when using an Intel processor. A comparison needs to be followed by a conditional branch. The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register. Branchless expressions can be used, such as
(_end - _start) >> 31, giving-1or0, which are even less readable.YvesDaoust wrote:
As far as I know there is always one when using an Intel processor A comparison needs to be followed by a conditional branch
You are incorrect. There's a compare, which sets flags, followed by a jump, which is the actual branch instruction and needs prediction. Here's some C# disassembly, Intel native will be similar:
bool b = i1 < i2;00000071 mov eax,dword ptr [ebp-40h]
00000074 cmp eax,dword ptr [ebp-44h]
00000077 setl al
0000007a movzx eax,al
0000007d mov dword ptr [ebp-48h],eaxbool c = true;00000080 mov eax,1
00000085 and eax,0FFh
0000008a mov dword ptr [ebp-4Ch],eax
if (i1 > i2)
0000008d mov eax,dword ptr [ebp-40h]
00000090 cmp eax,dword ptr [ebp-44h]
00000093 setle al
00000096 movzx eax,al
00000099 mov dword ptr [ebp-50h],eax
0000009c cmp dword ptr [ebp-50h],0
000000a0 jne 000000A9
{
000000a2 nop
c = false;
000000a3 xor edx,edx
000000a5 mov dword ptr [ebp-4Ch],edx
}
000000a8 nopYvesDaoust wrote:
The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register
You need to go read the Intel assembly guide. Compares (and many other instructions) set flags bits in the flags register. The jump instructions base their decision on how those flags are set. Intel instruction set has been this way since the 8008, and probably the 4004 before that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
YvesDaoust wrote:
As far as I know there is always one when using an Intel processor A comparison needs to be followed by a conditional branch
You are incorrect. There's a compare, which sets flags, followed by a jump, which is the actual branch instruction and needs prediction. Here's some C# disassembly, Intel native will be similar:
bool b = i1 < i2;00000071 mov eax,dword ptr [ebp-40h]
00000074 cmp eax,dword ptr [ebp-44h]
00000077 setl al
0000007a movzx eax,al
0000007d mov dword ptr [ebp-48h],eaxbool c = true;00000080 mov eax,1
00000085 and eax,0FFh
0000008a mov dword ptr [ebp-4Ch],eax
if (i1 > i2)
0000008d mov eax,dword ptr [ebp-40h]
00000090 cmp eax,dword ptr [ebp-44h]
00000093 setle al
00000096 movzx eax,al
00000099 mov dword ptr [ebp-50h],eax
0000009c cmp dword ptr [ebp-50h],0
000000a0 jne 000000A9
{
000000a2 nop
c = false;
000000a3 xor edx,edx
000000a5 mov dword ptr [ebp-4Ch],edx
}
000000a8 nopYvesDaoust wrote:
The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register
You need to go read the Intel assembly guide. Compares (and many other instructions) set flags bits in the flags register. The jump instructions base their decision on how those flags are set. Intel instruction set has been this way since the 8008, and probably the 4004 before that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
Glad to know about the
setlinstruction which indeed has the effect of transferring a flag to a register. Regarding the conditions flags, thank you, I am not a complete dummy. -
I guess there’s no way to teach a complier to look for stupid?
Obviously not - stupidity is highly creative in how it manifests itself ;)
-
YvesDaoust wrote:
As far as I know there is always one when using an Intel processor A comparison needs to be followed by a conditional branch
You are incorrect. There's a compare, which sets flags, followed by a jump, which is the actual branch instruction and needs prediction. Here's some C# disassembly, Intel native will be similar:
bool b = i1 < i2;00000071 mov eax,dword ptr [ebp-40h]
00000074 cmp eax,dword ptr [ebp-44h]
00000077 setl al
0000007a movzx eax,al
0000007d mov dword ptr [ebp-48h],eaxbool c = true;00000080 mov eax,1
00000085 and eax,0FFh
0000008a mov dword ptr [ebp-4Ch],eax
if (i1 > i2)
0000008d mov eax,dword ptr [ebp-40h]
00000090 cmp eax,dword ptr [ebp-44h]
00000093 setle al
00000096 movzx eax,al
00000099 mov dword ptr [ebp-50h],eax
0000009c cmp dword ptr [ebp-50h],0
000000a0 jne 000000A9
{
000000a2 nop
c = false;
000000a3 xor edx,edx
000000a5 mov dword ptr [ebp-4Ch],edx
}
000000a8 nopYvesDaoust wrote:
The Intel has only conditional branch instructions, no conditional moves or conditional arithmetic. Nor have I ever seen the value of a condition flag being transferred to a register
You need to go read the Intel assembly guide. Compares (and many other instructions) set flags bits in the flags register. The jump instructions base their decision on how those flags are set. Intel instruction set has been this way since the 8008, and probably the 4004 before that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
patbob wrote:
followed by a jump
Ooooh, the Jump instruction. Otherwise known in the somewhat higher level languages as "Goto" which of course "real" programmers are not allowed to use but for some unknown reason a compiler is. :)
If your neighbours don't listen to The Ramones, turn it up real loud so they can.
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
I have a guy three doors away (thank god) that likes to put in his monthly reports to the big cheese how many lines of code this or that module/programme has, as though that actually means something. I wonder how many of those lines consist of this kind of thing? No, I'm not going to look.
If your neighbours don't listen to The Ramones, turn it up real loud so they can.
-
I fully agree with you. In fact, I usually write code like this myself. But then how to explain those snippets which begin with
c = False? We need more context here. Also,cis a lousy variable name, unless the surrounding code makes its meaning clear. -
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.
If you have code that has the full series of statement snippets compiled together, I fully agree with you. If you are complaining about having so many ways to check for the same thing, I disagree with you. On a personal basis, some of those series of "saying almost the same thing" (When you start off as false and don't use Not logic = is false, all other cases, = is true.) aren't as readable as others, but also on a personal basis, I can choose the format that makes the most sense to me. Did you intend to say the same thing consistently and made a mistake?:
0bx didn't write:
c = False If _start <= _end Then c = True End If
Or are you making the point that it is difficult to always say the same thing by intentionally including a mistake in your logic? What makes it even more fun is if you make the object nullable. I don't know the VB.NET format, but C# would be:
?int c;
(Making coding more complex reduces the pool of people who can write code well. That improves your chances to shine or show you are a dunderhead. :laugh: )
-
c = True If \_start > \_end Then c = False End If c = True If \_end < \_start Then c = False End If c = True If Not \_start < \_end Then c = False End If c = True If Not \_end > \_start Then c = False End If c = False If \_start < \_end Then c = True End If c = False If \_end > \_start Then c = True End If c = False If Not \_start > \_end Then c = True End If c = False If Not \_end < \_start Then c = True End If.