Re: #include <iostream> mit std-Namespace oder #include <iostream.h> ohne Namespaces besser?

On Jun 22, 10:49 pm, Stefan Reuther <stefan.n...@arcor.de> wrote:
> Lars Rohwedder wrote:
> > Thomas Maeder <jvxexluzr...@mailinator.com> wrote:
> >>[...]
> >>Gemäss dem gegenwärtigen Standard musst Du auch <istream>
(für
> >>std::cin) und <ostream> (für std::cout) #includen, aber viele
> >>C++-Implementationen #includen diese beiden Header mit <iostream>
> >>gleich mit.

> > [27.3] sagt etwas anderes. Dort werden in <iostream> die
> > Standard-Ein- Ausgabestreams deklariert:

> > ----<snip>----
> > namespace std {
> >    extern istream cin;
> >    extern ostream cout;
> [...]
> > }
> > ----<snap>----

> > Dafür müssen natürlich die Datentypen (w)istream und (w)ostream
> > definiert sein.

> Natürlich nicht. Dazu reicht es, wenn diese Datentypen
> _deklariert_ sind (salopp: "class istream;").

Na ja, ein bisschen komplizierter ist es wohl, weil istream
keine Klasse ist, sondern ein typedef. Immerhin...

> Damit würdest du
> zwar Zugriff auf das Objekt 'cin' haben und könntest es z.B.
> an eine Referenz binden, aber sonst nichts damit anstellen,
> weil die Memberfunktionen fehlen. Das wäre nach dem aktuellen
> Sprachstandard legal.

> Aber wie James schon sagte, alle existierenden Bibliotheken
> deklarieren die Typen nicht nur, sondern definieren sie
> tatsächlich, so dass diese Diskussion rein akademisch ist,
> eben weil der nächste Standard dieses existierende Verhalten
> fordern wird.

Historisch hat ISO die alte <iostream.h> verteilt, auf dem
Grund, man wollte nicht alles einschleppen, nur weil man ostream
braucht (also <ostream>), oder besonders in einem Header, nur
weil man Referenzen auf istream und ostream verwendet (also
<iosfwd>). Soweit so gut; bei <iostream> hat es immer zwei
Betrachtungsweisen gegeben. Viele, wie ich, haben es im selben
Sinn betrachtet, und etwas wie:

#include <iosfwd>
namespace std {
extern istream cin ;
//  ...
}

erwartet; man includiert <iostream>, weil man std::cin oder
std::cout braucht, und in der Praxis, in echten
Andwendungsprogrammen kommt es selten vor, dass man std::cout
und die << Operatoren in derselben Source brauchen. Andere aber
(darunten Bjarne Stroustrup) haben es als direkten Ersatz für
<iostream.h> betrachtet, und erwartet, dass es auch <istream>,
<ostream> u.s.w. includiert.

Mir wäre es eigentlich lieber gewesen, wenn die erste
Interpretation sich durchgesetzt hätte. Dazu scheint es mir der
eigentlichen Wörtern der Norm besser zu entsprechen. Es ist aber
nicht so passiert---in der Tat haben alle Implementierungen die
zweite Version implementiert, viele Bücher und Artikeln davon
ausgegeben, u.s.w. Also habe ich dem Normierungsausschuss den
Vorschlag gemacht, die Norm an die »existing practice«
anzupassen. Vorschlag, der sofort angenehmen wurde.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
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
[ Auf dieses Posting antworten ]