Compile Warnings in vnsiserver

Alles relevante ist schon im Git.

Für den Nutzer ändert sich durch die letzten Patches nichts.

Die gestalten nur die "responsepacket" Erzeugung übersichtlicher, um sie später besser warten zu können, ohne die Funktion zu verändern (refactoring).

Das ist quasi als Angebot an den Maintainer vom Git gedacht gewesen, sich evtl. später die Arbeit zu erleichtern. Ob ihm das so besser gefällt und er das übernimmt, muss er entscheiden.

So wie ich es verstanden habe war der letzte Vorschlag von wirbel genau das: Ein Vorschlag. Getestet hat das bisher keiner und da ich selbst bis heute nicht dazu gekommen bin das zu testen kann man das selbstverständlich auch nicht einfach so übernehmen.

Was mich aktuell daran noch am meisten stört ist dieser Block (der eigentlich ähnlich ein zweites mal drin ist):

rework cResponsePacket · wirbel-at-vdr-portal/vdr-plugin-vnsiserver-crashes@f426ca8

github.com

Wenn auf "Objektorientierung und C++" dann bitte, wenn irgendwie möglich, raus mit dem Pointer-Low-Level-Kram. Eine Google-Suche hatte zumindest Ansätze gegeben wie man einem "Vector" gleich mehrere Elemente auf einmal zufügt. Es muss also irgendwie gehen, aber ich bin da noch zu weit weg.

Im Prinzip spricht auch technisch nichts dagegen std::string zu verwenden: https://stackoverflow.com/ques…-avoid-manual-dynamic-mem

Allerdings stimme ich da schon zu das ein "Vector" vermutlich "sauberer wäre". Aber wenn der "std::string" es einfacher macht eine aufeinander folgende Bytekette zu verwalten ohne dann doch wieder mit Pointern zu jonglieren, dann würde ich persönlich das vorziehen. Lieber std::string als wieder Low-Level-Zeugs. Und bei einem std::string weiß ich halt das ich ein 4 Byte Integer einfach auf "char" casten kann um es als "String der Länge 4" hinten anzuhängen. Habe ich selbst schon gemacht. Funktioniert einwandfrei.

Vielleicht komme ich auch tatsächlich nochmal dazu selbst bisschen zu probieren. Ich komme aktuell nicht dazu viel zu machen. Meine VDR-Kiste wird kaum noch genutzt und ich muss meinen Bekannten, für den ich bisher noch ein bisschen versuche zumindest den Arch-Paketsatz nutzbar zu halten, mal fragen ob er überhaupt noch vorhat einen neuen VDR zu bauen. Seine alte Kiste (größer 10 Jahre alt) wird nämlich nur noch mit Gebraucht-Teilen "am Leben gehalten" und Updates fahren wir da schon lange keine mehr drauf weil die bei so alter Hardware nur Ärger machen. Wenn er da keine Motivation mehr hat würde ich mich tendenziell eher noch mehr aus dem VDR-Bereich zurückziehen.

Doch, gegen string sprechen die Nullen im stream. Damit schneidet string den stream ab.

Ich hab selbst einen Usermode Treiber geschrieben der genau das macht. Die Nullen stören nur wenn man das Resultat tatsächlich als String nutzt. Von der Idee her ist std::string nur ein Byte Buffer. Die Nullen sind auch nur Bytes.

Hm, aber einen container für nullterminierte strings als byte buffer zu missbrauchen ist schlimmer als ein paar pointer. vector ist da eher das richtige.

Aber ja, du hattest oben recht mit deinem Kommentar, es war ein nur Vorschlag. Es funzt ja wieder alles.

Angenommen das hier ist der offizielle "Standard":

https://cplusplus.com/reference/string/string/

Dann ist da nicht einmal die Rede von "nullterminiert".

Man kann einen nullterminierten String rausziehen mit c_str() aber mit data() gibt es die interne Bytesequenz ohne Null am Ende.

Man kann wohl auch beliebige Datentypen mit "insert" ans Ende eines char-vectors hängen. Wäre auch eine Möglichkeit.