Thông tin tài liệu
How Not to Program in C++: 111 Broken Programs and 3 Working Ones, or Why Does 2+2=5986 ISBN:1886411956 by Steve Oualline 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 3 Working Ones, or Why Does 2 + 2 = 5986? Introduction Part I - Programs Chapter 1 - In the Beginning Starting Out on the Chapter 2 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 Threaded, Embedded — Chapter 11 - 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 3 Working Ones, or Why Does 2 + 2 = 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 1 2 3 4 5 6 7 8 9 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 3 working ones, or why d / Steve Oualline p cm Includes index ISBN 1-886411-95-6 C++ (Computer programming language) 2 Error analysis (Mathematics) 3 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 do 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 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, 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 three uninitialized local variables No wonder we get a strange result Answer 95: The problem is the statement: 24 sscanf(line, "%c %d", oper, value); The sscanf function takes pointers as its arguments (Remember C doesn't check arguments for the correct type.) In this case, we gave sscanf a character and an integer We should have given it a pointer to a character and a pointer to an integer: 24 sscanf(line, "%c %d", &oper, &value); Answer 96: The program use raw I/O to do its work (using the read and write system calls) This program does one raw read and raw write for each character Operating calls are expensive, and this program uses 2 (one read and one write) per byte copied To speed up the program, cut down on the operating system calls This can be done two ways: Use the buffered I/O system by making the input and output fstreams instead of file descriptors Read and write more than one character at a time Answer 97: The problem is the statement: for (index = 0; string[index] != '\0'; ++index) /* do nothing */ return (index); There is no semicolon after the /* do nothing */ statement The return is part of the for statement The code should look like this after it is indented properly: for (index = 0; string[index] != '\0'; ++index) /* do nothing */ return (index); From this code section we can see that the first time through, the for loop index will be zero and the return taken That's why all the strings are of zero length What the programmer wanted was: for (index = 0; string[index] != '\0'; ++index) /* do nothing */; return (index); Answer 98: The problem is that class is allocated not by the C++ new operator, but instead uses the old style C malloc operator This creates the space for the class without calling the constructor Then just to add insult to injury, memset is called to zero the class result = (struct info *)malloc(sizeof(struct info)); memset(result, '\0', sizeof(result)); What the programmer should have written is: result = new info; Note The author first found this problem in a large library he was trying to debug Because of the large size of the library and the complexity of the mess, it took him a week to find the location of the malloc Answer 99: The statement: out_file
Ngày đăng: 26/03/2019, 17:13
Xem thêm:
