Hallo, ich beschäftige mich gerade mit dem Berechnen von Werten und frage mich, welche Variablen man direkt miteinander "verrechnen" bzw. zuweisen kann (also erstmal keine Umwandlungen von Strings zum Beispiel).
Ich habe da 5 konkrete Fragen:
float tempF {48.3};
int tempI; // Großes i am Ende
byte tempB;
tempI = tempF; //Geht das? Ich denke ja , weil tempF ein gerades int sein könnte
tempB = tempF; //Geht das? Ich denke ja , weil tempF ein gerades Byte sein könnte
Aber was passiert in dem konkreten Fall, dass
tempF eine Nachkommastelle != 0 hat?
Oder tempF größer als 255 wird (bei tempB = tempF) ?
Gibt es eine Übersicht darüber, was man jeweils zuweisen kann?
grundsätzlich kann man alle nummerischen Datentypen miteinander verrechnen. Obs Sinn macht ist eine ganz andere Frage und kommt auf den Einzelfall an. Man kann auch konvertieren.
Das hier geht alles. Ob Sinn macht wie gesagt. Im besten Fall warnt dich der Compiler vorm Überlauf. tempF bleibt immer float. tempI bleibt immer int. temp8 bleibt immer byte.
float tempF {48.3};
int tempI; // Großes i am Ende
byte tempB;
tempI = tempF;
tempB = tempF;
tempI = tempF;
hierbei werden alle Kommastellen eiskalt abgeschnitten. Es findet auch keine Rundung statt. Abgesehen vom Wertebereichüberlauf.
tempB = tempF;
Gleiches Spiel wie oben.
Probiere es am Besten aus. Lasse alles im seriellen Monitor ausgeben. Wundere dich oder freue dich über die Ergebnisse.
Hallo, ich beschäftige mich gerade mit dem Berechnen von Werten und frage mich, welche Variablen man direkt miteinander "verrechnen" bzw. zuweisen kann
Hallo nochmal, dazu noch eine Nachfrage
Man soll ja bei den millis() mit long Variablen z.B.
unsigned long Intervall {1000};
vergleichen,
weil millis einen long-Wert zurückgeben.
Wenn ich aber sicher weiß, dass ich nur Intervalle von max. 60000 Millisekunden habe
(jede Minute für 1 Sekunde einen Tempsensor abfragen),
warum reicht dann kein unsigned int?
was spricht gegen: const unsigned int intervall[] = { 1000, 400, 270, 100 }; ?
Es wird mit millis() verglichen.
millis() liefert einen unsigned long
Wenn du unsigned long mit unsigned int verwurstest, solltest du ganz genau die automatischen Konvertierungen des Kompilers kennen und beherrschen.
Tust du das, spricht nichts dagegen, Äpfel mit Birnen zu vergleichen.
Versagst du aber an der Stelle, dann bitte nicht jammern: "Der Kompiler ist kaputt!"
Also:
Solange nichts ernsthaft dagegen spricht, dann verwende bitte die "richtigen" Datentypen.
Sonst nagelst du dir unbedachter weise, schnell mal eben eine Frikadelle ans Knie.
(und die unbedachten Mitleser, nageln sich ebenso Dinge dahin, wo sie nicht hin gehören)
Ich kann da (noch) nicht das große Problem überblicken als Newbie :o
Ich kann da (noch) nicht das große Problem überblicken als Newbie
Ja!
Das kommt noch.
Bei Vergleichen ist es immer komisch, wenn man Vorzeichenlose mit Vorzeichenbehaftete Dinge vergleicht.
Es kommt nicht immer dabei rum, was der unbedarfte Programmierer erwartet.
Schlimmer noch ist es mit Berechnungen.
Beispiel:
Der unsigned Über- oder Unterlauf ist definiert.
Der signed Überlauf ist explizit im C++ Standard ausgeschlossen.
Die Sprache sagt klar: Der signed Überlauf führt in ein undefiniertes Verhalten.
In einem solchen Fall ist das ganze Programm als fehlerbehaftet anzusehen.
Der Arduino darf dann z.B. beim Präsidenten anrufen, oder zum Mond fliegen, ohne dich zu fragen.
Da wären ja beide vorzeichenlos... ist das dann trotzdem fehlerhaft?
Wenn ich genau den Bereich der unsigned int eingenzen kann?
Ich habe dir doch einen Link zu den Konvertierungsregeln gepostet...
Aus denen geht klar hervor dass der kleinere Partner, bei z.B. einer Addition oder Vergleich, zu dem größeren Type konvertiert wird.
Deine Eingrenzung ist da also irrelevant.
Eine Nebelkerze.
Oder beim ESP8266 einfach auf die paar Byte pfeifen und
unsigned long intervallMessung + unsigned long intervallAuslesen nehmen?
Interessanter weise hast du da eine Kleinigkeit übersehen.
Der ESP ist ein 32 Bit System.
Somit ist unsigned int und unsigned long gleich groß.
Da ist also nix, mit sparen.
Auch gibts ja schließlich noch das Alignment
Welches dem sparen offensichtliche Grenzen setzt.
Grundsätzlich ist ein Prozessor am effektivsten wenn er mit seiner natürlichen Datenbreite arbeitet.
Alles andere bedeutet Mehrarbeit.
Es macht bei einem ESP also relativ selten Sinn kleinere Typen als 32Bit einzusetzen.
Der "Sparwille" richtet da oft mehr Schaden an, als es Nutzen bringt.
