Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Hallo Spiele-Programmierer,@BilderbergerK
Warum denkst du, dass der Ansatz nicht flexibel genug ist? Was genau möchtest du den erreichen und was funktioniert mit diesem Ansatz nicht? Prinzipiell sollte der Ansatz mindestens das erlauben, wonach dem du gefragt hattest. Deinen Code verstehe ich übrigens nicht. Von privater Ableitung würde ich auch abraten.
@BlueCobold
Die Anmerkung ist ja mal total am Thema vorbei. Mir scheint, du diskutierst gerne.
Und nein, das ist nicht unsinnig. Es gibt es im Wesentlichen zwei verschiedene Arten von Größen: Zahlen zur Dimensionierung von Speicher und Zahlen die eine andere freie Semantik und Wertebereich besitzen und unabhänig von Speicher sind (Eine Zeit in Sekunden wäre ein Beispiel). int in der Sprache von C(++) besitzt leider weder die eine noch die andere Semantik und ist somit prinzipiell weder für das eine noch für das andere geeignet. int ist ein Phänomen der Vergangenheit, als es noch viele Architekturen gab, die nicht auf Bytes basierten. Deshalb wurden damals im Standard die eingebauten Typen nicht auf feste Größe festgelegt. Heute allerdings ist es in plattformunabhänigen Code höchstens störend, das normale Integertypen ihren Wertebereich zwischen Architekturen und Compilern ändern können und das auch tun. Das Paradebeispiel ist wohl der Unterschied bei long zwischen Linux und Windows. Die Menge an sinnlosen Ärger den das schon bedeutet hat, ist gigantisch und eigentlich nicht zu rechtfertigen. Besonders die Tendenz vieler Linux-Programmierer zur Annahme, dass ihre C(++) Typen überall gleich wären und doch sicher überall das LP64 Model gelten würde, führt bei Portierungen häufig zu Problemen im Wertebereich. "Einfache" Probleme mit eigentlich überflüssigen Casts treten noch häufiger auf, wenn die eingebauten Typen verwendet werden.
Viele moderne verwandte Sprachen für moderne Plattformen verhindern das Problem heutzutage auch korrekt. Dazu gehören zum Beispiel C#, Java, Rust oder D. All die Sprachen machen es richtig. Das macht deutlich, dass die Vorteile von Integer Typen fester Größe für die meisten Fälle überwiegen und heutzutage die richtige Wahl sind.
Wenn man sich auf eine Menge von Plattformen und Compiler beschränkt, kann man mit genauen Festlegungen theoretisch auch mit den eingebauten Typen auskommen. Das ist meiner Meinung etwas engsichtig. Der einzige Grund gegen die Verwendung von Typen fester Größe ist doch, um mit alten Code konsistent zu bleiben und Tippfaulheit. Das kann ich auch verstehen, allerdings nicht warum man ihre Verwendung so schlecht finden könnte.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Totaler Unsinn. Ich habe plattform-unabhängigen Code, der läuft fehlerfrei auf 5 Systemen. Nirgends ist da ein int_32t. Ist auch gar nicht notwendig. Ich wüsste auch nicht wofür. Der Wertebereich ist durch Deinen Anwendungsfall beschränkt und nicht davon abhängig, ob das hier mal 32 Bit hat und dort 64 oder nicht. Es ist überhaupt in keiner Weise irgendwie störend, wie groß der int denn wirklich ist. Ich wüsste auch nicht warum. Im besten Fall ist der int größer als die 32 Bit, die Du mit int_32t festschreibst. Weniger wird es so ziemlich nirgendwo sein, auch wenn das rein theoretisch möglich wäre mit irgendeinem isoterischen Compiler. Was Du da beschreibst, ist praktisch irrelevanter Unfug. Das ist genau wie die Behauptung man solle char, short und int benutzen, je nachdem was für Werte man hat (z.B. char für Alter, weil das ja nie auch nur bis 110 geht). Im Normalfall hat der Compiler ohne die Festschreibung die besseren Optionen. Lass ihn machen, er weiß es besser als Du.@BlueCobold
Das klingt nach einem ganz ganz argen Design-Fehler. Wozu glaubst Du das zu brauchen und auch noch vererben zu müssen? Klingt doch für mich eher so als ob Du da eigentlich eine virtuelle Methode willst, die eine ID liefert und keine statische Property.allerdings habe ich es oft so, dass ich in einer Basisklasse ein statisches Attribut habe auf den ein paar Grundklassen basieren.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »BlueCobold« (23.10.2015, 16:09)
Ja?Totaler Unsinn. Ich habe plattform-unabhängigen Code, der läuft fehlerfrei auf 5 Systemen. Nirgends ist da ein int_32t. Ist auch gar nicht notwendig. Ich wüsste auch nicht wofür. Der Wertebereich ist durch Deinen Anwendungsfall beschränkt und nicht davon abhängig, ob das hier mal 32 Bit hat und dort 64 oder nicht. Es ist überhaupt in keiner Weise irgendwie störend, wie groß der int denn wirklich ist. Ich wüsste auch nicht warum. Im besten Fall ist der int größer als die 32 Bit, die Du mit int_32t festschreibst. Weniger wird es so ziemlich nirgendwo sein, auch wenn das rein theoretisch möglich wäre mit irgendeinem isoterischen Compiler. Was Du da beschreibst, ist praktisch irrelevanter Unfug. Das ist genau wie die Behauptung man solle char, short und int benutzen, je nachdem was für Werte man hat (z.B. char für Alter, weil das ja nie auch nur bis 110 geht). Im Normalfall hat der Compiler ohne die Festschreibung die besseren Optionen. Lass ihn machen, er weiß es besser als Du.@BlueCobold
Das klingt nach einem ganz ganz argen Design-Fehler. Wozu glaubst Du das zu brauchen und auch noch vererben zu müssen? Klingt doch für mich eher so als ob Du da eigentlich eine virtuelle Methode willst, die eine ID liefert und keine statische Property.allerdings habe ich es oft so, dass ich in einer Basisklasse ein statisches Attribut habe auf den ein paar Grundklassen basieren.
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
class Index { int index=0; }; class A : public Index { A() { index++; } }; class B : public Index { B() { index++; } }; print("A: %i; B%i\n", A::index, B::index); |
Totaler Unsinn. Ich habe plattform-unabhängigen Code, der läuft fehlerfrei auf 5 Systemen. Nirgends ist da ein int_32t. Ist auch gar nicht notwendig. Ich wüsste auch nicht wofür. Der Wertebereich ist durch Deinen Anwendungsfall beschränkt und nicht davon abhängig, ob das hier mal 32 Bit hat und dort 64 oder nicht. Es ist überhaupt in keiner Weise irgendwie störend, wie groß der int denn wirklich ist. Ich wüsste auch nicht warum. Im besten Fall ist der int größer als die 32 Bit, die Du mit int_32t festschreibst. Weniger wird es so ziemlich nirgendwo sein, auch wenn das rein theoretisch möglich wäre mit irgendeinem isoterischen Compiler. Was Du da beschreibst, ist praktisch irrelevanter Unfug. Das ist genau wie die Behauptung man solle char, short und int benutzen, je nachdem was für Werte man hat (z.B. char für Alter, weil das ja nie auch nur bis 110 geht). Im Normalfall hat der Compiler ohne die Festschreibung die besseren Optionen. Lass ihn machen, er weiß es besser als Du.@BlueCobold
Das klingt nach einem ganz ganz argen Design-Fehler. Wozu glaubst Du das zu brauchen und auch noch vererben zu müssen? Klingt doch für mich eher so als ob Du da eigentlich eine virtuelle Methode willst, die eine ID liefert und keine statische Property.allerdings habe ich es oft so, dass ich in einer Basisklasse ein statisches Attribut habe auf den ein paar Grundklassen basieren.
Z.B. will ich den Index eines Jeden Objektes aufrufen koennen, ohne das@BilderbergerK
Warum hast du verschiedene Variablen mit gleichen Namen? Warum benennst du die Variablen in der Basisklasse nicht einfach unterschiedlich? In deinem Beispiel sehe ich auch kein Problem, weil es nur eine Variable gibt und diese als auch die Vererbung privat sind.
Falls es mehrere Variablen mit gleichen Namen gibt, so gewinnt ohne der Angabe des Klassennamens immer die in der Klassenhierarchie letzte deklaration. Bei Mehrfachvererbungen kannst du mit using auswählen, welche Basisklasse den Vorang hat.
Ich verstehe allerdings momentan überhaupt nicht wofür du das brauchst. Ich würde mal vorschlagen, dass du mal genauer beschreibst was du gerade erreichen möchtest.
@BlueCobold
Na dann sei glücklich. Ich habe da bereits genau die Gegenteilige Erfahrung gemacht. In der Praxis ist momentan besonders der long-Typ problematisch. int kann man theoretisch verwenden, aber dann kommen bloß unnötige Casts weil das nirgends zusammenpasst. In der reallen Welt sind die meisten Typen auf Speicher bezogen (zum Beispiel STL Container) oder auf feste Typen in Dateien oder Protokollen.
Die zweite Sache die du ansprichst hat damit eher weniger zu tun.
EDIT:
Dein neues Beispiel wirkt nochmal seltsamer. Wofür das Ganze?
dein Lösungsansatz ist nicht schlecht, allerdings nicht flexibel genug.
Wofür man so etwas braucht? - Wenn man mehrmals von einer Klasse vererbt, die einen statischen Attribut hat.
C-/C++-Quelltext
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 class Basis { static int BaseID=0; }; class A : private Basis { ... }; class B : private Basis {...}; class SuperKlasse : public A, public B //A und B brauchen jeweils den statischen Member BaseID { .... };
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
template<typename T> class Basis { static int BaseID=0; }; class A : private Basis<A> { ... }; class B : private Basis<B> {...}; class SuperKlasse : public A, public B //A und B brauchen jeweils den statischen Member BaseID { void test() { std::cout << Basis<A>::BaseID << Basis<B>::BaseID << std::endl; } }; |
Es gibt es im Wesentlichen zwei verschiedene Arten von Größen: Zahlen zur Dimensionierung von Speicher und Zahlen die eine andere freie Semantik und Wertebereich besitzen und unabhänig von Speicher sind (Eine Zeit in Sekunden wäre ein Beispiel). int in der Sprache von C(++) besitzt leider weder die eine noch die andere Semantik und ist somit prinzipiell weder für das eine noch für das andere geeignet. int ist ein Phänomen der Vergangenheit, als es noch viele Architekturen gab, die nicht auf Bytes basierten. Deshalb wurden damals im Standard die eingebauten Typen nicht auf feste Größe festgelegt. Heute allerdings ist es in plattformunabhänigen Code höchstens störend, das normale Integertypen ihren Wertebereich zwischen Architekturen und Compilern ändern können und das auch tun. Das Paradebeispiel ist wohl der Unterschied bei long zwischen Linux und Windows. Die Menge an sinnlosen Ärger den das schon bedeutet hat, ist gigantisch und eigentlich nicht zu rechtfertigen. Besonders die Tendenz vieler Linux-Programmierer zur Annahme, dass ihre C(++) Typen überall gleich wären und doch sicher überall das LP64 Model gelten würde, führt bei Portierungen häufig zu Problemen im Wertebereich. "Einfache" Probleme mit eigentlich überflüssigen Casts treten noch häufiger auf, wenn die eingebauten Typen verwendet werden.
Viele moderne verwandte Sprachen für moderne Plattformen verhindern das Problem heutzutage auch korrekt. Dazu gehören zum Beispiel C#, Java, Rust oder D. All die Sprachen machen es richtig. Das macht deutlich, dass die Vorteile von Integer Typen fester Größe für die meisten Fälle überwiegen und heutzutage die richtige Wahl sind.
Ich habe da bereits genau die Gegenteilige Erfahrung gemacht. In der Praxis ist momentan besonders der long-Typ problematisch. int kann man theoretisch verwenden, aber dann kommen bloß unnötige Casts weil das nirgends zusammenpasst. In der reallen Welt sind die meisten Typen auf Speicher bezogen (zum Beispiel STL Container) oder auf feste Typen in Dateien oder Protokollen.
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »dot« (24.10.2015, 09:53)
Zitat
Portabilität ist überhaupt erst der Grund wieso int gerade keine feste Größe hat;
Zitat von »dot«
erst recht ist es kein "Phänomen der Vergangenheit".
Zitat von »dot«
int hat sowohl in C als auch in C++ eine ganz klar definierte Semantik und auch einen klar definierten Wertebereich.
Zitat von »dot«
https://de.wikipedia.org/wiki/Zirkelschluss
Zitat von »dot«
Inwiefern der "long-Typ" "in der Praxis problematisch" sein soll entzieht sich gerade meiner Vorstellungskraft, aber ich kann dir mit Sicherheit sagen, dass, wenn die Präsenz von int dich in deinem Code zu "unnötigen Casts" zwingt, weil "nirgendwo was zusammenpasst", mit deinem Code was nicht ganz in Ordnung sein kann...
Zitat von »dot«
wenn die Präsenz von int dich in deinem Code zu "unnötigen Casts" zwingt, weil "nirgendwo was zusammenpasst", mit deinem Code was nicht ganz in Ordnung sein kann...
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Werbeanzeige