C++ Implementations and Their Facilities
Standard-library components are part of every complete C++ implementation and are portable across implementations.
Will the Same Source Code Behave the Same?
Imagine you write a C++ program on one computer and then hand the same source code to a colleague, who compiles it on a different setup. Will it build and run the same way? The honest answer is that it depends on which facilities your program uses. Some facilities are guaranteed to be present wherever C++ is complete, and others are offered only by particular environments. Understanding that difference is the starting point for this article.
What do you think happens?
If your program uses only standard-library components, will it compile and run the same way on a different complete C++ implementation?
Reveal answer
Yes. Standard-library components are part of every complete C++ implementation and are portable across implementations.
This is the reason the standard library is the focus of portable code. Facilities outside that common set are where differences between implementations and environments can appear.
Tracing Where a Facility Comes From
The facilities a C++ program can call do not all come from the same place. Some come with every complete C++ implementation. Others come from the wider system the program runs on. Before deciding whether a piece of code is safe to move, you need to trace each facility back to its origin. The following example is an original illustration of that habit.
Tracing the facilities of a small program
A program uses three facilities: a component from the standard library, a graphical window library provided by its development environment, and a database interface. For each facility, decide where it comes from and whether it is guaranteed to be present on another complete C++ implementation.
- 1List each facility the program calls
There are three: a standard-library component, a GUI library, and a database interface. Listing them first keeps the tracing systematic.
- 2Check the standard-library component
Standard-library components are part of every complete C++ implementation and are portable across implementations. Its origin is the common set every complete implementation provides, so it is guaranteed to be present.
- 3Check the GUI library
GUI systems let a program present windows, buttons, and other visual controls. They are non-standard facilities. Its origin is the wider environment, so it must be identified and checked on each target system.
- 4Check the database interface
Database interfaces let a program talk to database systems. They are also non-standard and are offered only by particular environments, so they too depend on the target system.
- 5Record the dependencies
Only the first facility is portable by construction. The other two are deliberate dependencies that the program carries and must be verified when the code moves.
One facility is portable by construction, while two depend on the environment. Tracing each facility to its origin tells you exactly which parts of the program need checking on a new system.
Standard Library Versus Everything Else
Standard-library components are the facilities that are part of every complete C++ implementation and are portable across implementations. They are defined by the C++ standard, which the source uses as the basis for its self-contained description of the language.
The diagram shows the containment. A complete C++ implementation always contains the standard-library components. Non-standard libraries and interfaces are provided beyond that common set, and most implementations offer them. Foundation libraries sit on the other side of the picture: they come from the application development environment, which is aimed at corporate or industrial standard development and execution environments, and not necessarily from the C++ implementation itself.
Non-Standard Facilities in Practice
The source names several families of non-standard facilities. Each one is a real kind of capability that a program may depend on, and each one is supplied by something beyond the common standard-library set.
How Portability Changes with Facility Choice
Portability here means that code can be compiled and run on different C++ implementations without modification. The source states that its examples are kept portable, and that using standard-library components is the most direct way to achieve this. Compare two programs. The first uses only standard-library components. The second also calls a vendor-specific extension. When each is moved to another implementation, the effect is different.
| Facility type | Guaranteed in every complete C++ implementation? | Portability when moved |
|---|---|---|
| Standard-library components | Yes | Portable across implementations |
| Non-standard libraries and interfaces | Not guaranteed; offered beyond the common set | Must be identified and checked on each target |
| Foundation libraries from application development environments | Comes from the environment, not necessarily the implementation | Depends on the environment where applications are built and run |
Standard-library components compared with non-standard facilities
Mistakes Beginners Make with Facilities
Common mistake Assuming every facility a program calls is available everywhere
What it looks likeA program uses a GUI library from its development environment and is then compiled on a different setup without any check.
Why it failsOnly standard-library components are part of every complete C++ implementation. Non-standard facilities are offered beyond that common set and depend on the environment.
Do this insteadTrace each facility to its origin and identify which ones must be checked on the target system.
Common mistake Believing that using non-standard facilities is forbidden
What it looks likeA programmer avoids every non-standard feature out of fear, even when the environment provides exactly what the project needs.
Why it failsThe source does not tell a programmer to avoid non-standard facilities. It explicitly encourages exploring the more extensive facilities available on most systems.
Do this insteadUse non-standard facilities deliberately, and record the dependency so that it is a choice rather than an accident.
Common mistake Confusing foundation libraries with the standard library
What it looks likeA developer assumes a library bundled with the development environment is part of the C++ standard library.
Why it failsFoundation libraries come from the application development environment, not necessarily from the C++ implementation itself.
Do this insteadCheck where the library comes from before treating it as portable.
Practical Habits for Portable Code
Use standard-library components as the default, because they are the main way to keep code portable. When a program needs a non-standard facility, identify it, write down which environment provides it, and check it on each target system before the code is moved.
Checking Your Understanding
A colleague says that because their program builds on your machine, it will build on any complete C++ implementation. Which parts of the program would you check first, and why?
Hints
- Start by listing every facility the program calls.
- Ask which of those facilities are standard-library components and which are non-standard.
- Consider whether a GUI, web, or database facility would need to be verified on the target system.
Key Takeaways
- A complete C++ implementation always includes standard-library components, which are portable across implementations.
- Non-standard libraries and interfaces are provided beyond that common set, and examples include GUI systems, web interfaces, and database interfaces.
- Foundation libraries come from application development environments and are not necessarily part of the C++ implementation itself.
- Using standard-library components is the main way to keep code portable, while non-standard facilities should be identified and checked on each target system.
- Non-standard facilities are not forbidden; the goal is to make each environment-specific dependency a deliberate choice.