okay, so I posted about the If low < x < high Then syntax. The smart people got it. But now comes the big question. Under what circumstances will this code give a different result in VB6 compared to VB.NET.
If low < x < high Then
yesterday I asked people what does the code 2 < 1 < 5 produce.
Much to my amazement everyone seemed to get it right !! I must admit when the syntax was pointed out to me just the other day I really didn't expect to see what I saw. Admittedly, the syntax I used was low < x < high, still it wasn't until I fed it values for x above high or below low that I realized the syntax was doing other than I what I expected. Yes it was always True, regardless of the value of x.
But by my recent informal blog survey everyone got it right, so that possilby means either (1) it was intuitive, (2) people knew to expect the unexpected due to the way I asked the question (3) the sample set was too small to tell, and/or (4) frequent readers of my blog are the most intelligent coders there are so just because they could understand the code doesn't mean the average coder could ;)
So I'm thinking it's a combination of (2) , (3) and (4), and that the syntax is NOT intuitive <g>
So perhaps a follow question(s) should be:
(a) would you expect that result when you see If low < x < high Then, or would you expect that to test if x is in the range from low to high ?
(b) If you found code like this in existing VB production code would you leave it there ? If not, what would you say/do to the coder who wrote it ? If so,why would you use that syntax ?
Will the following VB code display True or False ? Why ?
(and no cheating by actually trying the code and decompiling it)
Option Strict Off
If 2 < 1 < 5 Then
Sometimes different problems come together to provide a unified solution. Today I think I stumbled across such a thing. Earlier today I noticed a comment post to an old blog entry of mine about how to tell if an assembly is a debug or release build
. It was nice to see that Google and my blogged helped out a fellow MVP, Doug Holland
Then tonight I was chatting with another fellow MVP who was having troubles with a C# build, over what looked like another case of over optimization by the JIT. I thought it sounded very similar to the issue I posted about String.IsNullOrEmpty causing a runtime null exception
. MVP2 asked if there was a way around the JIT optimizations. Well there is the compiler options in both VB and C#, but that switch alone does not stop these kind of over optimizations. You could of course just do a debug build but that would mean you need to remove any Debug.Asserts or Prints you might have in your code.
But putting these two seemingly different things together, gives you the option to turn on JIT tracking using the Debuggable attribute, as well as turning off optimizations.
<Assembly: Debuggable(True, True)>
This will fix the null reference issue, and may help you if you encounter weird runtime bugs only in a release build, not a debug build. Of course it does mean your code might not run as fast as it otherwise would.
Update: Well it turns out this fixes the null reference issue, but not the fix the issues that Maurice reported.
The good oil about the ADO.NET Entity Framework can be found via the MS data site