To null or to NULL?|
In C++, you can't unset a reference. However, you can use pointers, which are actual addresses of the memory location containing the data, and by convention, setting a pointer to 0 means it's unset. Universally, there is a label defined which is translated to 0 called NULL which makes code a lot easier to read.
Now, I'm perfectly used to NULL. I've worked with it every day for nearly 3 years now, and it's fine. However, I've just started work on a project at home in C#.
Initially, I was typing NULL in C#, which kind of made sense. After all, I haven't used Java for a long time. However, I soon got used to using null instead, probably because of the 5+ years of using it before I really got into C++.
Today at work I've been typing null all day!
As I type this out, I realise how incredibly dull it is. Too bad! I'm posting it anyway :P
I don't think you appreciate the magnitude of the dullness!
I was going to make a joke about your wife disagreeing, but really, this is so rudimentary to programmers that it'd bore Amanda too.
|Date:||March 2nd, 2010 05:10 am (UTC)|| |
heheh i just read this and giggled like a school girl! :D
Edited to add: I enjoyed it :) I dont actually do a lot of programming in a real sense so I still liked it, plus your posting-it-anyways-damnit sentence was endearing!
Edited at 2010-03-02 05:11 am (UTC)
I think that was the best part of the post :V
No, no: Java is fascinating!!!
Or so I will keep repeating to myself for the next ~3 weeks... :-P
Well, java is neat, but really nobody cares about my failure to switch languages quickly. Or IDEs, for that matter.
I found it interesting, but only cos i'm desperately trying to learn about programming and stuff, so even your language failure is interesting :p
I did, apparently, make an effort to make it informative...
I blame tired :V
I shifted over to null almost instantaneously, because the syntax highlighting in VS2008 C# picks up null, but not NULL (for obvious reasons).
I'm currently conflicted about C#. On the one hand I really like an awful lot of it. On the other hand all the stuff I really like about it is crippled on the 360. It's like Microsoft don't want me to use it...
I like it a lot, but I can see how a crippled version would be worse than using C++.
What's crippled? Speed, memory, or features?
Everything. The Compact Framework misses out a whole bunch of things from the API (including most of the Reflection features), but worse than that, the Xenon CPU is in-order. Which means that a JIT compiled, bytecode interpreted language is the worst possible fit for the 360.
The result is that anything you do in C# that results in code replacement or generation of any kind results in slowdown as the processor is forced to completely desync, purge and resync. And almost anything good in C# involves code replacement - delegates, generics, attributes, automatic iteration... hell, you can't even inline.
The one thing I'm happy about with it is that reducing the use of the GC is actually astonishingly simple, due to the way structs etc interact with the new keyword. Even then, when it finally does come to GC time, the Compact Framework version of the GC is NOT BLOODY GENERATIONAL. So it's a blanket purge system, making the whole mess 100x slower.
In short, it's the worst situation imaginable for anything even remotely software-engineering based. If I knew in November what I know now, I would not be using XNA for anything other than the very first initial prototype.
Good to know, thanks. I was aware that the Xenon CPU was in-order, although I didn't think about the implications for C#. I had noticed that using linked lists in any way generates a ton of cache misses, which is... disappointing. I guess that's true on a lot of systems (excluding, surprisingly, the Wii, whose cache I am only now realising is *lovely*.)
I gather the C# and Java GCs are normally pretty similar - even the Java GC will screw over your speed when it eventually kicks in.
Can you use GC.Collect() to try and shove all of your garbage collection into the end of quick frames? I.e. if you spot that your frame is over quickly and you're just waiting for the GPU (unless you're triple buffering, or using that time for some other time-consuming process) you start the GC, and hope that there aren't so many allocations since the last collection that it'll slow down the next frame. At least that way it'll do *most* of its collection while you aren't busy. There should totally be a GC.Abort ;)
There's also GC.WaitForPendingFinalizers() available, but I doubt you're ever going to want to lock your game thread to wait for the garbage collector - a slow frame interrupted by some garbage collection is better than a fast frame stalled until after the GC is finished, after all.