|
I don't know VB and was just wondering ... if
Return OrderNumber = 0
does a comparison and returns the result then how would you set the value of OrderNumber to 0 and then return OrderNumber?
In C#, the first is
return OrderNumber == 0;
and the second is
return OrderNumber = 0;
|
|
|
|
|
PaulLinton wrote: I don't know VB
Obviously 
VB doesn't know the == operator. Instead = can be either assignment or comparison, dependent on context.
In this case it's a comparison, but no assignment.
So
Return OrderNumber = 0 Would be
return OrderNumber == 0; in C#.
Your second C# example isn't possible in VB (as far as I know, but I didn't know it was possible in C# either )
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
The second one would be:
Return (Ordernumber = 0)
<edit>Or like this:
Return 0 = Ordernumber </edit>
modified 6-Jul-14 2:15am.
|
|
|
|
|
Been a while since I've made the computer hiccup, but last week had an interesting experience. A bug evidently caused everything to start paging to disk on Win7-64.
The short of it was in a window resizing routine the DC wasn't released correctly, so memory was being eaten quickly. Didn't realize it and continually resized for multi-seconds for fun. The computer started getting sluggish as heck. Opened up Resource Monitor and noted the memory increase upon resizing. But it was too late.
At bootup about 2 gigs is taken by all the background stuff I use. With the other progs, and the leak, my 4 Gigs main memory was exceeded. All well and good, but then the unexpected occurred: I watched the resource monitor show my memory opening up to the state where it only reported 560 MB or so being used! But none of the programs I had open closed at that point. They were VERY slow to respond, though!
A reboot fixed everything, and the bug was squashed in the next round. That's my tale. It fits the weird, but not the wonderful. For that you can have this piece of classic code I came upon in the project, which I just massively revised:
Rect() {
Rect(0, 0, 0, 0);
}
That initializer wasn't doing what the original author thought it was doing...
Or if you want another, this was the original author's assert macro:
#ifdef DEBUG
# define ASSERT (object) ((void)((object) || (AssertDebug(#object,__FILE__,__LINE__),1)))
#else
...
Used throughout the code like:
ASSERT(m_hWnd);
If it is expanded, Visual Studio throws a bunch of "103 IntelliSense: '#' not expected here" errors. I don't think they ever #defined DEBUG in their code, so the asserts were never even used. I guess they just liked typing... (Or maybe VS6 expanded macros differently?)
|
|
|
|
|
Thats how one of our developers with 18 years experience checks if guid is empty
public List<Comment> GetCommentIdsByUserQueryID_Paging(Guid userQueryID, out int total, int skipCount = 0, int itemsPerPage = 20)
{
.........
if (userQueryID.ToString().Length==0) return null;
..........
|
|
|
|
|
Ew. Yet, why check at all? And wouldn't an empty List be better than a null?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
because no further actions cannot be done if something went wrong and queryid is empty guid. Empty list its bites in memory
|
|
|
|
|
Stepan Kobzey wrote: if something went wrong
I don't think that's the responsibilty of this method. That should have been performed before calling the method.
Stepan Kobzey wrote: is empty guid
If the method is asked to perform the action, it should perform it.
Stepan Kobzey wrote: bites in memory
So what?
Basically, what goes wrong if you remove the check entirely?
It sounds like a case of premature optimization -- if the guid is never empty, then you are actually decreasing performance because you perform the check every time.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Should have been:
if (userQueryID.ToString() == "00000000-0000-0000-0000-000000000000") return null; He should've known that 
Alternatively he could've looped and count the 0's.
Just don't use Guid.Empty. I heard it's bugged 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
What if it has lower-case zeroes?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
You mean they aren't the letter O?
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Sander Rossel wrote: I heard it's bugged
You heard right - it's not even slightly unique.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Isn't a non-unique GUID pretty unique
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Pretty much the same argument as that for "there are no uninteresting numbers". 
"If there are uninteresting numbers, there must be a first uninteresting number, and that number would therefore be pretty interesting."
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Why doesn't he just generate the same guid again and compare?
|
|
|
|
|
Exactly. Ought to be
Guid invalid = Guid.Empty();
if (userQueryID.ToString().ToUpper() != invalid.ToString().ToUpper());return null; Oops;! Happened to add another feature...
|
|
|
|
|
Is the errant semi-colon on purpose? 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Don't fix that! Other places using that function meanwhile rely on its "feature" that it returns a *special* list for Guid.Empty()!
|
|
|
|
|
Bernhard Hiller wrote: it returns a *special* list for Guid.Empty()!
It's expected to, but does it?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
IIRC guid's are value not reference types so they can't be empty. Doesn't it have hasValue() method or some such?
|
|
|
|
|
They can't be null, but they can be empty, which is the guid equivalent of zero.
http://msdn.microsoft.com/en-us/library/system.guid.empty.aspx[^]
There's no HasValue property or method; you just need to test whether it's equal to Guid.Empty.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: you just need to test whether it's equal to Guid.Empty
Except for that you probably don't actually need to.
Edit:
I'm also suspicious as to whether or not they're actually using System.Guid. The snippet doesn't specify, so it's possible that they rolled their own Guid class and then all bets are off.
You'll never get very far if all you do is follow instructions.
modified 27-Jun-14 10:41am.
|
|
|
|
|
Well, you do if you want to know whether or not it's empty. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Except you probably don't actually need to.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Google for 'Index Of' instead of 'IndexOf'.
Those are some strange images in the results. (click) NSFW!!!
What the ____?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
