amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Der Dereferenzierungsoperator [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

25.09.2002, 21:16 Uhr

eliotmc
Posts: 925
Nutzer
Hallo,
ich habe vor krzem angefangen C zu lernen,
habe aber einige Verstanädnis Probleme was Zeiger
und Vektoren in ansi c angeht. Ich hoffe, dass
hier jemand etwas Lich ins Dunkle bringen kann!

Ich habe folgendes Programm Fragment:

int x, *y;
y=&x;
*y=20
printf("Inhalt von x = %i", *y);

Dann wird ausgegeben: Inhalt von x = 20
Das ist soweit auch logisch.
Aber jetzt folgendes:

int x, *y;
y=&x;
scanf("%i", y); <---
printf("Inhalt von x = %i", *y);

Dann wird auch ausgegeben: Inhalt von x = 20
Und jetzt meine Frage:
Warum habe ich bei scanf keinen Dereferenzierungsoperator???
Ich möchte doch den inhalt von x verändern!
Müßte es nicht eigentlich heißen:

int x, *y;
y=&x;
scanf("%i", *y); <---
printf("Inhalt von x = %i", *y);

Was natürlich falsch ist, aber warum???
Ich hoffe, dass das mir jemand erklären kannt.
Vielen Dnak im Voraus!
--
Andre Geisler
Email: eliot@eanet.de
UIN : 107806494
URL : http://www.eanet.de/user/eliot/

[ Dieser Beitrag wurde von eliotmc am 25.09.2002 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

25.09.2002, 21:27 Uhr

AC-FoX
Posts: 35
Nutzer
Öhm, wo kommt denn das "z" her? Ich denke mal, das soll "y" heissen, oder?
Das zu %i gehörende Argument ist vom Typ int*. Es ist also vollkommen korrekt, einen Pointer bei scanf anzugeben. Die Funktion muß ja die Speicherstelle wissen, wo sie das Ergebnis hinschreiben soll.

Grüzi

[ - Antworten - Zitieren - Direktlink - ]

25.09.2002, 21:40 Uhr

eliotmc
Posts: 925
Nutzer
>Öhm, wo kommt denn das "z" her? Ich denke mal, das soll "y" heissen, oder?

Ja, sollte y heißen!

>Das zu %i gehörende Argument ist vom Typ int*. Es ist also vollkommen korrekt, einen Pointer bei scanf anzugeben. Die Funktion muß ja die Speicherstelle wissen, wo sie das Ergebnis hinschreiben soll.

Wenn ich das aber kopiliere, läuft das Programm aber nicht,
sondern nur, wenn ich es ohne Pointer kopiliere.
--
Andre Geisler
Email: eliot@eanet.de
UIN : 107806494
URL : http://www.eanet.de/user/eliot/

[ - Antworten - Zitieren - Direktlink - ]

25.09.2002, 22:15 Uhr

AC-FoX
Posts: 35
Nutzer
Also dann erzähl mal, welche Konstellation du mit nicht-lauffähig meinst.
scanf("%i",*y); sollte nicht funktionieren, da y ja schon ein Pointer ist.
scanf("%i",y); müßte funktionieren, da der Wert von y die Addresse von x ist.
Dementsprechend müßte auch scanf("%i",&x); funktionieren.

Grüßli

[ - Antworten - Zitieren - Direktlink - ]

25.09.2002, 22:26 Uhr

eliotmc
Posts: 925
Nutzer
> Also dann erzähl mal, welche Konstellation du mit nicht-lauffähig meinst.
> scanf("%i",*y); sollte nicht funktionieren, da y ja schon ein Pointer ist.

Genau, funktioniert nicht.

> scanf("%i",y); müßte funktionieren, da der Wert von y die Addresse von x ist.

Ja, funktioniert.

> Dementsprechend müßte auch scanf("%i",&x); funktionieren.

Ja, funktioniert auch.

Ich probiere die Frage nochmal deutlicher zu stellen:

Folgendes.

1.
int x, *y;
y=&x;
*y=20;

und

2.
int x, *y;
y=&x;
scanf("%i", y);

Warum habe ich bei 1. *y=20 ein Derefernezierungsoperator und
bei 2. scanf("i", y) keinen???
Das Ergebnis ist doch das selbe, ich weise über Y (welches die
Addresse von x gespeichert hat), x einen Wert zu?
Warum benutze ich bei scanf() also nicht auch *????

btw.

würde auch folgendes funktionieren?

3.
int x, *y;
y=&x;
scanf("%i", &y);

Aber wahrscheinlich nicht, oder???
--
Andre Geisler
Email: eliot@eanet.de
UIN : 107806494
URL : http://www.eanet.de/user/eliot/

[ - Antworten - Zitieren - Direktlink - ]

25.09.2002, 23:13 Uhr

David
Posts: 65
Nutzer
y ist ein Zeiger der, nur die Adresse im Speicher enthält
würdest du y=20 schreiben (ohne würdest du nur die Adresse ändern)
mit y=&x übergibts du nur die Speicheradresse an y aber nicht
den Wert.

warum bei scanf keinen *
scanf erwartet nur die Adresse die ja y enthält.

bei 3. (&y) würde scanf die Adresse erhalten wo y im Speicher
ist, also würde 3. nicht den gewünschten Effekt haben.

mfg
David

[ - Antworten - Zitieren - Direktlink - ]

25.09.2002, 23:16 Uhr

AC-FoX
Posts: 35
Nutzer
Alsooooooo
Am Anfang waren die Dinosaurier, doch die starben aus, weil sie zu fett waren...

Die Pointergeschichte wieder :)

"Jetzt stelle wir uns mal janz doof. Wat is denn so ein Pointer, und wat macht der so den lieben langen Tag?"
Eine Variable, die ma mit "int x" anlegt, ist nichts weiter, als ein Speicherbereich (in diesem Falle 4 bytes, weil 32 bit zahl), in dem eine Zahl abgespeichert werden kann.
Dieser Speicherbereich hat eine Addresse. Also wie eine normale Hausaddresse. Und jetzt kommt der Trick. Eine Addresse, die man speichern oder verarbeiten will, ist auch eine 32bit Zahl.
So, und diese Addressenangabe kann man jetzt eben auch wieder in einer Variable speichern.

"So und dat iss nu ein Pointer?"
Deine Variable x, beinhaltet also die Zahl 20. Die Variable y beinhaltet die Addresse, an der die variable x im Speicher liegt. Das wäre irgendwas wie z.B. 0x4c674680.
Wenn du jetzt ein x=20; machst, dann wird an diese Speicherstelle die zahl 20 geschrieben. Der Compiler weiß selbst, wo er hinschreiben muß.
Du kannst aber auch *y=20; machen. In diesem Fall ist y immernoch die Adresse auf x (also 0x4c674680). Durch den Dereferenzierungsoperator weiß jetzt der Compiler aber, daß er nicht direkt diesen Wert überschreiben darf, sondern, daß y nur ein Pointer ist.
Er nimmt also die Zahl 0x4c674680 und interpretiert es als Addresse. Und an diese Addresse schreibt er jetzt den Wert 20. Deshalb bekommst du auch 20 als resultat, wenn du x abfragst.

"Ja, aber wat hat denn jetzt scanf() wieder für ein Problem? Des versteh ich nett!"
Die Funktion übernimmt Parameter als Eingangswerte. Du könntest x irgendeiner Funktion übergeben, aber dann würde nur der Wert, der in x gespeichert ist, übergeben. Doch die Funktion soll ja den Wert in x verändern. Also interessiert es sie nicht, was früher mal in x stand, sondern sie braucht die Information, wo x ist, damit sie den neuen Wert dorthin schreiben kann.
Bei scanf("%i",x); sagst du der Funktion also eigentlich scanf("%i",20);. Und das ist natürlich total nutzlos.
Bei scanf("%i",&x); sagtst du scanf("%i",0x4c674680);. Das ist genau das gleiche wie scanf("%i",y);.
Man beachte den Unterschied zu scanf("%i",*y);. Denn das wäre ja wieder 20 als Parameter.
Auch falsch ist scanf("%i",&y);. Denn in dem Fall übergibst du die Addresse von y. Prinzipiell nicht schlecht, aber dann würde die Funktion scanf den neuen Wert nicht in x speichern, sondern in y.
Ganz schlimm wirds bei scanf("%i",x);. Hier übergibst du die zahl 20 als Addresse. Dann schreibt scanf auch an die Addresse 20 im Speicher. Das könnte zu ganz miesen Abstürzen führen, und wirft mindestens einen Enforcer Hit.
Was ein Enforcer Hit ist, das erzähl dir ich in der nächsten Folge von "Programmieren leicht gemacht und umsonst".

Grüzi

[ Dieser Beitrag wurde von AC-FoX am 25.09.2002 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.09.2002, 10:26 Uhr

eliotmc
Posts: 925
Nutzer
Vielen Dank an euch alle,
ich habe es jetzt verstanden :)


--
Andre Geisler
Email: eliot@eanet.de
UIN : 107806494
URL : http://www.eanet.de/user/eliot/

[ - Antworten - Zitieren - Direktlink - ]

28.09.2002, 09:45 Uhr

Flinx
Posts: 1073
Nutzer
Eigentlich müßte ja nachträglich noch jemand Kernighan oder Ritchie auf die Zehen treten.
Denn dadurch, daß scanf() nur Zeiger als Argumente erwartet und damit die Syntax von printf() abweicht (obwohl es praktisch die Funktionen in umgekehrter Richtung zur Verfügung stellt), haben sie Generationen von C-Lernenden verwirrt...


[ Dieser Beitrag wurde von Flinx am 28.09.2002 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.10.2002, 00:21 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Flinx:
Eigentlich müßte ja nachträglich noch jemand Kernighan oder Ritchie auf die Zehen treten.
Denn dadurch, daß scanf() nur Zeiger als Argumente erwartet und damit die Syntax von printf() abweicht (obwohl es praktisch die Funktionen in umgekehrter Richtung zur Verfügung stellt), haben sie Generationen von C-Lernenden verwirrt...

Und weil scanf() die Richtigkeit der Pointertypen nicht überprüft, es prinzipiell überhaupt nicht kann, läuft ein Programm schon bei den kleinsten Fehlern Amok. Deshalb gibt es eine grundsätzliche Regel für den Umgang mit scanf(): Benutze es niemals!
Also, zum C-Lernen mags noch erträglich sein, sobald man über das zehnzeiler-Stadium hinaus ist und Alternativen kennt, ist der Moment gekommen, sich von dem Bufferoverflow-Generator namens scanf() abzuwenden.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

06.10.2002, 14:25 Uhr

Xin
Posts: 28
Nutzer
Zitat:
Original von Flinx:
Eigentlich müßte ja nachträglich noch jemand Kernighan oder Ritchie auf die Zehen treten.
Denn dadurch, daß scanf() nur Zeiger als Argumente erwartet und damit die Syntax von printf() abweicht (obwohl es praktisch die Funktionen in umgekehrter Richtung zur Verfügung stellt), haben sie Generationen von C-Lernenden verwirrt...


Kerningham & Ritchie kann man wegen vielem auf die Zehen treten, aber hätten Sie Deinem Vorschlag entsprochen, dann erst recht.
Es weicht nämlich eben nicht von printf() ab!

Bekanntlich muß scanf() wissen wohin es die gelesenen Werte schreiben soll - also ein Zeiger. Würde ich die Integer Variable schreiben wollen, interessiert mich doch nicht der Inhalt einer Variable, von der ich innerhalb scanf() nichtmal mehr etwas wüßte.

Hinweis: Bei Funktionsaufrufen werden die Variablen kopiert.
printf() muß also nicht wissen, wo das steht, es reicht zu wissen, was geschrieben werden soll. Wäre Dein Modell gültig, würde ich die Kopie überschreiben, die nach Verlassen der Funktion scanf() dann zerstört wird. <daumen hoch> ;) )

Für Rückgabewerte in der Parameterliste wird man immer Zeiger brauchen müssen. Auch wenn sie in Pascal 'var' heißen, es bleiben Zeiger. Entsprechendes gilt für die Krankheit Java - umbenennen des Problems ist nicht immer die Lösung - manche Sachen muß man einfach verstehen und perfekt und zweifelsfrei beherschen, um zu Programmieren.

--
Mit freundlichem Gruß
Sascha 'Xin' Atrops

[ - Antworten - Zitieren - Direktlink - ]

06.10.2002, 15:02 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Xin:
Für Rückgabewerte in der Parameterliste wird man immer Zeiger brauchen müssen. Auch wenn sie in Pascal 'var' heißen, es bleiben Zeiger. Entsprechendes gilt für die Krankheit Java - umbenennen des Problems ist nicht immer die Lösung - manche Sachen muß man einfach verstehen und perfekt und zweifelsfrei beherschen, um zu Programmieren.

Wenn Du Dich unbedingt auf dieses Glatteis begeben mußt: In Java gibt es weder Pointer auf primitive Datentypen noch dereferenzierte Objekte. Es ist also in keinster Weise mit C vergleichbar, das hat nichts mit Umbenennen zu tun. Wenn Du also mit diesem Halbwissen Java als Krankheit bezeichnest, ist das eher eine Pluspunkt für Java.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

17.10.2002, 15:33 Uhr

Xin
Posts: 28
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von Xin:
Für Rückgabewerte in der Parameterliste wird man immer Zeiger brauchen müssen. Auch wenn sie in Pascal 'var' heißen, es bleiben Zeiger. Entsprechendes gilt für die Krankheit Java - umbenennen des Problems ist nicht immer die Lösung - manche Sachen muß man einfach verstehen und perfekt und zweifelsfrei beherschen, um zu Programmieren.

Wenn Du Dich unbedingt auf dieses Glatteis begeben mußt: In Java gibt es weder Pointer auf primitive Datentypen noch dereferenzierte Objekte. Es ist also in keinster Weise mit C vergleichbar, das hat nichts mit Umbenennen zu tun. Wenn Du also mit diesem Halbwissen Java als Krankheit bezeichnest, ist das eher eine Pluspunkt für Java.

Solange Anweisungen wie "a=a+b;" und "a+=b;" unterschiedliche Ergebnisse liefern, bleibt Java in meinen Augen eine Krankheit.
Bei einer gewachsenen Sprache könnte ich es vielleicht noch halbwegs verstehen, aber nicht in einer neukonzeptionierten Sprache.
Einen '->' Operator in '.' umzubenennen ist in meinen Augen nicht die Lösung zukünftiger Softwareprobleme. Pointer bleibt Pointer.
Also bitte keine Halbwissenunterstellungen in der Form.

Ich würde mich nicht als Java-Experte bezeichnen, mein letztes Java Projekt war eine datenbankgestützte Hochregallagersteuerung/-verwaltung. Kein wirkliches Problem, aber auch kein Anfängerzweizeiler. Es bleibt auch mein letztes Projekt, weil ich mich weigere noch etwas in Java zu entwicklen.

--
Mit freundlichem Gruß
Sascha 'Xin' Atrops

[ - Antworten - Zitieren - Direktlink - ]

17.10.2002, 15:42 Uhr

Xin
Posts: 28
Nutzer
Bevor weitere Comments bezüglich "a=a+b;" und "a+=b;" kommen...

Ein Statement ist ein Statement und sollte nicht abhängig von der Position im Sourcecode oder dessen Schreibweise zu unterschiedlichen Ergebnissen führen:

Beispiel:
char func(char c)
{ int x = 0;
return( 'A'+x ); }
- bricht mit der Fehlermeldung ‘Cast erforderlich’ ab.
char func(char c)
{ int x = 0;
c = 'A' + x;
return( c ); }
- bricht ebenfalls mit der Fehlermeldung ‘Cast erforderlich’ ab.

Daraus ist zu schließen, dass die Expression 'A'+x keinen akzeptierten Wert darstellt. Wenn aber ein char und ein int nicht mit dem +-Operator verbunden werden dürfen, dann ist es meines Erachtens der += konsequenterweise auch nicht in der Lage diese Datentypen zu verbinden:

char func(char c)
{ int x = 0;
c = 'A';
c += x;
return( c ); }

Dieser Code wird vom Java-Compiler anstandslos verarbeitet.


Der Test fand unter Verwendung von 'javac' auf einem Linux-System statt.
--
Mit freundlichem Gruß
Sascha 'Xin' Atrops

[ - Antworten - Zitieren - Direktlink - ]

19.10.2002, 12:36 Uhr

Holger
Posts: 8116
Nutzer
@Xin:
Offenbar kann man auch mit Halbwissen größere Programme schreiben. Schlimmer ist aber, daß Du trotz der genannten Unterschiede aus meinem letzten Posting, auf die Du erst gar nicht eingehst, immer noch an Deiner absurden Umbenennungstheorie festhälst. Für den Fall, daß Du diesmal die Punkte liest und versuchst, mal darüber nachzudenken, bevor Du antwortest, hier noch etwas detailierter:

C++ unterstützt Zugriffe
  • dereferenziert (direkt)
  • über Pointer
  • über Referenzen
    sowohl für primitive Datentypen als auch für Objekte. Dementsprechend sind folgende Operationen möglich:
  • Addresse ermitteln '&'
  • Dereferenzieren '*'
  • Zugriff auf Elemente direkt oder Referenz '.'
  • Zugriff auf Elemente über Pointer '->'

    Java unterstützt Zugriffe
  • direkt auf primitive Datentypen
  • über Referenz für Objekte
    und zwar ausschließlich. Dementsprechend gibt es folgende Operation:
  • Zugriff auf Element über Referenz '.'

    ---------

    In C++ ist folgendes möglich:
  • Typecast von Pointertypen mit zueinander inkompatiblen Basistypen
  • Typecast von Pointern mit const-Basistyp auf nicht-const zur Umgehung von const
  • Erhöhen und Erniedrigen eines Pointers um den Speicherbedarf des Basistyps
  • Beliebige Konvertierung von Pointern nach int und umgekehrt
  • Zugriff auf eigentlich schon gelöschte Objekte oder nicht initialisierte Pointer
  • Erzeugen von flachen Kopien der Objektdaten durch Zuweisung der dereferenzierten Objekte

    Davon ist in Java folgendes möglich:
  • Nichts


    Hier von einer Umbenennung eines Operators zu reden, ist totaler Schwachsinn. Java Referenzen haben deutlich mehr mit C++ Referenzen gemeinsam, nur das ihnen eben nach der Initialisierung erneut eine Referenz zugewiesen werden kann.

    -----------------
    Zu Deinem Operator-Mysterium: Du vergleichst Äpfel mit Birnen.a+=b ist nicht eine Kurzschreibweise für a=a+b. '+=' ist ein eigenständiger Operator, und das Verhalten ist genau definiert. Setze für 'a' mal 'x[k++]' für ein array x und einen int k, und es wird klar, daß hier ein deutlicher Unterschied im Ergebnis besteht. Um zu demonstrieren, daß auch für C++ deutliche Unterschiede bestehen, hier ein Beispiel:
    code:
    class A
    {
    public:
      A operator+(A a)
      {
        return a;
      }
    };
    
    int main(int i, char**c)
    {
      A a, b;
    
      a=a+b; //funktioniert
      a+=b;  // Compilerfehler
    }

    a+=b wird nicht in a=a+b umgewandelt. Der Operator muß definiert sein. Und um zu zeigen, daß die Bearbeitung völlig anders abläuft, hier ein anderes Beispiel:
    code:
    #include <iostream.h>
    
    class A
    {
      int x;
    public:
      A() { x=0; }
      A(int i) { cout<<"Konvert. von <int>, "; x=i; }
      A & operator =(const A& src)
      {
        cout<<"Zuweisung, "; x=src.x;
      }
      operator int&()
      {
        cout<<"Konvert. nach <int>, ";
        return x;
      }
    };
    
    int main(int i, char**c)
    {
      {
        A x;
        cout<<"x=x+1 : ";
        x=x+1;
        cout<<"fertig."<<endl;
      }
      {
        A x;
        cout<<"x+=1 : ";
        x+=1;
        cout<<"fertig."<<endl;
      }
    }

    Bei der Ausführung wird offensichtlich, daß eine Konvertierung des Ergebnistyps der Addition vor der Zuweisung stattfinden muß, was beim += Operator nicht nötig ist. Genau das gleiche findet bei Java statt, wo die Addition von char und int, die sehr wohl erlaubt ist, den Ergebnistyp int besitzt und deshalb nicht ohne cast einer Variablen vom Typ char zugewiesen werden kann.
    Man merke: a+=b ist ein eigentständiger Operator und keine Kurzschreibweise für a=a+b, denn a wird beim ersteren nur einmal ausgewertet und genau das erwartet man auch bei einem solchen Ausdruck. Und auch a=b+a kann andere Werte als a=a+b zurückliefern.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ Dieser Beitrag wurde von Holger am 19.10.2002 editiert. ]

    [ - Antworten - Zitieren - Direktlink - ]

  • 22.10.2002, 16:06 Uhr

    Xin
    Posts: 28
    Nutzer
    Narf....

    Ohne weiter auf den Unsinn einzugehen, möge sich der geneigte Leser zu gemüte führen, wie Referenzen auf der Maschine abgebildet werden. Durch Zeiger für den weniger geneigten Leser.

    Ergo....

    Operatoren zu überlagern und sich dann zu 'wundern' dass das nicht mehr kompilierbar ist ist fürwahr ein 1A Beweis.

    Bei char handelt es sich um 8Bit-Zahlen, bei int um 32 Bit Zahlen. Zahlen kann man addieren. Mit + und mit +=, nur halt nicht in Java.
    Das ist äußerst konsequent und das war meine Aussage.
    Und weil das so konsequent ist halte ich Java für eine Krankheit.

    Mit mein 'Halbwissen' laufend zu unterstellen ändert an dieser Tatasache nichts mehr und ist nebenher auch ein 1A-Argument für Deine Beweisführung. LOL

    PS: Hübsche Farben...

    --
    Mit freundlichem Gruß
    Sascha 'Xin' Atrops

    [ Dieser Beitrag wurde von Xin am 22.10.2002 editiert. ]

    [ - Antworten - Zitieren - Direktlink - ]

    23.10.2002, 19:23 Uhr

    Holger
    Posts: 8116
    Nutzer
    Zitat:
    Original von Xin:
    Ohne weiter auf den Unsinn einzugehen, möge sich der geneigte Leser zu gemüte führen, wie Referenzen auf der Maschine abgebildet werden. Durch Zeiger für den weniger geneigten Leser.

    Und damit sind wir schon bei Deinem bisher groessten Schwachsinn. Die Aufgabe eine Hochsprache wie Java ist es, die Eigenheiten der zugrundeliegenden Maschine zu verbergen, dadurch kommt ueberhaupt erst die hoehere Produktivitaet zustande. Wer Java lernt, soll die Vorteile der in Java nicht vorhandenen Pointer nutzen und sich nicht um die Implementierung der virtuellen Maschine Gedanken machen. Und ich habe mehrere typische Pointer-Fehlerquellen von C aufgefuehrt, die in Java unmoeglich sind. Darauf kommt es letztendlich an.
    Aber wenn Du Dich unbedingt auf Maschinenebene herunterlassen willst:
    Deine Aussage ist falsch, denn in Sun's VM werden Objektreferenzen nicht durch einen, sondern indirekt ueber zwei Zeiger abgebildet, getrennt fuer Klasse und Instanzdaten, denn der Garbagecollector kopiert Objektdaten, deren Lebensdauer bestimmte Zeitrahmen ueberschreitet, in andere Speicherbereiche, um Speicherfragmentierung zu verhindern. Zeige mir, wie das mit C++/Zeigern funktionieren soll, die Deiner Meinung nach dasselbe sind.

    Nein lass es lieber bleiben.
    Zitat:
    Operatoren zu überlagern und sich dann zu 'wundern' dass das nicht mehr kompilierbar ist ist fürwahr ein 1A Beweis.
    Es war ein Beispiel, das die unterschiedliche Behandlung in C++ demonstriert und kein Beweis.
    Zitat:
    Bei char handelt es sich um 8Bit-Zahlen, bei int um 32 Bit Zahlen. Zahlen kann man addieren. Mit + und mit +=, nur halt nicht in Java.
    Falsch, char sind unsigned 16-Bit Zahlen und int signed 32-Bit Zahlen in Java. Beide koennen in Java mit + addiert werden, das Result ist von Typ int. Um ein int einer char-Variablen zuweisen zu koennen, braucht man einen typecast. Das der Compiler sich ueber Deinen fehlenden typecast beschwert, hat nichts mit der Addition zu tun. Das hatte ich im letzten Posting schon geschrieben, aber entweder liest Du ueberhaupt nicht, bevor Du antwortest, oder Du begreifst es einfach nicht.
    Der += Operator fuehrt dagegen eine inplace-Addition durch, deren Ergebnis-Typ der des left-Hand-Operators ist, ganz einfach.
    Zitat:
    PS: Hübsche Farben...
    Das war zur Verdeutlichung und hat denen, die versucht haben, die Problematik zu verstehen, hoffentlich geholfen. Da Du am Verstehen kein Interesse hast, haben die Farben natuerlich auch keinen Nutzen fuer Dich.
    Und deshalb, antworte erst gar nicht.

    mfg

    --
    Good coders do not comment. What was hard to write should be hard to read too.

    [ Dieser Beitrag wurde von Holger am 23.10.2002 editiert. ]

    [ - Antworten - Zitieren - Direktlink - ]

    23.10.2002, 20:07 Uhr

    thomas
    Posts: 7716
    Nutzer

    Habt ihr's bald ?


    --
    Email: thomas-rapp@web.de
    Home: home.t-online.de/home/thomas-rapp/

    [ - Antworten - Zitieren - Direktlink - ]


    -1- [ - Beitrag schreiben - ]


    amiga-news.de Forum > Programmierung > Der Dereferenzierungsoperator [ - Suche - Neue Beiträge - Registrieren - Login - ]


    .
    Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
    Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
    .