Re: how libraries work on different platforms
On Dec 3, 5:04 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Dec 2, 6:15 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* hmahe...@yahoo.com:
Hello I am starter in this amazing language and in
programming in general and I am wondering how the stream
library for example works fine on many platforms
(Windows,Linux etc.) does the compiler come with different
versions of this library on each platform
Yes.
or the implementation of the library
works on all platforms.
Yes. <g>
In practice the stream library implementation relies on a
lower level that is platform-specific. For example, that
lower level might be and typically is the FILE* abstraction
from the C standard library.
Which just moves the problem down a level:-). Sooner or later,
you've got to hit Posix or Windows (or whatever). (FWIW: none
of the iostream implementations I regularly use use FILE*.)
Well, for example, the Dinkumware standard library implementation in
MSVC 7.1 does (I just fired it up and looked at the code). To
understand this, if you want to go looking at the code, note that it
uses the internal definition _iobuf. The C library's FILE is in this
implementation a typedef for _iobuf.
Perhaps you don't use the Dinkumware implementation?
Not normally. I'm more or less constrained to use the
implementations which come with Sun CC or with g++, depending on
which platform I'm on. I've played around with it under VC++,
but I don't normally develop on a Windows platform.
Using FILE* to implement iostream is certainly a valid option
(although not used by g++). But all that that means is that the
platform specific code is in the implementation of the FILE*
stuff, and not in the implementation of iostream. In the end,
it has to be there somewhere.
There are other elements in the library which depend not only on
the system, but on the compiler itself: things like
std::type_info or std::numeric_limits.
Keep in mind that there exists portable implementations of the STL, e.g.
<url:http://www.stlport.org/>.
Which intentionally don't implement parts of the library
(<typeinfo>, for example), and which contain system dependent
code in other parts (the iostream subsystem, for example).
The border between "library" and "language" isn't always that
sharp. Some things (e.g. the rules concerning name look-up) are
clearly part of the language, and others (e.g. the standard
algorithms) clearly library, but there are gray areas in the
middle, around things like typeid/std::type_info, some of the
special handling of exceptions and new, <limits>, etc. And some
parts of the library can't be written in terms of C++: things
like <iostream> or <ctime> ultimately require functionality that
is not provided by the language, but by the platform (OS, etc.).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34