The point the author is making is that the compiler, should it wish to do so, could implement #include <string>
internally in the compiler, without there ever being any file called string
in the system that compiles your code. In reality, I'm not aware of any compiler that DOES implement this, but it's certainly viable from what the C++ standards perspective.
Each compiler vendor, such as GNU and Free Software Foundation for gcc, the people at Illinois University behind clang, the people at Microsoft, Borland, IBM, Intel, etc that produce a compiler will produce "an implementation" of a compiler. If I write my own C++ compiler that will be an implementation. I happen to have my own compiler for the language Pascal (written in C++ and using LLVM as the backend) - which is an implementation of the language Pascal - and like all implementations, it follows the standard, but has some "implementation defined" features. All implementations will have some things that are "based on what the implementor choose to do", for several possible reasons:
- The standard is not specific: size of
int
or Pascal's integer
is not specified beyond "it must be at least this big ...", so as long as the minimum criteria is fulfilled, the implementor can do what he/she/they chooses.
- Extensions - something that goes beyond the standard. Often the standard has restrictions or missing functionality that the implementor may decide to "improve" (this does make the implementation "non-standard", but if the extension doesn't alter the behaviour of standard compliant code, it's "safe" to add) [for example, Pascal doesn't have "names on files", so a Pascal program can't create a file by a particular name - most implementations do have SOME way to create a file by a particular name as an extension]
- Standard specifies "implementation defined behaviour" - similar to non-specific, the standard can say that "this is up to the implementor to do as she/he/they wish".