|
Tristan Rhodes wrote: not use variable names like textBox1
Well, in my class I teach, I take away points for using variable names like that. Trying to teach people to adopt some kind of decent coding standard.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Dave Kreskowiak wrote: I can't remember if they change to 64-bit integers on 64-bit machines or not.
Nope. Integers are always 32-bits in C#, which I found strange. The C# Language Specification is pretty explicit about it. "The int type represents signed 32-bit integers with values between –2147483648 and 2147483647." Period.
In C/C++, an int was intended to be the "natural" word size of the processor. In Intel x86 processors using DOS, an int was 16 bit. In Win32 and Linux, an int is 32 bits. There were even 24-bit systems where int was defined as 24 bits.
Enjoy,
Robert C. Cartaino
|
|
|
|
|
I remember the C++ types automatically sizing to the proc's width, but I couldn't remember if C#'s int and VB.NET's Integer remapped themselves to System.Int64. I didn't think it did, but I also don't have a 64-bit machine to test with either. 
|
|
|
|
|
Robert.C.Cartaino wrote: In C/C++, an int was intended to be the "natural" word size of the processor.
And I've seen so many cases where developers have written code making assumptions about the size of the data type only to find that their code breaks when they move to 64 bit servers. Standardising on types was part of the remit of the CLR team, so .NET code written for 32 bit would work on 64 bit as well.
|
|
|
|
|
I don't really like the aliases, in my opinion their primary use is to save keystrokes*, but I use them.
One of the odd things about them is that they're required for enumerations:
enum ThisEnum : int ...
enum ThatEnum : System.Int32 ...
And I seem to recall that there are situations where you can't use them, but I could be wrong about that.
* More importantly, they can ease the conversion of C/C++ code to C#, but how many people do that?
|
|
|
|
|
Trying to communicate with a java webservice that utilizes SwA instead of MTOM which is standard in Web Enhancments. Could anyone please tell me how I can do a SwA message in .NET?
|
|
|
|
|
Hi
(This is my first web service project so please point out if I've made any fundamental mistakes here.)
I have a problem using WCF .NET 3.5 VS2008 trying to create a c# client app that interacts with a 3rd party web service that uses SWA.
I have found that WCF .NET 3.5 does not support SWA. SWA was available as part of Web Services Enhancements (WSE) 3.0 for Microsoft® .NET VS2005 but WSE has not been updated for .NET 3.5 VS2008
The 3rd party web service wsdl is incompatible with wsdl.exe from .NET 3.0 so I cannot use VS2005 / .NET 3.0
I can create a service reference in VS2008 but it ignores the SWA (I think by design).
I think I have 2 choices - read up on wsdl so that I can modify the wsdl to be compatible with the VS2005 environment, or find a way to support SWA in VS2008.
Is this same as your problem?
Does anyone know of a solution for SWA with VS2008 .NET 3.5?
Thanks
A
|
|
|
|
|
Or will it freeze the application a little when doing garbage collection?
system
|
|
|
|
|
The GC will still freeze your application's main thread (and any child threads). Due to the way the GC works, this behavior will never change. It freezes the threads so it can "walk" the heap looking for reachable objects. If your application were still running, the GC would always be chasing it's tail and never be able to make any decisions.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
So can I disable auto garbage collection?
system
|
|
|
|
|
No. It's part of the .NET runtime itself and there is no way to turn it on or off.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Why would you want to? Seriously, why? This is the mechanism by which memory is reclaimed for your application. Do you really want your application to start leaking memory? To me, GC was one of the great features of .NET, and was an absolute godsend for me - coming from a C++ background, where you had to be so careful of how memory was allocated and freed, it's a relief to let the framework take care of this for me.
|
|
|
|
|
I agree with you. Gabage collection is really good.
When I used shared_ptr the first time, I can see how much it can clarify the code.
I know it can work well in .Net, but I just don't like the way it works (searching, freezing).
Does it have something better than garbage collection in real life?
Is the garbage in the bin useable in .Net? If not, why not clear it as soon as possible?
system
|
|
|
|
|
followait wrote: If not, why not clear it as soon as possible?
If you clear it straight away, you would introduce slow downs into your application because you'd be collecting pretty much every variable immediately. The garbage collection algorithm is pretty sophisticated, and is much less intrusive. I don't know if you've read up on it, but if you haven't you really should - it's enlightening.
|
|
|
|
|
Pete O'Hanlon wrote: I don't know if you've read up on it, but if you haven't you really should - it's enlightening.
Thanks. I'll learn it before I learn .Net .;P
Pete O'Hanlon wrote: If you clear it straight away, you would introduce slow downs into your application because you'd be collecting pretty much every variable immediately.
Usually, it has no problem, and memory pool can be used when necessary.
Pete O'Hanlon wrote: The garbage collection algorithm is pretty sophisticated
So it's hard to tell the good and the bad of it.
system
modified on Friday, September 19, 2008 8:37 PM
|
|
|
|
|
The garbage collector doesn't introduce noticable pauses unless you are really abusing it.
If you really have a pressing need to be constantly creating and destroying lots of tiny objects then use a resurrection pattern.
What scenario do you have where its not working well for you?
|
|
|
|
|
The problem is when GC is not necessarily, I also have to use it.
Just too rich.
More local variables mean higher cohensive 
Less function parameters mean looser coupling
|
|
|
|
|
If you don't like the garbage collector, then program in a none-managed language and manage all your memory requirements yourself. Then you'll come to know and love the GC.
|
|
|
|
|
I'm programming using C++ now, and sure that GC is very good when I need it.
More local variables mean higher cohensive
Less function parameters mean looser coupling
|
|
|
|
|
If the GC really isn't necessary for your usage scenario, then its won't spent any time collecting, and will run less frequently. If you think the GC is causing a problem in your program, then I suggest you first tell us what the ".Net Memory\% time spent in GC" performance counter reads.
The only performance bottlenecks I have seen in real world applications in my consulting role is due to poor programming (usually by people thinking they can do a better job than the experts).
|
|
|
|
|
If a specific part of the application has a real time demand, it'll be better if GC can be diabled
temporally.
I've just read it in MSDN, there are latency modes for it.
It survives.
More local variables mean higher cohensive
Less function parameters mean looser coupling
modified on Thursday, September 25, 2008 7:41 AM
|
|
|
|
|
If the application really has a realtime demand then you run it on a real time OS.
You shouldn't be considering doing anything in .Net if the slight interruptions of the GC are going to be an issue. There are plenty of other things that can interrupt execution on that platform.
|
|
|
|
|
No it's not. But Eiffel, for example, has per thread garbage collection. Problem is it has miniscule industry use. 
Kevin
|
|
|
|
|
Can I disable auto garbage collection in .Net?
system
|
|
|
|
|
Nope. If you did, you'd run out of memory VERY quickly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
