eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
C++ For Dummies, 7th Edition is the best-selling C++ guide on the market, fully revised for the 2014 update. With over 60% new content, this updated guide reflects the new standards, and includes a new Big Data focus that highlights the use of C++ among popular Big Data software solutions. The book provides step-by-step instruction from the ground up, helping beginners become programmers and allowing intermediate programmers to sharpen their skills. The companion website provides all code mentioned in the text, an updated GNU_C++, the new C++ compiler, and other applications. By the end of the first chapter, you will have programmed your first C++ application!
As one of the most commonly used programming languages, C++ is a must-have skill for programmers who wish to remain versatile and marketable. C++ For Dummies, 7th Edition provides clear, concise, expert instruction, which is organized for easy navigation and designed for hands-on learning. Whether you're new to programming, familiar with other languages, or just getting up to speed on the new libraries, features, and generics, this guide provides the information you need.
- Provides you with an introduction to C++ programming
- Helps you become a functional programmer
- Features information on classes, inheritance, and optional features
- Teaches you 10 ways to avoid adding bugs
The book incorporates the newest C++ features into the fundamental instruction, allowing beginners to learn the update as they learn the language. Staying current on the latest developments is a crucial part of being a programmer, and C++ For Dummies, 7th Edition gets you started off on the right foot.
Product Details
| ISBN-13: | 9781118823835 |
|---|---|
| Publisher: | Wiley |
| Publication date: | 05/22/2014 |
| Series: | For Dummies Books |
| Sold by: | JOHN WILEY & SONS |
| Format: | eBook |
| Pages: | 480 |
| Sales rank: | 568,853 |
| File size: | 3 MB |
About the Author
Stephen R. Davis is the bestselling author of numerous books and articles, including C# For Dummies. He has been programming for over 30 years and currently works for Booz Allen Hamilton in the area of Homeland Defense.
Read an Excerpt
Chapter 7 |
Okay, you've waited long enough. What, exactly, is object-oriented programming? Object-oriented programming, or OOP as those in the know prefer to call it, relies on two principles you learned before you ever got out of Pampers: abstraction and classification. To explain, let me tell you a little story. |
Abstraction and Microwave Ovens
Sometimes when my son and I are watching football, I whip up a terribly unhealthy batch of nachos. I dump some chips on a plate, throw on some beans, cheese, and lots of jalapeños, and nuke the whole mess in the microwave oven for 5 minutes. To use my microwave, I open the door, throw the stuff in, and punch a few buttons on the front. After a few minutes, the nachos are done. (I try not to stand in front of the microwave while it's working lest my eyes start glowing in the dark.) Now think for a minute about all the things I don't do to use my microwave:
|
These are not profound observations. You can think about only so much at one time. To reduce the number of things that you must deal with, you work at a certain level of detail. In object-oriented (OO) computerese, the level of detail at which you are working is called the level of abstraction. To introduce another OO term while I have the chance, I abstract away the details of the microwave's internals. When I'm working on nachos, I view my microwave oven as a box. (As I'm trying to knock out a snack, I can't worry about the innards of the microwave oven and still follow the Cowboys on the tube.) As long as I use the microwave only through its interface (the keypad), there should be nothing I can do to cause the microwave to enter an inconsistent state and crash or, worse, turn my nachos into a blackened, flaming mass. Functional nachosSuppose I were to ask my son to write an algorithm for how Dad makes nachos. After he understood what I wanted, he would probably write "open a can of beans, grate some cheese, cut the jalapeños," and so on. When it came to the part about microwaving the concoction, he would write something like "cook in the microwave for 5 minutes." That description is straightforward and complete. But it's not the way a functional programmer would code a program to make nachos. Functional programmers live in a world devoid of objects, such as microwave ovens and other appliances. They tend to worry about flow charts with their myriad functional paths. In a functional solution to the nachos problem, the flow of control would pass through my finger to the front panel and then to the internals of the microwave. Pretty soon, flow would be wiggling around through complex logic paths about how long to turn on the microwave tube and whether to sound the "come and get it" tone. In a world like this, it's difficult to think in terms of levels of abstraction. There are no objects, no abstractions behind which to hide inherent complexity. Object-oriented nachosIn an object-oriented approach to making nachos, I would first identify the types of objects in the problem: chips, beans, cheese, and an oven. Then I would begin the task of modeling these objects in software, without regard to the details of how they will be used in the final program. While I am doing this, I'm said to be working (and thinking) at the level of the basic objects. I need to think about making a useful oven, but I don't have to think about the logical process of making nachos yet. After all, the microwave designers didn't think about the specific problem of my making a snack. Rather, they set about the problem of designing and building a useful microwave. After the objects I need have been successfully coded and tested, I can ratchet up to the next level of abstraction. I can start thinking at the nacho-making level, rather than the microwave-making level. At this point, I can pretty much translate my son's instructions directly into C++ code. |
Classification and Microwave Ovens
Critical to the concept of abstraction is that of classification. If I were to ask my son, "What's a microwave?" he would probably say, "It's an oven that...." If I then asked, "What's an oven?" he might reply, "It's a kitchen appliance that...." (If I then asked "What's a kitchen appliance?" he would probably say, "Why are you asking so many stupid questions?") The answers my son gave in my example questioning stem from his understanding of our particular microwave as an example of the type of things called microwave ovens. In addition, my son sees microwave ovens as just a special type of oven, which is in turn a special type of kitchen appliance. |
In object-oriented computerese, my microwave is an instance of the class microwave. The class microwave is a subclass of the class oven, and the class oven is a subclass of the class kitchen appliances. Humans classify. Everything about our world is ordered into taxonomies. We do this to reduce the number of things we have to remember. Take, for example, the first time you saw a Saturn automobile. The advertisement called the Saturn "revolutionary, the likes of which have never been seen." But you and I know that that just isn't so. I like the looks of the Saturn, but hey, it's a car. As such, it shares all of (or at least most of) the properties of other cars. It has a steering wheel, seats, a motor, brakes, and so on. I bet I could even drive one without help. I don't have to clutter my limited storage with all the things that a Saturn has in common with other cars. All I have to remember is "a Saturn is a car that..." and tack on those few things that are unique to a Saturn. I can go further. Cars are a subclass of wheeled vehicles, of which there are other members, such as trucks and pickups. Maybe wheeled vehicles are a subclass of vehicles, which include boats and planes. And on and on and on. |
Why Classify?
True to form, one of the important questions I ask in this book is "Why?" Why do we want to classify? It sounds like a lot of trouble. (Besides, I've been programming the functional way for so long. Why do I need to change now?) It may seem easier to design and build a microwave oven specifically for this one problem, rather than build a separate, more generic oven object. Suppose, for example, that I want to build a microwave to cook nachos and nachos only. There would be no need to put a front panel on it, other than a START button. I always cook nachos the same amount of time. I could dispense with all that DEFROST and TEMP COOK nonsense. It would need to hold only one flat little plate. Three cubic feet of space would be wasted on nachos. For that matter, I can dispense with the concept of "microwave oven" altogether. All I really need is the guts of the oven. Then, in the recipe, I put the instructions to make it work: "Put nachos in the box. Connect the red wire to the black wire. Notice a slight hum. Try not to stand too close if you intend to have children." Stuff like that. But the functional approach has some problems:
|
Table of Contents
Introduction 1Part I: Getting Started with C++ Programming 7
Chapter 1: Writing Your First C++ Program 9
Chapter 2: Declaring Variables Constantly 33
Chapter 3: Performing Mathematical Operations 47
Chapter 4: Performing Logical Operations 53
Chapter 5: Controlling Program Flow 69
Part II: Becoming a Functional C++ Programmer 87
Chapter 6: Creating Functions 89
Chapter 7: Storing Sequences in Arrays 105
Chapter 8: Taking a First Look at C++ Pointers 121
Chapter 9: Taking a Second Look at C++ Pointers 135
Chapter 10: The C++ Preprocessor 153
Part III: Introduction to Classes 167
Chapter 11: Examining Object-Oriented Programming 169
Chapter 12: Adding Class to C++ 175
Chapter 13: Point and Stare at Objects 191
Chapter 14: Protecting Members: Do Not Disturb 207
Chapter 15: “Why Do You Build Me Up, Just to Tear Me Down, Baby?” 215
Chapter 16: Making Constructive Arguments 225
Chapter 17: The Copy/Move Constructor 247
Chapter 18: Static Members: Can Fabric Softener Help? 261
Part IV: Inheritance 271
Chapter 19: Inheriting a Class 273
Chapter 20: Examining Virtual Member Functions: Are They for Real? 281
Chapter 21: Factoring Classes 291
Part V: Security 301
Chapter 22: A New Assignment Operator, Should You Decide to Accept It 303
Chapter 23: Using Stream I/O 315
Chapter 24: Handling Errors — Exceptions 337
Chapter 25: Inheriting Multiple Inheritance 347
Chapter 26: Tempting C++ Templates 359
Chapter 27: Standardizing on the Standard Template Library 369
Chapter 28: Writing Hacker-Proof Code 381
Part VI: The Part of Tens 407
Chapter 29: Ten Ways to Avoid Adding Bugs to Your Program 409
Chapter 30: Ten Ways to Protect Your Programs from Hackers 417
Index 431