|
|
Forum: PC-Programmierung Typenwandlung uint zu uchar[2]Hallo, gibt es für die o.g. Typenwandlung eine elegantere Methode, als diese:
Viele Grüße Vor allem gibt es welche, die richtig sind. Entweder mit union oder mit Zeiegrn udn ein paar casts. Dieses Forum ist ziemlich voll von sehr ähnlichen Fällen. Warum? Es kommt drauf an, was er will und wie man mit union arbeitet. Auf jeden Fall hast du insofern recht, als es nicht mit Union geht, sondern bestenfalls mit union :-) Weil dein Vorschlag beinhaltet, in die eine Variante der Union zu schreiben und aus der anderen zu lesen. Und das ist undefined behaviour, auch wenn die meisten Leute das einfach nicht einsehen wollen. Und Substantive werden im Deutschen übrigens groß geschrieben. Martin schrieb: > Weil dein Vorschlag beinhaltet, in die eine Variante der Union zu > schreiben und aus der anderen zu lesen. > > Und das ist undefined behaviour, auch wenn die meisten Leute das einfach > nicht einsehen wollen. Dem Gesetz nach hast du Recht. Allerdings greift hier die normative Kraft des Faktischen. Besagtes Konstrukt wird seit Anbeginn der C-Welt so benutzt. Jeder Compilerbauer würde sich ins eigene Knie schiessen, wenn er hier absichtlich einen Problemkreis aufmacht. Denn: die für den Compilerbauer einfachste Variante ist es, wenn genau dieses Konstrukt (als Nebeneffekt) funktioniert. Selbst die Jungs in comp.lang.std.c-c++ (und da hängen immerhin diejenigen rum, die den Standard machen), haben längst aufgegeben dieses Konstrukt als Fehler zu werten. Sie machen eine Fussnote, dass es eigentlich nicht ganz korrekt ist, aber sie machen da schon seit Jahren kein Drama mehr draus. Bzw. wenn ich so zurückdenke, haben sie da nie ein Drama draus gemacht. undefiniert ist es deshalb, weil man zb mit einer union aus double und einem unsigned char Array eben nicht garantieren kann, dass jede Bytefolge, die ich da reinschreibe auch zu einem gültigen double führt. Aus diesem und ähnlichen Gründen kann diese Benutzung einer union nicht legalisiert werden. Martin schrieb: > Und das ist undefined behaviour, auch wenn die meisten Leute das einfach > nicht einsehen wollen. Die Annahme, daß man solche Fummeleien immer portabel haben müsste, ist ebenso verbreitet. Viele wollen nicht einsehen, daß ein Programm für einen MC ohnehin nur sehr bedingt portabel ist. Also geht es ggf. nicht darum, was der C-Standard sagt, sondern wie es auf dem vorhandenen System aussieht. Und damit geht es nicht mehr um eine undefined beh. von ISO-C, sondern um ein sehr definiertes Verhalten des gcc oder was auch immer. Ich bin ja auch ein Freund von Standards und portablen Programmen, aber wenn man beschließt, auf die Bytes einer int zuzugreifen, dann ist es eh Essig mit C-Standard und der Hinweis darauf für die Katz'. "nicht richtig" wird damit zu einer eher subjektiven Aussage, die für sich genommen nicht viel hilft. Sinnvoller wäre höchstens der Hinweis, daß es damit nicht mehr portabel ist. Ist natürlich nur meine Meinung. Martin schrieb: > Und Substantive werden im Deutschen übrigens groß geschrieben. In C aber nicht. :-) Karl Heinz Buchegger schrieb: > Dem Gesetz nach hast du Recht. > > Allerdings greift hier die normative Kraft des Faktischen. Mag ja alles sein, aber gerade auch hier im Forum hat sich so eine "Scheißegal, wir fummeln es solange hin, bis die LED blinkt"-Mentalität festgesetzt. Wenn man weiß, was C garantiert und was nicht, kann man sich die ein oder andere Freiheit erlauben. Wenn man es von vorneherein falsch lernt, dann wird man an einer ganz anderen Ecke plötzlich heftig auf die Nase fallen, weil das "Gelernte" eben einfach Bullshit war. Martin schrieb: > Karl Heinz Buchegger schrieb: >> Dem Gesetz nach hast du Recht. >> >> Allerdings greift hier die normative Kraft des Faktischen. > > Mag ja alles sein, aber gerade auch hier im Forum hat sich so eine > "Scheißegal, wir fummeln es solange hin, bis die LED blinkt"-Mentalität > festgesetzt. Geb ich dir recht. Aber in diesem konkreten speziellen Fall bellst du den falschen Baum hinauf. >Wenn man weiß, was C garantiert und was nicht, kann man sich die ein >oder andere Freiheit erlauben. Wo ist denn dann da die Freiheit? Wenn man genau das macht was garantiert ist nimmt man sich / erlaubt man sich keinerlei Freiheit. >aber gerade auch hier im Forum hat sich so eine "Scheißegal, wir fummeln es >solange hin, bis die LED blinkt"-Mentalität festgesetzt. Dem kann ich so nicht zustimmen. Gerade hier und hier vor allem Falk, Karl Heinz und Lothar sind diejenigen die hier immer wieder auf formal unkorrekte bzw. bedenkliche sprachliche Konstrukte hinweisen. >Mag ja alles sein,... Was soll das also nun heissen? Ich gebe zu bedenken, das zwischen formal unkorrekten Konstrukten die seit jahrzehnten angewendet werden und von Compilern unterstützt werden und solchen die erst gestern erfunden und mit nur zwei Compilern getestet wurden wohl doch ein Unterschied besteht der in Konsequenz bei dem einen möglicherweise einen Hinweis plausibel macht aber nur in dem anderen Fall Beiträge wie Deine. Heinz schrieb: >>Wenn man weiß, was C garantiert und was nicht, kann man sich die ein >>oder andere Freiheit erlauben. > > Wo ist denn dann da die Freiheit? Wenn man genau das macht was > garantiert ist nimmt man sich / erlaubt man sich keinerlei Freiheit. > >>aber gerade auch hier im Forum hat sich so eine "Scheißegal, wir fummeln es >>solange hin, bis die LED blinkt"-Mentalität festgesetzt. > > Dem kann ich so nicht zustimmen. Gerade hier und hier vor allem Falk, > Karl Heinz und Lothar sind diejenigen die hier immer wieder auf formal > unkorrekte bzw. bedenkliche sprachliche Konstrukte hinweisen. @Martin. Damit das aber nicht in den falschen Hals kommt. Ich (und sicher auch die anderen) würden uns freuen, wenn wir einen weiteren Mitstreiter zum Thema "gutes und standardkonformes C" bekommen. Denn in einem Punkt hast du natürlich recht: Es ist schon abenteuerlich, welches noch nicht mal Viertelwissen hier im Forum immer wieder durchkommt. Wenn wir es schaffen, dass die Promotionregeln einigermassen sitzen, dann ist vielerorts schon einiges erreicht. Klaus Wachtler schrieb: > Also geht es ggf. nicht darum, was der C-Standard sagt, sondern wie es > auf dem vorhandenen System aussieht. Es gibt in C den vorgesehenen Weg, und es gibt den Weg über unions. Nur weil die auf dem vorhandenen System auch funktionieren, muß ich die doch nicht unbedingt dafür einsetzen. > Ich bin ja auch ein Freund von Standards und portablen Programmen, aber > wenn man beschließt, auf die Bytes einer int zuzugreifen, dann ist es eh > Essig mit C-Standard und der Hinweis darauf für die Katz'. Deshalb muß man ja nicht gleich komplett alles über Bord werfen. Martin schrieb: > Ich schreib > > Klaus Wachtler schrieb: >> In C aber nicht. :-) > > Ich schreibe hier Deutsch, nicht C. Du meintest aber sicherlich nicht das deutsche Wort "Union", sondern das Schlüsselwort aus C, oder? Heinz schrieb: >>aber gerade auch hier im Forum hat sich so eine "Scheißegal, wir fummeln >>es solange hin, bis die LED blinkt"-Mentalität festgesetzt. > > Dem kann ich so nicht zustimmen. Gerade hier und hier vor allem Falk, > Karl Heinz und Lothar sind diejenigen die hier immer wieder auf formal > unkorrekte bzw. bedenkliche sprachliche Konstrukte hinweisen. Ja, um eben diesem Trend entgegenzuwirken. Rolf Magnus schrieb: > Klaus Wachtler schrieb: >> Also geht es ggf. nicht darum, was der C-Standard sagt, sondern wie es >> auf dem vorhandenen System aussieht. > > Es gibt in C den vorgesehenen Weg, und es gibt den Weg über unions. Nur > weil die auf dem vorhandenen System auch funktionieren, muß ich die doch > nicht unbedingt dafür einsetzen. Nein, muß man nicht. > >> Ich bin ja auch ein Freund von Standards und portablen Programmen, aber >> wenn man beschließt, auf die Bytes einer int zuzugreifen, dann ist es eh >> Essig mit C-Standard und der Hinweis darauf für die Katz'. > > Deshalb muß man ja nicht gleich komplett alles über Bord werfen. Nein, muß man nicht. Ich habe nie behauptet, daß unions generell besser sind für einen solchen Fall. Sie sind aber eine Möglichkeit (neben shiften und unions gibt es noch mehr). Aber alle Methoden haben Vor- und Nachteile, und ich will nur behaupten, daß Portabilität auf einem MC nicht unbedingt das alleinige Kriterium ist. Wenn man damit auf einem AVR umständliches Shiften umgehen kann, KANN es mit union sinnvoller sein. Deshalb finde ich so eine pauschale (Nicht-) Aussage: Martin schrieb: > Mit Union ist es jedenfalls schonmal nicht richtig. vollkommen überflüssig (vorsichtig formuliert). Nur weil man mal (weitgehend zu Recht) gelernt hat, daß portabel und standardkonform toll ist, zeugt es nicht von Intelligenz, das gleich als Totschlagargument zu mißbrauchen, ohne je darüber nachgedacht zu haben. Reflexe aus dem Rückenmark sind meistens schlecht beim Programmieren, mehr sehe ich nicht in diesem Beitrag. Rolf Magnus schrieb: > Ja, um eben diesem Trend entgegenzuwirken. Den unterstütze ich auch ausdrücklich. Dann aber bitte mit dem richtigen Hinweis, daß es eben nicht portabel ist, und nicht mit dem Blödsinn, daß es nicht ginge - ohne jede Begründung, wie man sich zu dem Quark verstiegen hat. Ganz abgesehen davon, daß so eine Diskussion schon zigfach durchgekaut wurde und wohl nie enden wird, weil immer wieder jemand sich weigert, mal die bisherigen Threads dazu zu suchen, und neben den sinnvollen Aussagen dazu auch genauso regelmäßig der Unfug hervorgewürgt wird. Klaus Wachtler schrieb: > Aber alle Methoden haben Vor- und Nachteile, Wenn wir mal von int und long weg verallgemeinern, also auch double in den Problemkreis mit hineinziehen, gibt es keinen standardkonformen Weg, um auf die einzelnen Bytes eines Datentyps zuzugreifen. Das ist nun mal so. Auch Pointer umcasten ist kein gültiger Weg. Daher sind unions genauso gut oder schlecht wie alles andere. Für int/long bleibt natürlich noch die Möglichkeit von Division zur Zerlegung und Multiplikation zum Zusammensetzen. Bei float/double geht das aber nicht. Karl Heinz Buchegger schrieb: > Wenn wir mal von int und long weg verallgemeinern, also auch double in > den Problemkreis mit hineinziehen, gibt es keinen standardkonformen Weg, > um auf die einzelnen Bytes eines Datentyps zuzugreifen. Das ist nun mal > so. Das stimmt nicht. Siehe Kapitel 6.2.6.1: "Values stored in non-bit-field objects of any other object type consist of n × CHAR_BIT bits, where n is the size of an object of that type, in bytes. The value may be copied into an object of type unsigned char [n] (e.g., by memcpy); the resulting set of bytes is called the object representation of the value." Wie die "object representation" genau aussieht, ist natürlich plattformabhängig, aber es gibt einen konformen Weg, um dranzukommen. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten