I just got my 40" HD widescreen LCD TV Friday morning and today I went out and bought Call of Duty 4 needing a new game to play now that I've beaten Rainbow Six: Vegas.
Wow. Just wow. This game is amazing.
Here's the trailer:
And here's some sample gameplay footage:
Update: Already beat the game... guess I'll go back now and try to get all the achievement points I missed.
Every once in a while, it becomes necessary to parse an integer from a string. The trick is doing so correctly and without the need to use an integer type larger than what you are parsing into (i.e. if you are trying to parse a 32bit integer, you don't want to have to use a temporary 64bit int value for checking overflow - this is especially desirable if you are trying to parse larger int values, such as a 64bit int because you won't likely have access to a 128bit int type).
The following macro correctly implements an integer parsing routine for a given number of bits:
#define STRTOINT(bits, max) \
static int \
strtoint##bits (const char *in, char **inend, \
int##bits##_t *retval, int *err) \
{ \
register const char *inptr = in; \
int##bits##_t val = 0; \
int digit, sign = 1; \
\
while (*inptr == ' ') \
inptr++; \
\
if (*inptr == '-') { \
sign = -1; \
inptr++; \
} \
\
in = inptr; \
while (*inptr >= '0' && *inptr <= '9') \
digit = (*inptr - '0'); \
if (val > (max / 10)) { \
*err = EOVERFLOW; \
return -1; \
} else if (val == (max / 10)) { \
if (digit > (max % 10) && \
(sign > 0 || digit > ((max % 10) + 1))) { \
*err = EOVERFLOW; \
return -1; \
} \
\
if (sign < 0) \
val = (val * sign * 10) - digit; \
else \
val = (val * 10) + digit; \
\
inptr++; \
if (*inptr >= '0' && *inptr <= '9') { \
*err = EOVERFLOW; \
return -1; \
} \
\
goto ret; \
} else { \
val = (val * 10) + digit; \
} \
\
inptr++; \
} \
\
if (inptr == in) { \
*err = EINVAL; \
return -1; \
} \
\
val *= sign; \
\
ret: \
*inend = (char *) inptr; \
*retval = val; \
\
return 0; \
}
To expand this macro to parse a 32bit integer value from a string, you would do:
STRTOINT(32, 2147483647L)
The resulting function would be named strtoint32().
Why implement my own integer parsing routine instead of using libc's strtol(), you ask?
For a variety of reasons:
To generate functions to parse 8, 16, 32, and 64bit integers, you would write:
STRTOINT(8, 127) STRTOINT(16, 32767) STRTOINT(32, 2147483647L) STRTOINT(64, 9223372036854775807LL)
What about unsigned integers, you ask? Not to worry, I have an implementation for that as well:
#define STRTOUINT(bits, max) \
static int \
strtouint##bits (const char *in, char **inend, \
uint##bits##_t *retval, int *err) \
{ \
register const char *inptr = in; \
uint##bits##_t val = 0; \
int digit; \
\
while (*inptr == ' ') \
inptr++; \
\
in = inptr; \
while (*inptr >= '0' && *inptr <= '9') { \
digit = (*inptr - '0'); \
if (val > (max / 10)) { \
*err = EOVERFLOW; \
return -1; \
} else if (val == (max / 10) && digit > (max % 10)) { \
*err = EOVERFLOW; \
return -1; \
} else { \
val = (val * 10) + digit; \
} \
\
inptr++; \
} \
\
if (inptr == in) { \
*err = EINVAL; \
return -1; \
} \
\
*inend = (char *) inptr; \
*retval = val; \
\
return 0; \
}
STRTOUINT(8, 255)
STRTOUINT(16, 65535)
STRTOUINT(32, 4294967295UL)
STRTOUINT(64, 18446744073709551615ULL)
And there you have it.
Note: these routines require [u]int[8,16,32,64]_t to be defined. If you are on Linux, #include <stdint.h> should do the trick.
Update: Miguel's blog goes into more detail on why this code was important for Mono.
Matt Asay, in a recent blog on CNET, tries to imply that Mono/Moonlight are a waste of Miguel's time/talents.
For these reasons I can't help but wonder why he's squandering his talents on writing largely irrelevant code (Mono, Moonlight) that appeals to himself, Novell, Microsoft, and no one else.
Really? No one else? Are you saying that the thousands of users and developers involved in the Mono community are nobodies? Are you saying that OTEE, the developers of Unity3D, are nobodies? Are you inferring that Codice Software and the growing list of companies/projects basing their software on Mono are nobodies?
Miguel says that he's doing this to bring the proprietary world into the open-source camp. It's not working, Miguel. You don't convince by capitulating. You convince by winning
Based on the growing number of users and developers getting involved with the Mono project (and recognizing that there are probably far more out there that just haven't made their presence known), I would say it is working. Because of the Mono project, more people are taking an interest in Open/Free Software, which I and many others would call "winning".
Rather, Miguel de Icaza can turn the industry on its head by putting his knowledge of interoperability and open source to work on developing the next-generation desktop (and not by recreating the "best" of Microsoft on Linux).
It's unfortunate that you are so short-sighted, Matt. That seems to be one of the more important differences between you and Miguel. Miguel sees the big picture. He knows that in order to create the "next-generation desktop", he'll need better tools in which to do it. He also sees that "winning" takes "developers, developers, developers!" He knows that you can't "win" if it takes developers on Linux 2 or 3 times as long to write an application as it takes to write on Windows with proprietary tools.
I think Miguel de Icaza is an exceptional developer. He's also a fantastically effective community leader.
All the more reason to let him continue doing what he does best.
Update: Joe Shaw makes an excellent point.
Update: It appears that Matt Asay has retracted his post and made an apology.