Struct oder Class?

Dravere

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

l'abra d'or

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

Dravere

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

Sebastian Pizer

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

l'abra d'or

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.

berniebutt

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!

Nexus

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.

Michael E.

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?

Dravere

@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

camper

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

Nexus

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.

berniebutt

Dravere schrieb:

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

Kritisieren darf man alles. Es gibt aber einen Unterschied in der Betrachtungsweise. Der eine will oder muss mit den vorgegebenen Bedingungen arbeiten - er hat eine Aufgabe mit den vorhandenen Mitteln zu lösen. Der andere interessiert sich für eine saubere Sprachsyntax und darauf aufbauendem Compilerbau. Diese beiden Dinge gehen in dieser Diskussion einfach nicht zusammen. Mir reicht es, wenn ich eine stabile und wartungsfreundliche Anwendung mit dem geringstmöglichen Aufwand auf die Beine stellen kann. Ob dafür struct oder class die bessere Wahl ist, soll mir egal sein. Früher hatte man nur ASSEMBLER, ALGOL, FORTRAN, PL1, etc. - und musste damit auch zurecht kommen. C war da echt ein riesiger Fortschritt, C++ erst recht. Ich möchte diesen Fortschritt nicht missen und weiss nicht, was jemand in Zukunft gravierend besseres anbieten kann, was nicht auch die alten Grundlagen beinhaltet.

Dravere

@Nexus,
Ich verwende halt struct nahezu nur für PODs und Template-Magie. Auch implizite Konvertierungen, wie sie camper aufgebracht hat, habe ich noch nie bei einem struct /POD benötigt. Auch wenn du jetzt sagst, dass diese Beschränkung von struct für dich das Schlüsselwort fast nutzlos machen würde, so wäre es meiner Meinung nach immer noch die bessere Lösung. So hat man nicht zwei Schlüsselwörter, welche eigentlich das Gleiche sind. Damit hätte das Schlüsselwort auch wirklich eine eigene Aufgabe. Ist ja sowieso witzig, wie man im C++ Standard Komittee geizig ist, was Schlüsselwörter betrifft, aber bei sowas hat man gleich zwei

Nexus schrieb:

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.

Ja, ich kenne die Quellen und gibt noch ein paar mehr. Allerdings informiere ich mich kaum noch darüber. Die sollen endlich den Standard verabschieden und fertig machen, dann werde ich mich wieder damit beschäftigen

@berniebutt,
... hä?
Ich kann kaum eine Verbindung zu dieser Diskussion erkennen. Wie kommst du plötzlich auf unterschiedliche Betrachtungsweisen? Was willst du aussagen? Wieso kann man nicht über ein Sprachdesign diskutieren? Klar hat die Sprache Dinge vereinfacht, trotzdem kann sie doch schwächen haben, über welche man diskutieren darf? Und den letzten Satz finde ich erst recht völlig verwirrend. Hat denn dagegen irgendjemand hier was gesagt, dass man alte Grundlagen nicht mit reinnehmen soll?

Grüssli

Nexus

Dravere schrieb:

Auch wenn du jetzt sagst, dass diese Beschränkung von struct für dich das Schlüsselwort fast nutzlos machen würde, so wäre es meiner Meinung nach immer noch die bessere Lösung. So hat man nicht zwei Schlüsselwörter, welche eigentlich das Gleiche sind. Damit hätte das Schlüsselwort auch wirklich eine eigene Aufgabe.

Ja, das stimmt. Vielleicht habe ich mich inzwischen einfach zu stark daran gewöhnt, die Unterscheidung halt semantisch durchzuführen, ohne dass ein Zwang vom Compiler da ist. Mich persönlich stört es nicht gross, dass die Schlüsselwörter prinzipiell gleich verwendet werden können.

Aber wie oft schreibst du eigene POD-Klassen? Ich wüsste nicht, wann ich das letzte Mal sowas benötigt hätte. Nicht dass ich nie Datenbündel bräuchte. Aber wie gesagt, mir sind Konstruktoren wichtig, und die zerstören eben den POD-Status.

Noch was zu mehreren gleichwertigen Möglichkeiten: Gerade im neuen Standard wird ja so viel an Redundanz und Sprachmitteln eingeführt, damit man ein Problem auch noch auf eine dritte und vierte Weise angehen kann. Dabei gibt es Dinge, die den bisherigen Mitteln wirklich überlegen sind, aber bei gewissen Neuerungen bin ich nach wie vor sehr skeptisch. Besonders, was die Initialisierung und "Vereinheitlichung" (d.h. noch mehr Möglichkeiten) der Syntax mit {} und ={} anbelangt...

Dravere schrieb:

Ist ja sowieso witzig, wie man im C++ Standard Komittee geizig ist, was Schlüsselwörter betrifft, aber bei sowas hat man gleich zwei

Da steckt wahrscheinlich auch was Psychologisches dahinter. Klassen, und mit ihnen das Schlüsselwort class , eröffnen die Möglichkeiten der objektorientierten Programmierung. Man will ja nicht nur verbesserte Strukturen, genauso wenig wie C++ nur ein verbessertes C ist. Viele Programmierer hatten die Verkörperung von OOP in einem neuen Schlüsselwort wohl nötig.

camper

Ich kann auch gerne nochmal mal im D&E C++ nachschauen, es ist aber chlüssig anzunehmen, dass class direkte Folge der Entstehungsgschichte von C++ ist (ein separates Schlüsselwort könnte den Präprozessor in "C with Classes" vereinfacht haben). Später gab es dann einfach keinen Grund mehr structs auf strikte C-Kompatibilität zu beschränken (was vermutlich auch die Compilerimplementation unnötig - wenn auch sicher nur geringfügig - verkomplizieren würde) und das Ergebnis sind eben zwei Schlüsselwort für im Wesentlichen den gleichen Zweck.

Dravere

Nexus schrieb:

Aber wie oft schreibst du eigene POD-Klassen?

Selten, aber kommt vor.

Nexus schrieb:

Viele Programmierer hatten die Verkörperung von OOP in einem neuen Schlüsselwort wohl nötig.

lol, könnte vielleicht wirklich was dran sein

@camper,
Wäre interessant, ist aber auch nicht so wichtig. Es wird sicher seine Gründe gehabt haben, zumindest hoffe ich das

berniebutt

Dravere schrieb:

@berniebutt,
... hä?
Ich kann kaum eine Verbindung zu dieser Diskussion erkennen. Wie kommst du plötzlich auf unterschiedliche Betrachtungsweisen? Was willst du aussagen? Wieso kann man nicht über ein Sprachdesign diskutieren? Klar hat die Sprache Dinge vereinfacht, trotzdem kann sie doch schwächen haben, über welche man diskutieren darf? Und den letzten Satz finde ich erst recht völlig verwirrend. Hat denn dagegen irgendjemand hier was gesagt, dass man alte Grundlagen nicht mit reinnehmen soll?
Grüssli

Das, was du Sprache nennst, sind die Elemente eines Compilers. Darüber kann man nahezu unbegrenzt diskutieren. Ich hatte gesagt: jeder Compiler ist ein Hilfsmittel zur Programmierung. Mich interessieren mehr die eigenen Lösungen mit den gebotenen Hilfsmitteln und die saubere Realisierung der an ein Programm gestellten Aufgaben. Ob nun die Sprache lupenrein ist oder der Compiler mehr anbieten könnte, soll mir egal sein. Dies ist dann meine Betrachtungsweise des Themas. Mit struct und class habe ich keine Probleme. Ich verwende struct im Sinne von ANSI-C und class für alles mehr. Wo ist nun das Problem? Ich sehe keines!