mein derzeitiges Programm funktioniert tadellos, wenn ich schreibe:
#define #daw100 250
.
.
int main(void)
{
long l;
.
.
if(l>10000L) l= daw100;
wenn ich aber if(l>10000) schreibe statt if(l>10000L), gibt es Probleme.
Woran liegt das?
Was auch immer du unter 'Es gibt Probleme' verstehst: Es liegt jedenfalls nicht am geposteten Mini-Auszug.
.. und der ist auch kein Originalauszug, sondern manuell "dem Originaltext nachempfunden", nicht in C-Tags formatiert, und es gibt keine vernünftige Beschreibung. Mithin kann das Problem nicht relevant sein - sonst würde er sich mehr Mühe geben.
@Klaus: wieso begibst du dich auf das niveau, das du bemängelst? ..tut es dir gut? hilf doch lieber, soweit es geht - glaub mir, auch du wirst dich besser fühlen als jetzt ;-) anyway, jeder ist seines eigenen gllücks schmied.
Master Snowman schrieb: > wieso begibst du dich auf das niveau, das du bemängelst? Habe ich das? Ich habe eigentlich nur gesagt, warum ich den Startbeitrag für nicht zielführend halte. Das hätte der TE nutzen können, um in Zukunft sinnvoller zu fragen und dann vielleicht mehr Hilfe zu bekommen. Eher scheint er deswegen pikiert zu sein, aber das ist sein Problem, nicht meines. Das drückt meine Stimmung jetzt nicht besonders, schließlich kommt so etwas ja öfter vor. > hilf doch lieber, soweit es geht das mache ich auch gerne, aber halt nicht bei Fragen, für die sich der Fragende ziemlich genau 0 Mühe gibt.
Master Snowman schrieb: > hilf doch lieber, Ja, wie denn? Ist doch nichts da, wo man ansetzen könnte! Du glaubst wohl auch es reicht, beim Doktor anzurufen und zu sagen "Es tut weh!" und schon weiß der was du hast.
hannes schrieb: > long l; hannes schrieb: > wenn ich aber if(l>10000) schreibe statt if(l>10000L), gibt es Probleme. Na, dämmerts?
Dohl schrieb: > hannes schrieb: >> long l; > > hannes schrieb: >> wenn ich aber if(l>10000) schreibe statt if(l>10000L), gibt es Probleme. > > Na, dämmerts? Nein, was soll da dämmern? Beides ist völlig gleichwertig. Der Vergleich wird im Zahlenraum long gemcht, und dazu wird der Integer 10000 vom Compiler automatisch nach long gecastet. Ob du an dieser Stelle 10000 oder 10000L schreibst, ist Jacke wie Hose. Es läuft immer darauf hinaus, das der long l gegen dem long 10000 auf die Relation 'größer' getestet wird. Ich glaub ihm ja, dass er ein Problem in seinem Code hat. Aber ich kann auch mit 100% Sicherheit sagen, dass es nicht in den 3 geposteten Zeilen sitzt. (Pikanterweise ist im Threadtitel auch nicht von 10000, in Worten Zehntausen, sondern von 100000L, in Worten Hunderttausend, die Rede. Ja was denn nun? Mal ganz abgesehen, dass Hunderttausend auf einem AVR mit sizeof(int) == 2 sowieso ganz automatisch ein long ist. Auch ohne den Suffix.)
Immer die gleichen siebengescheiten Erbsenklauber. Der TE wollte wissen, was es mit der Schreibweise "Datentyp nach Zahlenwert" auf sich hat.
"long: Ein long ist die erweiterte Form eines int. Im Gegensatz zum int hat dieser Datentyp 8 Bytes. Um eine Zahl als long zu markieren muss dieser ein L angehängt werden. " aus: http://webcache.googleusercontent.com/search?q=cache:VR0S7q4InKAJ:de.wikibooks.org/wiki/Java_Standard:_Primitive_Datentypen+Datentyp+nach+Zahlenwert+%2210L&cd=3&hl=de&ct=clnk&gl=de Das wäre die gewünschte Erklärung, aber warum ergibt es einen Fehler?
Noch so ein klugschwätzer. Long alleine hat auf avr 32bit. also 4 Byte. Was du meinst ist long long - der hat 64bit. Auch wenn Karl Buchegger hier nieder gemacht wird: er hat recht. Die Fehlerbeschreibung ist nicht nur unszureichend sondern auch noch inkonsistent. (10000 vs 100000? Es ist durchaus wichtig was von beidem gemeint ist. Das eine passt in int, das andere nur in Long) Wieder mal ein ganzer Thread den man einfach löchen sollte. Schade um den Speicherplatz. :-(
Der Albi schrieb: > Noch so ein klugschwätzer. > Long alleine hat auf avr 32bit. also 4 Byte. Was du meinst ist long long > - der hat 64bit. Abdul bezog sich — bewusst oder unbewusst — auf Java. Da ist ein long tatsächlich 8 immer Bytes groß. In C und C++ hängt die Größe von der Architektur ab. Auch wenn der TE nicht schreibt, welche Programmiersprache er verwendet (GCC kann auch Java), lässt aber das #define auf C oder C++ schließen. Über die Architektur wissen wir zwar nichts, da dieses Unterforum nicht nur für AVR-, sondern auch für ARM- und MSP430-Mikrocontroller ist, aber für alle drei ist ein long m.W. 4 Byte groß. <trollmodus> > ..., gibt es Probleme. > Woran liegt das? Das Problem lässt sich ganz leicht lokalisieren: Es sind die Bratpfannenschläge von deiner Freundin Liselotte, die du einstecken musst, wenn dein Programm nicht mindestens 1 großes 'L' enthält ;-) </trollmodus> @hannes: Sorry, aber aus deinen bisher geposteten Informationen lässt sich wirklich nicht mehr ableiten, da haben Karl Heinz und Klaus vollkommen recht. Und da solche Fragen hier öfters auftauchen, fallen die Antworten halt auch mal etwas bissiger aus. Einen Vorschlag, wie du deine Frage präzisieren kannst, hat Karl Heinz ja implizit schon geliefert: > Was auch immer du unter 'Es gibt Probleme' verstehst ... Statt dein Problem zu beschreiben, spielst du beleidigte Leberwurst.
Yalu X. schrieb: > halt auch mal etwas bissiger aus. Einen Vorschlag, wie du deine Frage > präzisieren kannst, hat Karl Heinz ja implizit schon geliefert: > >> Was auch immer du unter 'Es gibt Probleme' verstehst ... > > Statt dein Problem zu beschreiben, spielst du beleidigte Leberwurst. Und ein bischen mehr Originalcode wäre auch gut. Oft genug sitzt das Problem nicht dort, wo du es vermutest. Also: 2 Dinge * genügend Code * eine ordentliche Beschreibung, wie sich das Problem bemerkbar macht. Dann werden sie auch qualifiziert geholfen.
Der Albi schrieb: > Long alleine hat auf avr 32bit. also 4 Byte. Was du meinst ist long long > - der hat 64bit. ne "long long" hat mit 64bit nichts zu tun. "long long" kommt aus chengdon und hat keine Ahnung von Mikrorechentechnik sondern schraubt sie nur zusammen. :-)
Der Albi schrieb: > Noch so ein klugschwätzer. Um die Uhrzeit kann eigentlich dann nur ich gemeint sein. > Long alleine hat auf avr 32bit. also 4 Byte. Was du meinst ist long long > - der hat 64bit. Hat mich allerdings auch verwundert. Vielleicht war es zu spät? Ich dachte bislang, long wäre immer 32Bit und nur der unsägliche int plattformabhängig. > Auch wenn Karl Buchegger hier nieder gemacht wird: er hat recht. > Die Fehlerbeschreibung ist nicht nur unszureichend sondern auch noch > inkonsistent. (10000 vs 100000? Es ist durchaus wichtig was von beidem > gemeint ist. Das eine passt in int, das andere nur in Long) > > Wieder mal ein ganzer Thread den man einfach löchen sollte. Schade um > den Speicherplatz. :-( Ganz sicher nicht. Du Schwätzer!
Abdul K. schrieb: > Ich dachte bislang, long wäre immer 32Bit und nur der unsägliche int > plattformabhängig. Die Größen der Datentypen von C und C++ sind alle plattformabhängig, auch die von long, long long und char. Wie ich oben schon geschrieben habe, bezieht sich das, was du zitiert hast http://webcache.googleusercontent.com/search?q=cache:VR0S7q4InKAJ:de.wikibooks.org/wiki/Java_Standard:_Primitive_Datentypen+Datentyp+nach+Zahlenwert+%2210L&cd=3&hl=de&ct=clnk&gl=de aber nicht auf C/C++, sondern auf Java, wo diese Datentypen tatsächlich plattformunabhängig sind. In diesem Thread geht es jedoch, wie es aussieht, um C oder C++.
Es ging mir bei dem Link einfach nur im das angehängte L !
Als link wäre aber z.B. http://openbook.galileocomputing.de/c_von_a_bis_z/005_c_basisdatentypen_019.htm#mjb5d32a7c3c1c65c6a1658a8ab25ba0cb besser...
Ja, sorry. Ich hatte L noch nie in C verwendet, mußte also einfach googeln.
Karl heinz Buchegger schrieb: > Dann werden sie auch qualifiziert geholfen. Lieber Karl Heinz, ich schätze deine qualifizierten Postings in diesem Forum wirklich sehr! Um so mehr erstaunt (und ärgert) es mich, dass du hilfst, diesen grauenhaften Naddel-Auskunfts-Witz noch weiter zu verbreiten. Für jemanden, der versucht Deutsch zu lernen, kann es viel Verwirrung erzeugen, wenn diese falsche Syntax an jeder Ecke auftaucht. Ok, dies ist kein Forum für deutsche Sprache, aber zur Verbreitung von solch einem Quatsch tragen derartige Eintragungen trotzdem bei. Nichts für ungut, ist nicht persönlich gemeint molt
Leute, ihr dürft hier aufhören. Der Fragesteller sitzt doch längst beleidigt in einer Ecke und schmollt, weil alle so gemein zu ihm sind. Der wird sich nicht wieder hier melden, weil er nicht bereit ist, aus Ratschlägen zu lernen.
molt schrieb: Danke für den Rüffel. Im Grunde hast du recht und ich werde mich ein wenig an der Nase nehmen. Trotzdem möchte ich noch ein paar Worte darüber loswerden. > Um so mehr erstaunt (und ärgert) es mich, dass du hilfst, diesen > grauenhaften Naddel-Auskunfts-Witz noch weiter zu verbreiten. So wie jede andere Sprache auch, gibt es im Deutschen ein paar feststehende Phrasen. Phrasen die nicht grammatiklisch korrekt sind, Phrasen die scheinbar völlig am Thema vorbeigehen. Und trotzdem versteht sie jeder und weiß was damit gemeint ist. Ich denke, dass sich dieses "Da werden Sie geholfen" längst verselbstständigt hat und von einem Witz zu einer Phrase geworden ist. > Für > jemanden, der versucht Deutsch zu lernen, kann es viel Verwirrung > erzeugen, wenn diese falsche Syntax an jeder Ecke auftaucht. Es kann ihm aber auch gut tun, wenn er nicht nur Deutsch lernt, wie er es in der Schule lernt, sondern das Deutsch wie es ihm im Alltag begegnen wird. Und das sind oft 2 unterschiedliche Paar Schuhe (schon wieder eine Phrase). > Nichts für ungut, ist nicht persönlich gemeint Kein Problem. Ich fasse es auch nicht persönlich auf. Ich weiß noch, welche Schwierigkeiten ich oft hatte, als ich in englischsprachigen Foren angefangen habe, und die Amerikaner ihre feststehenden Phrasen ganz selbstverständlich benutzten. Oder hast du in der Schule gelernt, was man z.b. unter "barking up the wrong tree" versteht? (Nur um eine der noch am leichtesten zu erratenden Phrasen zu benutzen)
Klaus schrieb: > Leute, ihr dürft hier aufhören. Der Fragesteller sitzt doch längst > beleidigt in einer Ecke und schmollt, weil alle so gemein zu ihm sind. Ist doch egal. Den brauchen wir überhaupt nicht zum Plaudern, oder?
molt schrieb: > sorry, ich meinte natürlich "die andere" Imho war dass die, die nach Naddel und vor Naddel dran war, oder? ;-)
eklige Tunke schrieb: > Imho war dass die, die nach Naddel und vor Naddel dran war, oder? > ;-) Nach der Naddel ist vor der Naddel ... um noch eine weitere Phrase in etwas abgewandelter Form ins Spiel zu bringen ;-)
Karl heinz Buchegger schrieb: > Ich denke, dass sich dieses "Da werden Sie geholfen" längst > verselbstständigt hat und von einem Witz zu einer Phrase geworden ist. Leider hast du wohl recht. Google liefert für die betreffende Phrase 178000 Treffer. oh je...
Um darauf zurückzukommen - was ist denn nun der Unteschied zwischen a=20000 und a=20000UL ??
Hans der C-Programmierer schrieb: > Um darauf zurückzukommen - was ist denn nun der Unteschied zwischen > a=20000 > und a=20000UL Im Ergebnis: keiner. Im Detail: die 20000 im ersten Fall ist vom Typ "int", während 20000UL im zweiten ein "unsigned long" ist. Bei der Zuweisung zu a wird der Wert dann in den Typ von a umgewandelt. 20000 passt auch immer in einen "int", da ein "int" nach Standard immer mindestens einen Wertebereich von -32767 bis +32767 umfassen muss (er muss also immer mindestens 16 Bit haben). Relevant wird der Unterschied aber in anderen Fällen. Die Beispiele im folgenden gehen von einer Architektur wie z.B. dem AVR aus, bei der ein "int" 16 Bits und ein "unsigned long" 32 Bits hat. Zunächst einmal der erste Fall (also mit "int"):
1 | int a = (20000*2)/2; |
Alle Operanden haben hier den Typ "int", deshalb werden auch alle
Berechnungen ausschliesslich mit "int" durchgeführt. Jetzt passt aber
20000*2=40000 nicht mehr in einen int (maximaler Wert wäre 32767),
deshalb kommt es zu einem Overflow, das Ergebnis ist -25536. Geteilt
durch 2 ergibt das -12768, diesen Wert hat man am Ende in a. Ausserdem
erhält man vom gcc auch eine Warnung ("integer overflow in expression").
Jetzt der Fall mit der "unsigned long"-Konstanten:1 | int a = (20000UL*2)/2; |
Diesmal werden die Berechnungen alle mit "unsigned long" durchgeführt, da bei arithmetischen Operationen vereinfacht gesagt immer mit dem "größeren" der beiden Operandentypen gearbeitet wird. Diesmal passt dann die 40000 ohne weiteres in einen "unsigned long", und nach Division durch 2 erhält man am Ende wie erwartet 20000 als Wert für a. Dass das Ergebnis am Ende einem "int" zugewiesen wird spielt hier keine Rolle, es werden immer nur jeweils die beiden Operanden der Rechenoperation betrachtet. Erst ganz am Ende wird in einen "int" umgewandelt, hier passt der Wert 20000 aber ja wieder ohne Probleme rein. Ich hoffe, jetzt ist es etwas deutlicher geworden. Andreas
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.