My friends at Microsoft told me the next years’s TechEd, Microsoft’s primary technical conference, will take place in New Orleans, from June 7th to 11th.

 

This year’s Tech will take place in Los Angeles on the week of May 11th. I will not be able to attend this year but I expect to visit New Orleans next year.

I was recently involved in a discussion about the lack of “ranged ints” in the C# language. A ranged int is an integer type that would only accept a smaller subrange of all possible integers, say just 1 to 100. This is a discussion dear to me be because I sort of designed “ranged ints” for C++.

 

It all started because I used to develop with Turbo Pascal which *had* “ranged” integer types. You could turn on a compiler option that would automatically validate the range at runtime. I used it as a debugging aid, like an “automatic assert” every time the variable was assigned to. For instance, I would have a “row” variable that must hold values between 1 and 24, so I would declare it to be of a “row type”, a ranged integer of 1 to 24. During development and testing I would get an error if it got assigned something outside of that range. The final “non-checked” version would have this option turned off and have no performance penalties.

 

Then I had to switch to C++ and I missed my “ranged ints”. Since C++ templates allowed not only types but constants as arguments as well, I developed my own “ranged int” classes based on templates. At debug time they would check the range. I then flipped a compiler “define” and they would behave pretty much like a normal int, semantically and performance wise. This was not a popular C++ technique, but I used it left and right, despite that it made for slower compilations and at one point the Borland C++ compiler would choke with so much template usage.

 

I dusted off my C++ skills and wrote such an example as a console Win32 app below – this one is pretty simple (no copy constructor, no necessary operator overloading) and it will actually coerce the value to be within the range instead of issuing a warning, but you can get the idea. Of course, you could do the same with other numeric types such as float.

 

I couldn’t replicate the technique with C#. Maybe if it would accept constants as generics arguments, I could have my “ranged ints” back…

 

Here is the sample:

 

 

#include "stdafx.h"
#define DEBUG
template <int V1, int V2> class RangeInt {
private:
      int Value;
      #ifdef DEBUG
      // Checks range and force into the range if outside
      // An alternative would be to throw an exception or flag the error somehow
      void CheckRange() {
            if (Value < V1) {
                  Value = V1;
            }
            if (Value > V2) {
                  Value = V2;
            }
      }
      #endif
public:
      RangeInt() {
            Value = V1;
      }
      RangeInt(int N) {
            Value = N;
      #ifdef DEBUG
            CheckRange();
      #endif
      }
      operator int() {
            return Value;
      }
};

int _tmain(int argc, _TCHAR* argv[])
{
      RangeInt<1, 100> MyVal;
      MyVal = 0;
      printf("%d\n", MyVal);
      MyVal = 1000;
      printf("%d\n", MyVal);
      return 0;
}

 

64-bit computing has been around for some years now and it didn’t get a lot of traction, despite the efforts from hardware and software suppliers. I know the reason: few people really need to run 64-bit software on their desktops; even on the server side the picture is not so rosy.

 

From a software developer point of view, if you are not managing more than 2 GB of memory in your program, it doesn't make sense to go to 64 bits. Some people would go further and say that a 64-bit address space is only worth if you have a *single variable* that holds more than 2 GB of data by itself. This is a far cry from the jump from 16 to 32 bits. In the Intel 16-bit world it was a huge pain if you wanted to have variables holding more than 64 kb each - which any stupid program did have back then; 32-bits cured that.

 

If you have less than 2 GB of data in your program, the same 64-bit code is way larger and thus slower (takes more time to load from memory) and the memory operations themselves are slower. I would dare to say that there are very, very few desktop programs around that would benefit from going to a 64-bit address space.

 

I’ve heard people say that if you have to manage a large, multi-gigabyte file, such as a video file, a DVD image or even a PST/OST Outlook file, you could use a large variable. Yes, you could but I am not sure that there would be a benefit loading the whole thing into memory at once, even if it were virtual memory.

 

On the server side, where a single application is actually serving hundreds or thousands of users, there are more reasons to go to 64 bits, especially in the case of infrastructure products that will be around for several years like a database server.