[C++] Pass by reference/pointer/gewoon verschil?

[flowerp]

.oisyn schreef op 18 januari 2004 @ 05:25:
[...]

Ja maar stel je laat de int meegroeien, wat moet dan het 32-bits type worden? Dat kan niet long worden, want die moet minstens zo groot zijn als een int.

Het is nu vaak zo dat:
short int = 16 bits
int = 32 bits
long int = 32 bits

Maar dit is alleen maar een toevalligheid. Er staat nergens dat er perse een 16 bits type nodig is. Waarom het zo gegroeid is dat int en long int in de praktijk hetzelfde zijn weet ik ook niet. In mijn totale naiviteit zou ik zeggen dat je bij mee groeien zou doen:

short int = 32 bits
int = 64 bits
long int = 128 bits

De long int zou dan geen directe hardware support hebben op 64 bits systemen. De 'plain' int geeft door zijn 'plainness' dan aan dat het gaat om het gewone 'systeem' woord. De short is dan iets minder als het systeem woord en de long iets meer (dus potentieel langzamer). Voor het gevoel zou dit meer kloppen. (IMHO)

Als dit echt ongewenst is voor een basic type zou je kunnen zeggen:

short int = 16 bits
int = 32 bits
long int = 64 bits

Dan is je int inderdaad niet meegegroeid (in de praktijk), maar de long wel. In beiden gevallen ben je van die stomme praktijk situatie af dat long en int evengroot zijn. Dat slaat gewoon helemaal nergens op.

En dit zorgt er dan weer voor dat je geen oude code kunt gebruiken, en een naadloze portability tussen 32 en 64 bits staat toch wel hoog op het vaandel.

Maar waarom zijn die types dan niet ooit voor een bepaald aantal bits gespecificeerd, als dus nu blijkt dat dat 'meegroeien' helemaal niet gebeurt en men het blijkbaar altijd zo wil dat de short int 16 bit is en de 'plain' int 32 bit. Dan mogen ze van mij dat "short int <= int <= long int" verhaaltje vandaag nog uit de standaard schrappen, want dat heeft dan geen enkel practisch nut.

---

Offtopic: als je minder dan 2% edit, dan komt het editbericht er niet bij te staan

Aha. Dus toch :-)

[MSalters]

Samengevat: Waarom specificeert de standaard geen bitgroottes, terwijl de verschillende generaties x86 van 16-16-32 via 16-32-32 naar 16-32-32-64 gaan?

Antwoord: Omdat niet alles een x86 is?

Als ik het me goed herinner hebben courante Crays een behoorlijk goede C++ compiler met 43 bits longs, met 21 bits padding. Als ik het me goed herinner was de reden dat die 43 bits dan overeenkwamen met dezelfde 43 bits van een floating point getal met dezelfde waarde, en je kon dus met simpele bitops de long->float cast doen.

[Olaf van der Spek]

x86 is niet het enige platform waar types met een vast aantal bits handig zouden zijn.

[flowerp]

MSalters schreef op 18 januari 2004 @ 14:59:
Samengevat: Waarom specificeert de standaard geen bitgroottes, terwijl de verschillende generaties x86 van 16-16-32 via 16-32-32 naar 16-32-32-64 gaan?

Volgens mij is het meer:

---

Samengevat:

Waarom specificeert de standaard geen bitgroottes, terwijl de verschillende compilers in hun evolutie nu opeens wel aan de huidge, historische groottes -moeten- vasthouden.

---

Standaard C++ zou op ieder systeem moeten compileren. Aangezien de bitgroottes niet vast staan, en bv gray dus ook al iets groter dan 32 bits heeft, snap ik nog steeds niet waarom de bestaande types niet gewoon kunnen doorgroeien, ipv dat er nu nieuwe (C99:long long, MSC++:__int64, enz) types geintroduceerd -moeten- worden.

Als dat alleen is voor compatibiliteit, dan zou standaard C++ code dus niet op de Gray kunnen compileren wegens die 43 bits? Als dat wel kan, waarom zou het dan voor 64 bits niet kunnen? Blijkbaar klopt er iets gewoon niet. C99 doet ook al niet aan doorgroeien (en kwam dus met long long). Als een C++ implementatie in het verleden van 16-16-32 naar 16-32-32 kon gaan, waarom is dan nu opeens een 4de type nodig?


Dit staat overigens los van het feit, waarop Olaf al meerdere malen terecht op hamert, dat een optionele set van types, die wel fixed bit zijn, op elk platform, voor elke compiler handig zouden zijn. Het 'de hele wereld is geen x86' doet niet echt ter zake, omdat bv ook de Apple platformen met de G4->G5 transitie met hetzelfde probleem zitten.

Ik weet niet hoe de Apple compiler (iets aangepaste gcc) dit gaat oplossen, of al heeft opgelost. Mischien wel een __integer_64, of wie weet wat voor leuks, of mischien wel gewoon de standaard int of long int, of alvast de long long...

[MSalters]

C99 heeft fixed-width types.
Overigens is er nog een reden voor long long die ik hier nog niet gezien heb. Die reden is dat C99 types wil definieren met tenminste 16,32 en 64 bits. Dat zijn natuurlijk de types short, long en long long.
int mag om historische redenen niet langer dan long zijn, dus als je 64 bits int's had gewild had je medium int moeten invoeren voor 32 bits, en long moeten optrekken naar 64 bits. long long is wat dat betreft een kleinere wijziging; het is een nieuw type met nieuwe eigenschappen die de bestaande types ongemoeid laat.

[Olaf van der Spek]

Dus toch. En zelfs required in plaats van optional. Maar zal dit ook worden toegevoegd aan de C++ standaard?

C++:

8-bit:  int8_t   uint8_t
16-bit: int16_t  uint16_t
32-bit: int32_t  uint32_t
64-bit: int64_t  uint64_t

[.oisyn]

[nohtml]

flowerp schreef op 18 januari 2004 @ 11:56:
Maar dit is alleen maar een toevalligheid. Er staat nergens dat er perse een 16 bits type nodig is.

weet ik, dat zei ik eerder al met een quote uit de standaard

Waarom het zo gegroeid is dat int en long int in de praktijk hetzelfde zijn weet ik ook niet.

Waarschijnlijk omdat de 16-bits versies een int 16 bits was en een long 32 bits. Short en long zijn hetzelfde gebleven en de int is meegeschaald met het platform (wat je eigenlijk ook zou willen, omdat je als je een int gebruikt dan altijd het native type van je platform aanhoudt, want meestal zijn de berekeningen met dat type het snelst)

In mijn totale naiviteit zou ik zeggen dat je bij mee groeien zou doen:

short int = 32 bits
int = 64 bits
long int = 128 bits

Zoals ik al zei, dan ben je je 16 bits type kwijt

De long int zou dan geen directe hardware support hebben op 64 bits systemen.

waarom niet? De 64 bits int heeft dat op 32 bits systemen meestal ook.

Maar ik zou dan wel voor bovenstaande oplossing gaan, en dan __int16 gebruiken in geval van het 16 bits type, dat dan niet mapt naar een native type.

[MSalters]

OlafvdSpek schreef op 19 januari 2004 @ 09:34:
Dus toch. En zelfs required in plaats van optional. Maar zal dit ook worden toegevoegd aan de C++ standaard?

C++:

8-bit:  int8_t   uint8_t
16-bit: int16_t  uint16_t
32-bit: int32_t  uint32_t
64-bit: int64_t  uint64_t

Misschien, als je een compatibility-header toevoegd, maar er is behoorlijk wat kritiek binnen WG21(C++ commissie) op die types. In het bijzonder worden ze als te onduidelijk beschouwd, met te korte namen. In C++ is het waarschijnlijker dat de types int_fastest<8> of int_precisely<8> etcetera worden genoemd (of een variant daarvan). Voor C99 compatibility mogen int8_t en dergelijke dan typedefs zijn.
Het doel is dat mensen alleen voor zo'n type kiezen als er een goede reden voor is, en dat ze dan ook meteen het type kiezen wat ze bedoelen. Wat we dus niet willen is dat mensen uint32_t kiezen als ze alleen maar een unsigned type van tenminste 32 bits willen.

[farlane]

Voor dedicated spul is het wel handig. Tot nog toe moest je telkens zelf opzoeken welke types een compiler ondersteunde en van daaruit de juiste types definieren.

Dit scheelt weer wat zoekwerk. ( Maar niet echt heel veel )
Groter voordeel is de eenduidige notatie denk ik.

[Verwijderd]

OlafvdSpek schreef op 19 januari 2004 @ 09:34:
Dus toch. En zelfs required in plaats van optional. Maar zal dit ook worden toegevoegd aan de C++ standaard?

Ik had begrepen dat een flink aantal C99 dingen wel toegevoegd gaan worden.
Hopelijk alles of bijna alles zodat het eigenlijk 1 taal blijft met C het procuderele gedeelte en C++ het OO stuk. (hoewel C++ natuurlijk ook veel toevoegingen heeft boven C die helemaal niet OO zijn).

C++:

8-bit:  int8_t   uint8_t
16-bit: int16_t  uint16_t
32-bit: int32_t  uint32_t
64-bit: int64_t  uint64_t

Kewl! Ik moet me toch maar eens wat dieper in C99 gaan verdiepen. Zag bv al wel dat ze hele rare initialisers hadden voor structs. Die lijken me mischien in C++ een beetje overbodig omdat die al constructors heeft.

[Verwijderd]

.oisyn schreef op 19 januari 2004 @ 17:38:
[nohtml]

Waarschijnlijk omdat de 16-bits versies een int 16 bits was en een long 32 bits. Short en long zijn hetzelfde gebleven en de int is meegeschaald met het platform (wat je eigenlijk ook zou willen, omdat je als je een int gebruikt dan altijd het native type van je platform aanhoudt, want meestal zijn de berekeningen met dat type het snelst)

Inderdaad. 100% mee eens. Ik weet niet waar ik het ooit heb gelezen, maar ik had ook altijd geleerd dat in c/c++ een int altijd precies het aantal bits van het native platform type is. Daarom begrijp dus ook ik niet de move van MS en co. om op een 64 bits platform de int 32 bits te maken en een apart type voor 64 bits te introduceren.

Ik denk echt dat op een 64 bits platform de short 32 bits zou moeten zijn, de int 64 en de long 128.

Zoals ik al zei, dan ben je je 16 bits type kwijt

En is dat dan zo erg?

Waar mischien wel wat problemen te verwachten waren en mischien dat dat de reden van MS is om nu aan de grootes vast te houden, is dat in win32 veel van de types WPARAM en LPARAM gebruikt wordt. Ik meen me herinneren dat LPARAM voor sommige functies 2 kleineren types bevatte, dat het een long was met 1 short in de hoge bits en 1 short in de lage. (ben te lui om het op te zoeken, doe binnenkort wel).

Toen op het x86 platform de architectuur naar 32 bits ging en daarmee ook de compiler, maakte MS nogal redelijk grootte veranderingen in de win16 api om er win32 van te maken (win16 was toch niet zo *enorm* in gebruik). Met win32 is dat veel moeilijker, en win64 is dan maar een relatief kleine aanpassing hierop. (de echte nieuwe API is .NET).

[.oisyn]

Verwijderd schreef op 20 januari 2004 @ 00:13:
En is dat dan zo erg?

misschien compatibility met oude code?

Waar mischien wel wat problemen te verwachten waren en mischien dat dat de reden van MS is om nu aan de grootes vast te houden, is dat in win32 veel van de types WPARAM en LPARAM gebruikt wordt. Ik meen me herinneren dat LPARAM voor sommige functies 2 kleineren types bevatte, dat het een long was met 1 short in de hoge bits en 1 short in de lage. (ben te lui om het op te zoeken, doe binnenkort wel).

ja maar die zijn natuurlijk ook makkelijk opnieuw te definieren. Het zijn sowieso custom types, dus een #ifdef _WIN64 eromheen en je kunt ze mappen naar types die wel goed blijven