Reference

Abstract: Coming to grips with C++11 and C++14 is more than a matter of familiarizing yourself with the features they introduce (e.g., auto type declarations, move semantics, lambda expressions, and concurrency support). The challenge is learning to use those features effectively - so that your software is correct, efficient, maintainable, and portable. That's where this practical book comes in. It describes how to write truly great software using C++11 and C++14 - i.e. using modern C++. Topics include: The pros and cons of braced initialization, noexcept specifications, perfect forwarding, and smart pointer make functions The relationships among std::move, std::forward, rvalue references, and universal references Techniques for writing clear, correct, effective lambda expressions How std::atomic differs from volatile, how each should be used, and how they relate to C++'s concurrency API How best practices in "old" C++ programming (i.e., C++98) require revision for software development in modern C++ Effective Modern C++ follows the proven guideline-based, example-driven format of Scott Meyers' earlier books, but covers entirely new material.

Abstract: From the Book: C and C++ are the world's most important programming language: Indeed, to be a professional programmer today implies proficiency in these two languages. They are the foundation upon which modern programming is built. C was invented by Dennis Ritchie in the 1970s. C is a middle-level language. It combines the control structures of a high-level language with the ability to manipulate bits, bytes, and pointers (addresses). Thus, C gives the programmer nearly complete contra over the machine. C was first standardized late in 1989 when the American National Standards Institute (ANSI) standard for C was adopted. This version of C is commonly referred to as C89. This standard was also adopted by ISO (International Standards Organization). C89 was amended slightly in 1995. C++ was created by Bjarne Stroustrup, beginning in 1979. The development and refinement of C++ was a major effort, spanning the 1980s and most of the 1990s. Finally, in 1998 an ANSI/ISO standard for C++ was adopted. In general terms, C++ is the object-oriented version of C. C++ is built upon the foundation of C89, including its 1995 amendments. In fact, the version of C defined by C89 is commonly referred to as the "C subset of C++," Although C++ began as a set of object-oriented extensions to C, it soon expanded into being a programming language in its own right. Today, C++ is nearly twice the size of the C language. Needless to say, C++ is one of the most powerful computer languages ever devised. In 1999, a new ANSI/ISO standard for C was adopted. This version is called C99. It includes a number of refinements and several new features. Some of these "new" features were borrowed from C++, but some are entirely new innovations. Thus, several of the elements added by C99 are incompatible with C++. This means that with the advent of C99, Standard C is no longer a pure subset of C++, Fortunately, many of the incompatibilities relate to special-use features that are readily avoided. Thus, it is still easy to write code that is compatible with both C and C++. At the time of this writing, no major compiler currently accepts all of the C99 additions, but this is sure to change. The following table synopsizes the relationships between C89, C99, and C++. C89 The original ANSI/ISO standard for C. C89 is what most programmers today think of as C. C++ The object-oriented version of C. The current ANSI/ISO standard for C++ is built upon C89. Thus, C89 forms a subset of C++. C99 The latest standard for C. Includes all of C89, but adds several new features. Some of the new features are not supported by the current standard for C++. The material in this book describes C89, C99, and C++, When a feature is unique to one of these, it will be so flagged. Otherwise, you can assume that the feature applies to all three. As you are undoubtedly aware, C and C++ are large topics. It is, of course, not possible to cover every aspect of these important languages here. Instead, this quick reference distills their most salient features into a convenient and easy to use form.

Abstract: The ubiquitous use of raw pointers in higher-level code is the primary cause of all memory usage problems and memory leaks in C++ programs. This paper describes what might be considered a radical approach to the problem which is to encapsulate the use of all raw pointers and all raw calls to new and delete in higher-level C++ code. Instead, a set of cooperating template classes developed in the Trilinos package Teuchos are used to encapsulate every use of raw C++ pointers in every use case where it appears in high-level code. Included in the set of memory management classes is the typical reference-counted smart pointer class similar to boost::shared ptr (and therefore C++0x std::shared ptr). However, what is missing in boost and the new standard library are non-reference counted classes for remaining use cases where raw C++ pointers would need to be used. These classes have a debug build mode where nearly all programmer errors are caught and gracefully reported at runtime. The default optimized build mode strips all runtime checks and allows the code to perform as efficiently as raw C++ pointers with reasonable usage. Also included is a novel approach for dealing with the circular references problemmore » that imparts little extra overhead and is almost completely invisible to most of the code (unlike the boost and therefore C++0x approach). Rather than being a radical approach, encapsulating all raw C++ pointers is simply the logical progression of a trend in the C++ development and standards community that started with std::auto ptr and is continued (but not finished) with std::shared ptr in C++0x. Using the Teuchos reference-counted memory management classes allows one to remove unnecessary constraints in the use of objects by removing arbitrary lifetime ordering constraints which are a type of unnecessary coupling [23]. The code one writes with these classes will be more likely to be correct on first writing, will be less likely to contain silent (but deadly) memory usage errors, and will be much more robust to later refactoring and maintenance. The level of debug-mode runtime checking provided by the Teuchos memory management classes is stronger in many respects than what is provided by memory checking tools like Valgrind and Purify while being much less expensive. However, tools like Valgrind and Purify perform a number of types of checks (like usage of uninitialized memory) that makes these tools very valuable and therefore complement the Teuchos memory management debug-mode runtime checking. The Teuchos memory management classes and idioms largely address the technical issues in resolving the fragile built-in C++ memory management model (with the exception of circular references which has no easy solution but can be managed as discussed). All that remains is to teach these classes and idioms and expand their usage in C++ codes. The long-term viability of C++ as a usable and productive language depends on it. Otherwise, if C++ is no safer than C, then is the greater complexity of C++ worth what one gets as extra features? Given that C is smaller and easier to learn than C++ and since most programmers don't know object-orientation (or templates or X, Y, and Z features of C++) all that well anyway, then what really are most programmers getting extra out of C++ that would outweigh the extra complexity of C++ over C? C++ zealots will argue this point but the reality is that C++ popularity has peaked and is becoming less popular while the popularity of C has remained fairly stable over the last decade22. Idioms like are advocated in this paper can help to avert this trend but it will require wide community buy-in and a change in the way C++ is taught in order to have the greatest impact. To make these programs more secure, compiler vendors or static analysis tools (e.g. klocwork23) could implement a preprocessor-like language similar to OpenMP24 that would allow the programmer to declare (in comments) that certain blocks of code should be ''pointer-free'' or allow smaller blocks to be 'pointers allowed'. This would significantly improve the robustness of code that uses the memory management classes described here.« less