Steve Oualline - How Not to Program in C++: 111 Broken Programs and 3 Working Ones, or Why Does 2+2=5986

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; <

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

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 []? 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 "" 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.

[]The word is "DOG."

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. []

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 2 + 2. The result was 2. 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, "."

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.