Hallo Leute Muss euch leider schon wieder nerven. Hab hier im Forum gelesen, das UL für unsigned Long steht. Leider hab ich nirgends gefunden, wie ein unsigned long definiert ist. Nun meine Fragen: 1) Wie ist ein unsigned long definiert( wie viele Stellen hat er)? 2) Wo kann ich so was nachlesen 3) Bei dem Beispiel,das ich gesehen hatte, wurde an die Konstanten bei einer Rechnung mit uint32_t das UL angehängt, gilt das auch für Rechnungen mit uint64_t oder muss man dort was anderes anhängen, weil unsigned long zu klein ist( keine 20 Stellen hat)?
Du solltest genauer angeben welchen Compiler bzw welchen Controller du meinst. Long ist nicht gleich Long. Je nach System kann Long 32 oder 64 Bit groß sein. Weder Integer noch Long oder Word sind in ihrer Größe fest definiert
1.) Der Datentyp "long" ist normalerweise ein Integer mit 32bit. (Zahlen von 0 - 4.2nochwas*10^9) "unsigned" heißt "ohne Vorzeichen", d.h. nur positive Zahlen und die Null. 3.) UL noch einer Konstante kennzeichnet den Datentyp als "unsigned long". "10UL" sollte gleichbedeutend sein mit "(unsigned long)10". Bei 64bit-Integern würde ich vermuten, dass man ein "LL" bzw. "ULL" anhängen muss, (z.B. "10ULL")
Schau dir vielleicht die Includedatei stdint.h bei deiner Compiler-Toolchain an. Darin stehen Makros für die maximalen und minimalen Zahlen der ZahlenTypen.
Markus wrote:
> Weder Integer noch Long oder Word sind in ihrer Größe fest definiert
Allerings gibt es Mindestlängen im Standard: short und int sind
mindestens 16, long mindestens 32 Bit lang.
@ Detlev T. (detlevt) >> Weder Integer noch Long oder Word sind in ihrer Größe fest definiert Was eine Glanzleistung der Informatik war . . . :-( >Allerings gibt es Mindestlängen im Standard: short und int sind >mindestens 16, long mindestens 32 Bit lang. Ich nutze auf uCs nur intXX_t, da weiss man was man hat. MFG Falk
Falk Brunner wrote: >>> Weder Integer noch Long oder Word sind in ihrer Größe fest definiert > > Was eine Glanzleistung der Informatik war . . . :-( Wieso diese Ironie? Das Ganze bekommt dann einen Sinn, wenn man an die Sourcecode-Portabilität von C-Code denkt. Das gibt dem Compiler mehr Freiheit, einen an das jeweilige System angepassten Code zu erzeugen. Stelle dir einmal vor, man hätte damals die Länge von int zwingend auf die Registerlänge einer PDP-1 festgelegt. Das waren 18 Bit. Das müsste heute auf 32- und 64-Bit Rechnern leistungszehrend emuliert werden. In Hinblick auf die Zukunft ist es häufig besser, nicht immer alles festlegen zu wollen.
@ Detlev T. (detlevt) >> Was eine Glanzleistung der Informatik war . . . :-( >Wieso diese Ironie? Das Ganze bekommt dann einen Sinn, wenn man an die >Sourcecode-Portabilität von C-Code denkt. Das gibt dem Compiler mehr >Freiheit, einen an das jeweilige System angepassten Code zu erzeugen. Und was ist mit den Problemen/Seiteneffekten, die aus diesem Ansatz entstehen? >Stelle dir einmal vor, man hätte damals die Länge von int zwingend auf >die Registerlänge einer PDP-1 festgelegt. Das waren 18 Bit. Das müsste Naja, das hätte sich auch irgendwann mal sinnvoll eingependet, auf dem heute gültigen 8er Schema. >Hinblick auf die Zukunft ist es häufig besser, nicht immer alles >festlegen zu wollen. Aber solche schwammigen Definitionen machen allzuoft auch mehr Probleme als sie lösen. Und warum hat man die Fliesskommazahlen sauber und fest definiert, Integer aber nicht? MFG Falk
Falk Brunner wrote: > Und was ist mit den Problemen/Seiteneffekten, die aus diesem Ansatz > entstehen? Welche? >>Stelle dir einmal vor, man hätte damals die Länge von int zwingend auf >>die Registerlänge einer PDP-1 festgelegt. Das waren 18 Bit. Das müsste > > Naja, das hätte sich auch irgendwann mal sinnvoll eingependet, auf dem > heute gültigen 8er Schema. Eben nicht! Das wäre dann ja nicht mehr möglich gewesen. >>Hinblick auf die Zukunft ist es häufig besser, nicht immer alles >>festlegen zu wollen. > > Aber solche schwammigen Definitionen machen allzuoft auch mehr Probleme > als sie lösen. Und warum hat man die Fliesskommazahlen sauber und fest > definiert, Integer aber nicht? Welche? Und auch bei Gleitkommazahlen war nicht immer von Anfang an alles "sauber und fest definiert": Guckst du hier: http://home.earthlink.net/~mrob/pub/math/floatformats.html Und selbst die IEEE 754 Norm,auf die du dich wahrscheinlich beziehst, definiert "extended"-Formate, die lediglich die Mindestbitzahl vorschreiben. Guckst du hier: http://de.wikipedia.org/wiki/IEEE_754#Zahlenformate_und_andere_Festlegungen_des_IEEE_754-Standards
> Ich nutze auf uCs nur intXX_t, da weiss man was man hat. Wenn man direkt mit Hardware-Registern arbeitet, ist das auf jeden Fall sinnvoll. Aber sonst bieten sich eher die int_fastXX_t oder int_leastXX_t an. Diese sind die schnellsten bzw. kleinsten Typen, die noch mindestens so viele Bits haben, wie angegeben. Damit schränkt man es nicht auf eine feste Bitzahl ein, sondern auf das, was groß genug und trotzdem für den Anwendungsfall optimal ist - die fast-Typen, wenn man möglichst schnellen Code will, die least-Typen, wenn man Platz sparen muß. >>Stelle dir einmal vor, man hätte damals die Länge von int zwingend auf >>die Registerlänge einer PDP-1 festgelegt. Das waren 18 Bit. Das müsste > > Naja, das hätte sich auch irgendwann mal sinnvoll eingependet, auf dem > heute gültigen 8er Schema. Und doch hat sich diese Definition immer noch als zu restriktiv erwiesen. Eigentlich sollte int der native Typ der Architektur sein, also z.B. 16 Bits auf einen 16-Bit-Prozessor, 32 Bits auf einem 32-Bit-Prozessor. Auf 8-Bit-Prozessoren darf er aber nicht 8 Bits breit sein, da er auf mindestens 16 Bits eingeschränkt ist. Auf 64-Bit-Systemen ist er meistens auch nicht 64 Bits breit, da nur char und short kleiner sein dürfen und das nicht ausreicht für 8-, 16- und 32 Bit-Typen. Es gibt auch DSPs, die nur mit vielfachen von 24 Bits umgehen können. Wer würde denn einen Compiler benutzen, der darauf dann umständliche und langsame 8-, 16- und 32-Bit-Typen anbietet, aber eben nicht die optimialen mit 24 oder 48 Bits? >Hinblick auf die Zukunft ist es häufig besser, nicht immer alles >festlegen zu wollen. Ack. > Aber solche schwammigen Definitionen machen allzuoft auch mehr Probleme > als sie lösen. Zu enge Festlegungen machen in der Regel viel mehr Probleme. Es gibt sehr viele Hard- und Software-Spezifikationen, bei denen nachträgtlich mit unglaublich üblen Tricks gearbeitet wird, um die bei der ursprünglichen Definition festgelegten Enschränkungen zu umgehen. > Und warum hat man die Fliesskommazahlen sauber und fest definiert, > Integer aber nicht? Wie kommst du darauf, daß das der Fall sei?
@ Detlev T. (detlevt) >> Und was ist mit den Problemen/Seiteneffekten, die aus diesem Ansatz >> entstehen? >Welche? Wenn man z.B. ein Array von int nutzt, hat das mal 2*N und mal 4*N bytes Speicherplatz. Was bei bestimmten Portierungen zu Problemen führt, vor allem auf kleinen uCs. Oder wenn ich irgendwelche feste Structs brauche, z.B. um Sektoren eines FATs abzubilden. etc. >Eben nicht! Das wäre dann ja nicht mehr möglich gewesen. Wieso? Weil PDP-11 der unumstössliche Standard ist? C'mon. >Welche? Und auch bei Gleitkommazahlen war nicht immer von Anfang an >alles "sauber und fest definiert": Guckst du hier: >http://home.earthlink.net/~mrob/pub/math/floatformats.html Mag sein, mittlerweil ist es AFAIK aber schon recht klar definiert, oder? 32/64/80 Bit Float. @ Rolf Magnus (Gast) >> Ich nutze auf uCs nur intXX_t, da weiss man was man hat. >Wenn man direkt mit Hardware-Registern arbeitet, ist das auf jeden Fall >sinnvoll. Aber sonst bieten sich eher die int_fastXX_t oder Nicht nur dort, auch für Variablen. >trotzdem für den Anwendungsfall optimal ist - die fast-Typen, wenn man >möglichst schnellen Code will, die least-Typen, wenn man Platz sparen >muß. Na mal ehrlich, sind diese Fast-Typen WIRKLICH schneller als "normale" intxx_t oder ist das eher akademische Spielerei? >Und doch hat sich diese Definition immer noch als zu restriktiv >erwiesen. ??? Verstehe ich nicht. Wenn ich ein Programm schreibe, dann überlege ich mir, welche Zahlen verarbeitet werden müssen und wähle entsprechende Datentypen. Warum in aller Welt müssen die dann so schwammig definiert sein? Ein Byte ist ein Byte ist ein Byte, egal auf welcher Machine. Dito mit 32 Bit Werten. Und damit ist auch das logische Verhalten vollkommen maschinenunabhängig. Dass ein 8-bitter bei 32 Bit nicht so flott wie ein 32 Bitter ist ist dabei vollkommen logisch und auch egal. >Es gibt auch DSPs, die nur mit vielfachen von 24 Bits umgehen können. Ausnahmen. Als C entwickelt wurde war an DSPs noch nie und nimmer zu denken. >Wer würde denn einen Compiler benutzen, der darauf dann umständliche und >langsame 8-, 16- und 32-Bit-Typen anbietet, aber eben nicht die >optimialen mit 24 oder 48 Bits? So ein Code ist meist wenig portabel, da kann man sich auch einen int24_t vorstellen. >> Aber solche schwammigen Definitionen machen allzuoft auch mehr Probleme >> als sie lösen. >Zu enge Festlegungen machen in der Regel viel mehr Probleme. Naja, hier wirds philosophisch. Schau dir mal an, was die ganzen "offenen" Standards an "schönen" Dingen so mitbringen. Wenn da nicht bissel ne straffe Hand (=Standard) regiert, wird Larifari draus. >sehr viele Hard- und Software-Spezifikationen, bei denen nachträgtlich >mit unglaublich üblen Tricks gearbeitet wird, um die bei der >ursprünglichen Definition festgelegten Enschränkungen zu umgehen. Das ist ein GANZ anderes Thema. Wenn ich was übermässig aufbohren will passiert sowas nun mal. Und die heilige Kuh der Abwärtskompatibilität muss halt ab und zu dran glauben. >> Und warum hat man die Fliesskommazahlen sauber und fest definiert, >> Integer aber nicht? >Wie kommst du darauf, daß das der Fall sei? Hab ich in meiner jugendlichen Naivität mal so angenommen, dass 32/64/80 Bit Floats in C recht klar standardisiert sind. ;-) MFG Falk P.S. Man erinnere sich an die Zeit in Deutschland, als Kleinstaaterei gross geschrieben wurde (ist ja teilweise noch heute so, nennst sich nur P.C. Förderalismus). Dutzende Masse und Gewichte, etc. P.P. Die Vereinheitlichung , später S.I. waren da ein Segen. (Jaja, Äpfel und Birnen)
Falk Brunner wrote: > Wenn man z.B. ein Array von int nutzt, hat das mal 2*N und mal 4*N bytes > Speicherplatz. Was bei bestimmten Portierungen zu Problemen führt, vor > allem auf kleinen uCs. Oder wenn ich irgendwelche feste Structs brauche, > z.B. um Sektoren eines FATs abzubilden. etc. Das ist ziemlich philosophisch. Denn diese Probleme treten ja dann auf, wenn man nicht portablen Code portiert, bei dem man z.B sich auf int=16Bit verlässt, was der Standard nicht garantiert. Wer ist dann Schuld, der Standard oder der Programmierer? Man muss sich in solchen Fällen auf jedem System halt eine Umgebung mit Typendefinitionen schaffen, wo die Bit-Längen garantiert sind. Das ist möglich, ohne dass dies bei den Standard(!)-Typen sein muss. Genau dafür gibt es ja MAX_INT etc, wo man das überprüfen kann. >>Eben nicht! Das wäre dann ja nicht mehr möglich gewesen. > > Wieso? Weil PDP-11 der unumstössliche Standard ist? C'mon. Nein, weil 18-Bit dann der Standard gewesen wäre. Wie willst du das nachträglich ändern? Jeder Compiler, der das anders handhabt, wäre nicht mehr standard-konform und würde daher nicht benutzt. Schon mal vom A20-Gate gehört? (http://de.wikipedia.org/wiki/A20-Gate#Zukunft_des_A20-Gates) Selbst die allermodernsten x86-Prozessoren haben es noch, um standard-konform zu sein. Dabei wäre das AFAIK nur nötig, wenn jemand damit MS-DOS 1.0 benutzen wollte. Blödsinnig, aber einmal so festgelegt. > Dass ein 8-bitter bei 32 Bit nicht so flott wie ein 32 Bitter ist ist > dabei vollkommen logisch und auch egal. Umgekehrt sind aber viele 32-Bitter bei 8- & 16-Bit nicht so flott wie bei 32-Bit (Stichwort Busbreite, Missalignment). Deshalb hat man es ja gerade dem Compiler überlassen, die für diese Umgebung passende Bit-Länge auszuwählen, und nur Mindestwerte für die Standardtypen vorgegeben. Es steht dir ja frei, deine eigenen Typen zu definieren, die auf allen Systemen, mit denen du zu tun hast, die gleiche Größe haben. Das muss deswegen ja nicht Teil des Standards sein.
>> Eben nicht! Das wäre dann ja nicht mehr möglich gewesen. > > Wieso? Weil PDP-11 der unumstössliche Standard ist? C'mon. Nein, aber als C definiert wurde, wußte man nicht, was mal der unumstößliche Standard wird bzw. ob es überhaupt jemals einen geben würde. >>trotzdem für den Anwendungsfall optimal ist - die fast-Typen, wenn man >>möglichst schnellen Code will, die least-Typen, wenn man Platz sparen >>muß. > > Na mal ehrlich, sind diese Fast-Typen WIRKLICH schneller als "normale" > intxx_t oder ist das eher akademische Spielerei? Sie sind wie die intXX_t auch einfach nur typedefs auf die eigentlichen Integer-Typen. Die Idee, zu sagen, daß int der native Typ sein sollte, war, daß man dann einfach int nehmen kann, und es wird der Typ verwendet, der auf der Plattform am effizientesten ist. Meistens braucht man aber doch einen gewissen mindest-Wertebereich. Dazu sind dann die fast- und least-Typen da. Man braucht eigentlich selten einen Typ mit exakt 16 Bits. Meistens tut es einer, der nur mindestens soviele Bits hat. Und z.B. auf dem x86 im 32-Bit-Modus ist ein 32-Bit-Zugriff tatsächlich schneller als einer mit 16 Bits. >>Und doch hat sich diese Definition immer noch als zu restriktiv >>erwiesen. > >??? > Verstehe ich nicht. Hättest nur meine weitere Erklärung dazu lesen müssen. >>Es gibt auch DSPs, die nur mit vielfachen von 24 Bits umgehen können. > > Ausnahmen. Als C entwickelt wurde war an DSPs noch nie und nimmer zu > denken. Ja eben, das ist genau das, was ich meine. Damit C universell bleibt und auch auf Plattformen implementiert werden kann, an die man zum Zeitpunkt der Definition noch gar nicht denken konnte, darf man diese Definition nicht zu restriktiv machen. >>Wer würde denn einen Compiler benutzen, der darauf dann umständliche >>und langsame 8-, 16- und 32-Bit-Typen anbietet, aber eben nicht die >>optimialen mit 24 oder 48 Bits? > > So ein Code ist meist wenig portabel, da kann man sich auch einen > int24_t vorstellen. Manche Teile können schon portabel sein. > Hab ich in meiner jugendlichen Naivität mal so angenommen, dass > 32/64/80 Bit Floats in C recht klar standardisiert sind. ;-) Nein. Es gibt auch hier nur Mindestanforderungen. float muß mindestens 6 Dezimalstellen korrekt darstellen können, double und long double 10. Und 80 Bits für long double sind z.B. schon unter Windows nicht üblich. Da sind double und long double beide 64 Bit breit. Unter Linux auf dem PC ist long double 128 Bit breit, benutzt aber nur 80 Bits davon für die Wertrepräsentation.
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.