Maximaler Integerwert?

Matrim

[quote="chille07"]ich hätte eine unsinnige aber (meines wissens) funktionierende idee:
wenn man von einem integer=-1 solange 1 abzieht, bis die zahl wieder größer als 0 ist, und diese ausgibt erhält man den maximalen integerwert, da nach überschreiten der minimumgrenze wieder von "oben" begonnen wird... (bei mir hats geklappt!)

mfG (c)h[/quote]

Stimmt, die Idee ist unsinnig *g*

Einfacher (?) geht es wirklich, wenn man sich mit sizeof(int) die Anzahl der Bytes zurück geben lässt, die Integer (ja, ist verschieden auf manchen Systemen) im Speicher belegt.
Damit kann man dann MAX_INT bzw MIN_INT ausrechnen.

Die Idee mit limits.h ist natürlich das, was ich gesucht hab

Danke dafür.

Shade Of Mine

Matrim schrieb:

Einfacher (?) geht es wirklich, wenn man sich mit sizeof(int) die Anzahl der Bytes zurück geben lässt, die Integer (ja, ist verschieden auf manchen Systemen) im Speicher belegt.
Damit kann man dann MAX_INT bzw MIN_INT ausrechnen.

Nur, wenn du weisst, wieviel Bits in einem Byte sind... CHAR_BIT aus limits.h ist da dein Freund

Fazit: ohne limits.h ist es nicht möglich (ausser die unsinnige Methode: berechnen)

Matrim

Nun bin ich verwirrst, sind nicht immer 8 Bits in einem Byte?

freshman

Darstellbar sind im positiven Bereich die natürlichen Zahlen
bis (2 hoch (32-1) – 1); entspricht: (2 hoch (Anzahl Bits – 1) –1) = 2.147.483.647

*glaube ich*

groovemaster

Matrim schrieb:

Nun bin ich verwirrst, sind nicht immer 8 Bits in einem Byte?

Nein.

groovemaster schrieb:

Matrim schrieb:

Nun bin ich verwirrst, sind nicht immer 8 Bits in einem Byte?

Nein.

Wäää? Das möchte ich aber genauer beschrieben haben!
Per Definition ist doch ein Byte 8 Bit groß/lang.

Wenn nun einer kommt und sagt 1Kg sind nicht immer 1000g, dann bräuchten wir auch kein Kg. Also wäre ein Byte auch Sinnlos, wenns es nicht 8 Bits hätte!

Shade Of Mine

freshman schrieb:

Darstellbar sind im positiven Bereich die natürlichen Zahlen
bis (2 hoch (32-1) – 1); entspricht: (2 hoch (Anzahl Bits – 1) –1) = 2.147.483.647

*glaube ich*

Ja, glaubst du vielleicht. Ist aber trotzdem falsch.

@Airdamn:
ein Byte ist die kleinste adressierbare Einheit. Sie hat idR 8 Bit, aber nicht zwingenderweise.
siehe auch: http://medic.bgu.ac.il/comp/course/defs/byte.html

hmm ich glaube 1byte ist schon immer 8bit.
darauf hat man sich jetzt geeinigt. was früher mal war mit 6 oder so, das war früher so. nenn mir mal firmen, welche nicht 1zu8 nehmen. bei den heutigen rechner 32 und 64 bit rechner ist es halt "dumm" 7 zu nehmen. oder ist 7 neuerdings ein teiler von 32/64. oder ist 6 ein teiler? ne man hat sich jetzt auf 8 geeinigt.

siehe auch http://de.wikipedia.org/wiki/Byte

normalerweise gebe ich wikipedia nie zu 100% recht. aber in diesem falle kann ich statt 99 auch 100% recht geben

nette neue smilies
:xmas1: :xmas2: :xmas1:

hehe nehmt sie, solange sie noch da sind

:xmas1: :xmas2: :xmas2: :xmas1:

Shade Of Mine

newkid schrieb:

hmm ich glaube 1byte ist schon immer 8bit.

Nein.
wikipedia sagt auch klar, 8Bit sind ein Oktett

Mal abgesehen davon, dass es in C ja genaugenommen keine Bytes sind, sondern chars.

Wozu hätte man denn die Konstante CHAR_BIT wenn sie doch sowieso immer 8 wäre...?

freshman

freshman schrieb:

Darstellbar sind im positiven Bereich die natürlichen Zahlen
bis (2 hoch (32-1) – 1); entspricht: (2 hoch (Anzahl Bits – 1) –1) = 2.147.483.647

@Shade Of Mine: was stimmt denn daran nicht?

hmmm

@Shade Of Mine

also kannst du mir maybe 8/16/32/64/128 bit rechner nennen, wo nicht 1zu8 ist?
wenn er nen rechner hat mit 14 kann das wohl was anderes sein. aber nenn mir mal konkret rechner wo das nicht so sein sollte

wenn

Mal abgesehen davon, dass es in C ja genaugenommen keine Bytes sind, sondern chars.

dann erübrigt sich die frage und das Problem ja gleich

:xmas1: :xmas2: :xmas2: :xmas1:

:xmas1: :xmas1: :xmas2: :xmas1: :xmas1:

Shade Of Mine

freshman schrieb:

@Shade Of Mine: was stimmt denn daran nicht?

Dass ein int nicht zwangsläufig 32Bit hat.

newkid schrieb:

also kannst du mir maybe 8/16/32/64/128 bit rechner nennen, wo nicht 1zu8 ist?
wenn er nen rechner hat mit 14 kann das wohl was anderes sein. aber nenn mir mal konkret rechner wo das nicht so sein sollte

*lol*
natürlich haben 8/16/32/64/128 bit rechner 8bits per Byte.
Sonst wäre es ja _sehr_ komisch.

google hilft hier aber: http://minnie.tuhs.org/pipermail/tuhs/2004-September/001070.html

Natürlich ist 1 Byte == 8 Bit das gängigste. Aber es gibt eben Systeme (wenn auch verdammt wenige) in denen 1 Byte zB 9 Bit oder 10 Bit hat.

freshman

@Shade: ja gut, aber die allgemeine Form gilt aber:
MAX_INT = (2 hoch (Anzahl Bits – 1) –1)

sagen wir unentschieden

Shade Of Mine schrieb:

freshman schrieb:

@Shade Of Mine: was stimmt denn daran nicht?

Dass ein int nicht zwangsläufig 32Bit hat.

ok vergessen wir das thema. aber schon komisch, dass du ausweihst indem du aufeinmal von int redest. (int != byte)
ich meinte ja nur, das man von 8 ausgehen, kann und darf. wenn man wirklich mal für eine solche exotische maschine ( die du mir immer noch nicht genannt hast ) programmiert, dann sollte man das idr schon vorher wissen. maybe läuft auf soeiner maschine dann nichtmal der C-Compiler ( beispielsweise, also jetzt nicht drauf rumreiten bitte )

der webmaster nimmt mir mein neues spielzeug ( :xmas1: :xmas2: :xmas1: ) am 27.12 weg oder?

:xmas2: :xmas2: :xmas1: :xmas2: :xmas2:

Shade Of Mine

freshman schrieb:

@Shade: ja gut, aber die allgemeine Form gilt aber:
MAX_INT = (2 hoch (Anzahl Bits – 1) –1)

Vollkommen richtig. Und ich habe die Konstante für "Anzahl Bits" auch schon genannt.

[quote="newkid"]

Shade Of Mine schrieb:

freshman schrieb:

@Shade Of Mine: was stimmt denn daran nicht?

Dass ein int nicht zwangsläufig 32Bit hat.

ok vergessen wir das thema. aber schon komisch, dass du ausweihst indem du aufeinmal von int redest. (int != byte)

Weil freshman von 32 Bit geredet hat...

ich meinte ja nur, das man von 8 ausgehen, kann und darf.

Nur sinnvoll ist es nicht...

wenn man wirklich mal für eine solche exotische maschine ( die du mir immer noch nicht genannt hast ) programmiert, dann sollte man das idr schon vorher wissen.

Ich habe dir nen Link gezeigt, da stehen ein paar Beispiele.
Und wenn auf diesen Maschinen ein *BSD läuft, dann ist es nicht allzuabwegig, dass man dafür eine Anwendung schreibt. Natürlich nicht speziell für diese CPU, aber für *BSD - und das wird dann geportet.

Ich verstehe nicht, was daran so schwer sein soll statt 8 CHAR_BIT zu verwenden, wenn man die Anzahl der Bits pro Byte berechnet...

maybe läuft auf soeiner maschine dann nichtmal der C-Compiler ( beispielsweise, also jetzt nicht drauf rumreiten bitte )

Wenn *BSD dort läuft, läuft alles dort.

Niemand streitet ab, dass ein 8 Bit Byte das gängigste ist.
Das sind so kleinigkeiten die ich einfach nicht verstehe. Der C Standard sagt: ein Byte/char hat exakt CHAR_BIT bits (vielleicht wechselt man in Zukunft ja aucg 16Bits?) und gut ist. Da gibt es eigentlich nichts zu diskutieren...

AJ

@newkid
Les dir nochmal den Beitrag von Shade durch. Das int ist in Zusammenhang mit freshmans Kommentar gefallen und nicht mit deinem.

Nur weil du keine anderen Systeme kennst, die nicht 8 bit verwenden, gibt es sie dennoch. Es gibt vieles was du nicht kennst.

Was stellst du dir eigentlich bitte unter einem C-Compiler vor?? Ein C-Compiler für Windows läuft unter Linux auch nicht, auch auf der gleichen Maschine. Compiler müssen für jedes Betriebssystem explicit gebaut werden.

oh jungs. langsam kommts mir wie im kindergarten vor. leider sieht so aus als ob das kind wäre

ne ist gut, ihr habt recht und ich meine ruhe. :xmas1:

das mit dem C compiler hab ich so gemeint, wie ich es gesagt habe und wie du es gesagt hast. wenn es ne exotische maschine ist, und ein exotisches BS dann gibts maybe auch keinen c compiler. was ist daran schwer zu verstehen. die maschine aus dem jahre 58 oder so, das beispiel welches er genannt hat, hat bestimmt keinen c compiler, da es denn nicht gab. und ich glaube nicht, das fuer die kiste jetzt der neuste C compiler genommen wird, und fuer die kiste angepasst wird. ok?

ich meine nur wenn man fuer win oder linux programmiert(linux nicht super exotisch ), dann hat man mit 32/64 bit zu tun und 8bit/byte. wenn man jetzt so ne andere bit kiste hat, informiert man sich idr vorher und wenn man dann weiss das es 1zu6 sind, dann ist das ok. bei normalen win programmen kann man glaub ich ( zumindes NT-reihe ) zu 100% ausgehen, das es 1zu8 ist. und wenn man ein programm dafür schreibt, dann ist das IMMER so.

so genug daruerber gelabbert. ihr habt recht und ich meine ruh. :xmas1: :xmas2: :xmas1:

i love it :xmas1:

AJ

@newkid
Verstehen tust du es trotzdem wohl nicht, hab ich das Gefühl. Sagt dir eigentlich Portabilität was?

Ja ,sagt mir was. Aber nicht jedes Programm muss portabel sein. Es gibt nunmal sehr viele Programme die laufen nur auf WIN z.b. Einige sogar nur ab win2000
Einige laufen nur auf Linux, manche nur auf debian oder so aber nicht offzi. auf Suse ( bestes BSP. VLC, kann man dort nicht so einfach runterladen auf der offiz. site ). Oder Nintendo DS Games, laufen nicht auf PSP oder andersrum. Tausende Programme ( games sind auch programme ) laufen nicht auf jeder Kiste. Die meisten Sachen die programmiert werden, unterstelle ich mal, das diese nicht portabel sind.
Oder im embed. Bereich, da kann es gar nicht portabel sein, wenn man Microcontroller x hat, läuft der nicht auf anderen. Wo liegt das Problem.

Meine Aussage besagt nur, das man wenn man vorher weiss auf was es laufen soll, auch andere ( nicht portable ) Lösungen programmieren kann. Ich sagte nie, "Bitte benutzt nicht CHAR_BIT", klar kann man nehmen, aber andere (zugeschnittene) Lösungen sind deswegen nicht falsch.

Shade Of Mine

newkid schrieb:

wenn es ne exotische maschine ist, und ein exotisches BS dann gibts maybe auch keinen c compiler.

Dir ist schon klar, dass es C Compiler für nahezu jede Maschine gibt? Und Beispiele habe ich auch gebracht...

C Compiler gibt es wirklich fast überall - denn C Compiler sind so schön einfach zu schreiben. Und die C Runtime ist auch nicht wirklich ein so großer Aufwand...

das beispiel welches er genannt hat, hat bestimmt keinen c compiler, da es denn nicht gab. und ich glaube nicht, das fuer die kiste jetzt der neuste C compiler genommen wird, und fuer die kiste angepasst wird. ok?

Wenn NetBSD dort läuft, läuft auch ein C Compiler dort, weil man sonst NetBSD nicht vernünftig verwenden könnte.

ich meine nur wenn man fuer win oder linux programmiert(linux nicht super exotisch ), dann hat man mit 32/64 bit zu tun und 8bit/byte.

Nein, das was du meinst ist x86, der Prozessor also. Denn Linux läuft auf mehr als nur x86 und 64bittern.

Ich bin zu faul die kompatibilitätsliste durchzugehen, aber Linux läuft auf vielen Exoten...

wenn man jetzt so ne andere bit kiste hat, informiert man sich idr vorher

Du willst es nicht verstehen, gell?
Man _weiss_ eben _nicht_, dass das Programm mal auf so einer Kiste laufen soll.

Das nennt sich Portieren - das kommt gerade in der Unix Welt ziemlich oft vor.

bei normalen win programmen kann man glaub ich ( zumindes NT-reihe ) zu 100% ausgehen, das es 1zu8 ist. und wenn man ein programm dafür schreibt, dann ist das IMMER so.

Es sei denn, man will es protieren...

ihr habt recht und ich meine ruh

Natürlich haben wir recht, aber warum widersprichst du uns dann dauernd?

newkid schrieb:

Ja ,sagt mir was. Aber nicht jedes Programm muss portabel sein.

Nicht jedes, aber viele.
Vorallem ist es lächerlich wegen 8 vs CHAR_BIT die Portabilität aufzugeben.

Es gibt nunmal sehr viele Programme die laufen nur auf WIN z.b. Einige sogar nur ab win2000

Und?
Tut es diesen Programmen weh CHAR_BIT zu verwenden? Vielleicht läuft Win2K ja mal auf einer anderen Plattform als Intel/AMD Prozessoren...?

Einige laufen nur auf Linux, manche nur auf debian oder so aber nicht offzi. auf Suse ( bestes BSP. VLC, kann man dort nicht so einfach runterladen auf der offiz. site ).

Das hat aber andere Ursachen als Portabilität.

Die meisten Sachen die programmiert werden, unterstelle ich mal, das diese nicht portabel sind.

Und?
Ich nehme übrigens an, dass mehr Portable Programme existieren als umgekehrt. Denn die Unix Welt ist ziemlich groß...
Aber OK, da kann man nur spekulieren.

Ändert aber nichts daran, dass man CHAR_BIT verwenden sollte.

Oder im embed. Bereich, da kann es gar nicht portabel sein, wenn man Microcontroller x hat, läuft der nicht auf anderen. Wo liegt das Problem.

Doch, geht schon. Nicht gut und nicht immer, aber teilweise geht es.
Problem liegt in deiner Ignoranz.

Meine Aussage besagt nur, das man wenn man vorher weiss auf was es laufen soll,

Was man aber nur verdammt selten weiss.

Ich sagte nie, "Bitte benutzt nicht CHAR_BIT", klar kann man nehmen, aber andere (zugeschnittene) Lösungen sind deswegen nicht falsch.

Falsch nicht, aber Blödsinn.
Weil es unnötig ist.

Ich dereferenziere ja auch keine NULL Zeiger, nur weil meine Plattform das erlaubt...

Das sind so kleinigkeiten die uU manchmal entscheidend sein können. Der Aufwand ist ja mit oder ohne CHAR_BIT identisch (mal abgesehen davon, dass CHAR_BIT besser dokumentiert was da abgeht, was alleine schonmal ein verdammt guter Grund dafür ist) aber hin und wieder kann es Problemen vorbeugen die du ohne CHAR_BIT vermutlich nie gefunden hättest.

Ist wie void main() - ich sehe keinen Vorteil darin (natürlich auch keinen großen Nachteil, sondern nur einen kleinen) aber die Leute bevorzugen es.
Warum?
Was stört dich an CHAR_BIT? Warum würdest du es nicht verwenden?
Ist die Gefahr, dass du dann auf CHAR_BIT vergisst (weil du es ja nie verwendet hast) wenn du es mal brauchst, nicht relativ groß?

Ich verstehe es einfach nicht