3. Struct oder Class?

Struct oder Class?

  • D

    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.

    0
  • A

    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.

    0
  • B

    Dravere schrieb:

    @asc,
    berniebutt hat aber von struct geredet und nicht von Datenstrukturen.
    @berniebutt,
    Hast du dich womöglich verschrieben und Datenstrukturen gemeint? Denn struct hat keine Nachteile gegenüber class . Alles was class kann, kann auch struct in C++. Die zwei sind grundsätzlich völlig identisch, ausser dass halt class per Standard private ist und struct per Standard public . C++ macht keine weitere Unterscheidung.
    Grüssli

    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.

    0
  • L

    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

    0
  • F

    EDIT: Ah, okay... "D"... hielt das für einen verkorksten Smiley. 😉

    0
  • B

    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 🙂

    0
  • A

    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.

    0
  • F

    Oder noch einfacher: Man liest einmal drüber, merkt sich das. Fertig.

    0
  • Administrator

    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

    0
  • L

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

    0
  • ?

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

    0
  • Administrator

    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

    0
  • S

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

    0
  • L

    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.

    http://www.amazon.de/D-Programming-Language-Andrei-Alexandrescu/dp/0321635361/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1265976820&sr=1-1

    So was ich auf seiner Homepage gelesen hab ist er recht begeistert.

    0
  • B

    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!

    0
  • N

    Ich finde die Schlüsselwörter struct und class gut 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 struct nur 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 bei struct einsetze). Wenn mans wissen will, existiert ja noch is_pod aus Boost.TypeTraits. 😉

    0
  • M

    berniebutt schrieb:

    Wir leben nun einmal damit, dass das Design neuer Compiler auf bekanntem alten aufbauen muss.

    Was haben denn Compiler mit dem Thema zu tun? 😕

    0
  • Administrator

    @berniebutt,
    Aber man darf doch die Kritik in den Raum stellen? Falls dass ein Programmierer liest, welcher in Zukunft mal eine Sprache entwirft, denkt er hoffentlich an solche Diskussionen zurück und macht keine solchen Designfehler oder zumindest weniger. Es einfach nur zu aktzeptieren und damit leben, ohne es zu kritisieren, hilft überhaupt niemandem weiter. So gäbe es gar keinen Fortschritt. Und zudem ist das ein Sprach- und nicht ein Kompiler-Designfehler 😉

    @Nexus,
    Ein POD kannst du über die initializier-list initialisieren, es braucht daher keinen Konstruktor. Wobei ich gar nicht mehr weiss, ob das im nächsten Standard nicht gelockert wird. Und diese Lockerung hätte man ja auch schon früher bringen sollen, wenn wir schon dabei sind :p

    Grüssli

    0
  • C
    Mod

    Dravere schrieb:

    @Nexus,
    Ein POD kannst du über die initializier-list initialisieren, es braucht daher keinen Konstruktor. Wobei ich gar nicht mehr weiss, ob das im nächsten Standard nicht gelockert wird. Und diese Lockerung hätte man ja auch schon früher bringen sollen, wenn wir schon dabei sind :p

    Direkte Initialisierung ist nicht das Problem, einen generaliserten bennanten Pseudo-Konstruktor kann man jetzt schon haben. Konstruktoren werden aber notwendig, wenn Konvertierungen - insbesondere aus eingebauten Typen - gewünscht sind.

    template <typename T, typename A1> T make(const A1& a1) { T x = { a1 }; return x; }
template <typename T, typename A1, typename A2> T make(const A1& a1, const A2& a2) { T x = { a1, a2 }; return x; }
template <typename T, typename A1, typename A2, typename A3> T make(const A1& a1, const A2& a2, const A3& a3) { T x = { a1, a2, a3 }; return x; }
...
    0
  • N

    Dravere schrieb:

    @Nexus,
    Ein POD kannst du über die initializier-list initialisieren, es braucht daher keinen Konstruktor.

    Ja, aber die Aggregats-Initialisierungsliste ist etwas unflexibel und heikel. Wenn man zum Beispiel nachträglich eine Membervariable hinzufügt, funktioniert der bestehende Code immer noch, allerdings wird der neue Member nur null-initialisiert. Beim Ändern eines Konstruktors hingegen erhält man Compilerfehler und sieht so, wo man überall auf den neuen Member reagieren muss. Ausserdem will man vielleicht einen Standardkonstruktor anbieten, der was anderes macht, als alle Member mit Null zu initialisieren. Mal davon abgesehen, dass man mit Konstruktoren gar keine Möglichkeit mehr hat, die Initialisierung zu vergessen.

    Ich verwende struct auch meistens in Kontexten, wo nicht nur Member vorkommen, die selbst PODs sind. Ohne Konstruktoren und private / protected -Spezifizierer könnte man zwar auch bei Nicht-POD-Klassen immer noch die Aggregats-Initialisierungsliste verwenden (mit den erwähnten Nachteilen), aber struct auf Plain Old Data zu beschränken, würde das Schlüsselwort für mich nahezu nutzlos machen.

    Dravere schrieb:

    Wobei ich gar nicht mehr weiss, ob das im nächsten Standard nicht gelockert wird.

    Die Definition von POD wird um einiges gelockert, neuerdings kann man z.B. Konstruktoren in PODs einbauen. Siehe C++09 (Teil 1), Abschnitt "2.8 Plötzlich POD". Wobei ich mir nicht sicher bin, ob der Artikel noch aktuell ist. Auf Wikipedia steht sonst auch einiges, oder direkt auf entsprechenden Standard-Papers.

    0
Anmelden zum Antworten