spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Doch, das geht (siehe: http://ideone.com/g0AhFh). Aber ich glaube nicht, dass Du wirklich das willst, was da steht.

Zitat von »BilderbergerK«

[...]
allerdings compiliert GCC den Code nicht.

Und was sagt GCC wenn er den Code nicht kompiliert? Am Ende von newTemp fehlt ein ;

Nein, ich wüsste auch nicht wofür das gut sein soll.

Soweit ich wüsste geht das nicht ohne irgendwelche abgefahrenen C++ Tricks anzuwenden. Halte ich aber auch für nicht sinnvoll so etwas zu machen. Warum genau möchtest du das denn machen?

Das geht gar nicht.

Es ist allerdings möglich, die Template-Klasse von einer abzuleiten, die diese Variablen definiert. Damit kann man im Prinzip den selben Effekt erreichen.

int32_t ist übrigens Unsinn. Den kann man gern verwenden, wenn man wirklich wirklich wirklich genau diese Größe braucht, das ist aber höchstens bei binärer Serialisierung oder GPU-Buffern oder sowas der Fall. Für den normalen Anwendungsfall, sollte man int nehmen. Fertig.

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