Issue #012
June, 1996


Contents:

New Language Feature - Mutable
Introduction to Templates Part 4 - Specializations
Using C++ as a Better C Part 12 - Function Parameter Names
Performance - Duplicate Inlines


NEW LANGUAGE FEATURE - MUTABLE

In C++ it's possible to have a class object instance that is constant
and cannot be modified by the program, once initially set up.  For
example:

        class A {
        public:
                int x;
                A();
        };

        const A a;

        void g()
        {
                a.x = 37;
        }

is illegal.  In a similar way, invoking a non-const member function on
a const object is also illegal:

        class A {
        public:
                int x;
                A();
                void f();
        };

        const A a;

        void g()
        {
                a.f();
        }

The reason for this latter prohibition is due to separate
compilation.  A::f() may be defined in some other translation unit,
and there's no way of knowing whether it modifies the object upon
which it operates.

It is possible to define const member functions:

        void f() const;

that are allowed to operate on a const object instance.  Such a
function does not modify the instance it operates on.  The type of the
"this" pointer for a class T is normally:

        T *const this;

meaning that the pointer cannot be changed.  Within a const member
function, the type is:

        const T *const this;

meaning that neither the pointer nor the pointed-at object instance
can be modified.

Recently a new feature has been added to C++ to selectively allow for
individual data class members to be modified even for a const object
instance, and lessen the need for casting away of const.  For example:

        class A {
        public:
                mutable int x;
                A();
        };

        const A a;

        void f()
        {
                a.x = 37;
        }

This says that "x" can be modified even though it's a member of a
const object instance.

How useful "mutable" turns out to be remains to be seen.  One cited
example for its use is within classes whose object instances appear
constant but actually do change their state internally.  For example:

        class Box {
                double xll, yll;        // lower left X,Y
                double xur, yur;        // upper right X,Y
                double a;               // cached area
        public:
                double area() const
                {
                        a = (xur - xll) * (yur - yll);
                        return a;
                }
                class Box(double x1, double y1, double x2, double y2) :
                    xll(x1), yll(y1), xur(x2), yur(y2)
                {
                }
        };

        const Box b(1.0, 1.0, 11.0, 14.0);

        void f()
        {
                b.area();
        }

which is illegal usage unless we instead say:

        class Box {
                double xll, yll;        // lower left X,Y
                double xur, yur;        // upper right X,Y
                mutable double a;       // cached area
        public:
                double area() const
                {
                        a = (xur - xll) * (yur - yll);
                        return a;
                }
                class Box(double x1, double y1, double x2, double y2) :
                    xll(x1), yll(y1), xur(x2), yur(y2)
                {
                }
        };

        const Box b(1.0, 1.0, 11.0, 14.0);

        void f()
        {
                b.area();
        }


INTRODUCTION TO TEMPLATES PART 4 - SPECIALIZATIONS

In previous issues we've covered some of the basics of C++ templates.
Recall that a template is a class or function skeleton, and is
combined with specified type arguments to produce an actual class or
function.

Beyond this general mechanism, C++ also allows the programmer to
define specialized classes and functions that take the template and
implement it for particular types of template arguments.

Suppose, for example, that you have a String template, that supports
strings of most anything -- chars, ints, doubles, arbitrary class
types, and so on.  Now, it's pretty likely that strings of characters
will be used heavily, so it might make sense to special case this
combination of template and template argument:

        template <class T> class String {
                // stuff
        };

        template <> class String<char> {
                // stuff
        };

        String<char> x;

The "template <>" notation is fairly new and may not yet be
implemented in your local compiler.

This sequence is a bit different from:

        template <class T> class String {
                // stuff
        };

        String<char> x;

In this second case, the default implementation of String is used,
whereas in the specialization case, the programmer overrides the
default template and provides an implementation of String<char>.

For a function template, a specialization would be defined as:

        template <class T> void f(T) {}

        template <> void f(int) {}

It's also possible to have forward declarations of specializations:

        template <class T> class String {};

        template <> class String<double>;

or:

        template <class T> void f(T) {}

        template <> void f(unsigned short&);

A specialization must be declared or defined before use, so for
example:

        template <class T> int f(T) {return 0;}

        int i = f(12.34);

        template <> int f(double) {return 37;}

is invalid.

An interesting quirk with function templates concerns the case where
you have a C function, mixed in with a function template and
specialization:

        extern "C" void f(int);

        template <class T> int f(T) {return 0;}

        template <> int f(int)
        {
                f(37);
                return 0;
        }

The f(37) call here is not recursive.  Both "void f(int)" and "int
f(int)" match the call, and the non-template is preferred in such a
case.

It's also possible to have nested specializations, as in:

        template <class T> class A {
                template <class U> class B {
                        template <class V> void f(V) {}
                };
        };

        template <> template <> template <>
                void A<float>::B<double>::f(long double) {}

and you can specialize special member types such as constructors:

        struct A {
                template <class T> A(T) {}
        };

        template <> A::A(short) {}

or static data members:

        template <class T> struct A {
                template <class U> struct B {
                        static int x;
                };
        };

        template <> template <> int A<float>::B<long double>::x = 59;

Specializations are a way of special-casing templates for particular
argument types, and are useful in a variety of applications.  But they
can also be abused and make code harder to understand, especially if a
reader of the code doesn't pick up on the fact that specializations
are present.


USING C++ AS A BETTER C PART 12 - FUNCTION PARAMETER NAMES

Suppose that you have a C++ function, and for some reason you don't
actually use all the function parameters:

        int sum(int a, int b, int c)
        {
                return a + b;   // c not used
        }

Many compilers will give a warning in this case to the effect
"warning: parameter c not used".  This is perfectly legal code but the
warning can be tedious to deal with.

C++ has a feature that allows you to simply omit the parameter name:

        int sum(int a, int b, int)
        {
                return a + b;
        }

and avoid the warning.  This feature is especially handy when stubbing
out code.  A similar feature exists in catch handlers used in
exception handling.


PERFORMANCE - DUPLICATE INLINES

Suppose that you have a bit of code such as:

        inline long fact(long n)
        {
                if (n < 2)
                        return 1;
                else
                        return n * fact(n - 1);
        }

        int main()
        {
                long x = fact(23);

                return 0;
        }

to compute the factorial function via a recursive algorithm.  Will
fact() actually be expanded as an inline?  In many compilers, the
answer is no.  The "inline" keyword is simply a hint to the compiler,
which is free to ignore it.

So what happens if the inline function is not expanded as inline?  The
answer varies from compiler to compiler.  The traditional approach is
to lay down a static copy of the function body, one copy for each
translation unit where the inline function is used, and with such
copies persisting throughout the linking phase and showing up in the
executable image.  Other approaches lay down a provisional copy per
translation unit, but with a smart linker to merge the copies.

Extra copies of functions in the executable can be quite wasteful of
space.  How do you avoid the problem?  One way is to use inlines
sparingly at first, and then selectively enable inlining based on
program profiling that you've done.  Just because a function is small,
with a high call overhead at each invocation, doesn't necessarily mean
that it should be inline.  For example, the function may be called
only rarely, and inlining might not make any difference to the total
program execution time.

Another approach diagnoses the problem after the fact.  For example,
here's a simple script that finds duplicate inlines on UNIX systems:

        #!/bin/sh

        nm $@ |
        egrep ' t ' |
        awk '{print $3}' |
        sort |
        uniq -c |
        sort -nr |
        awk '$1 > = 2{print}' |
        demangle

nm is a tool for dumping the symbol tables of objects or executables.
A " t " indicates a static text (function) symbol.  A list of such
symbols is formed and those with a count of 2 or more filtered out and
displayed after demangling their C++ names ("demangle" has various
names on different systems).

This technique is simply illustrative and not guaranteed to work on
every system.

Note also that some libraries, such as the Standard Template Library,
rely heavily on inlining.  STL is distributed as a set of header
files containing inline templates, with the idea being that the
inlines are expanded per translation unit.

Much of the time such an approach is perfectly acceptable, but it's
worth at least knowing what's going on behind the scenes with
inlining, and what you can do about it if performance is not
acceptable.


ACKNOWLEDGEMENTS

Thanks to Nathan Myers, Eric Nagler, David Nelson, Terry Rudd,
Jonathan Schilling, and Clay Wilson for help with proofreading.


SUBSCRIPTION INFORMATION / BACK ISSUES

To subscribe to the newsletter, send mail to majordomo@world.std.com
with this line as its message body:

subscribe c_plus_plus

Back issues are available via FTP from:

        rmii.com /pub2/glenm/newslett

or on the Web at:

        http://www.rmii.com/~glenm

There is also a Java newsletter.  To subscribe to it, say:

subscribe java_letter

using the same majordomo@world.std.com address.

-------------------------

Copyright (c) 1996 Glen McCluskey.  All Rights Reserved.

This newsletter may be further distributed provided that it is copied
in its entirety, including the newsletter number at the top and the
copyright and contact information at the bottom.

Glen McCluskey & Associates
Professional C++ Consulting
Internet: glenm@glenmccl.com
Phone: (800) 722-1613 or (970) 490-2462
Fax: (970) 490-2463
FTP: rmii.com /pub2/glenm/newslett (for back issues)
Web: http://www.rmii.com/~glenm