|
C++ constructor's - der Letzte macht das Liccht aus ?
Hallo,
Heute auch mal eine C++ Frage: - wird nach dem löschen (also delete) des letzten ctor's ein ExitProcess eingeleitet ? weil, ich habe eine DLL, in der ich einen ctor lösche, aber die aufrufende Funktion von Delphi hinaus, wird nicht mehr erreicht. von daher nehme ich an, das nach dem letzten ctor eine Exit-Routine eingeleitet wird... ?!? |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
Eine DLL wird explizit geladen und entladen. Welche Objekte du dort im Speicher hast, ändert daran nichts.
Die Beschreibung klingt eher so, dass die Aufrufkonvention nicht zusammenpasst (stdcall üblicherweise). Da du keinen Code gezeigt hast, lässt sich dazu nicht viel sagen. |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
ok, mein Fehler.
um den Fehler zu sehen, hier der .cc Code:  hier.wenn ich die letzten zwei Zeilen lösche, dann klappt der Aufruf, und die Funktion reicht durch. Der dtor wird aber aufgerufen (also die Funktion dtor_QChae). nur das Objekt wird ja nicht gelöscht, was aber passieren soll.Es gibt zwei NameSpace's: - 1 mal der von Qt5 (GUI Framework), und: - 1 mal der von qvc (mein Eigener) |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
Was passiert denn, wenn du von Delphi aus debuggst?
|
AW: C++ constructor's - der Letzte macht das Liccht aus ?
moin moin.
- als erstes hatte ich den Fehler 0xc00005 bekommen, was auf eine fehlende .dll zu schließen mag. - dann hatte ich von RELEASE auf DEBUG gestellt - der DEBUG Modus ergab, das die Funktion dtor_QChar sauber aufgerufen wurde, und danach die Funktion durchgereicht wurde also:
Delphi-Quellcode:
im Gegensatz zu dem DEBUG Mode:
destructor QChar.Destroy;
begin // wird im RELEASE Mode durchgereicht dtor_QChar(ptr_cc); // ab hier ist der RELEASE Mode auf einmal zu Ende ?? ... inherited Destroy; end;
Delphi-Quellcode:
Es scheint mir, das RELEASE und DEBUG Mode sehr sehr unterschiedliche Dinge machen.
destructor QChar.Destroy;
begin // wird im DEBUG Mode durchgereicht dtor_QChar(ptr_cc); // ab hier wird dann normal weiter gewerkelt ... inherited Destroy; end; Aber das ist doch sehr nahe an Voodoo-Programming ?? was sollte so speziell am DEBUG Mode sein ? das Instruction Set dürfte dabei doch nicht betroffen sein ? |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
sodele.
Es scheint zu funktionieren. Die Ausgabedatei im DEBUG Mode ist in etwa gleich groß der RELEASE Mode - mit der Ausnahme, das keine Meldung kommen wie 0xc007b oder 0xc0005. Das einzige was ich in der DCE 12 IDE Eingestellt habe, ist der DEBUG Mode, aber jetzt kommts: ohne Debug-Informationen übersetzt. Es sind also keine Debug-Informationen enthalten (jedenfalls ich kann keine finden). Von daher verstehe ich nicht, das der RELEASE so viel Ärger macht. Der DEBUG Mode ohne Debug-Informationen scheint ein anderes Format auszugeben als der RELEASE. very voodoo... Aber naja, es klappt jetzt erstmal das, was ich angestrebt habe. |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
Zitat:
Der DEBUG Modus bindet aber womöglich doch noch im Linker irgendwelche Debug-Libraries statisch mit ein, welche im RELEASE dann andere sind. Die Debug-Informationen beziehen sich ja erstmal nur auf die vom eigenen SourceCode kompilierte Files. |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
das ja richtig.
Aber ich erhalte, wenn ich mit BPL Packages linke, fast die selben Image-Größen - im RELEASE wie auch - im DEBUG und das sind für die gerade aktuelle Anwendung etwas über 320 KB an Daten. - die DLL änderte sich ja nicht, wärend meiner Test's. - die DLL und das 64-Bit DEBUG Image liegen im gleichen Verzeichnis, keine Probleme - die DLL und das 64-Bit RELEASE Image liegen im gleichen Verzeichnis, Probleme Die Probleme sind: - 1 mal 0xc0007 oder: - 1 mal 0xc0005 beides sind Windows NT (ich nehme mal an kernel32.dll) Sachen. Daraus schließe ich, das DCE 12 nur im DEBUG Sinn macht, und wer Luxus haben möchte, dann die Version höher kaufen soll, um dann kleineren Content zu erhalten, mit dem RELEASE Mode. Ist aber auch eine gute Strategie, um die Raubkopierer zu enttarnen: - hört, hier haben wir ein Image Eurer Anwendung... - schauen wir doch mal in den binary Salat, und suchen nach bestimmten Mustern, die nur die DEBUG hat - zack, aus die Maus, Maus trapped. Ich mein, das würde ich als großer Compiler-Anbieter ja auch so machen. Aber das sich darüber so ausgeschwiegen wird, naja... Sollen ja nicht Andere wissen. Ich hatte vor kurzen ein ähnliches Thema. Da ging es aber um den FPC. Der hatte da so ein paar kleine Features eingebaut, womit die Erzeugung einer Eigener system unit recht umständlich ging, wenn man nicht im Besitz dieser kleinen compilerproc Informations-Dinger ist/war. Das müssten die Entwickler aber auch schon wieder geändert haben, mit wiederum neuen Features. |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
Zitat:
|
AW: C++ constructor's - der Letzte macht das Liccht aus ?
Das Problem ist meistens, dass irgendwo noch eine (kompilierte) Unit liegt, die statt der verwendet wird, die du vermutest.
Das lässt sich mit Everything von Voidtools leicht prüfen. Das lässt sich auch leicht testen, indem du eine Fehlermeldung oder einen Fehler an der Stelle einbaust. Wenn der Fehler dann nicht auftritt, wird nicht der aktuelle Quelltext verwendet. Und was deine Theorien angeht: Bevor du so etwas äußerst, solltest du das ganze auch geprüft haben. Der generierte Code ist ja jederzeit einsehbar. |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
ich finde EMB eine gute Sache !
mit anderen Produkten aus der (fast) selben Sparte bin ich total aufgelaufen. Das war noch mit BORLAND und diverse Produkte. Von denen ich mehr oder minder, Eigene Implementierungen im Laufe der Zeit programmiert habe bzw. noch dabei bin - ist ja alles für Ein-Mann-Projekt(e) ein wenig anders, als wenn man sie professionell in oder für einer Firma programmiert. Mir ist damals nur aufgefallen, das vieles an die Wand gefahren wurde, nur das man das jeweilige Produkt loswerden wollte. Aber mit EMB und dessen Vorg#nger bin ich sehr zufrieden - aber wegen der Lisenz nicht mehr produktiv einsetzen kann. Früher war ich zugegeben auch ein Anwender in Holzbearbeitung... Aber dadurch, dass ich einen kleinen Obolus in Form einer kleinen Spemnde zahle, bekomme ich dann deutlich mehr Support und oder Features. Soll heißen: Damals habe ich die Programmierer der Programme nicht respektiert, und erst seit dem ich selbst Programme entwickle habe ich erkannt, das dies sich nicht nur um das eigentliche Produkt handelt, sondern, dass da auch andere Menschen oder auch Ich selbst davon abhängig sind... Für das andere Programm, mit dem ich meine Hilfeprojekte schreibe, ist die Lisenz auch nur für ein Jahr gültig. Gut, für das was man geboten bekommt lohnen sich für mich die 40 Euro auch dann, wenn ich das Authoring Tool nicht jeden Tag einsetze... Von daher kann ich nur jedem OpenSource/OpenSoftware Anwender raten, über eine kleine Spende nach- zudenken. Ich bin halt jemand, der testet gerne, bevor er kauft. Manchmal geht das natürlich tiefer als ein Anwender für ein Produkt machen würde. Ein Excel-Anwender wird nicht das Wissen haben wie ein Access-Anwender, wohlgleich beide Produkte für Büro-Anwendungen genutzt werden können. Bitte verzeiht mir, wenn ich dann so hartnäckig nachfrage... Aber vielleicht ist ja der Eine oder Andere auch auf ähnliche Fragen gestoßen, die man hier sehr schön diskutieren könnte, aber vielleicht aus firmenpolitischer Sichtweise nicht direkt was für die Masse ausbreitbares ist... Und das man ein kostenloses (nicht umsonst) Tool verwenden kann, mit dem man seine Programmier- künste erlernen und ausbauen kann, um dann später in einer Eigenen oder Anderen Firma mit der Erstellung von Programmen oder anderen Dienstleistungen beschäftigt zu sein, finde ich richtig respektabel. Ich würde sofort auf die Professional Edition wechseln, wenn ich dürfte bzw. könnte. Aber mein jetziger Arbeitgeber hat mir Verboten, Geld in der IT bzw. im Internet zu machen. Und wenn ich das machen würde, würde das dann von meinen jetzigen Status degradieren... Danke für's Lesen |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
Da kann man oft nur mit dem ProcessMonitor schauen, was von wo sich Delphi wirklich krallt.
Aber vielleicht hilft auch schon ( [F6] depend ) Projektoptionen > Erzeugen > Delphi-Compiler > Compileren > Weitere Optionen > Unit-Abhängigkeitsinformationen ausgeben siehe die *.d im EXE/DLL-Ausgabeverzeichnis, bzw. für BPLs neben deren *.DCP Dort steht dann drin, welche Packages (genauer welche *.DCP) genutzt wurden, falls mit Packages kompiliert, bzw. auch welche *.PAS *.DCU direkt gelinkt wurden (ob vorkompiliert oder neu kompiliert, sieht man wohl nur am Änderungsdatum der DCU) |
AW: C++ constructor's - der Letzte macht das Liccht aus ?
habt recht...
hab alles nochmals bereinigt... dann klappts auch mit dem Nachbarn, äehm, ausführen... fiffi komm ... put put put ... |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 08:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz