In last week's column, we studied the rule of identity. We saw several ways in which identity is implemented, including relational database keys, file paths, and -- most significantly -- pointers.

Think back to the introduction of Pascal and C. Those languages quickly overtook FORTRAN and COBOL as the standards for application development. They did so because they offered two major advancements: structured programming (see sidebar) and pointers. The addition of pointers is what made those languages so powerful.

For the first time, a high-level language permitted us to implement linked lists, binary trees, heaps, and other dynamic structures. Furthermore, it allowed us to represent those abstract data types with ease, type safety, and clarity of code. Pointers allowed us to traverse complex data structures with loops or recursive functions. They made it easier for producers and consumers of data to communicate. All of that was possible because the pointer is a natural implementation of the rule of identity.

Natural implementation

The rule of identity states that every object has unique identity independent of state. Every pointer is unique by virtue of the fact that no two objects can occupy the same memory. The rule also states that all clients accessing the same object can expect uniform behavior. Since a memory location may be in only one state at a time, pointers follow that clause implicitly.

Location independence was not an issue when Pascal and C first appeared, as applications were machine-centric. So pointers implemented identity quite naturally.

Problems with pointers

Having said all that, let me emphasize that pointers are not synonymous with identity. In some cases in which identity is required, pointers are insufficient, as we will discuss when we get into location independence. In others in which identity is not called for, pointers can accomplish other goals, as we will find when we examine the state pattern.

The following example illustrates that better than any words can.

Suppose that the class CMatrix represents a real-valued square matrix such as those used to solve systems of linear equations. One would expect, when using that class, to express the matrix multiplication in code as follows:

  CMatrix a, b, c;

  // ... Fill in a and b. ...

  c =a*b;

To support that syntax, we write a multiplication operator that returns a CMatrix object:

  CMatrix CMatrix::operator *(const CMatrix &that)

  {

      CMatrix result;

      // ... Multiply "this" and "that" into "result". ...

      return result;

  }

Can you spot the problem in the above code? It is not a bug, per se, but it is something that your users will complain about. We will discuss the problem next week, and discover what pointers and identity have to do with its solution.

» posted by abennett

ITworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine