Navigate/Search

Archive for the 'C#' Category

The hobgoblin of little minds

Wednesday, October 14th, 2009

A few thoughts about consistency, of course (Pace Emerson. let’s not limit ourselves to merely foolish consistency…).

Ahem. Programming geekery ahead…

(more…)

for (int i = 0; i < someUpperbound; i++){ /*do stuff*/ }

Thursday, July 3rd, 2008

I don’t often comment on the search strings that bring people here – they certainly aren’t as interesting as the lesbian vampire sex permutations that bring random (and disappointed) browsers to The Mystery of the Haunted Vampire. (See what you have to look forward to, Doug?)

This morning, however, I got a doozy, one that really and truly prompted a “Dude. Wait. What?” moment, complete with mental needle-on-record sound effects. If you aren’t a programmer or otherwise IT-minded, skip this one – I really won’t mind. If you are, however, please join me after the jump…

(more…)

Baby steps with .NET 2.0

Friday, April 29th, 2005

Okay, so after installing Visual C# 2005 Express Edition (Beta 2), I decided to do something a little more, uh… challenging than mucking around with the Managed DirectX game sample from Coding4Fun… I mean, don’t get me wrong – I’m no DirectX expert by any stretch of the imagination… What I mean is taking a production app written in Visual C# 2003 (.NET v1.1) and seeing what (if anything) breaks.

Guess what?

Nothing broke.

Okay, that’s a slight exaggeration – there were a couple of Windows Forms properties that are no longer supported, one event/event handler pair didn’t get ported over by the wizard (I’m guessing that the name of the event was too close to a keyword, but that’s really and truly a wild-ass guess. It ain’t even a sophisticated wild-ass guess), and the solution had some minor trouble reconciling references between projects, but it was a matter of 15 – 20 minutes of mucking around to eliminate the errors. There are still some warnings that I’d like to get rid of, but I can’t until there’s a real version of MSDN out there so that I can understand how I should replace a deprecated boolean property with a property that uses an enum (thanks, guys…). But really, that’s it. There are a couple of things that have clearly changed with the way that repainting window surfaces is handled (there are some boxes around our custom controls, and there appears to be some kind of default mouse-over behavior that makes the UI respond slightly differently, but there’s been no substantial changes in the behavior of the app.

Except for one. It’s fast. Like, really fast. Snappy, even. It takes longer to load the app in debug mode, and it’s a little twitchy unloading, but form-to-form transitions that used to border on Internet-browser-over-dialup-slow are now barely perceptible.

This is good.

If Beta 2 is any indication of what the release version of Visual Studio 2005 and v2.0 of the CLR is going to look like, they’ve done some really nice stuff by way of addressing the shortcomings of WinForm apps. Oh, and if anyone else out there notices a problem with the Members Window of the Object Browser (not the project/assembly TreeView, but the window that displays the actual members of the selected object), please leave me a comment…

iterating through collections

Wednesday, November 10th, 2004

I Googled this today – it explained nicely a problem I was having, and got me to start thinking about the differences between a loop that reads:

MyObject obj = null; for (int i = 0; i < someCounter; i++) {     obj = MyObjectCollection[i];     obj.Foo(); }

as opposed to this:

foreach(MyObject o in MyObjectCollection) {     o.Foo(); }

I’d always suspected that there were likely overhead/performance problems with the foreach/in statement, but damn is it convenient. I’d never suspected that the loop used a fundamentally different mechanism to achieve that ease of use. What I found interesting is that while the author of the referenced blog entry took home the lesson that ‘mutable value types’ == potentially harmful, the lesson I got was ‘foreach/in’ == potentially harmful. I agree that structs that act more like classes should probably be classes – on the other hand, if you can’t predict what is going to come out of a statement shouldn’t that be viewed as the problem?

(And I’m going to have to find an addition to my css in order to format code snippets better…)

[Update 11/12/2004: found it! Right here; prettified the code, though I’m not too sure about the absolutely stark-white background. It’ll stay that way for now]

This just in!

Thursday, October 21st, 2004

Avoid public static!

That’s all. Move along. Nothing to see.