Scott Meyers
Effective C++ Third edition
Náučná pre dospelých
výpočtová technika
Jazyk:anglický
297 strán
Nakladateľ : Addison - Wesley
Rok vydania : 2014
V knižnici od : 17.8.2022
Výpožičiek : 0
Stav :
Výška/šírka : 23.5x18.8 cm
C++/Programming Languages
Effective C++ Third Edition
Every C++ professional needs a copy of Effective C++. It is an absolute must-read for anyone thinking of doing serious C++ development. If you've never read Effective C++ and you think you know everything about C++, think again."
— Steve Schirripa, Software Engineer, Google
C++ and the C++ community have grown up in the last fifteen years, and the third edition of Effective C++ reflects this. The clear and precise style of the book is evidence of Scott's deep insight and distinctive ability to impart knowledge."
— Gerhard Kreuzer, Research and Development Engineer, Siemens AG
The first two editions of Effective C++ were embraced by hundreds of thousands of programmers worldwide. The reason is clear: Scott Meyers' practical approach to C++ describes the rules of thumb used by the experts — the things they almost always do or almost always avoid doing — to produce clear, correct, efficient code.
The book is organized around 55 specific guidelines, each of which describes a way to write better C++. Each is backed by concrete examples. For this third edition, more than half the content is new, including added chapters on managing resources and using templates. Topics from the second edition have been extensively revised to reflect modern design considerations, including exceptions, design patterns, and multithreading.
Important features of Effective C++ include:
• Expert guidance on the design of effective classes, functions, templates, and inheritance hierarchies.
• Applications of new "TR1" standard library functionality, along with comparisons to existing standard library components.
• Insights into differences between C++ and other languages (e.g., Java, Ctt, C) that help developers from those languages assimilate "the C++ way" of doing things.
Scott Meyers is one of the world's foremost experts on C++ software development. He is author of the best-selling Effective C++ series (Effective C++, More Effective C++, and Effective STL), designer and author of the innovative Effective C++ CD, consulting editor for Addison-Wesley's Effective Software Development Series, and a member of the advisory board for Software Development magazine. He has served on the technical advisory boards for several start-up companies. Meyers received his Ph.D. in computer science from Brown University in 1993. His web site is www.aristeia.com.
www.awprofessional.com/series/professionalcomputing
ÚRYVOK :
If an int occupies 32 bits, a Point object can typically fit into a 64-bit register. Furthermore, such a Point object can be passed as a 64-bit quantity to functions written in other languages, such as C or FORTRAN. If Point’s destructor is made virtual, however, the situation changes. The implementation of virtual functions requires that objects carry information that can be used at runtime to determine which virtual functions should be invoked on the object. This information typically takes the form of a pointer called a vptr (“virtual table pointer”). The vptr points to an array of function pointers called a vtbl (“virtual table”); each class with virtual functions has an associated vtbl. When a virtual function is invoked on an object, the actual function called is determined by following the object’s vptr to a vtbl and then looking up the appropriate function pointer in the vtbl. The details of how virtual functions are implemented are unimportant. What is important is that if the Point class contains a virtual function, objects of that type will increase in size. On a 32-bit architecture, they’ll go from 64 bits (for the two ints) to 96 bits (for the ints plus the vptr); on a 64-bit architecture, they may go from 64 to 128 bits, because pointers on such architectures are 64 bits in size. Addition of a vptr to Point will thus increase its size by 50-100%! No longer can Point objects fit in a 64-bit register. Furthermore, Point objects in C++ can no longer look like the same structure declared in another language such as C, because their foreign language counterparts will lack the vptr. As a result, it is no longer possible to pass Points to and from functions written in other languages unless you explicitly compensate for the vptr, which is itself an implementation detail and hence unportable. The bottom line is that gratuitously declaring all destructors virtual is just as wrong as never declaring them virtual. In fact, many people summarize the situation this way: declare a virtual destructor in a class if and only if that class contains at least one virtual function. It is possible to get bitten by the non-virtual destructor problem even in the complete absence of virtual functions. For example, the standard string type contains no virtual functions, but misguided programmers sometimes use it as a base class anyway: class Specialstring: public std::string { // bad idea! std::string has a // non-virtual destructor }; At first glance, this may look innocuous, but if anywhere in an application you somehow convert a pointer-to-SpecialString into a pointer-to-
If an int occupies 32 bits, a Point object can typically fit into a 64-bit register. Furthermore, such a Point object can be passed as a 64-bit quantity to functions written in other languages, such as C or FORTRAN. If Point’s destructor is made virtual, however, the situation changes. The implementation of virtual functions requires that objects carry information that can be used at runtime to determine which virtual functions should be invoked on the object. This information typically takes the form of a pointer called a vptr (“virtual table pointer”). The vptr points to an array of function pointers called a vtbl (“virtual table”); each class with virtual functions has an associated vtbl. When a virtual function is invoked on an object, the actual function called is determined by following the object’s vptr to a vtbl and then looking up the appropriate function pointer in the vtbl. The details of how virtual functions are implemented are unimportant. What is important is that if the Point class contains a virtual function, objects of that type will increase in size. On a 32-bit architecture, they’ll go from 64 bits (for the two ints) to 96 bits (for the ints plus the vptr); on a 64-bit architecture, they may go from 64 to 128 bits, because pointers on such architectures are 64 bits in size. Addition of a vptr to Point will thus increase its size by 50-100%! No longer can Point objects fit in a 64-bit register. Furthermore, Point objects in C++ can no longer look like the same structure declared in another language such as C, because their foreign language counterparts will lack the vptr. As a result, it is no longer possible to pass Points to and from functions written in other languages unless you explicitly compensate for the vptr, which is itself an implementation detail and hence unportable. The bottom line is that gratuitously declaring all destructors virtual is just as wrong as never declaring them virtual. In fact, many people summarize the situation this way: declare a virtual destructor in a class if and only if that class contains at least one virtual function. It is possible to get bitten by the non-virtual destructor problem even in the complete absence of virtual functions. For example, the standard string type contains no virtual functions, but misguided programmers sometimes use it as a base class anyway: class Specialstring: public std::string { // bad idea! std::string has a // non-virtual destructor }; At first glance, this may look innocuous, but if anywhere in an application you somehow convert a pointer-to-SpecialString into a pointer-to-