C++ nach ISO Standart

rüdiger

<iostream> ist zwangsläufig!

Erhard Henkes

Also da hilft nur testen:
Compiler: Dev-C++ 4.9.8.2

#include <iostream.h>
main()
{
  cout << "hello, world" << endl;
}

Compiler-Warnung:
"C:/Dev-Cpp/include/c++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated."

Ist das nicht ein freundlicher Compiler? Er verweist sogar auf den korrekten Abschnitt im C++-Standard (s.o.). Ich kann den Dev-C++ nur empfehlen.

rüdiger

1. Dev-C++ ist eine IDE und kein Compiler, der Compiler ist der mingw, was ein GCC Port ist
2. liegt das nicht am Compiler, sondern an der zugehörigen Std-Library (vermutlich auch die GNU c++-stdlib), weil einfach nur in iostream.h ein #warning gesetzt wurde

Aber ich muss dir Recht geben, der GCC ist der beste Compiler

Erhard Henkes

Stimmt, da war ich schlampig. Korrekt: Dev-C++ 5.0 beta 8 (version 4.9.8.2), includes full Mingw compiler system (GCC 3.2)

Erhard Henkes

Das Problem ist, dass die Bücher den Standard nicht sauber zitieren. Daher wissen viele Anwender nicht, was wirklich Sache ist. Der Standard ist die wichtigste Primärliteratur. Er ist nach einiger Gewöhnung übrigens gut lesbar.

rüdiger

Der Standard ist IMHO keine Primärliteratur. Ich lese ihn nur, wenn ich mir in einer Sache wirklich nicht sicher bin oder mir langweilig ist, aber ansonsten brauch man den IMHO nicht zu lesen.

Erhard Henkes

Der Standard ist IMHO keine Primärliteratur.

Primärliteratur bedeutet hier nicht Einsteigerliteratur, sondern erste und damit wichtigste Quelle für Informationen. Wo findet man die Entwicklung von C++ knapper und präziser beschrieben als im Standard? Siehe:

1.10 Acknowledgments [intro.ack]
"The C++ programming language as described in this International Standard is based on the language as described in Chapter R (Reference Manual) of Stroustrup: The C++ Programming Language (second edition, AddisonWesley Publishing Company, ISBN 0– 201– 53992– 6, copyright 1991 AT&T). That, in turn, is based on the C programming language as described in Appendix A of Kernighan and Ritchie: The C Programming Language (PrenticeHall, 1978, ISBN 0– 13– 110163– 3, copyright 1978 AT&T). 2 Portions of the library clauses of this International Standard are based on work by P.J. Plauger, which was published as The Draft Standard C++ Library (PrenticeHall, ISBN 0– 13– 117003– 1, copyright 1995 P.J. Plauger)."

Shade Of Mine

also ich schau recht selten in den standard.
da lese ich lieber CUJ-Artikel oder n gutes Buch. da lernt man mehr dabei.

Erhard Henkes

Der Standard bietet das solide Fundament. Nicht mehr und nicht weniger.
Alles andere findet man in der Sekundärliteratur, die aber nur dann gut ist, wenn sie nicht gegen den Standard verstößt. Um dies beurteilen zu können, muss man den Standard beherrschen. Dazu muss man ihn lesen.

sili

edit: @ Erhard Henkes
: hmmm hab mich ja schon gefragt warum das bei mir nicht so is du benutzt eine neuerer version :p (ich benutze zwar 4.970 die 4.980 dauert mir viel länger zum kompilieren und die gefällt mir auch sonst nicht so...)

ich hab jetzt gerade mal beom "struppi" im register nachgeschlagen: die meisten header dateien sind ohne die endung (z.b. ctime,...) aber es gibt auch dateien die mit endung notiert sind: ctype.h assert.h und auch die iostream.h . was soll das jetzt?? ich hab im buch einige beispiele gefunden: diese sind wieder ohne endung: #include <iostream>
warum schreibt der im register aber z.t. mit endung????

Marc++us

Erhard Henkes schrieb:

Der Standard bietet das solide Fundament. Nicht mehr und nicht weniger.
Alles andere findet man in der Sekundärliteratur, die aber nur dann gut ist, wenn sie nicht gegen den Standard verstößt. Um dies beurteilen zu können, muss man den Standard beherrschen. Dazu muss man ihn lesen.

Ich weiß nicht. Ich lese den Standard nur, wenn Hume nicht mehr weiter weiß.

Das ist ja, wie wenn ich eine Fremdsprache dadurch lernen könnte, indem ich ein Grammatikbuch lese. Beim sprechen hilft mir das aber nicht viel weiter.

Vor allem schreibt der Frager ja, daß er einen saumäßigen Stil hat.

Ok, iostream.h ist das eine.

Aber das macht den Stil nicht aus.

Laut ISO-C++-Standard ist der folgende Code völlig legal:

class beispiel
{
public:
   int value;
   virtual void DOSomething(otherclass obj) = 0;
   beispiel() {};
protected:
   otherclass* PTRobj;
};

Trotzdem enthält der Code potentielle Fehler und Schwachstellen auf unterschiedlicher Ebene, inklusive einer ungeschickten Namensgebung.

Ich wüßte nun absolut nicht, wie man dies mit Hilfe des Standards beheben könnte.

Und wenn ich nun ein Buch vorliegen hätte, in dem zwar iostream.h verwendet wird, aber wenigstens erklärt wird warum man Copycons braucht und flache Kopien zu Problemen führen können, dann lernt der Leser doch mehr daraus als aus einem konformen Buch, wo dies aber schlecht erklärt wird.

Walli

Erhard Henkes schrieb:

Alles andere findet man in der Sekundärliteratur, die aber nur dann gut ist, wenn sie nicht gegen den Standard verstößt. Um dies beurteilen zu können, muss man den Standard beherrschen. Dazu muss man ihn lesen.

Naja, es soll auch Leute geben die Telefonbücher lesen .

RHBaum

Da wir ja grad beim Thema sind ....

Ich schaem mich auch manchmal ...
Ich benutz haeufig so wilde Sachen wie :

char * strbuffer = new char[100];
sprintf("[%2.2d:%2.2d:%2.2d.%3.3d.%3.3d]",ihour,imin,isec,imillisec,imicrosec);
std::string strOutput = strbuffer;
delete strbuffer;

Mal davon abgesehen, das ich den String einmal unnoetig kopiere, sagen doch viele, das das Design mies ist, weil hier C und C++ gemischt sind. (kann man das ohne grossen performanceverlusst auch steuck fuer Steuck in nen Stream schieben ? )

Nur wie macht mans richtig ? Und gibt es nen Buch wo man ueber solche Design-Sachen lesen kann.
Ist das C++ Design dann ploetzlich ok, wenn man die Stringklasse einfach mit Funktionen aufbohrt, die C Standards verwenden ?
Ist Mehrfachvererbung (ohne das man nen grosses Framework ala MFC,QT,VCL hat) nen gutes Design ?

Ciao ...

Marc++us

RHBaum schrieb:

Da wir ja grad beim Thema sind ....

Ich schaem mich auch manchmal ...
Ich benutz haeufig so wilde Sachen wie :
char * strbuffer = new char[100];
sprintf("[%2.2d:%2.2d:%2.2d.%3.3d.%3.3d]",ihour,imin,isec,imillisec,imicrosec);
std::string strOutput = strbuffer;
delete strbuffer;
Mal davon abgesehen, das ich den String einmal unnoetig kopiere, sagen doch viele, das das Design mies ist, weil hier C und C++ gemischt sind. (kann man das ohne grossen performanceverlusst auch steuck fuer Steuck in nen Stream schieben ? )

Ganz unter uns - wenn mich keiner sieht formatiere ich meine Strings auch in C++ gerne noch mit sprintf.

Dieser ganze iomanip-Quatsch ist so umständlich und unübersichtlich, gerade wenn man Zeilen mit Zahlen und Text gemischt erzeugen will, das ist ein Kreuz. Und ich habe dann auch keine Lust immer irgendwelche Boost&Co-Sachen zu verwenden.

Aber wie gesagt - das habe ich nie gesagt.

Apropos - das hat wohl vielen nicht gefallen - C# besitzt eine Variante für Stringformatierungen wie bei printf, aber mit einer echten Typsicherheit. Dies gefällt mir auch sehr gut.

Shade Of Mine

Sili schrieb:

hmmm hab mich ja schon gefragt warum das bei mir nicht so is du benutzt eine neuerer version :p (ich benutze zwar 4.970 die 4.980 dauert mir viel länger zum kompilieren und die gefällt mir auch sonst nicht so...)

hae?
Dev-C++ ist eine IDE - du kannst dir auch die binaries runterladen, dann musst du nix kompilieren. Wobei Delphi sowieso nicht lange zum kompilieren brauchtb

ich hab jetzt gerade mal beom "struppi" im register nachgeschlagen: die meisten header dateien sind ohne die endung (z.b. ctime,...) aber es gibt auch dateien die mit endung notiert sind: ctype.h assert.h und auch die iostream.h . was soll das jetzt?? ich hab im buch einige beispiele gefunden: diese sind wieder ohne endung: #include <iostream>
warum schreibt der im register aber z.t. mit endung????

math.h ist der C Header
cmath der C++ Header

und jetzt rate mal was der unterschied zwischen den beiden ist

Helium

Nur wie macht mans richtig ?

Guck mal, ob du dich mit boost::formated anfreunden kannst. Marc++us scheinbar nicht, ich finde es ganz gut.

Ist Mehrfachvererbung (ohne das man nen grosses Framework ala MFC,QT,VCL hat) nen gutes Design ?

Das kommt sehr auf die Verwendung an. Wenn du nur von Schnittstellen erbst (komplett abstrakten Basisklassen), hat keiner was dagegen. Wenn du es verwendest, um Policys einzusetzten ist das für C++-Programmierer meistens auch in Ordnung. Ansonsten gibt's Streit. Die einem meinen es ist OK, andere sagen es ist Mist, man hätte es mit ein wenig Nachdenken auch ohne Mehrfachvererbung hinbekommen. Ich schaffe das nie, ohne mir dann das Interface vieler Klassen vollzumüllen. Allerdings kommt das recht selten vor.

Ich mein sowas:

.
       Basis
         |
  +------+------+
Derivat1     Derivat2

Nun merkst du Derivat2 muss aber noch von Foo erben. Was machst du? Die einzige Lösung mit Einfachvererbung sieht so aus:

.
        Foo
         |
       Basis
         |
  +------+------+
Derivat1     Derivat2

Dann ist Derivat1 aber zugemüllt mit irgend 'nem Quatsch, den es gar nicht braucht. Für alle andere Klassen, die man noch von Basis ableitet, gilt das selbe.
Da finde ich die Lösung mit Mehrfachvererbung wesentlich schöner

.
       Basis          Foo
         |             |
  +------+------+------+
Derivat1     Derivat2

Allerdings kommt sowas allgemein extrem selten vor.

Marc++us

Man muß sich manchmal auch auf die Bedeutung besinnen.

Ganz klar: Vererbung heißt "ist ein". Also bedeutet Mehrfachvererbung, daß irgendein Objekt zweimal "ein xx ist". Das kommt vor. Wenn im Modell so ein Objekt vorkommt, dann realisiert man in Gottes Namen das auch mit Mehrfachvererbung, warum nicht. Da man im Modell ja auch ein Abbild von etwas macht, sind die Gefahren wie der Deadly Diamond eher unwahrscheinlich. Trotzdem tut man sich einen Gefallen, wenn man von [siehe Heliums Beispiel] Derivated1 und Derivated2 NICHT mehr weiter ableitet...

Für Interfaces ist es ohnehin ok, für Frameworks sollte man es auch eher vermeiden, weil man nie so genau weiß was die Leute "unten" in der Hierarchie mit dem Framework noch anstellen.

Daniel E.

Helium schrieb:

Da finde ich die Lösung mit Mehrfachvererbung wesentlich schöner
.
       Basis          Foo
         |             |
  +------+------+------+
Derivat1     Derivat2

Ist Foo jetzt das, was unter Mixin in der Werbung läuft?

Marc++us: Dein "völlig legaler Code" von oben, ist leider nicht wirklich konform. (Es gibt C++-Compiler, die spielen da nicht mit [eine Steinzeitversion von Sun mW]).

Erhard Henkes

Marc++us: Ich lese den Standard nur, wenn Hume nicht mehr weiter weiß.

So kann man das auch lösen.

Ich wollte nur darauf hinweisen, dass man im Standard die verbindlichsten Antworten auf formelle Fragen erhält. Konzeptionelle Lösungen findet man im Standard nicht ausreichend. Dafür gibt es hervorragende Tutorials/Bücher, die hier bereits umfänglich zitiert/gelinkt wurden.

Marc++us

Daniel E. schrieb:

Marc++us: Dein "völlig legaler Code" von oben, ist leider nicht wirklich konform. (Es gibt C++-Compiler, die spielen da nicht mit [eine Steinzeitversion von Sun mW]).

Wieso das denn nicht?