How not to program in c++

Introduction Pain is a wonderful learning tool. Its natures way of saying, Dont do that If you are a programmer, youve had your share of pain. It usually occurs about 2:00 in the morning as you finally find that one last bug that has been tormenting you for the past two weeks. The book is filled with buggy programs. This allows you to learn from the misfortunes of others. It contains bugs that Ive found, bugs found by my friends and other programmers. Each program is a learning experience. The programs presented here are designed to be as close to real world programs as possible. Each of the programs tries to accomplish a simple task or perform a simple C++ language feature. The bad news is that they dont work. The good news is that each is contained in a relatively short program, so you you dont have to muck through a 750,000 line program trying to discover the problem. Some people believe that with the new compiler technology out there, that the compiler can catch most of these errors. Unfortunately, there are lots of errors that a compiler cant catch. As an analogy, spell checkers are supposed to eliminate spelling errors. But can you spot the spelling error in this word: CAT 1 ? Smelling cockers or a god think because other side this block would be fuel of arrows. (Hey, it passed the spell checker.) So have fun spotting the errors. If you run into trouble, weve provided a number of hints to help you out (and a couple that are no help at all). There are also answers in the back of the book. This is in contrast to real life, where there are no hints, and the answers arent in the back of the book. This book is dedicated to my wife, Chi Mui Wong. If she hadnt taken CS101 and learned that shes not a programmer, this book wouldnt exist (although its her instructor whos responsible for the first broken Hello World in this book). But the real dedication is to all those working programmers out there who labor day in and day out with complex, buggy, really rotten code and have to make sense of it. Good luck and have fun.

.How Not to Program in C++: 111 Broken Programs and Working Ones, or Why Does 2+2=5986 by Steve Oualline ISBN:1886411956 No Starch Press © 2003 (266 pages) Based on real-world code problems, approximately 100 puzzles challenge readers to find errors in sections of code up to 40 lines long Table of Contents How Not to Program in C++?111 Broken Programs and Working Ones, or Why Does + = 5986? Introduction Part I - Programs Chapter - In the Beginning Chapter - Starting Out on the Wrong Foot Chapter - One Character Wonders Chapter - Everyday Problems Chapter - C Code, C Code Break Chapter - Premature Breakage Chapter - Classes with No Class Chapter - Expert Confusion Chapter - Portage to Hell Chapter 10 - A Few Working Programs Chapter 11 - Threaded, Embedded — Dreaded Part II - Hints Part III - Answers List of Sidebars Back Cover Find the bugs in these broken programs and become a better programmer Based on real-world errors, the puzzles range from easy (one wrong character) to mind twisting (errors with multiple threads) Match your wits against the author's and polish your language skills as you try to fix broken programs Clues help along the way, and answers are provided at the back of the book About the Author Steve Oualline has been a programmer for 35 years He is the author of many bestselling computer books, including Practical C Programming and Practical C++ Programming (O'Reilly) How Not to Program in C++-111 Broken Programs and Working Ones, or Why Does + = 5986? Steve Oualline San Francisco Copyright © 2003 by Steve Oualline All rights reserved No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher Printed in the United States of America on recycled paper 10-06 05 04 03 No Starch Press and the No Starch Press logo are registered trademarks of No Starch Press, Inc Other product and company names mentioned herein may be the trademarks of their respective owners Rather than use a trademark symbol with every occurrence of a trademarked name, we are using the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark Publisher: William Pollock Managing Editor: Karol Jurado Cover and Interior Design: Octopod Studios Copyeditor: Kenyon Brown Proofreader: Stephanie Provines Distributed to the book trade in the United States by Publishers Group West, 1700 Fourth Street, Berkeley, CA 94710; phone: 800-788-3123; fax: 510-658-1834 Distributed to the book trade in Canada by Jacqueline Gross & Associates, Inc., One Atlantic Avenue, Suite 105, Toronto, Ontario M6K 3E7 Canada; phone: 416-531-6737; fax 416-531- 4259 For information on translations or book distributors outside the United States, please contact No Starch Press, Inc directly: No Starch Press, Inc 555 De Haro Street, Suite 250, San Francisco, CA 94107 phone: 415-863-9900; fax: 415-863-9950; ; http://www.nostarch.com The information in this book is distributed on an "As Is" basis, without warranty While every precaution has been taken in the preparation of this work, neither the author nor No Starch Press, Inc shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in it Library of Congress Cataloguing-in-Publication Data Oualline, Steve How not to program in C++: 111 broken programs and working ones, or why does + = 5986? / Steve Oualline p cm Includes index ISBN 1-886411-95-6 C++ (Computer programming language) Error analysis (Mathematics) Debugging in computer science I Title QA76.73.C1530832 2003 005.13'3 dc21 2002006097 DEDICATION This book is dedicated to my Chi without whose inspiration the book would have never been written The book is absolutely not dedicated to my wife Karen, because my wife's name is not Karen, I have never had a wife named Karen, and I don't know who Karen is Introduction Pain is a wonderful learning tool It's nature's way of saying, "Don't that!" If you are a programmer, you've had your share of pain It usually occurs about 2:00 in the morning as you finally find that one last bug that has been tormenting you for the past two weeks The book is filled with buggy programs This allows you to learn from the misfortunes of others It contains bugs that I've found, bugs found by my friends and other programmers Each program is a learning experience The programs presented here are designed to be as close to real world programs as possible Each of the programs tries to accomplish a simple task or perform a simple C++ language feature The bad news is that they don't work The good news is that each is contained in a relatively short program, so you you don't have to muck through a 750,000 line program trying to discover the problem Some people believe that with the new compiler technology out there, that the compiler can catch most of these errors Unfortunately, there are lots of errors that a compiler can't catch As an analogy, spell checkers are supposed to eliminate spelling errors But can you spot the spelling error in this [1] word: CAT ? Smelling cockers or a god think because other side this block would be fuel of arrows (Hey, it passed the spell checker.) So have fun spotting the errors If you run into trouble, we've provided a number of hints to help you out (and a couple that are no help at all) There are also answers in the back of the book This is in contrast to real life, where there are no hints, and the answers aren't in the back of the book This book is dedicated to my wife, Chi Mui Wong If she hadn't taken CS101 and learned that she's not a programmer, this book wouldn't exist (although it's her instructor who's responsible for the first broken "Hello World" in this book) But the real dedication is to all those working programmers out there who labor day in and day out with complex, buggy, really rotten code and have to make sense of it Good luck and have fun [1] The word is "DOG." Part I: Programs Chapter List Chapter 1: In the Beginning Chapter 2: Starting Out on the Wrong Foot Chapter 3: One Character Wonders Chapter 4: Everyday Problems Chapter 5: C Code, C Code Break Chapter 6: Premature Breakage Chapter 7: Classes with No Class Chapter 8: Expert Confusion Chapter 9: Portage to Hell Chapter 10: A Few Working Programs Chapter 11: Threaded, Embedded — Dreaded Part II: Hints Part III: Answers Chapter 1: In the Beginning Overview In the beginning, there was the ENIAC Mark I One day an operator happened to notice that the machine was malfunctioning and traced the problem to a moth that had flown into the machine and gotten beaten to death by the relay contacts She removed the moth, taped it in the log book, and made a notation: "Found a bug in the system." Thus, the first computer bug [1] My introduction to computer bugs came long after this I wrote my first program at age 11 It was one assembly language instruction long The program added together + The result was The program was only one instruction long and it still had a bug in it This chapter contains a few "firsts": the first time I stayed up to 2:00 in the morning to locate a bug (Program 3), the first question on the first C programming test I administered (Program 2), and, of course, the first program in any programming book, "Hello World." Before the days of ATMs you had to go to the bank and manually make a deposit Usually you would use one of the preprinted deposit slips found in the back of your checkbook These came with your account number written in magnetic ink on the bottom of the slip If you ran out of slips, the bank would provide you with one It had no number written at the bottom, so when it was processed using the bank's automatic machinery, so the machine kicked it out and a clerk manually entered the account number A crook printed up his own version of the "generic" deposit slip It looked like the normal "generic" deposit slip, except that the crook's account number was printed in magnetic ink at the bottom He then went to the bank and slipped these slips into the bins holding the "generic" slips The scam worked this way: A customer entered the bank to make a deposit and got one of the doctored slips He filled it out and made a deposit Since the slip contains an account number, the computer automatically processed it and made a deposit into the account written on the bottom Ignored was the handwritten account number on the slip In other words, our crook was hijacking deposits A detective assigned to the case was baffled Deposits were disappearing and no one knew how He narrowed it down to deposits made in the bank He decided to try and make a large number of deposits and see what would happen Since he was using his own money, the deposits would have to be very small Very very small In fact they were for 6¢ each The detective spent a week making deposits He would go to the bank, fill out a slip, get in line, make a deposit for 6¢, fill out a new slip, get in line, make a deposit for 6¢, and so on The clerks thought he was crazy One day, one of his deposits disappeared So he had the bank search its records to see if anyone else had made a 6¢ deposit that day Someone had, and the crook was caught [1] Although people believe that this was the first use of the word bug in conjunction to computing machine it was not The term bug had been around for a long time before that to describe all sorts of machinery faults But why let the truth spoil a good story? Program 1: Hello World "Hello World" seems to be the first program in almost every programming book, and this is no different But this one is broken How can you break something as simple as "Hello World"? Take a look and see: /************************************************ * The "standard" hello world program * *************************************************/ #include void main(void) 7{ std::cout [...]... the string * 13 ************************************************/ 14 static int length( 15 const char string[] // String to check 16 ) 17 { 18 int index; // index into the string 19 20 /* 21 * Loop until we reach the 22 * end of string character 23 */ 24 for (index=0; string[index] != '\0';++index) 25 /* do nothing */ 26 27 return (index); 28 } 29 30 int main() 31 { 32 char line[100]; // Input line from... meteorologist to enter rainfall in inches Now these people were used to dealing with hundredths of inches so when you asked them how much rain fell today, they would say, "50" meaning 50/100 of an inch or half an inch However to enter this into the computer you had to type "0.50." One fellow forgot this and entered the rain for the day as "50." Now 50 inches is a lot of rain An awful lot of rain The computer... the table */ 10 11 for (index = 1; index ... programmer for 35 years He is the author of many bestselling computer books, including Practical C Programming and Practical C++ Programming (O'Reilly) How Not to Program in C++- 111 Broken Programs... Cataloguing -in- Publication Data Oualline, Steve How not to program in C++: 111 broken programs and working ones, or why does + = 5986? / Steve Oualline p cm Includes index ISBN 1-886411-95-6 C++. .. stayed up to 2:00 in the morning to locate a bug (Program 3), the first question on the first C programming test I administered (Program 2), and, of course, the first program in any programming book,