> I find the notion of pre-compiled headers for anything other than > a very special situation rather odd.
it is odd. i've just been playing with trying to get some stuff working under macos x, and the interfaces are just amazing. the standard approach seems to be to enumerate every possible situation (often literally, with enums) in the interface. a few days ago i did a little test, just to appreciate the full extent of things. cpp of a null source file (with only the #includes i needed) gave over 100,000 lines of code. there were at least 20,000 enum constants defined, with names such as kAudioHardwarePropertyBootChimeVolumeRangeDecibels, and kAudioFormatProperty_AvailableEncodeChannelLayoutTags. and the interfaces that are presented are almost unusable even if you take that on board. i've been looking at the audio interfaces; functionality provided by the system includes facilities to read mp3 files, do sample-rate conversion, and produce sound output, so i thought, as a first test, i'd try to play an mp3 file. i haven't succeeded yet. after struggling for a good while, i found some example code that does this. it's over 1000 lines of code. when it should be about 10. i'd think perhaps it was deliberate, if it didn't all seem so carefully done, with loving attention given to every misbegotten line of header file. as charles put it recently, with relation to usb: ``enough is specified to make it complicated, but not enough to be complete, once for all.'' so true. given that kind of programming environment, the decision to use precompiled headers becomes slightly more understandable, i suppose. i guess the only good thing is that by using interfaces like that, they'll be wasting countless man-hours of programmer time, potentially allowing those using smaller, smarter interfaces a competitive advantage. yeah right.
