explizite Typumwandlung

[PicNick]

Offenbar sind noch ein paar Leute ohne einen Schimmer, wie man wirklich professionelle Funktionen schreibt
z.B


void * memcpy ( void * destination, const void * source, size_t num );Das sind schon mal 15 €
http://www.cplusplus.com/reference/clibrary/cstring/memcpy

[Klebwax]

Offenbar sind noch ein paar Leute ohne einen Schimmer, wie man wirklich professionelle Funktionen schreibt
z.B


void * memcpy ( void * destination, const void * source, size_t num );Das sind schon mal 15 €
http://www.cplusplus.com/reference/clibrary/cstring/memcpy

Warum hast du dann nicht auch gleich das zweite Beispiel von Funktionen, für die soetwas wie ein void-Pointer überhaupt erfunden wurde, genannt: die Gruppe der Memory-Management-Funktionen. Die mehr als einseitige Begründung, wozu man so etwas braucht, findest du in der gängigen C-Literatur. Des gleichen findest du dort aber dort auch die Diskussionen, das eine richtige Programmiersprache Pointer, egal welcher Art, überhaupt nicht zulassen sollte. Offensichtlich haben Leute wie Wirth den Programmierern nicht zugetraut, vernüftig mit dem Instrument Pointer umzugehen.

Um aber bei "professionelle Funktionen" zu bleiben, glaubst du ernsthaft, so etwas wie das beschriebene uart_send() würde einem professionellen Code Review standhalten ? Wie verhält sich die Funktion, bei verschiedenen Compileroptimierungen oder auch verschieden Compilern, wie auf CPUs mit unterschiedlichen Wortbreiten, wie auf einer CPU mit anderen Alignment-Regeln, und wie bei Big oder Little Endian Rechnern?

MfG Klebwax

[Klebwax]

Zum Thema void pointer hier ein Ausschnitt von learncpp.com: (hervorhebungen von mir)

In general, it is a good idea to avoid using void pointers unless absolutely necessary, as they effectively allow you to avoid type checking. This allows you to inadvertently do things that make no sense, and the compiler won’t complain about it.

.....

However, very occasionally, you may still find a reasonable use for the void pointer. Just make sure there isn’t a better (safer) way to do the same thing using other language mechanisms first!

Statt "Just make sure" hab ich gesagt, schreib eine ausführliche Begründung oder zahl in die Kaffekasse.

MfG Klebwax

[Felix G]

Hmm, wie wärs mit folgendem Szenario:

Eine Funktion deren Rückgabewert ein Funktionspointer auf sich selbst ist (bzw. ganz allgemein ein Pointer auf eine Funktion des gleichen Typs).
Wenn du das ohne void* schaffst, gehört die Kaffeekasse dir


Zugegeben, sowas braucht man eher selten, aber ich habe auch noch ein praxisrelevantes Beispiel für dich:

Nehmen wir an du schreibst einen Low-Level Treiber für irgendeine Schnittstelle, sagen wir mal SPI. An dieser Schnittstelle können unterschiedlichste Geräte hängen, die wiederum eigene Treiber benötigen welche auf dem SPI Treiber aufsetzen. Bei solchen Treibern ist es üblich mit Callback-Funktionen zu arbeiten, damit das System nicht bei jeder Übertragung blockiert wird. 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.

[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