Programmier-"Niveau"

[MrBurns]

...RAII...

{
  File file;
  ...
}//macht file.close()

File* file = new File;
...
delete file; //macht file.close()

[otze]

besser kann mans kaum erklären.

Bei RAII geht es nicht darum, dass man selbst kein Objekt von Hand zerstört, sondern dass das zerstörte Objekt selber seine Resourcen aufräumt, ohne dass man als benutzer überhaupt wissen muss, dass es vorher Ressourcen angefordert hat (das berühmte file.close()).

Oder wie du es ausgedrückt hast:

zu irgendwas muss die Kapselung schließlich auch gut sein

Nur vergisst du dabei, dass deterministische Destruktoren ein integraler Bstanteil sind, um Ressourcen wegzukapseln -> RAII.

[Shade Of Mine]

Xin schrieb:

Womit wir nun bei dem Detail wären, ob das Objekt das ist, worauf die Perl-Variable zeigt oder die eben Perl-Variable, die genau das Objekt ist, das auf dem Stack liegt, was entsprechend ein SmartPtr ist, der hops geht, wenn der Scope endet und der Stack aufgeräumt wird, so dass der SmartPtr seine Resource frei gibt.

Nein. Da gibt es keine Details die unklar sind.

Ein Objekt ist ein Objekt. Und eine Variable ist eine Variable.
Wenn ich eine Referenz auf ein Objekt habe, ist die Lebensspanne des Objektes und die Lebensspanne der Referenz prinzipiell erstmal unterschiedlich. Es gibt spezielle Situationen wo sie gleich sind - aber generell betrachtet lebt ein Objekt unabhaengig von etwaigen Referenzen von denen es referenziert wird.

Und Perl ist ein super Beispiel. Genauso wie VB eins waere. Dein Stack-Ansatz wird naemlich durch RefCounting widerlegt. Oder auch in C++ funktioniert es ganz OK:

Resource r(A);
r=Resource(B);

neuzuweisung. Nichts geht Out-Of-Scope und dennoch wird die resource A korrekt aufgeraeumt. Cooler ist das ganze natuerlich in Perl, weils RefCounted ist:

new Resource(A);
new Resource(B);
new Resource(C);

Kein Stack, kein Scope, keine Variablen.

Aber ich weiss wie die Diskussion hier weiter gehen wird, deshalb ist das mein letzter Post.

Du denkst wiedereinmal nur im Kontext einer speziellen Implementierung. RAII ist ein Konzept. Sobald du deterministische Destruktion hast, kannst du RAII verwenden. Dazu braucht es keine Variablen oder Scopes oder Stacks.

[Xin]

otze schrieb:

Bei RAII geht es nicht darum, dass man selbst kein Objekt von Hand zerstört, sondern dass das zerstörte Objekt selber seine Resourcen aufräumt, ohne dass man als benutzer überhaupt wissen muss, dass es vorher Ressourcen angefordert hat (das berühmte file.close()).

Oder wie du es ausgedrückt hast:

zu irgendwas muss die Kapselung schließlich auch gut sein

Nur vergisst du dabei, dass deterministische Destruktoren ein integraler Bstanteil sind, um Ressourcen wegzukapseln -> RAII.

Aha... ich vergesse also angeblich den Destruktor... hab ich aber nicht vergessen. Beschrieb ich ja auch. Also am Destruktor kann das mangelnde Verständnis nicht liegen.

Shade Of Mine schrieb:

Ein Objekt ist ein Objekt. Und eine Variable ist eine Variable.
Wenn ich eine Referenz auf ein Objekt habe, ist die Lebensspanne des Objektes und die Lebensspanne der Referenz prinzipiell erstmal unterschiedlich.

Ein SmartPtr ist aber keine Referenz. Und nicht jede Sprache, erlaubt Dir zwischen Objekt, Variable und SmartPtr dazwischen explizit zu unterscheiden. Trotzdem können sie da sein.

Shade Of Mine schrieb:

Resource r(A);
r=Resource(B);

neuzuweisung. Nichts geht Out-Of-Scope und dennoch wird die resource A korrekt aufgeraeumt.

Richtig, A. Und die Frage ist, ob das Objekt A oder r das interessante Objekt ist.

Da sind wir scheinbar(!) unterschiedlicher Meinung, weil ich RAII vom handelnden Objekt - hier r oder auch die Perl-Variable - beschreibe, dass die Resource A verwaltet bzw. das Objekt, auf das eine Perl Variable zeigt und dass von Perl verwaltet wird.
Du beschreibst das gleiche Szenario aus Sicht der verwalteten Resource.

Shade Of Mine schrieb:

Aber ich weiss wie die Diskussion hier weiter gehen wird, deshalb ist das mein letzter Post.

Ja, finde ich gut - wir beschreiben den gleichen Sachverhalt aus zwei Perspektiven. Am Ende kommt das gleiche raus. Eine Fortsetzung ist daher auch nicht erforderlich.

Dass ich gerne in Implementierungen denke stimmt, ich bin Compilerbauer. Hier unterscheiden sich die Implementierung von Perl und C++ aber auch nicht, da eine Perl-Variable nicht mit einer C++ Variable direkt vergleichbar ist, sondern implizit eine Resource wrappt.

Wir reden vom gleichen. Ich aus der Sicht des Compilerbauers, mit der Frage der Umsetzung im Blick, Du aus der Sicht des Anwenders einer Programmiersprache. Für mich machen Deine beiden Anwendungen keinen Unterschied, weil die real ablaufende Implementierung identisch ist - sie liegt in einem Fall nur in der Verantwortung der Programmiersprache und bei C++ in der Verantwortung des Entwicklers. Als Compilerbauer ist mir das für die Umsetzung des Konzepts egal. Ich kann Dich auch nur darauf hinweisen, dass nur weil Du keine Scopes siehst, da trotzdem welche sind und auch da wo Du keine Variablen siehst, da trotzdem Variablen sind, die genauso aus Scopes laufen, wie ich es zuvor beschrieben habe.

{
  Resource refCountedTemporaryResult;
  refCountedTemporaryResult = new Resource( A );
}

Auch dann, wenn du nur 'new Resource(A);' schreibst und Resource eben ein Referenzzählender Datentyp ist.

Ich danke Dir für die Erklärung, sie hat mir weitergeholfen, Deine Position als Fallbeispiel meines Verständnisses von RAII einzuordnen.

Wir haben hier das Detail, wo wir erst den Startpunkt der Gedankenreise definieren müssten. Und wir somit zwar die gleiche Vokabel verwenden, aber aus einer anderen Perspektive: Der erste sieht die Vase, der zweite die beiden Gesichter und jeder wundert sich, wieso der andere etwas anderes sieht, obwohl beide doch am Ende das gleiche Bild vor Augen haben.

[Shade Of Mine]

Xin schrieb:

Ich kann Dich auch nur darauf hinweisen, dass nur weil Du keine Scopes siehst, da trotzdem welche sind und auch da wo Du keine Variablen siehst, da trotzdem Variablen sind, die genauso aus Scopes laufen, wie ich es zuvor beschrieben habe.

Deine Terminologie ist einfach komplett falsch. Das ist das Problem

Fuer dich bedeutet Scope/Stack das selbe und zwar, dass Objekte eine Lebenszeit haben und Objekte heissen bei dir Variablen.

Wenn du statt

wir sprachen eigentlich immer davon, dass die Variablen/Objekte auf dem Stack liegen

die korrekte Terminologie verwendest:
wir sprachen eigentlich immer davon, dass Objekte am Ende ihrer Lebenszeit ihre Resourcen selber aufraeumen
dann passt es ja.

Und genau deshalb ist es wichtig diese Vokabeln zu kennen. Damit man miteinander reden kann. Wenn SeppJ Stack sagt, weiss ich was er meint.

PS:
ich weiss, ich kanns nicht lassen

[knivil]

Mehr Haarspaltereien:

...was er aber nur tut, wenn er auf dem Stack liegt, genau wie Lock auf dem Stack liegt

Wo und wie Scopes verwaltet werden, ist voellig egal.

Objekt doch bitte ... überhaupt in die Lage versetzt wird, einen Destruktor ohne Absturz auszuführen

Das Objekt selbst fuehrt keinen Destruktor aus. Der C++ Compiler fuegt Code in dein Programm ein, dass das fuer dich uebernimmt. Fuer 'unwind' bzw. Buchfuehrung ueber Scopes ist nicht zwingend der Stack notwendig, eine Buchfuehrung auf dem Heap tut es auch. Aber wahrscheinlich meinen wir sogar mit Stack etwas unterschiedliches.

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

Ich kann Dich auch nur darauf hinweisen, dass nur weil Du keine Scopes siehst, da trotzdem welche sind und auch da wo Du keine Variablen siehst, da trotzdem Variablen sind, die genauso aus Scopes laufen, wie ich es zuvor beschrieben habe.

Deine Terminologie ist einfach komplett falsch. Das ist das Problem

Neues Problem...? ^^

Shade Of Mine schrieb:

Fuer dich bedeutet Scope/Stack das selbe und zwar, dass Objekte eine Lebenszeit haben und Objekte heissen bei dir Variablen.

Hehehe, da bist Du gerade mal komplett auf dem Holzweg, was Deine Vermutung über meine Definition von Variablen angeht.

There is no Spoon... ich leugne in C++ sogar die Existenz von Variablen, ergo können sie nicht die Objekte sein

Eine "Variable" ist ein Hilfskonstrukt, um ein Objekt zu identifizieren. Eine Variable selbst kann dabei auch ein Objekt sein, z.B. in Perl, die Variable kann aber nicht das Objekt sein mit dem der Programmierer zu arbeiten glaubt.
Man unterscheidet ja auch gerne zwischen Referenztypen und Primitiven, trotzdem kann man von beiden Variablen erzeugen, wobei die eine Variable nicht so funktioniert wie die andere. Deswegen ist eine C++-Variable auch nicht das gleiche wie eine Perl-Variable, weil beide Sprachen diese Identifizierung unterschiedlich handhaben. Es ist in beiden Fällen ein Hilfskonstrukt, das mal so, mal so implementiert wird, aber mit dem eigentlichen Objekt nur indirekt zu tun hat.

Eine Variable ist eine Identifikation einer Speicherstelle mit der zusätzlichen Information, was dort zu erwarten ist - auch dann, wenn sie einen primitiven Datentyp beschreibt. In Perl dynamisch zur Laufzeit, in C++ statisch zur Kompilierzeit. Ich würde sagen in C++ sind 90% aller Variable ein Integer kleiner 100, selbst dann, wenn der Entwickler

int a = 200;

geschrieben hat. Auch ein "int" ist am Schluss doch wieder ein '(char )' und in 90% der Fälle eben ein (char)+x, nämlich dann, wenn der Stack oder 'this' ins Spiel kommt, also bei allen nicht statisch lokalen Variablen, bei allen Parametern, Membern und bei allen "Variablen", die unbenannt sind und Du als Programmierer gar nicht zu Gesicht bekommst. Auch die unbenannten sind voll typisiert und rufen entsprechend beim Verlassen ihres Scopes den Destruktor auf.

Perl ist da noch aufwendiger, weil die Information zur Laufzeit noch in einem dafür vorgesehenen Objekt existieren muss. Was eine Variable in beiden Sprachen definitiv nicht ist, ist das Objekt mit dem der Programmierer zu arbeiten glaubt.

Ab hier geht's los. An der Stelle bin ich auch nicht "implementierungsabhängig", denn ab hier spielt es keine Rolle mehr, ob Du RAII in C++ oder Perl beschreibst. Ab hier stellt sich nur noch die Frage nach dem Konzept. Die Sprache klärt nur die Frage, ab wo dem Programmierer erlaubt wird, Einfluss zu nehmen. Aber das spielt für das Konzept selbst ja keine Rolle, solange der Programmierer die für das Konzept passenden fehlenden Befehle anweist. Da ist in Perl weniger erforderlich als in C++, weil einem Perl hier das Konzept schon soweit fertig ungefragt vor die Nase setzt.

Shade Of Mine schrieb:

Wenn du statt

wir sprachen eigentlich immer davon, dass die Variablen/Objekte auf dem Stack liegen

die korrekte Terminologie verwendest:
wir sprachen eigentlich immer davon, dass Objekte am Ende ihrer Lebenszeit ihre Resourcen selber aufraeumen
dann passt es ja.

Ooookay... wir sind uns grundsätzlich ja einig was RAII macht, schließlich werden bei Objekten, die auf dem Stack liegen nach Ablauf der Lebenszeit der Destruktor aufgerufen, der ihre Resourcen aufräumt... genau darum legt man die Dinger ja auch auf den Stack... Vase oder Gesicht...

Also habe ich jetzt die Funktionsweise des Destruktors hier nicht verstanden, wenn mir man mir erklärt, dass ich RAII nicht verstehe? "Resource Acquisition Is Initialization" heißt also übersetzt, dass Objekte am Ende ihrer Lebenszeit ihre Resourcen aufräumen und schon hätten wir uns sofort verstanden? Gut, das muss einem ja mal so gesagt werden.

Das erwarte ich von allen Klassen, dass sie die zu verantworteten Resourcen freigeben, da brauche ich eigentlich gar kein Buzzword zu. Ich habe da einfach ein Wort für Klassen, die das nicht machen: Defekt.
Mir war also nicht bewusst, dass ich für RAII explizit erwähnen muss, dass der Destruktor funktioniert, denn das halte ich für implizit, wenn ich Objekt sage. Und bevor jetzt der Pointer kommt, bei dem das nicht geht - auch der hat einen funktionierenden Destruktor, nur darf dieser nicht delete aufrufen, aber das Pointerobjekt wird entsprechend seiner Verantwortung und Definition korrekt abgebaut. Hätte man ein delete gewünscht, hätte man ja einen SmartPointer genommen.

Shade Of Mine schrieb:

ich weiss, ich kanns nicht lassen

Hehehe. Und ich weiß das auch.

[otze]

Eine Variable ist eine Identifikation einer Speicherstelle mit der zusätzlichen Information, was dort zu erwarten ist - auch dann, wenn sie einen primitiven Datentyp beschreibt. In Perl dynamisch zur Laufzeit, in C++ statisch zur Kompilierzeit. Ich würde sagen in C++ sind 90% aller Variable ein Integer kleiner 100, selbst dann, wenn der Entwickler

Das ist falsch. Register haben keine Addresse. Variablen können raus optimiert wrden, wnn der Compiler das Ergebnis bereits selbst berechnen kann usw. Aber ein "das ist falch" hat dich noch nie abgehalten, dich weiter zu verrennen. "Konsequent ist, wer Holzwegen bis an ihr Ende folgt"

message delivered, over and out.

[Xin]

otze schrieb:

Eine Variable ist eine Identifikation einer Speicherstelle mit der zusätzlichen Information, was dort zu erwarten ist - auch dann, wenn sie einen primitiven Datentyp beschreibt. In Perl dynamisch zur Laufzeit, in C++ statisch zur Kompilierzeit. Ich würde sagen in C++ sind 90% aller Variable ein Integer kleiner 100, selbst dann, wenn der Entwickler

Das ist falsch. Register haben keine Addresse. Variablen können raus optimiert wrden, wnn der Compiler das Ergebnis bereits selbst berechnen kann usw. Aber ein "das ist falch" hat dich noch nie abgehalten, dich weiter zu verrennen. "Konsequent ist, wer Holzwegen bis an ihr Ende folgt"

message delivered, over and out.

Abgesehen von dem "Das ist falsch" hast du nichts Falsches gesagt, wobei in dem Fall das, was Du als Variable bezeichnet, das Objekt ist, welches herausoptimiert wird, welches Dir als Entwickler als Variable angeboten wird, die zur Laufzeit in Wirklichkeit nie existiert hat.

Ich weiß es auch nicht, soviele Leute sagen mir, dass was ich tue alles falsch ist, ich muss ein schrecklicher Informatiker sein. Was ich nur nie verstehe ist, dass das Falsche, was ich tue funktioniert und die Leute, nachdem sie das Problem dann richtig gelöst und implementiert haben, genau die selben Fehler machen, damit etwas funktionierendes dabei rauskommt.

Solange "richtig" nicht funktioniert und ich in der Umsetzung mit "falsch" erfolgreich bin, bleibe ich gerne auf dem Holzweg. Am Ende entscheiden nämlich nicht die erfahrenen C++-Entwickler im C++-Forum, sondern die Frage, ob ein Programm fehlerfrei das gewünschte Ergebnis liefert. Aber das ist vermutlich auch falsch.

[hustbaer]

@Xin
Variablen existieren - wenn wir mal C-artige Sprachen ohne Reflection als Grundlage nehmen - grundsätzlich nur im Source-Code.
Genaugenommen existiert alles nur im Source-Code, bzw. der Vorstellung des Programmierers. Ausgenommen vielleicht bestimmte Werte-Folgen die man bei als beobachtbar klassifizierten Dingen in bestimmten Speicherbereichen wiederfinden wird, wenn man ein Programm laufen lässt.

Zu sagen eine Variable sei eine Adresse oder ein Offset oder sonstwas ist Unfug. Der C- bzw. C++-Standard garantiert unter Verwendung bestimmter definierter Begriffe wie "Objekt" etc. ein bestimmtes Verhalten, und das Programm setzt es um.
Dabei können zur Umsetzung von etwas was im Source-Code Variablen verwendet durchaus Adressen oder Offsets zum Einsatz kommen. Eine Variable *ist* deswegen aber weder eine Adresse noch ein Offset.

Davon abgesehen halte ich die Unterscheidung der Begriffe "Variable" und "Objekt" für fragwürdig. Ich würde eher sagen: Variablen sind in C++ eine Möglichkeit über Objekte zu sprechen.

[hustbaer]

@cooky451
Sorry falls der Artikel schon verlinkt wurde, ich hab nicht den ganzen Thread gelesen.
Passt auf jeden Fall für mich genau zu deiner Frage.

http://www.damninteresting.com/unskilled-and-unaware-of-it/

Und ja, mich wundert es auch immer wieder wie manche Leute ernsthaft von sich behaupten können sie könnten programmieren.

[Xin]

hustbaer schrieb:

Zu sagen eine Variable sei eine Adresse oder ein Offset oder sonstwas ist Unfug. Der C- bzw. C++-Standard garantiert unter Verwendung bestimmter definierter Begriffe wie "Objekt" etc. ein bestimmtes Verhalten, und das Programm setzt es um.

Jaja, der C++-Standard... der interessiert unter genau einer Bedingung: Dass man C++ programmiert. Ansonsten interessiert nur die Maschine, die sagt, ob ein Konzept umgesetzt werden kann oder nicht.

hustbaer schrieb:

Dabei können zur Umsetzung von etwas was im Source-Code Variablen verwendet durchaus Adressen oder Offsets zum Einsatz kommen. Eine Variable *ist* deswegen aber weder eine Adresse noch ein Offset.

Verstehe... Du sagtest ja schon, dass ich Unfug schreibe.

Dann schreib mal eine Implementierung und dann schauen wir mal, welche Member bei Dir in der class Variable auftauchen.
Für die Implementierung wirst Du das nämlich scharf definieren müssen und feststellen, dass eine Variable in der Regel ein Integer ist oder eine Adresse.

hustbaer schrieb:

Davon abgesehen halte ich die Unterscheidung der Begriffe "Variable" und "Objekt" für fragwürdig. Ich würde eher sagen: Variablen sind in C++ eine Möglichkeit über Objekte zu sprechen.

"Ich würde" sagen, "ich halte" nicht, sondern "ich habe". Ich habe implementiert. Diese Begriffe sind nicht wirklich fragwürdig.

Es ist absolut verständlich, dass man sich diese Sachen erstmal genau definieren muss und dass das im Programmieralltag gar nicht so tief in eine Sprache einsteigen muss. Aber das macht meine Aussage nicht zu Unfug.

Und das ist die Ecke aus der ich Konzepte aufbaue und verstehe, da juckt mich kein C++-Standard, kein Perl, kein sonstwas. Und daher reden Shade of Mine und ich über das gleiche ohne, dass es jemandem auffällt.

[cooky451]

@hustbaer
Erinnert mich an ein Bewertungsschema für Vorträge das ich mal gelesen habe:

Excellent
Very Good
Good
Average
Poor

Schön zu sehen hier wie "average" schon abwertend benutzt wird, quasi wie ein "almost poor". Average ist wohl einfach nicht genug. Ich würde mal schätzen der Durchschnitt der Bewertungen wird zwischen Good und Very Good liegen - wobei schon die Annahme dass durchschnittliche Vorträge nicht gut sein können verstörend ist.

[Zeus]

Xin schrieb:

hustbaer schrieb:

Zu sagen eine Variable sei eine Adresse oder ein Offset oder sonstwas ist Unfug. Der C- bzw. C++-Standard garantiert unter Verwendung bestimmter definierter Begriffe wie "Objekt" etc. ein bestimmtes Verhalten, und das Programm setzt es um.

Jaja, der C++-Standard... der interessiert unter genau einer Bedingung: Dass man C++ programmiert. Ansonsten interessiert nur die Maschine, die sagt, ob ein Konzept umgesetzt werden kann oder nicht.

Unsinn ein Compilerbauer schafft eine widerspruchsfreie Abbildung von abstrakte Konzepten auf die Maschine.

[Xin]

Zeus schrieb:

Xin schrieb:

hustbaer schrieb:

Zu sagen eine Variable sei eine Adresse oder ein Offset oder sonstwas ist Unfug. Der C- bzw. C++-Standard garantiert unter Verwendung bestimmter definierter Begriffe wie "Objekt" etc. ein bestimmtes Verhalten, und das Programm setzt es um.

Jaja, der C++-Standard... der interessiert unter genau einer Bedingung: Dass man C++ programmiert. Ansonsten interessiert nur die Maschine, die sagt, ob ein Konzept umgesetzt werden kann oder nicht.

Unsinn ein Compilerbauer schafft eine widerspruchsfreie Abbildung von abstrakte Konzepten auf die Maschine.

Was mich in diesem Forum immer wieder wundert, dass viele erstmal erklären müssen, dass sie dagegen ist, um dann eine Begründung dahinter zu liefern, die überhaupt keinen Zusammenhang mit der Aussage hat, die zuvor als "Unsinn" bezeichnet wurde. Dabei muss Deine nachfolgende Aussage ja nichtmals falsch sein - meine aber auch nicht. Es besteht einfach kein Zusammenhang und daher ist es auch keine Begründung dafür, erstmal dagegen zu sein.

Da Du offenbar Compilerbauexperte bist, fällt Dir sicherlich eine bessere Begründung dafür ein, mir "Unsinn" zu unterstellen. Ich könnte mir aber auch vorstellen, dass Du bloß einen Satz in diesem Thread gelesen hast und ohne Zusammenhang dieses Threads mal ein "Unsinn" posten wolltest.

[Zeus]

Xin schrieb:

Zeus schrieb:

Xin schrieb:

hustbaer schrieb:

Zu sagen eine Variable sei eine Adresse oder ein Offset oder sonstwas ist Unfug. Der C- bzw. C++-Standard garantiert unter Verwendung bestimmter definierter Begriffe wie "Objekt" etc. ein bestimmtes Verhalten, und das Programm setzt es um.

Jaja, der C++-Standard... der interessiert unter genau einer Bedingung: Dass man C++ programmiert. Ansonsten interessiert nur die Maschine, die sagt, ob ein Konzept umgesetzt werden kann oder nicht.

Unsinn ein Compilerbauer schafft eine widerspruchsfreie Abbildung von abstrakte Konzepten auf die Maschine.

Was mich in diesem Forum immer wieder wundert, dass viele erstmal erklären müssen, dass sie dagegen ist, um dann eine Begründung dahinter zu liefern, die überhaupt keinen Zusammenhang mit der Aussage hat, die zuvor als "Unsinn" bezeichnet wurde. Dabei muss Deine nachfolgende Aussage ja nichtmals falsch sein - meine aber auch nicht. Es besteht einfach kein Zusammenhang und daher ist es auch keine Begründung dafür, erstmal dagegen zu sein.

Krass, ich hab dir mit diesen Satz in zwei Fakten sofort wiederspruchen und du kommst damit an.

[Eisflamme]

Ich hab das Gefühl, hier reden alle aneinander vorbei. Jedenfalls kann ich in dem letzten Kaskadenzitat bei keiner Aussage begreifen, wie die mit der letzten zusammenhängt.

[berniebutt]

Eisflamme schrieb:

Ich hab das Gefühl, hier reden alle aneinander vorbei. Jedenfalls kann ich in dem letzten Kaskadenzitat bei keiner Aussage begreifen, wie die mit der letzten zusammenhängt.

Ich habe diesen Eindruck auch und verstehe das Thema als solches nicht.

[hustbaer]

@Xin
Variablen sind ein abstraktes Konzept und existieren nur im Source-Code.

Je nach Sprache und Compiler wird es im kompilierten Programm etwas geben was diesem Konzept mehr oder weniger entspricht. Oder eben auch nicht. Eine 1:1 Abbildung ist bei einem halbwegs leistungsfähigen Compiler nicht möglich.
Daher ist auch die Aussage "eine Variable ist ein Offset/Adresse" Quatsch.

Ganz konkret: die selben Variable kann im Kompilat einmal in einem Register stehen, danach an Offset X und ein paar Befehle weiter an Offset Y. Oder eben auch gar nicht vorkommen.
Beispielsweise können viele Compiler Laufvariablen in Schleifen rausoptimieren.

T* p = ...;
size_t const len = ...;
for (size_t i = 0; i < len; i++)
    p[i].Something();

Im fertigen Kompilat können hier p, len und i zu zwei Registern/Werten zusammengefasst werden: dem Zeiger auf das aktuelle p[i] und einem Zeiger auf p[len] bzw. p[len - 1].

Also wieder nach C++ zurückübersetzt:

T* p2 = ...;
T* pend = p2 + ...;
while (p2 != pend)
{
    p2->Something();
    p2++;
}

Und nun beantworte mir bitte: welchen Offset bzw. welche Adresse haben hier jeweils p, len und i?

Das Beispiel ist jetzt in C++, das selbe gilt aber für quasi jede Sprache.

[Xin]

hustbaer schrieb:

@Xin
Variablen sind ein abstraktes Konzept und existieren nur im Source-Code.

...

Und nun beantworte mir bitte: welchen Offset bzw. welche Adresse haben hier jeweils p, len und i?

Die übliche Antwort des Experten: Das ist implementierungsabhängig. ^^

Die Antwort kann ich auch nicht geben, weil ich die Verschachtelung des Scopes nicht kenne.
Variablen, die rausoptimiert werden, existieren nicht. Was nicht existiert, braucht auch kein Offset.

long long int add( int a, int b )
{
  long long int c = a+b;
  return c;
}

Implementierungsabhängig! Eine Möglichkeit innerhalb des Scopes wäre: c ist -8, a ist 0, b ist 4, <unnamed result> ist 8.