Zahlenformat 100000L?

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.

Freut mich, geholfen zu haben!

@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.

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.)

"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:
> 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.

Auch nicht persönlich, aber war das Naddel?

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?

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 ;-)

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