GUI-Bibliotheken | QTextEdit

[Padmak]

Ich hab mich vielleicht etwas missverständlich ausgedrückt, ich meinte mit dem wrappen vielmehr dass er sowas macht wie

std::unique_ptr<uint8_t> send_ptr(new uint8_t[packetlen]);
emit sendfunc(send_ptr);

Qt unterstützt die Pointer, sobald dann der letzte Slot durchgelaufen ist, wird der Speicher wieder freigegeben

Wenn er fastcall nutzen kann, kann er dann nicht auch thiscall benutzen, das ist noch angenehmer?
Der Hack geht aber glaube ich nur mit MSVC:

class dummy{
public:
    static void __thiscall hooked_func(){
        // yay
    }
};

Padmak

[Tasiro]

Originally Posted by MrSm!th

Wenn, dann könnte man zu einem weak_ptr greifen, wobei ich gerade nicht weiß, ob der ohne einen shared_ptr existieren kann.

Ein gewöhnlicher Zeiger ist da genau richtig. Ein std::weak_ptr lässt sich auch nur aus einem anderen std::weak_ptr oder einem std::shared_ptr erstellen.

[MrSm!th]

Originally Posted by Padmak

Ich hab mich vielleicht etwas missverständlich ausgedrückt, ich meinte mit dem wrappen vielmehr dass er sowas macht wie

std::unique_ptr send_ptr(new uint8_t[packetlen]);
emit sendfunc(send_ptr);

Qt unterstützt die Pointer, sobald dann der letzte Slot durchgelaufen ist, wird der Speicher wieder freigegeben

Ich habe dich schon verstanden. Dann sag mir mal, wo er damit ansetzen soll? Er erzeugt den String nicht selbst, er klaut ihn sich aus dem EDX Register. Er ist nicht für die Löschung verantwortlich und einen Smartpointer zu nutzen wäre fatal.

Außerdem leakt dein Code potenziell Speicher:
Smart Pointer nutzen delete und nicht delete[], du löschst also nicht alle Elemente.
Dafür müsstest du entweder einen Vector nutzen oder als Typ uint8_t[] verwenden.

Zudem ist ein explizites new potenziell Exception gefährdet.
Ich weiß nicht, ob MSVC bereits make_unique unterstützt, aber falls ja, nutze es!

Wenn er fastcall nutzen kann, kann er dann nicht auch thiscall benutzen, das ist noch angenehmer?
Der Hack geht aber glaube ich nur mit MSVC:

class dummy{
public:
    static void __thiscall hooked_func(){
        // yay
    }
};

Padmak

Ja.

[Tasiro]

Originally Posted by MrSm!th

Außerdem leakt dein Code potenziell Speicher:
Smart Pointer nutzen delete und nicht delete[], du löschst also nicht alle Elemente.
Dafür müsstest du entweder einen Vector nutzen oder als Typ uint8_t[] verwenden.

Das ist in der Tat undefiniertes Verhalten, aber das hat in der Form (in üblichen Implementierungen) kein Speicherleck zur Folge. Es wird bloß der Destuktor für alle Objekte außer dem ersten nicht aufgerufen. Das wiederum könnte ein Speicherleck produzieren.

Originally Posted by MrSm!th

Zudem ist ein explizites new potenziell Exception gefährdet.
Ich weiß nicht, ob MSVC bereits make_unique unterstützt, aber falls ja, nutze es!

Auch std::make_unique (welches von Visual C++ unterstützt wird) ist nicht ausnahmesicher. Nur hat die Verwendung von std::make_unique den Vorteil, dass dadurch Speicherlecks vermieden werden können (siehe ).

[MrSm!th]

Es wird bloß der Destuktor für alle Objekte außer dem ersten nicht aufgerufen. Das wiederum könnte ein Speicherleck produzieren.

So war es gemeint, sorry für die Formulierung ;O Stimmt, ist nur ein potenzielles Speicherleck.
Wobei es schon alleine durch den falschen delete Operator in manchen Implementierungen zum Crash kommt.

Auch std::make_unique (welches von Visual C++ unterstützt wird) ist nicht ausnahmesicher. Nur hat die Verwendung von std::make_unique den Vorteil, dass dadurch Speicherlecks vermieden werden können

Mit ausnahmesicher meinte ich nicht, dass aus der Funktion keine Exception herauskommt, sondern eben dass du in diesem Fall wenigstens keinen Speicher leakst (oder in anderen exotischen Fällen den Destruktor eines inexistenten Objekts aufrufst). Zumindest verstehe ich genau das unter ausnahmesicherer Programmierung.

[Tasiro]

Originally Posted by MrSm!th

Wobei es schon alleine durch den falschen delete Operator in manchen Implementierungen zum Crash kommt.

Interessant, hast du ein Beispiel? Clang und Intels Compiler konnte ich leider nicht testen, aber Microsofts und GCCs Resultat stürzt nicht ab.

Originally Posted by MrSm!th

Mit ausnahmesicher meinte ich nicht, dass aus der Funktion keine Exception herauskommt, sondern eben dass du in diesem Fall wenigstens keinen Speicher leakst (oder in anderen exotischen Fällen den Destruktor eines inexistenten Objekts aufrufst). Zumindest verstehe ich genau das unter ausnahmesicherer Programmierung.

"Ausnahmesicher" kam von mir, und da habe ich es falsch formuliert. Aber "ausnahmelos" klang auch irgendwie unpassend...
Wann tritt jener exotische Fall ein?

[MrSm!th]

Originally Posted by Tasiro

Interessant, hast du ein Beispiel? Clang und Intels Compiler konnte ich leider nicht testen, aber Microsofts und GCCs Resultat stürzt nicht ab.

Mein Fehler, habe das mit dem Fall verwechselt, dass du nicht die Startadresse an delete übergibst. Mit MSVC stürzt dir das Programm damit ab:

int *x = new int[2];
delete ++x;

"Ausnahmesicher" kam von mir, und da habe ich es falsch formuliert. Aber "ausnahmelos" klang auch irgendwie unpassend...

"Ausnahmelos" habe ich nie geschrieben.

Wann tritt jener exotische Fall ein?

Die Abarbeitung von Funktionsargumenten ist nicht das einzige, wo der Compiler Instructions umherschieben darf, wie er lustig ist.
Genauer gesagt schreibt die Sprachspezifikation grundsätzlich nur vor, dass beim Abarbeiten eines Ausdrucks alle weiteren Ausdrücke mit Seiteneffekten abgearbeitet sein müssen. Die meisten Anweisungen kann der Compiler aber parallelisieren oder anderweitig tauschen.
Beispielsweise könnte bei

unique_ptr<SomeClass> ptr(new SomeClass());

erst der Platz für SomeClass reserviert, dessen Adresse dem Smartpointer zugewiesen und dann der Konstruktor aufgerufen werden.
Schmeißt dieser eine Exception, dürfte der Destruktor laut Spezifikation nie ausgeführt werden, weil das Objekt nie existierte. Der Smartpointer wird dies aber tun. Im schlimmsten Fall schmeißt das einem ebenfalls wieder Exceptions um die Ohren, wenn der Destruktor auf einem Objekt mit undefiniertem Inhalt ausführt wird.

Diese Instructionschieberei macht insbesondere bei threadsicheren Singletons (Double-Checked-Locking) Probleme. Zumindest machte sie das, bevor es threadsichere Statics gab.

[Tasiro]

Originally Posted by MrSm!th

Die Abarbeitung von Funktionsargumenten ist nicht das einzige, wo der Compiler Instructions umherschieben darf, wie er lustig ist.
Genauer gesagt schreibt die Sprachspezifikation grundsätzlich nur vor, dass beim Abarbeiten eines Ausdrucks alle weiteren Ausdrücke mit Seiteneffekten abgearbeitet sein müssen. Die meisten Anweisungen kann der Compiler aber parallelisieren oder anderweitig tauschen.
Beispielsweise könnte bei

unique_ptr<SomeClass> ptr(new SomeClass());

erst der Platz für SomeClass reserviert, dessen Adresse dem Smartpointer zugewiesen und dann der Konstruktor aufgerufen werden.

Darf der Compiler nicht. Vor dem Aufruf der Konstruktor-Funktion müssen alle Argumente ausgewertet worden sein, auch die "new-Funktion", welche Speicher reserviert und als Nebeneffekt bei Erfolg den Konstruktor aufruft.


Edit:

Originally Posted by MrSm!th

Diese Instructionschieberei macht insbesondere bei threadsicheren Singletons (Double-Checked-Locking) Probleme. Zumindest machte sie das, bevor es threadsichere Statics gab.

Dieses "Double-Checked-Locking" sollte vermieden werden, da das Lesen des Zeigers außerhalb der verwendeten Sperre i. Allg. nicht mit dem Schreiben innerhalb dieser synchronisiert sein muss (die Leseoperation also noch einen alten Wert des Zeigers lesen könnte). Außerdem gibt es std::call_once.
Der Standard schreibt meines Wissens nichts über die Threadsicherheit der Initialisierung von statischen Variablen in Funktionen vor. Habe ich die Stelle doch gefunden. Eine parallele Ausführung muss warten.

[MrSm!th]

Originally Posted by Tasiro

Darf der Compiler nicht. Vor dem Aufruf der Konstruktor-Funktion müssen alle Argumente ausgewertet worden sein, auch die "new-Funktion", welche Speicher reserviert und als Nebeneffekt bei Erfolg den Konstruktor aufruft.

In dem PDF ist näher beschrieben, was ich meine.
Das beschriebene Szenario widerspricht deiner Aussage nicht.

Editieses "Double-Checked-Locking" sollte vermieden werden, da das Lesen des Zeigers außerhalb der verwendeten Sperre i. Allg. nicht mit dem Schreiben innerhalb dieser synchronisiert sein muss (die Leseoperation also noch einen alten Wert des Zeigers lesen könnte). Außerdem gibt es std::call_once.

s.o.
Dass es speziell dafür gedachte Libraries gibt, räumt das PDF ebenfalls ein, es geht aber um reine syntaktische Möglichkeiten, ohne plattformabhängige (wenn auch durch den Standard gekapselte) Systemschnittstellen zu nutzen.

Der Standard schreibt meines Wissens nichts über die Threadsicherheit der Initialisierung von statischen Variablen in Funktionen vor. Habe ich die Stelle doch gefunden. Eine parallele Ausführung muss warten.

Seit Cpp11 schon.

[Tasiro]

Originally Posted by MrSm!th

In dem PDF ist näher beschrieben, was ich meine.
Das beschriebene Szenario widerspricht deiner Aussage nicht.

Ich bezog mich oben auf deine Aussage zum Zerstören von durch Ausnahmen unvollständig konstruierten und damit "unzerstörbaren" Objekten im Kontext eines einzigen relevanten Threads, was der Standard nicht zulässt. Was möchtest du mir mit jener PDF-Datei sagen?

Originally Posted by MrSm!th

s.o.
Dass es speziell dafür gedachte Libraries gibt, räumt das PDF ebenfalls ein, es geht aber um reine syntaktische Möglichkeiten, ohne plattformabhängige (wenn auch durch den Standard gekapselte) Systemschnittstellen zu nutzen.

Wenn nicht von der Standardbibliothek gekapselt, wie dann? Ist dann nicht ein valides C++ - Programm, welches Multithreading-Elemente der Standardbibliothek verwendet, inhärent plattformabhängig? Ist dann nicht auch die Verwendung der (von der Standardbibliothek gekapselten) Systemschnittstellen wie jegliche Ein- und Ausgabe plattformabhängig? War plattformunabhängige Programmierung in C++ wirklich von Anfang an zum Scheitern verurteilt?
Ich denke nicht. Jenes Dokument ist zehn Jahre alt, und es ist nun auch ohne nicht-Standard-Bibliotheken möglich, die in jenem Dokument beschriebene Verfahrensweise für Singletons zu implementieren.

Was meinst du mit "rein syntaktische Möglichkeiten"? "Rein" wie "ohne semantische Bedeutung", oder wie "ohne nicht-Standard-Bibliotheken"?

Originally Posted by MrSm!th

Seit Cpp11 schon.

Wie ich schrieb - was in deinem Zitat zu sehen ist, kursiv. Drückte ich mich missverständlich aus? Ich fürchte es...

[MrSm!th]

Originally Posted by Tasiro

Ich bezog mich oben auf deine Aussage zum Zerstören von durch Ausnahmen unvollständig konstruierten und damit "unzerstörbaren" Objekten im Kontext eines einzigen relevanten Threads, was der Standard nicht zulässt. Was möchtest du mir mit jener PDF-Datei sagen?

Dass die Auswertung des Konstruktors des erzeugten Objekts eben nicht zwangsläufig vor der Zuweisung an den Pointer stattfinden muss.

Wenn nicht von der Standardbibliothek gekapselt, wie dann? Ist dann nicht ein valides C++ - Programm, welches Multithreading-Elemente der Standardbibliothek verwendet, inhärent plattformabhängig? Ist dann nicht auch die Verwendung der (von der Standardbibliothek gekapselten) Systemschnittstellen wie jegliche Ein- und Ausgabe plattformabhängig? War plattformunabhängige Programmierung in C++ wirklich von Anfang an zum Scheitern verurteilt?
Ich denke nicht. Jenes Dokument ist zehn Jahre alt, und es ist nun auch ohne nicht-Standard-Bibliotheken möglich, die in jenem Dokument beschriebene Verfahrensweise für Singletons zu implementieren.

Was meinst du mit "rein syntaktische Möglichkeiten"? "Rein" wie "ohne semantische Bedeutung", oder wie "ohne nicht-Standard-Bibliotheken"?

Ich habe nie gesagt, dass es alleine mit Standardbibliotheken nicht möglich ist. Der Code im PDF nutzt selbst welche. Ich sagte, es ist nicht ohne Bibliotheken möglich.
Die Standardbibliotheken kapseln Systemschnittstellen und Magie, um die Ausführreihenfolge bestimmter Codeteile zu forcieren.
Alleine mit rein syntaktischen Mitteln ist das nicht möglich. Wie der Artikel schon sagt, wenn ich 2 lokalen Integern zwei Werte zuweisen, garantiert mir niemand ob und in welcher Reihenfolge das geschieht; der Optimierung sei Dank.

Wie ich schrieb - was in deinem Zitat zu sehen ist, kursiv. Drückte ich mich missverständlich aus? Ich fürchte es...

Habe ich gesehen, ich wollte nur für andere Leser klarstellen, seit wann das der Fall ist, da es bei dir ausblieb.

[Tasiro]

Originally Posted by MrSm!th

Dass die Auswertung des Konstruktors des erzeugten Objekts eben nicht zwangsläufig vor der Zuweisung an den Pointer stattfinden muss.

Solange der Compiler für eine richtige Behandlung bei Ausnahmen sorgt, was eine Umstellung praktisch verhindert, wenn es tatsächlich zu Ausnahmen im Konstruktor kommen kann.

Originally Posted by MrSm!th

Ich habe nie gesagt, dass es alleine mit Standardbibliotheken nicht möglich ist.

Das hast du (nicht gesagt). Es ist (übrigens) erstaunlich viel ohne die Standardbibliothek nicht möglich. Es muss z. B. für die neue Initialisierungssyntax initializer_list eingebunden werden, für den Operator typeid ist es typeinfo.

Originally Posted by MrSm!th

Wie der Artikel schon sagt, wenn ich 2 lokalen Integern zwei Werte zuweisen, garantiert mir niemand ob und in welcher Reihenfolge das geschieht; der Optimierung sei Dank.

Das ist richtig. Aber es kann dir egal sein, dass der Compiler seine Arbeit verrichtet, weil du nur die vom Standard definierten Beziehungen zwischen Threads brauchst, an die muss sich der Compiler halten.

Originally Posted by MrSm!th

Habe ich gesehen, ich wollte nur für andere Leser klarstellen, seit wann das der Fall ist, da es bei dir ausblieb.

Dafür war das also gedacht. Du hast recht. Ich hielt es für unnötig, das zu sagen, weil nur der neue Standard gemeint sein kann.