Sorry, my time and space are running out but these books deserve to be covered this time rather than simply being left for next.
Both books include a substantial reference section. Indeed the STL Primer is basically a reference from page 109 onwards. Using the STL only dedicates a hundred pages to the reference section. The difference is that the former book includes an example of the use of each entry while the later confines itself to an alphabetical listing of what you might find in a formal standard.
The first part of the STL Primer basically consists of an overview. At the end of this we have a very short item on multi- threading. I wish the author had expanded this. And he concludes this part with a single page on allocators. The last sentence of that page is:
'Further details of allocators are beyond the scope of this book.' To which I would add that it is also beyond the scope of almost every programmer in the World. They are an interesting idea but getting them to work in anything but the most trivial ways is at least a 45 on Donald Knuth's scale of problem difficulty (50 on that scale is an unsolved problem).By contrast, the other book has a much larger general section in which the author covers all the main elements of the STL with plenty of short programs showing how it can be used. I think that he sometimes takes too much notice of how it should work. His short chapter on allocators is a good example. He describes the intentions of the designers (different memory models etc.) but does not seem to realise that theory does not meet practice. I think that this is a clue to what is the basis of this book: the author is writing on a basis of hearsay. He believes what others tell him. That does not make this a bad book but it means that there is little added value and the reader must be very careful.
Both books share a failing in that they use the old, superseded headers and avoid the use of namespaces. I think both books also miss the point by focusing on short examples. The STL is a low-level component box for building classes. Such things as the STL containers should not being hanging out there naked in the application programmers code space. Data structures belong safely encapsulated in a class where the class designer can protect the innocent from all the problems associated with low-level value-based generic types.
If I needed to learn about using the STL I think I would choose one of the other books that I have reviewed (such as The STL for C++ Programmers by Leen Ammeraal). If I wanted a handy reference The STL Primer would be my choice. None-the-less Using the STL has merit and you might well want to have a look at it before parting with your cash.
