Number of people that care: zero. Number of francophiles that may care: estimated to be >=1.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
You kids and your fancy high UIDs.
I'm surprised nobody has caught the obvious here, that IE8 is gaining ground thanks to a two-pronged strategy. The first is Microsoft pushing IE8 out forcefully to everyone via windows/microsoft update. Even on the server side of things. They rank it as a critical download rather than optional, so if you just have important updates turned on, it will show up all by itself eventually. The second is that Windows 7 and Server 2008 are both gaining momentum as people buy new stuff and companies begin to upgrade their infrastructures. It's a new year which means a new budget and money to spend on replacing dead or dying computers and servers.
All this results in IE8 gaining marketshare. It will end up capturing as much, if not more, of IE7's share over time. There may always be some old holdouts from companies running some crazy in-house web-based app that only works on IE6, but I'm sure there are still NT4 boxen humming away in some dusty server closets somewhere too.
My only beef with IE8 is how the rendering engine destroys some pages. Buttons don't appear, images and text gets cut off, and I'll be damned if the page printing feature doesn't still chop the sides off of pages rather than reformat them to fit the page for printing. MS releases "compatibility" updates for it nearly every week or two, just to get it to render as cleanly (which is relative at this point) as IE7. At many companies I take care of, I have intentionally disabled IE8 from WSUS and unchecked it from Windows Update using the "fuck you don't come back" button due to rendering problems that end up crippling some work-related sites.
Link to Original Source
by Herbert Schildt
I had seen some of Schildt's material in the early 90s, and had
recently found a copy of his original "Turbo C: The Complete
Reference" book because I was working with Turbo C 1.0 and 1.5 for
historical research. But what was Schildt up to now? I found a chapter
on garbage collection in C++ which looked really interesting, and
bought "The Art of C++" very cheaply because it's no longer in print
even though it is from 2004. I've been looking through it, trying to
brush up on both C and C++. The bottom line is, there's some good
stuff in this book, but some bad stuff too. It's probably worth what a
used copy would sell for to get the garbage collection chapter. Many
of Schildt's books have a quote about his material being "first-rate",
but much in this book is second-rate, as I'll explain when I get into
the individual chapters.
The goal of the book is to demonstrate the "Art" of C++ (does the
title echo Knuth on purpose?) by showing the artistry with which the
language can be used to craft elegant solutions. The book's chapters
are hands-on projects the novice can build to get some experience with
the language. It's by no means a professional programming book, but
not aimed at the rank novice, either. Because the book is a grab-bag
of extremely varied projects, there's probably something in here for
almost anyone. You're assumed to have some facility with your C++
compiler, editor, etc; and to know the basics about the
language. There are two chapters (multithreading and the Internet file
downloader) which are specific to the Windows environment, but the
other chapters could be worked through by anyone with a C++ compiler
(such as g++ on Linux).
Let's look at the chapters!
Chapter one is just a preface masquerading as a chapter. The author
basically could have said "C++ is a powerful language" on the title
page and skipped this. His point is valid, but doesn't require a
chapter to make. C++ allows the programmer to get close to the
machine and write expressive code. I assume anyone buying a
project-oriented book on C++ already knows this. It's curious that,
writing in 2004, the author doesn't even mention why p-code systems
such as the C# CLI and Java's JVM have eclipsed C++. That would be
interesting to examine, since there's got to be some reason people are
going back to the inefficiency of p-code.
Chapter two is the garbage collection chapter, and is actually very
interesting. Schildt uses C++ fully, and does a decent job explaining
how garbage collectors work. I was pleased by this. The explanation is
very simple and straightforward. I've seen garbage collectors in LISP
implementations written in C before, but never fully reverse
engineered them. Unlike LISP versions, this garbage collector is a
reference counter. It's probably not adequate for real-world use, but
it's fascinating to look under the covers of a simple garbage
collector and learn how it works.
Chapter three is about Windows multithreading, which I didn't pay much
attention to since I don't program on Windows. He extends the garbage
collector to run as a separate thread.
Chapter four is interesting. Schildt builds a front-end for C++ so new
language features can be implemented, much like the "cfront" program
added new C++ language features to C. The front-end reads your program
and translates several new features into their C++ equivalents. What's
interesting is that he adds a foreach keyword, but then doesn't extend
it to iterate over STL containers, just built-in arrays, so that's
underwhelming. If it supported STL containers, it would have made this
a killer chapter. Because I don't use C#, I don't understand the
benefits of the "typeof" operator Schildt develops. I thought it was a
cool idea to do to C++ what C++ did to C. The only beef I have is this
front-end is little more than C code. It isn't developed as an
object-oriented program from the ground up, even though it does throw
an exception. Where is the parser factory, and delegation to helper
objects which do the code rewrites, and the design patterns?
Chapter five is about Internet file downloads, which is so 1998. To
develop this program, Schildt uses a Windows high-level API called
WinInet, which I have to guess is a wrapper around the usual socket
functions common to UNIX and Windows. It's certainly easy! Basically
you just have to call about five functions in the right order and it's
all magic. You learn nothing about TCP or UNIX socket calls in this
chapter, so I'm not sure what the point is. Since this is a book on
C++, you would expect to be using the Borland VCL, or maybe MFC, but
the demo program is a Petzold-era Windows program written in C. The
author even includes a manual resource definitions file! Get out your
Petzold book and try to remember how to manually compile a resource
file. I am not very impressed by this chapter, since you don't learn
Chapter six has a bunch of financial formulas from your college
economics book coded in C++. This chapter is totally awful! Every
single formula uses C++'s built-in floating point data type. Surely
you're joking, Mr. Schildt? I expected this chapter to discuss
rounding errors, BCD packages, fixed-point class libraries, and so
on. A guy billed as "a genuine C++ guru" on the cover (it really says
that; I couldn't invent anything that corny) ought to know more about
this. This chapter alone is a good reason to put all copies of this
book in the recycle bin. I hope no one from my bank reads it! The
chapter is so bad I don't even need to get into the fact that the code
isn't very object-oriented.
On to chapter seven, where things get better. This is a chapter on
(very basic) AI based problem solving. Back in 1987, Schildt wrote a
classic book on Borland's Turbo Prolog which included this chapter. He
actually did a commendable job bringing it up to date for this book,
re-writing the examples in C++. What this chapter covers is creating a
decision tree and walking it in different orders. Again, like most of
these chapters, it's really basic, but gives a newcomer to AI a way to
get started before, say, venturing into "Structured Interpretation Of
Chapter eight is how to build your own STL container. This is a gentle
chapter, which works through the standard interfaces containers need
to support to interoperate with the standard algorithms and
iterators. I liked this chapter because I find the STL a little
disorienting, and most books (like one I have, "Generic Programming
and the STL") to be almost too detailed for a novice. What he builds
is an array that's indexed from any number, not just zero. This gives
the container a nice, clean implementation (subtract the index from
the base and index a real array) that doesn't get in the way of the
The final chapter is a Mini-C++ interpreter. Many of us will remember
Little C, Schildt's August 1989 contribution to Dr. Dobb's
Journal. (If not, you can find the original source and article online
if you convince Google you want it badly enough.) This is the same
code! The interpreter is a hand-coded recursive descent parser that
knows a rudimentary form of C. It does not use LEXX and YACC, so it's
actually a fascinating example of how these parsers work. Or, it
was. The trouble is this code has been around for a long time, and is
not even a C++ interpreter. It does not understand classes at
all. What else is there that distinguishes C++ from C? The interpreter
does understand using "cout > var" but not deeply,
it's just syntactic sugar.
If you're too lazy to enter the programs, you can download the source
online from Osborne's site, but a word of warning that the zip file
has a single text file for each chapter with the listings one after
the other, so it's hard to pick each file's source code apart. There
aren't any markers in the file to show you where one file ends and the
other begins. Almost silly to do it this way, since (hopefully) the
code was in separate files during testing!
My feeling at the end of the book was one of being underwhelmed. I
wouldn't waste much time with this book. If you can get it for a
couple of dollars, you might like to see the garbage collection
chapter. Given that the book bills its author as "the world's
number-one programming author" and "a genuine C++ guru", there's not
much to back up these claims.
(If you want to read the garbage collector chapter, see the link to it
on Schildt's Wikipedia entry.)"