Autor Thema: "assignment makes pointer from integer without a cast"  (Gelesen 9502 mal)

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #20 am: 28. April 2011, 22:09 »
Von dem Ergebnis bin ich aber doch ziemlich entsetzt. Vor allen das Ausgabe 2 und 4 das selbe Ergebnis liefern verstehe ich nicht. Den Ergebnistyp einer Addition muss der Compiler doch aus den beteiligten Operanden ableiten und da hätte ich nicht vermutet das der Compiler da eine Art Prioritätsentscheidung über beide Operanden macht, ich hätte mit "der Typ des linken Operand wird für das Ergebnis genommen" gerechnet.
So können sich Erwartungen unterscheiden. Ich hätte immer erwartet, dass eine Addition kommutativ ist. Pointer plus Zahl oder Zahl plus Pointer gibt wieder einen Pointer - was sollte auch sonst sinnvolles rauskommen dabei?

Zitat
Warum liefert Ausgabe 5 ein anderes Ergebnis? uintptr_t ist doch auch ein Pointer für ein 4 Byte großes Element oder etwa nicht?
uintptr_t ist ein Integertyp, der groß genug ist, dass man einen Pointer drin ablegen kann.

Zitat
Das ist auf jeden Fall ein Grund mehr warum ich VHDL so mag, VHDL ist wenigstens recht konsequent und verlässlich in seinem Verhalten. Da könnte man nie zwei unterschiedliche Datentypen einfach so mit einander Addieren.
Naja, zwei Pointer addieren wäre noch größerer Blödsinn. ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

MNemo

  • Beiträge: 547
    • Profil anzeigen
Gespeichert
« Antwort #21 am: 29. April 2011, 16:53 »
Von dem Ergebnis bin ich aber doch ziemlich entsetzt. Vor allen das Ausgabe 2 und 4 das selbe Ergebnis liefern verstehe ich nicht. Den Ergebnistyp einer Addition muss der Compiler doch aus den beteiligten Operanden ableiten und da hätte ich nicht vermutet das der Compiler da eine Art Prioritätsentscheidung über beide Operanden macht, ich hätte mit "der Typ des linken Operand wird für das Ergebnis genommen" gerechnet.
So können sich Erwartungen unterscheiden. Ich hätte immer erwartet, dass eine Addition kommutativ ist. Pointer plus Zahl oder Zahl plus Pointer gibt wieder einen Pointer - was sollte auch sonst sinnvolles rauskommen dabei?
Kommutativität ist etwas anderes: ∀ a,b ∊ X: a + b = b + a. Da passt der Fall nicht rein, weil a und b nicht aus der selben Menge sind. Es handelt sich praktisch um zwei verschiedene +. PTR + INT ist logisch und macht Sinn.
Aber die existens von "+: INT×PTR -> PTR" ist doch fragwürdig. Ich würde bei Addition erst einmal ein Neutrales Element und ein Inverses erwarten.

5 + (char*)0 = (char*)5 ≠ 5.
5 + (char*)1 - (char*)1 = (char*)6 - (char*)1 = ? 5 ¿

Deshalb würde ich da jetzt sowohl bei 5[ x], als auch bei 5 + x einen Compilere-ERROR für angebracht halten.
„Wichtig ist nicht, besser zu sein als alle anderen. Wichtig ist, besser zu sein als du gestern warst!“

DerHartmut

  • Beiträge: 236
    • Profil anzeigen
    • Mein Blog
Gespeichert
$_="krJhruaesrltre c a cnp,ohet";$_.=$1,print$2while s/(..)(.)//;
Nutze die Macht, nutze Perl ;-)

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #23 am: 29. April 2011, 20:02 »
Addition von Zeigern und Zahlenwerten hat auf jeden Fall die hier bereits beschriebenen Eigenschaften. Ihr seid hoffentlich auch alle froh, dass das so ist, denn ihr habt sicherlich schon mal Code geschrieben, der einen Zeiger inkrementiert oder dekrementiert hat.
Dieser Text wird unter jedem Beitrag angezeigt.

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #24 am: 02. May 2011, 12:26 »
Hallo,


das alles ist vermutlich der wesentliche Grund warum ich Pointer-Arithmetik immer vermeide.
Lieber mache ich einfor (uint i=0; i<length; i++) { data[i] = ???; }als einfor (; data<end_ptr; data++) { *data = ???; }bei Ersterem fühle ich mich einfach wohler und im Endeffekt ist es auch das was der Compiler meistens draus macht (deswegen haben moderne CPUs ja so tolle Adressierungsmodi).


Grüße
Erik (der jetzt wieder ein Grund mehr hat VHDL lieber zu haben als C)
Reality is that which, when you stop believing in it, doesn't go away.

 

Einloggen