int und nicht integer
-
Warum heißt es eigentlich int und nicht integer?
-
Weil "int" kürzer ist und "integer" nicht mehr Information beinhalten würde.
-
Kommt wohl aus den guten alten Zeiten, wo Speicher für Text noch teuer war.
Warum C++ das so hat ist ganz einfach wegen der Kompatibilität zu C. Und warum das C so hat weiss vielleicht volkard.
-
drakon schrieb:
Warum C++ das so hat ist ganz einfach wegen der Kompatibilität zu C.
Das liest sich so, als ob ein unabhängiges C++ es anders machen würde. Glaube ich bei "bool" statt "boolean" aber weniger.
-
Nexus schrieb:
drakon schrieb:
Warum C++ das so hat ist ganz einfach wegen der Kompatibilität zu C.
Das liest sich so, als ob ein unabhängiges C++ es anders machen würde. Glaube ich bei "bool" statt "boolean" aber weniger.
Wahrscheinlich, aber das war nicht die Frage.
Dann wäre die Antwort wohl gewesen: Ist so, weil war in C auch so.
Wenn wir z.B C# anschauen, dann haben die da wahrscheinlich wirklich einfach aus Gewohnheit (also Gewohnheit der Programmierer) das so gelassen, wie es in C üblich ist. Allerdings bietet Eiffel da einen Gegenpart, wo es halt anders gemacht wurde.
-
Die Frage ist warum heisst es nicht int8, int16, int32...
-
Es hat auch einen Vorteil, wenn Sachen die man öfters braucht, leicht und schnell zu schreiben sind. Das ist etwas, was ich an der C-Syntax sehr schätze. Man vergleiche zum Beispiel mal mit Pascal, was auch eine ganz hübsche Sprache wäre, wenn man nur nicht so viel tippen müsste.
-
Tim schrieb:
Die Frage ist warum heisst es nicht int8, int16, int32...
Weil es durchaus Sinn macht einen Typ zu haben, der genau so groß ist wie die Wortbreite des Prozessors. Auch wenn mir jetzt jeder sagen wird, dass das der ISO Standard nicht vorschreibt, implementieren die meisten Compiler es aber eben so.
Außerdem haben wir ja mit char, char16_t und char32_t für Zeichen bald entsperchende Keywords.
-
Ich fände es viel besser, wenn man char(256) oder char(32) (in Bytes) schreiben könnte, dann könnte man sich nämlich viele Bignum-Klassen sparen...
-
Die Sprache bietet dir aber problemlos die Möglichkeit, deine eigene bigint<n>-Klasse zu schreiben. Warum sollte man das in den Sprachkern integrieren? Die Implementierung dahinter sähe dann auch nicht anders aus.
-
ipsec schrieb:
Die Sprache bietet dir aber problemlos die Möglichkeit, deine eigene bigint<n>-Klasse zu schreiben.
Schieß los!
-
Michael E. schrieb:
ipsec schrieb:
Die Sprache bietet dir aber problemlos die Möglichkeit, deine eigene bigint<n>-Klasse zu schreiben.
Schieß los!
Wahrscheinlich sowas Ähnliches wie
std::bitset<N>, nur mit arithmetischen statt bitweisen Operationen. Gibts bestimmt schon irgendwo. Für bestimmte Grössen wie 32 Bit könnte man Template-Spezialisierungen anlegen und eingebaute Typen für bessere Performance verwenden.
-
drakon schrieb:
Wenn wir z.B C# anschauen, dann haben die da wahrscheinlich wirklich einfach aus Gewohnheit (also Gewohnheit der Programmierer) das so gelassen, wie es in C üblich ist.
Tim schrieb:
Die Frage ist warum heisst es nicht int8, int16, int32...
Bei C# ist es wohl wirklich aus gewohnheit der Programmierer so gemacht, da
intsogesehen nur ein alias ist fürInt32.Int32ist eine Struktur a lápublic struct Int32 : ... { }Daher ist
int i = 5;
das gleiche wie
Int32 i = 5;
und Sachen wie int.MaxValue sind möglich.Aber,
drakon schrieb:
Kommt wohl aus den guten alten Zeiten, wo Speicher für Text noch teuer war.
der Gedanke gefällt mir
-
FreakY<3Cpp schrieb:
Bei C# ist es wohl wirklich aus gewohnheit der Programmierer so gemacht, da
intsogesehen nur ein alias ist fürInt32.Beschäftige dich mal mit Boxing.
-
Was hat das mit Boxing zu tun?
-
FreakY<3Cpp schrieb:
Was hat das mit Boxing zu tun?
Er verwechselt es mit Java.
-
Jo.
-
Tim schrieb:
Die Frage ist warum heisst es nicht int8, int16, int32...
Im alten FORTRAN gab es das:
INTEGER2 (2 byte)
INTEGER4 (4 byte = Standard)
INTEGER8 (8 byte)
Aber, viele Compiler kannten nur INTEGER2 und INTEGERWarum nun int und nicht integer? Antwort: ist einfach kürzer!
Ist so ähnlich wie CD statt Compact Disk, TV statt Televisio, oder Auto statt Automobil.
-
Das mit dem Speicherplatz dürfte gar nicht so weit hergeholt sein. Generell war man zu dieser Zeit um Kürze bemüht - es passten ja nur 80 Zeichen auf eine Lochkarte.
Allerdings konnte das int-Schlüsselwort anfänglich meistens eh ausgelassen werden; das waren die Programmierer ja auch von B so gewohnt. Wahrscheinlich hat auch die geistige Nähe zu B beigetragen - Variablen wurden dort typneutral entweder als "auto" oder "extrn" (kein Tippfehler. Die Schlüsselwörter beziehen sich auf den Geltungsbereich der Variablen) deklariert, daneben jetzt für Typen etwa integer, floatingpoint, character, boolean etc. einzuführen, hätte sich wohl merkwürdig angefühlt.
Dass man nicht mit int32 etc. anfing, liegt einfach daran, dass es zur damaligen Zeit überhaupt keinen Sinn gemacht hätte, sich derart festzulegen. Was sollte das auf einer PDP-10 mit 36-bit-Worten?
-
seldon schrieb:
... es passten ja nur 80 Zeichen auf eine Lochkarte.
... Allerdings konnte das int-Schlüsselwort anfänglich meistens eh ausgelassen werden...
... das waren die Programmierer ja auch von B so gewohnt. ...Erscheint mir alles etwas fragwürdig!
- auf Lochkarten konnte man jeden Code unterbringen, auch mehr als 80 Zeichen pro Anweisung
- die Festlegung auf Typen gab es immer, teilweise implizit (i...n) = integer, Rest = float
- wer hat schon mit B programmiert?Die Pflicht, Typen festzulegen zu müssen, war ein kleiner aber sehr hilfreicher Fortschritt der Programmierung. Und da ist es egal, ob int oder integer. :p
