unsigned og signed

signed betyder at datatypen kan indeholde både negative og positive værdier.
unsigned betyder at datatypen kan indeholde positive værdier.

F.eks.

unsigned char p = 0;
char q = 0;
while(true)
{
  cout << "p: " << p;
  cout << "\tq: " << q << endl;
  p++;
  q++;
}

(Prøv det)

int (og også char) er per default signed.

char kan have værdier -128..127
short int kan (på de fleste systemer) have værdier -32768..32767
long int kan (på de fleste systemer) have værdier -2147483648..2147483647
unsigned char kan have værdier 0..255
unsigned short int kan (på de fleste systemer) have værdier 0..65535
unsigned long int kan (på de fleste systemer) have værdier 0..4294967295

hmmmm hva er fordelen i det ??

altså smider den bare en exception hvis min unsigned variable går hen og bliver negativ ??

er det stort set det samme som
int i = -29;
if(i < 0)
{
// FEJL
}else{
// FINT
}

Nej.

En unsigned int som bliver negativ bliver bare stor.

-1 i en unsigned long int (på 32 bit) vil være 4.2 milliarder

Der er 2 grunde til at vælge unsigned:
* man vil ikke have negative værdier
* man har brug for at tallene kan blive dobbelt så store

char er ikke signed pr default, char er signed på nogle platforme/compilere og unsigned på andre.

ahhhh det giver altså mere "plads" at til data i den positive ende at gøre den unsigned .... ???

Det er veldefineret hvad der sker når en unsigned "løber over", det er udefineret hvad der sker med en signed.

så lige en ting mere .... nu snakker arne_v
om short int og long int ..

hvad er int i sig selv? er det per default short int ???
ved godt der kommer nogne slemme begynder spørgsmål nu men de er meget rare at få på plads!... :)

short int er en kort int
long int er en lang int
int er lig med en af dem (muligvis kan den også være midt imellem)

typisk var short 16 bit long 32 bit og int 16 bit i gamle dage men
typisk short 16 bit long 32 bit og int 32 bit idag.

har det noget med programmets hurtighed om man skal vælge 16bit eller 32bit ? eller plads i hukommelsen eller ?

Unsigned bør altid bruges når man laver bit-manipulationer:

  int i = 0x80000000;
  unsigned int ui = 0x80000000;
  for (int j = 0; j < 34; j++)
  {
    printf("%12d %08x %12u %08x\n",i,i,ui,ui);
    i = i >> 1;
    ui = ui >> 1;
  }

giver følgende output (Visual C++ .Net)

-2147483648 80000000  2147483648 80000000
-1073741824 C0000000  1073741824 40000000
  -536870912 E0000000    536870912 20000000
  -268435456 F0000000    268435456 10000000
  -134217728 F8000000    134217728 08000000
  -67108864 FC000000    67108864 04000000
  -33554432 FE000000    33554432 02000000
  -16777216 FF000000    16777216 01000000
    -8388608 FF800000      8388608 00800000
    -4194304 FFC00000      4194304 00400000
    -2097152 FFE00000      2097152 00200000
    -1048576 FFF00000      1048576 00100000
    -524288 FFF80000      524288 00080000
    -262144 FFFC0000      262144 00040000
    -131072 FFFE0000      131072 00020000
      -65536 FFFF0000        65536 00010000
      -32768 FFFF8000        32768 00008000
      -16384 FFFFC000        16384 00004000
      -8192 FFFFE000        8192 00002000
      -4096 FFFFF000        4096 00001000
      -2048 FFFFF800        2048 00000800
      -1024 FFFFFC00        1024 00000400
        -512 FFFFFE00          512 00000200
        -256 FFFFFF00          256 00000100
        -128 FFFFFF80          128 00000080
        -64 FFFFFFC0          64 00000040
        -32 FFFFFFE0          32 00000020
        -16 FFFFFFF0          16 00000010
          -8 FFFFFFF8            8 00000008
          -4 FFFFFFFC            4 00000004
          -2 FFFFFFFE            2 00000002
          -1 FFFFFFFF            1 00000001
          -1 FFFFFFFF            0 00000000
          -1 FFFFFFFF            0 00000000

Signed int giver ihvertfald ikke det resultat jeg forventer

db

Hvad størrelsen af long, int og short angår:
sizeof(long) >= sizeof(int) >= sizeof(short)
Dvs at en long ikke er shortere end en short :-)

db

1) int skal naturligvis være stor nok til at kunne indeholde de data du skal
  bruge

2) hvis du skal have rigtigt store arrays kan det være en fordel at
  bruge mindst mulige som kan opfylde #1 af memory hensyn

I de fleste tilfælde kan du bare bruge int og regne med at compileren har
en fornuftigt størrelse for den.

Jeg er lidt ueneig med hensyn til signed int og shift.

Det giver faktisk konsistente resultater:

>>1 og /2 giver samme resultat.

Nogen gange skam man faktisk bruge den sign extension. Noget a la:

(v & (0x80000000 >> (nbits-1))) >> (32-nbits)

Vrøvle eksempel.

Vi prøver igen.

(v & (0x80000000 >> (nbits-1))) | vv

arne_v:
(-1 >> 1) -> -1
(-1 / 2) -> 0

db

Det kalder jeg et underflow problem.

Der er imidlertid også andre forskelle på >>1 og /2, men jeg synes
stadigvæk at den opfører sig logisk.

Bjarne Stroustrup skriver:
"When the left operand of the >> operator has a signed type and a negative value, the result of the operation will be implementation dependent"
(The Annotated C++ Reference Manual, 1990)

db

Det samme gælder for C.

Men unsigned int kan også give andre problemer:

for (unsigned int ui = 10; ui >= 0; ui--)
{
  // Endless loop
}

En klassisk fejl :-)

db

Bit fidleri vil næsten altid basere sig på forudsætninger
om størrelsen af int typer i bits og på repræsentationen
af negative tal.  C/C++ standarderne forudsætter ikke two's
complement. Og det gør det meget svært for en standard at beskrive
hvad der sker med shift af negative tal.

Enig !

db

Tid at lukke spørgsmålet ?

Og et svar såfrem nogle af mine kommentarer har været nyttige.

Lukke tid ?