Week 7 - Chapter 10 - Strings and Files

Theory

Debugging Methods

This chapter doesn't hit to hard on debugging methods, but it's worth our time to discuss some various approaches to debugging.

Compile it, Run it, see if it works. This method is, unfortunately, very popular. The idea here is that if there are no obvious errors, it must be jes' fine.
Put in print statements at strategic locations. This is a much better approach than the former. Basically, when a variable or flow of execution should change, you print something to the screen, usually the value of a variable or two. Sometimes, this approach is the only choice you have, like when you don't have a good debugger you can use, or when your program is time-critical and cannot be interrupted.
Step through every line in the program. This is the best way to debug a program. Having the ability and the turptitude to step through each and every line, keeping a close eye on the values of variables as you go, is the best approach you can take. Not only will it show you exactly what your program is doing, but it will teach you a lot about the language you are working in (i.e. operator precedence) and the compiler you are using (i.e. bugs it might have). Sometimes, you cannot easily do this, however.

Approaches to String Handling

Different programming languages take different approaches to strings.

No String Support - There is no easy way for dealing with strings. This is the case with some assembly languages and some very special-purpose scripting languages. It is rare to have no support for strings.
Strings As Arrays - This is a common approach, used in C, Pascal, and Ada. With this approach, you support a 'charater' type as a primitive and treat a string as a sequence of these (which is fairly intuative, from a programmer's point of view). This approach can be a little awkward, because you need to keep tabs on things like the length of your strings, managing the memory by hand if strings need to grow, etc. It helps (a lot) if you have a library of string routines that make life easier (such as the string.h library in C).
Strings As Native Types - Here, we treat strings as a "primitive" type with built-in support for strings in the language and numerous operators and string-manipulation functions. With this approach, you don't have to keep track of how big strings are or managing the memory they consume because this is all done for you by the language. This is the nicest approach, IMO, because it means we can be more lazy as programmers. :-) Perl, Python, Tcl, Bash, and numerous other scripting languages support strings as a native type.

Please note that few languages are "pure" in their approach to strings. Typically in a given language, strings can be dealt with at various different levels and there will likely be some niceities and some unpleasantness.

Ada Stuff for Chapter 10

Strings

String discussion begins on p. 429. A short list of the basic Ada String principles is found on p. 430.

Strings Are Arrays: (p. 430) A string is an array of characters and is declared as such. Individual characters can be referenced just like individual elements in an array. See p. 430. Note that a one-character string IS NOT the same as a Character variable. (strongly typed! -- see p. 431)

Assignment: (p. 432) You just use the := operator. Note that the two strings you are using in the assignment statement must be identical; they must both be exactly the same length. (strongly typed!)

Equivalence: (p.432) You use the = operator. As with assignment, the two strings must be identical length. Note that this does a "deep" character-by-character equivalence test.

Smarter String I/0: (p. 433) When you first learned about reading strings from stdin in chapter 3, you discovered that it was just a wee bit brain-dead with how it read them; you had to "pad" spaces until the end of the string if the text you entered was less than the length of the string.

To your great, good fortune, there is a function called Get_Line (p.433) which makes this process much more sensible: It reads until you enter a return, tells you how many characters it read, and stores those characters in a string, padding til the end for you. Much nicer. Syntax Summary p. 435.

String Slices: (p. 435) To slice a string means to extract a part of it. The way string slicing works in Ada is actually quite nice. See p. 435-436 for details. Basically, you use array notation with the list constructor (..) to specify a slice of a string. Note that this is also how you print a part of the string to stdout.

Concatenation: (p. 436) Long story short: You use the '&' operator. This is just like most flavors of BASIC. P. 436 has an example.

Feel free to blithely ignore everything the book has to say regarding mapping / translating. It's kind of interesting, but we don't need ot go into it too much.

Bounded / Unbounded Strings: (p. 443) The designers of Ada, in their infinite wisdom, realized that sometimes it's handy to be able to have variable-sized strings and not have to worry about them too much.

Files

In keeping with a long-standing UNIX tradition, files in Ada are treated as a "stream" of free-flowing text. This is good news because you can use the same Ada.Text_IO package and assorted functions that you've already been using. There are some overloaded Get() and Put() functions which take the typical Item => parameter, but have an additional File => parameter that takes an Ada.Text_IO.File_Type parameter. What a deal.

Package Specification: is on p. 444-446.

STDIN / STDOUT: is on p. 447 in the section "The Keyboard and the Screen as Text Files".

EOL / EOF: is at the bottom of p. 447. There is no BOL / BOF. Syntax Summary p. 448-449.

The code at the top of p. 448 shows a little hunklet of code that you can use to process a file one character at a time. (I hafta wonder why they didn't use WHILE loops...)

For the typicall life cycle of a file operation, see pages 449-451. It shows how you declare, open, read, write and close a file. The example "Copy" program which follows on p. 451 is likewise instructive.

Getting Input From Strings: (p. 459) Files are not the only way to read input. You can also treat a string as a file. The code / explanation on p. 459 shows how you can parse a string to read values from it. This is somewhat akin to sscanf in C.

Command-Line Parameters

Many UNIX programs make heavy use of command-line parameters to affect the output displayed or the execution performed. Examples of this include the ls, ps, and tar programs. In fact, there are very few exceptions. (Aside: for an example of this approach gone berzerk, do a 'man gcc', a 'man indent', or a 'man ls' someday.)

To everyone's good fortune, Ada also provides facilities for retrieving command-line parameters in the package Ada.Command_Line. See pages 460-461 for the details and an example program.

Assignment 6

Write a program which does the following things:

Open the file /usr/dict/words. This is a file that contains a list of words, one word per line. It's used for spell-checking and word look-up purposes.
Read the contents of the file one line at a time.
Determine the length of the word it read, and store that information.
After you're done reading the file, close it, and display to stdout, the number of 1 character words, 2 character words, 3 character words, and so forth up to the largest length word.

Output should look like this:

	1 char words: 4
	2 char words: 10
	3 char words: 51
	...
	(you get the idea)

Hints: You need to use a String variable, a File_Type variable and its associated functions, an array of Integers (or even 'Positive's), and a FOR loop or two. Additional hint: The longest word in /usr/dict/words is 28 characters long. Plan accordingly. (Alternatively, you might look at using an Unounded_String, up to you.)

'Nother Hint: You might find the sample code on pgs. 462-464 helpful.

Note: If you do your programming at home and then ftp your assignments up to the Zonker server, feel free to download the /usr/dict/words file to your home machine while you're writing your program. You do it using the same ftp commands you learned at the beginning of the semester, only you type 'get' instead of 'put'. We can go over this in class if anyone doesn't get it.

This assignment is due on October 31st, 2001, the night of the second exam.