Day 328

A trifle bizarre. After a bunch of investigation, I eventually narrowed down a synchronization problem to the following mini test program:

#include <time.h>
#include <stdio.h>
int main()
{
  time_t tv = time(NULL);
  struct tm *tms = localtime(&tv);
  printf("%02d:%02d:%02d DST:%d\n", 
         tms->tm_hour, tms->tm_min, 
         tms->tm_sec, tms->tm_isdst);
}

When I ran on Mac OS X:

~:date
Mon Mar 27 14:12:29 BST 2006
~:a.out
14:12:30 DST:1

But when I ran on my main Windows XP box:

c:\>time /t
14:13
c:\>localtime.exe
13:13:03 DST:0

Now, I'm usually happy to believe the worst of Microsoft, but it stretches even my credibility to think that their C runtime doesn't get the 1989 ANSI standard right (particularly as a quick web search didn't turn up any complaints).

Investigating further, when I ran the same code on a different Windows XP machine, I get the right answer:

c:\>time /t
14:15
c:\>localtime.exe
14:15:24 DST:0

So I checked MSDN and found some mutterings about "localtime corrects for the local time zone if the user first sets the global environment variable TZ...TZ is a Microsoft extension and not part of the ANSI standard definition of localtime. Note: The target environment should try to determine whether daylight saving time is in effect."

Running echo %TZ% from the command line showed up as GMT. So I tried changing the timezone to EST, but echo %TZ% was still reading GMT. Odd.

Eventually, I discovered that my login had TZ=GMT hard-coded into the environment (Control Panel, System, Advanced, Environment Variables). Not sure how it got that way, but finding it and making it not so has just taken a couple of hours.

[A:35029 B:3218 C:346 D:9187 Total:47780]

Day 74

[reading: Scott Meyers, "Effective C++ (3rd edn.)"]

I'm reading "Effective C++" again, with the publication of a new edition, and I'm struck by an observation. It's startling how much of the advice in early parts of the book boils down to: Understand how the compiler works. (Items 2, 4, 5, 7, 9, 10, 16 and 17 out of 18 so far)

This is an approach that I've got a lot of sympathy with; I really got to grips with Microsoft Word when I stopped observing the phenomonology of its peculiar behaviour, and instead sat down for half an hour to think about how it might be implemented internally. After that (even though I'm sure I didn't even get close to the true internals), I could cope with and predict the vagaries of the program much more effectively.

However, it does seem to me that one of the points of higher-level computer languages is so that programmers don't have to understand the details of the implementation. I guess if you just memorize the Effective C++ items and forget their explanations, then you can achieve that blissful state of ignorance—but it's safer and better to know the why and the how, which is why Scott's books sell so well.

But this does lead back to my underlying concern: that C++ is too complicated for mere mortal programmers. All of the individual features are there for a good reason, but taken as a whole the language is too big. A top-flight C++ programmer pretty much needs to know the whole of:

• Bjarne Stroustrup: C++ Programming Language (868 pages)
• Scott Meyers: Effective C++ (272 pages)
• Josuttis: The C++ Standard Library (744 pages)

That's 1884 pages in total. Even Common Lisp: The Language only weighs in at 971 pages.

I just about trust myself to write C++, but that's only because I know I'll avoid the parts of C++ that I don't understand fully. I've only ever met half a dozen people that I'd completely trust to write C++ (one of them being Scott), which makes for a hard time supporting C++ code.