Einsatz von short

unskilled

Also zusammenfassend hat es rein gar keinen Vorteil, short anstelle von int zu benutzen (von gigantischen Arrays mal abgesehen)? Performance kann man dadurch auch keine herausholen?

Das wollte ich damit nicht sagen - weil ich es einfach nicht genau weiß...
Ich wollte nur sagen, dass man (vor allem heutzutage) ja nicht mehr auf jedes Byte gucken muss - auch, wenn jetzt die ganzen Performance-Typen wieder aufschreien werden - wenn ich zwischen sehr gut wartbarem Code und weniger gut lesbarem entscheiden müsste und der gute 1 KB Speicher mehr beanspruchen würde, würde ich ihn noch immer nehmen... Nat. hat das irgendwo ne Grenze und zur Not definiert man die Funktion halt als template - kannste ja auch ma selbst ausprobieren?!

#include <ctime>

template <typename T, size_t length>
 clock_t foo (void)
  {
   clock_t ticker = clock ();
   T *arr = new T [length];
   T *arr_end = arr + length;
   T *copy (arr);
   for (arr = copy; arr != arr_end; ++arr)
    {
     *arr = 4;
    }
   for (arr = copy; arr != arr_end; ++arr)
    {
     *arr *= *arr;
    }
   for (arr = copy; arr != arr_end; ++arr)
    {
     *arr -= *arr;
    }
   delete []copy;
   return clock () - ticker;
  }

int main ()
{
const clock_t a (foo <int, 1>);
const clock_t b (foo <int, 10>);
const clock_t c (foo <int, 100>);
const clock_t d (foo <int, 255>);
const clock_t e (foo <int, 1000>);
const clock_t A (foo <short, 1>);
const clock_t B (foo <short, 10>);
const clock_t C (foo <short, 100>);
const clock_t D (foo <short, 255>);
const clock_t E (foo <short, 1000>);
}

könnte mir aber vorstellen, dass es bei keinem einen messbaren Wert gibt, also einfach noch paar schleifen drum rum machen oder so ^^

kannst ja ma sagen, was rauskam (Releasemodus) - ich kann gerad nich selbst testen ^^

bb

edit: sry, hatte bei den schleifen was vergessen ^^

Ihr n00bs,

sowohl int als auch short sind durch zwei Teilbar auf euren x86 CPUs, also gibts mit der Berechnung der Adresse sowieso keine größeren Probleme.
Dazu kommt, dass die x86 Architektur abwärtskompatibel ist und bei 16Bit und 32Bit kein Unterschied festzustellen ist (ich möchte jetzt an dieser Stelle nicht so weit gehen und behaupten es gäbe gar keinen).

Der short int wird aus genannten Gründen kaum verwendet. Entweder man will einfach eine Zahl speichern dann nimmt man int. Und sobald man sich um die Größe sorgt will man eh int_16, int_32, etc. verwenden (diese gibt es nicht offiziell, das wird für gewöhnlich durch typedefs realisiert, wenn du mit configure arbeitest bekommst du die in einer config.h serviert).
Also kurz: wenn die Größe relevant ist, dann sind die eingebauten Typen uninterressant da du dich nicht auf deren Größe verlassen kannst. Wenn sie keine Rolle spielt willst du normal eh einen int.

Deshalb hat short int keine Relevanz, du wirst ihn normal nur durch ein wchar_t, int_16 etc. indirekt nutzen (wobei wchar_t kein typedef auf short int sein muss, aber bei manchen ist das der Fall).

unskilled

OMFG Du N00b schrieb:

Ihr n00bs

Du Noob

OMFG Du N00b schrieb:

sowohl int als auch short sind durch zwei Teilbar auf euren x86 CPUs

Ach wirklich? Ich würde mal behaupten wollen, dass sowohl short als auch int durch zwei teilbar sind. (aber gut - dann könntest du nat. leider nicht ins spiel bringen, dass du wahrscheinlich keine x86 CPU hast). Wenn du Shift benutzen willst, dann solltest du dir auch im klaren sein, wann es angebracht ist und wann es falsch ist...

OMFG Du N00b schrieb:

also gibts mit der Berechnung der Adresse sowieso keine größeren Probleme.

Wer hat behauptet, dass es das gibt? Oo

OMFG Du N00b schrieb:

Dazu kommt, dass die x86 Architektur abwärtskompatibel ist

Das weiß hier glaube ich jeder

OMFG Du N00b schrieb:

und bei 16Bit und 32Bit kein Unterschied festzustellen ist (ich möchte jetzt an dieser Stelle nicht so weit gehen und behaupten es gäbe gar keinen).

Und genau darum ging es doch gerad...

OMFG Du N00b schrieb:

Der short int wird aus genannten Gründen kaum verwendet.
[und dann wiederholst du noch mal alles oder bringt irgendwelche Dinge an, die mit dem Thema maximal irgendwie in Verbindung stehen - aber keine, die hier von Bedeutung wären]

Also denn.. gj Noob...

Nexus schrieb:

Was ich auch schon gehört habe, wäre, dass int der ideale Typ wäre, weil er mit 4 Bytes meistens gerade an die Grösse der Prozessorregister angepasst ist. Heisst das, short ist diesbezüglich langsamer? Können nicht zwei short -Werte in einem Register gespeichert werden, und dann sieht es bezüglich Performance sogar besser aus?

int war in der regel der für die plattform am besten passende typ, bezogen auf registergröße und damit rechengeschwindigkeit. ich schreibe "war", weil bei compilern für die 64-bit-generation der x86-cpus mit dieser tradition gebrochen wurde (int ist dort weiterhin 32 bits breit), wohl aus rücksicht auf minder gut geschriebene software, die sich sonst nicht einfach neu kompilieren ließe.

auf 386+ mit 16-bit registern zu rechnen ist schlichtweg langsamer als mit 32-bit registern. wobei ich mich auf vielerorts geschriebenes verlasse, ausprobiert habe ich es nie.

ghorst

@erklärbär der int kann auf 64bit systemen 32bit betragen. er muss es nicht. beispiele für beide methoden sind: msvc mit 32bit int auf 64bit systemen (danke an hustbaer) und der gcc mit 64bit int auf 64bit systemen.

ansonsten: ich nutze short auch eher selten, da sie dank alignment meistens genau soviel speicher brauchen wie ints.

*john 0

ghorst schrieb:

@erklärbär der int kann auf 64bit systemen 32bit betragen. er muss es nicht.

Das ist definitiv falsch! Es hängt vom OS ab, bei JEDEM UNIX muß ein int 32Bit groß sein im 64Bit Modus, und das ist vollkommen unabhängig vom Compiler, weil das so in der Single UNIX Spec definiert ist.

Nexus

Also zusammengefasst gibt es eigentlich keinen Grund, short zu verwenden? Besteht nicht die Möglichkeit, dass dadurch schnellerer Code entsteht? Oder muss man sogar Angst haben, dass der Code langsamer wird?

ghorst

@nexus im normalfall: weder noch. der code sollte genauso schnell sein, da shorts mit alignment genauso schnell zugreifbar sind wie ints.

Nexus

Aber durch dieses Alignment werden short -Variablen wie ints behandelt (Performance und Speicherverbrauch)? Also gibt es doch keinen Grund, sie zu verwenden?

*john 0

Das sind Mikrooptimierungen von denen man die Finger lassen sollte, außer sie sind absolut notwendig. Wenn shorts für Modellierung ausreichend sind, sollte man sie verwenden. Ob shorts nun schneller oder langsamer als ints sind, hängt von der verwendeten Hardwareplattform ab, und ist keine Eigenschaft des Datentyps selbst.

Nexus

Naja, aber wenn man in den meisten Fällen durch short nichts gewinnt, aber sich im Wertebereich einschränken muss, ist die Thematik doch schon eine Überlegung wert...

Dravere

Also um es kurz zu machen. Ich selber brauche äusserst selten den Typ short.

Mir fallen spontan nur zwei Bereiche ein, wo ich shorts einsetze:

Ich habe bestimmte Vorgaben irgendwoher, zum Beispiel von einer Datenstruktur.
Ich möchte sicherstellen, dass ein gewisser Datenbereich eingehalten wird in meiner Bibliothek oder meinem Programm. Das kann viele Gründe haben, vielleicht will man einfach eine maximale Grenze setzen, weil es auch kritisch werden könnte, wenn die Zahl höher ginge. Dank dem short muss ich dann keine Bereichsprüfung machen, sondern kann mich auf dessen Grenze verlassen, bzw. darauf, dass der User die Warnungen einhält. Allerdings nicht unbedingt zu empfehlen, da es glaube ich nirgends heisst, dass ein short nicht auch grösser als 2 Bytes sein kann. Beim Standard gibt es da glaub ich nur eine Mindestgrösse-Vorgabe

Grüssli

Nexus

Okay, allen vielen Dank für die Antworten!
Dann werde ich in Zukunft den Datentyp short mit Bedacht einsetzen...