how libraries work on different platforms

[hmaher15]

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 or the implementation of the library
works on all platforms.

 

[Alf P. Steinbach]

* (e-mail address removed):

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.

Cheers, & hth.,

- Alf

 

[James Kanze]

* (e-mail address removed):

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*.)

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.

 

[Alf P. Steinbach]

* James Kanze:

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?

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/>.

Cheers, & hth.,

- Alf

 

[James Kanze]

* James Kanze:

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.

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.).

 

[hmaher15]

Thank you both (Alf P. Steinbach and James Kanze) for your help.