What is the relationship, if any, between iostream and the STL

[blangela]

Someone has asked me what the relationship is, if any, between iostream
and the STL. My suspicion is that iostream uses some of the
functionality provided by the STL, but I have no actual kowledge on
which to base my suspicion. Anyone out there know? Please make you
answer as verbose as possible.

Thanks,

Bob

 

[Noah Roberts]

Someone has asked me what the relationship is, if any, between iostream
and the STL. My suspicion is that iostream uses some of the
functionality provided by the STL, but I have no actual kowledge on
which to base my suspicion. Anyone out there know? Please make you
answer as verbose as possible.

The "STL" was a third party library that was brought into the standard
library. It behaved in certain ways and worked with certain concepts
not necissarily in compiler libraries at the time (I don't believe
there was a standard). When the STL became part of the standard
library parts of the implementation library changed to better work with
concepts in the STL. This includes string to which were added
iterators, and iostreams I believe - again, iterators where added.

Now days when people say "STL" they usually mean the C++ part of the
standard library (in otherwords not the C compat crap), which iostreams
are of course part of. IMHO the term should really be depricated but
whatever.

 

[Victor Bazarov]

Someone

Who? Your instructor at school or your interviewer?

has asked me what the relationship is, if any, between
iostream and the STL. My suspicion is that iostream uses some of the
functionality provided by the STL, but I have no actual kowledge on
which to base my suspicion. Anyone out there know?

Implementors of the library know the most, of course.

Please make you
answer as verbose as possible.

First and foremost, 'iostream' is part of the Standard Library. If
by "STL" you mean the Standard Library, here is your relationship.
I am not saying that just to wave you off, it's important in the sense
that the design intent and philosophy behind streams is in tune with
the rest of the library.

The streams fit into the rest of the library in two major ways: they
define (overload) operators for inputting and outputting types defined
in the library (std::basic_string, for one), and they also provide
iterators for use in some library algorithms. Also, there is a certain
link (so to speak) between streams and locales.

Whether streams make any use of any other parts of the library
behind the scenes, is unspecified. They can use stream functionality
provided by the Standard C library. As to sorting, searching, copying
and other algorithms, I don't see why not. Allocators and other
memory management stuff as well.

V

 

[blangela]

Who? Your instructor at school or your interviewer?

A colleage at work asked the question.

Implementors of the library know the most, of course.


First and foremost, 'iostream' is part of the Standard Library. If
by "STL" you mean the Standard Library,

I meant Standard Template Library by STL

here is your relationship.

 

[Victor Bazarov]

Victor Bazarov wrote: [..]

First and foremost, 'iostream' is part of the Standard Library. If
by "STL" you mean the Standard Library,

I meant Standard Template Library by STL

Do you mean the library that SGI publishes? Since 1998 there is
*Standard Library*. Vendorless STL doesn't exists since adoption of
the International Standard for C++ language. "STL" is an obsolete
term AFA C++ _language_ is concerned.

V

 

[Roland Pibinger]

Someone has asked me what the relationship is, if any, between iostream
and the STL.

Apart from being later (partially) incorporated into the C++ Standard
both libraries presented something 'new' and 'cool' at the time they
were make public. In the early nineties iostreams came out with OO
design and fancy operator overloadings, in the mid nineties STL used a
value-oriented, anti-OO, generic 'paradigm' influenced by functional
programming. If they were not ennobled by the C++ Standard you would
hardly find those libraries in current C++ code.

Best regards,
Roland Pibinger

 

[Lionel B]

Apart from being later (partially) incorporated into the C++ Standard
both libraries presented something 'new' and 'cool' at the time they
were make public. In the early nineties iostreams came out with OO
design and fancy operator overloadings, in the mid nineties STL used a
value-oriented, anti-OO, generic 'paradigm' influenced by functional
programming. If they were not ennobled by the C++ Standard you would
hardly find those libraries in current C++ code.

Right! Of course I'd much rather use printf instead of std::cout <<, char*
instead of std::string, double* instead of std::vector<double>, ... but
hey, they're part of the C++ standard, so I'd better use them.

Piffle.

 

[Dizzy]

Right! Of course I'd much rather use printf instead of std::cout <<, char*
instead of std::string, double* instead of std::vector<double>, ... but
hey, they're part of the C++ standard, so I'd better use them.

What you would prefer to use is very subjective of course but in the listed
cases there are clear technical advantages of using:

1. std::cout << instead of printf: mainly type safety and optimization
(better runtime speed), ie why not use the compile time lookup matching
types and argumets when looking for overloaded functions than telling
printf what types you will list (where you may get it wrong while the
compiler won't) also the same compiled code made to deal with various
things is generally worse optimizable than specific code ment to work with
specific types (ie an overloaded version of << than a general printf())

2. std::string instead of char*: providing safer method for string
manipulation (when not explicitely providing lengths for example) plus
simple things like always knowing the size of the string (and not having to
repeatedly call strlen() which is a O(n) operation)

3. std::vector<double> instead of double* (I supose you actually mean
instead of a C array of double because it's not the same thing with a
pointer in general thus no comparation is possible in general): not many
people know that the standard mandates that &v[0] is a contigous array that
can be manipulated externally (thus most people that wanted a C array
because they needed to work with legacy APIs can do it with std::vector
just fine) or that (most) implementations have specializations for using
std::copy() on std::vector::iterator and that in fact they actually call
memcpy and such in the cases where that is possible, etc

 

[Lionel B]

Sorry if it wasn't clear:


</irony>

[snip]

 

[Dizzy]

Sorry if it wasn't clear:



</irony>

Got me on that, I didn't fully read the quoted statement above (lost me
arround "new and cool at the time") thus did not realised the irony...

 

[Noah Roberts]

Sorry if it wasn't clear:



</irony>

Unfortunately there are those that feel this way and advocate prefering
such types even given the long list of technical reasons not to.

 

[Roland Pibinger]

Right! Of course I'd much rather use printf instead of std::cout <<, char*
instead of std::string, double* instead of std::vector<double>, ... but
hey, they're part of the C++ standard, so I'd better use them.

As if C Standard libraries were the only imaginable alternatives to
STL and iostreams - probably for you.

 

[Lionel B]

As if C Standard libraries were the only imaginable alternatives to
STL and iostreams - probably for you.

Yes, there are "imaginable alternatives": I could use C-style I/O (but I
find it clunkier and more error-prone than C++-style I/O). I could use raw
pointers and do my own memory allocation (but I find it clunkier and more
error-prone than eg. std::vector). I could write my own I/O wrappers or
containers (but life is too short to re-invent wheels). I could use
third-party I/O systems or containers or "semi-standard" libraries like
Boost (I occasionally do if they offer some advantage/functionality over
the standard facilities).

So I use C++-style I/O and standard containers because:

1) They work very nicely for me.

2) They are standard! Therefore my code is far more likely to be
comprehensible to others than non-standard stuff.

3) I don't want to re-invent wheels.

4) I have invested a good deal of time and effort to familiarise myself
with their paradigms and learn their usage.