GNU C++ - wie Speicherfehler abfangen ?

[paule32.jk]

Hallo,

- ich habe eine C++ Klasse im Namensraum (namespace) "qvc".
- ich habe eine gleich lautende Klasse QChar, die aber im Framework Qt5 untergebracht ist.
- die Qt5 QChar Klasse spreche per ::QChar an :

- die Klasse: qvc::QChar * foo = new qvc::QChar();
wird ohne Fehler erzeugt.
- im constructor von qvc::QChar erstelle ich eine Referenz zur Qt5 QChar Klasse:
mittels:

qvc::QChar() { origin_obj = new ::QChar(); }

- alles wird ohne Fehler oder Probleme erledigt.
- wenn ich jedoch dann im destructor das Objekt "origin_obj" löschen möchte, prüfe
ich vorher, das der Wert nicht einen nullpointer entspricht.
- wie zu erwarten ist, wird diese Auswertung mit True zurück geliefert und "delete"
versucht "origin_obj" zu löschen.
- aber genau hier bekomme ich einen Fehler, der aber nicht abgehandelt wird.
- ich habe versucht das ganze per try catch abzufangen, aber da passiert rein gar nichts.
- die std::wcout << L"...
wird nicht ausgegeben.
- wie kann man dann Speicherfehler abfangen, die in einer DLL passieren ?
- geht das nicht mit exception's ?
- wo liegt mein Fehler ?

Code:

namespace "qvc" {
class QChar {
private:
    ::QChar* origin_obj;
public:
    QChar();
    ~QChar();
...
};

qvc::QChar::~QChar(void)
{
    #ifdef DEBUG
    std::wcout << L"cpp: QChar: dtor..." << std::endl;
    #endif
    try {
        if (nullptr != origin_obj) {
            std::wcout << L"not null" << std::endl;
            delete origin_obj;
        }
    }
    catch (std::exception &e) {
        std::wcout << L"Exception: ";
        std::wcout << e.what() << std::endl;
    }
}
}

[HRolle]

Ich möchte an dieser Stelle daran erinnern, dass es sich hier um ein Delphi-Forum handelt. Fragen zu Qt können z.B. (nach vorheriger Anmeldung bei Qt) unter https://forum.qt.io/ diskutiert werden.

[Der schöne Günther]

Wir sehen hier ja nicht, was in deinem Konstruktor abgeht. Die ganze Sache hört sich doch eigentlich so an, als könnte man super ein nachstellbares Minimalbeispiel machen?

delete an sich wirft keine Exception, es sei denn, der Destruktor des Objekts wirft eine. Ich kenne mich mit Qt nicht aus, aber QChar scheint gar keinen zu haben. Damit hätte ich mir erklärt dass dein try..catch nicht greift, wenn das Ding halt dann was wirft, was sich nicht von std::exception ableitet.

Zieh das doch mal einer DLL raus, als standalone Anwendung und schau dir die Sache im Debugger an, dann muss man kein printf-Debuggung machen.

[jaenicke]

Zitat:

Zitat von HRolle (Beitrag 1539810)

Ich möchte an dieser Stelle daran erinnern, dass es sich hier um ein Delphi-Forum handelt.

Das hier ist aber der Unterbereich für andere Sprachen. ;-)

Zitat:

Zitat von Der schöne Günther (Beitrag 1539814)

Zieh das doch mal einer DLL raus, als standalone Anwendung und schau dir die Sache im Debugger an, dann muss man kein printf-Debuggung machen.

Man kann auch eine C++-DLL problemlos debuggen. Dafür gibt es viele Tools, unter anderem den C++-Builder, den es auch in einer Community Edition gibt.

Aber am einfachsten ist natürlich, das ganze ohne DLL zu debuggen, das stimmt. Wenn es dann noch das Problem gibt...

[paule32.jk]

- es geht nicht auschließlich um Qt5 an für sich.
- es geht darum, Objekte, die mit new erstellt wurden zu löschen - das ist unabhängig vom Framework und Aufgabe von C++
- einen kleinen Einblick kann man hier erhalten

der try catch Block wird garnicht angetastet.

[Kas Ob.]

@paule32.jk , You miss handling QChar https://doc.qt.io/qt-6/qchar.html

It is not class like all others with constructor and destructor, it is simple 2 bytes type with methods, something like WChar in pascal with record helper, or simply a managed record that have only WChar/Char.

No need to delete it, unless you will declare it as referenced (aka dynamic).

In other words, if origin_obj ( https://github.com/paule32/fpc-qt/bl...har.cc#L10-L16 ) is local field, then you don't need to delete and you can't delete.

[HRolle]

Zitat:

Zitat von jaenicke (Beitrag 1539815)

Zitat:

Zitat von HRolle (Beitrag 1539810)

Ich möchte an dieser Stelle daran erinnern, dass es sich hier um ein Delphi-Forum handelt.

Das hier ist aber der Unterbereich für andere Sprachen. ;-)

Sorry, ich habe nicht darauf geachtet, wo der Thread angesiedelt ist. Trotzdem bleibe ich dabei, dass diese Frage besser in das Qt-Forum passt.

[paule32.jk]

@Kas Ob.

it seem so.
But like I can see, that QChar is a class, with members like "bool isDigit()".
And me, when I have understand you, it should possible for C++ to "delete foo;", too.
When "foo" is not a Pointer (also when a Pointer to the class TuFoo exists:

auto * fifi = new TuFoo();

then you can delete it without problems.

I the simmilar same way, you can do: auto * fifi = new int;
which give you a "global" fifi reference, that over life the calling stack (it will also
accessible outside).

So, it should not be a Problem, that I i "free" the allocated memory (under 64-Bit there are
8 Bytes).

An other thing is it, if you use class references or integer references in the local scope
(without allocating static memory with "new").
So, class TuFoo fifi;
will automatically clean/free, if the callee function reach the Epilog.

[Kas Ob.]

QChar is 2 bytes structure supplied with methods and default constructor, yes there is a constructor but it is more filling with default value which is 0.

Now, look how you declared it, in your code there is no "*", it is local field and in-place, trying to delete it itself will not be possible.

Also see your example posted here against the one in the GitHub

Code:

namespace "qvc" {
class QChar {
private:
    ::QChar* origin_obj;
public:
    QChar();
    ~QChar();
...
};

qvc::QChar::~QChar(void)
{
    #ifdef DEBUG
    std::wcout << L"cpp: QChar: dtor..." << std::endl;
    #endif
    try {
        if (nullptr != origin_obj) {
            std::wcout << L"not null" << std::endl;
            delete origin_obj;
        }
    }
    catch (std::exception &e) {
        std::wcout << L"Exception: ";
        std::wcout << e.what() << std::endl;
    }
}
}

Code:

namespace qvc {

qvc::QChar::QChar(void      ) { origin_obj = new ::QChar( ); }
qvc::QChar::QChar(char     t) { origin_obj = new ::QChar(t); }
qvc::QChar::QChar(uint8_t  t) { origin_obj = new ::QChar(t); }
qvc::QChar::QChar(uint16_t t) { origin_obj = new ::QChar(t); }
qvc::QChar::QChar(uint32_t t) { origin_obj = new ::QChar(t); }
qvc::QChar::QChar(wchar_t  t) { origin_obj = new ::QChar(t); }
qvc::QChar::QChar(short    t) { origin_obj = new ::QChar(t); }
...

qvc::QChar::~QChar(void)
{
    #ifdef DEBUG
    std::wcout << L"cpp: QChar: dtor..." << std::endl;
    #endif
    try {
        if (nullptr != origin_obj) {
            std::wcout << L"not null" << std::endl;
            delete origin_obj;
        }
    }
    catch (std::exception &e) {
        std::wcout << L"Exception: ";
        std::wcout << e.what() << std::endl;
    }
}

See the difference ?

In all cases, QChar is 2 bytes and this is smaller and lighter than using dynamic one with extra pointer (either 32 or 64 bit, meaning 4 or 8 bytes) with overhead of allocating and deallocating, just slap it where ever you need to use, as static and in place then use it and don't free it, because it does not need to be free.

In other words use it as you use int or LONG .... the only difference is it will have initial value, and comes with methods, that is it.

[Kas Ob.]

Here found you this
https://cpp.hotexamples.com/examples...-examples.html

no constructor and no destructor !

[Phoenix]

Zitat:

Zitat von paule32.jk (Beitrag 1539805)

- wie kann man dann Speicherfehler abfangen, die in einer DLL passieren ?
- geht das nicht mit exception's ?
- wo liegt mein Fehler ?

- Eigentlich gar nicht.
- Nein.
- Du benutzt eine Memory-Unsichere Sprache :cyclops:

Ernst gemeinter Rat: Wenn Du Memory-Safe arbeiten willst, dann wirf C / C++ weg und schau Dir Rust an.
Das ist zwar in den ersten Tagen absoluter Brainfuck mit dem Speicherverwaltungskonzept, weil das so ungewohnt ist, aber wenn Du durch diese Hölle durch bist wirst Du nichts mehr anderes machen wollen.

Der Compiler kann dort nämlich statisch analysieren das alles was allokiert wird auch wieder freigegeben wird und Du nie auf Dinge zugreifst die unsicher sind.

Aber auch hier gilt, wenn Du fremde dll's Konsumierst die nicht in Rust geschrieben sind und die nicht gescheit mit dem Memory umgehen, dann ist das so. Speicherfehler in unsafe code (also alles was nicht in Rust gebaut ist) wirst Du damit mit erben. Aber Du kannst Dir wenigstens 100% sicher sein dass Dein eigener Code da garantiert keine Probleme hat.

[Der schöne Günther]

Kann dem nur zustimmen, die Arbeit mit Rust ist bislang einfach fantastisch. Mir geht es weniger um die "berühmten" Speicherfehler wie OpenSSL oder erst neulich Crowdstrike und "Mit Rust wäre das nicht passiert", allein was der Compiler/Linter mir erzählt, bis hin zum "Hey, benenn doch deine Methode so und so um, dann wird klarer, dass sie die Daten so und so verarbeitet". Währenddessen sagt Delphi dir noch nichtmal, wenn du in deinem Record mit nicht initialisierten Variablen arbeitest...