A colleague was writing a bit of image processing code in C# while working under the assumption that a bitwise shift operation by a negative count (i.e. lvalue >> -2) would result in the opposite shift (lvalue << 2 in our example). Nevermind the logic behind that assumption, while helping doing some research I've stumbled upon what might be a portability issue in the C# language design.

Apprently C# defines the left/right-shift operators as, for example:

It goes on to specify the behavioural differences between 32-bit and 64-bit code but gives no indication of what happens if you shift by a negative value (which is possible given that count is of type int); this is left undefined. This leaves certain behavioural aspects of applications up to the VM; what probably happens is (for Intel processors anyway) that the JIT compiler generates something which looks like:

If count is negative, this will result in a mask of the two's complement, so for -2 this would be 11110 - or a shift-left by 30. I'm not sure what prompted Tal to make the assumption regarding negative shifts, but the fact of the matter is that his code compiled without warning. If the default operators were declared with uint count, at the very least we'd get a "possible signed-unsigned mismatch" compiler warning. Most people would slap themselves and correct their erroneous code.

I couldn't find any reference of this with a Google search and would be more than interested in hearing corrections, explanations or just opinions...

Update (September 7th, 10:16): As per Eli Ofek's advice I started a discussion thread on the MSDN forums which already proved useful. A guy calling himself TAG suggested that the reason why the operators are defined with signed shift count is that unsigned types are not CLS- (common language specification-) compliant. This could very well be the case, however I am adamant that the language specification should reflect this; also, the fact that the CLS does not support unsigned types is nontrivial (and not easily found), which could potentially mean a lot of projects, open source and commercial, are in fact nonportable because they make use of unsigned types.

The game reviews I promised are still in the pipeline (it takes a lot of effort to get myself in the "reviewer state"), but I did post other stuff instead (mostly software- and development-related). Now it's time for tidbits:

• I've been sorely lacking a "navigation" submenu in Microsoft Word. I use a lot of internal hyperlinks in my documents (and have been reading and writing quite a few of those for the past few weeks), and it's a pain in the ass not to be able to navigate back and forth. Apparently it's just hidden in the Web toolbar and is readily accessible using Alt+Left and Alt+Right keyboard shortcuts. Oddly enough the keyboard customization dialog shows a GoBack function as well as the WebGoBack-WebGoForward duo; I'm not entirely clear on the difference yet. Anyways it's amazing how much better life is all of a sudden.
• There are numerous updates to the ReSharper 2.0 beta post.
• Thanks to Ofer for introducing me to the kickass bugmenot.com. It's basically a user-contributed database of registration information for any and all websites (there's even an entry for Nectarine!) which should prove amazingly useful, particularly when complemented by services like DodgeIt. They also have a petition asking content providers to stop with the pointless mandatory registration procedures. Not sure if I'll sign or not, but the site itself is damn useful.
• DevBoi seems to be a very useful development tool: it is a sidebar extension for Mozilla browsers offering easy access to online/offline documentation repositories for standards such as HTML, CSS and more.
• Apparently them christian preachers weren't kidding around: pr0n can indeed make you blind. Consider yourself, er, warned.

Light load this time. More to come.

I always enjoy researching languages (a passion that's only intensified since I cowrote our internal C#->java source-level compiler), so when a colleague approached me with an issue he had while creating a design in C# I was immediately intrigued.

Consider the following scenario:

Now, suppose I want to create another class, a3, which overrides ret but instead of implementing it on its own, it calls the a1 implementation - effectively skipping two generations of inheritence. If I wanted to call a2's implementation I could write a simple base.ret() call, so for a1 it's a simple case of base.base.ret(), right?

Quite wrong. Apparently the C# language specification defines the base keyword in a way that simply does not allow this. I was curious of this is the case with java as well, and lo and behold: java doesn't support super.super.member constructs either.

While researching the issue, I've come across two particularly interesting notes: Mads Torgersen, the new Microsoft program manager on C# Compiler and Language, has this to say in an interview:

Q: why only the first immediate base class is allowed in c#? e.g. cant do base.base.ToString()
A: The behaviour of your base class is determined by the writer of that class. It would open up a hole for breach of contract if you could bypass this and access something that this writer has decided to hide from you.

I'm not sure I'm convinced by this; it assumes the person who writes the instance class is not the same person who wrote the base class, which is not always the case. Other people around the 'net have said that this is a sort of "OOP no-no"; I can't say I've ever thought about this particular issue very deeply so I'll have to do some more thinking. If anyone has any references (no books, please - they're expensive and difficult to get) I would be very interested in hearing about it.

Brian Maso, posting to a similar discussion regarding java, suggests that this limitation derives from the java virtual machine design:

"super" is not an object reference. It's a Java language fiction. It basically indicates to the compiler that the target method call uses the "invokespecial" bytecode, not the usual method invocation bytecode "invokevirtual". This is as opposed to "this", which is an actual object reference variable.

If that is indeed the case, I can imagine the CLR shares similar design limitations, however this is research I'll leave for another time. For the time being suffice to say that the only way to do this is to use reflection, which is a sloppy solution which hinders performance, readability and safety. Imagine accessing runtime information, creating class instances (generating additional work for the GC in the process) etc. instead of a simple vtable indirection - it's not even funny!

I was implementing a watchdog system over a certain system's XML configuration repository using System.IO.FileSystemWatcher. Annoyingly, changes to the file (such as saving it with Notepad) would often result in the change event being fired twice. The system is designed so that whenever the file is changed, it is reloaded and several parts of the system are suspended (via thread synchronization) while the information is being re-cached. This in itself wouldn't be a problem since changes to the XML files are manual and rare, the XML schemas and serialization metadata are already cached etc. so the reloading operation shouldn't take more than 100-200ms (and the lock itself is only obtained at the very end of said process) - however there is a drain on CPU time and memory resources which I certainly wouldn't want doubled.

While it seems I wasn't the only one to encounter this behaviour, I've yet to see a proper solution to it; in the meanwhile I settled for a small hack where an update to the XML file are only processed if n seconds (2 in my case) have elapsed since the last update. Does anyone know of a cleaner way to solve this?

I came across a fairly unusual situation today, where a referenced assembly contained XML schemas as embedded resources. The schemas may (and do) contain <xs:include> and <xs:import> directives, which could not be resolved when I was trying to compile the schema: the schemas were including other schemas by relative URI (for example, SystemConfig.xsd has an <xs:include schemaLocation="Base.xsd" /> directive), and when the schemas are loaded from a resource there are no URIs to speak of.

After a bit of reading I settled down to write a custom implementation of XmlResolver. It's used like so:

Grab it here, and do let me know if you find this useful or have any comments/questions!

Update (18:58 GMT+2): Interesting. Apparently a developer called Jay Harlow wrote a similar class a while ago; his is VB.NET, mine is C#, but the similarity is staggering. So if you're looking for a VB.NET version of the class, there you are

I've been using NDoc a lot over the last couple of weeks and have found it invaluable. There is, however, one major hurdle I've encountered: it doesn't seem to support documenting of events. At all. Now I'm trying to generate documentation for one of our interfaces (which consists mostly of events) but can't :-(

I couldn't find anything relevant on the web (via Google or Google Groups). Ideas?

I've updated the lists of open source and proprietary software I use. I also consistently update the post about ReSharper 2.0 beta; finally, I've installed the new version of dasBlog.

The world is a better place, certainly.

Check this out: How to install Windows XP in 5 hours or less. I found this one particularly funny:

56. Time passes. It is getting dark. You are likely to be eaten by a grue.

I'll give a shekel (don't ask) to anyone who knows what that's all about (well no, not really, but it's funny anyway).

I was about to download log4net 1.2 beta 8, which I've been using for almost two years now, only to find that the project's been moved from SourceForge to Apache and an incubation release it out.

1.2.9 beta looks extremely impressive and I will report my comments on the subject as I become more experienced with it.

From the list of features the ones that impressed me the most are:

• The new logging contexts; NDCs was always thoroughly useful (never found any use for MDCs though) and an extensible, scoped NDC should indeed prove useful.
• PatternLayout customization; combined with the new logging contexts this seems to be an incredibly powerful tool (consider: conditional object state dumps with no little or no code overhead/clutter!)
• .NET formatting syntax. Trivial but necessary.
• Customizable levels for finer debug message granularity.
• Per-appender security contexts: 'nuff said.
• Pluggable file locking for FileAppender; I'm not readily sure where this would be useful, but I bet I'll find it before long...

I'm always impressed by open source goodness

Scott's released dasBlog 1.8! I don't have time to install it just yet - will probably save that for tomorrow. Since all the bugs I filed were fixed the new version is bound to be da bomb!

Update (August 15th, 11:32 GMT+2): dasBlog 1.8 is up and running. Oddly enough it seems to be compiled, or at least set up, to run in debug mode (web.config is set to <complication debug="true"... />), so I changed that. Everything seems to be in order.

The new BlogXP theme is very slick, but it's going to take quite a bit of time to rework it to fit the site design (get rid of the calendar, change the title, add a bit of personality...), so I'll stick with my modified DiscreetBlue in the meantime.