The scope resolution operator is used to resolve the scope of a name. By default, all user-defined names reside within the global namespace, however you can create additional namespaces as required (all namespaces exist within the global namespace). This makes it possible to re-use the same names within different namespaces and thus eliminate name clashes.

For instance, the standard library exists within the std namespace, so if we want to use the string data type, we use scope resolution as follows:

std::string s = "Hello world";

Note that :: is the scope resolution operator.

Since the std namespace itself resides within the global namespace, we could also explicitly refer to it as follows:

::std::string s = "Hello world";

The global namespace has no name. However, the global namespace is always implied, so in most cases we can simply leave out the global scope resolution operator and thus simplify our code.

Scope resolution comes into its own when we have two or more namespaces containing the same name. Without scope resolution there would be no way to differentiate between them. Consider the following:

std::string caption;

namespace A {

std::string caption;

};

Here we've got two variables named caption. At global scope we can refer to these as follows:

caption = "Hello world"; // global caption

A::caption = "Hello world"; // namespaced caption

Note how we use scope resolution to refer to A::caption.

If we define a function within namespace A, it can also refer to them as follows:

namespace A {

std::string caption;

void foo () {

caption = "Hello world"; // refers to A::caption

::caption = "Hello world"; // refers to global caption

}

};

Note how caption implicitly refers to A::caption from within the A namespace while we must use global scope resolution to resolve the global caption.

The foo function itself can also be called from outside of the namespace using scope resolution:

A::foo();

Scope resolution also applies to class members (a class is itself a type of namespace). This is what allows two different classes to use the same member names. We can also embed (nest) namespaces within other namespaces, similar to the way in which all namespaces at global scope are implicitly embedded within the global namespace. For instance, the standard library has an embedded namespace called chrono which contains the system_clock data type. If we want to use it we need to use the following scope resolution:

std::chrono::system_clock c;

Useful as scope resolution is, its usage is often redundant (much like the global scope resolution is largely redundant). For instance, if we plan to make use of a lot of std::string data types within our code, it would make sense to import the string name into the global namespace. We achieve this with the using keyword:

using std::string;

string s = "Hello world";

Obviously it makes no sense to do this for just one variable, but it makes code containing a lot of string data types much easier to read because we no longer need scope resolution. The system_clock is another typical example:

using std::chrono::system_clock;

system_clock c;

Importing the standard library into the global namespace is particularly useful in small trivial programs (particularly code demonstration programs), to the extent you will often see the entire namespace imported:

using namespace std;

Note that the names that are imported are dependant upon which library headers you've included at the point of import, therefore you should use this facility with caution. Include files can include other files you may not be immediately aware of and in large, complex programs there is a danger of importing a name that could clash with a user-defined name. Therefore it's best to only import those specific names you actually need to import. Better still, you can import directly into a function, thus limiting the scope of the import to that one function.

void foo()

{

using std::string;

string s = "Hello world";

// ...

}

void bar()

{

string s = "Hi!"; // error: string data type not defined!

}

Here the import only applies to the foo function, not the bar function.

With proper use of modularisation, importing names into the global namespace at file scope is generally OK so long as you only import what you need to make your code easier to read (and write). Don't import names on the off-chance you might need them later, and avoid including entire namespaces unnecessarily.

Resources

Top Categories

Product

Company