Seite 3 von 3
Verfasst: 14.02.2009 15:05
von X0r
Hm, stellt sich dann aber die Frage, warum im Smartwin++ Beispiel z.B. das hier steht:
Code: Alles auswählen
int SmartWinMain( Application & app )
{
HelloWinClass * testHello = new HelloWinClass;
testHello->initAndCreate();
return app.run();
}
Und wieso werden bei Windows Forms z.B. die ganzen gadgets dynamisch allokiert? Also muss man das doch machen, wenn die Objekte als Objekte der Klasse deklariert sind?
Also irgendwie bin ich jetzt etwas durcheinander.
Verfasst: 14.02.2009 15:28
von milan1612
Das kann viele Gründe haben, zum Einen braucht man sich in diesem Fall nicht
um die Freigabe bemühen da das Ganze automatisch gemacht wird (z.b.
beim Schließen des Hauptfensters). Zum anderen um eine einfache und
eingängige Übergabe einer Instanz zu gewährleisten was bei einem Window Framework
recht oft benötigt wird (z.b. bei Event Handlern).
Bei fremdem Code wirst du das recht häufig finden und da wirds auch Gründe geben
warum die Autoren das so gemacht haben. Bei eigenem Code hab ich da eine
Faustformel dafür: Wenns nicht unbedingt nötig ist, meide dynamischen Speicher.
Verfasst: 14.02.2009 15:44
von X0r
Und wie könnte es in meinem Code eventuell doch sinnvoll sein? Würde mich mal interessieren, damit ich weiß, wann ichs benutzen sollte.
Verfasst: 14.02.2009 16:02
von milan1612
Wie jetzt? Du benutzt den ifstream um eine Datei auszulesen. Das Ganze passiert
innerhalb einer Funktion. Das heißt du benötigst den ifstream nirgendwo anders
sondern nur lokal. Also gibt es keinerlei Grund ihn dynamisch zu allokieren.
Wenn du den ifstream in einer anderen Funktion brauchst die nur innerhalb der
Ersten Funktion aufgerufen wird kannst du den ifstream einfach per Pointer oder
besser per const reference übergeben und fertig.
So, jetzt stell dir mal eine Klasse vor die intern einen ifstream verwendet.
Selbst hier brauchst du keine dynamische Allokierung, denn du kannst den ifstream
innerhalb der Klasse statisch deklarieren. Wenn eine Instanz der Klasse out-of-scope
geht, dass heißt zerstört wird, wird auch dein ifstream zerstört.
Und jetzt stell dir mal eine DLL vor die einen ifstream-Wrapper für Purebasic
darstellt. Hier wäre eine dynamische Allokierung sinnvoll (solange man das Ganze
threadsafe programmieren will). Einfach mit 'new' erstellen, einen Pointer darauf
an Purebasic übergeben, den der PB Programmierer wiederum an alle anderen
Funktionen der DLL übergibt. Am Schluss eine Destroy-Funktion die den ifstream
wieder löscht.
Sorry, aber mehr Beispiele fallen mir jetzt nicht ein, ich hab nur in sehr seltenen
Fällen _wirklich_ dynamische Allokierung eines Objekt Types _benötigt_.
Meistens kann man es vermeiden...
Verfasst: 14.02.2009 16:46
von X0r
Hm, ja stimmt.
PBler habens echt gut.
Verfasst: 15.02.2009 20:02
von inc.
Fluid Byte hat geschrieben:[ot]
Welche IDE verwendest du eigentlich? Bin gerade dabei mir die Visual C++ Express Editon zu installieren. Was kostenlose IDE's angeht soll es angeblich die beste sein.
Hier zu finden:
http://www.microsoft.com/germany/Expres ... press.aspx
Ansonsten vielleicht noch Code::Blocks. Aber taugt die was?
[/ot]
Nimm direkt Code::Blocks in Verbindung mit dem MS Visual C++ 2003 Toolkit und der Platform SDK. Der Kompiler ist ebenso optimierend, aber macht NULL Probleme, wenn du mal für PB statische Libraries erstellen willst.
http://www.uploading.com/files/HNH73WB3 ... ).zip.html
Oder hier noch weitere Links:
http://www.google.de/search?hl=de&safe= ... tSetup.exe
http://forums.codeblocks.org/index.php/board,20.0.html
Mit VS 2005/2008 ist das dynamische Einbinden der C Runtime Library anders gelöst worden, ein gewöhnliches Linken mit der MSVCRT via PoLink reicht nicht mehr, es geht nur noch via statischem Linken und dem MS Linker ohne Probleme. Aber da bei PB Importen am Ende eben PoLink diesen Job erledigt, wirst du oder der Nutzer deiner Lib immer Runtime Errors bekommen.
Verfasst: 15.02.2009 20:59
von Fluid Byte
inc. hat geschrieben:Mit VS 2005/2008 ist das dynamische Einbinden der C Runtime Library anders gelöst worden, ein gewöhnliches Linken mit der MSVCRT via PoLink reicht nicht mehr, es geht nur noch via statischem Linken und dem MS Linker ohne Probleme. Aber da bei PB Importen am Ende eben PoLink diesen Job erledigt, wirst du oder der Nutzer deiner Lib immer Runtime Errors bekommen.
Danke für den Tipp. Hab mir jetzt CB und das Toolkit gezogen und installiere es gerade.
Verfasst: 15.02.2009 22:12
von edel
Du kannst auch VC 2008 nutzen, musst spaeter nur ein weiteres Manifest
und die Runtime Libs dazu linken. Also ausser der Manifest Datei aendert
sich da nichts. Falls dir die Abhaengikeit dann doch zu gross ist, kannst du
auch mit VC 2008 die alten Compiler nutzen. Musst nur die Verzeichnisse
aendern.