More Effective C++: 35 New Ways to Improve Your Programs and Designs / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (23) from $1.99   
  • New (9) from $31.71   
  • Used (14) from $1.99   

Overview

More than 150,000 copies in print!

Praise for Scott Meyers’ first book, Effective C++:

“I heartily recommend Effective C++ to anyone who aspires to mastery of C++ at the intermediate level or above.”
– The C/C++ User’s Journal

From the author of the indispensable Effective C++, here are 35 new ways to improve your programs and designs. Drawing on years of experience, Meyers explains how to write software that is more effective: more efficient, more robust, more consistent, more portable, and more reusable. In short, how to write C++ software that’s just plain better.

More Effective C++ includes:

  • Proven methods for improving program efficiency, including incisive examinations of the time/space costs of C++ language features
  • Comprehensive descriptions of advanced techniques used by C++ experts, including placement new, virtual constructors, smart pointers, reference counting, proxy classes, and double-dispatching
  • Examples of the profound impact of exception handling on the structure and behavior of C++ classes and functions
  • Practical treatments of new language features, including bool, mutable, explicit, namespaces, member templates, the Standard Template Library, and more. If your compilers don’t yet support these features, Meyers shows you how to get the job done without them.

More Effective C++ is filled with pragmatic, down-to-earth advice you’ll use every day. Like Effective C++ before it, More Effective C++ is essential reading for anyone working with C++.


Scott Meyers has done it again, expanding on his indispensable classic Effective C++ with 35 new ways to improve programs and designs to make them more consistent, more efficient, more portable, in short, just plain better.Join Meyers for his in-the-know discussions of advanced C++ techniques likesmart pointers and double-dispatching, or examine your own programefficiency with the help of Meyers' critical analysis of the costs of usingC++.If your C++ compiler doesn't support new features like bool and theStandard Template Library, Meyers can get you over your design hump bydemonstrating how to get the job done regardless.This pragmatic advicesource is as essential to a C++ library as Meyers' previous book, and isjust as useful for any experienced programmer not content to produce merelyadequate programs.

Read More Show Less

Editorial Reviews

Booknews
For programmers at the intermediate level and above. This sequel to the author's Effective C++ provides methods for improving program efficiency. Coverage includes examinations of the time/space costs of C++ language features; descriptions of advanced techniques (placement new, virtual constructors, smart pointers, reference county proxy classes, and double-dispatching); examples of the impact of exception handling; and treatment of new language features (e.g. bool, mutable, explicit, namespaces, member templates). Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780201633719
  • Publisher: Addison-Wesley
  • Publication date: 12/29/1995
  • Series: Addison-Wesley Professional Computing Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 336
  • Sales rank: 426,117
  • Product dimensions: 7.37 (w) x 9.22 (h) x 0.81 (d)

Meet the Author

Scott Meyers is one of the world's foremost authorities on C++, providing training and consulting services to clients worldwide. He is the author of the best-selling Effective C++ series of books (Effective C++, More Effective C++, and Effective STL) and of the innovative Effective C++ CD. He is consulting editor for Addison Wesley's Effective Software Development Series and serves on the Advisory Board for The C++ Source (http://www.artima.com/cppsource). He holds a Ph.D. in Computer Science from Brown University. His web site is http://www.aristeia.com.

Read More Show Less

Read an Excerpt


Item 33: Make non-leaf classes abstract

Suppose you're working on a project whose software deals with animals. Within this software, most animals can be treated pretty much the same, but two kinds of animals -- lizards and chickens -- require special handling. That being the case, the obvious way to relate the classes for animals, lizards, and chickens is like this: The Animal class embodies the features shared by all the creatures you deal with, and the Lizard and Chicken classes specialize Animal in ways appropriate for lizards and chickens, respectively.

Here's a sketch of the definitions for these classes:

class Animal {
public:
Animal& operator=(const Animal& rhs);
...

};
class Lizard: public Animal {
public:
Lizard& operator=(const Lizard& rhs);
...

};
class Chicken: public Animal {
public:
Chicken& operator=(const Chicken& rhs);
...

};

Only the assignment operators are shown here, but that's more than enough to keep us busy for a while. Consider this code:

Lizard liz1;
Lizard liz2;

Animal *pAnimal1 = &liz1;
Animal *pAnimal2 = &liz2;

...

*pAnimal1 = *pAnimal2;

There are two problems here. First, the assignment operator invoked on the last line is that of the Animal class, even though the objects involved are of type Lizard. As a result, only the Animal part of liz1 will be modified. This is a partial assignment. After the assignment, liz1's Animal members have the values they got from liz2, but liz1's Lizard members remain unchanged.

The second problem is that real programmers write code like this. It's not uncommon to make assignments to objects through pointers, especially for experienced C programmers who have moved to C++. That being the case, we'd like to make the assignment behave in a more reasonable fashion. As Item 32 points out, our classes should be easy to use correctly and difficult to use incorrectly, and the classes in the hierarchy above are easy to use incorrectly.

One approach to the problem is to make the assignment operators virtual. If Animal::operator= were virtual, the assignment would invoke the Lizard assignment operator, which is certainly the correct one to call. However, look what happens if we declare the assignment operators virtual:

class Animal {
public:
virtual Animal& operator=(const Animal& rhs);
...
};
class Lizard: public Animal {
public:
virtual Lizard& operator=(const Animal& rhs);
...
};
class Chicken: public Animal {
public:
virtual Chicken& operator=(const Animal& rhs);
...
};

Due to relatively recent changes to the language, we can customize the return value of the assignment operators so that each returns a reference to the correct class, but the rules of C++ force us to declare identical parameter types for a virtual function in every class in which it is declared. That means the assignment operator for the Lizard and Chicken classes must be prepared to accept any kind of Animal object on the right-hand side of an assignment. That, in turn, means we have to confront the fact that code like the following is legal:

Lizard liz;
Chicken chick;

Animal *pAnimal1 = &liz;
Animal *pAnimal2 = &chick;

...

*pAnimal1 = *pAnimal2;     // assign a chicken to
This is a mixed-type assignment: a Lizard is on the left and a Chicken is on the right. Mixed-type assignments aren't usually a problem in C++, because the language's strong typing generally renders them illegal. By making Animal's assignment operator virtual, however, we opened the door to such mixed-type operations.

This puts us in a difficult position. We'd like to allow same-type assignments through pointers, but we'd like to forbid mixed-type assignments through those same pointers. In other words, we want to allow this,

Animal *pAnimal1 = &liz1;
Animal *pAnimal2 = &liz2;

...

*pAnimal1 = *pAnimal2;   // assign a lizard to a lizard

but we want to prohibit this:

Animal *pAnimal1 = &liz;
Animal *pAnimal2 = &chick;

...

*pAnimal1 = *pAnimal2; // assign a chicken to a lizard

Distinctions such as these can be made only at runtime, because sometimes assigning *pAnimal2 to *pAnimal1 is valid, sometimes it's not. We thus enter the murky world of type-based runtime errors. In particular, we need to signal an error inside operator= if we're faced with a mixed-type assignment, but if the types are the same, we want to perform the assignment in the usual fashion. We can use a dynamic_cast (see Item 2) to implement this behavior. Here's how to do it for Lizard's assignment operator:

Lizard& Lizard::operator=(const Animal& rhs)
{
// make sure rhs is really a lizard
const Lizard& rhs_liz = dynamic_cast(rhs);

proceed with a normal assignment of rhs_liz to *this;

}

This function assigns rhs to *this only if rhs is really a Lizard. If it's not, the function propagates the bad_cast exception that dynamic_cast throws when the cast fails. (Actually, the type of the exception is std::bad_cast, because the components of the standard library, including the exceptions thrown by the standard components, are in the namespace std. For an overview of the standard library, see Item 35.)

Even without worrying about exceptions, this function seems needlessly complicated and expensive -- the dynamic_cast must consult a type_info structure; see Item 24 -- in the common case where one Lizard object is assigned to another...

Read More Show Less

Table of Contents

Acknowledgments xi

Introduction 1

Basics 9

Item 1: Distinguish between pointers and references. 9
Item 2: Prefer C++-style casts. 12
Item 3: Never treat arrays polymorphically. 16
Item 4: Avoid gratuitous default constructors. 19

Operators 24

Item 5: Be wary of user-defined conversion functions. 24
Item 6: Distinguish between prefix and postfix forms of increment and decrement operators. 31
Item 7: Never overload &&, , or ,. 35
Item 8: Understand the different meanings of new and delete. 38

Exceptions 44

Item 9: Use destructors to prevent resource leaks. 45
Item 10: Prevent resource leaks in constructors. 50
Item 11: Prevent exceptions from leaving destructors. 58
Item 12: Understand how throwing an exception differs from passing a parameter or calling a virtual function. 61
Item 13: Catch exceptions by reference. 68
Item 14: Use exception specifications judiciously. 72
Item 15: Understand the costs of exception handling. 78

Efficiency 81

Item 16: Remember the 80-20 rule. 82
Item 17: Consider using lazy evaluation. 85
Item 18: Amortize the cost of expected computations. 93
Item 19: Understand the origin of temporary objects. 98
Item 20: Facilitate the return value optimization. 101
Item 21: Overload to avoid implicit type conversions. 105
Item 22: Consider using op= instead of stand-alone op. 107
Item 23: Consider alternative libraries. 110
Item 24: Understand the costs of virtual functions, multiple inheritance, virtual base classes, and RTTI. 113

Techniques 123

Item 25: Virtualizing constructors and non-member functions. 123
Item 26: Limiting the number of objects of a class. 130
Item 27: Requiring or prohibiting heap-based objects. 145
Item 28: Smart pointers. 159
Item 29: Reference counting. 183
Item 30: Proxy classes. 213
Item 31: Making functions virtual with respect to more than one object. 228

Miscellany 252

Item 32: Program in the future tense. 252
Item 33: Make non-leaf classes abstract. 258
Item 34: Understand how to combine C++ and C in the same program. 270
Item 35: Familiarize yourself with the language standard. 277

Recommended Reading 285

An auto_ptr Implementation 291

General Index 295

Index of Example Classes, Functions, and Templates 313

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Anonymous

    Posted November 8, 2008

    No text was provided for this review.

  • Anonymous

    Posted April 15, 2011

    No text was provided for this review.

Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)