Struct oder Class?
-
sirchillalot schrieb:
Struct ist auch OOP!!!
Eine Datenstruktur ist kein OOP. Dazu gehören noch ein paar Dinge mehr...
Ich finde dazu die Erklärung aus der wikipedia garnicht so schlecht:
wikipedia schrieb:
Die Grundidee dabei ist, Daten und Funktionen, welche auf diese Daten angewandt werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.
Im Idealfall sollte ein Objekt also nach außen hin nur eine Schnittstelle bereit stellen, und nicht ein nach außen offenes Scheunentor.
-
asc schrieb:
sirchillalot schrieb:
Struct ist auch OOP!!!
Eine Datenstruktur ist kein OOP. Dazu gehören noch ein paar Dinge mehr...
Ich finde dazu die Erklärung aus der wikipedia garnicht so schlecht:
wikipedia schrieb:
Die Grundidee dabei ist, Daten und Funktionen, welche auf diese Daten angewandt werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.
Im Idealfall sollte ein Objekt also nach außen hin nur eine Schnittstelle bereit stellen, und nicht ein nach außen offenes Scheunentor.
Aber ich kann doch auch in einem Struct alles Private machen und hab so wieder ein saubere OOP konzept?!
-
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 vonstruct
geredet und nicht von Datenstrukturen.@berniebutt,
Hast du dich womöglich verschrieben und Datenstrukturen gemeint? Dennstruct
hat keine Nachteile gegenüberclass
. Alles wasclass
kann, kann auchstruct
in C++. Die zwei sind grundsätzlich völlig identisch, ausser dass haltclass
per Standardprivate
ist undstruct
per Standardpublic
. C++ macht keine weitere Unterscheidung.Ich persönlich verwende allerdings auch im allgemeinen
class
für Klassen undstruct
für Daten- und Hilfsstrukturen. Aber ich habe schon Leute erlebt, welche nurstruct
verwendet haben oder auch umgekehrt. Die Verwendung von beiden und in der Bedeutung umgekehrt (class
als Datenstruktur,struct
als 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
struct
zu 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
struct
nä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 vonstruct
geredet und nicht von Datenstrukturen.
@berniebutt,
Hast du dich womöglich verschrieben und Datenstrukturen gemeint? Dennstruct
hat keine Nachteile gegenüberclass
. Alles wasclass
kann, kann auchstruct
in C++. Die zwei sind grundsätzlich völlig identisch, ausser dass haltclass
per Standardprivate
ist undstruct
per 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?
struct
schadet 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.