String stuff
-
And how is this a bug? I read it as a boolean expression: Is the left side of the equation (Outline) equal to the right side of the equation? If the answer is no, the result is false... It may be an issue with not understanding the language syntax, but, should others, unfamiliar with C, C++, C#, etc. post such nuances as bugs? Just my thoughts... Tim
This is a classic subtle bug. A piece of code that is perfectly syntacticaly correct but has unintended results. What exactly do YOU define as a bug? Since I didn't write it as a boolean expression the subtle typo that caused it to become a boolean expression formed the basis for it being considered a bug. It's not a misunderstanding of the syntax, and actually has little to do with the language itself. I think you failed to study the entire expression. In C for example a similar bug might be created with the expression
thivar = thivar = 1; (instead of: thisvar = thisvar + 1;)
or more likely: if (thisvar = thatvar-5) { //do something meaningfull and elegant here } The length of the expression and the complexity of the line of code makes it more subtle than that trivial expression. I've been at this for more than 30 years, It's these stupid subtle typos that still cause the most unintended results. :laugh:
-
This is a classic subtle bug. A piece of code that is perfectly syntacticaly correct but has unintended results. What exactly do YOU define as a bug? Since I didn't write it as a boolean expression the subtle typo that caused it to become a boolean expression formed the basis for it being considered a bug. It's not a misunderstanding of the syntax, and actually has little to do with the language itself. I think you failed to study the entire expression. In C for example a similar bug might be created with the expression
thivar = thivar = 1; (instead of: thisvar = thisvar + 1;)
or more likely: if (thisvar = thatvar-5) { //do something meaningfull and elegant here } The length of the expression and the complexity of the line of code makes it more subtle than that trivial expression. I've been at this for more than 30 years, It's these stupid subtle typos that still cause the most unintended results. :laugh:
Actually, I DID understand the syntax, both from a VB and from a C reference. The results may have been unintentional, but the code worked as it should. I took the 'bug' reference to mean there was a problem with the language parser, meaning, the code is not working as written. So, in that context, the bug is with HOW the code was written, not with the language itself... As yes, after doing this for over 25 years, it IS those subtle typos that cause the most problems.
-
Actually, I DID understand the syntax, both from a VB and from a C reference. The results may have been unintentional, but the code worked as it should. I took the 'bug' reference to mean there was a problem with the language parser, meaning, the code is not working as written. So, in that context, the bug is with HOW the code was written, not with the language itself... As yes, after doing this for over 25 years, it IS those subtle typos that cause the most problems.
True but a (at least my definition) bug is any unintended functioning of the program whether the compiler, or programmer is causing the unintended result is irrelevant. If you want a compiler bug I'll post the one that got me in trouble with Microsoft. It's with their old version 6 C compiler (yes C compiler not visual C) and was released about the time that the C standard was being ratified. Scott
-
Actually, I DID understand the syntax, both from a VB and from a C reference. The results may have been unintentional, but the code worked as it should. I took the 'bug' reference to mean there was a problem with the language parser, meaning, the code is not working as written. So, in that context, the bug is with HOW the code was written, not with the language itself... As yes, after doing this for over 25 years, it IS those subtle typos that cause the most problems.
All my code works as it's written. Sometimes I just didn't mean to write it that way...!! ;-) Dave
-
In vb the '&' concatenates strings"
OutLine = OutLine = "," & "D," & ThisDataset.Tables("TimeSheet").Rows(i).Item("Double Time").ToString()
I would expect outline to be added to but all I was getting was "False" After staring at it for quite a while I realized what the problem was. It's subtle but not incredibly difficult once you realize what the "False" means.
And Option Explicit On on all files... 'nuf said.
-
And Option Explicit On on all files... 'nuf said.
True, but why should there be another state apart from Option Explicit? As long as we cater for fools, could we end up looking like the sheep we are sheparding? :doh:
-
Another reason to hate vb: oberloading = instead of using ==
I still say that the C (and its ilk) assignment operator should be :=, as in Pascal.
-
This is a classic subtle bug. A piece of code that is perfectly syntacticaly correct but has unintended results. What exactly do YOU define as a bug? Since I didn't write it as a boolean expression the subtle typo that caused it to become a boolean expression formed the basis for it being considered a bug. It's not a misunderstanding of the syntax, and actually has little to do with the language itself. I think you failed to study the entire expression. In C for example a similar bug might be created with the expression
thivar = thivar = 1; (instead of: thisvar = thisvar + 1;)
or more likely: if (thisvar = thatvar-5) { //do something meaningfull and elegant here } The length of the expression and the complexity of the line of code makes it more subtle than that trivial expression. I've been at this for more than 30 years, It's these stupid subtle typos that still cause the most unintended results. :laugh:
A "logic error".
-
I still say that the C (and its ilk) assignment operator should be :=, as in Pascal.
I always thought that was stupid. Which operation do you perform more often in your code, assignment or test for equality? Assignment, of course. Making the assignment operation require two characters and the test for equality one character is inefficient. At that, at least on U.S. keyboards, it's even worse. The "
:=" construct requires four keypress actions: press Shift, press :, release Shift, press =.
Software Zen:
delete this; -
I always thought that was stupid. Which operation do you perform more often in your code, assignment or test for equality? Assignment, of course. Making the assignment operation require two characters and the test for equality one character is inefficient. At that, at least on U.S. keyboards, it's even worse. The "
:=" construct requires four keypress actions: press Shift, press :, release Shift, press =.
Software Zen:
delete this;No, I meant a bare = is not a part of the syntax; == is test for equality and := is assignment. I'll gladly type the extra character (two keystrokes) to save myself from unexpected functionality.