int und nicht integer

drakon

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...

SeppJ

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.

FrEEzE2046

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.

wxSkip

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...

ipsec

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.

Michael E.

ipsec schrieb:

Die Sprache bietet dir aber problemlos die Möglichkeit, deine eigene bigint<n>-Klasse zu schreiben.

Schieß los!

Nexus

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.

freaky

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 int sogesehen nur ein alias ist für Int32 . Int32 ist 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

Michael E.

FreakY<3Cpp schrieb:

Bei C# ist es wohl wirklich aus gewohnheit der Programmierer so gemacht, da int sogesehen nur ein alias ist für Int32 .

Beschäftige dich mal mit Boxing.

freaky

Was hat das mit Boxing zu tun?

Zeus

FreakY<3Cpp schrieb:

Was hat das mit Boxing zu tun?

Er verwechselt es mit Java.

Michael E.

Jo.

berniebutt

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 INTEGER

Warum 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?

berniebutt

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

darkfate

Inti schrieb:

Warum heißt es eigentlich int und nicht integer?

Wenn du schon so argumentierst dann verwende ebenfalls keine "Ein-Wort-Abkürzung". Dann sollte es doch etwas wie:

signed integer value MyValue = 1;
//oder noch genauer
signed without decimal position after point MyValue = 1;

.. um die values ganz klar von structs/classes/templates abzugrenzen.

Deswegen sind wir glücklich das es so kurz und knapp geht.

berniebutt schrieb:

- auf Lochkarten konnte man jeden Code unterbringen, auch mehr als 80 Zeichen pro Anweisung

Aber man hätte halt dementsprechend mehr Lochkarten gebraucht. Lochkarten wachsen ja nicht auf...naja, indirekt schon, aber du weißt, was ich meine.

berniebutt schrieb:

- die Festlegung auf Typen gab es immer, teilweise implizit (i...n) = integer, Rest = float

Das ist jetzt FORTRAN-spezifisch. In B und allem, was davor lag (also der Sprachreihe, aus der C hervorging und um die es hier geht), gab es keine Festlegung auf Typen. Es gab nur das Maschinenwort, und das konnte man halt benutzen, wie man gerade wollte.

berniebutt schrieb:

- wer hat schon mit B programmiert?

Dennis Ritchie, beispielsweise. Du weißt schon, der, der nachher C daraus entwickelte. Und Ken Thompson, der UNIX darin schrieb. Natürlich sind C und UNIX nur Fußnoten in der Geschichte der Informationstechnik.

berniebutt schrieb:

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

Das ist sicher richtig, auch wenn es anfänglich eher als Notlösung empfunden wurde. Die PDP-11 brachte Neuerungen, die sich in B nicht mehr vernünftig behandeln ließen, und das Fehlen von Fließkommazahlen war wohl letztlich auch eine Belastung, selbst für eine Sprache, die zur Systemprogrammierung konzipiert war.

berniebutt

@seldon Natürlich, intern sind alles Maschinenworte. Mit denen man aber nicht gerne umgehen will, auch K&R nicht als eher Systemprogrammierer. Statt Assembler haben sie ..., B, C mit grossem Erfolg draufgesattelt.

Seien wir doch froh, dass es heute überall die Datentypen gibt. Assembler und andere Maschinensprachen habe ich nur sehr ungern eingesetzt. FORTRAN und C waren mir stets lieber, heute nur noch C. Ob das nun int oder integer heissen soll, erscheint mir Schnuppe!

Und die Schlepperei von Lochkarten-Kartons ist auch vorbei. Einmal auf der Treppe hingeschmissen war besonders schön. Ohne Numerierung der Lochkarten sah man ziemlich alt aus.

Ich denke, wir können dieses Thema hier abschliessen! :p