zeiger

bist du sicher, daß du den Fall exakt nachgestellt hast (void-Zeiger)? Ich habe hier nur den VC6-Compiler, und der läßt folgendes problemlos zu:

void CopyFromFrame8900(void *Dest, unsigned int Size) 
{ 
   *((char*)Dest) = 'b';
   ...
   ...
}

und auch im Kontext ohne Funktion:

void* Dest;

*((char*)Dest) = 'b';

mir wäre auch völlig unklar, warum eine simple Dereferenzierung nicht modifizierbar sein sollte (wenn das dereferenzierte nicht gerade const ist, oder ähnliches)

Ich muß hinzufügen, daß ich bisher deutlich wenig mit ANSI-C99 zu tun hatte, da ich vermute, daß der Comeau-Compiler auch hier auf dem neuesten (ANSI-C99) Stand ist, so daß höchstens deswegen eine Erklärung für mich möglich ist.

Ich habe leider den gcc nicht hier, bin mir aber ziemlich sicher, diese Konstrukte schon selbst auch mit diesem Compiler ohne Probleme angewendet zu haben, als auch in anderem Code gesehen zu haben.

Jetzt habe ich doch noch einmal den ANSI-C99-Standard hervorgekramt, und finde folgendes:

A modifiable lvalue is an lvalue that does not have array type, does
not have an incomplete type, does not have a const-qualified type, and if it is a structure
or union, does not have any member (including, recursively, any member or element of
all contained aggregates or unions) with a const-qualified type.

durch das Casten auf char* fällt für mich die einzige Möglichkeit aus dem oben zitierten weg, daß diesen Fall zu einem nicht änderbaren lvalue macht (incomplete type)

und wenn ich die beiden obigen Code-Teile vom Comeau übersetzen lasse, bekomme ich diesen Fehler nicht, also muß irgendwo ein Unterschied zwischen unseren Test-Versionen sein

Also wenn du mir das erklären kannst (oder zumindest zeigen kannst, was du dem Comeau vorgesetzt hast, damit ich es nachvollziehen kann)

MfG

Krösus

Halte Dich an die Richtlinie aus der Schule, daß, wenn man einen Inkrement-Operator verwendet, in der betreffenden Programmzeile keine andere Operation stehen darf - sonst wird es unübersichtlich! Wer soll den so eine Konstruktion lesen und verstehen??? Du verstehst sie wahrscheinlich noch nicht einmal selbst! Was erst wirst Du selbst in ein paar Wochen sagen? Was wird Dein Kollege sagen, wenn er Dein Programm warten muß??

TheTester

das das beim gcc und beim vc von ms funktioniert...würd ich eher als "feature" anstelle von "standardkonform" bezeichnen...

bye

tt

TheTester schrieb:

das das beim gcc und beim vc von ms funktioniert...würd ich eher als "feature" anstelle von "standardkonform" bezeichnen...

dann erkläre mir, wo im Zitat aus dem Standard, das ich angegeben habe, zu erkennen ist, daß es kein modifizierbarer lvalue ist. Der Standard sagt, es ist ein modifizierbarer lvalue, denn alle Aussagen für diesen Fall stimmen mit dem Zitat überein...

MfG

ich habe das Gefühl, daß wir von verschiedenen Dingen sprechen:

natürlich ist:

(*(unsigned char *)Dest)++

kein lvalue, und damit erst recht kein modifizierbarer..

aber es ging ja um das Beispiel:

((char)Dest) = 'b'; // es geht um den Ausdruck ((char)Dest)

und da haben wir einen (modifizierbaren) lvalue.

Das ganze ist nur entstanden, da Shade Of Mine meinte, daß das hier:

((unsigned char)foo)

nur ein rvalue ist, ich denke, er meinte die Version mit anschließender Inkrementierung (siehe ganz oben, die dann natürlich auch vom Comeau-Compiler abgelehnt wird), dann kann man das so stehen lassen

MfG

Shade Of Mine

Probe-Nutzer schrieb:

ich habe das Gefühl, daß wir von verschiedenen Dingen sprechen:

Jo, hast recht. Mein Fehler.
Habs verwechselt. Sorry

Krösus

Meintest Du vielleicht sowas ähnliches?

* (unsigned char*) Dest = ReadFrame8900();
++Dest; //Fehler, void-Pointer können nicht inkrementiert werden

Einfachste Lösung, gut lesbar

unsigned char* pucDest = (unsigned char*) Dest;
*pucDest = ReadFrame8900();
Dest = pucDest + 1;

Lokale Variable sparen:

* (unsigned char*) Dest = ReadFrame8900();
Dest = ((unsigned char*) Dest) + 1;

Es gibt definitiv keinen Vorteil, alles in eine Zeile zu packen.
Ich habe den Eindruck, Du machst den beliebten Fehler, schon bei der ersten Implementierung zu versuchen, das allerletzte i-Tüpfelchen an Geschwindigkeit herauszukitzeln. Das ist falsch. Zuallererst einmal soll ein Programm laufen, seine Funktion erfüllen, sicher sein und lesbar und wartbar geschrieben sein. (Daher ist auch die theoretische Diskussion, ob so ein Konstrukt eventuell legal sein könnte, in der Praxis bedeutungslos - jeder Abteilungsleiter wird Dir schlicht und einfach verbieten, solchen Code zu produzieren!) Danach kann man versuchen, an den Stellen, wo es darauf ankommt und wo es was bringt, die Performanz zu steigern.

@Krösus:

waren deine beiden letzten Beiträge an mich gerichtet?

Wenn ja, dann hast du den falschen Adressaten erwischt, es ging mir ab meinem ersten Beitrag hier in diesem Thread nur um die Korrektheit eines bestimmten Konstrukts, nicht um irgendwelche stilistischen Aspekte der vorgestellten Code-Stücke und der Eingangsfrage. Da der Fragende, edka, sowieso den Wunsch geäußert hat, dies "übersichtlich" umzuschreiben, habe ich auch auf keinen deiner beiden Beiträge reagiert (denn du hast zu der Frage passende Anmerkungen gemacht), weil sie eigentlich nicht an mich gerichtet sein sollten, aus den oben genannten Gründen.

Das ist auch der Grund, warum ich immer ein "@Name:" oder ein Zitat bringe, damit klar ist, an wen etwas gerichtet ist. Solltest du mich nicht gemeint haben, dann vergiß diesen Beitrag, ansonsten denke an das zielgerichtete Posten von Antworten, damit keine Mißverständnisse aufkommen

MfG

Krösus

Probe-Nutzer: Meine Beiträge waren natürlich an Edka, den Verfasser (Stimmt das eigentlich? Oder ist er selbst der bedauernswerte Kollege, der so ein Programm-Machwerk ausmisten soll!) der Monster-Programmzeile, gerichtet!
Wenn Du Dich angegriffen gefühlt hast, dann bitte ich um Entschuldigung, das war von mir keinesfalls so gemeint!!!

Edka ist zumindest der Verfasser der ersten Frage, ob er sowas selber gebaut hat, oder jetzt Code "entziffern" muß, konnte ich aus seinem Beitrag nicht entnehmen

und natürlich habe ich mich nicht "angegriffen" gefühlt, ich bin in Foren schon ganz anders "angegriffen" worden (und habe "Angriffe" auf andere gesehen), dein Beitrag war sachlich genug gehalten, um sich nicht angegriffen zu fühlen (obwohl hier in den Programmier-Foren auch Worte wie "Unsinn", "Unfug" usw. fallen, was mir nicht gefällt. Wenn man den anderen schon länger "kennt" im Forum, dann kann man vielleicht einschätzen, daß der andere solche Worte nicht übel nimmt. Aber wenn man es mit (Foren-)Anfängern zu tun hat (und auch sonst hat nicht jeder das Niveau der Leute, die diese Worte benutzen), sollte man dies nicht benutzen, um damit die Leute nicht "abzuschrecken" oder "einzuschüchtern", so daß diese sich im Extremfall gar nicht mehr trauen, ins Forum zu schreiben. Ok, es gibt "schärfere Worte" als die genannten, dennoch würde ich es nie so schreiben, auch wenn es sich tatsächlich um "unsinnige" Code-Konstrukte oder -Konzepte handeln würde. Man kann auch ohne diese Deutlichkeit genau erklären, warum etwas völlig daneben ist (nicht schön ist es, wenn "Unsinn", "Unfug" usw. auch noch grundlos fallen, selbst wenn man sich dafür danach entschuldigt. Sowas kann man problemlos vermeiden, und keiner fühlt sich dann "angegriffen" oder steht als "Unwissender" da, mit den eventuell extremen Folgen wie oben erwähnt)). Nur war der Abstand zwischen deinen Beiträgen so groß, daß ich dachte (weil der Bezug für mich zur Ausgangsfrage (zeitlich) zu weit weg war), es ging um meine Antworten...

MfG