Introduction to Pointers, Structures and Linked-Lists Part 7

Introduction to Pointers, Structures and Linked-Lists Part 7
Introduction to Member Functions
by Chris Bennett aka Dwarfsoft

Well, now that we have all of these many linked list functions in everybody's favourite form of programming (procedural) what are we going to do? My suggestion is to throw you into the deep end of Object Oriented Programming (OOP). Despite a lot of misinformation about OOP the objects that are used in any Object Oriented (OO) language DO NOT need to be visual. Also, to put a lot more misinformation to rest, you should know that Visual Basic 4 and lower were NOT OO (I am still unaware of 5 and 6, but it looks like Microsoft is trying to emulate OO for VB).

Object Oriented Programming is the art of describing programming structures and elements in a way that is understandable as a real world object. Structures defined in this way can be used together in inheritance and other wonderful ways. C++ is not an entirely Object Oriented Language, as you are required to make procedural calls (i.e., your main () function) before you can make use of the Object Oriented aspects. There are some entirely Object Oriented languages out there (Eiffel, Java and SmallTalk to name a few) but we will stay right in the heart of the programming industry with C++.

Well, it isn't totally OO, and it won't really be the 'deep end' but I hope this will give you a little introduction to the OO side of programming. It is possible to use our knowledge of struct's to get some Object Oriented background, so I think I will do some introductory work. There are some extra things that you can add to a structure other than data elements. It is possible to have structure members such as functions. These functions are not handled as pointers (I will cover function pointers later) but they are stored globally for use by all instances of a single type of structure. Every structure of a certain instance is able to address the function, but the function can not be specifically called. Here is an example of a structure with member functions.

typedef struct strAddress *AddressPtr_t;
typedef struct strAddress
{
    strAddress();     // Constructor
    ~strAddress();      // Destructor
    AddressPtr_t Next();  // Return instance of Next List Element
    AddressPtr_t Prev();  // Return instance of Prev List Element
    AddressPtr_t NextPtr,PrevPtr;
}Address_t;

This is very similar to previous definitions of structures. The actual functions that are listed in this definition are not included, but they could be. I will come back to such member functions later. For the moment I will do a little explanation on the Constructor and Destructor.

A Constructor is a function that is called on the initialisation of a new instance of a certain type. In English, this means that once you create a new variable of type Address_t the strAddress() constructor is called. You can specifically call the constructor function with your created Address_t variable, and I will show you how to do so later. Similarly to the constructor, the Destructor is a member function that is called on the, wait for it, destruction of the variable. This happens when the program finishes, or if an instance to the structure is freed, or if a local reference to a structure is ended with (the function which the local variable was initialised in ends). The Constructor and Destructor must have the SAME NAME as the structure. The difference between the two is that the Destructor MUST HAVE a tilde (~) before its name. See the code above for an example.

Now that we have seen how to initialise a structure with member functions, we can continue on and see how to actually write those functions:

strAddress::strAddress()
{
  NextPtr = NULL;
  PrevPtr = NULL;
}

strAddress::~strAddress()
{
}

AddressPtr_t strAddress::Next()
{
  if (NextPtr) return (NextPtr);
  return (NULL);
}

AddressPtr_t strAddress::Prev()
{
  if (PrevPtr) return (PrevPtr);
  return (NULL);
}

It becomes obvious here that before the actual function name, the structure name (or scope) must be put. The '::' is known as the scope resolution operator. There are other uses of the scope resolution operator, but in this particular case it is to refine the functions to be part of the scope of the structure. This is using the scope resolution operator to localise or refine the scope, where it can also be used to generalise or expand the scope. I will not cover the generalisation aspect until at least a 'last tidbits' section if at all.

Automatically in the Prev() and Next() functions the scope has been refined to the structure. This means that when they are accessing NextPtr and PrevPtr they will not be accessing anything other than that which is in the structure unless it has been defined in their local function.

We can see that the destructor doesn't do anything. This means that its definition here is redundant, so it doesn't need to have been initialised at all. What is more, the functions themselves are very short. The structure could have been initialised like this:

typedef struct strAddress *AddressPtr_t;
typedef struct strAddress
{
  strAddress()      // Constructor
  {
    NextPtr = NULL;
    PrevPtr = NULL;
  }

  // Return instance of Next List Element
  AddressPtr_t strAddress::Next()
  {
    if (NextPtr) return (NextPtr);
    return (NULL);
  }

  // Return instance of Prev List Element
  AddressPtr_t strAddress::Prev()
  {
    if (PrevPtr) return (PrevPtr);
    return (NULL);
  }

  AddressPtr_t NextPtr,PrevPtr;
}Address_t;

I severely dislike doing this at all. It really becomes messy, but it sometimes can be useful if all your function is doing is returning a single value (this wont become apparent until we reach classes).

There you have member functions. So what are they for? Basically, member functions are there to do any of the grunt work that is associated with its particular structure. It is used only for that structure but later on when we discuss inheritance you will see how they can help save time. Before we can get to inheritance, we must see classes. That is where I wish to go for the next article. Keep posted.

Cheers, Chris Bennett (aka. Dwarfsoft)

Discuss this article in the forums

Date this article was posted to GameDev.net: 9/30/2004
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
General