short, int und long

[Xin]

Yepp.

PS: fat-lobytes Antwort ist besser.

[fat-lobyte]

Also wäre es naheliegend (da ich auf Basis von SDL arbeiten möchte), direkt die von SDL verwendeten Primitiv-Datentypen zu verwenden, oder?

Wenn der Code für immer mit der SDL verschmolzen sein wird, dann schon. Eigentlich gibts genau für den gleichen Zweck seit C++11 das Zeugs in <cstdint>:

Code: Alles auswählen

namespace std {
typedef signed integer type int8_t; // optional
typedef signed integer type int16_t; // optional
typedef signed integer type int32_t; // optional
typedef signed integer type int64_t; // optional
typedef signed integer type int_fast8_t;
typedef signed integer type int_fast16_t;
typedef signed integer type int_fast32_t;
typedef signed integer type int_fast64_t;
typedef signed integer type int_least8_t;
typedef signed integer type int_least16_t;
typedef signed integer type int_least32_t;
typedef signed integer type int_least64_t;
typedef signed integer type intmax_t;
typedef signed integer type intptr_t; // optional
typedef unsigned integer type uint8_t; // optional
typedef unsigned integer type uint16_t; // optional
typedef unsigned integer type uint32_t; // optional
typedef unsigned integer type uint64_t; // optional
typedef unsigned integer type uint_fast8_t;
typedef unsigned integer type uint_fast16_t;
typedef unsigned integer type uint_fast32_t;
typedef unsigned integer type uint_fast64_t;
typedef unsigned integer type uint_least8_t;
typedef unsigned integer type uint_least16_t;
typedef unsigned integer type uint_least32_t;
typedef unsigned integer type uint_least64_t;
typedef unsigned integer type uintmax_t;
typedef unsigned integer type uintptr_t; // optional
} // namespace std

[Glocke]

Wenn der Code für immer mit der SDL verschmolzen sein wird, dann schon. Eigentlich gibts genau für den gleichen Zweck seit C++11 das Zeugs in <cstdint>

Was heißt verschmolzen ... wenn du damit meinst, dass der Code immer auf SDL basiert, dann ja.

[Glocke]

Hi, inzwischen verwende ich an entsprechenden Stellen die Typen aus http://en.cppreference.com/w/cpp/types/integer. Muss ich bei char, bool, float und double auch auf so etwas achten?

LG Glocke

[Xin]

Hi, inzwischen verwende ich an entsprechenden Stellen die Typen aus http://en.cppreference.com/w/cpp/types/integer. Muss ich bei char, bool, float und double auch auf so etwas achten?

Bei char hast Du mindestens 8 Bits. Bei float hast Du mindestens 32 Bit. Bei Bool hast Du mindestens 1 Bit. Da ein Compiler aber mindestens 1 Byte ansprechen muss, sind 8 Bool nicht 1 Byte, sondern 8 Byte - meistens...

Wenn Du Daten verschicken möchtest, solltest Du immer mit dem sizeof-Operator arbeiten.

[Glocke]

Hi, inzwischen verwende ich an entsprechenden Stellen die Typen aus http://en.cppreference.com/w/cpp/types/integer. Muss ich bei char, bool, float und double auch auf so etwas achten?

Bei char hast Du mindestens 8 Bits. Bei float hast Du mindestens 32 Bit. Bei Bool hast Du mindestens 1 Bit. Da ein Compiler aber mindestens 1 Byte ansprechen muss, sind 8 Bool nicht 1 Byte, sondern 8 Byte - meistens...

Wenn Du Daten verschicken möchtest, solltest Du immer mit dem sizeof-Operator arbeiten.

Naja ich versende meine Objekte (die dann solche Primitivdaten enthalten) mittels sizeof und sende vorher (damit die Gegenseite weiß wie viel Byte sie lesen muss) die Größe an die Gegenseite. Dabei habe ich dann eben das Problem mit den verschiedenen Größen. Gibt es für die übrigen Typen auch solche Entsprechungen mit fester Größe?

LG Glocke

[Xin]

Naja ich versende meine Objekte (die dann solche Primitivdaten enthalten) mittels sizeof und sende vorher (damit die Gegenseite weiß wie viel Byte sie lesen muss) die Größe an die Gegenseite. Dabei habe ich dann eben das Problem mit den verschiedenen Größen. Gibt es für die übrigen Typen auch solche Entsprechungen mit fester Größe?

Ich würde die Werte als gegeben akzeptieren.

Deine Software würde dann auf Computern nicht laufen, die andere Größen verwenden.
Mir ist momentan nicht bekannt, dass derartige Rechner noch ernsthaft im Einsatz sind und wenn doch, wirst Du dort kein SDL finden.
Ich würde also einfach von float mit 4 Byte und von double mit 8 Byte ausgehen und nochmal googlen, ob bool einem Byte entspricht.

[Glocke]

Na ok, danke

[Nemo]

Ich verwende inzwischen eigene Primitiv-Klassen, zum Beispiel XSD::Primitive::Double statt double, da sie Funktionalität wie "AsString()" oder "Parse( char const *) zur Verfügung stellen, die sich wunderbar mit anderen meiner Templates kombinieren lassen und z.B. operator == so überladen ist, dass innerhalb einer gewissen Toleranz verglichen wird. Ähnliches für XSD::Primitives::Int - aber halt ohne Toleranz, was den Vergleich angeht.

Wenn ich das richtig verstehe ist eine Primitiv-Klasse einfach eine Klasse mit dem jeweiligen primitiven Datentyp als einzige Membervariable oder?
In diesem Fall müsste ein Programm, dass mit solchen Klassen arbeitet doch langsamer sein, weil der Operator wieder den Operator des primitiven Datentyps aufruft, oder verstehe ich da was falsch?

[Xin]

Moin Nemo und willkommen on Board.

Wenn ich das richtig verstehe ist eine Primitiv-Klasse einfach eine Klasse mit dem jeweiligen primitiven Datentyp als einzige Membervariable oder?

Grundsätzlich ja, aber wie schon gesagt, kann die Klasse weitere Funktionalität anbieten und damit ein Primitiv für Templates zugänglich machen, die vom verwendeten Datentyp gewisse Funktionalität erwarten.

In diesem Fall müsste ein Programm, dass mit solchen Klassen arbeitet doch langsamer sein, weil der Operator wieder den Operator des primitiven Datentyps aufruft, oder verstehe ich da was falsch?

Das ist erstmal korrekt.

Wenn Du allerdings

Code: Alles auswählen

Interger::Integer( int value )
  : Value( value) {}

inline Integer operator * ( Integer const & lhs, Integer const & rhs )
{ return Integer( lhs.Value * rhs.Value ); }

in den Header packst, gibt es eigentlich nichts, was nicht rauszuoptimieren wäre, weil es eigentlich die klassischen Fälle darstellt, die ein Optimierer anpacken sollte.

Trotzdem kann es eventuell langsamer laufen, wenn die Optimierung nicht ausreicht. Bisher verwende ich die Primitiv-Klassen vorrangig für Datenhaltung, da spielt die Laufzeit keine so große Rolle, Zeitverlust entsteht vorrangig durch Netzwerk oder Festplattenzugriff.
Man könnte sie aber durchaus mal gegen echte Primitive in echten Aufgaben antreten lassen, um das zu verifizieren.