Overview

• A full scale C++ development environment will typically contain hundreds or thousands of classes, functions, and variables (maintained in .h/.cpp modules, that are used by various application programs.
• Often several modules perform related functions; for example, there may be a set of modules to perform network communication, another group to handle logging (the reporting and storing of messages relevant to an application), another having to do with the tax calculations of a payroll application.
• Although there is no C++ mechanism for grouping related modules together, various conventions are employed: e.g. creating a directory for each such group and placing all modules of that group in the directory.
• Regardless of how the modules are organized, a basic problem that arises is that of name clashes, i.e., two or more functions with the same name. If their signatures differ — i.e., their parameter lists differ in number and/or type, there's no problem — that's overloading; however, often their will be functions from different parts of the system with the same name and signature (one simple example is a function called init that initializes a subsystem of an application. Such functions are often paramterless, and the existence of two such functions in separate sets of modules that are brought into the same application results in a name clash.
• Object-oriented programming, with its heavy use of classes, lessens this problem with respect to function names (since functions are typically placed in classes where they do not clash with functions of other classes).
  • However, this simply pushes the problem onto class names; separate groups of modules may define classes with the same name; for example there could be an Address class in the subsystem dealing with employees, and a class of the same name in a subsystem dealing with web access.
• In general, the larger the collection of modules, the more pronounced this problem will become.
• To overcome this issue, C++ has a notion of namespace.
  • This is a mechanism that allows us to avoid name clashes by isolating the various subsystems.

Namespaces

• Namespaces are meant to isolate identical names, used in different subsystems, from each other.
  • If you read the above background material, the notion of a namespace is similar to that of an address space: within the same namespace, the same identifier refers to the same entity, while the same identifier in two (or more) namespaces are independent.
• Again, within our classroom, the name Instructor refers to only one entity (me); in another classroom, the Instructor is a totally different person.
• In the context of programming languages and C++ in particular, the notion of a namespace allows one to isolate identically named entities (functions, variables, classes, etc) by placing them in different namespaces
  • Within the namespace, the identifier is known by its (simple) name (for example within our classroom, I could be known as Gerald)
  • Outside the namespace, the simple name is insufficient; I must further qualify my (simple/first) name with a last name.
    • Alternatively, we could come to an agreement outside the namespace that when we speak of the simple name Gerald we are referring to me.
    o
• By placing subsystems of modules in separate namespaces, we can avoid the issue of name clashes
  • The analogy of first names in the classroom breaks down somewhat here: I have no say in the first names of the people who register for my class, and thus there is a (reasonable?) chance that there may be another Gerald in the class (i.e., a name clash)
  • However, a software subsystem is usually designed by a team of interacting programmers who will do design the system together as well as communicate with each other (especially with regard to anything that affects the group as a whole, such as the introduction of names visible to the whole subsystem), so name clashes can be avoided.
    • Besides the compiler will generate an error in the event of a name clash
    • The idea of the namespace is not so much to prevent name clashes completely (that can still happen by using the same name for two different entities in the same namespace); rather the idea is to make it easier for designers of independent software systems to use natural names without worrying about the impact on other subsystems.

Namespaces in C++

• There are two issues involved when working with namespaces:
  • Defining the namespace
  • Referring to entities within a particular namespace
• Each namespace must be assigned a unique name which is used when referring to that namespace.

The Global Namespace Scope

• All code you've written has been at top-level, i.e., not embedded within any namespace blocks.
• Such code is said to be at global namespace scope (we'll be discussing scopes as part of the actual syllabus shortly).
• In general, no qualification is needed for any entity at this level
  • There are situations where you need to be explicit that you are talking about an entity at global scope; in such you would use the scope resolution operator with no first operand; e.g., ::getAvg

The std Namespace

• All standard C++ entities (i.e., all the classes, functions, variables, etc in the standard C++ libraries, such as iostream, string, etc) belong to the namespace std (doesn't that explain a lot? :) ).

Explicitly Qualifying a Name with the Scope Resolution Operator

• Assume we have a namespace named , sp, and the following declaration:

  int i;
  		

  within that namespace.
• Code within sp can simply refer to the above variable by its unqualified name i.
• Code from outside the namespace can refer to this variable using the scope resolution operator sp::i.
  • We place the namespace as the first operand of the :: operator
  • (In the definition (implementation) of a class' member functions, the first operator is the name of the class containing the function)
• (We can also use the explicitly qualified form, sp::i from within the namespace, but there is little reason to do so)
• Pertinent examples for you:
  • std::string
  • std::cout

The using Directive

• This is the one you've been using since 1110; it makes the entire specified namespace available for reference without scope qualification.
  • The form is:

    using namespace namespace name;
    				

• This is why you've been able to write cout and string rather than std::cout and std::string.
• There is a school of thought that's against using the 'using directive' because it brings in the entire namespace and increases the likelihood of a clash or even worse, your calling a function other than the one you think you're calling
  • The latter scenario can occur if you forget to write the function (call it f, say, and a function of the same name already exists in the namespace (this actually happens often with max which is an existing function in one of the standard libraries).
• However, placing it at the top of your .cpp is not bad-- because you are the author of that file and you see what's happening.
• What conventional wisdom objects to is placing it in a .h file, because that file may very well be used by others, who are not aware of the fact that a using directive has been issued which directly affects which entities are being called.
• The solution is to either fully qualify in .h files, or employ the next technique

The using Declaration

• The using declaration allows you to open up a single item rather than the entire namespace.
• The form is:

  using namespace name::entitiy name
  		

  for example

  using std::string;
  		

• This is much more controlled and is the preferred technique
• For both the directive and declaration, the effect is from that point onwards in the source code until another directive or declaration that affects the entity (or entire namespace. (Don't forget that #include results in a textual in-place expansion)

What This Means to You

• Not much, if you want to be lazy or sloppy, since we're not introducing any namespaces.
• However, you should realize the pros and cons of each of the techniques, as well as what the standard recommendation of no directives in header files.