|
You realize that the API Viewer looked at a huge, and incomplete, text file for it's data? All it does is provide a VB6 header for calling WIn32 functions. It provides no documentation on anything and doesn't even inspect actual .DLL's for anything.
|
|
|
|
|
I see what you mean - maybe then OLE Viewer could at least help the OP see the QueueStatus values(if it is an enum)?
modified on Friday, May 7, 2010 11:23 PM
|
|
|
|
|
The API Viewer will only list the values defined in the text file. It will not tell you what they are used for nor if you can combine them, and again, only for Win32 functions. It will do nothing for any library outside of Win32 nor anything added to Win32 after about 20 years ago.
|
|
|
|
|
Yes thanks - I was simultaneously modifying my post above - can the OP use the OLE Viewer ?
modified on Saturday, May 8, 2010 6:30 AM
|
|
|
|
|
No. It doesn't supply anywhere near the same information. It only handles Object Linking and Embedding stuff, not COM or Win32 stuff.
|
|
|
|
|
I'm translating some C# code into VB. In several places, the author uses static on private functions. My understanding is that static methods are useful only if you are building a toolbox: the keyword tells the compiler to organize the code differently and allow programmers to call the method from the class itself rather than from an instance of the class. Fine and understandable, but what is the use if the method is not publicly available? Is the code better optimized? Or is it a matter of programming style?
|
|
|
|
|
Perhaps those methods are called by a public static method? They would need to be static also.
|
|
|
|
|
Trust me, I've hit that pothole before.
It was just that I've never seen private static methods before; if there was an efficiency reason to use them I was going to adopt the technique. I might anyway: self-documenting code is always good.
|
|
|
|
|
For me, it's all about usage.
If a method needs this it's non-static. If it doesn't, the the compiler will make it static if it creates it via Refactor, or I will if I realize.
If it is static, it doesn't matter when I refer to it - I can use it from static or non-static methods. If it isn't (but could be), then I will swear a bit when I want to use it from a static method (public or private).
If you can, make private methods static - or at least I do.
You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace
C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy
|
|
|
|
|
I write a lot of private statics -- most access private static data.
I see no reason to make a method non-static just because it's private.
|
|
|
|
|
As others already said, I choose static to indicate the method needs no data or has no state, other than static data fields.
|
|
|
|
|
It looks like static is being used to document methods that did not interact with the class' internal variables; I was just curious if there was any advantage that went with it. Thanks for the responses.
|
|
|
|
|
Gregory.Gadow wrote: It looks like static is being used to document methods that did not interact with the class' internal variables
I assume by "class" you mean "instance" here. Static methods can access class-level (i.e. static) variables. Although you then need to think carefully about threading issues if these static variables are being changed by different instances.
|
|
|
|
|
Yes, the instance's variables 
The class has no static storage, and all of the static methods are along the lines of "perform a calculation on the parameter and return the result."
|
|
|
|
|
David Skelly wrote: think carefully about threading issues
Oh, yeah, there's that -- static methods are thread-safe, right? Maybe in some cases you don't need thread-safety, so making the method non-static will allow increased parallelism? 
|
|
|
|
|
PIEBALDconsult wrote: static methods are thread-safe, right?
yes, if the documentation for a particular class says so. Otherwise no.
The typical .NET class does that, as you well know.
|
|
|
|
|
I found this interesting piece on the msdn site -
"A call to a static method generates a call instruction in Microsoft intermediate language (MSIL), whereas a call to an instance method generates a callvirt instruction, which also checks for a null object references. However, most of the time the performance difference between the two is not significant."
This is contrary to the belief that static methods can improve performance in certain situations.
So I suppose it's just a matter of usage really.
|
|
|
|
|
Abhinav S wrote: This is contrary to the belief that static methods can improve performance in certain situations.
Why contrary? Sounds like it says static methods are faster. Granted the difference is not significant most of the time (i.e., it is significant some of the time).
|
|
|
|
|
when is that local variables are created and destroyed ,C#?
thanks.
|
|
|
|
|
You really need to buy this book[^] and read it. The point of the forums is not to teach people the basics of the language - the forums are here to help people with specific problems they may have.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
What difference does it make?
|
|
|
|
|
it may be important when a method needs huge amounts of local variables: it may work well when they get allocated and freed by the smallest code block that contains them, it may throw a StackOverflowException when all of them get allocated upfront.
|
|
|
|
|
Luc Pattyn wrote: when a method needs huge amounts of local variables
 Refactor?
|
|
|
|
|
Isn't that going to use more stack space? Return addresses, and so forth...
I have learnt that you can not make someone love you, all you can do is stalk them and hope they panic and give in.
Apathy Error: Don't bother striking any key.
|
|
|
|
|
Yeah, well, you could delegate some data to local variables in a different method, executed by some other thread. So basically implement an in-stack database, using Invoke to call on a single GetSet() method. But then that may be over-engineering the situation a bit.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
