C++ Annotations Version 4.0.0

Chapter 8: Classes having pointers to members

We're always interested in getting feedback. E-mail us if you like this guide, if you think that important material is omitted, if you encounter errors in the code examples or in the documentation, if you find any typos, or generally just if you feel like e-mailing. Mail to Frank Brokken or use an e-mail form. Please state the concerned document version, found in the title. If you're interested in a printable PostScript copy, use the form, or better yet, pick up your own copy by ftp from ftp.icce.rug.nl/pub/http.

Pointers in classes have been discussed in detail in section 5. As we have seen, when pointer data-members occur in classes, such classes deserve some special treatment.

By now it is well known how to treat pointer data members: constructors are used to initialize pointers, destructors are needed to free the memory pointed to by the pointer data members.

Furthermore, in classes having pointer data members copy constructors and overloaded assignment operators are normally needed as well.

However, in some situations we do not need a pointer to an object, but rather a pointer to members of an object. The realization of pointers to members of an object is the subject of this part of the C++ annotations.

8.1: Pointers to members: an example

Knowing how pointer to variables and objects are to be used does not intuitively lead to the concept of pointer to members. Even if the returntype and parametertypes of a memberfunction are taken into account, surprises are encountered. For example, consider the following class:

class String { public: ... char const *get() const; private: ... char const (*sp)() const; }; Within this class, it is not possible to define a char const (*sp)() const pointing to the get() member function of the String class.

One of the reasons why this doesn't work is that the variable sp has a global scope, while the memberfunction get() is defined within the String class. The fact that the variable sp is part of the String class is of no relevance. According to sp's definition, it points to a function outside of the class.

Consequently, in order to define a pointer to a member (either data or function, but usually a function) of a class, the scope of the pointer must be within the class' scope. Doing so, a pointer to a member of the class String can be defined as

char const (String::*sp)() const; So, due to the String:: prefix, sp is defined to be active only in the context of the class String. In this context, it is defined as a pointer to a const function, not expecting arguments, and returning a pointer to const chars.

8.2: Initializing pointers to members

 Pointers to members can be initialized to point to intended members. Such a pointer can be defined either inside or outside a member function.

Initializing or assigning an address to such a pointer does nothing but indicating which member the pointer will point to. However, member functions (except for the static member functions) can only be used when associated with an object of the member function's class. The same holds true for pointers to data members.

While it is allowed to initialize such a pointer outside of the class, it is not possible to access such a function without an associated object.

In the following example these characteristics are illustrated. First, a pointer is initialized to point to the function String::get(). In this case no String object is required.

Next, a String object is defined, and the string that is stored within the object is retrieved through the pointer, and not directly by the function String::get(). Note that the pointer is a variable existing outside of the class' context. This presents no problem, as the actual object to be used is identified by the statement in which object and pointervariable are combined. Consider the following piece of code:

void fun() { char const (String::*sp)() const; sp = String::get; // assign the address // of String's get() // function String // define a String object s("Hello world"), cout << (s.*sp)() // show the string << endl; String *ps; // pointer to a String object ps = &s; // initialize ps to point at s cout << (ps->*sp)() // show the string again << endl; } Note in this example the statement (s.*sp)(). The .* construction indicates that sp is a pointer to a member function. Since the pointer variable sp points to the String::get() function, this function is now called, producing the string ``hello world''.

Furthermore, note the parentheses around (s.*sp). These parentheses are required. If they were omitted, then the default interpretation (now parenthesized for further emphasis) would be s.* (sp()). This latter construction means

Not an impossible or unlikely construction, but wrong as far as the current definition of sp is concerned.

When a pointer to a member function is associated with an object, the pointer to member selector operator .* is used. When a pointer to an object is used (instead of the object itself) the ``pointer to member through a pointer to a class object'' operator ->* operator is required. The use of this operator is also illustrated in the above example.

8.3: Pointers to static members

 Static members of a class exist without an object of their class. In other words, they can exist outside of any object of their class.

When these static members are public, they can be accessed in a `stand-alone' fashion.

Assume that the String class also has a public static member function int n_strings(), returning the number of string objects created so far. Then, without using any String object the function String::n_strings() may be called:

void fun() { cout << String::n_strings() << endl; } Since pointers to members are always associated with an object, the use of a pointer to a memberfunction would nomally produce an error. However, static members are actually global variables or functions, bound to their class.

Public static members can be treated as globally accessible functions and data. Private static members, on the other hand, can be accessed only from within the context of their class: they can only be accessed from inside the member functions of their class.

Since static members have no particular link with objects of their class, but look a lot like global functions, a pointer variable that is not part of the class of the member function must be used.

Consequently, a variable int (*pfi)() can be used to point to the static memberfunction int String::n_strings(), even though int (*pfi)() has nothing in common with the class String. This is illustrated in the next example:

void fun() { int (*pfi)(); pfi = String::n_strings; // address of the static memberfunction cout << pfi() << endl; // print the value produced by // String::n_strings() }

8.4: Using pointers to members for real

 Let's assume that a database is created in which information about persons is stored. Name, street names, city names, house numbers, birthdays, etc. are collected in objects of the class Person, which are, in turn, stored in a class Person_dbase. Partial interfaces of these classes could be designed as follows: class Date; class Person() { public: ... char const *get_name() const; Date const &birthdate() const; private: ... }; class Person_dbase { public: enum Listtype { list_by_name, list_by_birthday, }; void list(Listtype type); private: Person *pp; // pointer to the info unsigned n; // number of persons stored. }; The organisation of Person and Person_dbase is pictured in figure 5: Withing a Person_dbase object the Person objects are stored. They can be reached via the pointer variable Person *pp.

figure 5 is shown here.
figure 5: Person_dbase objects: Persons reached via Person *pp

We would like to develop the function Person_dbase::list() in such a way that it lists the contents of the database sorted according to a selected field of a Person object.

So, when list() is called to list the database sorted by names, the database of Person objects is first sorted by names, and is then listed.

Alternatively, when list() is called to list the database sorted by birthdates, the database of Person objects is first sorted by birthdates, and is then listed.

In this situation, the function qsort() is most likely called to do de actual sorting of the Person objects ( In the current implementation pp points to an array of Person objects. In this implementation, the function qsort() will have to copy the actual Person objects again and again, which may be rather inefficient when the Person objects become large. Under an alternative implementation, in which the Person objects are reached through pointers, the efficiency of the qsort() function will be improved. In that case, the datamember pp will have to be declared as Person **pp.). This function requires a pointer to a compare function, comparing two elements of the array to be sorted. The prototype of this compare function is

int (*)(void const *, void const *)
However, when used with Person objects, the prototype of the compare() function should be
int (*)(Person const *, Person const *)
Somewhere a typecast will be required: either when calling qsort(), or within the compare() functions themselves. We will use the typecase when calling qsort(), using the following typedef to reduce the verbosity of the typecasts (a pointer to an integer function requiring two void pointers):
typedef int (*pif2vp)(void const *, void const *)

Next, the function list() could be developed according to the following setup:

void Person_dbase::list(Listtype type) { switch (type) { case list_by_name: qsort(pp, n, sizeof(Person), (pif2vp)cmpname); break; case list_by_birthday: qsort(pp, n, sizeof(Person), (pif2vp)cmpdate); break; } // list the sorted Person-database } There are several reasons why this setup is not particularly desirable:

Much of the complexity of list() function could be reduced by defining pointers to the compare-functions, storing these pointers in an array. Since this array will be common to all Person_dbase objects, it should be defined as a static array, containing the pointers to the compare-functions.

Before actually constructing this array, note that this approach requires the definition of as many compare functions as there are elements in the Listtype enum. So, to list the information sorted by name a function cmpname() is used, comparing the names stored in two Person objects, while a function cmpcity(), is used to compare cities. Somehow this seems to be redundant as well: we would like to use one function to compare strings, whatever their meanings. Comparable considerations hold true for other fields of information.

The compare functions, however, receive pointers to Person objects. Therefore, the data-members of the Person objects to which these pointers point can be accessed using the access-memberfunctions of the Person class. So, the compare functions can access these data-members as well, using the pointers to the Person objects.

Now note that the access memberfunctions that are used within a particular compare function can be hard-coded, by plainly mentioning the accessors to be used, and they can be selected indirectly, by using pointers to the accessors to be used.

This latter solution allows us to merge compare functions that use the same implementations, but use different accessors: By setting a pointer to the appropriate accessor function just before the compare function is called, one single compare function can be used to compare many different kinds of data stored inside Person objects.

The compare functions themselves are used within the context of the Person_dbase class, where they are passed to the qsort() function. The qsort() function, however, is a global function. Consequently, the compare functions can't be ordinary member functions of the class Person_dbase, but they must be static members of that class, so they can be passed to the qsort() function.

Summarizing what we've got so far, we see that the problem has been broken down as follows:

From this analysis the essential characteristics of the proposed implementation emerge.

For every type of listing, as produced by the function list(), the following is required:

This information does not depend on a particular Person_dbase object, but is common to all of these objects. Hence it will be stored compile-time in a static Person_dbase kind of array.

How will the compare() functions know which element of this array to use? The requested index is passed to the list() member function as a Listtype value. The list() function can then save this information in a static Person_dbase::Listtype variable for the compare() functions to use.

We've analyzed enough. Let's build it this way.

8.4.1: Pointers to members: an implementation