Hallo, Versuche gerade die Grundlagen der C Sprache zu erlernen dabei hätte ich 2 kurze Fragen zu einem C-Code: 1) Was bedeutet *string++ ? Wird hier der Index des Strings also String[n] um eins erhöht ? Wäre das dann dasselbe wie *(string+1) ? 2) Was bedeutet die Variablendeklaration "uint8_t" in der IF Anweisung if(((uint8_t)(w_size-r_size))==0) ? Habe es versucht in google zu suchen ist aber wegen des zusammenhags nur schwer oder gar nicht zu finden. Könnte mir da jemand helfen ?
Gast
#2801872
Bernd Leiser schrieb: > 1) Was bedeutet *string++ ? > Wird hier der Index des Strings also String[n] um eins erhöht ? Wäre > das > dann dasselbe wie *(string+1) ? nein string ist ein zeiger und diese adresse wird um ein erhöhr, vorher wird aber noch der wert der Adresse zurückgeben char c = *string; string++; > 2) Was bedeutet die Variablendeklaration "uint8_t" in der IF Anweisung > if(((uint8_t)(w_size-r_size))==0) ? das ist nur ein CAST - aber hier irgendwie nicht sinnvoll. besser lesbar sollte das sein if ( w_size == r_size ) ?
1. Pointer inkrementieren, essentiell einen Buchstaben weitergehen ( schau mal http://www.youtube.com/watch?v=jn9NBNF9Zr8 ) 2. uint8_t bedeutet vorzeichenlose Zahl (Integer) 8 bit breit. nagel mich nicht drauf fest ;-) Grüße edit: zu langsam ;-)
Ok danke für die schnellen Antworten. Mit dem Zeiger war mir nicht ganz klar was addiert wird Wert oder Adresse. Mit dem uint8_t nehme ich mal an das es in der If Anweisung keine Funktion hat sondern als Hilfe dient oder ? Da beide Variablen schon deklariert wurden.
Gast
#2801914
Bernd Leiser schrieb: > Ok danke für die schnellen Antworten. Mit dem Zeiger war mir nicht ganz > klar was addiert wird Wert oder Adresse. In solchen Fällen hilft es sich die Operatorenpräzedenz (oder wie man das auch schreiben mag) vor Augen zu führen. Richtige Programmierer kennen die auswendig... > Mit dem uint8_t nehme ich mal > an das es in der If Anweisung keine Funktion hat sondern als Hilfe dient > oder ? Da beide Variablen schon deklariert wurden. Google mal nach "c cast", in 2 Wörtern ist das nicht zu erklären.
Bernd Leiser schrieb: > Ok danke für die schnellen Antworten. Mit dem Zeiger war mir nicht ganz > klar was addiert wird Wert oder Adresse. ++ bindet stärker als * Schau dir die Table of operator precedence an. http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_precedence > Mit dem uint8_t nehme ich mal > an das es in der If Anweisung keine Funktion hat sondern als Hilfe dient > oder ? Da beide Variablen schon deklariert wurden. Das ist ein Cast! Einem Wert, der einen bestimmten Datentyp hat, wird ein anderer Datentyp aufgezwungen. Du brauchst ein C-Buch. Dringend. Googeln und halbseidene Online-Tutorien sind kein Ersatz für ein ordentliches Lehrbuch.
Ok das hat mir schon weitergeholfen. Danke noch mal. Werde mich dann mal damit beschäftigen.
Gast
#2802813
Moritz M. schrieb: > nagel mich nicht drauf fest ;-) Warum antwortest du dann? Sprachgrundlagen sind keine Hexerei und auch kein Ratespiel. Kein Problem, wenn einer was nicht weis, aber ich kann es nicht ab dass hier so viel Halbwissen verbreitet wird.
Gast
#2802869
troll schrieb: > In solchen Fällen hilft es sich die Operatorenpräzedenz (oder wie man > das auch schreiben mag) vor Augen zu führen. Richtige Programmierer > kennen die auswendig... Nein, nur Leute, die sich fuer richtige Programmierer halten. Leute die richtige Entwickler sind, haben die laengst vergessen, weil sie nur Code schreiben, der davon nicht abhaengt.
Gast
#2802896
Marwin schrieb: > weil sie > nur Code schreiben, der davon nicht abhaengt. was allerdings theoretisch, praktisch, und ganz überhaupt unmöglich ist... Oliver
Oliver schrieb: > Marwin schrieb: >> weil sie >> nur Code schreiben, der davon nicht abhaengt. > > was allerdings theoretisch, praktisch, und ganz überhaupt unmöglich > ist... Nunja, Klammern kann man quasi immer setzen :) Grüße, Simon
Marwin schrieb: > troll schrieb: > >> In solchen Fällen hilft es sich die Operatorenpräzedenz (oder wie man >> das auch schreiben mag) vor Augen zu führen. Richtige Programmierer >> kennen die auswendig... > > Nein, nur Leute, die sich fuer richtige Programmierer halten. Leute > die richtige Entwickler sind, haben die laengst vergessen, weil sie > nur Code schreiben, der davon nicht abhaengt. Und genau wie praktisch alle absoluten (und beinahe religiösen) Aussagen ist auch diese nicht richtig. In Wirklichkeit gibt es praktisch keinen C-Programmierer, der seinen Code tatsächlich so schreibt, dass er komplett frei von Operatorpräzedenz-Abhängigkeiten ist. Oder wie viele Programmierer kennst du, die
1 | |
schreiben würden, statt
1 | |
? Die Wahrheit liegt natürlich wieder mal irgendwo in der Mitte. Der erfahrene Programmierer hat einen Satz an Operatorpräzedenzen, deren er sich absolut sicher ist, und die dann auch unweigerlich in den Code einfließen (wie obiges Beispiel), und wenn er sich nicht ganz sicher ist, schaut er nicht lange in irgendwelchen Tabellen nach, sondern setzt einfach Klammern.
Stefan Ernst schrieb: > Oder wie viele Programmierer kennst du, die > > x = (a + b); > > schreiben würden, statt > > x = a + b; > > ? Oder statt
1 | |
gar
1 | |
Ja, so machen es die "richtigen" Entwickler ;-)
Yalu X. schrieb: > ((p2[i]).x) = ((((-((p[i]).x)) * scale) + offs) + x0); > > Ja, so machen es die "richtigen" Entwickler ;-) Nönönö, so geht das aber nicht! Da sind ja überall undefinierte Typen drin, die Experten casten natürlich die Operanden anstatt so undefinierten Code zu produzieren. Bekanntlich ist C die Programmiersprache, die immer zufällige Ergebnisse liefert — zumindest les ich das immer wieder hier im Forum, also muss da was dran sein! Lange Rede, kurzer Sinn, richtig muss das so heissen:
1 | |
int16 ist natürlich eine Eigenkreation. Denn die Typen aus stdint.h sind böse!
Johann L. schrieb: > int16 ist natürlich eine Eigenkreation. Denn die Typen aus stdint.h sind > böse! int16 aber auch, weil das genauso wie int16_t eine völlig kryptische, C-typische Abkürzung ist. Klar lesbarer Code sieht so aus:
1 | |
Ok, in meinem Beispiel tauchen noch die wenig aussagekräftigen Identi- fier p2, p, i, s, scale usw. auf, die ebenfalls durch verbösere Namen ersetzt werden sollten. Auch size_t ist natürlich noch schwer optimie- rungsbedürftig.
Don't drink and code!
Yalu X. schrieb: > Auch size_t ist natürlich noch schwer optimie-rungsbedürftig. Oh, erwischt. Mea culpa. Ich werd nie zum Experten... Falk Brunner schrieb: > Don't drink and code! Das Original ist doch "Don't drink and drive!"
Gast
#2803319
Falk Brunner schrieb: > Don't drink and code! nene, die haben was stärkeres intus Einen schönen Abend noch :-)
Gast
#2803938
Johann L. schrieb: > Nönönö, so geht das aber nicht! Arroganz schreibt immer noch den schlechtesten Code.
Gast
#2804003
Johann L. schrieb: > Lange Rede, kurzer Sinn, richtig muss das so heissen:
1 | |
Ich kenne ein grafisches Programmier-Tool, das generiert tatsächlich solchen Code...
Falk Brunner schrieb: > Don't drink and code! http://xkcd.com/323/ Hoffentlich liest ehydra das =)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.