Ein Problem bleibt aber noch.
Ich wollte die Funktionnen und Klassen wie in Davids Buch nennen, also wie er halt 'tbFunktion'.
Aber bei Batzer2D wäre das ja bFunktion. Das kommt aber mit dem Bool-kürzel durcheinander
Warum hast du ein Kürzel für bool? Lies vielleicht einmal
diesen Post, dort habe ich gegen die UN argumentiert.
![;)](wcf/images/smilies/wink.png.pagespeed.ce.L9LRa_F2a5.png)
Und Namensräume würde ich unbedingt verwenden, für Präfixe spricht in C++ so gut wie gar nichts.
Solche Init/Exit-Methoden sind aber eigentlich gar nicht so schlimm!Viele Konzepte arbeiten mit solchen StartUp() und ShutDown() Funktionen.Ich verweise hier mal auf das Buch Game Engine Architecture und 3D Game Engine Design.Meiner Meinung nach , ist das aber auch eine Geschmacksfrage.
Es gibt bestimmt Anwendungsfälle, wo eine Initialisierung nicht direkt möglich ist oder erst später Sinn macht. Allerdings stellen diese Fälle meiner Ansicht nach eher die Ausnahme dar. Das Ziel beim Design einer Klasse sollte sein, eine Invariante zu erzwingen, sodass ein Objekt zu keiner Zeit einen ungültigen Status hat.
Das Problem ist auch bei Weitem nicht nur von theoretischer Natur. Der Verzicht auf Konstruktoren verkompliziert viele Dinge. Man darf weder const-Member, Referenzen, noch nicht defaultkonstruierbare Member/Basisklassen besitzen, da jene nur im Konstruktor initialisiert werden können. Dieses Vorgehen macht es erforderlich, die verwendeten Typen ebenfalls so zu gestalten, dass sie einen Defaultkonstruktor bereitstellen, der keine Initialisierung vornimmt. Im gesamten Anwendungscode werden zusätzliche Fallunterscheidungen notwendig, um zu prüfen, ob ein Objekt bereits initialisiert worden ist und gültig ist. Bei manuell aufzurufenden Aufräumfunktionen besteht die Gefahr von Memory Leaks, Exceptionsicherheit wird nicht gewährleistet. Grundsätzlich handelt man sich viele Probleme aus C ein, die in C++ nicht mehr bestehen.