Vad är det som skapar en "död punkt" i denna loop?

[Icecap]

90kar08: tyvärr inte! Standarden säger att den är minst en byte! En int kan vara större men den är inte definierat till att vara det! I senare versioner (C89+) är en int minst 16 bit.

Standarden säger att det finns 3 typer:
short (int)
int
long (int)

Räknad i antal bytes är förhållandet: short <= int <= long.

En long kan alltså uppta samma antal bytes som en short.

Citat: "On a computer that cannot easily address memory smaller than a word, the implementor might even choose to use a single size for all three sizes."

Ref: "C - A reference manual", ISBN 3-13-109802-2, sid 83.

Att de flesta kompilers sedan försöker hålla int till 16 bit och long till 32 bit är bara en fördel men standarden är inte tvingande! Detta är en av de stora problem med "ursprungs-C" vilket utlöste en del ändringar iom C89 och nyare.

[Nerre]

Det är väl därför som man i de flesta källkoder idag typ-definierar egna typer?

Jag ser i alla fall väldigt ofta idag int_16 och int_32 i källkod (vill minnas att unsigned-versionerna brukar heta uint_16 och uint_32?).


Googlade lite snabbt och det är tydligen stdint.h som innehåller dessa och mitt minne av hur de ser ut var visst inte helt korrekt.
http://en.wikibooks.org/wiki/C_Programm ... e/stdint.h

[Icecap]

Nerre: exakt rätt!

[ie]

@ie:
Tror jag hänger med på vad du menar men börjar bli lite förvirrad nu. Ska jag flytta ner ++ och -- till step i loopen?

Nej, det menade jag inte.

I for-loopen är det ingen skillnad på att skriva ++step eller step++, då den görs som ett "eget steg" i programmet.

Om du istället använder ++ i en tilldelningssats (t ex value = constants[++step] vilket jag inte rekommenderar i detta fall) så har det betydelse.

Om step är 25 och du gör
value = constants[++step]
så kommer step att ökas till 26 och du hämtar constants[26] till value.

Om du istället skriver
value = constants[step++]
så hämtar du constants[25] till value, sen ökar du step till 26.

Alltså, vill du använda värdet av step före eller efter du inkrementerar det?

Denna fråga finns liksom inte i for-loopen, där betyder båda versionerna bara "inkrementera värdet".

[gkar]

Att en 100-pos array inte indexeras 1-100 är dels
ett av de vanligaste nybörjarfelen och samtidigt
en av de mer korkade sakerna med C...

Hur borde det fungera?

[Nerre]

Det mest logiska för en människa är ju att om man har en array så är det första elementet 1, och det andra 2. Då vet jag direkt att 48:e elementet är 48.

Och en array på 100 element är alltså från 1 till 100.

[Magnus_K]

@ie: Nu hänger jag med. I mitt fall så blir det väl lite speciellt eftersom jag går både upp och ner i värdet?
Det känns som att detta påverkar hur jag vill göra "vändningarna" dvs:

1,2,3,...97,98,99,98,97,...3,2,1,2,3 osv...
eller
1,2,3,...97,98,99,99,98,97,...3,2,1,1,2,3 osv...

Eller ja, det är väl egentligen hur man vill ha det men jag tror jag förstår hur det fungerar nu.

Diskussionen om hur elementen i en array indexeras lägger jag mig inte i. Jag är bara glad att jag fått lära mig hur det fungerar i C.

[Icecap]

Nerre: jag håller med om att första element i en samling är #1. Men i datorvärlden är första element #0 för att 0 ju är en siffra som alla andra. Är det viktigt att använda 1 som första element är det bara att byta till Pascal, då kan du få det så.

Jag ser inget problem i att första elementet i en array har index 0, man utgår ju från starten och räknar hur många steg man ska gå in i arrayn och då känns 0 som en helt OK index för att man ändå pekar på det och alltså inte behöver stega i arrayn.

[sodjan]

> Hur borde det fungera?

Självklart är det logiska att numrera elementen 1-100.
Du har väl inget hus med nummer 0 på din gata?

> Men i datorvärlden är första element #0...

Är det? Finns det en naturlag för det?

[gkar]

Det har att göra med att i C har vi egentligen ingen arrayhantering, vi har pekare och offset med "scaled indexing"
Dvs, vi har inget index 0 i egentlig mening, vi har data som ligger direkt på pekaren.
Det är helt logiskt om man ser det på rätt sätt.

Vi borde kanske ändra så att gatunumren börjar på 0!

[sodjan]

Bättre att ha språk som är logiska...
Tekniska saker kan datorerna hålla reda på...

Men du har ju rätt, C var inte avsett för generell
programmering och då blev det som det blev.

[Mr Andersson]

90kar08: tyvärr inte! Standarden säger att den är minst en byte! En int kan vara större men den är inte definierat till att vara det! I senare versioner (C89+) är en int minst 16 bit.

Hur vanligt är det med kompilatorer som är äldre än c89? Jag programmerar nästan bara x86/x64 så jag har inte så stor koll på microprocessor- och stordatorvärlden.

[sodjan]

Före 1989 var det väldigt vanligt.
Och C är ju betydligt äldre än så.

Men i praktiken lär det vara väldigt ovanligt med
en kompilator där char = int storleksmässigt.
Även i 8-bitars system.

[Icecap]

Vad jag vet är gatunumren i USA baserat på ett avståndsmått från vägens "start". Detta skulle vara orsaken till vägnummer av typen 27893 - fast jag förstår att en "standardtomt" är ett visst antal yards så det finns nog något multiple som ska passa.

Och det samma gäller arrays i C: det är inte frågan om vilket element man vill ha, det är fråga om hur långt borta det är från startpunkten när man räknar index.

Så att startelementet ska vara #1 är jag inte överens om. Det motsvarar i grunden till att man ska märka upp 100 steg - men inte räknar med stället man utgår ifrån.

[Gimbal]

Självklart är det logiska att numrera elementen 1-100.

Vad som är logiskt beror på sammanhanget.
I språket C är det logiskt att börja på noll, om man vet varför det börjar på noll.