Article View: dnet.atari
Article #594Re: Turbo-C 2.0 Borland
From: Martin Weitzel
Date: Wed, 21 Feb 1990 14:35
Date: Wed, 21 Feb 1990 14:35
50 lines
3276 bytes
3276 bytes
In article <1276@nixpbe.UUCP> mboen@nixpbe.UUCP (Martin Boening) writes:
[dd ..]
>Das steht schon so in K&R. Man weis nur, dass ein int in der Groesse >= short
>aber <= long ist. Und short und long sind die einzigen Typen, deren Laenge
>festliegt: short = 16 Bit, long = 32 bit. Also, switch vergessen, portable
^^ ^^
>programmieren. Ueberhaupt: Wer sich auf implizite Funktionstypen verlaesst,
>der ist verlassen. Zum Glueck kann man in TC ANSI artig mit Prototype etc pro-
>grammieren und wird dann auf die meisten Knecken mit Warnings aufmerksam ge-
>macht.
Waehrend ich den Rest loesche (da weitgehend Uebereinstimmung besteht)
moechte ich hier eine kleine Bemerkung anbringen:
In ANSI-C sind fuer 'short' und 'long' nur MINDEST-Groessen gefordert
und zwar als WERTEBEREICH. Diese Wertebereiche sind so, dass sich
fuer 'int' und 'short' mindestens 16, fuer 'long' mindestens 32
Bit ergeben. Bei 'signed char' und 'unsigned char' ergeben sich
mindestens 8 Bit.
Zu 'char' laesst sich nur etwas sagen, wenn man den gleichzeitig
den Maschinenzeichensatz spezifiziert: Alle Zeichen des Maschinen-
zeichensatzes muessen als "positive Werte" darstellbar sein, ferner
gibt es noch den Wert 0 (fuer '\0'). (Fuer eine Maschine, die
offiziell den ISO-8859 Zeichensatz unterstuetzt und 8 Bit char-s
hat, bleibt damit uebrigens nur die Wahl, char-s als 'unsigned char'
zu betrachten ... doch das geht schon ueber die urspruengliche
Fragestellung hinaus.)
Es lohnt bei modernen 32-Bit-Architekturen uebrigens meist nicht
'short' zu verwenden ausser bei Arrays: Die Einsparung im
Datenraum kann durch erhoehten Platzbedarf im Maschinencode mehr als
wettgemacht werden und manchmal sind sogar *mehr* Speicherzyklen
erforderlich um ein 'short' zu schreiben, als fuer ein 'int'
(und deshalb legen manche Compiler einzelne 'shorts' auch einfach
als 'int' ab ...)
Generell sollte man 'int' als den "effizientesten" Typ sehen und
in allen Faellen verwenden, wo man mit Sicherheit den Wertebereich
von -32767 bis 37767 nicht ueberschreitet. In Faellen, in denen
man mehr Kontrolle ueber die tatsaechliche Anzahl von Bits haben
will, sollte man wie vorgeschlagen eigene Datentypen definieren.
Aber Vorsicht mit 'int16' oder 'int32': Auf manchen Maschinen
koennte nur die Wahl zwischen 18 oder 36 Bit bestehen. Sollte
ein Programm davon ausgehen, dass 'int16' nicht weniger, aber
auch nicht *mehr* als 16 Bit hat, ist es potentiell unportabel!
--
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
--
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
Technical Details
Message-ID:
<632@mwtech.UUCP>Path:
arc1-ca.pugleaf.net!gmdzi!unido!mikros!mwtech!martinReferences:
<1993@laura.UUCP> <1276@nixpbe.UUCP>Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII-7-bit X-Google-Thread: 12bdcf,e671da0a06e98b2e X-Google-Attributes: gid12bdcf,public X-Google-ArrivalTime: 1990-02-22 01:17:20 PST Path: arc1-ca.pugleaf.net!gmdzi!unido!mikros!mwtech!martin From: martin@mwtech.UUCP (Martin Weitzel) Newsgroups: dnet.atari Subject: Re: Turbo-C 2.0 Borland Keywords: Turbo C 2.0 Borland Message-ID: <632@mwtech.UUCP> Date: 21 Feb 90 14:35:00 GMT References: <1993@laura.UUCP> <1276@nixpbe.UUCP> Reply-To: martin@mwtech.UUCP (Martin Weitzel) Distribution: dnet Organization: MIKROS Systemware, Darmstadt/W-Germany Lines: 50 Posted: Wed Feb 21 15:35:00 1990