GIDNetwork > Archive: September, 2005
« August, 2005 October, 2005 »

GIDNetwork Archives

September, 2005

Things to Avoid in C/C++ -- scanf / number, Part 8

by: WaltP September 28, 2005 13:03:25

scanf() / Reading a number

This is where scanf() actually doesn't do a bad job. Not great, but not bad either. What it does right is read the entire value. It ignores white space and new-lines too. What it does wrong is mess up if an illegal character is entered. But to be fair, it does tell you about it. Usually. Most programmers just don't listen.

Things to Avoid in C/C++ -- scanf / string, Part 7

by: WaltP September 27, 2005 09:12:37

scanf() / Reading a string

There is only one thing I really need to say about using scanf() to read a character string:

Things to Avoid in C/C++ -- scanf / character, Part 6

by: WaltP September 26, 2005 22:31:29

scanf() / Reading a character

Two of the biggest drawbacks to scanf() and reading a single character is:

Things to Avoid in C/C++ -- scanf, Part 5

by: WaltP September 21, 2005 10:40:53


Man, where to begin? scanf() is a notoriously ill-behaved function.

Things to Avoid in C/C++ -- system("pause"), Part 4

by: WaltP September 20, 2005 15:40:36


I've never understood why system("PAUSE") is so popular. Sure it will pause a program before it exits. This pause is very useful when your IDE won't wait as you test a program and as soon as the program finished the window closes taking all your data with it.

Things to Avoid in C/C++ -- feof(), Part 3

by: WaltP September 20, 2005 11:00:06

feof() to exit a loop

You should never use feof() as the exit indicator for a loop. feof() is TRUE only after the end of file (EOF) is read, not when EOF is reached. To test this, create a normal text file (mine is feof.fil):

Things to Avoid in C/C++ -- fflush(stdin), Part 2

by: WaltP September 18, 2005 11:39:31

fflush() to clear the input stream

You should never use fflush() to clear any input stream, including stdin. According to the C Standard:

Things to Avoid in C/C++ -- gets() , Part 1

by: WaltP September 14, 2005 11:05:55

C/C++ programmers are allowed to do some things they shouldn't. We are given functions that are supposed to be useful but aren't because of hidden faults, or taught ways to do things that are bad, wrong, not necessary. These posts will discuss many of these as time goes on.

The code in this collection of electronic bits is specifically written in C. I'm using the free Borland 5.5 compiler for the code. For any code that is designed to show the errors, your results may be a little different. But rest assured, the problem exists in many if not all compilers. And if most compilers show these anomalies, wouldn't you rather not use the feature even if it works on your current compiler?

Command Line Arguments, Part 3

by: WaltP September 8, 2005 10:56:22

Command Line Parameters as Switches

Design Considerations

Command Line Arguments, Part 2

by: WaltP September 5, 2005 20:26:46

Single Characters as Command Line Parameters

A single character as a parameter, although not extremely useful, will give us a basis for later in this topic.

Beginning Python Tutorial (Part 4)

by: crystalattice September 3, 2005 12:44:23

Python Lists

Lists in Python are one of the most versatile collection object types available. The other two types are dictionaries and tuples, but they are really more like variations of lists.

Command Line Arguments, Part 1

by: WaltP September 2, 2005 13:59:04

Getting Data Without Operator Input

Command line arguments are a great way get information into your console mode programs without the need for input statements in your code. They are also useful when tunning program from a batch (script) file.

« August, 2005 October, 2005 »


Copyright © GIDNetwork™ 2001 - 2014

Another website by J de Silva

Page generated in : 0.03710 sec.