3. C++ nach ISO Standart

C++ nach ISO Standart

  • E

    Zunächst mal: Ruhig Blut! So wichtig ist der Standard nun auch wieder nicht, dass man sich gleich schämen muss, wenn man die volle Bandbreite anwendet. Also, wenn Du die richtigen Header <iostream> <cmath> und die using (namespace ...) Deklarationen/Direktiven verwendest, die C++-casts einsetzt, const-correctness anwendest, int main(){...} schreibst, return 0 weg lässt, macht das schon mal einen guten Eindruck.

    #include <iostream> 
using namespace std; 

int main() 
{ 
    const double PI = 3.141592; 
    double r, v; 
    cout << "Bitte Radius eingeben." << endl;  
    cout << "Radius = "; 
    cin  >> r;  
    v = 4.0 / 3.0 * PI * r * r * r ;  
    cout << "Das Volumen betraegt " << v << endl;  
 }

    Richtig gut werden die Programme mit Einsatz der STL, da dies viele Fehler vermeidet (memory leaks, überflüssige temporäre Kopien, ...) und durch Verwendung der für C++ typischen Konzepte (OOP, Templates, Exceptions, namespaces, ...).

    Hier einige Tipps für diese drei Bereiche:

    Standard: http://home.arcor.de/cpp_kurs/cpp/toc.htm
    Strasser, C++ Programmieren mit Stil (2.(!) Auflage)

    STL: Nicolai M. Josuttis, The C++ Standard Library, Addison Wesley

    Konzepte: Das Buch von Marc++us, Scott Meyers, Herb Sutter, Andrei Alexandrescu, "Struppi"(zuletzt!). HumeSikkins Beiträge hier im Forum lesen.

    0
  • W

    Warum denn so dringend das return 0; weglassen. Ist doch vom Standard her Jacke wie Hose...

    0
  • S

    [quote="Erhard Henkes"]Zunächst mal: Ruhig Blut! So wichtig ist der Standard nun auch wieder nicht, dass man sich gleich schämen muss, wenn man die volle Bandbreite anwendet. Also, wenn Du die richtigen Header <iostream> <cmath> und die using (namespace ...) Deklarationen/Direktiven verwendest, die C++-casts einsetzt, const-correctness anwendest, int main(){...} schreibst, return 0 weg lässt, macht das schon mal einen guten Eindruck.[quote]

    aaahh!! ich will auch nach iso standard coden. ich hab mit c++ in 21 tagen aber gelernt das man return 0; schreiben sollte. was soll ich denn nun glauben?? 😕

    und ausserdem: wo ist der unterschied zwischen <iostream.h> (so hab ichs gelernt und mach ichs auch) und <iostream>?? bzw. was ist "schöner"??

    0
  • W

    Schöner ist <iostream> weil es im Standard ist.

    0
  • R

    return 0; kannst du am Ende von main weglassen. iostream.h gibt es laut Standard nicht und du solltest es nicht mehr benutzen

    http://fara.cs.uni-potsdam.de/~kaufmann/?page=GenCppFaqs&faq=iostream#Answ

    0
  • E

    Die besten Antworten auf offene Fragen findet man im C++-Standard (INTERNATIONAL STANDARD ISO/IEC 14882 First edition 1998-09-01) selbst:

    3.6.1 Main function [basic.start.main]
    "A return statement in main has the effect of leaving the main function (destroying any objects with automatic storage duration) and calling exit with the return value as the argument. If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;"

    Man sieht also, dass man "return 0;" am Ende von main(){...} weglassen kann. Der Compiler ergänzt dies automatisch (MSVC++ 6 motzt allerdings noch, ab MSVC++ 7 ist das o.k.). Es ist allerdings auch nicht verboten, diese Zeile zu schreiben. Überflüssiges sollte man IMHO weglassen. 😉

    17.4.1.2 Headers [lib.headers]
    "The elements of the C++ Standard Library are declared or defined (as appropriate) in a header. The C++ Standard Library provides 32 C++ headers, as shown in Table 11:

    Table 11 — C++ Library Headers
    <algorithm> <iomanip> <list> <ostream> <streambuf> <bitset> <ios> <locale> <queue> <string> <complex> <iosfwd> <map> <set> <typeinfo> <deque> <iostream> <memory> <sstream> <utility> <exception> <istream> <new> <stack> <valarray> <fstream> <iterator> <numeric> <stdexcept> <vector> <functional> <limits>

    The facilities of the Standard C Library are provided in 18 additional headers, as shown in Table 12:

    Table 12 — C++ Headers for C Library Facilities
    <cassert> <ciso646> <csetjmp> <cstdio> <ctime> <cctype> <climits> <csignal> <cstdlib> <cwchar> <cerrno> <clocale> <cstdarg> <cstring> <cwctype> <cfloat> <cmath> <cstddef>

    Except as noted in clauses 18 through 27, the contents of each header cname shall be the same as that of the corresponding header name.h, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause 7), or ISO/IEC:1990 Programming Languages—C AMENDMENT 1: C Integrity, (Clause 7), as appropriate,
    as if by inclusion. In the C++ Standard Library, however, the declarations and definitions (except for names which are defined as macros in C) are within namespace scope (3.3.5) of the namespace std."

    Der aktuelle Dev-C++ motzt inzwischen, wenn man iostream.h verwendet; MSVC++ 6 akzeptiert beides.

    0
  • S

    Erhard Henkes schrieb:

    Der aktuelle Dev-C++ motzt inzwischen, wenn man iostream.h verwendet

    also davon hab ich noch nichts bemerkt 🙄 welche meinst du?? 4.980??
    ok <iostream> und nicht <iostrem.h>. und return 0; ist nicht zwangsläufig 🙂

    edit: sorry hab nicht das gemeint was ich geschrieben hab 🙄

    0
  • R

    <iostream> ist zwangsläufig!

    0
  • E

    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.

    0
  • R

    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

    0
  • E

    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)

    0
  • E

    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.

    0
  • R

    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.

    0
  • E

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

    0
  • S

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

    0
  • E

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

    0
  • S

    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????

    0
  • M

    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.

    0
  • W

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

    0
  • R

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

    0
Anmelden zum Antworten