RSS for my articles

A friend suggested on Sunday that I create an RSS feed for my articles,
so that interested parties would know when I’ve created a new one – so
I’ve done it.
It’s hand-crafted, so there may be a few wrinkles to iron out, but
hopefully it will prove useful. It would be nice if there was a way of
specifying the last time that an item had been updated (rather than the
original publishing date). I can’t see anything like that in the spec but maybe I’ve missed something. The feed works in Thunderbird at least – let me know if you have problems with it.

New (to me) threading paradigms

In the last couple of days, I’ve been reading up on CSPs (Communicating Sequential Processes) and the Microsoft Research project CCR (Concurrency and Coordination Runtime). I suspect that the latter is really a new look at the former, but I don’t have enough experience with either of them to tell. Now, I know a number of my readers are smart folks who have probably lived and breathed these things for a while – so, is my hunch right, or are they fundamentally different models?

A few links for further reading:

System.Random (and java.util.Random)

This is as much a “before you forget about it” post as anything else.

Both Java and .NET have Random classes, which allow you to get random numbers within a certain range etc. Unless you specify otherwise, both are seeded with the current time. Neither class claims to be thread-safe. This presents a problem – typically you effectively just want one source of random numbers, but you want to be able to access it from multiple threads. You certainly don’t want to create a new instance of the Random class every time you want a random number – due to the granularity of the system clock, that commonly gives repeated sequences of random numbers (i.e. multiple instances are created with the same seed, so each instance gives the same sequence).

I suggest that very few people really need to specify seeds – which means they don’t really need instance methods in the first place. A class with static methods (matching the interface of Random) would be perfectly adequate. This could be implemented using a single Random instance and locking to get thread safety, but a slightly more elegant (or at least more interesting) way would be to use thread-local static variables. In other words, each thread gets its own instance of Random. Now, that introduces the problem of which seed to use for each of these instances. That’s pretty easily solved though – either you take some combination of the thread ID and the current time, or you create a new instance of Random the first time any thread accesses the class, and use that Random as the source of seeds for future Randoms. The only time locking is needed is to access that Random, which occurs once per thread.

This does, of course, break my “keep it as simple as possible” rule – the simplest solution would certainly be to lock each time. In this case though, as this will end up as a library class which may well be used by many threads simultaneously in situations where a lot of random numbers are being generated, I think it’s worth the extra effort. I’ll probably write this up as an article when I’ve written the tests and implementation…

Adverts on my C# article pages?

I had an email today which suggested I should start advertising on my C# article pages. I’ve considered this in the past without coming to any conclusions. I would certainly plump for Google AdSense on the grounds that it’s fairly non-invasive. I just can’t decide whether or not it’s a good idea.

Pros:

  • I get money for things which do actually take a fair amount of time to write.

Cons:

  • I’d need to work out what the tax implications are (particularly in terms of being in the UK when Google is in the US). I don’t currently fill in a tax return, although I’ll have to next year anyway…
  • People might get annoyed with the ads and not want to read the articles.
  • People might feel that when I link to an article either here or in newsgroups, that I’m just doing so to get more money.

That last point really worries me – but maybe I’m being paranoid. So, what do you think – should I give it a try, or would it “spoil” the articles?

Code formatter online

I’ve finally got round to doing it… the code I use for posting code for articles etc has now been transformed into a small ASP.NET app. It’s based on a VB.NET article. I converted it from VB.NET to C# using Instant C# (which worked very well – just a few gotchas, far fewer than last time I tried it) and then refactored it into a more object-oriented and cleanly layered structure. There’s now a WinForms application, and a separate class library, which the ASP.NET app uses.

If you want to use the results yourself, you’ll need the stylesheet I use. Unfortunately, between this blog, my home page, and the home for the application, I’m starting to get far too many copies floating around – I may need to rationalise at some stage, as making a change is becoming painful. Anyway, just reference the stylesheet in your page header, cut and paste whatever the app provides for you (between the textbox and the sample output) and you’re away.

The site is hosted by AspSpider.NET – free ASP.NET hosting. I only signed up with them yesterday, and everything seems to work pretty seamlessly, so it seems reasonable to acknowledge them in this post :)

The code can still be made a lot prettier, but it’s getting there. I was pleased with the ASP.NET side of things – obviously (being me) I did it all in a plain text editor, and the resulting .aspx page is 29 lines, with the code-behind weighing in at 60 lines. Nice.

Future plans for it:

  • A drop down list of languages (easy) (done, 17th Nov 2005)
  • A radio-button for the format type (css, html – easy)
  • Adding Java to the list of languages (hopefully fairly easy) (done, 17th Nov 2005)
  • Giving the code back to the Darren Neimke

CLI spec mistake with unboxing and enums

When looking over someone’s test code the other day, I happened to notice he was unboxing a boxed enum to an int. I was mildly surprised that he was able to do so – I thought you could only ever unbox to the exact value type that was “in the box”. Naturally, I consulted the spec. The C# spec is relatively woolly on the subject, unfortunately, but the CLI spec (partition three, end of chapter 4 for those who wish to look it up) is very clear. Here’s what it states under the Exceptions section, which is the interesting part – obj is the value to unbox, valuetype is the type we’re tring to unbox to:

InvalidCastException is thrown if obj is not a boxed valuetype (or if obj is a boxed enum and valuetype is not its underlying type)

That’s from the first edition of the spec. The third edition (still under consideration for approval by ISO/IEC) has this:

System.InvalidCastException is thrown if obj is not a boxed valuetype, or if obj is a boxed enum and valuetype is not its underlying type.

Seems harmless enough, right? Well, consider a situation where you have two enums, FirstEnum and SecondEnum. Then consider this (the code is in C#, but the generated IL is a direct translation – in particular, the types used for unboxing are preserved):

// Keep declarations out of the way to focus on the conversions.
object o;
int i;
FirstEnum x;
SecondEnum y;

o = 1; // The value of o is a boxed System.Int32
i = (int) o; // Conversion 1
x = (FirstEnum) o; // Conversion 2
y = (SecondEnum) o; // Conversion 3

o = (FirstEnum)1; // The value of o is a boxed FirstEnum
i = (int) o; // Conversion 4
x = (FirstEnum) o; // Conversion 5
y = (SecondEnum) o; // Conversion 6

Now, which of those versions should succeed? Reading absolutely literally, only conversion 1 should work. The others should all throw InvalidCastException. In all but conversions 1 and 4, the first part of the “or” clause in the spec is true (i.e. we’re trying to unbox to a different type) and in conversion 5, the second part of the “or” clause is true (the value is a boxed enum, and the type we’re trying to unbox it to isn’t the underlying type – it’s the real type!).

I know that’s reading the spec very literally, rather than taking the obviously intended meaning – but specifications should be precise documents. In fact, I’m not sure the intended meaning is so obvious anyway. Clearly conversions 1 and 5 should work (an “exact match” should always be valid) but what about 4? Should I be able to unbox an enum to an int? The way the spec is worded suggests that probably I should. What about the other way round (conversions 2 and 3), unboxing an int to an arbitrary enum which has int as its underlying type? Not so sure about that. As for conversion 6, unboxing one enum to a completely different one (which happens to share the same underlying type) – I think I’d actually rather that failed.

So, what happens? Under the current .NET implementations, all the conversions succeed. That pretty much means that’s the way the behaviour is going to have to stay, meaning I won’t be able to get my wish about conversion 6. Still, never mind – what’s important is that the spec matches reality. I believe it’s very hard to word this in the “single sentence” style they’ve tried for. I think I’d say:

System.InvalidCastException is thrown if none of the following valid conversions are applicable:

  • obj is a boxed valuetype (covers 1 and 5)
  • valuetype is an enum, and obj is a boxed value of the underlying type of valuetype (covers 2 and 3)
  • obj is a boxed enum with underlying type valuetype (covers 4)
  • valuetype is an enum, and obj is a boxed value of an enum with the same underlying type as valuetype (covers 5
    and 6)