What is difficult depends on your background. For most, the hardest part of learning C++ is to look up from the programming language constructs and focus on concepts in the application. That is, to learn to think abstractly and to design with a focus on classes rather than on sequences of operations.
I tackle this tricky problem by presenting each feature of the C++ language in the context of its use. For key C++ facilities - such as classes and class hierarchies - I accompany the discussion of what the language offers with a discussion of the design techniques the features exist to support.
Each chapter has a final section summarizing the recommendations found in that chapter as a list of one-line pieces of advice (with references back to the more extensive discussion in the text). My expectation is that novice C++ programmers will use these rules of thumb to guide their initial use of C++. Experienced C++ programmers will use the pieces of advice to determine what is new in C++ programming and as starting points for experimentation with new programming and design techniques.
The two are symbiotic. Learning to use C++ well is to learn to master the principles and practical aspects of design. On the other hand, you can no more learn object-oriented design without building programs than you can learn bicycling or dancing just by reading a manual. Practice and experimentation is essential and that can only be done using a suitable programming language - such as C++. Consequently, I present the features of C++ in the context of small examples of good design. The design section of the book sums up and makes explicit the principles and techniques that have been quietly used throughout the book.
In general, the book approaches topics by starting with the concrete and familiar and then gradually moving towards the more general. This, after all, is the way most of us think and learn. That way, we always have concrete examples to help us understand more general and abstract notions.
As much as is needed for the application in hand. Seriously, the standard library provides many useful facilities and also examples of many general techniques. I mine the standard library for useful techniques. However, it takes far less knowledge to use a library well than to understand it completely. I give overviews of facilities so that people can select what they want and quickly find more information about the library facilities they decided to use. The book's extensive index and cross referencing are very important to programmers that use the library before they have read all of the book and or even the library section - and most programmers will do that.
Programmers can use standard library facilities such as vectors, strings, lists, maps, stream I/O long before they master the advanced C++ features. People who does not come from a C background will appreciate that they can use these library facilities long before they understand the trickier parts of the C subset of C++.
The original STL was the basis for the container and algorithms part of the standard library and those parts are now commonly referred to as "the STL." Thus, when you sort a vector or merge two lists using the standard library you are using the STL. In addition to the STL, the standard library offers strings, I/O, numerics, and of course the C standard library.
I don't think it makes sense to deem a single language "the best" for broad application areas. People and problems differ too much for that. However, C++ is a great language for applications with stringent requirements and the standards effort has significantly strengthened it for many large and critical uses.
C++ has the close-to-the-machine features that allow the programmer to do even the most efficiency-demanding systems programming tasks. The facilities for data abstraction and object-oriented programming allows this basic efficiency to be applied in large and complex applications where facilities for organizing the code are essential.
I find that C++ has a real strength in projects and organizations that span several traditional application areas - such as a project involving networking, visualization, database access, and numerical analysis. More specialized language have problems spanning such diverse areas, and C++ allows programmers to build libraries to efficiently support the different parts of such an application. After all, my initial reason for creating C++ was to combine C's raw efficiency with facilities for program organization.
For ambitious projects, I consider C++'s flexibility and the basic efficiency of its facilities critical. Trying to restrict what a programmer can do in the name of some philosophy is asking for trouble. The world is too diverse and changing too rapidly for a general-purpose language to be paternalistic. We must encourage programmers and designers to use proven techniques, but we must not limit them to those proven techniques by trying to force them to use only ``good'' style by limiting the set of language facilities offered. The problem with ``fool proof'' languages is that ``fools'' are so clever. You can write bad code in any language, what matters is how easy it is to write good and elegant code. For C++, the aim is to allow people to write good and elegant code under the stringent requirements of everyday industrial software development.
A ``final draft standard'' is the last draft produced before submitting the standard to the national standards bodies for approval as an international (ISO) standard. Nothing significant is supposed to change between the final draft standard and the international standard. However, the international community scrutinizes the final draft standard for completeness and clarity presentation. No new features are supposed to be added at this stage and no current features are supposed to be removed.
The main benefit of a standard is stability. It gives the implementers a fixed target to work towards. This should give more solid implementations, more and better tools, and more and better libraries.
For programmers, the standard presents a base on which portable code can be written. The necessary system dependencies can be clearly delineated and isolated. From a teacher's point of view, the standard provides a stable environment in which to teach concepts and techniques. A widely used standard language and library is important here because it ensures that what is learned is widely applicable. It also ensures that what is learned will be useful for many years to come.
It is also important that an international standard makes it much harder and much less attractive for various companies to ``play games'' with the language.
Certainly, but the standard library is also a major pedagogical opportunity. Relying on the standard library allows me to present much better examples early on and to postpone the discussion of trickier language features until the reader can be assumed to have a bit more experience with C++. For example, the standard library vector and list are far easier to understand and use than the built-in array type and the pointer operations needed to do the equivalent vector and list manipulation without a standard library. Having the standard library available allows me to present arrays and pointers as implementation details of higher-level concepts.
Explaining the standard library in detail is a challenge. I present the key ideas and facilities early on so that people can use them and then go into significant detail later on. In all, the book must have about 300 pages related to the standard library. That library is not just useful, it is also a mine of examples of useful design and programming techniques. There are powerful and elegant techniques in that library that go beyond what C++ programmers have traditionally used.
What is the one aspect of the English language you like best and which do you like the least? These questions are hard, and their answers can easily be misleading.
It is no secret that I dislike the syntax derived from C, some aspects of arrays, and the promiscuous conversion rules for built-in types (see ``The Design and Evolution of C++'' for details). The beauty of a language feature is primarily in the ways it combines with other features in the support of useful and elegant programming techniques. Thus, it is hard to praise a single language feature in isolation. However, let me point to abstract classes and the way overload resolution interacts with templates as examples of features that allow some really nice code to be written.
There are no major feature in C++ that is surplus in the sense that you could remove it without forcing some programmers to rewrite their code in an uglier, less maintainable, and/or less efficient way. There are details of C++ that I dislike, but those are nits, and in general, I'm very happy with the language as it emerges from the standards process. Standard C++ is a closer approximation to my original ideal for C++ than any previous version. I hope that my new book will show people how that is and help them take advantage of this latest C++ to write better code.
Since Sun chose to make Java syntactically very similar to C++, comparisons between the languages becomes inevitable. However, Java and C++ are very dissimilar when you consider how you design systems and write good code (you can, of course write lousy code in any language). In particular, Java lacks most of the facilities that C++ provides for statically (compile-time) checked flexible code. This leads Java code to rely on run-time facilities in a way that would be inappropriate for a C++ program, and often inherently far less efficient.
I think that if you plan to do serious programming in C or C++, you should learn C++ and the techniques that go with it. It is always useful to learn many languages and no serious programmer should be monolingual. Knowing just one language is inherently limiting and learning a second, third, ... tenth, etc. language is far easier than learning the first. However, it would be a mistake to think that you can become a good C++ programmer just by learning Java and then applying your newly-developed skills in a C++ environment. Similarly, I doubt that learning C++ is sufficient to make you a good Java programmer.
Another issues is that the Java libraries are very different from the C++ libraries. Syntax is always the most visible part of code, and always the least significant aspect of that code.
Yes, I'm basically happy with Standard C++ and its library. There are details that I would have chosen to do differently had I had the opportunity, but there are no major feature that I would like to remove or a ``missing'' feature that I realistically think I could have added. Standard C++ enables a new level of elegance compared to previous versions of C++. That's the main reason I re-wrote "The C++ Programming language" more or less from scratch. The new facilities and techniques deserve nothing less. A minor revision could never do justice to the language we now have.