Home > Articles > Programming > C/C++

This chapter is from the book

This chapter is from the book

Namespaces

What's in a name? That which we call a rose. By any other name would smell as sweet.
—William Shakespeare, Romeo and Juliet

When a program uses different classes and functions written by different programmers, there is a possibility that two programmers will use the same name for two different things. Namespaces are a way to deal with this problem. A namespace is a collection of name definitions, such as class definitions and variable declarations. A namespace can, in a sense, be turned on and off so that when some of its names would otherwise conflict with names in another namespace, it can be turned off.

Namespaces and Using Directives

We have already been using the namespace that is named std. The std namespace contains all the names defined in many of the standard C++ library files (such as iostream). For example, when you place the following at the start of a file

#include <iostream>

that places all the name definitions (for names like cin and cout) into the std namespace. Your program does not know about names in the std namespace unless you specify that it is using the std namespace. To make all the definitions in the std namespace available to your code, you insert the following using directive:

using namespace std;

A good way to see why you might want to include this using directive is to think about why you might want to not include it. If you do not include this using directive for the namespace std, then you can define cin and cout to have some meaning other than their standard meaning. (Perhaps you want to redefine cin and cout because you want them to behave a bit differently from the standard versions.) Their standard meaning is in the std namespace, and without the using directive (or something like it), your code knows nothing about the std namespace, and so, as far as your code is concerned, the only definitions of cin and cout are whatever definition you give them.

Every bit of code you write is in some namespace. If you do not place the code in some specific namespace, then the code is in a namespace known as the global namespace. So far, we have not placed any code we wrote in any namespace and so all our code has been in the global namespace. The global namespace does not have a using directive because you are always using the global namespace. You could say there is always an implicit automatic using directive that says you are using the global namespace.

Note that you can be using more than one namespace at the same time. For example, we are always using the global namespace and we are usually using the std namespace. What happens if a name is defined in two namespaces and you are using both namespaces? This results in an error (either a compiler error or a run time error, depending on the exact details). You can have the same name defined in two different namespaces, but if that is true, then you can only use one of those namespaces at a time. However, this does not mean you cannot use the two namespace in the same program. You can use them each at different times in the same program.

For example, suppose NS1 and NS2 are two namespaces and suppose myFunction is a void function with no arguments that is defined in both namespaces but defined in different ways in the two namespaces, then the following is legal:

{
  using namespace NS1;
  myFunction( );
}
{
  using namespace NS2;
  myFunction( );
}

The first invocation would use the definition of myFunction given in the namespace NS1, and the second invocation would use the definition of the myFunction given in the namespace NS2.

Recall that a block is a list of statements, declarations, and possible other code, enclosed in braces {}. A using directive at the start of a block applies only to that block. So the first using directive applies only in the first block and the second using directive applies only in the second block. The usual way of phrasing this is to say that the scope of the NS1 using directive is the first block, while the scope of the NS2 using directive is the second block. Note that because of this scope rule, we are able to used two conflicting namespaces in the same program (such as in a program that contains the two blocks we discussed in the previous paragraph).

Normally, you place a using directive at the start of a block, but if you place further down in the block, you need to know the precise scope of a using directive. The scope of a using directive is from the place where it occurs to the end of the block. You may have a using directive for the same namespace in more than one block, so the entire scope of a namespace may cover multiple disconnected blocks. When you use a using directive in a block, it is typically the block consisting of the body of a function definition.

If you place a using directive at the start of a file (as we have usually done so far), then the using directive applies to the entire file. A using directive should normally be placed near the start of a file (or the start of a block), but the precise scope rule is that the scope of a using directive that is outside of all blocks is from the occurrence of the using directive to the end of the file.

Creating a Namespace

In order to place some code in a namespace, you simply place it in a namespace grouping of the following form:

namespace Name_Space_Name
{
  Some_Code
}

When you include one of these groupings in your code, you are said to place the names defined in Some_Code into the namespace Name_Space_Name. These names (really the definitions of these names) can be made available with the using directive:

using namespace Name_Space_Name;

For example, the following, taken from Display 5, places a function declaration in the namespace Space1:

namespace Space1
{
  void greeting( );
}

If you look again at Display 5, you see that the definition of the function greeting is also placed in namespace Space1. That is done with the following additional namespace grouping:

namespace Space1
{
  void greeting( )
  {
    cout << "Hello from namespace Space1.\n";
  }
}

Note that you can have any number of these namespace groupings for a single namespace. In Display 5, we used two namespace groupings for namespace.

Display 5—Namespace Demonstration

#include <iostream>
using namespace std;

namespace Space1
{
  void greeting( );
}

namespace Space2
{
  void greeting( );
}

void bigGreeting( );

int main( )
{
  {//This block use definitions in namespaces Space2, std, and the global namespace
    using namespace Space2;
    greeting( );
  }

  {//This block use definitions in namespaces Space1, std, and the global namespace
    using namespace Space1;
    greeting( );
  }

//Names out here only use definitions in namespaces std, and the global namespace
  bigGreeting( );

  return 0;
}

namespace Space1
{
  void greeting( )
  {
    cout << "Hello from namespace Space1.\n";
  }
}

namespace Space2
{
  void greeting( )
  {
    cout << "Greetings from namespace Space2.\n";
  }
}

void bigGreeting( )
{
  cout << "A Big Global Hello!\n";
}

Sample Screen Dialogue

Greetings from namespace Space2.
Hello from namespace Space1.
A Big Global Hello!

Every name defined in a namespace is available inside the namespace groupings, but the names can also be made available to code outside of the namespace. For example, the function declaration and function definition in the namespace Space1 can be made available with the using directive

using namespace Space1

as illustrated in Display 5.

Using Declarations

This section describes a way to qualify a single name so you can make only one name from a namespace available to your program, rather than making all the names in a namespace available.

Suppose you are faced with the following situation. You have two namespaces: NS1 and NS2. You want to use the function fun1 defined in NS1 and the function fun2 defined in namespace NS2. The complication is that both NS1 and NS2 define a function myFunction. (Assume all functions in this discussion take no arguments so overloading does not apply). You cannot use

using namespace NS1;
using namespace NS2;

This would potentially provide confliction definitions for myFunction. (If the name myFunction is never used, then most compilers will not detect the problem and will allow your program to compile and run.)

What you need is a way to say you are using fun1 in namespace NS1 , fun2 in namespace NS2, and nothing else in the namespaces NS1 and NS2. The following is your solution:

using NS1::fun1;
using NS2::fun2;

A qualification of the form

using Name_Space::One_Name;

makes the (definition of the) name One_Name from the namespace Name_Space available, but does not make any other names in Name_Space available. This is called a using declaration.

Note that the scope resolution operator :: that we use in these using declarations is the same as the scope resolution operator we use when defining member functions, and these two uses of the scope resolution operator have a similarity. For example, in Display 2, we had the following function definition:

void DigitalTime::advance(int hoursAdded, int minutesAdded)
{
  hour = (hour + hoursAdded)%24;
  advance(minutesAdded);
}

In this case, the :: means that we are defining the function advance for the class DigitalTime, as opposed to any other function named advance in any other class. Similarly,

using NS1::fun1;

means we are using the function named fun1 as defined in the namespace NS1, as opposed to any other definition of fun1 in any other namespace.

There are two differences between a using declaration, such as

using std::cout;

and a using directive such as

using namespace std;

The differences are

  1. A using declaration makes only one name in the namespace available to your code, while a using directive makes all the names in a namespace available.

  2. A using declaration introduces a name (like cout) into your code so no other use of the name can be made. However a using directive only potentially introduces the names in the namespace.

Point 1 is pretty obvious. Point 2 has some subtleties. For example, suppose the namespaces NS1 and NS2 both provide definitions for myFunction, but have no other name conflicts, then the following will produce no problems:

using namespace NS1;
using namespace NS2;

provided that (within the scope of these directives) the conflicting name myFunction is never used in your code.

On the other hand, the following is illegal, even if the function myFunction is never used:

using NS1::myFunction;
using NS2::myFunction;

Sometimes this subtle point can be important, but it does not impinge on most routine code. So, we will often use the term using directive loosely to mean either a using directive or a using declaration.

Qualifying Names

This section introduces a way to qualify names that we have not discussed before. Suppose that you intend to use the name fun1 as defined in the namespace NS1, but you only intend to use it one time (or a small number of times). You can name the function (or other item) using the name of the namespace and the scope resolution operator as follows:

NS1::fun1( );

This form is often used when specifying a parameter type. For example, consider

int getInput(std::istream inputStream)
. . .

In the function getInput, the parameter inputStream is of type istream where istream is defined as in the std namespace. If this use of the type name istream is the only name you need from the std namespace (or if all the names you need are similarly qualified with std::), then you do not need

using namespace std;

nor

using std::istream;

Note that you can use std::istream even within the scope of a using directive for another namespace that also defines the name istream. In this case, std::istream and istream will have different definitions. For example, consider.

using namespace MySpace;
void someFunction(istream p1, std::istream p2);

Assuming istream is a type defined in the namespace MySpace, then p1 will have the type istream as defined in MySpace, and p2 will have the type istream as defined in the std namespace.

Programming Example: A Class Definition in a Namespace

In Displays 6 and 7, we have again rewritten both the header file dtime.h for the DTimeSavitch. Note that the namespace DTimeSavitch spans the two files dtime.h and dtime.cpp. A namespace can span multiple files.

Display 6—Placing a Class in a Namespace (Header File)

//This is the header file dtime.h.
//A better version of this class definition will be given in Displays 8 and 9.
#ifndef DTIME_H
#define DTIME_H

#include <iostream>
using std::istream;
using std::ostream;

namespace DTimeSavitch
{
  class DigitalTime
  {
   <The definition of the class DigitalTime is the same as in Display 1.>
  };
}// DTimeSavitch

#endif //DTIME_H

Display 7—Placing a Class in a Namespace (Implementation File)

//This is the implementation file: dtime.cpp 
#include <iostream>
#include <cctype>
#include <cstdlib>
using std::istream;
using std::ostream;
using std::cout;
using std::cin;
#include "dtime.h"

namespace DTimeSavitch
{
  <All the function definitions from Display 2 go here.>
}// DTimeSavitch

If you rewrite the definition of the class DigitalTime, as shown in Displays 6 and 7, then the application program in Display 3 needs to specify the namespace DTimeSavitch in some way, such as the following:

using namespace DTimeSavitch;

or

using DTimeSavitch::DigitalTime;

Programming Tip: Choosing a Name for a Namespace

It is a good idea to include your last name or some other unique string in the names of your namespaces, so as to reduce the chance that somebody else will use the same namespace name as you do. With multiple programmers writing code for the same project it is important that namespaces that are meant to be distinct really do have distinct names. Otherwise, you can easily have multiple definitions of the same names in the same scope. That is why we included the name Savitch in the namespace DtimeSavitch in Display 6.

Unnamed Namespaces

A compilation unit is a file, such as a class implementation file, along with all the files that are #included in the file, such as the interface header file for the class. Every compilation unit has an unnamed namespace. A namespace grouping for the unnamed namespace is written in the same way as any other namespace, but no name is given, as in the following example:

namespace
{
  void sampleFunction( )
    .
    .
    .
} //unnamed namespace 

All the names defined in the unnamed namespace are local to the compilation unit, and so the names can be reused for something else outside the compilation unit. For example, Display 8 shows a rewritten (and our final) version.

Display 8—Hiding the Helping Functions in a Namespace—Interface File

//This is the header file dtime.h. This is the interface for the class DigitalTime.
//Values of this type are times of day. The values are input and output in 24 hour
//notation as in 9:30 for 9:30 AM and 14:45 for 2:45 PM.
#ifndef DTIME_H
#define DTIME_H

#include <iostream>
using std::istream;
using std::ostream;

namespace DTimeSavitch
{
  class DigitalTime
  {
  public:
    DigitalTime(int theHour, int theMinute);

    DigitalTime( );
    //Initializes the time value to 0:00 (which is midnight).

    getHour( ) const;
    getMinute( ) const;

    void advance(int minutesAdded);
    //Changes the time to minutesAdded minutes later.

    void advance(int hoursAdded, int minutesAdded);
    //Changes the time to hoursAdded hours plus minutesAdded minutes later.

    friend bool operator ==(const DigitalTime& time1, 
                const DigitalTime& time2);
    friend istream& operator >>(istream& ins, DigitalTime& theObject);
    friend ostream& operator <<(ostream& outs, 
                  const DigitalTime& theObject);
  private:
    int hour;
    int minute;
  };

} //DTimeSavitch
#endif //DTIME_H

The helping functions digitToInt, readHour, and readMinute are used outside the unnamed namespace without any namespace qualifier. Any name defined in the unnamed namespace can be used without qualification anywhere in the compilation unit. (Of course, this needed to be so, since the unnamed namespace has no name to use for qualifying its names.)

It is interesting to note how unnamed namespaces interact with the C++ rule that you cannot have two definitions of a name (in the same namespace). There is one unnamed namespace in each compilation unit. It is easily possible for compilation units to overlap. For example, both the implementation file for a class and an application program using the class would normally both include the header file (interface file) for the class. Thus, the header file is in two compilation units and hence participates in two unnamed namespaces. As dangerous as this sounds, it will normally produce no problems as long as each compilation unit's namespace makes sense when considered by itself. For example, if a name is defined in the unnamed namespace in the header file, it cannot be defined again in the unnamed namespace in either the implementation file or the application file. So, a name conflict is avoided.

Pitfall: Confusing the Global Namespace and the Unnamed Namespace

Do not confuse the global namespace with the unnamed namespace. If you put a name definition in no namespace grouping, then it is in the global namespace. To put a name definition in the unnamed namespace, you must put it in a namespace grouping that starts out as follows, without a name:

namespace
{

Both names in the global namespace and names in the unnamed namespace may be accessed without qualifier. However, names in the global namespace have global scope (all the program files), while names in an unnamed namespace are local to a compilation unit.

This confusion between the global namespace and the unnamed namespace does not arise very much in writing code, since there is a tendency to think of names in the global namespace as being "in no namespace," even though that is not technically correct. However, the confusion can easily arise when discussing code.

Programming Tip: Unnamed Namespaces Replace static Qualifier

Earlier versions of C++ used the qualifier static to make a name local to a file. This use of static is being phased out, and you should instead use the unnamed namespace to make a name local to a compilation unit. Note that this use of static has nothing to do with the use of static to qualify class members. So, since static was used to mean more than one thing, it is probably good that one use of the word is being phased out.

Programming Tip: Hiding Helping Functions

There are two good ways to hide helping functions for a class. You can make the function a private member function of the class or you can place the helping function in the unnamed namespace for the implementation file of the class. If the function naturally takes a calling object, then it should be made a private member function. If it does not naturally take a calling object, you can make it a static member function (for example, DigitalTime::readHour in Displays 1 and 2), or you can place it in the unnamed namespace of the implementation file (for example, readHour in Display 8).

If the helping function does not need a calling object, then placing the helping function in the unnamed namespace of the implementation file makes for cleaner code, since it better separates interface and implementation into separate files, and since it avoids the need for so much function name qualification. For example, we can use the function name readHour unqualified since it is in the unnamed namespace, while in the version in Display 2, we need to use DigitalTime::readHour.

Nested Namespaces

It is legal to nest namespaces. When qualifying a name from a nested namespace, you simply qualify twice. For example, consider

namespace S1
{
  namespace S2
  {
    void sample( )
    {
     .
     .
     .
    }
   .
   .
   .
  } //S2
}//S1

To invoke sample outside of the namespace S1, you use

S1::S2::sample( );

To invoke sample outside of namespace S2, but within namespace S1, you use

S2::sample( );

Alternatively, you could use a suitable using directive.

Programming Tip: What Namespace Specification Should You Use?

You have three ways to specify that your code uses the definition of a function (or other item) named f, which was defined in a namespace named theSpace. You can insert

using namespace theSpace;

Alternatively, you can insert

using theSpace::f;

Alternatively, you could use no using directive at all, but always qualify the function name by writing theSpace::f instead of just plain f.

Which form should you use? All three methods can be made to work, and authorities differ on what they recommend as the preferred style. However, to obtain the full value of namespaces, it is good to avoid the form

using namespace theSpace;

Placing such a using directive at the start of a file is little different from placing all definitions in the global namespace, which is what earlier versions of C++ actually did. So, this approach gets no value out of the namespace mechanism. (If you place such a using directive inside a block, then it only applies to that block, and so that is another alternative, and an alternative that is both sensible and advocated by many authorities.)

We prefer to use the second method most of the time, inserting statements like the following at the start of files:

using theSpace::f;

This allows you to omit names that are in the namespace but that are not used. That in turn avoids potential name conflicts. Moreover, it nicely documents which names you use, and it is not as messy as always qualifying a name with notation of the form theSpace::f.

If your files are structured so that different namespaces are used in different locations, it may sometimes be preferable to place your using directives and using declarations inside of blocks, such as the bodies of function definitions, rather than at the start of the file.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020