|
|
|
|
|
|
|
someone reading the program. Using the same identifier in several different contexts can lead to confusion or hard-to-detect errors. In general, it is wisest to create struct member names that are different from those in other struct types and that are different from non-struct variable names. |
|
|
|
|
|
|
|
|
Testing and Debugging Hints |
|
|
|
|
|
|
|
|
1. The declaration of a struct type must end with a semicolon. |
|
|
|
|
|
|
|
|
2. Be sure to specify the full member selector when referencing a component of a struct variable. |
|
|
|
|
|
|
|
|
3. When using arrays within structs or arrays of structs, be sure to attach the index to the array name when accessing individual components of the array. |
|
|
|
|
|
|
|
|
4. Process each member of a struct separately, except when assigning one struct variable to another (of the same type), passing the struct as a parameter, or returning the struct as a function return value. |
|
|
|
|
|
|
|
|
5. Be cautious about using the same member names in different struct types. It is allowed but may be confusing. |
|
|
|
|
|
|
|
|
6. Do not use anonymous struct types unless you have a special reason for doing so. |
|
|
|
|
|
|
|
|
The record is a data structure for grouping together heterogeneous datadata that are of different types. Individual components of a record are accessed by name rather than by relative position, as in an array. In C++, records are referred to as structures or as structs. We can use a struct variable to refer to the struct as a whole, or we can use a member selector to access any individual member (component) of the struct. Entire structs of the same type may be assigned directly to each other, passed as parameters, or returned as function return values. Comparison of structs, however, must be done member by member. Reading and writing of structs must also be done member by member. We can build quite complex structures made up of arrays of structs, where the components of the structs are themselves arrays and structs. |
|
|
|
|
|
|
|
|
The design of our algorithms and data structures must be done in parallel. At the top level of our design, we visualize the data structures as abstract objects, such as tables, lists, and entries. As we refine our design, we get more specific about data structure. Our tables take on shape; our entries become more concrete. When we reach the point in the design where a module must apply a specific algorithm to a data structure, we must determine the exact form that our data structure will take. |
|
|
|
|
|
|
|
|
Applying the top-down, defer-details principle to data structures is an example of data abstraction. The logical description of the data structure is at a higher level. The details of how the data structure is implemented are pushed down to a lower level. |
|
|
|
|
|