Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins

Hi Ulrich,

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

Damit lässt es sich vermutlich bauen, aber die Probleme, die graphtftng mit >=vdr-2.3.0 hat, werden durch den Patch nicht behoben.

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

Zitat von kls

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?

Zitat von M-Reimer

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

Zitat von Ulrich Eckhardt

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

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

Zitat von kls

[...] 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 ;-). ...

Vermutlich DAMIT?

*SCNR*

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

Zitat von domml

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

Zitat von kls

VDR benutzt die STL nicht.

Klaus

Eigentlich hätte mich ja eher der technische Hintergrund interessiert. Mein Dozent an der Hochschule legt uns nahe, dass wir so oft wie möglich gut getestete Bibliotheken nutzen sollen. Begründung: Je weniger Code man selber schreibt umso weniger Fehler kann man machen.

Zitat von kls

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

Zitat von domml

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?

namespace VDR {
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; }
template<class T> inline int sgn(T a) { return a < 0 ? -1 : a > 0 ? 1 : 0; }
template<class T> inline void swap(T &a, T &b) { T t = a; a = b; b = t; }
}
using namespace VDR;

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

Klaus

Zitat von M-Reimer

Mein Dozent an der Hochschule legt uns nahe, dass wir so oft wie möglich gut getestete Bibliotheken nutzen sollen. Begründung: Je weniger Code man selber schreibt umso weniger Fehler kann man machen.

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

Nein. Reicht nicht weil die ".h" direkt "using namespace" macht.

Das "using namespace" müsstest du in die ".c"-Dateien packen. Nur so hat ein Plugin-Autor die Wahl.

Richtig, das using muß in die .c Files.

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

Zitat von Copperhead

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:

Zitat von http://www.boost.org/

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.