[C] declaratie int, long (borland compiler)

[Blizard]

Ben sinds kort begonnen met C op school (borland compiler), maar nou moeten we bv een integer declareren als int en niet als long (enkel indien er waarden > 32.. moeten opgeslagen worden). Maar met de huidige processors is het dan niet zo dat de cpu meer moeite heeft met 16bit waardes te converteren naar 32bit, om daar dan met verder te rekenen, om dan tenslotte na de berekeningen terug deze waarde om te zetten naar een 16bit int.

Nu is m'n vraag : alles long declareren ... of toch maar luisteren naar de docenten. En zijn er eventueel websites die hier meer informatie over bieden ?

[curry684]

Je docenten zijn stom, een signed int is op een 16-bit CPU (antiek overigens) echt maximaal 32767. C biedt niet voor niets een long datatype.

[Blizard]

Ik denk dat mijn probleemstelling een beetje verwarrend is.
Ik vroeg me af of het nog nuttig is een variable te declareren als (échte) int ... ?!

[JayTaph]

ja, dat is nuttig om als int te declaren.. ints zijn vrijwel altijd de optimale reken groote voor processoren (meestal de registergrootte), waarbij longs dat vaak niet zijn. Longs zijn per definitie dus NIET geschikt om te gebruiken (tenzij je ze nodig hebt natuurlijk). Je docent heeft dus gelijk..

op 32bits platformen zijn long en int trouwens allebei 32bits (sizeof(long) en sizeof(int) zijn beide 4), maar dit hoeft dus niet..

Het enige wat je zeker weet, is dat byte <= int <= long <= long long

wat de groottes precies zijn, is weer dus platform afhankelijk.

[Verwijderd]

JayTaph schreef op 01 december 2002 @ 17:33:
ja, dat is nuttig om als int te declaren.. ints zijn vrijwel altijd de optimale reken groote voor processoren (meestal de registergrootte), waarbij longs dat vaak niet zijn. Longs zijn per definitie dus NIET geschikt om te gebruiken (tenzij je ze nodig hebt natuurlijk). Je docent heeft dus gelijk..

Dit is onzin, volgens mij. Op 64bit platformen onder linux met gcc als compiler is een int 32bit en een long 64bit. Waarom? Omdat dat zo afgesproken is. Dat heeft niks met systemen, platformen te maken of wat dan ook, het is puur en alleen conventie per platform/architectuur, per OS of per compiler.

Over het algemeen gebruik je een int als standaard rekenwaarde, maar daar is verder geen reden voor, behalve historisch besef, heb ik het idee.

Het enige wat je zeker weet, is dat byte <= int <= long <= long long

En short staat tussen byte en int in. .

[curry684]

JayTaph schreef op 01 December 2002 @ 17:33:
ja, dat is nuttig om als int te declaren.. ints zijn vrijwel altijd de optimale reken groote voor processoren (meestal de registergrootte), waarbij longs dat vaak niet zijn. Longs zijn per definitie dus NIET geschikt om te gebruiken (tenzij je ze nodig hebt natuurlijk). Je docent heeft dus gelijk..

Erm u zwamt, Blizard heeft het over waarden groter dan 32..., ik neem aan dat ie daarmee 32768 bedoelt. Daarbij heb je hoe dan ook een long nodig, en heb je dus een enorme bug als je op een 16-bit platform een int gebruikt.

Het klopt dat een int de optimale rekeneenheid is, maar dat boeit alleen voor for-loopjes e.d. Juist als je met grote(re) getallen gaat rekenen moet je er goed rekening mee houden of de getallen waarmee je omgaat wel zullen passen, en/of goede portable bounds checking invoeren.

edit:

Stukje geschrapt nadat de eerste 5 stukken documentatie die ik vond mekaar onderling allemaal tegenspraken.

[ Voor 18% gewijzigd door curry684 op 01-12-2002 18:02 ]

[Verwijderd]

type grootte waarde bereik
---- ------- -------------
int 2 -32.768 tot 32.768
u int 2 0 tot 32.768
short int 2 -32.768 tot 32.767
long 4 van -2 147 483 648 tot 2 147 483 647
etc.

[Blizard]

Hmz, nog niet echt een oplossing voor m'n probleem.

Ik weet dat een normale 16 bit int kleiner is dan een long (32 bit). Maar visual C gebruikt bv voor een int ook 32 bit, omdat de processors van vandaag dit gewoon aangenamer vinden om met te rekenen. Je kan deze dan wel signed en unsigned gaan gebruiken.

Maar de processor heeft meer tijd nodig om een 16bit int om te zetten naar zijn 32 bit systeem dan dat hij moeite heeft met een 32bit long .. of niet ?

[CyBeR]

Verwijderd schreef op 01 december 2002 @ 18:06:
type grootte waarde bereik
---- ------- -------------
int 2 -32.768 tot 32.768
u int 2 0 tot 32.768
short int 2 -32.768 tot 32.767
long 4 van -2 147 483 648 tot 2 147 483 647
etc.

int en unsigned int past niet evenveel in hoor

[MisterData]

Verwijderd schreef op 01 december 2002 @ 18:06:
type grootte waarde bereik
---- ------- -------------
int 2 -32.768 tot 32.768
u int 2 0 tot 32.768
short int 2 -32.768 tot 32.767
long 4 van -2 147 483 648 tot 2 147 483 647
etc.

* MisterData RML-tovenaar:

Type	Grootte	Waarde Bereik
int	2	-32.768 tot 32.768
unsigned int	2	0 tot 65.536
short int	2	-32.768 tot 32.767
long	4	van -2 147 483 648 tot 2 147 483 647

CyBeR schreef op 01 december 2002 @ 18:26:
[...]


int en unsigned int past niet evenveel in hoor

Veranderd in bovenstaand schema

[ Voor 19% gewijzigd door MisterData op 01-12-2002 18:58 ]

[JayTaph]

Verwijderd schreef op 01 december 2002 @ 17:44:
Omdat dat zo afgesproken is. Dat heeft niks met systemen, platformen te maken of wat dan ook, het is puur en alleen conventie per platform/architectuur, per OS of per compiler.

Over het algemeen gebruik je een int als standaard rekenwaarde, maar daar is verder geen reden voor, behalve historisch besef, heb ik het idee.

quoting K&R: "int will normally reflect the most 'natural' size for a
particular machine"

Een integer is dus per definitie de standaard rekenwaarde waarop alles geoptimaliseerd is, en vaak is dat de registergrootte. Ik zeg dus, per defintie, een 8bit register systeem, kun je weinig doen met -127..128 bits integers. Op deze architecturen zijn de integers veelal 16 bits.

Aangezien er vele compilers, op nog meer platformen op nog meer architecturen zijn, zijn er altijd uitzonderingen. Het type-probleem is nooit echt gedefineerd, en daarom is het ieder voor zich.

Waarom dat gcc dan 32bits integers gebruikt weet ik niet, maar daarvoor zal wel een goede reden zijn (op alpha zijn ze in ieder geval wel 64bits, en is sizeof(int) == sizeof (long)).

En short staat tussen byte en int in. .

Dat rijtje klopte inderdaad niet helemaal.. foutje van mij

char <= short <= int <= long ( <= long long )

Waarbij een aantal dingen verplicht zijn, zoals een long die minimaal 32bits dient te zijn.

Erm u zwamt, Blizard heeft het over waarden groter dan 32..., ik neem aan dat ie daarmee 32768 bedoelt. Daarbij heb je hoe dan ook een long nodig, en heb je dus een enorme bug als je op een 16-bit platform een int gebruikt.

Huh? Dat was toch helemaal de vraag niet? De vraag was of het verstandig is om longs (32bits variabelen eigenlijk) te gebruiken op een 32bit systeem terwijl de compiler een 16bit compiler is. Mijn antwoord is nee, omdat je toch met een 16bit instructieset werkt en dat de normale int (16bit) hiervoor de optimale grootte is.

Juist als je met grote(re) getallen gaat rekenen moet je er goed rekening mee houden of de getallen waarmee je omgaat wel zullen passen, en/of goede portable bounds checking invoeren.

Dat is logisch.. Precies om die reden wordt er gekeken tijdens een ./configure wat de groottes zijn van de 4 basis-eenheden.

Ik weet dat een normale 16 bit int kleiner is dan een long (32 bit). Maar visual C gebruikt bv voor een int ook 32 bit, omdat de processors van vandaag dit gewoon aangenamer vinden om met te rekenen. Je kan deze dan wel signed en unsigned gaan gebruiken.

Maar de processor heeft meer tijd nodig om een 16bit int om te zetten naar zijn 32 bit systeem dan dat hij moeite heeft met een 32bit long .. of niet ?

16bits waardes in een 32bits register stoppen gaat redelijk snel, hiervoor bestaan vaste processor-instructies die dit snel kunnen regelen. Dit is op zich het probleem dus niet. Andersom (32bits getallen op 16bits systemen) brengt het wel erg veel overhead met zich mee.

Maar met de huidige processors is het dan niet zo dat de cpu meer moeite heeft met 16bit waardes te converteren naar 32bit, om daar dan met verder te rekenen, om dan tenslotte na de berekeningen terug deze waarde om te zetten naar een 16bit int.

Nu is m'n vraag : alles long declareren ... of toch maar luisteren naar de docenten. En zijn er eventueel websites die hier meer informatie over bieden ?

Eventjes terugkomend op je eerste posting:

Als jij al je variabelen als long zou defineren, dan zou de compiler hiervoor allemaal extra slagen moeten maken om die 32bits variabelen in de 16bits registers te proppen. Dat je huidige processor 32bits getallen aankan, is leuk, maar daarvan maak je dus absoluut geen gebruik, en de processor kan ook niet zien dat jij dat eigenlijk wel wilt (die voert ten slot van rekening alleen maar uit wat em is opgedragen).

Als je dus wilt dat je echt van je 32bits registers en rekencapatiteit gebruikt maakt, moet je dus een 32bit compiler hebben die je code omzet in 32bits instructies.

[JayTaph]

MisterData schreef op 01 december 2002 @ 18:56:
[...]

En leuk lijstje waar je alleen niet zo veel mee kunt...

code:

int main (void) {
  printf ("%d - %d - %d\n", sizeof(int), sizeof (long), sizeof (long long));
}

geeft 4 - 4 - 8, waardoor ik wel veel meer kan opslaan in een int of signed int


Zoals ik dus al aangaf, er zijn geen vaste waardes voor short, int, long (en long long, maar die is niet officieel opgenomen in de standaarden).

[TheOneLLama]

Als je wilt gebruiken wat het snelste is moet je meestal int hebben. Of dat 8/16/32/64 bit is hangt geheel van je compiler af. Compileerd die Borland compiler overigens niet naar 16bit code?

Het char <= short <= int <= long ( <= long long ) klopt in theorie ook niet. Ik mag ook een compiler maken waar char groter is als bv short. (denk aan bv Unicode)

[curry684]

Nee een char is per definitie het kleinst adresseerbare stukje geheugen. Bij Unicode wordt gebruik gemaakt van het type 'wchar_t', wat een compiler-alias is voor unsigned short.

[.oisyn]

JayTaph schreef op 01 december 2002 @ 19:11:
16bits waardes in een 32bits register stoppen gaat redelijk snel, hiervoor bestaan vaste processor-instructies die dit snel kunnen regelen. Dit is op zich het probleem dus niet. Andersom (32bits getallen op 16bits systemen) brengt het wel erg veel overhead met zich mee.

als je een 32 bits waarde in een 32 bits register wilt stoppen op een 80386+ cpu die in 16 bits realmode/virtual x86 mode draait dan neemt dat net zoveel overhead mee als dat je een 16 bits waarde in een 32 bits register wilt stoppen in gewoon 32 bits mode

Waarom? omdat je een extra byte nodig hebt voor de opcode, namelijk 66h, die de daaropvolgende instructie omzet van 16 -> 32 bits of 32 -> 16 bits, afhankelijk van de huidige modus

MisterData schreef op 01 december 2002 @ 18:56:

* MisterData RML-tovenaar:

Type	Grootte	Waarde Bereik
int	2	-32.768 tot 32.767 32.768
unsigned int	2	0 tot 65.536
short int	2	-32.768 tot 32.767 32.768
long	4	van -2.147.483.648 tot 2.147.483.647 2.147.483.648

note: tot != tot en met

[ Voor 31% gewijzigd door .oisyn op 01-12-2002 20:22 ]

[JayTaph]

.oisyn schreef op 01 december 2002 @ 20:16:

als je een 32 bits waarde in een 32 bits register wilt stoppen op een 80386+ cpu die in 16 bits realmode/virtual x86 mode draait dan neemt dat net zoveel overhead mee als dat je een 16 bits waarde in een 32 bits register wilt stoppen in gewoon 32 bits mode

Waarom? omdat je een extra byte nodig hebt voor de opcode, namelijk 66h, die de daaropvolgende instructie omzet van 16 -> 32 bits of 32 -> 16 bits, afhankelijk van de huidige modus

Ik doelde meer op de overhead die je hebt om 32bits getallen te bewerken met 16bits registers. Verder moet je je post eventjes verduidelijken, want volgens mij ben je een paar dingen door elkaar aan het halen..

note: tot != tot en met

Maak er dan tot en met van, anders worden de 1-complement freaks helemaal gek van deze tabel

[.oisyn]

JayTaph schreef op 01 December 2002 @ 21:21:
[...]

Ik doelde meer op de overhead die je hebt om 32bits getallen te bewerken met 16bits registers.

ah op die fiets
tja, veel 16 bits compilers maken toch gebruik van 32 bits registers als ze met longs werken, dus ik denk niet dat dat helemaal opgaat

Verder moet je je post eventjes verduidelijken, want volgens mij ben je een paar dingen door elkaar aan het halen..

nee hoor, ik heb m nog een keer nagelezen, en hij klopt helemaal

Maak er dan tot en met van, anders worden de 1-complement freaks helemaal gek van deze tabel

zat ik ook aan te denken, maar dan moest ik meer editten

[MSalters]

curry684 schreef op 01 december 2002 @ 20:06:
Nee een char is per definitie het kleinst adresseerbare stukje geheugen. Bij Unicode wordt gebruik gemaakt van het type 'wchar_t', wat een compiler-alias is voor unsigned short.

Nee, dat is een VC6 bug. wchar_t is een echt type, met aparte overloads en zo.

[curry684]

MSalters schreef op 01 December 2002 @ 23:18:
Nee, dat is een VC6 bug. wchar_t is een echt type, met aparte overloads en zo.

Excusez-moi, u heeft volkomen gelijk. Ik ben na enkele jaren Unicode development met VC6 iets te hard gewend dat de volgende nutteloze voorbeeldcode:

C++:

void Test(char* p_Test)
{
wchar_t         l_Fiets[] = L"Fiets";

Test(l_Fiets);
}

Als error het volgende geeft:

code:

'Test' : cannot convert parameter 1 from 'unsigned short [6]' to 'char *'

Ik probeer het net uit in VC.net en die vermeld wel netjes dat ie 'wchar_t [6]' niet kan converteren

[Blizard]

Laat ons er wel van uitgaan dat we enkel werken op een 32bit processor. Geen 16bit meer. En we slaan een waarde op in een 16bit int van borland.
Dus als ik het goed begrijp heeft de computer evenveel werk met een 32bit long dan met een 16 bit int ... ?

[JayTaph]

.oisyn schreef op 01 December 2002 @ 21:28:
[nohtml]

nee hoor, ik heb m nog een keer nagelezen, en hij klopt helemaal

Jah, idd... hij klopt,.. na een kop koffie zie je alles veel helderder

[Verwijderd]

Of een int 16 of 32 bit of 24bit of wat dan is, hangt totaal af van je compiler en je compiler-settings, maar d'r moet inderdaad altijd gelden dat

sizeof(short) <= sizeof(int) <= sizeof(long)
Dus:

Type	Grootte	Waardebereik
short	2	van - (1 << 15) t/m (1 << 15) -1
int	2 - 4	(maximaal) van - (1 << 31) t/m (1 << 31) - 1
long	4	van - (1 << 31) t/m (1 << 31) - 1

en dus mag een int zowel 16 als 32 bit zijn, maar ook gerust 24 bit(!) voor een x86 platform. Een andere waarde dan 16 en 32 is door de architectuur van de x86 wat onhandig, maar in principe mag een int ook 17 of 30 bit zijn o.i.d.!
Regelmatig bepalen compilers zelf vanuit de code wat het handigst is in een bepaalde situatie en is niet zonder meer een regel te stellen. Wel wordt een int standaard altijd geschaald naar 32 bit alvorens deze als argument voor een functie wordt meegegeven, of als return-waarde wordt teruggegeven.

Bewijs in gcc:

C:

int i = 0x12345678;

[Verwijderd]

MSalters schreef op 01 December 2002 @ 23:18:
Nee, dat is een VC6 bug. wchar_t is een echt type, met aparte overloads en zo.

In C (waar je niets te maken hebt met overloads ) is een wide char gedefineerd als een type die "minstens groot genoeg moet zijn om een unicode char in op te slaan". in gcc onder x86 geldt dat:

sizeof(wchar_t) == 4 (typedef van unsigned long)

(Wel even <stddef.h> include-en in je sourcefile)

[ Voor 17% gewijzigd door Verwijderd op 02-12-2002 10:41 ]

[Soultaker]

Mijn bijdrage aan de discussie: lang leve GLib en gint16, guint16, gint32, etcetera!

Verder heb ik met mezelf afgesproken gewoon int's te gebruiken wanneer ik 32-bits precisie nodig heb. Dan maar geen compatibility met DOS en 16-bits platforms; het scheelt een hoop loos typewerk, terwijl meestal op voorhand wel duidelijk is dat je nooit naar een 16-bit platform wil porten. Wanneer je de Windows API gebruikt, bijvoorbeeld.