Wenn ich in meinem Code eine Variable als unsigned int oder uint8_t
definieren bekomme ich bei jeder for-funktion immer folgende
Fehlermeldung:
warning: comparsion is always true due to limited range of data types
Meine for-funktion sieht folgendermaßen aus:
for (t=wait;t>=0;t--)
{
//führe code in for-schleife aus
}
Irgendjemand eine Idee woran das liegen kann?
Upps, mein Fehler !
Aber so müsste es doch gehen.
Zumindest bekomme ich keine Fehlermeldung mehr.
for (t=wait;t|=0;t--)
{
//führe code in for-schleife aus
}
> Aber so müsste es doch gehen.
Ob das so geht kannst du in wenigen Minuten selbst, evlt. mit Hilfe
eines Debuggers, herausfinden.
Interessanterweise sollte das tatsächlich funktionieren, wenn auch eine
unübliche Lösung. Aber bitte tu dir den Gefallen und lies das Kapitel
über for-Schleifen und das über Vergleichsoperatoren in deinem C-Buch
nochmal genau durch, damit du verstehst, wieso das funktioniert. :)
SORRY!! Ohne die ";" SCH... Kopiererei.
for(t = wait; t; t--)
{
/* code... */
}
ist Code-sparender als z.B.
for(t = 0; t < wait; t++)
{
/* code... */
}
und somit schon üblich.
> und somit schon üblich.
Auf diese Weise natürlich (wobei ich vermutlich "t != 0" in die
Bedingung schreiben würde, für den Compiler ist das das gleiche).
Aber schau dir nochmal genau die Version von Tobias an:
> for (t=wait;t|=0;t--)
Du wirst wohl nicht bestreiten, dass "t |= 0" als Bedingung ein wenig
unüblich und nicht gerade sehr intuitiv ist.
Nein, Tobis Variante ist potentiell platzsparender:
for(t = wait; t; t--)
{
/* code... */
}
Ein Test auf 0 ist je nach Architektur schneller als ein Test auf einen
bestimmten Wert.
Allerdings bezweifle ich beinahe, dass das im fertigen Programm
signifikante (=messbare) Auswirkungen hat.
Nachtrag: Die Schleifen unterscheiden sich allerdings ein wenig,
abgesehen von der Laufrichtung. Bei deiner Variante nimmt t niemals den
Wert wait an, dafür ist es beim ersten Durchlauf 0. Bei der
platzsparenderen Variante wird t niemals 0 und ist beim ersten
Durchlauf gleich wait.
Ich habe sicherheitshalber nachgefragt, denn:
Ist 't' nur uint8_t, dann kannst Du Dir die ganze for-Schleife
sparen, die wird ziemlich sicher wegoptimiert. Der Code, der in der
Schleife ausgeführt wird könnte noch Einfluss darauf haben, aber das
ist nach Deinen bisherigen Auskünften unwahrscheinlich.
Wenn Du wissen willst, welche Variante performanter ist, dann musst Du
Dich schon damit auseinandersetzen, wie viele Zyklen die jeweiligen
Assembleranweisungen zur Ausführung benötigen. Ich bin da grad zu faul
zu...
Probiers mal aus!
Kompilier beide Varianten und schau nach, wieviel Code rauskommt.
Das steht im Output Fenster unten am Bildschirm, wenn du im
Programers' Notepad programmierst:
Device: atmega32
Program: 10464 bytes (31.9% Full)
(.text + .data + .bootloader)
Data: 324 bytes (15.8% Full)
(.data + .bss + .noinit)
c:\avr\atmega_projects\mainboard_tester>pause
Drcken Sie eine beliebige Taste . . .
"Also welche Variante ist jetzt potentiell besser ?"
Im Prinzip stimmen die Kommentare oben zwar schon, aber es hängt auch
arg vom Compiler ab. Wenn t in der Schleife nicht verwendet wird, dann
ist beispielsweise bei GCC der Code der Schleife identisch. Weil der
diese klassische Kontrollstruktur identifiziert und optimiert:
.L5:
..for-body..
sbiw r28,1
brne .L5
Und wenn's drauf ankommt: Gilt wait > 0, dann ist
t = wait; do ... while (--t != 0);
etwas kürzer als jede for-Variante.