Struct oder Class?
-
sirchillalot schrieb:
Aber ich kann doch auch in einem Struct alles Private machen und hab so wieder ein saubere OOP konzept?!
Ich habe absichtlich nicht das Wort "struct" verwendet sondern "Datenstruktur". Und nein, wenn man in einer "Datenstruktur" alles privat macht, hat man kein sauberes OOP-Konzept (Da dann die Möglichkeit der Funktionszugriffe fehlen).
-
asc schrieb:
sirchillalot schrieb:
Aber ich kann doch auch in einem Struct alles Private machen und hab so wieder ein saubere OOP konzept?!
Ich habe absichtlich nicht das Wort "struct" verwendet sondern "Datenstruktur". Und nein, wenn man in einer "Datenstruktur" alles privat macht, hat man kein sauberes OOP-Konzept (Da dann die Möglichkeit der Funktionszugriffe fehlen).
Ok klar Datenstruktur ist was anderes.
Aber wenn ich jetzt von Structs ausgehe, die können dann doch auch Methoden haben.
Allg. handhabe ich es aber auch das ich Strukts als reine Datenstrukturen nutze.
-
@asc,
berniebutt hat aber vonstructgeredet und nicht von Datenstrukturen.@berniebutt,
Hast du dich womöglich verschrieben und Datenstrukturen gemeint? Dennstructhat keine Nachteile gegenüberclass. Alles wasclasskann, kann auchstructin C++. Die zwei sind grundsätzlich völlig identisch, ausser dass haltclassper Standardprivateist undstructper Standardpublic. C++ macht keine weitere Unterscheidung.Ich persönlich verwende allerdings auch im allgemeinen
classfür Klassen undstructfür Daten- und Hilfsstrukturen. Aber ich habe schon Leute erlebt, welche nurstructverwendet haben oder auch umgekehrt. Die Verwendung von beiden und in der Bedeutung umgekehrt (classals Datenstruktur,structals Klasse) habe ich allerdings noch nie gehört
Daher denke ich schon, dass man es auch ein wenig als Stil bezeichnen kann, was man nun verwendet.Grüssli
-
Was meint ihr denn mit Datenstrukturen? Ein AVL-Baum ist eine Datenstruktur. Ich würde jetzt nicht auf die Idee kommen, dafür zwingend oder überhaupt
structzu verwenden. Auch würde ich nicht sagen, dass man sowas in der OOP nicht hat.
-
Bashar schrieb:
Was meint ihr denn mit Datenstrukturen? Ein AVL-Baum ist eine Datenstruktur.
Guter Wink. Ich benutze
structnämlich oft dort, wo man es tatsächlich als Datenstruktur anschauen kann. Nämlich als tuple (so, wie rüdiger es auch macht).Ich denke oben wurde mit Datenstruktur eher ein solches tuple (strukturierte Daten) gemeint und nicht Datenstrukturen (Listen, Bäume usw.), wie man sie herkömmlicherweise kennt.
-
drakon schrieb:
Ich denke oben wurde mit Datenstruktur eher ein solches tuple (strukturierte Daten) gemeint und nicht Datenstrukturen (Listen, Bäume usw.), wie man sie herkömmlicherweise kennt.
Ja, hätte wohl PODs schreiben sollen, aber damit können Anfänger in der Regel noch weniger anfangen.
-
Dravere schrieb:
@asc,
berniebutt hat aber vonstructgeredet und nicht von Datenstrukturen.
@berniebutt,
Hast du dich womöglich verschrieben und Datenstrukturen gemeint? Dennstructhat keine Nachteile gegenüberclass. Alles wasclasskann, kann auchstructin C++. Die zwei sind grundsätzlich völlig identisch, ausser dass haltclassper Standardprivateist undstructper Standardpublic. C++ macht keine weitere Unterscheidung.
GrüssliMan hätte in C++ die Definition des Schlüsselwortes struct besser bei der Bedeutung aus ANSI-C belassen. Dann wäre die Diskussion hier überflüssig. So bleiben Unklarheiten und werden dem Programmierstil überlassen.
-
Ist wohl jetzt etwas OT, trotzdem ein Wink in Richtung
Da ist ein erheblicher Unterschied zwischen struct und class.
struct ist ein Value-Type, es wird das Objekt bei Zuweisung kopiert. Class ist ein Reference-Type, Da wird bei Zuweisung nur Referenziert (wie auch in java).
Für struct gibt es keine Vererbung, daher auch keine virtuellen Funktionen.
struct hat aber trotzdem (wie auch class) per default private Members!
Sind denke ich die entscheidensten Unterschiede. Hier gibts eine Übersicht:
http://www.digitalmars.com/d/2.0/struct.html
-
EDIT: Ah, okay... "D"... hielt das für einen verkorksten Smiley.
-
berniebutt schrieb:
Man hätte in C++ die Definition des Schlüsselwortes struct besser bei der Bedeutung aus ANSI-C belassen. Dann wäre die Diskussion hier überflüssig. So bleiben Unklarheiten und werden dem Programmierstil überlassen.
Man hätte IMO das Schlüsselwort class gar nicht einführen sollen, da struct schon alles kann, was class kann. Die defaults bei der Sichtbarkeit und Vererbung sind egal, da man sowieso (ich zumindest) explizit private und public hinschreibt.
Aber dann hätte man das ja nicht C with classes nennen können und hätte im OOP-Hype der frühen 90er keine so große Rolle gespielt, und die Geschichte wäre ganz anders verlaufen
-
Bashar schrieb:
Man hätte IMO das Schlüsselwort class gar nicht einführen sollen...
Ich hätte es besser gefunden wenn struct nur POD-Typen zugelassen hätte, dann wäre der Unterschied auch eindeutig.
-
Oder noch einfacher: Man liest einmal drüber, merkt sich das. Fertig.
-
asc schrieb:
Bashar schrieb:
Man hätte IMO das Schlüsselwort class gar nicht einführen sollen...
Ich hätte es besser gefunden wenn struct nur POD-Typen zugelassen hätte, dann wäre der Unterschied auch eindeutig.
Das wäre hammermässig gewesen. Dann hätte der Kompiler einem gleich noch sagen können, ob es denn nun ein gültiger POD-Typ ist oder nicht, bzw. eine Fehlermeldung ausgeben, wenn dies nicht der Fall wäre.
Aber so bleibt einem halt nichts anderes übrig, also dieser Designfehler über den Programmierstil zu korrigieren und am Ende darüber zu debattieren, was nun der bessere Stil ist
@l'abra d'or,
Wozu dieses Off-Topic? Das hat ja wirklich überhaupt nichts mehr mit dem Thema zu tun. Könnte man zum Beispiel auch zu C# sagen, aber was solls? Wozu?
Grüssli
-
Dravere schrieb:
@l'abra d'or,
Wozu dieses Off-Topic? Das hat ja wirklich überhaupt nichts mehr mit dem Thema zu tun. Könnte man zum Beispiel auch zu C# sagen, aber was solls? Wozu?Sry. Es ging hier doch auch irgendwo um den Unterschied zwischen struct und class, und wie man es in C++ hätte besser machen können. Da dachte ich wäre ein kleiner Blick in Richtung D nicht uninteressant. Da ich keinen Peil von C# habe, kann ich dazu auch nix sagen...
-
l'abra d'or schrieb:
Ist wohl jetzt etwas OT, trotzdem ein Wink in Richtung
Da ist ein erheblicher Unterschied zwischen struct und class.Leider kam D um viele Jahre zu spät. Ich bin der Meinung, man hätte struct nicht übernehmen sollen. Und viele andere C-Unsicherheiten auch nicht, Pointer, implizite Konvertierungen, die C-Libray, ...
-
l'abra d'or schrieb:
Dravere schrieb:
@l'abra d'or,
Wozu dieses Off-Topic? Das hat ja wirklich überhaupt nichts mehr mit dem Thema zu tun. Könnte man zum Beispiel auch zu C# sagen, aber was solls? Wozu?Sry. Es ging hier doch auch irgendwo um den Unterschied zwischen struct und class, und wie man es in C++ hätte besser machen können. Da dachte ich wäre ein kleiner Blick in Richtung D nicht uninteressant. Da ich keinen Peil von C# habe, kann ich dazu auch nix sagen...
Nur gibt es in C++ diesen Unterschied zwischen Referenz-Typen und Value-Typen nicht. Daher könnte man in C++ diese Möglichkeit von D gar nicht einführen. Ich verstehe somit nicht, auf was du damit hinaus wolltest.
Grüssli
-
<off-topic>
C++Fan 2010 schrieb:
Leider kam D um viele Jahre zu spät.
Leider gibt's keine gute Umsteiger-Doku zu D. Ich meine, Walter Bright hat sicherlich ein Interesse, D an die Leute zu bringen. Zumindest meldet er sich ab und zu in der ein oder anderen C++ Diskussion und macht Werbung für D. Er sollte stattdessen mal etwas Zeit investieren, auf seiner Homepage etwas zu bringen, was auch überzeugt. Listen von Sprach-Features und Beispiele sind langweilig. Das ist genau der falsche Ansatz. Ich habe bisher noch kein Buch über D in der Hand gehabt. Aber soweit haben sie mich noch nicht, dass ich mir so etwas besorgen würde. Sorry, aber das, was ich von D so inzwischen mitbekommen habe, macht auf mich nicht den Eindruck, es handele sich um ein stimmiges Design. Der Fokus auf "nette Features" ist eher abschreckend.
C++Fan 2010 schrieb:
Ich bin der Meinung, man hätte struct nicht übernehmen sollen.
Wieso das denn?
structschadet C# auch nicht.C++Fan 2010 schrieb:
Und viele andere C-Unsicherheiten auch nicht, Pointer, implizite Konvertierungen, die C-Libray, ...
Klingt so, als wäre Java sehr nah an Deinem Ideal.
</off-topic>
-
Sebastian Pizer schrieb:
Ich habe bisher noch kein Buch über D in der Hand gehabt. Aber soweit haben sie mich noch nicht, dass ich mir so etwas besorgen würde.
So was ich auf seiner Homepage gelesen hab ist er recht begeistert.
-
Wir leben nun einmal damit, dass das Design neuer Compiler auf bekanntem alten aufbauen muss. Anders wird neueres nicht akzeptiert oder mangels fehlender Kompatibilität sofort verworfen. Fellhuhn hat recht, man liest das und fertig! Oder anders gesagt: Jeder Compiler ist nur ein Hilfsmittel zur Programmierung - was man mit diesem Hilfsmittel macht, bleibt die eigene Angelegenheit. Also, konzentriert Euch besser auf den sauberen Entwurf Eurer Programme!
-
Ich finde die Schlüsselwörter
structundclassgut so, wie sie sind. Ich halte es für nützlich, voll gekapselte Klassen durch das Schlüsselwort schon von Datenbündeln/Funktoren/Metafunktionen zu unterscheiden.Für
structnur PODs zuzulassen ist meiner Meinung nach – zumindest bei der momentanen Definition von POD – nicht besonders sinnvoll, weil man zum Beispiel auf Konstruktoren verzichten muss (welche ich doch recht häufig beistructeinsetze). Wenn mans wissen will, existiert ja nochis_podaus Boost.TypeTraits.
