C++ constructor's - der Letzte macht das Liccht aus ?

[paule32.jk]

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... ?!?

[jaenicke]

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.

[paule32.jk]

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)

[jaenicke]

Was passiert denn, wenn du von Delphi aus debuggst?

[paule32.jk]

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:

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;

im Gegensatz zu dem DEBUG Mode:

Delphi-Quellcode:

destructor QChar.Destroy;
begin
  // wird im DEBUG Mode durchgereicht
  dtor_QChar(ptr_cc);
  // ab hier wird dann normal weiter gewerkelt
  ...
  inherited Destroy;
end;

Es scheint mir, das RELEASE und DEBUG Mode sehr sehr unterschiedliche Dinge machen.
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 ?

[paule32.jk]

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.

[Rollo62]

Zitat von paule32.jk:

Der DEBUG Mode ohne Debug-Informationen scheint ein anderes Format auszugeben als der RELEASE.
very voodoo...

TL;DR;

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.

[paule32.jk]

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.

[freimatz]

Zitat von paule32.jk:

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 bin alles andere als gute auf EMB zu spechen, aber bitte behalten deine Verschwörungstheorien für Dich.

[jaenicke]

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.