Warum C++ das so hat ist ganz einfach wegen der Kompatibilität zu C. Und warum das C so hat weiss vielleicht volkard.

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.

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

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.

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

Schieß los!

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.

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

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.

Was hat das mit Boxing zu tun?

Er verwechselt es mit Java.

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.

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?

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

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.

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

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