Live, pull request "remove any 'using namespace std;' "

Nicht grundsätzlich, aber im VDR Plugin Kontext wohl die bessere Lösung um Kollisionen mit VDR eigene Implementierungen zu verhindern. Siehe hier

Es ist sauberer, dafür mehr Tipparbeit.

Wenn du z.B. folgende Code Schnipsel vergleichst

#include <vdr/tools.h>

using namespace std;

(..)
int a = 5;
int b = 3;

swap(a,b);

Dann läufst du in ein Problem, weil 'swap' sowohl in vdr/tools.h, als auch in der libstdc++ als std::swap definiert ist. Und sogar bis C++20 auch noch inkompatibel.

Uns wurde an der Hochschule empfohlen "using namespace std" immer zu verwenden. Viele wesentliche Funktionen sind in diesem Namespace und den dann immer zu wiederholen ist redundant.

Zitat von M-Reimer

Uns wurde an der Hochschule empfohlen "using namespace std" immer zu verwenden

Dem stimme ich zu, dann aber an der richtigen Stelle: nicht im Header File und nach allen #include's um keinen Einfluss auf anderen Code zu erzeugen.

Diese Diskussion hier auf stackoverflow bringt es auf den Punkt, die ersten drei Antworten nach dem Fragesteller.

https://stackoverflow.com/ques…d-considered-bad-practice

Informatik an der Hochschule hat nicht immer den passenden Bezug zur Realität - nicht böse gemeint...

Das funktioniert nämlich nur, wenn alle beteiligten Komponenten mit Namespaces arbeiten. Und auch dann kann man immer in diese Falle laufen, dass es Doppeldeutigkeiten gibt. Wenn man Glück hat, dann meckert der Compiler...

Da der vdr-Code komplett ohne Namespaces ist, ist es dann immer so eine Sache, wenn man durch ein using den globalen Namespace mit Dingen füllt...

Lars.

Btw..

Um das hier zum Abschluss zu bekommen, fehlt noch ein zweiter Pull Request um das gleiche für die ecpp Dateien nach zu ziehen.

Zitat von mini73

Informatik an der Hochschule hat nicht immer den passenden Bezug zur Realität - nicht böse gemeint...

Trotzdem kann ich durchaus nachvollziehen das man sich alles aus "std" in den globalen Namespace holt. Für mich ist das irgendwie "fester Bestandteil der Sprache C++" und wenn man diese Typen viel nutzt, dann wird das ständige "std::" irgendwann lästig.

Und ja, ich hab auch "using namespace std" in ".h"-Files. Allerdings nur in ".h"-Files die nicht "Projektübergreifend" genutzt werden. Bei Libraries sehe ich ein das das da nichts verloren hat aber wenn ich ein abgeschlossenes Projekt erstelle und in meinen Header-Files die Klassen deklariere, dann will ich in den Attributen auch nicht ständig das "std::" haben.

Zitat von mini73

Da der vdr-Code komplett ohne Namespaces ist, ist es dann immer so eine Sache, wenn man durch ein using den globalen Namespace mit Dingen füllt..

Könnte man natürlich jetzt auch umdrehen und fragen: Warum hat der VDR nicht über den gesamten Code einen eigenen Namespace "vdr". Wenn das konsequent überall eingebaut ist wäre das Problem aus der Welt und da der VDR komplett in seinem Namespace läuft wäre auch am VDR-eigenen Code gar nicht so viel zu ändern. Ja, ich weiß:

Zitat von M-Reimer

Warum hat der VDR nicht über den gesamten Code einen eigenen Namespace "vdr".

Wenn es eine Wunschliste geben würde, würde ich das auch gerne drauf setzen. Damit wäre das Problem von Live sauber gelöst, dass LOG_ERROR, LOG_DEBUG, LOG_INFO sowohl in cxxtools als auch im VDR verwendet wird.

Aber die gibt es nicht ...

Genau da habe ich heute auch drauf geschaut, aber noch nicht zu 100% verstanden, wer genau der Schuldige ist.

Wie auch immer, diese Patch Serie würde schon mal etwas dort verbessern, wo das Problem induziert wurde - in live.

Zitat von M-Reimer

Trotzdem kann ich durchaus nachvollziehen das man sich alles aus "std" in den globalen Namespace holt. Für mich ist das irgendwie "fester Bestandteil der Sprache C++" und wenn man diese Typen viel nutzt, dann wird das ständige "std::" irgendwann lästig.

Ich verstehe dein Denken dahinter, aber "in echt" ist das halt immer etwas anders.

Der vdr stammt aus einer Zeit, wo die STL sehr bescheiden war, insbesondere, was ihre Performance betraf. Auch wir bei mir in der Firma haben für unsere C++ Projekte damals (vor 20 Jahren) eigene String-Klassen usw. geschrieben, weil wir bestimmte Features brauchten, die die STL damals nicht geboten hat.

Und auch wir haben das alles nicht in einem eigenen Namespace, weil es einfach nicht nötig war.

Code entwickelt sich halt - und man muss ihn immer in seinem Kontext sehen.

Der vdr benutzt nicht viele wirkliche C++ Features (nur ein wenig Klassen, Vererbung, Templates...) und vor allem einfach keine STL. Das muss man schon unterscheiden, auch wenn es bei anderen Sprachen (C#, Java, Python...) anders läuft und das Framework kaum von der Sprache zu trennen ist.

Zitat von M-Reimer

Könnte man natürlich jetzt auch umdrehen und fragen: Warum hat der VDR nicht über den gesamten Code einen eigenen Namespace "vdr".

Weil es nicht nötig war.

In der "freien Wildbahn" ist vieles etwas pragmatischer als am "grünen Tisch". Und wenn man etwas zu einem Projekt beiträgt, dann muss man immer den Kontext des Projekts betrachten.

Und selbst wenn alles in einem Namespace "vdr" wäre - ich vermute, es würde dann genügend Plugin-Entwickler geben, die dann "using namespace vdr;" benutzen würden, weil sie ja eine Menge aus diesem Namespace benutzen wollen würden. Und dann würde es sich wieder beißen...

Insofern muss man dann abwägen, wie viele "vdr::" man im Gegensatz zu "std::" schreiben müsste. Ich würde es dann vorziehen, den Namespace in der Unterzahl dann nicht einfach per "using" einzubinden.

Letztlich darf man aber immer machen, was man möchte, solange ads richtige dabei am Ende herauskommt.

Lars.

Zitat von wirbel

Um das hier zum Abschluss zu bekommen, fehlt noch ein zweiter Pull Request um das gleiche für die ecpp Dateien nach zu ziehen.

Genau das wird jetzt mit VDR 2.5.4 zwingend notwendig, Live baut nicht mehr, es kommt ein overload error bei swap.