for(;;) schleife verlassen

THE_FreaK

nein schrieb:

Jedes C-Programm ist auch ein C++ Programm

Nein

Na da bin ich ja mal auf die begründung gespannt ^^

volkard

PAD schrieb:

@volkard
Es ist halt so üblich das Kinder (C++) sagen alles was die Eltern (C) machen ist falsch. Das sind die Eltern auch gewöhnt.
Wenn ich mich recht erinnere steht im C++ Standard der Verweis das ihm der C Standard ein Basisdokument ist.

glaub ich nicht.

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

definitiv falsch.

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

definitiv falsch.

und wird aufgerufen wenn ein Objekt zerstört wird.
Was ist bitte wenn ich das Objekt erhalten möchte und trotzdem in die obigen Situationen kommen.

darum geht es nicht.

Deinen heisgeliebten Konstruktor kann man da ja wohl nicht verwenden.
Somit ist man bei einer break oder Flag Lösung.

natürlich kann man.

Thema Exceptions, wenn ich die von dir preferierte Methode nutze müßte es so aussehen

nonsense.

Für mich ist da kein Unterschied, außer das ich ein anderes Konzept angewendet habe.

du hast keine ahnung, was exceptionsicherheit bedeuten soll.

Der deutliche Unterschied zwischen uns ist das ich bereit bin, gleichzeitig verschiedene Konzepte anzuwenden (C,C++, ...) du aber scheinbar das Glück hast nur mit einem Konzept arbeiten zu können oder zu wollen.

der hauptunterschied ist, daß du noch nichtmal "effektiv c++ programmieren" gelesen und kapiert hast. das ist oberpeinlich, wenn man so redet, wie du.

ich will hier definitiv niemand etwas aufdrängen, sondern ich nutze Beispiel aus meiner Arbeit um anderen zu helfen

du hilfst damit aber keinem. im gegenteil. bitte stelle diesbezügliche aktivitäten ein, bist du "effektiv c++ programmieren" und am besten auch noch "exceptional c++" kapiert hast.

oder von anderen durch gut Argumente was zu lernen.

offensichtlich bist du lernbefreit.

Uberzeugen kann man mich gerne, Uberreden nicht.

nein, du bist nicht bereit, argumente, und seien sie noch so scharf ziehend, anzunehmen.

Noch ein ganz heißer Tip
Bjarne Stoustrup
Die C++ Programmiersprache
Addison Wesley
ISBN 3-8273-2058-5
4.Auflage

Lies dir Mal das Kapitel 6.1.5 durch was dort zum break geschrieben steht.

glaub mir, ich kenne die syntax der schleifen und von switch.

volkard

PAD schrieb:

Thema Exceptions, wenn ich die von dir preferierte Methode nutze müßte es so aussehen

func1(...) 
{ 
 //Auswerten überprüfen 
 try
 {
   for (a;b;c) 
   { 
    if (condition) 
     throw 33; 
   } 
 }
 catch (int CondNum)
 {
 return Condnum;
 }

 ..... 
 
 return PASS;
}

func1(...) 
{ 
//Auswerten überprüfen 
for (a;b;c) 
{ 
  if (error) 
   ErrorCode=33; 
   flag=FAIL; 
   break; 
} 
 if (PASS != flag) 
   return ErrorCode; 
.... 
return PASS; 
}

humbug.
wie fast immer ist die einfache version die gute. die folgende ist zu deinem müll funktional identisch:

func1(...) 
{ 
  for (a;b;c) 
    if (condition) 
     return 33; 
 ..... 
 return PASS;
}

es geht darum, zu erlauben, daß die funktionen, die man selber aufruft, exceptions werfen, und zwar wo sie wollen. und darum, nicht try/catch schreiben zu müssen, außer man will wirklich den fehler bearbeiten und nicht nur, um was aufzuräumen.

PAD

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

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

Nächste 2 Zitate, wenns dir nicht in de Kram passts wirds ignoriert Überzeugen nicht überreden wo ist das Beispiel

In dem Beispiel, falls ein Fehler drin ist zeigen, oder Bessere Lösung vorschlagen Nonsens ist geniale Hilfe

du hast keine ahnung, was exceptionsicherheit bedeuten soll.

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

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

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

lernbefreit: Was dich nicht wundern sollte, ich will überzeugt werden nicht überredet, und bisher keine sinnvollen Argumente deinerseits

Wer blind antwortet ohne den Text zu lesen, gibt die falschen Antworten.

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

PAD

@volkhard

Sorry du hast mit den Exceptions angefangen und du hast nicht begriffen das vor dem return noch weitere Aktionen waren
die ausgeführt werden sollten bevor die Funktion verlassen wird.

HumeSikkins

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

Und das sind genau die Sätze mit denen man sich disqualifziert. Selbst ein halbes Pfund Rindergehacktes ist dazu in der Lage das "definitv falsch" einzuordnen. Du aber überführst es mutwillig in den falschen Kontext.
Mit etwas gutem Willen kann man zwar sagen, dass C++ zusätzliche Möglichkeiten
gegenüber C bietet. Die Auusage "Jedes C-Programm ist auch ein C++ Programm" bleibt dadurch aber nach wie vor "definitv falsch".
Jedes heißt: Gegenbeweis durch Beispiel möglich:

#include <stdlib.h>
int main()
{
char* p = malloc(1);
free(p);
return 0;
}

Ups. Schon fertig. Gültiges C89/C99 nicht aber gültiges C++.

volkard

PAD schrieb:

@volkhard

faslch

PAD schrieb:

Sorry du hast mit den Exceptions angefangen und du hast nicht begriffen das vor dem return noch weitere Aktionen waren die ausgeführt werden sollten bevor die Funktion verlassen wird.

n dem code, den ich zuletzt umsetze, war das nicht der fall.
in anderen beispielen nante ich das, was for dem return noch passieren soll "aufräumen" und das ist aufgabe eines destruktor. dieses "aufräumen" muß nicht die speicherfreigabe sein. auch schließen von dateien, rellbacken von exceptions, ja sogar das miteilen an den benutzer, daß teilschritte geklappt haben, fällt alles dort rein.
vielleicht kapierste nun ein wenig mehr meiner argumente.

Shade Of Mine

nachtrag zu Humes Beitrag:
http://david.tribble.com/text/cdiffs.htm

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