# Like 0Likes Dislike Introduction to Pointers, Structures and Linked-Lists Part 7

structure functions return function constructor addressptr_t object oriented instance
Introduction to member functions

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.



{

AddressPtr_t Next();  <span class="codecomment">// Return instance of Next List Element</span>

AddressPtr_t Prev();  <span class="codecomment">// Return instance of Prev List Element</span>



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:



{

NextPtr = NULL;

PrevPtr = NULL;

}

{

}

{

<span class="codekeyword">if</span> (NextPtr) <span class="codekeyword">return</span> (NextPtr);

<span class="codekeyword">return</span> (NULL);

}

{

<span class="codekeyword">if</span> (PrevPtr) <span class="codekeyword">return</span> (PrevPtr);

<span class="codekeyword">return</span> (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:



{

{

NextPtr = NULL;

PrevPtr = NULL;

}

<span class="codecomment">// Return instance of Next List Element</span>

{

<span class="codekeyword">if</span> (NextPtr) <span class="codekeyword">return</span> (NextPtr);

<span class="codekeyword">return</span> (NULL);

}

<span class="codecomment">// Return instance of Prev List Element</span>

{

<span class="codekeyword">if</span> (PrevPtr) <span class="codekeyword">return</span> (PrevPtr);

<span class="codekeyword">return</span> (NULL);

}



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)

Author: Chris Bennett aka Dwarfsoft
Contact: dwarfsoft@hotmail.com
April 17, 2001