Socket++, by Gnanasekaran Swaminathan (Centreville, VA), is an iostream-like class for UNIX and inet sockets, pipes, and socket-pairs. Socket++ classes can be used more effectively than directly calling the underlying low-level system functions. Since Socket++ has the same interface as the LibG++ iostream (i.e. like cout and cin), it automatically performs type-safe input and output.

Socket++ provides the following classes:

• sockbuf Class:: — Socket streambuf class.
• sockAddr Class:: — Base class for socket addresses.
• sockinetbuf Class:: — Socket class for INET address family.
• sockinetaddr Class:: — Address class for INET address family of sockets.
• sockunixbuf Class:: — Socket class for UNIX address family.
• sockunixaddr Class:: — Address class for UNIX address family of sockets.
• sockstream Classes:: — /O socket stream classes
• pipestream Classes:: — I/O stream classes that provides pipe, socketpair, and popen facilities.

Socket++ runs on many UNIX platforms including Sun Sparc, IBM RS/6000, DECstation, and SGI Indigo boxes. Socket++ version 1.4, released on 13-Jun-93, is now available as CUG Library volume #400.

Problem definition takes place within three predefined files named setup.c, fitness. c, and prob.h. Specifically, setup.c contains a function table and the functions it references as well as the terminals table. Next, prob.h must contain prototypes for the user-defined functions. Last, fitness.c contains functions to evaluate and validate populations and trees, and to perform early termination, as well as the definition of the fitness (training and test) cases. Since each problem uses the same filenames, you'll need to have a separate subdirectory for each problem. SGPC includes an example set to solve Koza's simple regression problem and the ADF problem with a simple 2-class dendritic classifier.

For a complete description of genetic methods see Genetic Programming by John R. Koza, MIT Press, 1992. For other reading, Tackett delivered a paper entitled "Genetic Programming for Feature Discovery and Image Discrimination" for "Genetic_Algorithms: Proceedings of the Fifth International Conference" (GA93), S. Forrest Ed., Morgan-Kaufman 1993.

A CForm application consists of modules containing "pictures" to handle the various functions in the application. A picture in turn consists of fields and text literals describing the appearance. Fields are named regions of the screen used for input and output. Fields have attributes for type, size, and event-handling functions. Before creating a picture, you must first create a viewport. A viewport describes the width, height, and position on the real screen where the picture will appear.

You may specify field positions in absolute or relative coordinates. Alternately, you may ask to "center" on a particular row or column or use "max" to place it on the furthest row or column. CForms fields can be either numeric, character, or alphanumeric. Last, a field can have any combination of the following modifiers: protected (read-only), forbidden, uppercase, highlighted, and invisible.

CForms shows its flexibility and ease of operation best in its event handling. Each field can have special handling for any of the following events: key, refresh, draw, left, entry, and exit. CForms includes a library of more than 30 functions for handling the most common types of event processing. For example, the function fld_ismodified will tell you if the user actually changed anything.

The key event allows you to intercept each keypress as the user types along in the field. CForms supports an extremely extensive set of keys including function keys, editing keys, numeric keypad function keys (e.g. SUN), and special purpose keys (e.g. HELP key). Many keys have separate shift-state identifications (e.g. shift-delete-char). However, control keys and alt keys are not supported.