[c] sizeof(int64) == 8

[Verwijderd]

Ik ben aan het proberen om een programma te maken dat een 64 bit integer gebruikt als 64 booleans, ik wil het zo net mogelijk programmeren om het portable te houden. Als ik een sizeof(unsigned long long) doe dan returned de compiler 8, ik begrijp dat de compiler dit doet omdat hij het wilt allignen op 4 bytes. Is er een operator/functie in C die mij returned hoeveel bytes een type echt groot is? Ik hou er namelijk niet van om 2^5 en 5 in mijn programma te hard coden inverband met portability.

[DuDePrOdUcTiOnS]

Een unsigned long long is toch ook daadwerkelijk 8 Bytes groot? Of begrijp ik je vraag verkeerd?

[Sebazzz]

Dit verschilt dus per platform, en daarom geeft sizeof 8 voor een long.
Het klopt trouwens gewoon hoor
byte -> 8 bits
short -> 2 bytes -> 16 bits
int -> 4 bytes -> 32 bits
long -> 8 bytes -> 64 bits

Correct me if i'm wrong, uiteraard, mijn C kennis is een beetje vastgeroest

Met 2^8 reken je alleen uit hoeveel verschillende waardes een getal kan hebben.

[ Voor 12% gewijzigd door Sebazzz op 07-09-2009 22:06 ]

[Verwijderd]

Volgens mij is daarvoor toch zo'n compiler ding iets als: #MAXINT# ?

Zie hier: http://msdn.microsoft.com/en-us/library/296az74e(VS.80).aspx

Als is dit ook niet echt wat ik bedoelde, er is volgens mij een compiler specific dingetje voor

[ Voor 61% gewijzigd door Verwijderd op 07-09-2009 22:08 . Reden: Linkje met info ]

[Verwijderd]

Ja je hebt gelijk, het is al laat en ik heb me verteld (ik zat te denken 2^5=64 maar uiteraard is de berekening 8*8=64)
Mijn excuses

[!null]

Als je expliciet een long gebruikt dan zou die toch overal 64 bits moeten zijn, platform onafhankelijk.

[Verwijderd]

In de C specs is volgens mij nergens gegarandeerd dat sizeof(unsigned long long) == 8 maar correct me, if i'm wrong.

@PaddoSwam: ja limits.h is precies wat ik bedoel, bedankt

[ Voor 21% gewijzigd door Verwijderd op 07-09-2009 22:12 ]

[Icelus]

Verwijderd schreef op maandag 07 september 2009 @ 22:09:
In de C specs is volgens mij nergens gegarandeerd dat sizeof(unsigned long long) == 8 maar correct me, if i'm wrong.

@PaddoSwam: ja limits.h is precies wat ik bedoel, bedankt

Een long long is minimaal 8-bytes breed.

[Verwijderd]

Icelus schreef op maandag 07 september 2009 @ 22:13:
[...]
Een long long is minimaal 8-bytes breed.

Maar kan toch groter zijn dan 8 bytes? Al zullen er in de praktijk geen voorbeelden zijn lijkt het mij toch beter om geen aanames te maken over de grote van types en gewoon de constantes in limit.h hiervoor te gebruiken

[CyBeR]

!null schreef op maandag 07 september 2009 @ 22:06:
Als je expliciet een long gebruikt dan zou die toch overal 64 bits moeten zijn, platform onafhankelijk.

Niet bepaald, da's platformafhankelijk. Daarom hebben de meeste platforms tegenwoordig ook de meer explicietere uint64_t.

[!null]

Sorry, je wil inderdaad expliciet een (eventueel unsigned) 64 bit hebben, dan zit je altijd goed.

[Soultaker]

CyBeR schreef op maandag 07 september 2009 @ 22:17:
Niet bepaald, da's platformafhankelijk. Daarom hebben de meeste platforms tegenwoordig ook de meer explicietere uint64_t.

De meeste misschien wel, maar Microsoft's compiler doet er niet aan.

In de praktijk kun je dus beter gewoon zelf long long typedefen; dat is een 64-bit integer op praktisch alle platforms die dat type ondersteunen.

[.oisyn]

CyBeR schreef op maandag 07 september 2009 @ 22:17:
Daarom hebben de meeste platforms tegenwoordig ook de meer explicietere uint64_t.

De (u)intN_t types zijn standaard C99, maar optioneel. Een platform dat geen 64 bits int kent, maar bijv. wel een grotere int, zal geen (u)int64_t definieren. Het is daarom handiger om uint_least64_t te gebruiken, die per definitie gedefinieerd moet worden door een compliant C99 implementatie. Die kan evt. groter zijn dan 64 bits, maar je bent er in ieder geval zeker van dat er 64 bits in passen

Soultaker schreef op maandag 07 september 2009 @ 22:27:
[...]

De meeste misschien wel, maar Microsoft's compiler doet er niet aan.

Da's op zich niet zo'n big deal. Hier staat een portable versie (BSD license), en hier staat een MSVC++ versie (custom OS license). C++ coders zouden mijn (enigszins, wegens 'long long') portable template oplossing kunnen gebruiken , maar goed, die hebben voor deze specifieke usecase natuurlijk ook gewoon de beschikking over een std::bitset<64>

[ Voor 35% gewijzigd door .oisyn op 07-09-2009 22:51 ]

[Soultaker]

Ja lekker, een header file van 800 regels toevoegen omdat Microsoft <stdint.h> mist. Dan doe ik liever typeof long long mijn_type; wat ook op alle denkbare platforms die 64-bit integers supporten werkt, en wat in C99 en C++0x toch ook als integer van minstens 8 bytes gedefinieerd wordt, wat feitelijk op een soort int_least64_t neerkomt (maar niet precies, want in theorie zou er een kleiner type dan long long kunnen zijn dat minstens 64 bits heeft).

[.oisyn]

Soultaker schreef op maandag 07 september 2009 @ 22:55:
Ja lekker, een header file van 800 regels toevoegen omdat Microsoft <stdint.h> mist

Exact om die reden. Je voegt een standaard header toe omdat hij mist. Ik zie het punt niet helemaal?

Kijk, je hebt natuurlijk gelijk dat het wellicht wat overkill is voor dit specifieke probleem, maar ik zie het meer als iets wat je standaard sowieso al installeert, net als boost bijvoorbeeld.

[Soultaker]

Mja, zit wat in. Op source file niveau is het inderdaad mooier omdat je onconditioneel #include <stdint.h> kunt doen en dan werkt het, ongeacht waar die definities vandaan komen. Op projectniveau veroorzaakt het meer clutter omdat je dus een relatief groot bestand toevoegt waarvan je 99% niet eens gebruikt.

[ Voor 10% gewijzigd door Soultaker op 07-09-2009 23:29 ]

[Olaf van der Spek]

Soultaker schreef op maandag 07 september 2009 @ 22:27:
In de praktijk kun je dus beter gewoon zelf long long typedefen; dat is een 64-bit integer op praktisch alle platforms die dat type ondersteunen.

boost/cstdint.hpp?

Soultaker schreef op maandag 07 september 2009 @ 23:28:
Op projectniveau veroorzaakt het meer clutter omdat je dus een relatief groot bestand toevoegt waarvan je 99% niet eens gebruikt.

Bang dat de schijf volraakt?
Grootte van zo'n bestand is toch nauwelijks relevant?

[ Voor 37% gewijzigd door Olaf van der Spek op 10-09-2009 20:23 ]

[Soultaker]

Als mijn schijf volstaat met code heb ik anders een groot probleem, want dan kan ik echt níets meer vinden. Het gaat me dus niet om fysieke ruimte, maar om het overzichtelijk en herbruikbaar houden van zo'n project en dat doe je niet door voor elke scheet een 3rd party library als dependency toe te voegen.

En nee, ik ga niet Boost als dependency toevoegen als alternatief voor zoiets simpels als typedef long long x;

[EMP]

En wat is er mis met 8 chars (oftewel 8*8 bits unsigned) te gebuiken? Veel compatibeler kun je het niet krijgen...

Uberhaupt vraag ik mij af waar je 64 booleans voor gebruikt...?

[Soultaker]

Vakjes op een schaakbord ofzo?

Ik kan me wel voorstellen dat er situaties zijn waarin je een constant aantal bools tussen 33 en 64 nodig hebt en dan is het makkelijker ze in één 64-bits integer te packen dan in een struct met een array van chars.

Als je bovendien nog bitoperaties op de hele vector wil doen (and, or, xor) dan is het ook zinnig om zo veel mogelijk bits in één machine word te proppen. (Op een 32-bits architectuur heeft een 64-bits integer dan weinig zin, maar als je toch meer dan 32-bits nodig hebt kan het weinig kwaad, want dan worden 64-bits operaties min of meer op dezelfde manier geëmuleerd als je zelf zou doen.)

[ Voor 3% gewijzigd door Soultaker op 10-09-2009 22:25 ]

[Verwijderd]

Waarom zou je niet direct het aantal bytes kunnen meegeven omdat je toch weet dat je per byte gaat werken. Dus geen sizeof(unsigned long long) maar gewoon 8?

[ Voor 0% gewijzigd door Verwijderd op 11-09-2009 09:51 . Reden: bytes != bits ]

[.oisyn]

Soultaker schreef op donderdag 10 september 2009 @ 22:24:
Ik kan me wel voorstellen dat er situaties zijn waarin je een constant aantal bools tussen 33 en 64 nodig hebt en dan is het makkelijker ze in één 64-bits integer te packen dan in een struct met een array van chars.

Als je bovendien nog bitoperaties op de hele vector wil doen (and, or, xor) dan is het ook zinnig om zo veel mogelijk bits in één machine word te proppen. (Op een 32-bits architectuur heeft een 64-bits integer dan weinig zin, maar als je toch meer dan 32-bits nodig hebt kan het weinig kwaad, want dan worden 64-bits operaties min of meer op dezelfde manier geëmuleerd als je zelf zou doen.)

Nogmaals, std::bitset<64>
.edit: oh wacht, dit was een C topic. Nou ja, mensen moeten ook gewoon geen C willen coden

[ Voor 5% gewijzigd door .oisyn op 11-09-2009 10:58 ]

[Matis]

.oisyn schreef op vrijdag 11 september 2009 @ 10:56:
Nogmaals, std::bitset<64>
.edit: oh wacht, dit was een C topic. Nou ja, mensen moeten ook gewoon geen C willen coden

Bitsets Wij werken met 64bits hashes. Daarin zijn bitsets enorm handig. Feitelijk zijn het 64booleans achter elkaar, maar op deze manier veel makkelijker te implementeren en er logisch mee te kunnen rekenen.

[Olaf van der Spek]

Soultaker schreef op donderdag 10 september 2009 @ 21:51:
maar om het overzichtelijk en herbruikbaar houden van zo'n project en dat doe je niet door voor elke scheet een 3rd party library als dependency toe te voegen.

Waarom eigenlijk niet? Omdat onder Windows (geen package management) het installeren van die dependencies zo irritant is?