vdr-2.4.6 kompiliert mit gcc-11.0.0 nicht

das "max()" gegen "std::max()" tauschen wie in de Fehlermeldung angegeben sollte doch mit allen gehen ....

Kommt drauf an wo das "max" vorkommt. Das Problem ist hier das Klaus aus bisher unbekannten Gründen nicht auf das "max" aus der C++ Standard Library zurückgreift und stattdessen das Rad neu erfindet.

Ein einfacher Patch um diesen Probleme dauerhaft zu eliminieren wäre Umstellung des VDR selbst auf "std::max" und Löschen der eigenen Implementierung.

Stimmt, die Macros Templates min und max sind überholt.

[edit]korrekter Hinweis.[/edit]

Es sind keine Macros, sondern Templates:

template<class T> inline T min(T a, T b) { return a <= b ? a : b; }
template<class T> inline T max(T a, T b) { return a >= b ? a : b; }

Hi,

bei Gentoo kommt gcc-11 nun auch auf uns zu. Wie lösen wir das am vernünftigsten?

Ideal wäre eine Lösung die auch mit gcc-9/10 funktioniert, UND ermöglicht daß nicht in allen Plugins rumgepatch werden muss.

Gerade fällt mir ein, "swap" wird auch moniert. Kann das durch "std::swap" ersetzt werden?

In tools.h werden die Macros __STL_CONFIG_H, _STL_ALGOBASE_H und _MOVE_H abgefragt, um zu erkennen, ob Header-Files der stdlib inkludiert wurden. Für VDR selber ist dies nicht der Fall, so dass also keines dieser Macros definiert sein sollte. Warum dies nun in gcc-11 plötzlich doch der Fall ist, weiß ich nicht.

Die Frage ist aber doch warum immer wieder der Kampf ausgefochten wird irgendwie die "Spezial-Versionen" im VDR zu "verteidigen". Warum nicht entsorgen und die "Standard-Versionen" nutzen? Ich frage mich ob das nicht sogar ein einfacher GCC11-Fix wäre. Passendes Include oben rein und die Defines so verbiegen das sie direkt auf std::max und std::min zeigen.

Wegen dem "woher kommen die Defines" würde ich einfach mal in den Raum stellen das eine der vielen anderen Includes vielleicht seinerseits bei GCC 11 auf ein STL-Feature aufsetzen, die entsprechende ".h" inkludiert und so das Define global reinziehen. Ist halt irgendwo in Kampf gegen die Programmiersprache wenn man Standardfeatures mit der Brechstange nicht haben will.

Vorschlag:

--- tools.h     2021/01/19 20:38:28     5.3
+++ tools.h     2021/05/05 15:16:45
@@ -53,17 +53,15 @@

 // In case some plugin needs to use the STL and gets an error message regarding one
 // of these functions, you can #define DISABLE_TEMPLATES_COLLIDING_WITH_STL before
-// including tools.h.
-#if !defined(__STL_CONFIG_H) // for old versions of the STL
-#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL) && !defined(_STL_ALGOBASE_H)
+// including any VDR header files.
+#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL)
 template<class T> inline T min(T a, T b) { return a <= b ? a : b; }
 template<class T> inline T max(T a, T b) { return a >= b ? a : b; }
 #endif
 template<class T> inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
-#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL) && !defined(_MOVE_H)
+#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL)
 template<class T> inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
 #endif
-#endif

 template<class T> inline T constrain(T v, T l, T h) { return v < l ? l : v > h ? h : v; }

Plugins, die STL verwenden, müssen dann halt DISABLE_TEMPLATES_COLLIDING_WITH_STL definieren.

Warum nichtmal wenigstens einen Satz zur Frage warum der VDR eigene Spezial-Implementierungen hat? Und wenn es "gefallen mir besser" ist, dann schreib halt einfach das.

Ich will ja nicht sagen das ignorieren sehr unhöflich ist, aber ich finde ignorieren eigentlich schon sehr unhöflich.

Quote from kls

Vorschlag:

Diff

--- tools.h     2021/01/19 20:38:28     5.3
+++ tools.h     2021/05/05 15:16:45
@@ -53,17 +53,15 @@

 // In case some plugin needs to use the STL and gets an error message regarding one
 // of these functions, you can #define DISABLE_TEMPLATES_COLLIDING_WITH_STL before
-// including tools.h.
-#if !defined(__STL_CONFIG_H) // for old versions of the STL
-#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL) && !defined(_STL_ALGOBASE_H)
+// including any VDR header files.
+#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL)
 template<class T> inline T min(T a, T b) { return a <= b ? a : b; }
 template<class T> inline T max(T a, T b) { return a >= b ? a : b; }
 #endif
 template<class T> inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
-#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL) && !defined(_MOVE_H)
+#if !defined(DISABLE_TEMPLATES_COLLIDING_WITH_STL)
 template<class T> inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
 #endif
-#endif

 template<class T> inline T constrain(T v, T l, T h) { return v < l ? l : v > h ? h : v; }

Display More

Plugins, die STL verwenden, müssen dann halt DISABLE_TEMPLATES_COLLIDING_WITH_STL definieren.

kann man das auch bei 2.5.3 anwenden? Hab ja das gleiche Problem bei Fedora 34.

cocobrother Der Patch ist gegen die 2.5.3, und sollte auch für ältere Versionen gehen.

kls i will Check…

M-Reimer VDR hat (fast) von Anfang an swap(), min() und max() selber implementiert und hat STL weder benutzt noch gebraucht. Als dann Plugins dazukamen, gab es einige Autoren, die in ihrem Code gerne STL verwenden (was ihr gutes Recht ist). Aber anscheinend verträgt sich das nicht mit den Templates in tools.h, daher habe ich einige Macros abgefragt, um zu testen, ob vielleicht ein STL-Header-File inkludiert wurde, und dann die störenden Templates deaktiviert. Vielleicht hätte ich von Anfang an nur DISABLE_TEMPLATES_COLLIDING_WITH_STL benutzen sollen, aber ich wollte es den Plugin-Autoren halt einfach machen.

Eigentlich sollte es sich aber doch gar nicht "beissen", wenn in tools.h die Templates definiert werden, und in einem Plugin z.B. statt min() std::min() benutzt wird. So ganz verstehe ich nicht, was da eigentlich schief läuft...

Ich hab jetzt mal ne ganz dumme Frage:

Was ist der Unterschied zwischen dem Template "max" und "std::max" ? Die Funktion mutet mir doch identisch an?!?

md_berlin Sie erfüllen den gleichen Zweck. Selbst wenn sie nicht exakt gleich sind sollten sie sich schon sehr ähneln.

Ich hab jetzt einfach mal mitgenommen das das im VDR eben schon immer so war und dann "never change a running system".

Wäre es mein Projekt würde ich es als Herausforderung sehen mal zu schauen was C++ mittlerweile "nativ" bietet und wie viel eigener Code damit raus könnte. Dafür spricht nicht nur das Argument, dass die "nativ" verfügbaren Funktionen über viele Projekte genutzt werden, und so Optimierungen/Bugfixes schneller umgesetzt werden, sondern auch der "Wiedererkennungswert". Ein neuer "Beitragender" findet sich, wenn er C++ kann und einen Standardtypen sieht, einfach direkt zurecht.

Aber ist letztlich die Entscheidung von kls was ihm wichtiger ist. Mir kann es weitgehend egal sein weil ich auch in Zukunft nicht im größeren Stil Plugins entwickeln will.

Solange niemand ein 'using namespace std' benutzt, sollten 'min' und 'std::min' ohne macros drum herum friedlich coexistieren.

Anscheinend ist eher das Problem, dass es das magische _STL_ALGOBASE_H nicht gibt und damit weder min noch std::min.

Wo kommt das her, doch nicht etwa aus einer speziellen Implementation der STL?

Die saubere Lösung könnte btw auch sein, betroffene Plugins zu fixen, anstatt hier neue Verrenkungen zu bauen.

Quote from wirbel

Solange niemand ein 'using namespace std' benutzt

Auch das habe ich schon mal in einem Plugin gesehen: vdr-plugin-live

Lässt sich fixen.