C+ statt C++
-
Naja, aber der Aufwand ist bei structs größer, um das zu bewerkstelligen.
-
häh?
Leute, offenbar ist vielen von euch nicht bewusst, dass structs und Klassen (deshalb hab ich es auch so provokant geschrieben) das selbe sind.
Sie werden auch genau so wie Klassen benutzt. Der einzige mir bekannte Unterschied ist der, den MaSTaH erwähnt hat.
-
Schon klar, aber es ist doch unbestritten schwieriger, Membervariablen in structs private zu machen als in Klassen, oder nicht?!
-
Warum ist das schwieriger? Du schreibst genauso public: und private: hin. Es ist genau gleich.
Nur die Voreinstellung, wenn du nichts hinschreibst, ist anders.
-
Äh...
Ja, ganze 8 Zeichen (private:) schwieriger. :p// struct mit privaten Membervariablen: struct foo { private: T bar; }; // aequivalente Klasse: class foo { T bar; };Im Ernst: structs SIND tatsächlich äquivalent zu Klassen, mal von dieser Kleinigkeit mit private/ public abgesehen.
-
struct und class sind das gleich... wird auch beim compilieren gleich behandelt. Es gibt also theoretisch keinen Unterschied. Allerdings macht man bei einem struct deutlich "Hey, hier handelt es sich um eine reine Datenstruktur, der ich gerne nur public-Members zur Verfügung stellen will!" Wenn ich keine reine Datenstruktr haben will, nehme ich ein class.
Es ist eine reine Design-Frage und was ich damit "Aussagen" will.
-
@nman
also das die gleich sind wage ich zu bezweifeln bis ich nicht ASM code von den beiden beispielen gesehen habe
Erst ab dann kann man sagen sie seien "äquivalent"
-
*** schrieb:
also das die gleich sind wage ich zu bezweifeln bis ich nicht ASM code von den beiden beispielen gesehen habe
Erst ab dann kann man sagen sie seien "äquivalent"Du wirst nicht den Assemblercode davon zu sehen bekommen, weil es den nicht gibt. Die beiden Konstrukte sind äquivalent, weil der C++ Standard das so definiert, Punkt. Wenn irgendein Compiler dafür unterschiedlichen Code generiert, ist das sein Problem.
-
gh0st124 schrieb:
Shlo schrieb:
gh0st124 schrieb:
Klassen sind wie Strukturen, können aber einiges mehr...
zum Beispiel?
o Methoden aufnehmen;
o Einzelne Elemente verstecken (Zugriffsspezifikationen a la private - public - protected;ich würde dir ganz dringend raten ein gutes C++ Buch zur Hand zu nehmen und es auch zu lesen
-
Es gibt sowieso keinen Assembler-Code für "Strukturen" oder "Klassen", weil das Ganze eine reine Vorstellungssache ist.
Soweit ich weiss, ist lediglich vorgeschrieben, wie die Elemente im Speicher zu liegen haben und mehr nicht. Die Methoden haben genau genommen nach dem Compilieren auch nichts mehr mit den Daten selber zu tun, bzw. gehören nicht zu den Daten, wie es so schön dargestellt wird.
-
Optimizer schrieb:
Es gibt sowieso keinen Assembler-Code für "Strukturen" oder "Klassen", weil das Ganze eine reine Vorstellungssache ist.
Soweit ich weiss, ist lediglich vorgeschrieben, wie die Elemente im Speicher zu liegen haben und mehr nicht. Die Methoden haben genau genommen nach dem Compilieren auch nichts mehr mit den Daten selber zu tun, bzw. gehören nicht zu den Daten, wie es so schön dargestellt wird.Es ist sogar noch nicht mal vorgeschrieben, wie die Elememnte im Speicher vorliegen. Stichwort alignment!
-
tobidope schrieb:
Es ist sogar noch nicht mal vorgeschrieben, wie die Elememnte im Speicher vorliegen. Stichwort alignment!
Die Reihenfolge innerhalb eines Sichtbarkeitsbereiches (public, private, protected) schon.
-
Die Reihenfolge innerhalb eines Sichtbarkeitsbereiches (public, private, protected) schon.
Hat das eigentlich irgend einen tieferen Sinn?
-
Helium schrieb:
Die Reihenfolge innerhalb eines Sichtbarkeitsbereiches (public, private, protected) schon.
Hat das eigentlich irgend einen tieferen Sinn?
Ich nehme an, es kommt von den C structs, denn dort war es ja wichtig...
Um ehrlich zu sein, sehe ich aber, ausser bei den C structs den Sinn auch nicht.
-
Wo ist denn bei C-structs der tiefere Sinn?
-
also ich muss ja mal sagen: wer stucts wie klassen benutzt ist pervers !
natürlich kann man structs wie klassen verwenden. man kann alle möglichen sachen missbrauchen, aber es geht nun einmal um die grundlegende eigenschaft der programmkapslung.
-
warum pervers? Das ist eben deine Vorstellung von structs. Aber ich sehe keinen logischen Grund darin. ich mach das immer so, dass ich structs nehme, wenn ich erst public Member einrichten musst (zB. enum-Konstanten). Warum sollte ich dann erst class schreiben um dann ein public einzufügen?
-
klassen sind nunmal klassen und structs sind structs und das sollten sie auch bleiben. wenn jemand deine programme liest und sieht, dass du structs benutzt, wird er zunächst davon ausgehen, dass es ein struct im C-sinn ist. ich versteh eh nicht warum man structs so "aufgemotzt" hat.
es gibt aber notationen an die man sich auch halbwegs halten sollte. ich habe (viel) früher auch mal unterstriche und für andere scheinbar sinnlose regeln benutzt um meine funktionen, variablen & co zu benennen und habe es als "meinen programmierstil" bezeichnet, aber solche einzelaktionen helfen im endeffekt niemandem.
-
Das hängt davon ab ob dieser Programmierer viel C gemacht hat. Er könnte auch mit C++ groß geworden sein oder von einer anderen Sprache her kommen.
Structs sind eine feine sache wenns um Ansammlung von Variablen geht (wie in C) oder um Funktoren etc. zu schreiben.
Also kleine,einfache Funktionalitäten abbilden.
-
komischer kautz schrieb:
klassen sind nunmal klassen und structs sind structs und das sollten sie auch bleiben. wenn jemand deine programme liest und sieht, dass du structs benutzt, wird er zunächst davon ausgehen, dass es ein struct im C-sinn ist. ich versteh eh nicht warum man structs so "aufgemotzt" hat.
Einige Leute neigen dazu die eigenen Eindrücke auf andere Menschen zu übertragen. Wie ich bereits sagte, dir gefällt es nicht und du hast damit wohl Probleme. Aber deswegen muss man keine allgemein gültige Moral darauf aufbauen.