Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins

  • Wohl schon in 2.3.5 wurde in tools.h ein paar ifndefs für STL eingeführt, deren Sinn sich mir so nicht erschließt. Vorher konnte man mit -D__STL_CONFIG_H die Templates min,max,swap und sgn des VDR abschalten und in den Plugins die STL-Makros nutzen. Das funktioniert jetzt so nicht mehr, oder nur noch wenn die Include-Verzeichnisse irgendeine spezielle Reihenfolge haben, da z.B. _MOVE_H und _STL_ALGOBASE_H irgendwo in den Innereien der STL-Header gesetzt werden. Das führt zu lustigen Compiler-Fehlern wenn z.B. swap oder sort von der STL verwendet wird.


    Graphtftng bekommt man mit dieser Änderung z.B. nicht mehr ans kompilieren. Interne Defines der STL-Header zu verwenden ist meiner Meinung nach keine gute Idee. Gibt es da spezielle Gründe für diese Änderung oder sollte man die besser doch wieder rückgängig machen?

    VDR 2.3.8 Kodi 17.4-Krypton
    OpenSUSE Leap 42.3, Kernel 4.13.5, Thermaltake DH102, ASHRock Q2900M, CineS2 V6.5.
    Plugins:
    softhddevice v0.6.1rc1-GITad21656, radio 1.0.1, externalplayer 0.3.3, trayopenng 1.0.2, fritzbox 1.5.3, cdplayer 1.2.4, femon v2.3.0-GIT-6112484, menuorg 0.5.1, extrecmenu v1.2.5-git, streamdev-server v0.6.1-git, extrecmenu v1.2.4, cecremote 1.4.1, osd2web 0.1.22

  • Hi Ulrich,


    probier mal graphtftng mit dem angehängten Patch zu bauen.

    Dateien

    Gruß MegaX


  • probier mal graphtftng mit dem angehängten Patch zu bauen.


    Der Patch zeigt gerade das Problem, was ich da bemängelt hatte, er sortiert unter anderem Include-Files um. Eigentlich darf die Reihenfolge der Includes keine Auswirkung haben, ob was compiliert oder nicht. Deswegen sollte sich Klaus vielleicht noch mal die Änderung in tools.h anschauen.

    VDR 2.3.8 Kodi 17.4-Krypton
    OpenSUSE Leap 42.3, Kernel 4.13.5, Thermaltake DH102, ASHRock Q2900M, CineS2 V6.5.
    Plugins:
    softhddevice v0.6.1rc1-GITad21656, radio 1.0.1, externalplayer 0.3.3, trayopenng 1.0.2, fritzbox 1.5.3, cdplayer 1.2.4, femon v2.3.0-GIT-6112484, menuorg 0.5.1, extrecmenu v1.2.5-git, streamdev-server v0.6.1-git, extrecmenu v1.2.4, cecremote 1.4.1, osd2web 0.1.22

  • Irgendwie muß tools.h ja "erfahren", daß STL-Header inkludiert werden, die Templates definieren, die auch VDR selber definiert. Und das geht nunmal nur, wenn die STL-Hedaer vor tools.h inkludiert werden.


    Klaus

  • Irgendwie muß tools.h ja "erfahren", daß STL-Header inkludiert werden, die Templates definieren, die auch VDR selber definiert. Und das geht nunmal nur, wenn die STL-Hedaer vor tools.h inkludiert werden.


    Warum kommt es überhaupt zu der Situation? Kann der VDR nicht einfach die STL-Definitionen nutzen? Wozu das Rad neu erfinden?

  • Warum kommt es überhaupt zu der Situation? Kann der VDR nicht einfach die STL-Definitionen nutzen? Wozu das Rad neu erfinden?


    VDR benutzt die STL nicht.


    Klaus

  • rgendwie muß tools.h ja "erfahren", daß STL-Header inkludiert werden,


    Das war vor der Änderung besser gelöst, einfach durch das setzten von __STL_CONFIG_H. Wobei __STL_CONFIG_H ja auch immer noch gesetzt werden muss. Ich sehe deshalb keinen Vorteil in der Änderung.


    Das beste wäre natürlich, den VDR STL-Konform zu machen ;D

    VDR 2.3.8 Kodi 17.4-Krypton
    OpenSUSE Leap 42.3, Kernel 4.13.5, Thermaltake DH102, ASHRock Q2900M, CineS2 V6.5.
    Plugins:
    softhddevice v0.6.1rc1-GITad21656, radio 1.0.1, externalplayer 0.3.3, trayopenng 1.0.2, fritzbox 1.5.3, cdplayer 1.2.4, femon v2.3.0-GIT-6112484, menuorg 0.5.1, extrecmenu v1.2.5-git, streamdev-server v0.6.1-git, extrecmenu v1.2.4, cecremote 1.4.1, osd2web 0.1.22


  • Das war vor der Änderung besser gelöst, einfach durch das setzten von __STL_CONFIG_H. Wobei __STL_CONFIG_H ja auch immer noch gesetzt werden muss. Ich sehe deshalb keinen Vorteil in der Änderung.


    Die Änderung wurde notwendig, weil in neueren Versionen der STL-Header das Macro __STL_CONFIG_H nicht mehr definiert ist.
    Man musste dieses Macro nicht selber definieren, wenn man die STL-Header *vor* tools.h inkludiert hat.
    Schuld sind also die STL-Autoren, die, wie ich aus berufenem Mund erfahren habe, sich vor dem Programmieren regelmäßig erst einen ansaufen, um auf ihre verqueren Ideen zu kommen ;-).

    Zitat


    Das beste wäre natürlich, den VDR STL-Konform zu machen ;D


    Es gibt keine Vorschrift, die besagt, daß man die STL benutzen *muß* ;-).


    Auserdem könnten ja auch die Plugins, die die STL benutzen wollen, z.B. std::max() schreiben, um nicht mit VDRs Template-Funktionen zu kollidieren ;-).


    Klaus

  • Klaus, könntest Du nicht die Funktionen aus vdr, die mit der STL kollidieren in einen namespace ( z. B. "vdr") legen, und dann diesen namespace in den vdr .c files mit "using namespace vdr" bekanntmachen. Dann sollte nix mehr kollidieren.


    Wenn Du Interesse hast, könnte ich dafür einen Patch bauen.


    Gruß


    Dominik

    VDR: Thermaltake DH102, Asus M3N78-PRO AMD 4850e, GT 220 passiv, 1x Mystique SaTiX-S2 Dual

  • Klaus, könntest Du nicht die Funktionen aus vdr, die mit der STL kollidieren in einen namespace ( z. B. "vdr") legen, und dann diesen namespace in den vdr .c files mit "using namespace vdr" bekanntmachen. Dann sollte nix mehr kollidieren.


    Jasmin hat extra die neuen Abfragen eingebaut, damit Plugins die STL verwenden können. Einzige Voraussetzung: die STL-Header müssen (wie bisher auch) *vor* tools.h inkludiert werden.
    Funktioniert das denn nicht?


    Klaus

  • Schuld sind also die STL-Autoren, die, wie ich aus berufenem Mund erfahren habe, sich vor dem Programmieren regelmäßig erst einen ansaufen, um auf ihre verqueren Ideen zu kommen ;-).


    Für mich klingt das hier wie die Erklärung warum Klaus STL nicht nutzt :)


    Claus

    MLD 5.1 mit vdr 2.2 - lirc yaUSBir - Octopus NET S2 - SCR - XFX GeForce 9300 mit Intel E3200 - 2GB RAM -
    WD Green 6TB HDD - SanDisk 64GB SSD - Lian Li PC-C37B - Samsung LE40A559
    MLD 5.3 mit vdr 2.3.4 - Raspberry Pi 3 - rpihddevice
    MLD 5.1 mit vdr 2.2 - Banana Pi - softhddevice
    MLD 5.0 mit Squeeze Play - Raspberry Pi 2 - 32GB SD - 7" Touch TFT
    MLD 2.0 mit vdr 1.6 - SMT-7020s - 80GB HDD

  • Klaus, könntest Du nicht die Funktionen aus vdr, die mit der STL kollidieren in einen namespace ( z. B. "vdr") legen, und dann diesen namespace in den vdr .c files mit "using namespace vdr" bekanntmachen. Dann sollte nix mehr kollidieren.


    Würde das so in tools.h reichen?

    Code
    1. namespace VDR {
    2. template<class T> inline T min(T a, T b) { return a <= b ? a : b; }
    3. template<class T> inline T max(T a, T b) { return a >= b ? a : b; }
    4. template<class T> inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
    5. template<class T> inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
    6. }
    7. using namespace VDR;


    Wenn ja, dann wäre das für mich durchaus OK.


    Klaus

  • Deswegen alle .c Files zu ändern kommt nicht in Frage.


    Das Problem war doch, seweit ich das mitbekommen habe, daß die Deklarationen zwischen VDR und STL kollidierten. Wenn VDR nun seine Templates in einen eigenen Namespace verpackt, dann können die Deklarationen nicht mehr kollidieren. An der Aufrufstelle kann sich der Programmierer dann ja immer noch überlegen, ob er einfach nur max() schreibt und, falls er tools.h inkludiert hat, Das VDR-Template bekommt, oder ob er std::max() schreibt und sicher ist, die STL-Variante zu bekommen.


    Oder übersehe ich da was?


    Klaus

  • Ahh. Also programmieren wir ab jetzt auch alles mit z.B. Boost. Wird ja häufig verwendet, ist also gut getestet.


    Genau so ist es. Boost ist gut getestet und hat zudem das Ziel möglichst alle seine Funktionen zum C++-Standard zu machen:


    http://www.boost.org/ schrieb:

    We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are included in the C++ Standards Committee's Library Technical Report (TR1) and in the new C++11 Standard. C++11 also includes several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for standardization in C++17.


    Im Umkehrschluss wäre es mal ganz interessant mal zu evaluieren welches der VDR-Plugins mit Boost-Abhängigkeit vielleicht bereits ohne baut, wenn man den C++-Standard beim Kompilieren hochsetzt. Das ist aber ein anderes Thema und gehört nicht hierher.