Scribd
Upload
17 views33 pages

Separate Compilation and Namespaces

Uploaded by

okuwobi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
17 views33 pages

Separate Compilation and Namespaces

Uploaded by

okuwobi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 33

Chapter 11

Separate
Compilation
and Namespaces
Learning Objectives
 Separate Compilation
 Encapsulation reviewed
 Header and implementation files

 Namespaces
 using directives
 Qualifying names
 Unnamed namespaces
 Hiding helping functions
 Nested namespaces

Copyright © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. All rights reserved. 11-25


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

Copyright © 2006 Pearson Addison-Wesley. All rights reserved. 11-26


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

Copyright © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. All rights reserved. 11-29


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

Copyright © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. 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 © 2006 Pearson Addison-Wesley. All rights reserved. 11-33

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy