C++ nach ISO Standart

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?

ist der dev-c++ 4 näher am Standard als mein vc++6.0?

Es gibt keinen Standard für IDEs.

Daniel E.

Marc++us schrieb:

Daniel E. schrieb:

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?

Das Semikolon nach dem Funktionsbauch des Konstruktors ist pedantischerweise nicht erlaubt. Außer dem besagten Compiler scheint sich da aber (zurecht) niemand dran zu stören.

Bashar

Daniel E.: Wo steht das? Nach der Grammatik ist eine leere Deklaration in einer Klasse erlaubt. 9.2:

class-specifier: class-head { member-specification_opt }

member-specification: member-declaration member-specification_opt

member-declaration: decl_specifier_opt member_declarator_list_opt ;

Wenn man pingelig ist, interpretiert man 9.2.1 "... and each such member-declaration shall declare at least one member name of the class" als Zusatzregel zur Grammatik, dann kommt aber die Ableitung

member-declaration: function-definition ;_opt

zum Tragen.

Daniel E.

Bashar schrieb:

dann kommt aber die Ableitung

member-declaration: function-definition ;_opt

zum Tragen.

Bezieht sich das '_opt' auf das Semikolon oder die 'function-definition'?

(Falls ich danebengelegen haben sollte, habe ich natürlich absichtlich die Unwahrheit gesagt, um hier direkt vor Ort die Nützlichkeit der C++-Norm zu belegen. [So was muss man sich ausdenken, nur weil man ohne nachzusehen postet. <Sowas aber auch.>]) (dreifache Klammerverschachtelung = ein Smiley)

Bashar

auf das Semikolon

Erhard Henkes

@eineFrage: Der Compiler des Dev-C++ (4.9.x.x) ist deutlich näher am Standard als der Compiler des MSVC++6.

HumeSikkins

@Bashar und Daniel E.
Sehe ich das richtig, dass dieses "Semikolon nach Funktionsdefinition erlaubt" nur *innerhalb* einer Klassendefinition gilt, es außerhalb aber verboten ist:

class A
{
public:
void func() {}; // erlaubt
void func2();
};

void A::func2() {}; // verboten

Bitte sagt ja

Bashar

Hume: Öhm, ich hab zwar letzte Woche noch argumentiert, dass die Grammatik das zuläßt:

simple-declaration: decl-specifier-seq_opt init-declarator-list_opt ;

Aber im Text steht, dass die "init-declarator-list" nur weggelassen werden kann, wenn das ganze eine Klasse oder einen Aufzählungstyp deklariert. Schade eigentlich, was ist so schlimm an leeren Deklarationen?