 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Daniel Sch374le
Guest
|
 Posted: Sat Jun 18, 2005 12:33 pm Post subject: unteschiedliche int Typen |
 |
|
Hallo NG
ich habe eine grundsätzliche Frage zum folgenden
dabei bin ich einwenig off topic, weil es um long long geht
unsigned long x = (1 << 31) + 10;
unsigned long y = (1 << 31) + 20;
long long z = x + y;
unsigned long res = z % ((long long)1 << 32);
birgt meiner Meinung nach einen Fehler
dass Compiler x+y addiert, Ergebniss in einem temporärem
int (dieser überläuft) speichert und den falschen Wert z zuweist.
Ist diese Vermutung korrekt?
würde dies richtig sein
long long z = (1<<31) + 10;
z += (1<<31) + 20;
z %= (long long 1) << 32;
kleine Zusatzfrage
in welchen Typ versucht der Compiler Ausdrücke zu stecken
1<<31 //1
1<<32 //2
1+1 //3
'1' + 1
0.2 + 1
im speziellen //1 nach signed oder unsigned int?
Gruss, Daniel
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
 |
Thomas Mang
Guest
|
| Posted: Sat Jun 18, 2005 1:12 pm Post subject: Re: unteschiedliche int Typen |
|
|
"Daniel Schüle" <uval (AT) rz (DOT) uni-karlsruhe.de> schrieb im Newsbeitrag
news:d91508$4da$1 (AT) news2 (DOT) rz.uni-karlsruhe.de...
| Quote: | Hallo NG
ich habe eine grundsätzliche Frage zum folgenden
dabei bin ich einwenig off topic, weil es um long long geht
unsigned long x = (1 << 31) + 10;
unsigned long y = (1 << 31) + 20;
long long z = x + y;
unsigned long res = z % ((long long)1 << 32);
birgt meiner Meinung nach einen Fehler
|
Kommt drauf an was für Dich ein Fehler ist 
Was erwartest Du als Ergebnis?
| Quote: | dass Compiler x+y addiert, Ergebniss in einem temporärem
int (dieser überläuft) speichert und den falschen Wert z zuweist.
Ist diese Vermutung korrekt?
|
Nein, wenn zwei unsigned long addiert werden wird das Ergebnis auch stets
als unsigned long evaluiert. Ein int kommt da nie vor.
Die Probleme treten wohl schon vorher auf, in der ersten Zeile.
Laß die mal das Ergebnis von
std::cout << ( (1 << 31) + 10);
auf Deiner Maschine ausgeben.
| Quote: |
würde dies richtig sein
long long z = (1<<31) + 10;
z += (1<<31) + 20;
z %= (long long 1) << 32;
kleine Zusatzfrage
in welchen Typ versucht der Compiler Ausdrücke zu stecken
1<<31 //1
int |
| Quote: | 1<<32 //2
int, aber auf 32-bit Mascchinen undefined behavior. |
Thomas
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Rolf Magnus
Guest
|
| Posted: Sat Jun 18, 2005 1:18 pm Post subject: Re: unteschiedliche int Typen |
|
|
Daniel Schüle wrote:
| Quote: | Hallo NG
ich habe eine grundsätzliche Frage zum folgenden
dabei bin ich einwenig off topic, weil es um long long geht
unsigned long x = (1 << 31) + 10;
unsigned long y = (1 << 31) + 20;
long long z = x + y;
unsigned long res = z % ((long long)1 << 32);
birgt meiner Meinung nach einen Fehler
dass Compiler x+y addiert, Ergebniss in einem temporärem
int (dieser überläuft) speichert und den falschen Wert z zuweist.
Ist diese Vermutung korrekt?
|
Nicht in einem int, sondern in einem long, aber ansonsten schon, abhängig
davon, wie du "Fehler" definierst (*). Dem Additionsoperator ist es
Wurscht, welchem Typ du sein Ergebnis später mal zuweist. Er ermittelt wie
die anderen arithmetischen und logischen Operatoren auch den Zieltyp
ausschließlich aus den Typen der Parameter.
Hier gibt's aber noch ein anderes Problem, das ich aber erst weiter unten
nochmal aufgreifen werde.
(*) Das Ergebnis der Addition ist definiert. Es ist so, als wäre der Modulo
ausgeführt worden, den du nachher explizit nochmal ausführst. Dies gilt
aber nur für vorzeichenlose Typen.
| Quote: | würde dies richtig sein
long long z = (1<<31) + 10;
z += (1<<31) + 20;
z %= (long long 1) << 32;
|
Nein, denn "(1 << 31) + 10" ist vom Typ int, und der Wert passt in einen
32bittigen vorzeichenbehafteten Integer nicht mehr hinein. Das könnte also
nur dann korrekt sein, wenn int mehr als 32bit hat, was bei dir vermutlich
nicht der Fall ist.
| Quote: | kleine Zusatzfrage
in welchen Typ versucht der Compiler Ausdrücke zu stecken
1<<31 //1
1<<32 //2
1+1 //3
|
int, alle drei. Wenn du was anderes willst, mußt du es explizit angeben,
z.B.:
1L << 31
oder
static_cast
ebenfalls int
double
| Quote: | im speziellen //1 nach signed oder unsigned int?
|
signed.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Stefan Reuther
Guest
|
| Posted: Sat Jun 18, 2005 1:45 pm Post subject: Re: unteschiedliche int Typen |
|
|
Daniel Schüle wrote:
| Quote: | unsigned long x = (1 << 31) + 10;
unsigned long y = (1 << 31) + 20;
|
(1 << 31) ist auf einem 16-bit-System undefiniert, auf einem
32-bit-System üblicherweise -2147483648. Wenn schon, dann
unsigned long x = (1UL << 31) + 10;
| Quote: | long long z = x + y;
unsigned long res = z % ((long long)1 << 32);
birgt meiner Meinung nach einen Fehler
dass Compiler x+y addiert, Ergebniss in einem temporärem
int (dieser überläuft) speichert und den falschen Wert z zuweist.
|
Es wird in einem temporären unsigned long gerechnet, weil die Operanden
beide unsigned long sind.
| Quote: | Ist diese Vermutung korrekt?
würde dies richtig sein
|
Warum probierst du es nicht einfach aus?
| Quote: | long long z = (1<<31) + 10;
z += (1<<31) + 20;
z %= (long long 1) << 32;
|
Wenn man den offensichtlichen Typo rausmacht, kommt da -4294967266 raus.
| Quote: | kleine Zusatzfrage
in welchen Typ versucht der Compiler Ausdrücke zu stecken
1<<31 //1
|
int. Wenn sizeof(int)*CHAR_BIT > 32, ist das Ergebnis +2147483648. Bei
kleineren ints ist es undefiniert.
int, und bei weniger als 33 Bit pro int undefiniert. gcc auf x86 bekommt
1 raus.
int.
int.
double.
Stefan
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Thomas Mang
Guest
|
| Posted: Sat Jun 18, 2005 1:59 pm Post subject: Re: unteschiedliche int Typen |
|
|
"Stefan Reuther" <stefan.news (AT) arcor (DOT) de> schrieb im Newsbeitrag
news:d91fip.178.1 (AT) stefan (DOT) msgid.phost.de...
| Quote: | kleine Zusatzfrage
in welchen Typ versucht der Compiler Ausdrücke zu stecken
1<<31 //1
int. Wenn sizeof(int)*CHAR_BIT > 32, ist das Ergebnis +2147483648. Bei
kleineren ints ist es undefiniert.
|
OK bereits ab sizeof(int) * CHAR_BIT >= 32.
Die Regel lautet:
The behavior is undefined if the right operand is negative, or
greater than or equal to the length in bits of the promoted left operand.
Ich nehme mal stark an, mit Länge ist die object representation gemeint,
nicht die value representation. 100% sicher bin ich mir aber rein vom Lesen
dieses paras nicht.
Thomas
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Stefan Reuther
Guest
|
| Posted: Sat Jun 18, 2005 2:21 pm Post subject: Re: unteschiedliche int Typen |
|
|
Thomas Mang wrote:
| Quote: | "Stefan Reuther" <stefan.news (AT) arcor (DOT) de> schrieb im Newsbeitrag
kleine Zusatzfrage
in welchen Typ versucht der Compiler Ausdrücke zu stecken
1<<31 //1
int. Wenn sizeof(int)*CHAR_BIT > 32, ist das Ergebnis +2147483648. Bei
kleineren ints ist es undefiniert.
OK bereits ab sizeof(int) * CHAR_BIT >= 32.
|
Es ist in keinem Fall für 32-bit-int wohldefiniert, weil 2^31 nicht
notwendigerweise in einem 32-bit-int darstellbar ist.
| Quote: | Ich nehme mal stark an, mit Länge ist die object representation gemeint,
nicht die value representation. 100% sicher bin ich mir aber rein vom Lesen
dieses paras nicht.
|
Es muss die object-representation sein.
# The value of E1 << E2 is E1 (interpreted as a bit pattern) leftshifted
# E2 bit positions; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aber, wie gesagt, es ist nicht definiert, welcher int-Wert jetzt dem
Bitmuster 0x80000000 entspricht. Das kann mindestens -2^31 oder -0 sein
(wobei ich auf die Schnelle gar nicht finde, ob das nun undefiniert,
unspezifiziert oder implementations-definiert ist).
Stefan
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Thomas Mang
Guest
|
| Posted: Sat Jun 18, 2005 2:57 pm Post subject: Re: unteschiedliche int Typen |
|
|
Thomas
"Stefan Reuther" <stefan.news (AT) arcor (DOT) de> schrieb im Newsbeitrag
news:d91hlc.1e8.1 (AT) stefan (DOT) msgid.phost.de...
| Quote: | Thomas Mang wrote:
"Stefan Reuther" <stefan.news (AT) arcor (DOT) de> schrieb im Newsbeitrag
kleine Zusatzfrage
in welchen Typ versucht der Compiler Ausdrücke zu stecken
1<<31 //1
int. Wenn sizeof(int)*CHAR_BIT > 32, ist das Ergebnis +2147483648. Bei
kleineren ints ist es undefiniert.
OK bereits ab sizeof(int) * CHAR_BIT >= 32.
Es ist in keinem Fall für 32-bit-int wohldefiniert, weil 2^31 nicht
notwendigerweise in einem 32-bit-int darstellbar ist.
|
Jaja, aber nicht wohldefiniert bedeutet ja nicht undefiniert (in C++ -
Terminologie).
"OK" war ja etwas neutraler :-)
Außerdem darf man das bitschieben nicht mit der Interpretation des
anschließenden Wertes verwechseln (object-repres. vs. value-repr.). Das 2^31
rauskommen soll habe ich ja nie behauptet.
Steht eigentlich irgendwo festgeschrieben, daß bei sizeof(int) * CHAR_BIT >
32 auch mehr als 32 bits in der value-representation teilnehmen? Nicht das
das praktisch ein Problem wäre, aber ist es garantiert ?
Also müsste man numeric_limits<int>::digits() ranziehen, was wiederum keine
compile-time Konstante ist....
| Quote: |
Ich nehme mal stark an, mit Länge ist die object representation gemeint,
nicht die value representation. 100% sicher bin ich mir aber rein vom
Lesen
dieses paras nicht.
Es muss die object-representation sein.
# The value of E1 << E2 is E1 (interpreted as a bit pattern) leftshifted
# E2 bit positions; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
Hier gehts um Interpretationen, nicht um Größen im Speicher oder das
Schieben selber.
| Quote: | Aber, wie gesagt, es ist nicht definiert, welcher int-Wert jetzt dem
Bitmuster 0x80000000 entspricht. Das kann mindestens -2^31 oder -0 sein
(wobei ich auf die Schnelle gar nicht finde, ob das nun undefiniert,
unspezifiziert oder implementations-definiert ist).
|
Gemäß dem C-Standard ist es implementation-defined wie sign-bits
interpretiert werden (sign+magnitude, 1's complement, 2's complement),
ebenso ob (für uns interessant) der Wert wenn sign-bit = 1 und alle anderen
bits = 0 ein gültiger Wert ist, oder ein trap-value - dann wäre es
undefiniert.
Aber implementation-defined ist noch nicht (aber potentiell) undefined.
Steht eigentlich in irgendeinem Standard - vielleicht einen den der C / C++
Standard einbindet, daß das sign bit direkt an die value-bits anschließen
muß ???
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Falk Tannhäuser
Guest
|
| Posted: Sat Jun 18, 2005 3:35 pm Post subject: Re: unteschiedliche int Typen |
|
|
Thomas Mang wrote:
| Quote: | Steht eigentlich irgendwo festgeschrieben, daß bei sizeof(int) * CHAR_BIT
32 auch mehr als 32 bits in der value-representation teilnehmen? Nicht das
das praktisch ein Problem wäre, aber ist es garantiert ?
|
Nicht dass ich wüsste - von Hörensagen kenne ich eine Implementierung,
wo sizeof(int) * CHAR_BIT == 48 ist, aber nur 40 Bit für die Wertdarstellung
von "int" zur Verfügung stehen, da die Hardware wohl 48-Bit-Worte, in denen
die übrigen 8 Bit nicht gleich 0 sind, als Gleitkommazahlen ansieht.
| Quote: | Also müsste man numeric_limits<int>::digits() ranziehen, was wiederum keine
compile-time Konstante ist....
|
Doch, ist ein "static const int"-Member - velwechserst du's vielleicht mit
std::numeric_limits<...>::min() und max()?
| Quote: | Steht eigentlich in irgendeinem Standard - vielleicht einen den der C / C++
Standard einbindet, daß das sign bit direkt an die value-bits anschließen
muß ???
|
Keine Ahnung - wäre interessant zu wissen, wie es auf der oben erwähnten
Plattform ist / war (weiß nicht, ob die noch gefertigt oder zumindest in
Gebrauch ist).
MfG
Falk
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Thomas Mang
Guest
|
| Posted: Sat Jun 18, 2005 6:32 pm Post subject: Re: unteschiedliche int Typen |
|
|
--
Thomas
"Falk Tannhäuser" <tannhauser86549spam (AT) free (DOT) fr> schrieb im Newsbeitrag
news:42b43f33$0$16666$626a14ce (AT) news (DOT) free.fr...
| Quote: | Thomas Mang wrote:
Steht eigentlich irgendwo festgeschrieben, daß bei sizeof(int) *
CHAR_BIT
32 auch mehr als 32 bits in der value-representation teilnehmen? Nicht
das
das praktisch ein Problem wäre, aber ist es garantiert ?
Nicht dass ich wüsste - von Hörensagen kenne ich eine Implementierung,
wo sizeof(int) * CHAR_BIT == 48 ist, aber nur 40 Bit für die
Wertdarstellung
von "int" zur Verfügung stehen, da die Hardware wohl 48-Bit-Worte, in
denen
die übrigen 8 Bit nicht gleich 0 sind, als Gleitkommazahlen ansieht.
Also müsste man numeric_limits<int>::digits() ranziehen, was wiederum
keine
compile-time Konstante ist....
Doch, ist ein "static const int"-Member - velwechserst du's vielleicht mit
std::numeric_limits<...>::min() und max()?
|
Jepp, danke für die Korrektur.
Warum sind eigentlich min, max und einige andere member functions, andere
statische member?
Thomas
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Falk Tannhäuser
Guest
|
| Posted: Sat Jun 18, 2005 10:03 pm Post subject: Re: unteschiedliche int Typen |
|
|
Thomas Mang wrote:
| Quote: | Warum sind eigentlich min, max und einige andere member functions, andere
statische member?
|
Da habe ich mich vor einiger Zeit auch mal drüber gewundert und
in comp.std.c++ nachgefragt (Thread vom 05. und 06. Mai 2004,
Betreff "Proposed resolution of open request #416").
Offenbar war das Problem, dass std::numeric_limits für alle
arithmetischen Typen funktionieren ähnlich soll, aber min und max
nur für Ganzzahltypen Übersetzungszeitkonstanten sein können.
Da diese Situation nicht so toll ist, gibt's boost::integer_traits::const_min
und _max (siehe <http://www.boost.org/libs/integer/integer_traits.html>).
Wäre schön, wenn dies Standard werden würde...
MfG
Falk
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Mon Jun 20, 2005 1:53 pm Post subject: Re: unteschiedliche int Typen |
|
|
Falk Tannhäuser wrote:
| Quote: | Thomas Mang wrote:
Warum sind eigentlich min, max und einige andere member
functions, andere statische member?
Da habe ich mich vor einiger Zeit auch mal drüber gewundert
und in comp.std.c++ nachgefragt (Thread vom 05. und 06. Mai
2004, Betreff "Proposed resolution of open request #416").
Offenbar war das Problem, dass std::numeric_limits für alle
arithmetischen Typen funktionieren ähnlich soll, aber min und
max nur für Ganzzahltypen Übersetzungszeitkonstanten sein
können. Da diese Situation nicht so toll ist, gibt's
boost::integer_traits::const_min und _max (siehe
http://www.boost.org/libs/integer/integer_traits.html>). Wäre
schön, wenn dies Standard werden würde...
|
Dazu gibt es einen Erweiterungsvorschlag von Gabriel dos Reis,
um "trivialle" Funktionen auch als Übersetzungszeitkonstanten zu
nehmen.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Stefan Reuther
Guest
|
| Posted: Mon Jun 20, 2005 6:45 pm Post subject: Re: unteschiedliche int Typen |
|
|
Thomas Mang wrote:
| Quote: | Steht eigentlich irgendwo festgeschrieben, daß bei sizeof(int) * CHAR_BIT
32 auch mehr als 32 bits in der value-representation teilnehmen? Nicht das
das praktisch ein Problem wäre, aber ist es garantiert ?
|
Nein.
3.9.1p1:
# For character types, all bits of the object representation participate
# in the value representation. For unsigned character types, all
# possible bit patterns of the value representation represent numbers.
# These requirements do not hold for other types.
| Quote: | Es muss die object-representation sein.
# The value of E1 << E2 is E1 (interpreted as a bit pattern) leftshifted
# E2 bit positions; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Hier gehts um Interpretationen, nicht um Größen im Speicher oder das
Schieben selber.
|
Das Bitmuster ist doch die Repräsentation?
Dass mittendrin irgendwelche Paddingbits stehen, würde ich mal
ausschließen. Also dass z.B. 0xFFFF im Speicher als
11110000111100001111000011110000
^^^^
Paddingbits
steht. Denn das bisse sich meiner Meinung nach mit 3.9.1p7:
# The representations of integral types shall define values
# by use of a pure binary numeration system.
| Quote: | Gemäß dem C-Standard ist es implementation-defined wie sign-bits
interpretiert werden (sign+magnitude, 1's complement, 2's complement),
ebenso ob (für uns interessant) der Wert wenn sign-bit = 1 und alle anderen
bits = 0 ein gültiger Wert ist, oder ein trap-value - dann wäre es
undefiniert.
|
Das ist in C++ eigentlich genauso. C++ ist, soweit ich das mitbekommen
habe, bei den Anforderungen an die Umgebung eigentlich identisch mit C90.
| Quote: | Steht eigentlich in irgendeinem Standard - vielleicht einen den der C / C++
Standard einbindet, daß das sign bit direkt an die value-bits anschließen
muß ???
|
Das würde ich aus 3.9.1p7 folgern. Insbesondere der Fußnote[44].
Stefan
--
[44] A positional representation for integers that uses the binary
digits 0 and 1, in which the values represented by successive bits are
additive, begin with 1, and are multiplied by successive integral power
of 2, except perhaps for the bit with the highest position.
(Adapted from the American National Dictionary for Information
Processing Systems.)
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Falk Tannhäuser
Guest
|
| Posted: Mon Jun 20, 2005 9:33 pm Post subject: Re: unteschiedliche int Typen |
|
|
Stefan Reuther wrote:
| Quote: | Das Bitmuster ist doch die Repräsentation?
Dass mittendrin irgendwelche Paddingbits stehen, würde ich mal
ausschließen. Also dass z.B. 0xFFFF im Speicher als
11110000111100001111000011110000
^^^^
Paddingbits
steht. Denn das bisse sich meiner Meinung nach mit 3.9.1p7:
|
Und vor allem mit § 5.8/2-3:
The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shifted
E2 bit positions; vacated bits are zero-filled.
If E1 has an unsigned type, the value of the result is E1 multiplied
by the quantity 2 raised to the power E2, reduced modulo ULONG_MAX+1
if E1 has type unsigned long, UINT_MAX+1 otherwise.
[Note: the constants ULONG_MAX and UINT_MAX are defined in the header
The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has
an unsigned type or if E1 has a signed type and a nonnegative value,
the value of the result is the integral part of the quotient of E1 divided
by the quantity 2 raised to the power E2. If E1 has a signed type and a negative
value, the resulting value is implementation-defined.
MfG
Falk
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Tue Jun 21, 2005 8:43 am Post subject: Re: unteschiedliche int Typen |
|
|
Stefan Reuther wrote:
| Quote: | Thomas Mang wrote:
Steht eigentlich irgendwo festgeschrieben, daß bei
sizeof(int) * CHAR_BIT > 32 auch mehr als 32 bits in der
value-representation teilnehmen? Nicht das das praktisch ein
Problem wäre, aber ist es garantiert ?
Nein.
3.9.1p1:
# For character types, all bits of the object representation participate
# in the value representation. For unsigned character types, all
# possible bit patterns of the value representation represent numbers.
# These requirements do not hold for other types.
Es muss die object-representation sein.
# The value of E1 << E2 is E1 (interpreted as a bit pattern) leftshifted
# E2 bit positions; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Hier gehts um Interpretationen, nicht um Größen im Speicher oder das
Schieben selber.
Das Bitmuster ist doch die Repräsentation?
Dass mittendrin irgendwelche Paddingbits stehen, würde ich mal
ausschließen. Also dass z.B. 0xFFFF im Speicher als
11110000111100001111000011110000
^^^^
Paddingbits
steht. Denn das bisse sich meiner Meinung nach mit 3.9.1p7:
# The representations of integral types shall define values
# by use of a pure binary numeration system.
|
Dass der Wert so im Speicher stehen darf ist eindeutig erlaubt.
Die Paddingbits aber dÜrfen durch keinen Operator in Betracht
genommen; bei >> und << bleiben sie, wo sie sind, und maskieren
mit & darf sie auch nicht in Betracht nehmen. Also, z.B., mit
dem obergenannten Wert, nach << 2 enthält der Speicher:
11110000111100001111000011000000
und ein & mit 0x0F0F nachher ergibt:
00000000111100000000000011000000
(Die Bits können aber sichtbar sein, wenn man den Speicher über
einem unsigned char* anschaut.)
| Quote: | Gemäß dem C-Standard ist es implementation-defined wie
sign-bits interpretiert werden (sign+magnitude, 1's
complement, 2's complement), ebenso ob (für uns interessant)
der Wert wenn sign-bit = 1 und alle anderen bits = 0 ein
gültiger Wert ist, oder ein trap-value - dann wäre es
undefiniert.
Das ist in C++ eigentlich genauso. C++ ist, soweit ich das
mitbekommen habe, bei den Anforderungen an die Umgebung
eigentlich identisch mit C90.
|
Ja, aber die explizite Beschränkung auf Grösse mit Vorzeichen,
einer Komplemente oder zweier Kompemente ist erst in C99
eingekommen.
| Quote: | Steht eigentlich in irgendeinem Standard - vielleicht einen
den der C / C++ Standard einbindet, daß das sign bit direkt
an die value-bits anschließen muß ???
Das würde ich aus 3.9.1p7 folgern. Insbesondere der Fußnote[44].
[44] A positional representation for integers that uses the binary
digits 0 and 1, in which the values represented by successive bits are
additive, begin with 1, and are multiplied by successive integral power
of 2, except perhaps for the bit with the highest position.
(Adapted from the American National Dictionary for Information
Processing Systems.)
|
Bleibt frei, wo und wieviele Paddingbits.
Inzwischen frage ich mich in wie Weit, dass alle dies relevant
ist. Wenn man zweier Komplement ohne Padding, mit Datengrößen
immer von einer Zweierpotenz von Bits als normal betrachtet: so
weit ich weiß, seitdem C++ verbreitet geworden ist, hat es nur
zwei aussergewöhnlichen Rechner gegeben: die Unisys Serie A
(ehemalige Burroughs) et die Unisys 3200 (ehemalige Univac). Die
ersten sind jetzt seit einigen (ungefähr fünf?) Jahren ausser
Produktion, und die zweiten haben keine Padding-Bits (sind aber
einer Komplemente, mit 36 Bits, und noch in Produktion).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Stefan Reuther
Guest
|
| Posted: Tue Jun 21, 2005 7:36 pm Post subject: Re: unteschiedliche int Typen |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote:
| Quote: | Stefan Reuther wrote:
Dass mittendrin irgendwelche Paddingbits stehen, würde ich mal
ausschließen. Also dass z.B. 0xFFFF im Speicher als
11110000111100001111000011110000
^^^^
Paddingbits
steht. Denn das bisse sich meiner Meinung nach mit 3.9.1p7:
# The representations of integral types shall define values
# by use of a pure binary numeration system.
Dass der Wert so im Speicher stehen darf ist eindeutig erlaubt.
Die Paddingbits aber dÜrfen durch keinen Operator in Betracht
genommen; bei >> und << bleiben sie, wo sie sind, und maskieren
mit & darf sie auch nicht in Betracht nehmen.
|
Das beißt sich meiner Meinung nach mit der Forderung, dass ein "pure
binary numeration system" verwendet werden solle, in dem jedes Bit der
nächsthöheren Zweierpotenz entspricht (Fußnote 44).
Schließlich darf ich mir in C++ die Repräsentation anschauen, indem ich
das Objekt als Feld von unsigned char interpretiere, und dieser hat
keine Padding-Bits. In anderen Worten, wenn ich
int i = 42;
schreibe, *muss* danach irgendein Byte im Speicher den Wert 42 haben,
also z.B.
unsigned char* p = (unsigned char*) &i;
assert(sizeof(i) != 2 || p[0] == 42 || p[1] == 42);
Ansonsten steht und fällt meine Argumentation natürlich mit der
Definition des "pure binary numeration system".
| Quote: | Inzwischen frage ich mich in wie Weit, dass alle dies relevant
ist. Wenn man zweier Komplement ohne Padding, mit Datengrößen
immer von einer Zweierpotenz von Bits als normal betrachtet: so
weit ich weiß, seitdem C++ verbreitet geworden ist, hat es nur
zwei aussergewöhnlichen Rechner gegeben: die Unisys Serie A
(ehemalige Burroughs) et die Unisys 3200 (ehemalige Univac). Die
ersten sind jetzt seit einigen (ungefähr fünf?) Jahren ausser
Produktion, und die zweiten haben keine Padding-Bits (sind aber
einer Komplemente, mit 36 Bits, und noch in Produktion).
|
Es gibt auch heute noch in nennenswerten Stückzahlen Prozessoren mit
Wortbreiten wie 12, 18 oder 24. Ein C++-Compiler dafür ist mir nicht
bekannt, wohl aber C-Compiler. Der Prozessor, auf dem ich meine Brötchen
verdiene, hat ein paar 40-bit-Register (allerdings in C++ keinen
40-bit-Typ, der nächste passende wäre long long mit 64 Bit).
Stefan
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
