|
|
Forum: Compiler & IDEs Pointer-Konstrukt mit Array -> böse?Hallo, ich hätte eine Frage: Wird folgendes Konstrukt funktionieren? Ist es programmierstil-mässig böse?
Richtig?! Grüsse elektrodejns schrieb: > unsigned int my_val; > unsigned char my_val_a[2]; > > &my_val_a = &my_val; Jags mal durch den Compiler und sieh nach was er dazu zu sagen hat :-) Merk dir eine Grundregel in C: Arrays sind Bastarde. Es gibt praktisch nichts, was du mit einem Array als ganzes machen kannst. Auch Zuweisungen nicht. Und 2-tens (das dürfte die Idee in deinem Code gewesen sein): Wenn eine Variable eine Adresse hat, dann hat sie die. Die kriegt sie vom Compiler/Linker zugewiesen und es gibt nichts was du daran ändern könntest. Es mag zwar relativ naheliegend sein, eine Variable mittels int i; &i = 4711; an die Speicheradresse 4711 zu knüppeln, nur spielts das eben nicht. Danke. Karl Heinz Buchegger schrieb: > Jags mal durch den Compiler und sieh nach was er dazu zu sagen hat :-) Würd ich gern aber ein ich hab noch kein GCC auf einem HTC Android gesehen (bin mit m Handy online) Grüsse und nochmals Danke, ich verzieh mich jetz raus ausm Deutschunterricht in die Mittagspause. elektrodejns schrieb: > Grüsse und nochmals Danke, ich verzieh mich jetz raus ausm > Deutschunterricht in die Mittagspause. ausm Deutschunterricht, so so ... o tempora, o mores! ;-) Karl Heinz Buchegger schrieb: > Und 2-tens (das dürfte die Idee in deinem Code gewesen sein): Wenn eine > Variable eine Adresse hat, dann hat sie die. Die kriegt sie vom > Compiler/Linker zugewiesen und es gibt nichts was du daran ändern > könntest. Um genau zu sein, gibt es natürlich bei diversen Compilern Erweiterungen, mit denen man eine Variable bei der Definition an eine Speicheradresse nageln kann. Aber das geschieht bei der Definition. Im Nachhinein geht da nichts mehr. elektrodejns schrieb: > Würd ich gern aber ein ich hab noch kein GCC auf einem HTC Android > gesehen (bin mit m Handy online) Aber online gibt es sowas: http://codepad.org/ > ich verzieh mich jetz raus ausm > Deutschunterricht in die Mittagspause. Wie, du nutzt den Deutschunterricht um im Forum zu surfen? :-) > unsigned int my_val; > unsigned char my_val_a[2]; > > &my_val_a = &my_val; Offenbar versuchst du da gerade die "union" neu zu erfinden. Das über eine Union zu machen ist zwar streng genommen nicht koscher, aber so dermaßen weit verbreitet, dass du das bedenkenlos machen kannst. Noch besser wäre es natürlich, es standardkonform und portabel per Shift&Mask zu machen. Stefan Ernst schrieb: > aber so dermaßen weit verbreitet, dass du das bedenkenlos machen kannst. What?!?! Nur weil es so viele (falsch) machen ist garantiert, dass es funktioniert? Also soweit ich im Programmierbusiness bin, funktioniert Programmierung so nicht. Garantiert ist nur das, was der C-Standard da sagt. Und der garantiert sowas eben nicht. Simon K. schrieb: > Stefan Ernst schrieb: >> aber so dermaßen weit verbreitet, dass du das bedenkenlos machen kannst. > > What?!?! Nur weil es so viele (falsch) machen ist garantiert, dass es > funktioniert? Also soweit ich im Programmierbusiness bin, funktioniert > Programmierung so nicht. > Garantiert ist nur das, was der C-Standard da sagt. Und der garantiert > sowas eben nicht. Ich bin durchaus bei dir, was Beachtung dessen betrifft, was vom Standard zugesagt wird und was nicht. Allerdings stimmt es schon, was Stefan sagt: Diese Union-Überlagerung gibt es, seit es C gibt. Es ist kein einziger Compiler bekannt, bei dem die Dinge nicht so funktionieren würden (und es gibt auch keinen wirklichen technischen Grund dafür). De facto hat sich hier die 'normative Kraft des Faktischen' eingebürgert, so dass eher zu erwarten ist, dass ein Compilerhersteller dieses Feature 'nachrüstet', anstatt alle vor den Kopf zu stossen, falls es mal notwendig sein sollte. Warum es dann nicht im Standard steht? Weil es formal gesehen eigentlich falsch ist und man damit etwas fordert, was man tunlichst aus dem Standard raushalten will. Im Standard wurde viel wert darauf gelegt, dass Maschinenabhängigkeiten möglichst draussen bleiben (der Standard lässt zb die Frage nach der Darstellung von negativen Zahlen völlig aussen vor. Trotzdem programmieren wir immer so, als ob 2-er Komplement garantiert wäre). Im Standard gibt es keine Zusicherung, dass ein C-Byte dasselbe wie ein Byte auf physikalischer Ebene ist. Und ohne diese Zusicherung ist es schwierig zu definieren, wie so eine Überlagerung funktionieren soll. elektrodejns schrieb: > &my_val_a = Das ist ungefähr so, als würde ich mir die Schuhe ausziehen und an den Urlaubsort schicken, statt selber zu fahren. Eine Adresse kann niemals das Ziel einer Operation sein, sondern nur Quelle. Sie ist ja nichtmal eine Variable, sondern wird vom Linker ausgerechnet und eingesetzt. Peter elektrodejns schrieb: > Würd ich gern aber ein ich hab noch kein GCC auf einem HTC Android > gesehen (bin mit m Handy online) Büdde: http://forum.xda-developers.com/showthread.php?t=1645182 Und fang ja net mit "Russencode" an wo in einer Zeile C die Opcodes direkt auf'n bestimmten µC "optimiert" werden und keine Sau weiß welcher µC das eigentlich sein soll m( elektrodejns schrieb: > Ist es programmierstil-mässig böse? Es ergibt schlicht keinen Sinn. > &my_val_a = &my_val; Das ist ähnlich also ob du schreibst:
und dann erwartet, daß fortan nun 5 das selbe ist wie 7. Prinzipiell kann man sowas ja schon machen, nicht ohne Grund nennen manche C einen "besseren Makro Assembler" Vielleicht ist es auch ein klein wenig schneller als shift & mask. (Würd ich nicht wetten, Compiler sind manchmal recht clever.) Wenn es denn sein muss würde ich es über eine Union machen. Dann ist einigermaßen offensichtlich, dass es hier 2 unterschiedliche Zugriffswege auf die selben Daten gibt. + Kommentar warum und weshalb. ABER: Portabel ist der Code damit nicht mehr zwingend. Wenn sich die Byte-Order der Platform ändert kann es Probleme geben. Ich bin da mal böse auf die Nase gefallen. Simuliert auf der Entwicklungsumgebung hat alles funktioniert, auf der Zielplatform ging gar nichts. Und es gab keinen Debugger, kein Log, nichts. Ich hab' dann ne Debug-LED angelötet und erst nach Stunden rausgefunden, dass der Simulator die Byte-order der Zielplatform nicht richtig simuliert hat. Grüße, Joey Tilo Renz schrieb: > Prinzipiell kann man sowas ja schon machen, nicht ohne Grund nennen > manche C einen "besseren Makro Assembler" Haha, großartig. 20 Posts darüber, dass es totaler Unsinn ist und dann findet sich doch noch jemand, der meint, dass man das machen kann. 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