>>The UNIX-Hater’s Handbook has a chapter on X Windows.
>
>Am I supposed to be able to get past the opening lines of that chapter?
>
> X Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X Windows is to memory as Ronald Reagan was to money.
While Regan’s economic policies were undoubtedly superior to those we have today, they weren’t seen as being great until fairly recently. (2000-ish, IIRC) Also, they aren’t totally the best. (I’m not sure there is an objectively BEST economic policy at that level of government, except the truisms of: don’t spend money you don’t have and don’t think about what you’re spending it on before you do.)
The movie “Lorenzo’s Oil” shows a good example of the downside of Regan’s economic policy; though only tangentially and it’s only one small scene in a very interesting and touching story.
Also, I think that what the authors are trying to convey is that the idea of “throwing more money” (resources) at the problem isn’t going to make up for the bad design choices, which were probably politically motivated on some level. (Inter/intra-corporation politics can get WEIRD.)
>Also, the chapter on C++ is full of complete nonsense (and I’m not a terribly big fan of C++, I just happen to know it very well)
Really? I find it rather accurate. For example the #include scheme of code reuse (literally the same thing as cut-and-pasting the whole file indicated) is the worst possible implementation for the job. (I’ve used Turbo Pascal and Delphi for years, the [precompiled] unit inclusion and smartlinking are lightyears ahead of the C/C++ model. Yes, I know there are C++ precompiled header files, however they fall short of the flexibility of units.)
C++ syntax regarding pointers is horrible. In all honesty it’s the popularity of C/C++ and how horrid their Byzantine nature of handling of pointers are that make pointers ‘a bad thing’ in some CS circles.
Also, the syntax makes it absurdly easy to screw yourself. All the little features that people claim to be efficient because they make compact code are usually the ones that encourage sloppy programming practice.
Consider:
a_function()
{ char c, buff[80];
int i = 0;
while ((c = getchar()) != ‘\n’)
buff[i++] = c;
buff[i] = ‘\000’;
do_it(buff);
}
There is no check on length, resulting in ease of buffer overflow. The c = getchar assignment in the while condition leaves no room for checking for an EOF either. This is, objectively speaking, horrible programming practice, and yet it’s supposed to be ‘good’/’efficient’?
>Oh, I just realized that the book is copyright 1994, so ...
So what? Just because it’s old doesn’t mean it’s bad.
>>It’s a good read.
>No, its a complete waste of time.
Oh, come on! You took one look, got huffy over a political difference and then whined and cried over its age!? It’s humor, makes no pretense to be otherwise, and yet there’s a lot of experiential knowledge in that humor.
No, I did take the time to read most of several chapters, although the Reagan reference was flippant. The C++ stuff was so obviously out of date (eg pre-STL), that I went and checked the t copyright date. So, as a technicaly guide, its almost useless, although I suppose that as a historical reference, there is some value there.
Your code example is more a C issue than a C++ one.