Vba frage dim Byte oder integer?
integerhallo liebe Community folgende Frage zur Deklaration von Jahr
Hätte ich anstatt integer auch Byte nehmen können ?
Vielen Dank schonmal
2 Antworten
Hättest du. Aber Integer ist besser. Mit Integer unterscheidest du besser zwischen beispielweise 1999 und 2099.
Wenn du nur ein Byte nimmst, dann stehen dir nur maximal 256 Jahreszahlen zur Verfügung.
Das kommt immer darauf an welchen Zahlenbereich man braucht.
Byte oder Char sind 8-bit und bieten 256 verschiedene Möglichkeiten, man kann also damit Zahlen zwischen 0 und 255 (ohne Vorzeichen, "unsigned") bzw. Zahlen zwischen -128 und +127 ("signed") darstellen.
Int bzw. Short Int hat 16 bit, das kann 65536 verschiedene Werte annehmen, also 0…65535 (unsigned) oder -32768…32767 (signed).
Der Speicherplatzverbrauch ist bei Int natürlich doppelt so hoch wie bei Byte/Char. Hat der Prozessor 16 bit oder mehr, dann ist der Aufwand damit zu rechnen der gleiche, eine 16-bit CPU hat sogar weniger Aufwand bei int da die sich immer die richtige Anzahl an Bytes aus dem Speicher greift. Hat die CPU mehr bits als der Datentyp den man verwendet, werden "nachbarbytes" mit aus dem Speicher gegriffen und die müssen dann erst mal "aussortiert" werden.
D.h. am schnellsten arbeitet das Programm wenn man den Datentyp nimmt der der Bitbreite der CPU entspricht. Bei einem PC mit 64-bit Betriebssystem wäre das also "int64" bzw. "long long" oder modern "int64_t". Dafür wird dann aber Speicher verschwendet, bei einfachen programmen kein Problem, bei Programmen die viele Daten verarbeiten allerdings schon. Auf jeden Fall sollte man sich beim Abspeichern von Daten in eine Datei oder Übertragung per Netzwerk genau überlegen wie viele bits man braucht und dann ggf. die Variablen in einen kleineren Datentyp kopieren bevor gespeichert wird. Denn beim Abspeichern spielt die Zeit zum Umrechnen keine Rolle, der verbrauchte Platz auf der Festplatte oder die Bandbreite im netzwerk allerdings schon.
P.S.:
Möchtest Du lernen wie man Programme optimiert, dann hilft Dir beim PC ein eingebautes Register, das die "CPU-Ticks" zählt. Damit kannst Du messen wie lange ein Programmteil dauert.
Hier steht, wie es geht: http://www.c-howto.de/tutorial/zeitfunktionen/cpu-ticks/
Wie viel Zeit ein CPU-Tick ist, das hängt natürlich von der CPU ab. Moderne CPUs verändern ihre Taktfrequenz und passen die dem Bedarf an. Daher kannst Du nicht mehr sagen wie lange genau das gedauert hat. Aber Du kannst immer noch abschätzen was schneller ist und was langsamer. Auch stört das Multitasking, Du kannst also auch nicht sagen, wie viele Taktzyklen der Code wirklich gebraucht hat. Aber zum experimentieren was effizienter ist reicht das allemale.
Früher in DOS wurde das Register dazu benutzt Spiele immer mit der richtigen Geschwindigkeit ablaufen zu lassen, das Spiel lief immer mit der richtigen geschwindigkeit, egal welche CPU man hatte (sofern stark genug). Erst wenn die CPU viel zu schnell ist und die Register unbemerkt (mehrfach) überliefen kam es zu Problemen. Startete man ein Spiel das für 286 (<8MHz) geschrieben wurde auf einem 486 oder gar Pentium (≤100MHz) kam nach einem Blitz direkt das "Game Over" weil das Spiel einfach tausende male schneller lief als vorgesehen. Zum einen halt weil die CPU-Ticks schneller überliefen als abgefragt, zum anderen reichte der Wertebereich der Bremsvariablen nicht mehr auszurechnen wie viele Ticks gewartet werden musste.
Da steht "int bzw. short int", und das ist falsch. "int" hat eben mehr zu bieten. Und von "kurz short" steht da auich gar nichts, sondern im Gegenteil wird "short" nicht wieder erwähnt. Auf 'nem C64 hättest Du fast recht gehabt: Da hatte ein Int 16 Bit, aber damals hatte "load 'VBA',8,1" noch etwas anderes ausgelöst, denn es gab gar kein Visual Basic for Applications auf C64, sondern Commodore Basic.
1) Unter VBA hat ein Integer 32 und nicht 16 Byte. Quelle: https://learn.microsoft.com/de-de/dotnet/visual-basic/language-reference/data-types/integer-data-type. 64-Bit-CPUs verarbeiten 32-Bit-Daten relativ effizient - kaum langsamer als 64-Bit-Daten.
2) Optimierungen sollte man grundsätzlich erst durchführen, nachdem das Hauptproblem gelöst wurde. Und wenn man nicht tausend lineare Abschreibungen durchführt, dann sollte man Optimierungen gar nicht durchführen - und immer einen garantiert(!) ausreichenden Datentyp wie z. B. Integer nehmen, damit kann man auch den Taler von Jesus' Verrat berechnen. Ein Char ist vom Verständnis her nicht als Zahl gedacht, das ist schlechter hardwarenaher Programmierstil - und hat schon manchen zur Verzweiflung gebracht, als UTF zeigte, dass 7 Bit ASCII plus 1 Bit für die Welt zu wenig waren. Heutzutage hat ein Zeichen oft mehr als 1 Byte, und tatsächlich behandelt VBA einen Char als 1 Zeichen mit 16 Bit!