Untervererbung von Template in GCC

Alter Hase

Wohnort: Deutschland Bayern

Beruf: Schüler

24.10.2015, 11:27

Falls das hier falsch rüber gekommen ist:
Ich bin nicht für die blinde und ausschließliche Verwendung von Typen fester Größe.

Alles was ich sage ist, dass die eingebauten Typen eigentlich eher selten der Intention entsprechen.
Feste Typen entsprechen der, meiner Erfahrung nach, schon etwas häufiger.

Ich bin auch total für Typen wie size_t. Den der hat eine festen Anwendungsbereich und ist klar definiert.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Spiele Programmierer« (24.10.2015, 11:38)

Zum Seitenanfang

Community-Fossil

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

24.10.2015, 11:56

Dann machst Du sehr unübliche Erfahrungen, ganz ehrlich. int entspricht so ziemlich immer der Intention, außer es geht um Binärkompatibilität irgendeiner Art (Dateien, Buffer, etc), die aber sehr strikte technische Umstände erfordert.

Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Zum Seitenanfang

Evrey

Treue Seele

Beiträge: 245

Beruf: Weltherrscher

24.10.2015, 15:00

Da das int-Thema hier schon eh' breit getreten ist...

Ich hab tatsächlich oft von Problemen mit int und long gelesen. Ein schönes Beispiel aus dem C-Standard wurde ja bereits genannt, aber die meisten lassen sich auf zwei Sachen zurückführen: Vornherein falsch genutzte Typen (int statt size_t), was bei 64bit-Ports ins Knie schießt, oder eben solche fehlgeleiteten Erwartungen, wie etwa dass int in etwa die Größe eines GPRs haben sollte, bei x86_64 häufig dennoch nur 32bit groß ist.

Beim ersten dieser Fälle kann man natürlich sagen: Eigene Dummheit! size_t und intptr_t gibt es nicht umsonst. Da gegen könnte man aber wieder ins Feld führen, dass man für diese Typen erstmal einen extra Header einfügen muss. Dann kann man auch gleich int32_t & Co. nutzen. Oder gleich solche Typen als Builtins haben.

Der zweite Fall ist einfach dumm, aber lässt sich im Grunde auf Problem 1 herunterbrechen, dass man besser Typen garantierter Größe verwendet. In solchen Fällen z.B. intptr_t.

Insofern... int ist für die meisten Fälle tatsächlich genau richtig, aber es ist nicht von der Hand zu weisen, dass int "oft" falsch verwendet wird, was dann schnell zu bösen Bugs führt. Diese Verwirrung wäre in Sprachen wie Rust mit builtin Typen wie i32 und isize nicht passiert. Angesichts der Tatsache, dass int auf den meisten Plattformen eh' 32bit groß ist, dass für auf Microcontroller portierbaren Code (z.B. MRuby) eh' oft Spezialisierungen mit #ifdefs getätigt werden, und dass diese 32bit eh' oft den Wertebereich umfassen, den man so im Alltag braucht... Wo ist das Problem dabei, int32_t zu tippen? In den meisten Fällen ist es eh' nur ein Alias für int, bloß mit der Garantie, dass es sich wirklich-wirklich überall völlig gleich verhält. Zumal bei der expliziten Größenangabe im Namen schnell die Alarm-Glocken läuten, wenn man für 64bit-Systeme portiert und man es irgendwo fälschlich für Größen nutzte, und dass 32bit-Arithmetik auf 64bit-Plattformen keine Performance einbüßt.

	C-/C++-Quelltext
1 2 3 4	int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main

(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Zum Seitenanfang

BilderbergerK

Frischling

Beiträge: 34

25.10.2015, 08:40

Sagen wir mal Du hast einen Taschenrechnerprogramm aus alter Zeit und hast damals int oder long(also 32bit) als Variablen verwendet und heute neu compilierst, dann wird aus int/long 64 bit. Woran liegt das Problem? Das ist doch der Sinn an C++.
Sicher kannst du die genauer Größge festlegen, was im Bereich Netzwerkprogrammierung z.B. sehr sinnvoll ist.

Zum Seitenanfang

Alter Hase

Wohnort: Deutschland Bayern

Beruf: Schüler

25.10.2015, 11:10

Offensichtlicher wird das Problem, wenn der Wertebereich des Typen kleiner wird. (wie zum Beispiel long von Linux auf Windows). In die andere Richtung kann es auch Probleme geben, wenn zum Beispiel davon ausgegangen wird, dass man alle Werte eines solchen Typen in einem anderen Typen fester Größe wie zum Beispiel in eine Datei oder einer anderen Bibliothek speichern kann.

All das führt zu Casts und Reibungspunkten, weil bestimmte Werte in die eine oder andere Richtung nicht dargestellt werden können. (Das ist in C++ übrigens Undefined Behavior)

Zum Seitenanfang

Community-Fossil

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

25.10.2015, 11:13

Das sind aber eben auch die einzig validen Stellen, wo feste Datentypen-Größen relevant sind - Dateien und binäre Protokolle. Und davon gibt es nicht allzu viele. Jedenfalls nicht in dem Maß, dass man jeden int einer Klasse durch int32_t ersetzen müsste oder sollte.

Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Zum Seitenanfang

Alter Hase

Wohnort: Deutschland Bayern

Beruf: Schüler

25.10.2015, 11:32

Also in der Software die ich so programmiere kommen letzendlich alle Daten aus Dateien und wandern in OpenGL und WinAPI zur Darstellung und Verarbeitung. Komplett losgelöste Daten die auch noch immer im garantierten Wertebereich von int [-32767;32767] liegen, habe ich irgendwie eher selten.

Zum Seitenanfang

Community-Fossil

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

25.10.2015, 11:34

Du hast also keinerlei Modelle? Bei Dir sind alles Dateien und GL-Buffer? Klingt sehr merkwürdig. Klingt nach schlechter Kapselung.

Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Zum Seitenanfang

Alter Hase

Wohnort: Deutschland Bayern

Beruf: Schüler

25.10.2015, 11:38

Die Modelle kommen ja auch aus Dateien und wandern in OpenGL.
Das sind allerdings floats. In meinem Terrain-Renderer habe ich das Highfield als Festkomma. Das wird mit 32 Bit in einer Datei gespeichert und auch mit 32 Bit Ints an OpenGL geschickt.

Dort sehe ich zum Beispiel keinen Grund, warum ich im Zwischenschritt alles in einem Dateitypen umwandeln sollte, der in beide Richtungen inkompatibel ist.

Zum Seitenanfang

Community-Fossil