3. definierte und undefinierte Codekonstrukte

definierte und undefinierte Codekonstrukte

  • H

    cd9000 schrieb:

    "Undefiniert" und "implementationsabhängig" halte ich aber für sehr schwammig.
    Viele undefinierte Konstrukte funktionieren bei einer bestimmten Implementierung; sind sie deswegen implementierungsabhängig?

    Im Kontext von Standard-C++ sind die Begriffe keineswegs schwammig. Sie werden im Standard eindeutig definiert (1.3.5, 1.3.12 sowie 1.3.13)

    0
  • W

    Hallo,
    Toll - so viele Antworten!!!!!
    Aus dem Grunde auch schon mal, weil das eigentlich eine
    Anfängeraufgabe ausm Stroustrup is, die aber anscheinend
    doch auch zu Diskussionen führt unter Fortgeschrittenen.

    Ich hab nun weiter hinten in dem Buch unter C2 noch
    folgendes dazu gefunden und wollte es mal der
    Vollständigkeit halber noch anführen:

    unsigned char c1 = 64;    // wohldefiniert, ein char hat mind 8 Bit
unsigned char c2 = 1256;    // implementierungsspezifisch

// ... und ...

const int size = 4*1024;
char page[size];

void f()
{
    page[size+size] = 7;    // undefiniert
}

    ...sind allerdings eben nur 2 Bsps und nicht 5, aber nun is mir klarer
    in welche Richtung das gehen soll.

    Danke Euch nochmal! 🙂

    0
  • A
     

    int i = 2;
  cout << i++ << (i++) * (i++);

    Ist ebenfalls undefiniert.

    0
  • C

    Hi,

    bei

    struct undef {
int a;
char b;
long c;
}

    ist auch undefiniert, in welcher Reihenfolge die Objecte im Speicher abgelegt werden.
    (daher kann man um alles auf 0 zu setzen nicht die Funktion mamset() benutzen, der man als Startadresse die Adresse von undef.a übergibt, und als Anzahl der zu überschreibenden Bytes sizeof(int) + sizeof(char) + sizeof(int).

    0
  • S

    c++eus schrieb:

    Hi,

    bei

    struct undef {
int a;
char b;
long c;
}

    ist auch undefiniert, in welcher Reihenfolge die Objecte im Speicher abgelegt werden.
    (daher kann man um alles auf 0 zu setzen nicht die Funktion mamset() benutzen, der man als Startadresse die Adresse von undef.a übergibt, und als Anzahl der zu überschreibenden Bytes sizeof(int) + sizeof(char) + sizeof(int).

    das mit den padding bytes stimmt.
    aber es ist schon definiert, dass a vor b vor c kommt. sonst wäre es ja ein blödsinn.

    0
  • C

    Shade Of Mine schrieb:

    c++eus schrieb:

    Hi,

    bei

    struct undef {
int a;
char b;
long c;
}

    ist auch undefiniert, in welcher Reihenfolge die Objecte im Speicher abgelegt werden.
    (daher kann man um alles auf 0 zu setzen nicht die Funktion mamset() benutzen, der man als Startadresse die Adresse von undef.a übergibt, und als Anzahl der zu überschreibenden Bytes sizeof(int) + sizeof(char) + sizeof(int).

    das mit den padding bytes stimmt.
    aber es ist schon definiert, dass a vor b vor c kommt. sonst wäre es ja ein blödsinn.

    wieso?
    es bleibt doch dem Compiler überlassen, inwiefern er das optimiwert.

    0
  • S

    c++eus schrieb:

    wieso?
    es bleibt doch dem Compiler überlassen, inwiefern er das optimiwert.

    klär mich mal auf

    was darf er optimieren?
    padding bytes? ja
    reihenfolge der variablen? nein

    solltest du anderer meinung sein, bitte die stelle im standard angeben, wo das steht. danke.

    0
  • C

    Hi,

    stimmt, der Compiler lässt die Variablen wo sie sind. Er füllt sie lediglich mit Füllbyte auf, um die Variablen an Zweierpotenzen beginnen zu lassen.

    0
  • H

    @c++eus
    Innerhalb eines Access-Levels ist die Reihenfolge der Anordnung von Membern genau definiert. In diesem Fall muss a an einer niedrigeren Adresse als b liegen, welches wiederum vor c liegen muss.

    0
  • C

    wendy schrieb:

    unsigned char c1 = 64;    // wohldefiniert, ein char hat mind 8 Bit
unsigned char c2 = 1256;    // implementierungsspezifisch

    Der Code ist in Ordnung, aber dein Kommentar IMHO nicht. Kann char nicht auch 7 Bits haben? (rein theoretisch, ist heute natürlich Blödsinn.)

    0
  • W

    Ähm ?!
    Soweit ich bis jetzt gelesen (und begriffen) habe,
    ist bei den versch. Typen nur immer die Mindestgrössen
    festgelegt. Die effektive obere Grenze ist dann
    compiler-spezifisch (== implementierungsabhängig ?!).

    Also, ein char ist mind. 8 Bit gross/lang.

    Ich versteh das dann so: 8 gesetzte Bit sind ja nur 255
    und 64 < 255 < 1256, da ja char hier als Zahl betrachtet
    wird.

    ...oder?

    PS.: das war nicht mein Kommentar sondern B. Stroustrup's

    0
  • B

    wendy schrieb:

    Also, ein char ist mind. 8 Bit gross/lang.

    Ich versteh das dann so: 8 gesetzte Bit sind ja nur 255
    und 64 < 255 < 1256, da ja char hier als Zahl betrachtet
    wird.

    Richtig.

    0
  • C

    Muss ein char nach dem Standard also mindestens 8 Bit haben?
    Funktioniert das nicht auch mit 7 Bit, wenn man eine Maschine hat, bei der die Bytes 7 Bit groß sind?

    0
  • H

    Muss ein char nach dem Standard also mindestens 8 Bit haben?

    Yup.

    Funktioniert das nicht auch mit 7 Bit, wenn man eine Maschine hat, bei der die Bytes 7 Bit groß sind?

    Wenn ich mich recht entsinne muss eine solche Maschine in diesem Fall die 8 (oder mehr) Bits in Software simulieren.

    0
Anmelden zum Antworten