Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Like
0Likes
Dislike

Introduction to Pointers, Structures and Linked-Lists Part 8

By Chris Bennett aka Dwarfsoft | Published Sep 30 2004 04:45 AM in General Programming

class data functions access member protected allow private list
If you find this article contains errors or problems rendering it unreadable (missing images or files, mangled code, improper text formatting, etc) please contact the editor so corrections can be made. Thank you for helping us improve this resource



This is just a short article that will help with the small but easy transition from structures to classes. There is very little difference between a class and a struct, and the differences I will
not cover in this article until the "Inheritance" and "Polymorphism" articles. Here I will just go through the definition of a class (as copied from the MSDN library, the Microsoft Visual C++
definition of a class):



<span class="codekeyword">class</span> [<i>tag</i> [: <i>base-list</i> ]]

{

    <i>member-list</i>

} [<i>declarators</i>];

[ <span class="codekeyword">class</span> ]<i> tag declarators</i>;


Well, what does this syntax tell us about how we define a class? Let us stroll through what each part of the class definition process is:








 What this means:
classis the type that we are specifying, this works exactly the same as a struct or a union would work.
tagis an identifier so that we can create more instances of our class.
base-lista list of classes that this class inherits
member-lista list of member functions and data that this class uses
declarators  declarators are an instance of the class, and are a usable variable. Eg: The declarator in the expression "int i;" is i

I will go into inheritance later, so we can ignore the base-list part. The member-list stuff we have already seen in our struct's as they are the data and
functions that can be used to all the ends of our requirements. One thing that I never covered in the previous article on Member functions was the public,
private and protected access modifiers. Quite simply, they are seperators that you place throughout your class or structure
that allow data flow only where you allow it.


Here is an example: If you have our linked list that was defined in previously featured articles, and left them as they are, but allowed users (or third-party programmers) direct access through
the way the linked list was set up, then they would be able to point our Next and Previous pointers to whatever they wanted to. Code that allows anybody to do this is bad code, and dangerous code.
The program is likely to crash because it is pointing to some obscure memory address, or it could even crash your computer by overwriting some important data in memory unknowingly.


I will not go into the details of data hiding at the moment (I will save that for my proposed next article, "Class Design") but I will breifly describe what the modifiers mean to us.











Access Modifier   Action
public In this section we allow anybody and everybody to call the functions, or allows access to the variables that are listed (not recommended for everything)
private Only the class itself and friends of the class have access to this, but we will avoid talking about function friends for now. This is where it is recommended that you
store all class member variables.
protected Protected functions and data can be accessed by derived classes without the need for a specific friend declaration. This is where you put data for sharing information
which is useful, but users will not need to know about.

Mostly we store our member variables in the private section, and our interface functions (the functions that allow the users certain minimal access to data and how they may manipulate it) will be
in the public section. There are occassions where private or protected functions will be created that aid our other class members, but are either too likely to be misused by the user or are of little
use to the interface of the class.


Cheers, Chris (a.k.a. Dwarfsoft)


Author: Chris Bennett aka Dwarfsoft
Contact: dwarfsoft@hotmail.com
February 24th, 2002
© Copyright Chris Bennett, 2002








Comments

Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.




PARTNERS