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:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34