|
This sounds to me like: it was evaluating for false and now is evaluation for true.
Best regards,
Jaime.
|
|
|
|
|
Definitely not! It means not not, does it not?
|
|
|
|
|
This does remind me of the admin authentication of a custom made e-shop I saw once.
The script checked whether the user name and admin matched, but there was no check whatsoever if this user was an admin. In other words, everyone with an account on the site could get in the admin panel 
Jeroen De Dauw
---
Forums ; Blog ; Wiki
---
70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
|
|
|
|
|
it's cute!
maybe I should do that too! 
Well maybe he did that just because he like the look of it and, anyway (!!b == b) is true (at least in C#, I guess it's not in C), so that's alright! 
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
While I wouldn't generally use "!!" in the argument of an 'if' statement (which will inherently test whether the operand is non-zero) I see nothing wrong with using "!!" in certain contexts. For example, some compilers support bit variables and/or allow single-bit fields within a struct. If I need to set such variables based upon certain bits in a variable, I think it's cleaner to say bitVar = !!(byteVar & 0x40); than to say bitVar = ((byteVar & 0x40) != 0);. Basically, I regard "!!" as an operator which turns an integer into a Boolean. Anything wrong with that?
|
|
|
|
|
supercat9 wrote: Anything wrong with that?
Everything! It is not an operator in the sense of being part of the language. It is a clever trick that you may understand, but is likely to confuse someone who later has the job of maintaining the code. In my experience the more simple and standard the code is the better. Whether you write bitVar = !!(byteVar & 0x40); or bitVar = ((byteVar & 0x40) != 0);, chances are the compiler will optimise it and generate the same object code.
|
|
|
|
|
Yay! 
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.
This message is made of fully recyclable Zeros and Ones
|
|
|
|
|
Richard MacCutchan wrote: In my experience the more simple and standard the code is the better. Whether you write bitVar = !!(byteVar & 0x40); or bitVar = ((byteVar & 0x40) != 0);, chances are the compiler will optimise it and generate the same object code.
I use the more verbose syntax when testing more than one bit, to make explicit whether I am checking for any bit being set, or all bits being set. Whether or not anyone else uses the same convention, I find that at least in my own code it's nice to be able to distinguish at a glance between single-bit tests and multi-bit tests.
|
|
|
|
|
Actually, I would use bitVar = ((byteVar & 0x40) == 0x40);.
Using the != 0 or in your case the !! style will work if you are comparing a single bit, but it will break if you are comparing multiple bits: bitVar = ((byteVar & 0x41) == 0x41); is not the same as bitVar = ((byteVar & 0x41) != 0);.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: Using the != 0 or in your case the !! style will work if you are comparing a single bit, but it will break if you are comparing multiple bits: bitVar = ((byteVar & 0x41) == 0x41); is not the same as bitVar = ((byteVar & 0x41) != 0);.
If I am testing multiple bits, I will either explicitly test for being unequal to zero, or being equal to a particular number (depending upon whether the requirement is that at least one bit be set, or that all bits be set). I do not like the syntax you seem to favor, since its normal semantic meaning requires that the same constant appear on both halves of the comparison operator; if the two halves get edited out of sync, the code will break.
|
|
|
|
|
I agree.
Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting.
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
Luc Pattyn wrote: Furthermore I'm all in favor of using named constants for these kinds of tests, so the code becomes self-documenting.
I like named constants too, but many of the same issues remain. If I have a test:
if ((somevariable & SOMEIDENTIFIER) == SOMEIDENTIFIER) I have to worry about whether the two "SOMEIDENTIFIER"s are the same. If the identifiers are the same and the value gets changed (but remains a power of two) things will be fine, but if the code is copied/pasted and then modified to use a different identifier, an imperfect patch job could cause all sorts of problems.
|
|
|
|
|
I agree once more.
If SOMEIDENTIFIER has more than one bit set, it all depends on the intent of the snippet; a switch might even be in order then.
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
I guess my main point is that I view testing for a single bit as being a different operation from testing a multi-bit expression numerically (a judgment colored perhaps by the existence of instructions on my favorite microcontrollers to perform such tests). Using an expressions like "!!(expr & BITMASK)" for the cases where BITMASK is a single bit makes clear that the code is supposed to look at a single bit, as opposed to numerically masking the expression and examining the result. The compiler will recognize the single-bit mask and generate code to exploit the bit-test instructions regardless of how the source code is written, but I like having a different way of expressing single-bit tests from multi-bit ones.
BTW, I sometimes use 'case' structures for the multi-bit case, though if all four cases of two bit flags are populated, I'll often use an if/else-if tree, depending on what sort of speed is required.
|
|
|
|
|
This could have resulted from a quick conversion of Assert() statements. The assert is a positive statement that explodes if not true. To covert them to execute a non-lethal action the quickest and perhaps safest approach is to just change to an if() throwing a NOT in front of the expreseion. New error handling code follows.
...not advocating this, just offering an explanation.
|
|
|
|
|
|
I asked a developer for code to create a specific XML document to save time.
Here is what he sent.
Needless to say, it didn't save me any time.
Dim XMLFile As StreamWriter = New StreamWriter(strAssetFile, False)
XMLFile.WriteLine("<Assets>")
XMLFile.WriteLine("<Encoding>")
XMLFile.WriteLine("<Profile Specifier=" + """" + "Standard1" + """" + ">")
XMLFile.WriteLine("</Profile>")
XMLFile.WriteLine("</Encoding>")
XMLFile.WriteLine("<Asset FilePath=" + """" + strUpDestinationFile + """" _
+ " AssetID=" + """" + Movieid.ToString + """" _
+ " CustomerID=" + """" + "1129" + """" _
+ " AssetName=" + """" + strFileName.Substring(0, strFileName.LastIndexOf(".")).Replace("_", " ") + """" _
+ " AssetDescription=" + """" + "Upolad" + """" _
+ " Category=" + """" + """" _
+ " FileNameToUse=" + """" + strFileName.Substring(0, strFileName.LastIndexOf(".")) + """" _
+ " Bytes=" + """" + (0).ToString + """" _
+ " Activate=" + """" + (1).ToString + """" _
+ " />")
XMLFile.WriteLine("</Assets>")
XMLFile.Close()
CreateAssetXML = strAssetFile
|
|
|
|
|
While I generally can't stand Visual Basic for much, it does certainly have some neat features for working with XML. You should send your developer a link to this article on MSDN[^].
Adam Maras | Software Developer
Microsoft Certified Professional Developer
|
|
|
|
|
Well, there are many horrors in that code.
The longest line can be shortened 50% by using String.Format()
Besides this, there is a high risk to produce a bad-formed XML if you have quotes, less-than or greater-than symbols inside your strings.
XmlTextWriter is the proper class to do xml serialization.
Best regards,
Jaime.
|
|
|
|
|
What feedback did you provide the developer...?
|
|
|
|
|
Try<br />
Dim d As Double = Math.Sqrt(number)<br />
Catch ex As Exception<br />
'do stuff<br />
End Try
|
|
|
|
|
Shenanigans! Nobody is that dumb.
Please... no.
|
|
|
|
|
It's almost like this one I saw a long time ago:
if (abs(num)!=num) ...
(this is a real one...)
|
|
|
|
|
jkruza wrote: (this is a real one...)
lol, i didnt make this up
|
|
|
|
|
Yeah, I believe you.
But it's so stupid, it's really hard to believe it's real.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
