OHNE Kopierkonstruktor - Programmabbruch [mittels geeigneter Methode]

CStoll

"undefiniertes Verhalten" bedeutet nicht unbedingt Absturz - das kann auch bedeuten, daß du das Pech hast, daß alles durchläuft. Und double delete bewirkt (lediglich) undefiniertes Verhalten.

TGGC

Ich glaube kaum, das APIs Befehle wie MakeCrash() anbieten. Daher ist die Aufgabe schon etwas komisch. Eine moeglicherweise sinnvolle Interpretation waere eine unbehandelte Exception zu erzeugen. Also einfach der Klasse ein Flag geben, ob der Copykonstruktor aufgerufen wurde. Im Konstruktor auf false setzen und im Copykonstruktor auf true. Instanz der Klasse erzeugen, kopieren. Wenn das Flag immer noch false ist, dann wurde es lediglich vom Standard Copykonstruktor kopiert und man wirft eine Exception. Ende. f'`8k

Autocogito

Gruß, TGGC (making great games since 1992)

Simon2

TGGC schrieb:

...Daher ist die Aufgabe schon etwas komisch....

Und nicht nur deswegen. Auch dies hier kommt mir seltsam vor:

Chito schrieb:

...
Wenn ich den Kopierkonstruktor herauskommentiere, soll das Programm abstürzen....

Etwas im Source auskommentieren, um einen Laufzeitfehler, aber keinen Compilefehler zu bekommen ? Was ist das denn für ein Lehrinhalt ? Soll da gezeigt werden, dass man sich auch Compilermeldiungen (bzw. deren Fehlen) nicht verlassen soll ?
Mit "Absturz" könnte man auch ein fehlgeschlagenes assert() verbinden....

Gruß,

Simon2.

CStoll

@TGGC: Ich würde die Klasse eher nicht so designen, daß sie unbedingt kopiert werden MUSS - sondern eher ein Problem analog zum double delete forcieren:

class test
{
  test() :p(new int(1) {}
  test(test& other) : p(new int(*other.p)) {}
  test& operator=(test& other)
  {
    *p=*other.p;
    return this;
  }

  ~test()
  {
    --*p;
    assert(*p==0);
  }
private:
  int*p;
};

LordJaxom

TGGC schrieb:

Ich glaube kaum, das APIs Befehle wie MakeCrash() anbieten.

Also zumindest unter UNIX fallen mir spontan drei Möglichkeiten zur Selbstterminierung mit Speicherabbild ein

TGGC

CStoll schrieb:

@TGGC: Ich würde die Klasse eher nicht so designen, daß sie unbedingt kopiert werden MUSS

Das ist aber die Aufgabe. Ausserdem ist das letztendlich nichts Anderes nur das sich das Flag halt irgendwo versteckt, z.b. in der Speicherverwaltung. Fuers Lernen faende ich es sinnvoller, das nicht ueber irgendein Sideeffekt oder undefiniertes Verhalten zu erreichen. f'`8k

Gruß, TGGC (making great games since 1992)

CStoll

TGGC schrieb:

CStoll schrieb:

@TGGC: Ich würde die Klasse eher nicht so designen, daß sie unbedingt kopiert werden MUSS

Das ist aber die Aufgabe.

Bist du sicher? Der Eröffnungspost sagt nur aus, daß die Klasse ohne (bzw. mit dem implizit generierten) Copy-Ctor nicht funktionsfähig sein darf/sollte - eine Klasse, die ich vor der Zerstörung mindestens einmal kopiert haben muß, ist nicht wirklich sinnvoll.

TGGC

Und wie ueberpruefst du, ob der implizit generierte Copy-Ctor oder der Explizite Aufgerufen wurde, wenn nie eine Instanz kopiert wird? Die Aufgabe verlangt somit, das kopiert wird. Also schreibe ich mir logischerweise einfach eine Klasse, die mir sagt, ob ihr Copy-Ctor aufgerufen wurde. Ich brauch dann nur das Flag abfragen und "crashen". Deine Klasse ist hingegen inherent kaputt. f'`8k

Gruß, TGGC (making great games since 1992)

CStoll

TGGC schrieb:

Deine Klasse ist hingegen inherent kaputt. f'`8k

Wieso das? (abgesehen von dem potentiellen Speicherleck?) Der Ansatz demonstriert direkt die Probleme, die beim Verstoß gegen die "Rule of Three" auftreten können - und ist damit auch als abschreckendes Beispiel für die Zukunft geeignet (und er erfüllt die Aufgabenstellung - wenn der implizite Copy-Ctor zum Einsatz kommt, schmiert das Programm ab).

Eine Klasse, die nur zu dem Zweck existiert, irgendwann kopiert zu werden, ist technisch sinnlos (im Gegensatz zu einer Klasse, die ohne einen explizit definierten Copy-Ctor unbrauchbar ist). Also was kann man damit effektiv anfangen?

@Chito: Es wäre nett, wenn du mal die "offizielle" Lösung bringen würdest

Gruß, TGGC (making great games since 1992)

Nur am Rande: Du kannst solche Texte auch als Signatur einstellen

TGGC

CStoll schrieb:

Wieso das? (abgesehen von dem potentiellen Speicherleck?

Noch Fragen?

CStoll schrieb:

Eine Klasse, die nur zu dem Zweck existiert, irgendwann kopiert zu werden, ist technisch sinnlos (im Gegensatz zu einer Klasse, die ohne einen explizit definierten Copy-Ctor unbrauchbar ist). Also was kann man damit effektiv anfangen?

Die Aufgabenstellung erfuellen. f'`8k

Gruß, TGGC (making great games since 1992)

CStoll

TGGC schrieb:

CStoll schrieb:

Wieso das? (abgesehen von dem potentiellen Speicherleck?

Noch Fragen?

Ja, ich kann das Problem mit einem einfache "delete p" beheben - wie willst du deine Klasse so erweitern, daß sie praktisch nutzbar wird?

CStoll schrieb:

Eine Klasse, die nur zu dem Zweck existiert, irgendwann kopiert zu werden, ist technisch sinnlos (im Gegensatz zu einer Klasse, die ohne einen explizit definierten Copy-Ctor unbrauchbar ist). Also was kann man damit effektiv anfangen?

Die Aufgabenstellung erfuellen. f'`8k

Und der praktische Lerneffekt dieser Übung wäre gleich NULL (sicher, Chito ist damit in der Lage, nutzlose Klassen zu schreiben. Aber für seine Karriere als Programmierer bringt das gar nichts)

tntnet

class A
{
    static bool copied;
  public:
    A(const A& c)
   { copied = true; }
   ~A()
   { if (!copied) abort(); }
};

bool A copied = false;

int main()
{
  A a1;
  A a2(a2);
}

:p

Simon2

Jungs, Jungs, Jungs, ....

diese "Schw-Vergleich-Diskussion" bringt doch nichts und entsteht nur aufgrund einer schwachsinnigen/unvollständig wiedergegebenen/unklaren/... Aufgabenstellung.
Es ist hier noch nicht geklärt, welche Aufgabe wirklich gelöst werden soll und Ihr koppt Euch, wessen "Lösung" das besser tut ?

Lohnt doch gar nicht......

Gruß,

Simon2.

Ihr seit dumm.

TGGC

Ach, CStoll steht fuer Mehrere? f'`8k

Gruß, TGGC (making great games since 1992)

Simon2

TGGC schrieb:

Ach, CStoll steht fuer Mehrere? f'`8k...

Blöd und überflüssig - da kenne ich eigentlich nur Besseres von Dir.

Gruß,

Simon2.