for(;;) schleife verlassen

volkard

PAD schrieb:

Jedes C-Programm ist auch ein C++ Programm
C++ bietet dazu zusätzliche Methoden und Möglichkeiten an.
definitiv falsch.

C++ bietet keine zusätzlichen Methoden an, komisch jedes Buch schreibt aber das Gegenteil
Falsch sagen kann jeder Ich sprach von Überzeugen nicht von über reden.
Bring ein Beispiel

hat hume dankenswerter weise schon. und du hast dich als der geoutet, der keine ahnung hat. sorry, aber es reicht nicht, was in 5 büchern gelesen zu haben. der satz "C ist eine echte teilmenge von C++" findet sich in hunderten und ist dennoch falsch.

PAD schrieb:

Jetzt zum Destruktor
Laut Definition ist der Destruktor das Gegenstück zum Konstruktor
definitiv falsch.

Das Stoustrup was falsches schreibt wundert mich Gleiche Quelle Kapitel 10.4.1

der standard definiert. nicht struppi.

Un du bist nicht in der Lage das zu erklären.

kindern wie dir erklärt man es auch nicht mehr.

Wenn ich im Stoustrup mir Kapitel E.2 anschaue erfüllt mein C Code die Bedingung die exceptionsicherheit gestellt wird ohne c++ zu benutzen.

haste definiert, daß im "vergleich" keine excepion fliegen kann. isrt der vergleich zufällig der vergleich von std::string mit char const*? kann ja alles ein. und dein code kackt in solchem falle bitterbös ab.

Stoustrup ist mir neben dem Standard für Definitionen lieber.
Ich benutze lieber die Quelle als den von vielen gefilterten Aufguss.
Was nicht heist das andere Leute keine guten Bücher schreiben

der standard definiert. in ddaß man den ctor nicht als gegenteil vom dtoe definiert, ist ja wohl sonnenklar. das wäre nämlich ne inhaltliche geschichte. das paßt nicht. man definiert nur, was wann zu passieren hat. nicht was was bedeuten soll.

:p Zusammenfassung deine Antwort ohne ein sinnvolles Argument eigentlich Schade :p

weil zu zu blöd bist, zu überlegen. wenn ich dir sage, daß ein satz von die nonsens ist, dann überleg kurz und es sollte klar sein. du sagt nen müll. ich sage "falsch". und dann kannst du doch nicht kommen mit "doch, ich hab recht." du hast auch mal zu begründen, was du dahersagtst. aber alle deine begründungen kann ich in der luft verreißen, so unausgegoren sind sie. wie du bemerken wirst, steht auch kein einziges deiner argmente mehr.
so gar keins. das ist an sich ein zeichen dafür, daß du auf breiter front unrecht hast. und jetzt lies diese diskussion nochmal von vorn, damit du nicht wieder mit sachen kommst, die längst widerlegt sind.

PAD

@Shade Of Mine:
Danke für die Quelle die die Inkompatibilitäten zwischen C+ und C erkärt.
Somit ist definitiv nicht jeds C-Programm mehr mit einem C++ Compiler kopilierbar

@volkard 00:34 Sorry ich hatte wirklich die 3 Punkte vergessen die das anzeigen sollten,
@volkard: Schau mal so geht das.

Mein Beitrag 31.07.53
Aufräumarbeiten sind nicht nur Dinge die durch Destruktoren erledigt werden können, es können auch
längere CodeSequencen sein, die sich mit ganz anderen Dingen beschäftigen (siehe Hardwarenahe Programmierung, Schnittstellen unminitialiseren so daß ich gar keine Destructor brauche) .
Diese Teile von Code könnte man auch unmittelbar ins if schreiben, was aber die Lesbarkeit nicht unbedingt fördert.

- Durch einen Destruktor wird doch eine Objekt doch zerstört. Ist das sachlich richtig.
Wenn ich also ein Objekt einmal habe und wende den Destruktor einmal an ist das Objekt zerstört.

- Ich habe also zum Bespiel ein Objekt. welches mir die Kommunication mit einem RS232 Port ( COM-Port) ermöglicht.
Beim Erzeugen des Objekts wird eine Verbindung zum COM-Port mit der default Baudrate hergestellt die Input und Outputbuffer
geflusht so das ich einen sauberen Port vorfinde. An diesen COM-Port ist ein externes Gerät mit einer Spannungsversorgung angeschlossen
die aus dem Programm gesteuert wird.

Wenn ich jetzt in einer jetzt uns ja allen allgemein bekannten Schleife in der Kommunikation einen Fehler finde
möchte ich die Schleife beenden den Fehler melden, und korrektive Aktionen starten.

Wenn ich dann deinen Vorschlag aufgreife den Destruktor aufzurufen um aufzuräumen, so würde IMHO ich typischer Weise hingehen
und auch den COM-Port schließen, denn ich vernichte ja das Objekt und es wäre falsch den COM-Port offenzulassen, weil ihn sonst ein neues Objekt nicht mehr bekommen kann.
Eine weitere Folge des KommunikationsFehlers ist, das ich eine Spannungsversorgung aus und wieder einschlten muss. Du willst doch nicht behaupten das sinnvoll ist in einem Objekt das Kommunikation macht, in dessen Destruktor eine Spannungsversorgung für ein Gerät zu schalten. Das Kommunikationsobjekt kann ja schließlich mehrfach für unterschiedliche Aufgaben eingesetzt werden.

Ich muss aber das Objekt behalten und kann es erst dann zerstören, natürlich mit einem Destruktor, wenn ich nicht mehr mit dem COM-Port arbeiten möchte.

Vielleicht verstehst du jetzt endlich das deine Destruktormethode mit Sicherheit in gewissen Zusammenhängen (dann wenn das Objekt vernichtet werden kann) die richtige und auch sinnvolle Lösung ist, das dieser Lösungsanstz wenn das Objekt erhalten bleiben muß falsch ist.

Vergleich bitte mal unsere beiden Definitionen von Aufräumen.

- Wieso ist die Aussage der Destruktor ist das Gegenstück zum Konstruktor eine Inhaltliche Aussage.
Der Ctor wird aufgerufen wenn das Objekt erzeugt wird, der Dtor wird gerufen wenn das Objekt zerstört wird.
d.h im Ctor sollten alle Aktionen enthalten sein um das Objekt sicher ins Leben zu bringen und im Dtor sollten
alle Aktionen seine die sicherstellen das das Objekt sauber zerstört wird.
Was ist daran falsch?

Es ist schade das du wenn die die Argumente ausgehen oder die Beispiele fehlen persönlich wirst.

Wenn ich sehe das jemand etwas nicht vesteht, versuche ichs auf eine andere Art zu erklären und ziehe mich nicht schmollend zurück, da es jemand wagt meine Genialität anzuzweifeln

Das Wort falsch ist eine Aussage aber kein Argument.

Der Text falsch, weil ... ist viel besser.

Wenn in diesem Thread Sachen widerlegt wurden, hatten die Authoren meistens einen anderen Namen.

volkard

PAD schrieb:

- Wieso ist die Aussage der Destruktor ist das Gegenstück zum Konstruktor eine Inhaltliche Aussage.
Der Ctor wird aufgerufen wenn das Objekt erzeugt wird, der Dtor wird gerufen wenn das Objekt zerstört wird.
d.h im Ctor sollten alle Aktionen enthalten sein um das Objekt sicher ins Leben zu bringen und im Dtor sollten
alle Aktionen seine die sicherstellen das das Objekt sauber zerstört wird.
Was ist daran falsch?

beispiel:

class Foo
{
   int* a;
   auto_ptr<int> b;
   public:
   Foo()
   {
      cout<<"Foo angelegt!"<<endl;
   }
   Foo(int s)
   :a(new int[s])
   {
   }
   Foo(auto_ptr<int> c)
   :b(c)
   {
   }
};

so, und hier sage mir doch mal, wie der destruktor aussehen muß, wenn er "das gegenteil" des destruktors ist. falls das nicht geht, ist deine desfinition falsch, oder?

volkard

PAD schrieb:

- Ich habe also zum Bespiel ein Objekt. welches mir die Kommunication mit einem RS232 Port ( COM-Port) ermöglicht.
Beim Erzeugen des Objekts wird eine Verbindung zum COM-Port mit der default Baudrate hergestellt die Input und Outputbuffer
geflusht so das ich einen sauberen Port vorfinde. An diesen COM-Port ist ein externes Gerät mit einer Spannungsversorgung angeschlossen
die aus dem Programm gesteuert wird.

Wenn ich jetzt in einer jetzt uns ja allen allgemein bekannten Schleife in der Kommunikation einen Fehler finde möchte ich die Schleife beenden den Fehler melden, und korrektive Aktionen starten.

Wenn ich dann deinen Vorschlag aufgreife den Destruktor aufzurufen um aufzuräumen, so würde IMHO ich typischer Weise hingehen
und auch den COM-Port schließen, denn ich vernichte ja das Objekt und es wäre falsch den COM-Port offenzulassen, weil ihn sonst ein neues Objekt nicht mehr bekommen kann.

ok, soweit einverstanden.

Eine weitere Folge des KommunikationsFehlers ist, das ich eine Spannungsversorgung aus und wieder einschlten muss. Du willst doch nicht behaupten das sinnvoll ist in einem Objekt das Kommunikation macht, in dessen Destruktor eine Spannungsversorgung für ein Gerät zu schalten. Das Kommunikationsobjekt kann ja schließlich mehrfach für unterschiedliche Aufgaben eingesetzt werden.

was stört dich daran, für jede unterschiedliche aufgabe ein eigenes zu nehmen?

Ich muss aber das Objekt behalten und kann es erst dann zerstören, natürlich mit einem Destruktor, wenn ich nicht mehr mit dem COM-Port arbeiten möchte.

also erst am ende des gesamten programms? das würde nicht mehr der forderung entsprechen, objekte so lokal wie möglich zu machen.

Vielleicht verstehst du jetzt endlich das deine Destruktormethode mit Sicherheit in gewissen Zusammenhängen (dann wenn das Objekt vernichtet werden kann) die richtige und auch sinnvolle Lösung ist, das dieser Lösungsanstz wenn das Objekt erhalten bleiben muß falsch ist.

nein. man kann sehr schön auch objekte bauen, wie bis zum programmende leben.

kenne nicht alle datend des programms, das du dir vorstellst. aber man kriegt stets die gewnschten aufräumarbeiten in nen passenden destruktor rein.
vielleicht ist hier gemeint, daß man ein RS232-Objekt in der main() anlegt, wo es bis programmende lebt, um sich das reinitialisieren der schnittstelle zu sparen. und die konkreten Geräte, deren Stromversorgung man anmacht und ausmacht, halt lokaler.
eventuell ist dein feler, daß du nicht genügend unterschiedliche objekte anlegst. ist das der fall?

Daniel E.

PAD schrieb:

Laut Definition ist der Destruktor das Gegenstück zum Konstruktor

definitiv falsch

Das Stoustrup was falsches schreibt wundert mich Gleiche Quelle Kapitel 10.4.1

Einen Satz, der behauptet was zitiert wurde, kann ich in §10.4.1 nicht finden.

Wenn ich im Stoustrup mir Kapitel E.2 anschaue erfüllt mein C Code die Bedingung die exceptionsicherheit gestellt wird ohne c++ zu benutzen.

Das ist eine Nullaussage. Exceptions sind ein Sprachmittel in C++, das in C nicht existiert. Folglich kann man in C keinen ausnahmefesten Code schreiben -- oder wenigstens ist es komplett sinnlos,weil C keine "Ausnahmen" kennt.

Durch einen Destruktor wird doch eine Objekt doch zerstört. Ist das sachlich richtig.

Nein, der Destruktor wird aufgerufen, wenn das Objekt zerstört wird.

Wenn ich also ein Objekt einmal habe und wende den Destruktor einmal an ist das Objekt zerstört.

IdR wendet man keine Destruktoren an. Das geht meistens wunderbar implizit.

Vielleicht verstehst du jetzt endlich das deine Destruktormethode mit Sicherheit in gewissen Zusammenhängen (dann wenn das Objekt vernichtet werden kann) die richtige und auch sinnvolle Lösung ist, das dieser Lösungsanstz wenn das Objekt erhalten bleiben muß falsch ist.

Es ist eine allgemein anerkannte Methode, genannt RAII. Bei richtigem Design und genug kleinen Objekten würde das auch mit deinem Beispiel funktionieren wobei mir Kommunikation mittels Objekten in C++ immer noch etwas abenteuerlich vorkommt ...

Wieso ist die Aussage der Destruktor ist das Gegenstück zum Konstruktor eine Inhaltliche Aussage.

War das eine Frage? Wir sind hier in einem technischen Forum, da ist im Zweifel alles eine inhaltliche Aussage. Zum Brabbeln von inhaltsleerem Widersinn gibt es das Offtopic-Forum.

Der Ctor wird aufgerufen wenn das Objekt erzeugt wird, der Dtor wird gerufen wenn das Objekt zerstört wird.
d.h im Ctor sollten alle Aktionen enthalten sein um das Objekt sicher ins Leben zu bringen und im Dtor sollten
alle Aktionen seine die sicherstellen das das Objekt sauber zerstört wird.
Was ist daran falsch?

Nichts?
Das hat aber mit dem Satz von oben ('Ein Destruktor zerstört ein Objekt') nicht zu tun. Man kann auch einen seichten Widerspruch erkennen (ein Zerstör-Aufruf-Problem, also das logische C++-Äquivalent zum Henne-Ei-Problem).

junix

Nachdem ich nun PAD habe hängen lassen, weil mir
a) die Zeit gefehlt hat, hier intensiv teilzunehmen
b) er ja bezüglich des breaks eine ähnliche Argumentations aufgebaut hat wie ich sie hätte,
melde ich mich mal wieder zurück.

volkard schrieb:

eventuell ist dein feler, daß du nicht genügend unterschiedliche objekte anlegst. ist das der fall?

Nehmen wir folgende Situation: Target und Host haben eine Bidirektionale, asynchrone Kommunikation (ja, sie, sowas gibts)

Ich kann hier also unmöglich jedes mal, wenn ch schreiben will, eine Objekt erzeugen, das auf den Com-Port zugreift, da ich ja sonst allfällig ankommende Events vom Target verpassen würde.

Ausserdem macht es doch wenig sinn, jedesmal vor dem Senden wieder Performance und Rechenzeit dafür zu verschleudern, den Com-Port neu zu initialisieren, weil die Initialisierung ja mti der Zerstörung deiner jeweils lokalen Objekte wieder den Bach runter ging oder nicht? (Du bist doch hier der Geschwindigkeitsfanant?)

Da Events vom Target quasi "Interrupts" in meinem Programm darstellen können, macht es sinn, den Protokoll-Codec direkt auf die Com-Klasse zu setzten, denn da für die Kommunikation sowieso immer das Protokoll verwendet werden muss, macht es wenig sinn, den Com-Port direkt für andere sichtbar zu machen. (per Ableitung oder ob da nun der CoDec die Parent-Klasse des Com-Ports ist, sei dahingestellt).

Nun möchte ich aber, dass Kommunikationsfehler und Protokollfehler selbsständig vom CoDec behandeln lassen... Macht es nun sinn, dass ich einfach aus gewissen Funktionen rausspringe, nach dem Destruktor schreie um aufzuräumen und alles zurückzusetzen und damit auch gleich die Objekte sauber zerstöre? wohl kaum oder?

-junix

PAD

Danke jetzt wird das Ganze wieder richtig interessant.

@Volkhard dein Text von 11:11 da muß ich noch ein bisschen kauen. Vermutlich meinen wir was unterschiedliches mit
dem Begriff Gegenstück.

@Volkhard dein Text von 11:22 Erst mal banal eine andere Erfahrungswelt als deine, wenn du die Texte von junix
mit einbeziehst bekommst du vielleicht ein Bild von den unterschiedlichen Environments.

Zu deiner Beruhigung, dieses RS232-Programm ist kein konkretes Projekt. Es ist nur ein Hilfsgerüst für diese
Diskussion.

Im Rahmen dieses Beispiels hast du auch Recht mit der Aussage ich würde es erst am Ende des ganze Programms zerstören.(Aber eine unserer Regeln für die solche Abläufe ist. Solche Verbindungen leben so lange wie nötig und so kurz wie möglich.). Das heißt deine sinnvolle Forderung der hohen Localität gehen wir auch nach.

Wenn ich dich richtige verstehe würdest du nicht die gesamte Kommunikation mit dem Comport als Objekt verstehen,
sondern wahrscheinlich den COMPort als ein Objekt und einzelne Kommunicationen über den COMPort als eigenständige Objekte die das Objekt COMPort nutzen, d.h, Du würdest die Objekte sehr fein granular anlegen.

Das muß ich noch ein bißchen gären lassen, ist für mich ein bisschen ungewohnt.

um sich das reinitialisieren der schnittstelle zu sparen.

wenn das schnell geht ist das ok jedesmal zu reinitialisieren,
wenn dieser ReInit Process länger dauert als die eigentliche Arbeit stört er
den Gesamtablauf und verlängert die Testzeiten in einem nicht tolerierbarn Mass.

PAD

@Daniel E

Zitat 1:
Man erreicht dies durch die Bereitstellung einer speziellen Funktion, die den Konstruktor komplementiert

Zitat 2: Der erste Abschnitt definiert was Ausnahmefestigkeit bedeuted. Ein beliebiges Stück SW kann A-fest sein
wenn es diese Bedingungen erfüllt. Das C++ sinnvollerweise formalisierte Methoden bereitstellt ist ein Vorteil dieser Sprache. Aber Object Orientiert Programmieren kann man auch in Assembler und auch solche sinnvolen Konzepte Verwirklichen.

Zitat 3: Ist das nicht das Henne Ei Problem. Ich hatte nicht gesagt das ich den Dtor explizit aufrufe. Aber es ist doch immer noch so das der Code im Dtor dazu führt das das objekt korrekt vernichtetd wird.

Zitat 4: siehe 3

Zitat 5: Warum wenn ich Volkard richtig verstehe ist das eine zulässige Methode

Zitat 6:

der standard definiert. in ddaß man den ctor nicht als gegenteil vom dtoe definiert, ist ja wohl sonnenklar. das wäre nämlich ne inhaltliche geschichte. das paßt nicht. man definiert nur, was wann zu passieren hat. nicht was was bedeuten soll.

Das ist glaub ich eine Kommunicationsproblem zwischen Volkard unt mir. Mit Gegenstück meine ich nur, das sowie der Ctor impliziet beim erzeugen eines Objekts aufgerufen wird, wird der Dtor beim zerstören aufgerufen.
Natürlich darf eine Sprachdefinition in diesem Sinne keine Inhalte definieren.

letztes Zitat 7: Ich glaube das ist in diesem Fall eine reines Sprechweisenproblem was schon mit 3 und 4 abgedeckt ist.

Shade Of Mine

junix schrieb:

Nehmen wir folgende Situation: Target und Host haben eine Bidirektionale, asynchrone Kommunikation (ja, sie, sowas gibts)

Ich kann hier also unmöglich jedes mal, wenn ch schreiben will, eine Objekt erzeugen, das auf den Com-Port zugreift, da ich ja sonst allfällig ankommende Events vom Target verpassen würde.

Ausserdem macht es doch wenig sinn, jedesmal vor dem Senden wieder Performance und Rechenzeit dafür zu verschleudern, den Com-Port neu zu initialisieren, weil die Initialisierung ja mti der Zerstörung deiner jeweils lokalen Objekte wieder den Bach runter ging oder nicht? (Du bist doch hier der Geschwindigkeitsfanant?)

warum solltest du das objekt dann immer zerstoeren wollen??
ein Objekt das eine Verbindung zum COM Port aufbaut, sieht mir nicht so aus, als ob es lokal in eine kleine Senden funktion gehoert...

angenommen du hast einen main loop - in dem passiert der verbindungsfehler und eine exception fliegt.
dann kann man ja die exception fangen, und darauf reagieren -> zB den main loop neu starten mit einem reinitalisierten objekt, oder einfach nur mit ein paar sekunden warte zeit eine neue verbindung aufbauen, oder sonstwas.

du hast ja selber die kontrolle was du machst - eine exception bedeutet ja nicht, dass das objekt dann auch tot sein muss.

Nun möchte ich aber, dass Kommunikationsfehler und Protokollfehler selbsständig vom CoDec behandeln lassen... Macht es nun sinn, dass ich einfach aus gewissen Funktionen rausspringe, nach dem Destruktor schreie um aufzuräumen und alles zurückzusetzen und damit auch gleich die Objekte sauber zerstöre? wohl kaum oder?

nein, das macht keinen sinn.
das musst du aber auch nicht tun.

du faengst die exception dort, wo du sie behandeln willst. also in deinem fall faengst du in der protokoll klasse.

PAD schrieb:

Im Rahmen dieses Beispiels hast du auch Recht mit der Aussage ich würde es erst am Ende des ganze Programms zerstören.(Aber eine unserer Regeln für die solche Abläufe ist. Solche Verbindungen leben so lange wie nötig und so kurz wie möglich.). Das heißt deine sinnvolle Forderung der hohen Localität gehen wir auch nach.

wenn das objekt am ende zerstoert wird, legt man es auch nicht lokal in einer funktion an - das wuerde selbst ohne exceptions nicht gehen.

wenn das schnell geht ist das ok jedesmal zu reinitialisieren,
wenn dieser ReInit Process länger dauert als die eigentliche Arbeit stört er
den Gesamtablauf und verlängert die Testzeiten in einem nicht tolerierbarn Mass.

warum immer reinitialisieren?
warum denkt ihr, dass eine exception immer alles killt?
wenn du RAII richtig verwendest, dann stirbt immer nur die resource, die auch sterben muss.
bsp:

void foo(COM& com)
{
  Sender s(com); //sender wird an COM gebunden um daten zu verschicken

  s.send(irgendwas); // hier fliegt ne exception
} //baeng! Sender ist tot und COM lebt

void bar()
{
  COM com;
  for(;;)
  {
    try
    {
      foo(com);
    }
    catch(LightExeption& e) //kleiner fehler
    {
      com.check_state(); //wenn check_state ne exception wirft, kann man nix mehr
      //machen - verbindung Tot, wenn nicht, dann passt alles.
    }
  }
}

void foobar()
{
  bar();
  }
  catch(HeavyException& e)
  {
    //nix zu machen, alles tot
  }
}

wie wuerde das in C aussehen?

int foo(COM* com)
{
  Sender* s=bind(com); //sender wird an COM gebunden um daten zu verschicken

  return send(s,irgendwas);
} //baeng! Sender ist tot und COM lebt

void bar()
{
  COM com;
  for(;;)
  {
    int error=foo(&com);
    if(error==7)
    {
      if(check_state(&com))
        return 9;
    }
  }
}

void foobar()
{
  int error=bar();
  if(error==9)
  {
    //alles tot
  }
}

wo ist der unterschied?
vielleicht bin ich bloed, aber ich sehe echt nicht, wie sich exceptions anders verhalten, als diese fehlercodes (von den vorteilen von exceptions mal abgesehen)

Daniel E.

PAD schrieb:

Zitat 1:
Man erreicht dies durch die Bereitstellung einer speziellen Funktion, die den Konstruktor komplementiert

Dort geht es um das spezielle Beispiel der 'Tabelle'.

Zitat 2: Der erste Abschnitt definiert was Ausnahmefestigkeit bedeuted.

Das ist eine sehr interessante Auslegung des ersten Absatzes von $E.2. Bei mir schreibt Stroustrup da ständig von Objekten. Das verwundert kaum, es geht in dem Kapitel schließlich um 'Ausnahmefestigkeit der Standardbibliothek'.

Ein beliebiges Stück SW kann A-fest sein

Ich verstehe nicht, wie Code in einer Sprache gegen etwas geschützt sein kann, was diese Sprache nicht unterstützt. Ich kann C-Code nicht gegen Exceptions schützen. Ich kann in so kugelsicher programmieren, dass keine Buffer Overflows etc pp drin sind, aber das ist nicht 'ausnahmensicher'.

volkard

PAD schrieb:

@Volkhard

das muß doch aufwand sein, meinen namen jedesmal falsch zu schreiben, statt copy&paste zu benutzen.

Killing me softly

sorry; hier stand Schwachsinn

junix

Shade Of Mine schrieb:

warum solltest du das objekt dann immer zerstoeren wollen??

Da ich nur knapp Zeit habe, nur eine knappe Antwort dazu: Volkard hat sich in einem der oberen Postings so geäussert als würde er das Objekt Com-Port jedesmal aufs Neue zerstören (oder ich hab ihn falsch verstanden).

Auf den Rest komm ich vermutlich frühestens morgen früh so um 5Uhr zurück... ich muss jetzt noch einige Vorbereitungen treffen und dann arbeiten gehen (o: Sorry.

-junix

Shade Of Mine

junix schrieb:

Volkard hat sich in einem der oberen Postings so geäussert als würde er das Objekt Com-Port jedesmal aufs Neue zerstören (oder ich hab ihn falsch verstanden).

kannst du die relevante stelle mal zitieren?
ich sehs nämlich nicht.

btw: fahrt euch nicht so auf ein text beispiel fest.

gebt mal ein beispiel wo man keine exceptions verwenden kann.
(sowas habe ich nämlich noch nie erlebt und auch noch ne darüber gelesen)

PAD

@Shade Of Mine 14:03

Du bist da in einem Diskurs mit volkard mitten rein gesprungen. Volkard ist unheimlich scharf auf den Dtor und sowohl junix als auch ich haben versucht klar zu machen das nicht unter allen Umständen ein Dtor das Mittel der Wahl ist

Auch dein Einwurf

ein Objekt das eine Verbindung zum COM Port aufbaut, sieht mir nicht so aus, als ob es lokal in eine kleine Senden funktion gehoert...

gehört zu dieser Diskussion, wobei volkard die fein granulare Lösung vertritt.

Warum immer reintialisieren, bezieht sich auf des Dtor methode, mit der junix und ich auch unsere Schwierigkeit haben. Wenn ich ein Dtor benutze wie Volkard es vorschlägt wäre der COM-port und müßte beim neuen öffen nue initialisiert werden.

Ich sehe in deinen beiden Lösungen keine Unterschied in der Leistungsfähigkeit armer volkard
nur Unterschiede in der Methode der Implementierung.

Welche Implementierung besser ist, kann man nicht objektiv beurteilen, ist eher einer Frage welcher Philisophie und das im positiven Sinne gemeint man anhängt.

@Daniel E. Sorry Daniel bei mir ist das Kapitel überschrieben 10.4 Objekte 10.4.1 Destruktoren
Zitat am Ende des zweiten Abschnitts

Eine Interesante Auslegung: textuel hast du Recht. Aber neben der exakten Beschreibung des Konzepts in der Implementierung für C++ nutzt er doch eine sinnvolle allgemeine Definition. Diese Definition kann man ja sinnvoll auch andere Arbeitsbereiche übertragen. Un die zugrundeliegenden Ideen halte ich für sehr gut.

@volkard wollte weder dir noch deinem Namen leides tun, ich schreib aber schneller (erstens als denke und zweitens) als ich suchen und Copy-Past mache.

Daniel E.

PAD schrieb:

Sorry Daniel bei mir ist das Kapitel überschrieben 10.4 Objekte 10.4.1 Destruktoren

Ja, und? Bei mir ist §10 mit Klassen betietelt. Darum geht es nicht. Verwechselst Du das jetzt mit der Diskussion um §E.2? Dort geht es um ausnahmesichere Objekte, die es in C nicht gibt.

Zitat am Ende des zweiten Abschnitts

Da geht es bereits nicht mehr um die Definition, sondern um Anwendungsfälle, resp Beispiele. Ist das so schwer zu verstehen?

PAD

@Daniel E. Irgendwie stehe ich jetzt auf dem Schlauch

Der Ausgangspunkt war das Konstruktor und Destruktur Gegenstücke sind.
Der eine benutzt im Rahmen der Objekterzeugung der andere im Rahmen der Objektzerstörung

Dann bin doch mit der Quellenangabe genau richtig.

Daniel E.

PAD schrieb:

Der Ausgangspunkt war das Konstruktor und Destruktur Gegenstücke sind.

Das sind sie vielleicht auf 'Namensebene' und in Programmen werden sie manchmal so eingesetzt, dass der eine den anderen wieder aufhebt (Du zitierst Stroustrup bei einem Beispiel, wo das zufällig so ist). allerdings ist das eine sehr eigenartige Beziehung. Die Mutter, die ein Kind in einen 'benutzbaren' Zustand bringt, ist ja auch nicht das Gegenstück zum Totengräber, der dann 'aufräumt', oder?

PAD

@ Daniel E dein Vergleich ist einigermassen hart, aber ist es nicht genau so?

Deinen ersten Satz verstehe ich nicht. Ich beziehe mich nicht auf den Inhalt was in den beiden passiert, sondern auf die Funktionalität und den Zeitpunkt wo sie benutzt werden.

Der Dtor hebt nicht unbedingt das auf was der Ctor macht. Sehr oft wir das zwar so sein wie das delete zu einem new, aber sind auch in jedem von beiden ein Menge andere Aktionen denkbar und zulässig, die keine inverse Aktion im Gegenstück finden.

Der Ctor führt alle Aktionen durch die nötig sind um das Objekt zu gebären
Der Dtor führt alle Aktionen durch um das Objekt zu begraben

Um in deinem Beispiel zu bleiben.

Shade Of Mine

ich will mich nicht auf einen satz von volkard festlegen.

deshalb: wenn ihr einen code kennt, wo exception mit dtoren nicht funktionieren, dann zeigt es her.

ich weiss nicht genau was volkard gemeint hat, das ist aber auch egal: ein objekt kann nur dann sterben, wenn es den scope verlässt, egal ob mit exception oder ohne -> der scope wird verlassen, das objekt ist tot.