Chapter 11

Separate
Compilation
and Namespaces

Copyright © 2016 Pearson, Inc.

All rights reserved.
 Learning Objectives
• Separate Compilation
– Encapsulation reviewed
– Header and implementation files
• Namespaces
– using directives
– Qualifying names
– Unnamed namespaces
– Hiding helping functions
– Nested namespaces

Copyright © 2016 Pearson Inc. All rights reserved. 11-2

 Separate Compilation
• Program Parts
– Kept in separate files
– Compiled separately
– Linked together before program runs
• Class definitions
– Separate from "using" programs
– Build library of classes
• Re-used by many different programs
• Just like predefined libraries

Copyright © 2016 Pearson Inc. All rights reserved. 11-3

 Class Separation
• Class Independence
– Separate class definition/specification
• Called "interface"
– Separate class implementation
– Place in two files
• If implementation changes  only that
file need be changed
• Class specification need not change
• "User" programs need not change

Copyright © 2016 Pearson Inc. All rights reserved. 11-4

 Encapsulation Reviewed
• Encapsulation principle:
– Separate how class is used by programmer
from details of class’s implementation
• "Complete" separation
– Change to implementation  NO impact on
any other programs
• Basic OOP principle

Copyright © 2016 Pearson Inc. All rights reserved. 11-5

 Encapsulation Rules
• Rules to ensure separation:
1. All member variables should be private
2. Basic class operations should be:
• Public member functions
• Friend or ordinary functions
• Overloaded operators
Group class definition and prototypes together
• Called "interface" for class
3. Make class implementation unavailable to
users of class

Copyright © 2016 Pearson Inc. All rights reserved. 11-6

 More Class Separation
• Interface File
– Contains class definition with function and
operator declarations/prototypes
– Users "see" this
– Separate compilation unit
• Implementation File
– Contains member function definitions
– Separate compilation unit

Copyright © 2016 Pearson Inc. All rights reserved. 11-7

 Class Header Files
• Class interface always in header file
– Use .h naming convention
• Programs that use class will "include" it
– #include "myclass.h"
– Quotes indicate you wrote header
• Find it in "your" working directory
– Recall library includes, e.g., <iostream>
• < > indicate predefined library header file
• Find it in library directory

Copyright © 2016 Pearson Inc. All rights reserved. 11-8

 Class Implementation Files
• Class implementation in .cpp file
– Typically give interface file and implementation file same
name
• myclass.h and myclass.cpp
– All class’s member function defined here
– Implementation file must #include class’s
header file
• .cpp files in general, typically contain
executable code
– e.g., Function definitions, including main()

Copyright © 2016 Pearson Inc. All rights reserved. 11-9

 Class Files
• Class header file #included by:
– Implementation file
– Program file
• Often called "application file" or "driver file"
• Organization of files is system dependent
– Typical IDE has "project" or "workspace"
• Implementation files "combined" here
• Header files still "#included"

Copyright © 2016 Pearson Inc. All rights reserved. 11-10

 Multiple Compiles of Header Files
• Header files
– Typically included multiple times
• e.g., class interface included by class implementation and program
file
– Must only be compiled once!
– No guarantee "which #include" in which file,
compiler might see first
• Use preprocessor
– Tell compiler to include header only once

Copyright © 2016 Pearson Inc. All rights reserved. 11-11

 Using #ifndef
• Header file structure:
– #ifndef FNAME_H
#define FNAME_H
… //Contents of header file
…
#endif
• FNAME typically name of file for
consistency, readability
• This syntax avoids multiple definitions
of header file

Copyright © 2016 Pearson Inc. All rights reserved. 11-12

 Other Library Files
• Libraries not just for classes
• Related functions
– Prototypes  header file
– Definitions  implementation file
• Other type definitions
– structs, simple typedefs  header file
– Constant declarations  header file

Copyright © 2016 Pearson Inc. All rights reserved. 11-13

 Namespaces
• Namespace defined:
A collection of name definitions
– Class definitions
– Variable declarations
• Programs use many classes, functions
– Commonly have same names
– Namespaces deal with this
– Can be "on" or "off"
• If names might conflict  turn off

Copyright © 2016 Pearson Inc. All rights reserved. 11-14

 using Directive
• using namespace std;
– Makes all definitions in std namespace
available
• Why might you NOT want this?
– Can make cout, cin have non-standard
meaning
• Perhaps a need to redefine cout, cin
– Can redefine any others

Copyright © 2016 Pearson Inc. All rights reserved. 11-15

 Namespace std
• We’ve used namespace std
• Contains all names defined in many standard library
files
• Example:
#include <iostream>
– Places all name definitions (cin, cout, etc.)
into std namespace
– Program doesn’t know names
– Must specify this namespace for program
to access names

Copyright © 2016 Pearson Inc. All rights reserved. 11-16

 Global Namespace
• All code goes in some namespace
• Unless specified  global namespace
– No need for using directive
– Global namespace always available
– Implied "automatic" using directive

Copyright © 2016 Pearson Inc. All rights reserved. 11-17

 Multiple Names
• Multiple namespaces
– e.g., global, and std typically used
• What if name defined in both?
– Error
– Can still use both namespaces
– Must specify which namespace used at
what time

Copyright © 2016 Pearson Inc. All rights reserved. 11-18

 Specifying Namespaces
• Given namespaces NS1, NS2
– Both have void function myFunction()
defined differently
{
using namespace NS1;
myFunction();
}
{
using namespace NS2;
myFunction();
}
– using directive has block-scope

Copyright © 2016 Pearson Inc. All rights reserved. 11-19

 Creating a Namespace
• Use namespace grouping:
namespace Name_Space_Name
{
Some_Code
}
• Places all names defined in Some_Code
into namespace Name_Space_Name
• Can then be made available:
using namespace Name_Space_Name

Copyright © 2016 Pearson Inc. All rights reserved. 11-20

 Creating a Namespace Example
• Function declaration:
namespace Space1
{
void greeting();
}
• Function definition:
namespace Space1
{
void greeting()
{
cout << "Hello from namespace Space1.\n";
}
}

Copyright © 2016 Pearson Inc. All rights reserved. 11-21

 using Declarations
• Can specify individual names
from namespace
• Consider:
Namespaces NS1, NS2 exist
Each have functions fun1(), fun(2)
– Declaration syntax:
using Name_Space::One_Name;
– Specify which name from each:
using NS1::fun1;
using NS2::fun2;

Copyright © 2016 Pearson Inc. All rights reserved. 11-22

 using Definitions and Declarations

• Differences:
– using declaration
• Makes ONE name in namespace available
• Introduces names so no other uses of name
are allowed

– using directive
• Makes ALL names in namespace available
• Only "potentially" introduces names

Copyright © 2016 Pearson Inc. All rights reserved. 11-23

 Qualifying Names
• Can specify where name comes from
– Use "qualifier" and scope-resolution operator
– Used if only intend one use (or few)
• NS1::fun1();
– Specifies that fun() comes from namespace
NS1
• Especially useful for parameters:
int getInput(std::istream inputStream);
– Parameter found in istream’s std namespace
– Eliminates need for using directive or declaration

Copyright © 2016 Pearson Inc. All rights reserved. 11-24

 Naming Namespaces
• Include unique string
– Like last name
• Reduces chance of other namespaces
with same name
• Often multiple programmers write
namespaces for same program
– Must have distinct names
– Without  multiple definitions of same name
in same scope
• Results in error

Copyright © 2016 Pearson Inc. All rights reserved. 11-25

 Class Namespace Example:
Display 11.6 Placing a Class
in a Namespace (Header File)

Copyright © 2016 Pearson Inc. All rights reserved. 11-26

 Class Namespace Example:
Display 11.7 Placing a Class
in a Namespace (Implementation File)

Copyright © 2016 Pearson Inc. All rights reserved. 11-27

 Unnamed Namespaces
• Compilation unit defined:
– A file, along with all files #included in file
• Every compilation unit has unnamed namespace
– Written same way, but with no name
– All names are then local to compilation unit
• Use unnamed namespace to keep
things "local"
• Scope of unnamed namespace is
compilation unit

Copyright © 2016 Pearson Inc. All rights reserved. 11-28

 Global vs. Unnamed Namespaces

• Not same
• Global namespace:
– No namespace grouping at all
– Global scope
• Unnamed namespace:
– Has namespace grouping, just no name
– Local scope

Copyright © 2016 Pearson Inc. All rights reserved. 11-29

 Nested Namespaces
• Legal to nest namespaces
namespace S1
{
namespace S2
{
void sample()
{
…
}
}
• Qualify names twice:
– S1::S2::sample();

Copyright © 2016 Pearson Inc. All rights reserved. 11-30

 Hiding Helping Functions
• Recall helping function:
– Low-level utility
– Not for public use
• Two ways to hide:
– Make private member function
• If function naturally takes calling object
– Place in class implementation’s unnamed namespace!
• If function needs no calling object
• Makes cleaner code (no qualifiers)

Copyright © 2016 Pearson Inc. All rights reserved. 11-31

 Summary 1
• Can separate class definition and implementation 
separate files
– Separate compilation units
• Namespace is a collection of name definitions
• Three ways to use name from namespace:
– Using directive
– Using declaration
– Qualifying

Copyright © 2016 Pearson Inc. All rights reserved. 11-32

 Summary 2
• Namespace definitions are placed
inside namespace groupings
• Unnamed namespace
– Used for local name definitions
– Scope is compilation unit
• Global namespace
– Items not in a namespace grouping at all
– Global scope

Copyright © 2016 Pearson Inc. All rights reserved. 11-33