[Programmiererstammtisch] "Zum ächzenden Compiler"

[slowcar]

Ist (zum Glück) so gar nicht mein Fokusgebiet, halte mich von C-Code lieber fern, aber das hier könnte relevant sein: https://github.com/android/ndk/issues/201
Soweit ich das verstanden habe, funktioniert also das dynamische laden nicht, wenn die Bibliothek Abhängigkeiten auf eine andere dynamisch geladene hat - aber könnte auch sein, dass ich damit falsch liege.
Ich habe bislang zum Glück nur dynamische Bibliotheken ohne gegenseitige Abhängigkeiten verwendet
(Finde es schon nervig genug, die verschiedenen Architekturen vorzuhalten)

[Ramkhamhaeng]

Danke, das scheint genau die richtige Issue-Meldung zu sein. Das die Android-App die äußere native Lib mit RTLD_LOCAL statt RTLD_GLOBAL scheint der Unterschied zu sein. Die innere Lib, die von der äußeren per dlopen geladen hat kann dann nicht auf die Symbole der äußeren Zugreifen.
Etwas überraschend, da man eher erwarten würde die Grenze Global/Lokal wird nur zwischen Android-App und der äußeren Lib gezogen.

Aber erstmal zuende lesen...


Edith: Hm in meinem Fall ist die Sache leider komplizierter. Normalerweise wäre in dem Fall die Lösung gewesen beim Kompilieren gegen die Lib zu linken, die später mit dlopen die andere öffnet..

Das bringt mir aber gar nichts, denn bei mpv schreiben sie als Kommentar

Linkage to libmpv

The current implementation requires that your plugins are not linked against libmpv. What your plugins uses are not symbols from a libmpv binary, but symbols from the mpv host binary.

Ich müsste also beim Kompilieren meines Plugins gegen das Binary linken. Das geht wohl, wenn man '-rdynamic' beim Erstellen des Binaries gesetzt hat, damit man von dort auch Symbole bekommt. Aber bei der Android-Version gibt es so ein Binary nicht

[Tiramisu]

Ist es eine gute Idee in C++ für den Zugriff auf Class members möglichst immer this->... zu verwenden? Einerseits kann der Leser dadurch leichter zwischen class members und gewöhnlichen lokalen Variablen unterscheiden und andererseits entstehen für den Compiler keine Missversändnisse, wenn man für lokale Variablen dieselben Namen wie für class members verwendet. Der Nachteil ist allerdings, dass der Quellcode durch die Verwendung von this->... länger wird. Außerdem habe ich den Verdacht, dass "this->member" etwas mehr Zeit beanspruchen könnte im Vergleich zu "member". Aber da bin ich mir nicht sicher.

[alpha civ]

Eine gute IDE sollte eigentlich in der Lage sein, class members anders einzufärben als lokale Variablen, so dass der Leser keine Schwierigkeiten haben sollte, dass zu unterscheiden. Der Compiler hat sowieso da keine Probleme. Was anderes ist es natürlich, wenn die Namen von lokalen und member Variablen identisch sind, hier musst du "this->" verwenden.

Alternativ kannst du auch einen Präfix für member Variablen verwenden, z.B. "m_". Dann sieht man auch ohne IDE mit was man es zu tun hat.

[Tiramisu]

Da hast du natürlich recht.

[Flati]

Es ist zumindest guter Stil das man Classmember immer mit this markiert. Häufig macht das über save/Actions die Formatter auch automatisch.
Insbesondere wenn mehrere Personen an den Code arbeitet signalisiert man das man sich beim programmieren vollauf bewußt war das man auf Classmember zugreifen wollte und nicht nur eine Lokale Variable. Habe schon einige Bugs gesehen wo die aisversehen gleich hießen und man hat es nicht gleich bemerkt und hat dann zu komischen Effekten geführt hat.
Ich bin zwar selbst in Java unterwegs, in c++ wird es aber nicht anders sein.

[alpha civ]

Letztendlich gehört sowas in einem internem Styleguide, damit nicht jeder Entwickler da was anderes macht.

[Zulan]

Es ist zumindest guter Stil das man Classmember immer mit this markiert.

Ich kennen keinen C++ style guide der das empfiehlt. Z.B. die C++ core guidelines treffen dazu AFAIK keine Aussage, verwenden aber auch kein this-> in den Beispielen. this-> braucht man eigentlich nur in zwei Situationen:

1. Beim Zugriff auf member von templatisierten Basisklassen
2. Bei mehrdeutigkeiten / shadowing. Das ist aber i.d.R. besser das ganz zu vermeiden.

[Tiramisu]

Es gibt sicher noch weitere Verwendungen für this wie z.B. return *this.
Oder wenn man Klassenmember speichern und wieder laden will wie z.B. savedMembers = *this und *this = savedMembers, wobei savedMembers nur die wichtigen member beinhalten muss.

[alpha civ]

Was versteht du unter "speichern" und "laden"?

[Tiramisu]

Wenn ich z.B. die Memberwerte in einen alten Zustand zurückversetzen will.

inline void Set() { savedMembers = *this; }
inline void Reset() { *this = savedMembers; }
void Example() {
//Do Something
Set();
//Do Something
Reset();
//Do Something
}

[slowcar]

Wenn ich z.B. die Memberwerte in einen alten Zustand zurückversetzen will.

inline void Set() { savedMembers = *this; }
inline void Reset() { *this = savedMembers; }
void Example() {
//Do Something
Set();
//Do Something
Reset();
//Do Something
}

Wo kann man Deinen Styleguide zur Programmierung käuflich erwerben?

[Tiramisu]

Den Style gibt es gratis, weil die Indents in Forenposts automatisch ignoriert werden.

[EpicFail]

Dafür gibt es doch die Code Umgebung

[Harleen]

Wenn ich z.B. die Memberwerte in einen alten Zustand zurückversetzen will.

inline void Set() { savedMembers = *this; }
inline void Reset() { *this = savedMembers; }
void Example() {
//Do Something
Set();
//Do Something
Reset();
//Do Something
}

Wie ist denn savedMembers deklariert? Ein member kann es ja nicht sein, sonst würde deine Klasse sich selbst enthalten. Eine globale Variable wird es hoffentlich nicht sein.
Generell sieht das so schmutzig aus, dass du dem Ganzen nur einen Namen geben musst, dann ist es ein Design Pattern.