Effective C++: 85 Specific Ways to Improve Your Programs and Designs

Other Format (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $78.01
Usually ships in 1-2 business days
Other sellers (Other Format)
  • All (5) from $78.01   
  • New (2) from $105.00   
  • Used (3) from $78.01   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$105.00
Seller since 2014

Feedback rating:

(181)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
$154.52
Seller since 2014

Feedback rating:

(290)

Condition: New
Brand New Item.

Ships from: Chatham, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Page 1 of 1
Showing All
Close
Sort by

Overview

Scott Meyers is an undisputed guru of C++, best known for his incisive guidelines on effective use of the language. This CD includes the complete text of his Effective C++ and More Effective C++, plus a collection of recent C++ magazine articles. Far more than the sum of Meyers' two books, the CD has over 2000 separate links: within and between the books, among the books and the articles, and from the books and articles to the Internet. Meyers personally selected the magazine articles to complement the material in his books, and they make the CD even more comprehensive and up-to-date.

Navigating the Effective C++ CD is fast and easy, because it takes advantage of powerful new features in the leading web browsers. You never have to dick more than twice to get to the information you want.

The CD offers unprecedented support for linking into the material, so seamlessly integrating the CD with a collection of HTML documents (such as an Intranet) is painless. Also unprecedented is the CD's configurability. Preference options control the size of images, diagrams, and file sizes, resulting in a system that looks good and responds quickly, regardless of your configuration.


It won't turn you into a programmer, but it will make you a lot better and wiser. Designed for intermediate C++ programmers, Effective C++, Second Edition and More Effective C++ compose this CD-ROM, along with recent magazine articles and 2000 links. Authored by Scott Meyers, these texts help you navigate through problems with effective (read that as clean, tight and fast) code.

Read More Show Less

Editorial Reviews

C/C++ Users Journal
Wow! All I can say is Wow!... If you are a C++ programmer, get this book.
Windows Developers Journal
I am happy to report that Scott Meyers has broken the logjam of fat books, higher prices, and thin CD-ROMs with Effective C++ CD.
Jack Woehr

CBT for C++

Effective C++ CD is the HTML (Netscape-oriented) version of Scott Meyers' previous two works, Effective C++, Second Edition and More Effective C++. Additionally, five supplementary magazine articles appear in the collection. There are also links to relevant material on the Web which that been added to the current edition and which did not appear in the print edition.

Scott Meyers' work is so well known as scarcely to need introduction. Respect for his C++ acumen and pedagogic skills is so widespread that I was prepared to thoroughly detest his work, which I have encountered often but barely deigned to read to date.

On close examination, I find Meyers' books to be superb.

Of the 50 catechismic "Items" in the body of Effective C++, the vast majority are of critical importance to solid C++ programming. Virtually everything Scott Meyers suggests on these subjects is germane and practical. Where one could conceivably differ with Meyers' approach, his is nevertheless an entirely sound approach.

The second volume, More Effective C++, is cast in the same mold as the first volume. Here the discussion of 35 further "Items" tends to devolve somewhat towards matters of style. However, these are still critical issues being raised that the intermediate C++ programmer must confront sooner or later, as presented in Meyers' rich and sympathetic tutorial prose.

The five supplementary magazine articles -- "Exception Handling: A False Sense of Security," by Tom Cargill; "Coping with Exceptions," by Jack W. Reeves; "Exception-Safe Generic Containers," by Herb Sutter; "Counting Objects in C++," by Scott Meyers; and "A First Look at C++ Program Analyzers," by Scott Meyers and Martin Klaus -- serve the dual function of extending the discussion of some important material covered in the text and of introducing the heads-down programmer to some of the intellectual controversy in the world of C++ literati.

If you actively code C++ and have less than five years' full-time on-the-job experience in C++, you probably should obtain this CD-ROM set, which is both inexpensive and exceptionally easy to browse and absorb. It reads smoothly, and is factual. Meyers' examples are elegant and nearly egoless. His advice is invariably helpful.

Let us acknowledge that Scott Meyers has a stylistic instinct and an aesthetic for genuine workplace C++ as fine and flawless as one programmer can admit of another programmer. Let us also acknowledge a great web editing and production job. This is top flight self-instruction technical literature tastefully and professionally redesigned in CD-ROM form with an eye to readability and ease of navigation. And considering that, in addition to the content, Meyers also designed and implemented the presentation format of this fine CD-ROM, he gets an extra thumbs up. A job well done.
— Dr. Dobb's Electronic Review of Computer Books

Read More Show Less

Product Details

  • ISBN-13: 9780201310153
  • Publisher: Addison-Wesley
  • Publication date: 1/28/1999
  • Series: Professional Computing Series
  • Edition description: New Edition
  • Pages: 8
  • Product dimensions: 7.58 (w) x 9.36 (h) x 0.80 (d)

Meet the Author


Scott Meyers is a recognized authority on C++; he provides consulting services to clients worldwide. He is a former columnist for The C++ Report, a featured speaker at technical conferences around the globe, and the author of Effective C++, Second Edition, More Effective C++, and The Effective C++ CD. He received his Ph.D. in Computer Science from Brown University in 1993.
Read More Show Less

Read an Excerpt


Item 1: Prefer const and inline to # define.

Shifting from C to C++

Getting used to C++ takes a little while for everyone, but for grizzled C programmers, the process can be especially unnerving. Because C is effectively a subset of C++, all the old C tricks continue to work, but many of them are no longer appropriate. To C++ programmers, for example, a pointer to a pointer looks a little funny. Why, we wonder, wasn't a reference to a pointer used instead?

C is a fairly simple language. All it really offers is macros, pointers, structs, arrays, and functions. No matter what the problem is, the solution will always boil down to macros, pointers, structs, arrays, and functions. Not so in C++. The macros, pointers, structs, arrays and functions are still there, of course, but so are private and protected members, function overloading, default parameters, constructors and destructors, user-defined operators, inline functions, references, friends, templates, exceptions, namespaces, and more. The design space is much richer in C++ than it is in C: there are just a lot more options to consider.

When faced with such a variety of choices, many C programmers hunker down and hold tight to what they're used to. For the most part, that's no great sin, but some C habits run contrary to the spirit of C++. Those are the ones that have simply got to go.

Item 1: Prefer const and inline to #define.

This Item might better be called "prefer the compiler to the preprocessor," because #define is often treated as if it's not part of the language per se. That's one of its problems. When you do something like this, #define ASPECT-RATIO 1.653 the symbolic name ASPECT - RATIO may never be seen by compilers; it may be removed by the preprocessor before the source code ever gets to a compiler. As a result, the name ASPECT-RATIO may not get entered into the symbol table. This can be confusing if you get an error during compilation involving the use of the constant, because the error message may refer to 1. 653, not ASPECT_RATIO. If ASPECT_RATIO was defined in a header Me you didn't write, you'd then have no idea where that 1. 6 5 3 came from, and you'd probably waste time tracking it down. This problem can also crop up in a symbolic debugger, because, again, the name you're programming with may not be in the symbol table.

The solution to this sorry scenario is simple and succinct. Instead of using a preprocessor macro, define a constant:

const double ASPECT_RATIO = 1.653;

This approach works like a charm. There are two special cases worth mentioning, however.

First, things can get a bit tricky when defining constant pointers. Because constant definitions are typically put in header files (where many different source files will include them), it's important that the pointer be declared const, usually in addition to what the pointer points to. To define a constant char* -based string in a header Me, for example, you have to write const twice:

const char * const authorName = "Scott Meyers".

For a discussion of the meanings and uses of const, especially in conjunction with pointers, see Item 2 1.

Second, it's often convenient to define class-specific constants, and that calls for a slightly different tack. To limit the scope of a constant to a class, you must make it a member, and to ensure there's at most one copy of the constant, you must make it a static member:

class GamePlayer
private:

static const int NUM_TURNS = 5; constant declaration

int scores[NUM-TURNS]; use of constant,

There's a minor wrinkle, however, which is that what you see above is a declaration for NUM_TURNS, not a definition. You must still define static class members in an implementation file:

const int GamePlayer::NUM_TURNS; mandatory definition;
goes in class impl. file

There's no need to lose sleep worrying about this detail. If you forget the definition, your linker should remind you. Older compilers may not accept this syntax, because it used to be illegal to provide an initial value for a static class member at its point of declaration. Furthermore, in- class initialization is allowed only for integral types (e.g., ints, bools, chars, etc.), and only for constants. In cases where the above syntax can't be used, you put the initial value at the point of definition:

class EngineeringConstants this goes in the class
private: header file
...
} ;

double EngineeringConstants::FUDGE_FACTOR = 1.35;

This is all you need almost all the time. The only exception is when you need the value of a class constant during compilation of the class, such as in the declaration of the array GamePlayer: :scores above (where compilers insist on knowing the size of the array during compilation). Then the accepted way to compensate for compilers that (incorrectly) forbid the in-class specification of initial values for integral class constants is to use what is affectionately known as "the enum hack." This technique takes advantage of the fact that the values of an enumerated type can be used where ints are expected, so GamePlayer could just as well have been defined like this:

class GamePlayer {
private:
...
} ;

Unless you're dealing with compilers of primarily historical interest (i.e., those written before 1995), you shouldn't have to use the enum hack. Still, it's worth knowing what it looks like, because it's not uncommon to encounter it in code dating back to those early, simpler times.

Getting back to the preprocessor, another common (mis)use of the #define directive is using it to implement macros that look like func tions, but that don't incur the overhead of a function call. The canonical example is computing the maximum of two values:

#define max(a,b) ( (a) > (b) ? (a) :
(b) )

This little number has so many drawbacks, just thinking about them is painful. You're better off playing in the freeway during rush hour.

Whenever you write a macro like this, you have to remember to parenthesize all the arguments when you write the macro body: otherwise you can run into trouble when somebody calls the macro with an expression. But even if you get that right, look at the weird things that can happen:

int a = 5, b = 0;

max(++a, b) ; a is incremented twice
max(++a, b+10); a is incremented once

Here, what happens to a inside max depends on what it is being compared with!

Fortunately, you don't need to put up with this nonsense. You can get all the efficiency of a macro plus all the predictable behavior and typesafety of a regular function by using an inline function (see Item 33):

inline int max(int a, int b) { return a > b ? a :
b; }

Now this isn't quite the same as the macro above, because this version of max can only be called with ints, but a template fixes that, problem quite nicely:

tenplate<class T>
inline const T& max{const T& a, const T&
b}
{ return a > b ? a : b; }

This template generates a whole family of functions, each of which takes two objects convertible to the same type and returns a reference to (a constant version of) the greater of the two objects. Because you don't know what the type T will be, you pass and return by reference for efficiency (see Item 22).

By the way, before you consider writing templates for commonly useful functions like max, check the standard library (see Item 49) to see. if they already exist. In the case of max, you'll be pleasantly surprised to find that you can rest on others' laurels: max is part of the standard C++ library.

Given the availability of consts and inlines, your need for the preprocessor is reduced, but It's not completely eliminated. The day is far from near when you can abandon #include, and #ifdef /#ifndef continue to play important roles in controlling compilation. It's not yet time to retire the preprocessor, but you should definitely plan to start giving it longer and more frequent vacations.

Item 2: Prefer <iostream> to <stdio.h>.

Yes, they're portable. Yes, they're efficient. Yes, you already know how to use them. Yes, yes, yes. But venerated though they are, the fact of the matter is that scanf and printf and all their ilk could use some improvement. In particular, they're not type-safe and they're not extensible. Because type safety and extensibility are cornerstones of the C++ way of life, you might just as well resign yourself to them right now. Besides, the printf /scanf family of functions separate the variables to be read or written from the formatting information that controls the reads and writes, just like FORTRAN does. It's time to bid the 1950s a fond farewell. Not surprisingly, these weaknesses of printf /scanf are the strengths of operator>> and operator<<.
...

cin >> i >> r;
cout << i << r;

If this code is to compile, there must be functions operator>> and operator<< that can work with an object of type Rational. If these functions are missing, it's an error. (The versions for ints are standard.) Furthermore, compilers take care of figuring out which versions of the operators to call for different variables, so you needn't worry about specifying that the first object to be read or written is an int and the second is a Rational.

In addition, objects to be read are passed using the same syntactic form as are those to be written, so you don't have to remember silly rules like you do for scanf, where if you don't already have a pointer, you have to be sure to take an address, but if you've already got a pointer, you have to be sure not to take an address. Let C++ compilers take care of those details. They have nothing better to do, and you do have better things to do. Finally, note that built-in types like int are read and written in the same manner as user-defined types like Rational. Try that using scanf and printf! . . .

Read More Show Less

Table of Contents


Preface
Acknowledgments
Introduction
Shifting from C to C++
Item 1: Prefer const and inline to #define.
Item 2: Prefer <iostream> to <stdio.h>.
Item 5: Use the same form in corresponding uses of new and delete.
Item 6: Use de1ete on pointer members in destructors.
Item 7: Be prepared for out-of-memory conditions.
Item 8: Adhere to convention when writing operator new
Item 9: Avoid hiding the "normal" form of new.
Item 10: Write operator delete if you write operator new.
Item 30: Avoid member functions that return non-const
Item 31: Never return a reference to a local object or to a
Item 32: Postpone variable definitions as long as possible.
Item 33: Use inlining judiciously.
Item 34: Minimize compilation dependencies between files
Afterword
Index
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

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