4. int und long gleich gross

int und long gleich gross

  • *

    Vielen Dank für Deine Antwort 🙂

    0
  • F

    Seit Ansi c99 gibt es auch long long.

    Viele Grüße

    festus0815

    0
  • *

    ich habe hier eine Aussage aus einer c-Klausur:
    "long-Zahlen sind in C immer 32 Bit lang"
    und da wurde die Aussage als richtig markiert

    und die aussage:
    "integer-Zahlen sind in C immer 16 Bit lang" als falsch

    aber long ist doch nicht immer 32 bit lang, oder?

    0
  • Mod

    CMAN schrieb:

    aber long ist doch nicht immer 32 bit lang, oder?

    Korrekt. Die Aufgabe ist dann falsch ,es sei denn man interpretiert das als ein "mindestens". In dem Fall wäre dann aber wiederum die Aussage über die Integer richtig.

    edit: Und hier noch eine Liste der garantierten Mindestgrößen:
    http://en.wikipedia.org/wiki/Limits.h

    0

  • CMAN schrieb:

    "long-Zahlen sind in C immer 32 Bit lang"

    Für gesicherte Größen gibt es im C99 Standard dann u.a.

    uint32_t

    und das sind dann wirklich immer 32 Bit.

    0
  • _

    7.18.1.1 schrieb:

    Exact-width integer types

1 The typedef name intN_t designates a signed integer type with width N , no padding
  bits, and a two’s complement representation. Thus, int8_t denotes a signed integer
  type with a width of exactly 8 bits.
2 The typedef name uintN_t designates an unsigned integer type with width N . Thus,
  uint24_t denotes an unsigned integer type with a width of exactly 24 bits.
3 [b]These types are optional[/b]. However, if an implementation provides integer types with
  widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a
  two’s complement representation, it shall define the corresponding typedef names.

    ja ich weiß, nicht immer auf dem std. rum reiten... 😞

    0
  • L

    Naja aber zumindest in POSIX sind diese Typen Pflicht, und Notfalls kann man sich nen Header schreiben der die Typen entsprechend definiert (#ifdef-Orgien inklusive 😛 )

    0
  • _

    linux_c89 schrieb:

    ... und Notfalls kann man sich nen Header schreiben der die Typen entsprechend definiert (#ifdef-Orgien inklusive 😛 )

    nun ja, aber ich kann doch kein ((uint32_t)a+(uint32_t)b) machen wenn das rechenwerk bzw. der compiler dies nicht implementiert hat. sagen wir mal der gibt nur rechenoperationen auf 8bit her, dann kann ich machen was ich will aber das beste was ich definieren kann ist

    #define uint32_t unsigned char;

    und dann kommt

    uint32_t a=0xFF;
a<<=CHAR_BIT;
if(a==0)
  :eek:

    @edit: möglicherweise ist dies der grund warum diese typen optional sind (c ist doch grad für die kleinen sachen im leben) 😉

    0
  • ?

    In POSIX sind (|u)int_(8|16|32)_t verlangt, 64 bit sind optional, siehe hier. (|u)int64_t ist nur dann garantiert, wenn die Plattform einen entsprechenden Integertyp hat; POSIX verlangt hier keine Wunder von Compilerentwicklern. Eine Plattform, die nicht mit 32-bit-Integern umgehen kann, ist nicht POSIX-konform.

    Im Übrigen möchte ich _-- das typedef-Schlüsselwort ans Herz legen.

    0
  • ?

    _-- schrieb:

    linux_c89 schrieb:

    ... und Notfalls kann man sich nen Header schreiben der die Typen entsprechend definiert (#ifdef-Orgien inklusive 😛 )

    nun ja, aber ich kann doch kein ((uint32_t)a+(uint32_t)b) machen wenn das rechenwerk bzw. der compiler dies nicht implementiert hat.

    Wenn das der Compiler nicht kann, dann geht es natürlich nicht. Aber dann ist er Abseits jedes C-Standards (auch ohne uint32_t und Konsorten).

    _-- schrieb:

    @edit: möglicherweise ist dies der grund warum diese typen optional sind (c ist doch grad für die kleinen sachen im leben) 😉

    Nein. Der Grund warum diese optional sind ist, dass es Geräte gibt bei denen ein Byte ebn nicht 8Bit groß ist, sondern z.B. 9 oder 24 Bit. Und bei denen wäre die Darstellung eines exakt 32Bit großen Typs wirklich aufwändig und v.a. immer ineffizient.

    0
Anmelden zum Antworten