Klischeepunk

Nach lesen und Googlen zieh ich zurück Damit seh ich auch excps als mittel der Wahl. Ich bin etwas verwirrt, wieso ich Fest davon ausgegangen bin dass die Exception gelöscht wird.Thx für die Erläuterungen.

Wenn ich mich richtig erinner meckert bei Java netterweise auch der Compiler, wenn ich ne Exception nicht behandel, mein Compiler übersetzt folgendes allerdings Problemlos: main() { Klasse objekt; // bezeichner gültig, trotz exception objekt.test(); // keine Möglichkeit die Gültigkeit zu prüfen -> Absturz } Allein deswegen würd ich das Ding fertig erstellen lassen - oder mich an einer anderen Stelle darum kümmern. Wie gesagt, lieber einmal zu oft auf .IsValid() prüfen, einen zustand den ich im Konstruktor setzen könnte, anstatt auf gut Glück etwas zu tun. Im Falle Klasse *Objekt = NULL; Objekt = new Klasse(); sieht das anders aus, da kann ich brav NULL prüfen, aber da ich nicht immer auf'm Heap rumhampel und mich auch bei einem $Fremder nicht darauf verlassen will, dass er meine Fehlerbehandlungen korrekt übernimmt, würde ich lieber ein gültiges Objekt erstellen, das versucht die von $Fremder eingebauten Fehler vernünftig zu behandeln. In einer hypothetischen double CBruch::Divide(); Methode eben bspw. zu prüfen n == 0 und einen Ausnahmezustand zurückgeben, o.ä., allerdings einem anderen - soweit irgendwie möglich - nie die möglichkeit einräumen das Programm zu crashen. Oder eben wie gesagt: Factory her, wie ich meinen Konstruktor da behandel ist gänzlich mir überlassen und ich entscheide was $Fremder in die Hand bekommt.

Achja anmerkung noch: Wenn du für andere Libs, Frameworks oder was auch immer gestaltest - dann bau ne saubere Schnittstelle, die sich um das Objekt kümmert, dann muss dein gegenüber absolut nichts vom Objekt wissen und du gibst nur ein true/false zurück ob das ding korrekt erstellt wurde oder nicht (aus deiner Interfacemethode, NICHT dem Objektkonstruktor!) Dein "Nutzer" kann dann schlichtweg if(createObjekt(objBuf)) { /*Fange etwas damit an */ } machen und ist happy, oder wegen mir auch Objekt *objBuf = NULL; objBuf = createObjekt(z, n); if(objBuf != NULL) {/***** you dolphin and whale*/} Objekt *createObjekt(int z, int n) { /*Ausnahme Abfangen*/ if(n == 0) { return NULL; } /* ... */ } Irgendetwas in die Richtung. Wichtig ist nicht ob ich ne Zeile mehr oder weniger tippen muss, sondern ob ich was vernünftiges aus deiner "BlackBox" zurück erhalte. Und vernünftig bedeutet etwas,das entweder Gültig ist und im Fehlerfall auch Fehler wirft, oder etwas dem ich ansehe dass irgendwas gründlich schief gegangen ist.

@Schlitzauge nur interesse halber: Sicher das dein Code funktioniert? Imho landest du da wunderbar im Nirvana, ein Überlauf von long double über LDBL_MAX dürfte bei LDBL_MIN landen und damit völlig valide sein. Überläufe kannst du hier nicht abfangen, dies müsste früher geschehen (eingabe?) - Hatte aber keine lust das ding zu compilieren oder zu googlen. Und für den fall, dass eben genau diese Prüfungen nichts bringen, hätte es ein "(long double)var" ebenso getan. Die genauigkeit lässt sich btw. deutlich eleganter in pow(10, iDecimals) ausdrücken und zu guter letzt 0.0 == 0.00000000 == 0. Also die Prüfung geht nach hinten los und der rest ist trivial. Was die Typen angeht, wenn ich sie noch richtig im Kopf hab: (f)loat, (L)ong double für Gleitpunktzahlen (l)ong, (u)nsigned und (u)nsigned (l)ong also (ul) für Ganze Zahlen.

An der Idee ein sinnloses Objekt freizugeben ist nichts krank, dies allerdings in einem Bereich zu tun, in dem das Objekt existiert und auf den Gerade zugegriffen wird, hat schon etwas krankes. Wenn ich in eine Funktion springe und ihr gleichzeitig den Speicher wegnehme, dann dürfte es mit recht hoher Wahrscheinlichkeit dazu führen, dass dir dein Stack mit Pauken und Trompeten um die Ohren fliegt. Nach ner Diskussion mit nem Kumpel außerdem noch: Eine Exception hat im Konstruktor nichts, aber auch gar nichts verloren. Der Konstruktor hat _immer_ korrekt zu terminieren. Logischerweise. Wir wollen unsere Variablen korrekt initialisieren und das Objekt Gültigkeit erlangen lassen. Sind nacher unerwarteterweise korrupte Daten drin, fangen wir das lieber in eine .IsValid()/.AssertValid() Methode ab, bauen uns Validitätsprüfungen an den Anfang der Methode oder aber, lassen das Objekt in ner Factory erstellen, wo wir bereits vor erstellen des Objektes die Validität der Übergebenen Parameter prüfen können. Hierzu: Factory method pattern Ansonsten würde ich flashpixx Aussage weiter verfolgen: Membermethode Exception werfen lassen, sollten wir unerwarteteerweise doch murks im Objekt stehen lassen und vllt im Konstruktor "Ausnahmenwerte" definieren. (bspw. Erwartete eingabe ist immer >= 0 wäre -1 eine Option eine Ausnahme zu kennzeichnen, seis nun "kein wert erhalten" oder "something has gone terribly wrong") . Zu guter letzt: Dein Objekt "gehört" immer jemand anders, nie sich selbst, von daher kann der Besitzer sich auch darum kümmern, dass er seinen Speicher wieder sauber hinterlässt. - Seis die Factory, die main() oder ein anderes Objekt oder auch nur Methode. Undefinierte Zustände sind jederzeit vermieden, also sollte es auch kein Problem darstellen das Objekt sauber zu zerstören. (erst danach beginnt undefiniertes verhalten )

Du wirst ihm halt wohl oder übel irgendwo die defines mitgeben müssen. Wie du das nun realisierst (einbinden einer Header, Compiler Flag, von hand #define WIN32 angeben, whatev) ist dir überlassen. Letztendlich muss dein Compiler wissen was er tun soll, sonst macht er Mist. Wie das bei deinem Compiler am komfortabelsten funktioniert sagt dir: Das Handbuch.

Sich selbst zerstören? Speicher einer Funktion zum Zeitpunkt der Lauftzeit (dieser Funtkion) wieder freizugeben? Halt ich jetzt nur sehr bedingt für nen Plan, dass man sich damit ins Knie schießt sollte eigentlich selbstverständlich sein. 4) Genau dieser Aufbau könnte relevant sein, vorallem da du von korrekt erzeugten/fehlerhaft erzeugten Objekten sprichst, Wenn im Konsturktor einfach nur ein "Zähler = z", "Nenner = n" ausgeführt werden ist das ding trotzdem völlig korrekt gebaut, die hypothetische Methode "CBruch::divide()" fliegt dir dann halt um die Ohren. Vom Korrekten Anlegen halber Objekte hab ich noch nicht gehört, entweder es klappt oder es klappt nicht. 0 oder 1. 5) Wann nicht? Ein Objekt kann noch so dynamisch sein, es ist trotzdem nur innerhalb seines Scopes gültig.

Rtfm.

1. if(z==0) throw Exception(); 2. try{/*whatev*/}catch(Exception e){objekt.~CBruch();}finally{/*whatev*/} 3. Ein kurzer Blick in die C++ ref hätte dir das btw. auch beantwortet. 4. Benenn deine Variablen Anständig und CBruch(int, int) ist keine Klasse, sondern maximal der Konstruktor. Die Klasse ist CBruch, wenn überhaupt. 5. Ich behaupte einfach mal ohne deinen Code zu kennen, deine Instanz der Klasse CBruch wird innerhalb einer Funktion erzeugt. Nach ablauf der Funktion ist es nicht mehr gültig und wird automatisch zerstört.

Klar, #ifdef XY #endif Deiner IDE teilst du mit welcher define für welches profil gesetzt wird. Voila. Bspw. #ifdef _MS_DOS_ oder #ifdef WIN32...

TIOBE Software: The Coding Standards Company Gibt Anhaltspunkte für die fundierte Auswahl

Das ist der Punkt weswegen ich auch nicht versteh wieso immer noch über Sprachen diskutiert wird. Die Sprache ist von deinem Betrieb, Einsatzbereich, persönlichen Vorlieben der Zuständigen, etc. abhängig, das vorgehen ist universal. Also: Irgendeine Sprache schnappen und Programmieren lernen.

Google Ich bin nicht deine Suchmaschine.

Jo SQL ist nicht schlecht wenn du mit Datenbanken zu tun hast... ^^ Es gibt für wohl jede Sprache den richtigen Anwendungsbereich. Von daher, wenn du nicht heut schon weisst woran genau du arbeiten wirst hör auf dir über Quatsch Gedanken zu machen. Wenn du Programmieren lernst, kannst du diese Prinzipien in so ziemlich jeder Sprache umsetzen. In der einen mit mehr, in der anderen mit Weniger aufwand, aber funktionieren tu'n die alle gleich. Syntax ist schnell gelernt. Solang du dir allerdings überlegst ob du nun SQL oder lieber Java lernst hast du wirklich andere Sorgen. Das erlernen von neuem als "Zeitverschwendung" zu sehen halte ich übrigens für sehr fraglich.

Word.