Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
die Init Methode die kein Rückgabewert besitzt und protected ist
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »TrommlBomml« (01.12.2012, 16:52)
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »stef« (01.12.2012, 18:13)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Nein. Ganz und gar nicht. Das sind perfekte Beispiele dafür, dass es KEINE globalen Objekte sein sollten. Wie oft stellt man fest, dass man eben doch nicht nur eine DB-Verbindung braucht, sondern mehrere. Sorry, aber da hast Du ganz ganz schlechte Beispiele angeführt.Man denke zum Beispiel an ein MUTEX oder einen Datenbankconnect. Alles potentielle Kandidaten für globale Objekte.
NEIN! Dafür gibt es BREAK und CONTINUE. Ein Goto ist da die absolut falsche Lösung. Auch eine Variable ist da meist unnötig.Man denke an mehrfach verschachtelte Schleifen aus denen ich in bestimmten Situationen aussteigen will. Baue ich mir in jede Schleife eine Variable für den Abbruch ein oder springe ich mit goto direkt raus.
Das ist wohl definiert. Du solltest Dir dazu wohl die Definition des Standards oder ein gutes Buch zurate ziehen.Exceptions in Konstruktoren sind auch ein heißes Eisen. Wenn ich ein Objekt auf dem HEAP anlege und im Konstruktor
noch andere Daten mit new initialisiere und dann eine Exception werfe, wie verhält sich dann das System ?
Ist Speicher allokiert ? Ist er nicht allokiert ? Wird der Destruktor aufgerufen ? Ist der Zeiger auf das Objekt = NULL ? usw.
C++ ohne Exceptionhandling? Beispiel bitte. Das ist dann irgendwas, sowas wie C++ ohne Klassen: Alles, aber kein C++. Von daher muss dort eine ganz andere Lösung gewählt werden, als für C++ üblich ist. Ist ja wohl auch logisch. Davon reden wir hier aber nicht, wir reden hier von C++ mit Exceptions. Nur weil irgendwo irgendwer eins der wichtigsten Konzepte der Sprache nicht verfügbar hat, ist das kein Grund eine gute Praxis auszuschlagen auf all den Systemen, wo es funktioniert.Viele Embeded Systeme unterstützen C++ ohne Exceptionhandling, was dann ?
Meiner Meinung nach sollte ein Softwareentwickler nur eine Sache prinzipiell ablehnen: Paradigmen !
Pauschal die Behauptung aufzustellen das globale Variablen, goto usw. von Teufel sind halte ich für falsch.
Es gibt immer bestimmte Situationen in denen sowas verpöntes hilfreich sein kann.
Man denke zum Beispiel an ein MUTEX oder einen Datenbankconnect. Alles potentielle Kandidaten für globale Objekte.
Man denke an mehrfach verschachtelte Schleifen aus denen ich in bestimmten Situationen aussteigen will.
Baue ich mir in jede Schleife eine Variable für den Abbruch ein oder springe ich mit goto direkt raus.
Exceptions in Konstruktoren sind auch ein heißes Eisen. Wenn ich ein Objekt auf dem HEAP anlege und im Konstruktor
noch andere Daten mit new initialisiere und dann eine Exception werfe, wie verhält sich dann das System ?
Ist Speicher allokiert ? Ist er nicht allokiert ? Wird der Destruktor aufgerufen ? Ist der Zeiger auf das Objekt = NULL ? usw.
Viele Embeded Systeme unterstützen C++ ohne Exceptionhandling, was dann ?
Was ich damit sagen will ist: Software ist so vielseitig und komplex das man immer von Situation zu Situation entscheiden sollte.
Nein. Ganz und gar nicht. Das sind perfekte Beispiele dafür, dass es KEINE globalen Objekte sein sollten. Wie oft stellt man fest, dass man eben doch nicht nur eine DB-Verbindung braucht, sondern mehrere. Sorry, aber da hast Du ganz ganz schlechte Beispiele angeführt.
NEIN! Dafür gibt es BREAK und CONTINUE. Ein Goto ist da die absolut falsche Lösung. Auch eine Variable ist da meist unnötig.
Das ist wohl definiert. Du solltest Dir dazu wohl die Definition des Standards oder ein gutes Buch zurate ziehen.
C++ ohne Exceptionhandling? Beispiel bitte.
Du magst durchaus Recht haben, dass fast jedes Konzept irgendwo eine sinnvolle Verwendung finden kann. Deine Beispiele sind allerdings Paradebeispiele dafür, wo man sie NICHT verwenden sollte.
Du meintest Dogmen!?
Faustregeln sind nicht in Stein gemeißelte, universelle Gesetze, sondern Leitfäden für gute Praxis. Wer ihnen blind folgt ist nicht besser als wer sie ignoriert...
Oder du packst die innere Schleife in eine Funktion, was wohl sowieso angebracht wäre, da das Ding offenbar relativ komplexe Logik beinhaltet...
Dort kann man Exceptions dann eben nicht verwenden. Aber nur weil es tatsächlich Bereiche wie manche Embedded Systeme oder Teile eines Betriebssystemkernels gibt, wo Exceptions aus bestimmten Gründen keine Option sind, heißt das noch lange nicht, dass man Exceptions im Allgemeinen nicht verwenden sollte...
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »stef« (01.12.2012, 22:56)
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Was? Ich habe jetzt schon auf mehreren Embedded Systemen gearbeitet und mache das noch immer. Exceptions waren immer vorhanden, im jetzigen System läuft die Anwendung sogar unter Java. Soll nicht heißen, dass das überall so ist. Aber C und ASM ist heute wirklich nicht mehr oft anzutreffen. ASM schon echt gleich gar nicht.Also im Embeddedbereich wird wirklich kaum mit Excetions gearbeitet und auch andere "luxeriöse" Dinge einer Sprache fallen raus (begrenzte Rechenkapazitäten) allerdings ist das ein ganz anderes Teilgebiet und das kann man eigentlich kaum zum Vergleich heranziehn. Meistens wird in reinem C programmiert und das dann noch mit ASM Optimierung.
Interessante Diskussion übrigends.
Das machst Du vielleicht so. Das heißt aber nicht, dass das eine gute Praxis ist.Wenn ich versuche eine Exclusiv-Resource mit einem MUTEX / CriticalSection in 15 Threads zu schützen dann deklariere ich das Objekt global und mache es mit extern den jeweiligen Threadfunktionen zugänglich.
Nein. Aber für globale Variablen trifft das aber zu.Das Objekt mühevoll 15 Threads per Zeiger zu übergeben ist völlig unsinnig, zeitaufwändig und unübersichtlich.
Nein, falsch. Genau dafür gibt es Connection-Pools. Globale Variablen für Datenbankverbindungen in Threads sind so ziemlich die schlechteste Idee, die ich kenne.Das selbe gilt für Datenbankverbindungen wenn diese von allen Threads benutzt werden.
Nein. Goto ist unübersichtlich. Ist es schon immer gewesen. Wie dot schon sagte, deutet das eher darauf hin, dass Du einen zu langen Code hast, der sinnvoller in Funktionen aufgeteilt werden sollte. Genau das blockierst Du mit einem GOTO übrigens ganz schnell. ... Moment mal, reden wir hier ernsthaft darüber, ob man GOTO verwenden sollte? Ich meine... WHAT THE FUCK?Hier einen Konstrukt zu bauen das alle Schleifen ohne GOTO verlässt ist zeitaufwändig, mühevoll, unübersichtlich und oben drein noch fehleranfällig.
Da widerspreche ich auch nicht. Aber das Verhalten eines Konstruktors in welchem eine Exception geworfen wird, ist und bleibt wohldefiniert.C++ ist so komplex das es Massig Grauzonen und Ungereimtheiten gibt. (siehe http://www.comeaucomputing.com/iso/cwg_active.html)
Gut, dann geht das dort eben nicht. Das ändert aber nichts daran, dass man es dort benutzen sollte, wo es geht. Nur weil es in einem speziellen System nicht geht, heißt das noch lange nicht, dass man es überall anders auch so bescheiden lösen sollte.VERIX !!! Ein VeriFone Betriebssystem für Bezahlterminals. Unterstützt C++ mit STL und allem drum und dran. Nur keine Exceptions.
Mutex ist ein Paradebeispiel für eine statische Variable verwendet von schlechten Entwicklern. Es ist kein Paradebeispiel für eine globale Variable.Globale Objekte benutze ich genau da wo dieses Applikationsweit einmal existiert und von vielen Modulen benutzt wird. Da ist der MUTEX DASSS Paradebeispiel für !
Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von »BlueCobold« (01.12.2012, 23:05)
Das machst Du vielleicht so. Das heißt aber nicht, dass das eine gute Praxis ist.
Nein. Goto ist unübersichtlich. Ist es schon immer gewesen. Wie dot schon sagte, deutet das eher darauf hin, dass Du einen zu langen Code hast, der sinnvoller in Funktionen aufgeteilt werden sollte. Genau das blockierst Du mit einem GOTO übrigens ganz schnell. ... Moment mal, reden wir hier ernsthaft darüber, ob man GOTO verwenden sollte? Ich meine... WHAT THE FUCK?
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »stef« (02.12.2012, 00:10)
Das machst Du vielleicht so. Das heißt aber nicht, dass das eine gute Praxis ist.
Stell dir vor du schreibst eine Applikation in der mehrere Threads auf ein Gerät zugreifen das über RS232/COM1 am Hostrechner angeschlossen ist.
Die Threads öffnen ab und zu mal COM1 senden was raus und schließen COM1 wieder. Um zu verhindern das es beim öffnen von COM1 kracht schachtelst du die Zugriffe in eine CS.
Bei zwei Threads übergebe ich die CS vielleicht noch als Pointer an die Threads einzeln. Bei 30 Threads möchte ich den Entwickler sehen der die CS nicht global deklariert.
Nenne mir einen vernünftigen Grund die CS irgend wo zu verbergen und via Zeiger an alle Threads einzeln zu übergeben außer "Weil man es so macht ..." !
Werbeanzeige