bessere Zufallszahlen?
-
man bracuht ja auch nur zahl[0] initialisieren, zahl[1]-zahl[99] wird ja per rand() mit gültigen werten gefüllt!
-
Nein. Die fragliche Stelle war diese:
srand(((time(NULL)-i)+zahl[i])); zahl[i]=rand();Die leidet erstens ziemlich an Klammeritis und zweitens faßt Du zahl[i] an, bevor Du es "initialisierst".
-
Daniel E. schrieb:
camper schrieb:
nach der norm darf hier nicht 'alles' passieren, denn es handelt sich um built-in typen
Was darf denn laut Norm nicht passieren? Kapitel und Vers?
sag ich dir gerne später (wenn ich mich recht entsinne bei fundamentalen datentypen/equivalenz zu char* arrays etc.). kurz gesagt existiert ein builtin oder POD typ solange dafür speicher reserviert ist - unabhängig von irgendwelchen (pseudo-)constructor/destructor calls - also auch unabhängig davon, ob es initialisiert wurde. ausserdem kennt ein int keine ungültigen zustände. folglich ist eine lvalue-zu-rvalue conversion wie hier stets ohne weiteres möglich. es ist hier also nur der 'wert' von zahl[i] undefiniert, nicht aber, was damit gemacht wird.
-
camper: Naja, nicht ganz. Ich zitiere aus dem C-Standard: 6.2.6.1#5:
Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.41) Such a representation is called a trap representation.
'Character types' sind wirklich nur 'character types' (6.2.5#15). Ich bezweifle, daß das in C++ so viel anders ist.
-
Daniel E. schrieb:
camper: Naja, nicht ganz. Ich zitiere aus dem C-Standard: 6.2.6.1#5:
Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.41) Such a representation is called a trap representation.
'Character types' sind wirklich nur 'character types' (6.2.5#15). Ich bezweifle, daß das in C++ so viel anders ist.
ist es auch nicht. aber dort steht richtigerweise nur need not und nicht do not. für int kann das nähmlich nicht gelten. es kann keine representationen für int geben, die keine gültigen ints sind.
3.9.1
-
... The representation for integral types shall define values by use of a pure binary system. 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.
nun kann man aber durch binäre operationen von jeder beliebigen representation zu jeder anderen gelangen (für nichtnegative werte muss die representation für signed(unsigned typen gleich sein) - dabei kann man aber nicht zu ungültigen (trap) werten kommen. es gibt also 2^n gültige int representationen und diese representationen müssen in n bits gespeichert sein. (wenn ich das richtig sehe muss n hier nicht ein ganzzahliges vielfaches der bitzahl eines chars sein - das spielt aber keine rolle, denn überzählige bits wären dann schlicht kein teil der value representation von int).
-
-
camper schrieb:
Daniel E. schrieb:
camper: Naja, nicht ganz. Ich zitiere aus dem C-Standard: 6.2.6.1#5:
Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.41) Such a representation is called a trap representation.
'Character types' sind wirklich nur 'character types' (6.2.5#15). Ich bezweifle, daß das in C++ so viel anders ist.
ist es auch nicht. aber dort steht richtigerweise nur need not und nicht do not. für int kann das nähmlich nicht gelten. es kann keine representationen für int geben, die keine gültigen ints sind.
Huch, 6.2.6.2#1 erlaubt explizit integer padding bits und in der zugehörigen Fußnote steht, daß spezielle Bitfolgen Traps auslösen können.
Das ist ein Widerspruch zu dem, was Du da schreibst:
nun kann man aber durch binäre operationen von jeder beliebigen representation zu jeder anderen gelangen (für nichtnegative werte muss die representation für signed(unsigned typen gleich sein) - dabei kann man aber nicht zu ungültigen (trap) werten kommen. es gibt also 2^n gültige int representationen und diese representationen müssen in n bits gespeichert sein. (wenn ich das richtig sehe muss n hier nicht ein ganzzahliges vielfaches der bitzahl eines chars sein - das spielt aber keine rolle, denn überzählige bits wären dann schlicht kein teil der value representation von int).
-
ich kann im C++ standard keinen hinweis darauf finden. der wert eines objekts wird durch seine wert-representation bestimmt, irgendwelche bits, die zwar zur objektrepresentation aber nicht zur wert-representation gehören, dürften keine rolle spielen. damit also trap-representationen möglich sind, müssten diese teil der wertrepresentation sein - das widerspricht in meinen augen aber der forderung der binären darstellung wie oben angegeben.
ich nehme allerdings meine behauptung zurück, dass der standard irgendetwas dazu sagt, was in diesem falle nicht passieren kann. undefiniert ist eben undefiniert - aber nicht zwingend böse, undefiniertes verhalten darf ja durch eine implementation explizit definiert werden; und in diesem speziellen falle dürfte das doch auf sehr viele mögliche rechnersysteme zutreffen.