Declaration vs Definition

While a declaration may be repeated without an effect, there can typically be only one definition:

• For a variable, the definition entails the allocation of storage. Clearly this can be done only once
• For a function, the definition is the specification of the function body; again we can't have two of these
• For a class, the definition is the specification of the data members and member functions.

For illustrative purposes, we'll focus on a class named Simple with a single int data member named val, a default constructor, and a single member function name getVal.

Class Declarations and Definitions

Class Declarations

class Simple;

Class Definition

class Simple {
public:
	Simple(int val);
	int getVal();
private:
	int val;						// data members are part of class declaration
};			

• The data members are actually declarations; ni storage is allocated until an object of the class is actually instantiated
• The member functions are declared as well (no fnction bodies which would mean a definition
  • The question is where to place the function bodies; there are several variations.

Function Definitions within the Class Definition in the Header (.h) File

• Place the function definitions in the class declaration
  • this is similar to what we do in Java
  • it's rarely done for all the functions, but often done for the simple and small ones (for example get/set functions)

// Simple.h

class Simple {
public:
	Simple(int val) : val(val) {}		// outside val is data member; inside val is parameter
	int getVal() {return val;}		// inline function
private:
	int val;						// data members are part of class declaration
};			

The Issue with Definitions in a Header File

//simple.cpp

#include "simple.h"

…

simple_app.cpp

#include "simple.h"

This multiple-inclusion of the same header file occurs even within the same file … as an example, almost all applications use strings and thus would contain a #include <string>. Suppose the app also was using a set of custom string utility function (other than the ones included in the standard C++ string library. Those functions would take string arguments and as the function declarations in the corresponding header file (let's call it custom_string_utils would make reference to the string class type, it would need a #include in its header file:

// app.cpp

#include <string>
#include "custom_string_utils"

…

// custom_string_utils.h

#include <string>

void pretty_print(string s);
…

When the preprocessor exapands the source file, the header file string is included twice (once from the app's include and the other from the custom_string_utils' herader file's include.

If there were variable and function definitions in the header file they would trigger multiple-definition errors at link-time.

• Class definitions in and of themselves do not trigger such errors as they are type descriptions, not objects or function bodies
  • As long as the class definitions are identical (which would of course be the case if they all came from the same header file), there is no problem
• Inline functions have the same properly — as long as all the defs are identical (again, true since they come from the same class definitions in the same header file) all is good
• We will see below how to handle the situation where we don't want to place the function definition in the class definition (body)
  • There are several reasons for this:
    • avoid cluttering the class definition
    • desire to hide the details of the function body
  • We will also see that we will have to deal with templates in this context as well

Function Definitions Separated from the Class Declarations

• Separation of interface and implementation
• in this approach, the interface, i.e., the class definition consisting of member function declarations and data members, goes in the .h file, and the implementation, i.e., the member function definitions (function bodies) go in the .cpp file.
  • The issue then becomes that the body of a member function is not within class scope

// Simple.h (interface/header) file
class Simple {
public:
	Simple(int val);			// headers only
	int getVal();
private:
	int val;						// data members are part of class declaration
};			

//Simple.cpp (implementation/source) file

Simple::Simple() : val(val) {}
int Simple::getVal() {return val;}

• We introduce the Simple:: scope resolution operator to:
  • indicate this is a member function of the class and thus has access to data members
  • place the function body into class scope (as discussed above)

Mixtures of Non-inline and Inline Member Functions

• as mentioned above, short, simple functions are often coded inline (in the .h file), while the others are placed in the corresponding .cpp file
• if all functions are placed inline (the first approach), no .cpp file is necessary
  • Everything has been specified in the .h file
• there are times (e.g., templates, as we will see) when we have no choice but to have even relatively large and complex functions be inline; i.e., be visible together with the rest of the class definition)

  class Simple {
  public:
  	Simple(int val);			// headers only
  	int getVal();
  private:
  	int val;						// data members are part of class definition
  };			
  inline Simple::Simple() : val(val) {}
  inline int Simple::getVal() {return val;}
  		

  • rather than placing them in the class definition, we can put them in the .h file AFTER the class definition
  • the syntax requires a scope resolution operator (to have them be in the class scope) AND the inline keyword (so they don't trigger multiple-definition link errors).
    • in .h file

      class Simple {
      public:
      	Simple(int val);			// headers only
      	int getVal();
      private:
      	int val;						// data members are part of class declaration
      };			
      inline Simple::Simple() : val(val) {}
      inline int Simple::getVal() {return val;}
      						

    • the keyword inline is necessary since everything is going into the .h file (more on that later)

class Simple {
	…
	int val = 0;
};

static (Class) Members

• static data member and member functions have the same semantics as in Java — there is a single copy of a static data member for the class, and static member functions take no receiver (instead they are invoked with the class name and scope resolution operator, e.g. SomeClass::f()) and can only refer to the static data member of the class.
• the static keyword is used only in the class declaration, the subsequent definition does not contain static in the header.
• Unlike Java, data members in C++ cannot be initialized at the point of the declaration (pre-C++ 11)
  • (non-static) data members are typically initialized in the constructor
  • static data members are almost always initialized in the corresponding .cpp file

    // Simple.h
    
    class Simple {
    	…
    	static int nextId;
    	…
    };
    				

    // Simple.cpp
    
    int Simple::nextId = 1000;
    				

The Danger of using namespace in Header Files

The Notion of 'Who' is Compiling / 'Ownership' of the Source (.cpp) File

As such, all files included in the source file (recursively) and expanded by the preprocessor are essentially 'guests' of the source file and should not do anything that affects the semantics of that source file. In particular, no header (.h) file should contain a using namespace; doing so would 'pollute' the namespace of the source file from that point onwards (and most likely without the knowledge of the creator of the source file).

For example, the following header file contains a using. All subsequent appearances of string then resolve to the string type of the std namespace.

// somefile.h

using namespace std;

void f(string);

A source file that includes this file will ';silently be resolving string to std::string

//app.cpp

#include "somefile.h"

// no using in .cpp

…
	string s;		//std::string by virtue of the header's <>code>using
…

Instead, the header files should fully qualify any names as necessary:

// somefile.h

void f(std::string);

(This is true for actual code contained in inline functions as well)

Code Used in this Lecture