this sort of programming has a lot in common with the stage of learning a language where you understand the grammar but don't know the vocabulary. read two lines. lookup unknown words. lather. rince. repeat.
- erik On Mon Mar 27 11:30:49 CST 2006, [EMAIL PROTECTED] wrote: > > 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. >
