explizite Typumwandlung

[Klebwax]

Und aus eigener Erfahrung kann ich dir garantieren, daß du in einer Callback-Funktion mehr Informationen haben möchtest als nur ein Flag das dir sagt ob die Übertragung erfolgreich war oder nicht. Ein void-Pointer, der vom Low-Level Treiber einfach nur mitgeführt wird, erlaubt es dir beliebige Informationen an einen Job anzuhängen die dir dann in der Callback-Funktion wieder zur Verfügung stehen.

Und woher weißt die Callback-Funktion, wie sie die beliebigen Informationen verarbeiten soll? Wie soll der Compiler ein Type-Check machen wenn er den Type nicht kennt? Wie soll das Entwicklungsteam in Bangalore robusten Code liefern, der mit deinem Treiber zuverlässig funktioniert?

In der Praxis hast natürlich auch recht. Für ein Programm, das man selbst schreibt, wartet, und das obsolet ist, sobald man die Firma verlässt, ist das ok. Aber das Wort "professionell", das gefallen ist, passt da nicht. Wie schreibt der CCC über den Bundestrojaner: "Das hat wohl ein Praktikant geschrieben".

Meine Erfahrung sagt mir, eigentlich jeder Pfusch, den ich mal programmiert habe, ist mir wieder auf die Füße gefallen. Und jeder Pfusch, den ich hab durchgehen lassen, hat die Firma auf die eine oder andere Weise Geld gekostet.

MfG Klebwax

[Felix G]

Und woher weißt die Callback-Funktion, wie sie die beliebigen Informationen verarbeiten soll? Wie soll der Compiler ein Type-Check machen wenn er den Type nicht kennt? Wie soll das Entwicklungsteam in Bangalore robusten Code liefern, der mit deinem Treiber zuverlässig funktioniert?

Wie die Informationen zu interpretieren sind weiß per Definition nur die Callback Funktion...

Der Witz an der Sache ist, daß der Low-Level Treiber dem Benutzer (also in diesem Fall dem High-Level Treiber, der von mir aus auch gern in Bangalore geschrieben werden kann) die Möglichkeit gibt, beliebige Zusatzinformationen mitzuführen. Welche Bedeutung diese Informationen haben ist dem Low-Level Treiber dabei völlig egal, die kennt nur der Benutzer.


Ich stimme dir zu wenn du sagst, daß man void* nicht einfach nur verwenden sollte um Compiler-Warnungen zu unterdrücken. Denn das klappt zwar wunderbar, aber dafür wundert man sich dann später woher die ganzen Bugs kommen. Aber ein paar sinnvolle Anwendungen gibt es eben doch, und daher behaupte ich einfach mal, daß ein void* nicht mal ansatzweise so "böse" ist wie etwa ein goto

[Klebwax]

Dann liegen wir ja nicht weit auseinander. Obwohl ich die potentiellen Probleme von void-Pointern für gravierender halte, als die von gotos. Nicht umsonst ist z.B. in c++ als Ersatz von malloc und co new eingeführt worden.

Aber mal back to topic: Die Idee, den Speicher, den eine Structur belegt, byteweise zu dumpen, ohne gleichzeitig die Informationen über etwaiges Enlignment oder eine Byteorder mit zu übertragen, bekommt bei mir eine "6 setzen". Wenn ich da falsch liege, sind die Leute die RPC oder XML entwickelt haben Ignoranten. Und das traue ich mir nicht zu, anzunehmen.

MfG Klebwax

[Siro]

Hallo Du Void Allergiker:

das ist doch völlig unwichtig wie oder was ich übertrage, solange es dokumentiert wird.
Ich kann eh nicht alles in eine Struktur einbauen wie die Daten übertragenen oder codiert sind.

Also braucht der Empfänger sowieso ein Dokumentation, wie oder was ich übertrage, oder in welchem Datenformat.
Und genau damit weis der Empfänger auch wie meine Struktur bzw. Daten aufgebaut sind und kann evtl. dadurch mit meinen
Daten auch was anfangen. Ich kann doch in meine Sendedaten einbauen was ich will. Wichtig ist,
daß der Empfänger weis, wie er es auswerten soll. Aber diese Information bekomme ich doch in meine
Daten oder Struktur eh nicht hinein, sondern nur durch DOKUMENTATION.

Da die ganze Diskusion ja über den Void Pointer ausgelöst wurde:
Natürlich kann ich den Void Pointer ersetzten durch z.B struct*....
aber wenn der Empfänger meine Struktur nicht kennt ist auch der Datentyp für die Katz.
da nützt auch kein "Casting" mehr etwas. Ob vorher, nachher, oder wann auch immer.
Ohne spezielle Informationen (Dokumentation) sind die Daten nutzlos.
Und ob nun die Daten Little Endian oder Big Endian oder packed oder was auch immer codiert sind,
kann ich doch meinem Datenblock eh nicht entnehmen, bzw. könnte ich schon,
wenn der Empfänger weis wie er meine Beschreibung z.B. den Datenblock zu interpretieren hat.
Deshalb:
Man sendet Daten, auch gern mit einem Void Pointer, (weil man sendet ja nur Byte für Byte)
aber ohne zusätzliche Doku sind die Daten eh "Müll" Da sind wir wohl alle einer Meinung.
Was nützt mir denn der Integer Pointer, der auf 8,16,32, oder vielleicht auf 64 Bit zeigt,
wichtig für den Empfänger ist doch, wie sind die Daten codiert. Also kann ich getrost mit einem Void Pointer senden,
ich muss eh das Format preisgeben (Dokumentieren) , sonst sind die Daten unauswertbar.
Kurz gesagt: ohne Dokumentation läuft garnichts.
Und der Void Pointer hat damit seine Berechtigung...Er zeigt irgenwo hin und ich möchte auch irgendwelche Daten senden.

Achja, ich möchte aber extra betonen, solange es die Möglichkeit gibt, den Code so zu implementieren, daß man im Vorfeld Fehler vermeiden oder aufspüren kann,
sollte jeder bestraft werden, der dieses Vorgehen vernachlässigt.

Zum Thema Goto: der "verhasste" Goto hat teilweise derart gute Dienste geleistet (ich meine damit der Übersichtlichkeit der Software beigetragen) wenn auch nur im Einzelfall,
daß ich ihn absolut nicht als böse bezeichnen würde. Wenn jemand aber damit durch die Gegend springt ist es echt fatal.

eine gute Nacht wünscht euch,
Siro