DLL/Klassen/Funktionen
-
Was ist mit der __finally Erweiterung von Borland ? Funktioniert das in diesem Falle nicht ?
try {
pVersionInfo = new TCRVerInfo(Application->ExeName);
pCUPInfo = new TCRCPUInfo();}
__ finally {delete pVersionInfo;
delete pCUPInfo;
}
-
Hallo wegus,
dein Tip ist sicher nicht schlecht, doch so weit ich IcemanX verstanden habe tritt der Fehler beim löschen des Objektes auf. Dein Vorschlag würde nur dann die finally durchlaufen wenn beim Erzeugen ds Objektes ein Fehler aufgetreten wäre.Evi48
-
Ehrlich ? Dann habe ich das Konzept von __finally falsch verstanden ! Ich dachte im Gegensatz zu try/catch wird __finally auch ohne Fehler abgearbeitet. Muß ich wohl noch mal nachlesen...

-
Hallo,
Eine Instanz dieser Klasse sollte problemlos zu löschen sein. Ich vermute hier einfach mal, dass der Fehler zwischen den Aufrufen dieser beiden Funktionen liegt. Evtl. wird delete vorher schonmal aufgerufen. Ein Destruktor (nicht Dekonstruktor) ist hier ebenfalls nicht nötig.
Das Design dieser Klasse halte ich allerdings für fragwürdig (returns im Konstruktor u. ä.). Zu Abfragen der Versionsinformationen würde doch auch eine einfach Funktion reichen.@evi48
Ich weis, das der Code zur Abfrage aus diesem Link stammt, verstehe aber trotzdem diesen Aufwand nicht. Warum muss die Instanz dynamisch erzeugt werden? Ein einfaches Instanziieren (so wie VerInfo pVer;) reicht doch auch. Die Abfrage if(pVer != NULL) ist ebenfalls sinnlos. Wenn die Instanz nicht erzeugt werden konnte gibts eine Exception. Ein delete eines NULL-pointers gibt keinen Fehler. Warum das Ganze also?Ciao
-
wegus schrieb:
Ehrlich ? Dann habe ich das Konzept von __finally falsch verstanden ! Ich dachte im Gegensatz zu try/catch wird __finally auch ohne Fehler abgearbeitet. Muß ich wohl noch mal nachlesen...

Ja, du hast recht - finally wird immer durchlaufen. Du fängst aber nur die Fehler beim Erstellen ab. Obwohl aber gerade das delete überprüft werden soll. (Laut Evi48)
-
Hallo C++ Freunde,
ich möchte nicht von behaupten absolut fitt in C++ zu sein aber ich denke IcemanX geht es nur um den Destruktor seiner Klasse.IcemanX schrieb:
Klappt auch soweit ganz gut, ausser bei freigeben des Speichers bei den Klassen bekomme ich dann Speicherzugrifffehler.
Mit finally habe ich nachgelesen und hatte Unrecht doch löst es auch nicht das Problem.
Evi48
-
Hallo,
Leute da ich ich ja ne Diskusion in die Welt gerufen !!!!
Kann es sein das es ein Problem der Speicherverwaltung meiner DLL ist oder so.
Gebe gerne mal das Projekt weiter bei Interesse!!! (es lebe open source)

Da kann wer will mal die Klasse aus meinr im eigenen Projekt testen, ob das gleiche passiert !!!???!!!!
Gruß
IcemanX
-
Hallo,
haben noch eine Person mit dem gleichen Prob. gefunden,
siehe Beitrag ^16:13:27 18.11.2003 SilentSurfer^
[url]http://www.c-plusplus.net/forum/viewtopic.php?t=55626&highlight=dll+klassen+delete
[/url]dort steht aber auch keine Lösung!!!!!!!!!!!

-
Hallo
kannst du dein Projekt online stellen
(finden sich moeglicherweise einige die das dann checken)MfG
Klaus
-
-
hat schon wer nen Anhaltspunkt

-
kann ihm denn keiner helfen der ist bestimmt schon ganz frustriert

-
-
Hallo,
habe gerade von einem aufmerksamen User erfahren das viele gar keine *.rar Dateien öffnen können. Dachte eigentlich das sich RAR durch die grössere Leistung gegenüber ZIP schon mehr durchgesetzt hat .....

Vielen Dank an Hinterthuer Dieter für die Info

Hier der Link im ZIP Format:
-
Hallo Hinterthuer Dieter,
RAR haben wohl doch recht viele Leute,
habe mal auf meinem Webserver die Zugriffe geprüft und musste feststellen
das die *.rar bereits von 20 Leuten geladen wurde und die *.zip nur von 2 Leuten, wovon eine du sein wirst
Gruß
IcemanX--------------------------------------------------------------------------
HATT EINER DER 22 LEUTE SCHON NEUIGKEITEN FÜR MICH

-
Bin einer der 22... habs nicht gerafft.
Bleiben noch 21.
-
Plemplem schrieb:
Bin einer der 22... habs nicht gerafft.
Bleiben noch 21.
Bekommst du auch nen Speicherzugriffsfehler beim delete oder was ??????
Gruß
IcemanX
-
Es wäre sicher hilfreich, wenn du neben dem reinen DLL-Code auch ein lauffähiges (Minimal)Projekt mitliefern würdest, in dem die DLL geladen bzw. Klassen/Funktionen daraus verwendet werden.
-
Jansen schrieb:
Es wäre sicher hilfreich, wenn du neben dem reinen DLL-Code auch ein lauffähiges (Minimal)Projekt mitliefern würdest, in dem die DLL geladen bzw. Klassen/Funktionen daraus verwendet werden.
Einfach ein neues Projekt mit einem Fenster und 3 Buttons indem
CRLib.h und CRLib.lib eingebunden werden, dann noch im header folgenden Code:extern PACKAGE TCRVerInfo *pVersionInfo; extern PACKAGE TCRCPUInfo *pCUPInfo;------------------------------------------------------------------------------
Button1
pVersionInfo = new TCRVerInfo(Application->ExeName); pCUPInfo = new TCRCPUInfo();Button2
int iCPUUsage = pCUPInfo->getUsage(); char szCPUUsage[10]; strcpy(szCPUUsage, itoa(iCPUUsage, szCPUUsage, 10)); MessageBox(NULL, szCPUUsage, "", MB_OK); // Dazu muss *.exe resource Daten besitzen!!!!! //String sProductname = pVersionInfo->GetVerInfo(VI_PRODUCT_NAME); //MessageBox(NULL, sProductname.c_str(), "", MB_OK);Button3
//hier kommt der Fehler delete pVersionInfo; delete pCUPInfo;Gruß
IcemanX
-
IcemanX schrieb:
Fullqoute gelöscht.
--------------------------- Fehler --------------------------- Programm 'S:\SOURCE\Cescon\C\Test\Memwatch\1.00.0000\Memwatch.exe' kann nicht gefunden werden. --------------------------- OK ---------------------------Ich hab die Projektdatei geöffnen und F9 gedrückt... während dem Linken (oder schon beim Programmstart?) kommt die Meldung.(Ich sage doch, dass ich es nicht raffe! :p )
Edit:
Zitate bitte auf das Notwendigste beschränken. Danke!