Zitat:

---

Original von Holger:

Abgesehen davon, dass globale Variablen keine gute Idee sind, sollte trotzdem der Destruktor korrekt aufgerufen werden. Wenn das nicht passiert, fallen mir zwei Möglichkeiten ein:

Du beendest das Programm nicht korrekt (hinter dem Rücken des Compilers

Der Compiler ist fehlerhaft

---

Zitat:

---

Zitat:

---

Heisst das in meinem Fall, wenn ich eine Klasse A habe und ich diese mit

list.addElement(A("Param1", 2, 'C', TRUE));

in die Liste lege sie dort solange bleibt, bis die Liste zerstört wird, auch wenn die Methode und die Klasse, in der dieser Aufruf steht zwischenzeitlich verlassen wird?

---

Solange die Variable list besteht, ja.

---

Zitat:

---

Zitat:

---

Ich hoffe, dass dies nicht mehr der Fall ist, wenn meine Liste auf Referenzen umgestellt ist und ich in a folgendes schreiben kann:

addElement(B &b)
{
list.addElement(b);
}

Oder ist dort nach dem Verlassen dieser Methode wieder damit zu rechnen, dass direkt im Anschluss der Destruktor von B gerufen wird?

---

Wenn sich im Aufrufer nichts ändert, ja. Aber in list liegt ja dann eine Kopie von b, auch wenn das wahrscheinlich nicht das ist, was Du vorhattest.

---

Zitat:

---

Ein Pointer kann auf ein beliebiges Objekt zeigen, und von einem auf ein anderes Objekt "umgebogen" werden. Die Syntax unterscheidet sich von einem "echten" Objekt dadurch, daß ein Pointer dereferenziert werden muß. Ein Pointer ist eine eigenständige Datenstruktur.

Eine Referenz zeigt auf ein ganz spezielles Objekt, kann nicht umgebogen werden, und unterscheidet sich syntaktisch nicht von einem "echten" Objekt. Eine Referenz ist nur ein anderer Variablenname für dieselbe Datenstruktur (das Objekt) - also ein Alias.

---

Zitat:

---

C++ macht kein Reference Counting; der Pointer auf b hält b nicht am Leben, wenn b selbst out-of-scope geht.

Der Destruktor wird wahrscheinlich nicht beim Verlassen von addElement() aufgerufen, sondern beim Verlassen der aufrufenden Funktion, in der b als lokale Variable deklariert wurde.

---

Zitat:

---

Zitat:

---

Ich hoffe, dass dies nicht mehr der Fall ist, wenn meine Liste auf Referenzen umgestellt ist und ich in a folgendes schreiben kann:

addElement(B &b)
{
list.addElement(b);
}

Oder ist dort nach dem Verlassen dieser Methode wieder damit zu rechnen, dass direkt im Anschluss der Destruktor von B gerufen wird?

---

Wenn sich im Aufrufer nichts ändert, ja. Aber in list liegt ja dann eine Kopie von b, auch wenn das wahrscheinlich nicht das ist, was Du vorhattest.

---

Leider nein!

Aber wieso jetzt eine Kopie? Ich hab Referenz so verstanden, dass keine Kopie des Objektes angelegt wird? Jetzt bin ich verwirrt. Würde nämlich genau letzteres benötigen: Die Referenz auf ein Objekt in der Liste - aber keine Kopie des Objektes in der Liste. Denn wenn in einer weiteren Liste ebenfalls eine Referenz auf das gleiche Objekt gespeichert ist und sich das Objekt ändert, sollen beide Referenzen auf das geänderte Objekt verweisen.
Wenn jedoch nun bei Übergabe der Referenz an die Liste eine Kopie des Objektes angelegt wird ist das natürlich denkbar schlecht!

Was tut man in so einem Fall? Doch wieder auf Zeiger zurückfallen?

Zitat:

---

Original von gni:

Zitat:

---

Reth:
Also ist der C++ Programmierer gar kein so Pointer-Jongleur wie der C-Programmierer? Benutzt der C++ Programmierer fast nur Objekte und deren Kopien als viel mehr Referenzen auf Objekte (in Java hat man nur Referenzen)?

---

Pauschal läßt sich das nicht beantworten. new() braucht (fast ;-) immer ein delete() und wie Du gesehen hast, gibt es starke Aversionen gegen new().

Zitat:

---

Verbrät das nicht viel mehr Speicher als nötig wäre?

---

Wieso? Auch statische Objekte belegen Platz.

---

Zitat:

---

Original von Solar:

Korrekt. Zumal mit dem syntaktischen Element der Referenz ein guter Weg dazugekommen ist, Funktionen by reference aufzurufen (also ohne ein Objekt zu kopieren), ohne mit (fehleranfälligen) Pointern hantieren zu müssen.

Wie gesagt, in C++ benutzt man viel und gerne die Referenz:

void foo( Object const & paramter )
{ ... }

In der Funktion ist "parameter" somit keine Kopie des Arguments, sondern das Argument selbst. Und wenn man das 'const' wegläßt, kann man "parameter" in der Funktion sogar verändern.

---

Zitat:

---

Zitat:

---

Verbrät das nicht viel mehr Speicher als nötig wäre?

---

Das Speicherprofil der durchschnittlichen C++-Anwendung liegt eher unter dem einer Java-Anwendung vergleichbarer Güte, weil Garbage Collection und der dazugehörige Aufwand wegfällt. (Von der Virtual Machine und dem JIT mal ganz zu schweigen.)

---

Zitat:

---

Ich kann mir immer noch nicht vorstellen, warum Du zwei Listen mit Referenzen auf dieselben Objekte haben willst, und Du hast mit keinem Wort etwas über die Natur dieser Listen erwähnt. Geht's hier nur um's Prinzip? Oder kann man evtl. an Deinem Design etwas ändern?

---

Zitat:

---

Original von Solar:

Für den ambitionierten Pointer-Jongleur bleibt nur noch der shared_ptr - nur ist der leider (noch) nicht in der Standardbibliothek, sondern (noch) nur in der Boost-Bibliothek.

---

Zitat:

---

Also "Standard" ist leider nicht, und "üblich"... hängt halt zu sehr von Deiner Datenstruktur ab, und was Du eigentlich vorhast...

---

Zitat:

---

Zitat:

---

Und was passiert, wenn ein und dasselbe Objekt in 2 versch. Listen stehen soll? Dann zeigen doch die jeweiligen anonymen Autopointer auf das gleiche Objekt, es kann aber nur einmal freigegeben werden!?

---

Nein. auto_ptr und refernziertes Objekt stehen in einer 1:1-Beziehung. Auf ein Objekt kann immer nur ein auto_ptr zeigen. In diesem Fall ist auto_ptr die falsche Lösung.

Wenn Du tatsächlich ein- und dasselbe Objekt in zwei Listen brauchst, brauchst Du tatsächlich einen Reference Counter in irgendeiner Form.

---

Zitat:

---

Original von Solar:
Oh, zur Syntax:

new Object() gibt Dir einen Pointer auf ein Object, Object() gibt Dir ein Object.

---

Zitat:

---

STL-Container speichern Kopien der Objekte. Das ist OK, wenn Deine Objekte "billig" zu kopieren sind (d.h., nicht übermäßig groß / komplex).

Wenn sie "teuer" sind, oder Du unbedingt "new" verwenden möchtest, gibt es (ebenfalls in der STL) das Wrapper-Template auto_ptr<>. Das wird benutzt wie folgt:

auto_ptr<Object> aptr( new Object() );

Du kannst aptr wie einen Pointer auf Object verwenden. Der Pointer auf Object ist eine Membervariable von aptr, der syntaktisch transparent behandelt wird - *aptr ist vom Typ Object.

---

Zitat:

---

Der "Trick" bei auto_ptr<> besteht darin, daß bei einer Kopie (auto_ptr<Object> bptr = aptr) keine echte Kopie angelegt, sondern der Pointer auf Object "weitergereicht" wird - aptr ist nach der Zuweisung nicht mehr gültig. Und wenn bptr "out-of-scope" geht, wird (durch den Destruktor von auto_ptr<>) automatisch "delete" auf den enthaltenen Pointer aufgerufen.

Auf den ersten Blick nur verwirrend; aber extrem praktisch, wenn Du Pointer in einem Container speichern willst (wie oben beschrieben):

list.push_back( aptr );

In der Liste wird ein (anonymer) auto_ptr<Object> als Kopie von aptr angelegt. aptr ist ab sofort ungültig. Geht jetzt list out-of-scope, ruft es den Destruktor für alle enthaltenen Objekte auf - und das Objekt, auf das aptr ursprünglich gezeigt hat, wird "delete"'d.

---

Zitat:

---

Original von Solar:

Zitat:

---

Original von Reth:

Wenn während des Programms neue Objekte notwendig sind, die vorher noch nicht absehbar waren, wie soll man das denn realisieren?

---

Als lokale Variable?

Class var; // Standardkonstruktor
Class var("Hallo!"); // Class( char * ) oder Class( string& )
Class var = "Hallo!"; // Erzeugen eines anonymen Objekts und Zuweisung über operator=()

"new" legt ein Objekt auf dem Heap an, das solange existiert, bis es mit "delete" zerstört wird. Das "var" aus den obigen Beispielen wird automatisch zerstört, wenn es "out of scope" geht.

Oder anonym:

#include <vector>

using std::vector;

vector<Object> list;

list.push_back( Object("Hallo") );
list.push_back( Object("Welt") );

---

Zitat:

---

Bitte, bitte gib Dir Mühe. Ich habe mir ein Projekt an's Bein gebunden, bei dem ein Java-Progger genau das gemacht hat: In C++ Java zu programmieren. Grau-en-haft. Ich krieg' jedesmal Migräne, wenn ich versuche, den Code wieder ein Stück lesbarer zu machen.

---

Zitat:

---

Du meinst STL, und Du hast ein Problem.

---

Ich hoffe doch nur, weil ich sie nicht habe - oder siehtst Du bei mir noch sonstige Probleme?

Zitat:

---

Du machst nicht zufällig mit MaxonC++ herum, oder StormC 3?

---

Zitat:

---

Nein, ehrlich. C++ ohne STL ist ungefähr wie Java ohne 'import'. Dringend GCC 3.x besorgen!

---

Zitat:

---

Original von Solar:

Wieso willst Du sie überhaupt dynamisch erzeugen?

---

Zitat:

---

Zunächst einmal, ganz wichtig, begreife C++ als eigene Sprache, nicht als eine andere Möglichkeit Java zu programmieren.

---

Das wird schwierig genug

Zitat:

---

Nicht jede Klasse muß von einem allgegenwärtigen "class Object" abgeleitet sein. Wenn zwei Klassen nicht miteinander verwandt sind, modelliere sie auch nicht als verwandt.

---

Zitat:

---

Nicht jedes Objekt muß mit "new" erstellt werden. (Im Gegenteil, oft wirst Du in einem gut entworfenen Programm kein einziges "new" brauchen.)

---

Zitat:

---

Mache Dich mit der Standardbibliothek vertraut. Dort wirst Du Dinge finden wie Container (vor allem <vector>), oder den auto_ptr (in <memory>).

---

Zitat:

---

Original von Reth:
Danke für den Tip aber Atomic will bei mir auch nicht:

Connecting to Atomic Clock server ptbtime2.ptb.de
Server connection time: 0.04
Server Health: insufficient...trying next server.

Connecting to Atomic Clock server de.pool.ntp.org
Connection error with de.pool.ntp.org
Connecting to Atomic Clock server ntp0.fau.de
Connection error with ntp0.fau.de
Connecting to Atomic Clock server ntp3.fau.de
Connection error with ntp3.fau.de
Connecting to Atomic Clock server ntps1-1.cs.tu-berlin.de
Connection error with ntps1-1.cs.tu-berlin.de
Connecting to Atomic Clock server ntps1-0.cs.tu-berlin.de
Connection error with ntps1-0.cs.tu-berlin.de
Connecting to Atomic Clock server ptbtime1.ptb.de
Connection error with ptbtime1.ptb.de
Connecting to Atomic Clock server ntp1.t-online.de
Connection error with ntp1.t-online.de
Connecting to Atomic Clock server ntp1.fau.de
Connection error with ntp1.fau.de
Connecting to Atomic Clock server ntp2.fau.de
Connection error with ntp2.fau.de
Connecting to Atomic Clock server
Connection error with
*** NIST Time Services are not present...exiting


Solche Meldungen gabs auch mit den voreingestellten Servern!

Liegts evtl. daran, dass ich beim meinem DSL-Router nen neuen Provider eingetragen hab? An der Firewallkonfig. des Routers hab ich aber nix geändert!

---