Adreßoperator
-
Nachdem mir gestern mal wieder ein peinlicher Fehler unterlaufen ist muss ich jetzt mal genau fragen :
Wann genau brauch ich den den '&' zum einlesen von Zeichen (also bei zb bei scanf)?
Ich dachte :
- bei allen Zahlen
- bei einzelnen charsStimmt das oder hab ich was vergessen/falsch geschrieben ?
-
Eigentlich brauchst du die Adresse des Ziels bei allen Daten, die du über scanf() einlesen willst (auch wenn Tim gleich aufstöhnen wird - Stichwort "Call by Reference"). Und bei den meisten Datentypen bekommst du diese Adresse halt mit dem Operator &.
Die einzige Ausnahme ist afaik die Eingabe von Strings - das char-Array wird implizit umgewandelt in einen Zeiger auf den Zielbereich, darum kannst/mußt du es direkt ohne Adress-Ermittlung übergeben.
-
scanf braucht immer eine adresse. wenn du einen string angibst, wird automatisch die adresse genommen. gibst du scanf einen pointer, dann ist das ja auch schon eine adresse. nur bei 'nackten' variablen musst du dem compiler sagen, dass du die adresse meinst (mit dem '&').
-
CStoll schrieb:
(auch wenn Tim gleich aufstöhnen wird - Stichwort "Call by Reference").
mittlerweile dürfte selbst er verstanden haben, wie's gemeint ist.
-
Hmmm Call by Reference, war das nicht die Übergabe von Daten an Funktionen per Adresse ? hab da glaub ich mal gelesen das des bei C nicht wirklich geht, also immer über Call by Value, oder lieg ich falsch
?
-
indirection-freak schrieb:
CStoll schrieb:
(auch wenn Tim gleich aufstöhnen wird - Stichwort "Call by Reference").
mittlerweile dürfte selbst er verstanden haben, wie's gemeint ist.
Ich habe akzeptiert, dass ihr gerne mißverständliche Bezeichnungen benutzt. Falls du das meinst
@ toxor: Es gibt in C kein "call by reference", richtig. Bei der Übergabe eines Zeigers kann man ihn als Referenz betrachten, daher kommt die Verwirrung. Aber auch Zeiger werden "by value" übergeben.
-
Das meinte ich mit der Bemerkung an Tim - C unterstützt eigentlich nur die Übergabe per Value, also übergibt man die Adresse einer Variable (per value) an die Funktion - und diese kann den übergebenen Zeiger dereferenzieren und damit auf die Variablen des Hauptprogramms zugreifen.
(und auf diese Weise erreicht man über die entsprechenden Verrenkungen ein Verhalten, das man durchaus als "call by reference" ansehen könnte)
-
Okay vielen Dank
-
Tim schrieb:
Ich habe akzeptiert, dass ihr gerne mißverständliche Bezeichnungen benutzt.
da gibts nichts misszuverstehen. siehe z.b. CStolls erklärung...^^
-
pointer-freak schrieb:
Tim schrieb:
Ich habe akzeptiert, dass ihr gerne mißverständliche Bezeichnungen benutzt.
da gibts nichts misszuverstehen. siehe z.b. CStolls erklärung...^^
Ganz offensichtlich gibt es hier was misszuverstehen. Siehe z.B. meine Erklärung.
-
Da stellt sich mir die Frage, gibt es echte Übergabe per Referenz, die wirklich ohne Kopieren eines "Identifikators" auskommt? Wenn ja wir darf man sich das vorstellen?
-
naja, eigentlich nicht. vielleicht könnte man macro-parameter als eine form von referenzen bezeichnen (zugegebenermassen eine sehr starre form im gegensatz zu pointern):
#define DOUBLE(x) ((x)*=2) ... int a=10; DOUBLE(a); // <-- call by reference ??!
dabei wird zur laufzeit nichts kopiert sondern der macro parameter wird vom preprocessor ausgewertet. aber im prinzip ist es wumpe, ob das kopieren des identifikators vor, beim, oder nach dem compilieren passiert.
-
Also "call by reference" ohne Referenzen kennen wir ja schon. Aber ein "call by reference" ganz ohne call ist mal echt heiss
-
Tim schrieb:
Also "call by reference" ohne Referenzen kennen wir ja schon. Aber ein "call by reference" ganz ohne call ist mal echt heiss
du glänzt wieder mal durch nichtvorhandene imagination. dann sind für dich inline-funktionen bestimmt auch keine calls, ne?
-
textersetzungs-fan schrieb:
Tim schrieb:
Also "call by reference" ohne Referenzen kennen wir ja schon. Aber ein "call by reference" ganz ohne call ist mal echt heiss
du glänzt wieder mal durch nichtvorhandene imagination.
Wieso soll ich mir was vorstellen wo ich ganz genau weiss, dass es nicht so ist?
textersetzungs-fan schrieb:
dann sind für dich inline-funktionen bestimmt auch keine calls, ne?
Das ist schon eine gute Frage. Genau genommen ist es eigentlich nur dann ein call wenn nicht geinlined wird, ansonsten natürlich schon. Aber der Punkt ist echt gut.
-
Tim schrieb:
Genau genommen ist es eigentlich nur dann ein call wenn nicht geinlined wird, ansonsten natürlich schon.
nun ja, ich bin ja auch mehr der lowlevel-fanatiker und stelle mir am liebsten beim programmieren vor, wie elektrische impulse durch flipflops rasen, aber beim coden gibt's eben verschiedene abstraktionslevel. da kann man sich einen makro-'aufruf' durchaus als funktionsaufruf vorstellen (man gibt was rein und kriegt was raus). wie's technisch abläuft ist natürlich auch wichtig, aber auf einer höheren ebene ist das gar nicht so entscheidend.
-
Zustimmung. Aber auf höheren Ebenen nimmt man ja auch keine Makros mehr
-
Tim schrieb:
Zustimmung. Aber auf höheren Ebenen nimmt man ja auch keine Makros mehr
Oje, lieber Mod,
Bodenhaftung verloren
Unter C gibt es nur das, was Präprozessor und Compiler hergeben. Macros sind da oft die unerwarteten Problemlöser. Das hier ist das C- Forum, vergessen?
Viel Spaß auf den "höheren Ebenen" :p
-
pointercrash() schrieb:
Macros sind da oft die unerwarteten Problemlöser.
stimmt schon. denk doch nur mal an deine eeprom-variablen. der <beliebiges_wort_einsetzen>-freak hat dir einst gezeigt, wie wunderbar macros die sprache C bereichern können.
-
pointercrash() schrieb:
Tim schrieb:
Zustimmung. Aber auf höheren Ebenen nimmt man ja auch keine Makros mehr
Oje, lieber Mod,
Bodenhaftung verlorenWieso?
pointercrash() schrieb:
Unter C gibt es nur das, was Präprozessor und Compiler hergeben. Macros sind da oft die unerwarteten Problemlöser.
Und ebenso oft die (un)erwarteten Problemerzeuger.
pointercrash() schrieb:
Das hier ist das C- Forum, vergessen?
Und? Was willst du damit sagen?
@ anything-freak:
Welches Problem hat das EEPROM-Makro denn gelöst?
-