Adreßoperator

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.

lolz

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

pointercrash**

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 verloren

Wieso?

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?

-->
http://www.c-plusplus.net/forum/viewtopic-var-t-is-199923-and-start-is-0.html

pointercrash**

Tim schrieb:

Wieso?

Warum das so ist, weiß ich nicht, aber im ANSI-C- Forum Makros schlechtzureden und von höheren Ebenen zu faseln, ist Themaverfehlung

Tim schrieb:

Und ebenso oft die (un)erwarteten Problemerzeuger.

Ja, und auch Pointer verursachen Probleme bei fehlerhafter Anwendung, trotzdem sind sie zentraler Bestandteil von C. Daß man sie im Elysium der "höheren Ebenen" auch nicht unbedingt braucht, hat doch HIER nichts zu sagen.

Tim schrieb:

@ anything-freak:
Welches Problem hat das EEPROM-Makro denn gelöst?

sh. voriger Post. Ich fand's schön, wie elegant man das damit machen kann und weil's mich interessiert hat, habe ich ein bißchen mit dem Präp gespielt. Richtig eingesetzt geben die Makros eine weitere Abstraktionsebene, die ich zumindest früher nicht ausreichend gewürdigt habe. Das finde ich im Nachhinein schade.

Tim schrieb:

Und? Was willst du damit sagen?

Du empfiehlst Leuten quasi wegen nicht näher bezeichneter möglicher Probleme beim Autofahren auf die höheren Gänge zu verzichten und verweist darauf, daß in "höheren Ebenen" stufenlose Automatikgetriebe existieren.
In C wird jedoch noch gekuppelt und geschaltet, sonst fährt's nicht richtig. Hier gehören Makros nicht benörgelt, sondern erklärt, ist doch das C- Forum, oder?

pointercrash() schrieb:

aber im ANSI-C- Forum Makros schlechtzureden .... ist Themaverfehlung
...
Richtig eingesetzt geben die Makros eine weitere Abstraktionsebene...
...
In C wird jedoch noch gekuppelt und geschaltet, sonst fährt's nicht richtig. Hier gehören Makros nicht benörgelt, sondern erklärt....

super statement, pointercrash. ganz meine meinung -->∞
dem ist nichts hinzuzufügen, deshalb unendlich viele 'daumen-hoch'.

pointercrash() schrieb:

Tim schrieb:

Wieso?

Warum das so ist, weiß ich nicht, aber im ANSI-C- Forum Makros schlechtzureden und von höheren Ebenen zu faseln, ist Themaverfehlung

1. Ich rede Makros nicht schlecht. Ich finde nur falschen/übermäßigen Einsatz von Function-like-Makros schlecht. Das ist ein Unterschied.
2. Die "höheren Ebenen" wurden von anderen zuerst benutzt. Bitte nochmal lesen. Danke.

pointercrash() schrieb:

Tim schrieb:

Und ebenso oft die (un)erwarteten Problemerzeuger.

Ja, und auch Pointer verursachen Probleme bei fehlerhafter Anwendung, trotzdem sind sie zentraler Bestandteil von C.

Der (eigentlich offensichtliche) Unterschied ist, dass man Zeiger praktisch nicht durch andere Konstrukte ersetzen kann. Die meisten Function-like-Makros aber schon.

pointercrash() schrieb:

Daß man sie im Elysium der "höheren Ebenen" auch nicht unbedingt braucht, hat doch HIER nichts zu sagen.

Spar dir dein Geblubber von wegen "Elysium der "höheren Ebenen"", siehe oben.

pointercrash**

Tim schrieb:

1. Ich rede Makros nicht schlecht. Ich finde nur falschen/übermäßigen Einsatz von Function-like-Makros schlecht. Das ist ein Unterschied.

Ah ja? Was ist denn falsch? Und was zuviel? Erleuchte uns mit Beispielen!

Tim schrieb:

2. Die "höheren Ebenen" wurden von anderen zuerst benutzt.

Jo, aber Du hast den Kontext verdreht. Bitte nochmal lesen. Danke.

Tim schrieb:

Der (eigentlich offensichtliche) Unterschied ist, dass man Zeiger praktisch nicht durch andere Konstrukte ersetzen kann. Die meisten Function-like-Makros aber schon.

Hast Du noch nie Code übernommen, der von jemand produziert wurde, der panische Angst vor Pointern hatte? Es geht auch (fast) ohne, der Code wird halt sehr umständlich. Andererseits hab' ich jetzt einen Teil meiner Libs durch Makros deutlich straffen können, weil mir jemand diese Möglichkeit gezeigt hat. Vorher war das viel umständlicher.

Tim schrieb:

Spar dir dein Geblubber ...

In dem Fall ein Makro zu setzen, war ein sachbezogenes Beispiel und es wurde erläutert, daß der Code sukzessive aufgelöst wird. Es gibt verschiedene Abstraktionsebenen, zum Schluß fällt Maschinencode raus, so war das wohl gemeint. Supertimmi antwortet, daß es in höheren Ebenen keine Makros braucht. Also entweder hat er das Beispiel nicht verstanden oder nur genutzt, seinen "Humor" unter Beweis zu stellen.

pointercrash() schrieb:

Tim schrieb:

1. Ich rede Makros nicht schlecht. Ich finde nur falschen/übermäßigen Einsatz von Function-like-Makros schlecht. Das ist ein Unterschied.

Ah ja? Was ist denn falsch? Und was zuviel? Erleuchte uns mit Beispielen!

#define SetBit(a, p) ((a)[(p)>>3] |= (1<<((p)&3)))
#define GetBit (a, p) (!!((a)[(p)>>3] & (1<<((p)&3))))

- Unnötiger Einsatz von Makro, eine Funktion wäre wesentlich übersichtlicher.
- Seiteneffekte durch evtl. mehrfache Auswertung von p.
- Bricht die (ungeschriebene) Regel, dass Makros nur Großbuchstaben enthalten sollten und nicht groß/klein gemischt.

pointercrash() schrieb:

Tim schrieb:

2. Die "höheren Ebenen" wurden von anderen zuerst benutzt.

Jo, aber Du hast den Kontext verdreht. Bitte nochmal lesen. Danke.

Bist du dir sicher, dass du überhaupt verstanden hast, was ich mit Ebene meinte? Vielleicht meinte ich ja Abstraktionsebene? Du darfst jetzt darauf herumreiten, dass ich mich unklar ausgedrückt habe...

pointercrash() schrieb:

Tim schrieb:

Der (eigentlich offensichtliche) Unterschied ist, dass man Zeiger praktisch nicht durch andere Konstrukte ersetzen kann. Die meisten Function-like-Makros aber schon.

Hast Du noch nie Code übernommen, der von jemand produziert wurde, der panische Angst vor Pointern hatte? Es geht auch (fast) ohne, der Code wird halt sehr umständlich.

Ja, das ist fucked-up Code. Durfte ich schon oft genug wegwerfen.

pointercrash() schrieb:

Andererseits hab' ich jetzt einen Teil meiner Libs durch Makros deutlich straffen können, weil mir jemand diese Möglichkeit gezeigt hat. Vorher war das viel umständlicher.

Erleuchte uns mit Beispielen. Das EEPROM-Beispiel kenne ich schon. Davon war FIELD_OFFSET und FIELD_SIZE sinnvoll. Die anderen beiden hätte man genausogut als Funktion schreiben können.

pointercrash() schrieb:

Supertimmi antwortet, daß es in höheren Ebenen keine Makros braucht. Also entweder hat er das Beispiel nicht verstanden oder nur genutzt, seinen "Humor" unter Beweis zu stellen.

Nichts für ungut, aber glaubst du nicht, dass du dich hier gerade in etwas verrennst?

Tim schrieb:

Die anderen beiden hätte man genausogut als Funktion schreiben können.

zeig mal wie, aber ohne dass die aufrufe komplizierter werden.

Edit: hier stand erst Mist.

Naja, gibt man halt Element, Größe des Elements und Offset an. Nicht wirklich tragisch.