Programmier-"Niveau"

[asc]

knivil schrieb:

Code den niemand außer einem selbst verstehen kann ist niemals inakzeptabel

Code den nur einer versteht gibt es nicht. Sich einzuarbeiten ist manchmal ungemein schwieriger aber machbar.

Es gibt durchaus Personen die Code schreiben bei dem ein Einarbeiten wesentlich länger dauert, als den Code weg zuschmeißen und neu zu schreiben. Und in solchen Fällen ist der Codestil inakzeptabel. Wenn Personen meinen kryptischen Code schreiben zu müssen, passen sie in keine Firma.

Wer meint alles in 2-Buchstabenkombinationen verpacken zu müssen, alles global zu definieren und von überall aus darauf zuzugreifen, 5fach-Zeiger zu verwenden und nicht einen Kommentar oder wenigstens etwas Hilfe zu gewähren, ist jedenfalls in keinen Projekt mit mehreren Personen gut aufgehoben. Und das hat auch nicht mit C++ Denke zu tun, auch in C kann man sauberen und lesbaren Code schreiben.

[SideWinder]

...er ist auch in seinen eigenen Projekten ganz allein nicht gut aufgehoben, vergisst er doch innerhalb von fünf Monaten wofür das Konstrukt gebraucht wurde und wie es genau funktioniert.

MfG SideWinder

[Xin]

SeppJ schrieb:

Bei RAII ist es vollkommen egal, ob ein Objekt im automatischen oder im Freispeicher liegt. ... Aber ich denke, du bist auch ganz froh, dass ein vector<string> hinter sich aufräumt, obwohl die Strings im Freispeicher liegen.

...was er aber nur tut, wenn er auf dem Stack liegt, genau wie Lock auf dem Stack liegt. Was Lock/vector<string> intern macht, interessiert mich dabei nicht - zu irgendwas muss die Kapselung schließlich auch gut sein.

Solltest Du RAII außerhalb eines Scopes benutzen, ist es natürlich auch "Resource Acquisition Is Initialization"... was sich aber gleich damit deckt, dass ein Objekt doch bitte keinen invaliden Zustand annehmen sollte, ergo seine Resourcen im Konstruktor so einrichtet, dass es anschließend noch damit klar kommt, bzw. überhaupt in die Lage versetzt wird, einen Destruktor ohne Absturz auszuführen. Sogesehen ist ein akzeptabler Standardkonstruktor RAII.

Langer Text, kurzer Sinn: Man programmiert, um einem Computer die Arbeit zu überlassen. Man benutzt RAII, um das Speichermanagement dem Computer zu überlassen und sich selbst die Arbeit zu vereinfachen. Man kann RAII auch verwenden, weil man sonst nix zu tun hat, genauso wie man ohne Grund programmieren kann.

Man kann auch Objekte mit Standard-Konstruktor aufrufen, dann konfigurieren und dann über den Stack zerstören lässt. Konfiguration ist quasi Benutzung.

Wenn man mit RAII allerdings kein Ziel verfolgt, das man dann auch benennen darf, dann ist RAII nur ein wertloses Buzzword.

Wobei ich Dir mit der Haarspalterei allerdings recht gebe ist, dass RAII ein ziemlich dämliche Bezeichnung für die üblicherweise damit verbundene Semantik ist, während die Diskussion hier gleichzeitig wieder dafür spricht, dass zwei Informatiker erst mal die Semantik ihres Vokabulars abgleichen müssen, bevor sie miteinander reden können. Von der Bedeutung der Buchstaben "RAII" bin ich also eigentlich voll auf Deiner Seite, wie ich auch den Leuten beibringe, dass das, was man unter OOP versteht nichts mit Objektorientierter Programmierung zu tun hat, sondern Datentyporientierte Programmierung ist und sie wenn sie OOP hören DOP verstehen müssen und für OOP doch bitte Methodenpointer verwenden mögen.

Ergo: Wir wissen beide, was RAII ist, wir wissen wozu es sinnvoll ist, wir können fachlich damit umgehen, haben das Know How und können trotzdem nicht über RAII sprechen, sonst würden wir hier nicht diskutieren. ^^

Das liebe ich an der Informatik: jeder weiß was er tut und vor lauter Buzzwords besteht keine Möglichkeit das was man tut in einem Satz zu erklären. ^^

[asc]

Xin schrieb:

SeppJ schrieb:

Bei RAII ist es vollkommen egal, ob ein Objekt im automatischen oder im Freispeicher liegt. ... Aber ich denke, du bist auch ganz froh, dass ein vector<string> hinter sich aufräumt, obwohl die Strings im Freispeicher liegen.

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

Du hast imho RAII nicht verstanden.

[Gast]

Xin schrieb:

Das liebe ich an der Informatik: jeder weiß was er tut...

asc schrieb:

Du hast imho RAII nicht verstanden.

ROFL!

[Shade Of Mine]

Idiome und Patterns sind eine Sprache.
Es geht dabei darum Namen zu haben.

Wenn ich jemanden sage: nimm ein Singleton - dan weiß er genau was gemeint ist. Da gibt es dann keine 2 Interpretationen.

Ansonsten muss man eine halbe Stunde lang rumdiskutieren bis alle Beteiligten auf dem gleichen Stand sind.

Ein weiterer Vorteil dieser Sprache und Vokabeln ist, dass man schneller die relevanten Sachen lernen kann. Denn zB MVC zu verstehen wenn man es als Erklärung vor sich hat, ist trivial. MVC zu verstehen, wenn man nur den ganzen Tag Code schreibt und sich selber Lösungen für die Probleme der Trennung des Frontends vom Backend überlegen muss - kostet viel zu viel Zeit.

So können Neulinge schon direkt die richtigen Sachen lernen. Das hilft sehr.

PS:
und RAII hat mit Stack Variablen nicht viel zu tun - bis auf, dass die C++ Implementierung von RAII sehr oft Stack Variablen verwendet. In Perl gibt es zB keine Stack Objekte und trotzdem RAII.

[SeppJ]

asc schrieb:

Xin schrieb:

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

Du hast imho RAII nicht verstanden.

FTFY

Sorry Xin, aber du hast es wirklich nicht verstanden. Du redest dir ein, dass du es verstanden hättest und bist vermutlich sogar stolz darauf, dass du als einziger erkannt hast, dass das etwas triviales ist, was du schon längst wusstest. Aber du bist der einziger der das so sieht, weil du es falsch verstanden hast.

Ich werde jetzt nicht einzeln auf deine Aussagen eingehen, weil es nicht das Thema des Threads ist. Wenn du mehr wissen möchtest, dann lies es dir selber an oder frag bei Unklarheiten im C++-Forum nach. Sei dabei aber offen, etwas neues zu lernen, anstatt darauf zu bestehen, dass es etwas ist was du schon kennst unter einem Buzzwordnamen. Jedenfalls hoffe ich für dich, dass es dir zu denken gibt, wenn gleich mehrere der erfahrenen C++'ler im Forum dir unabhängig sagen, dass du das nicht richtig verstanden hast.

[Xin]

asc schrieb:

Xin schrieb:

SeppJ schrieb:

Bei RAII ist es vollkommen egal, ob ein Objekt im automatischen oder im Freispeicher liegt. ... Aber ich denke, du bist auch ganz froh, dass ein vector<string> hinter sich aufräumt, obwohl die Strings im Freispeicher liegen.

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

Du hast imho RAII nicht verstanden.

Deine bescheidene Meinung in Ehren, aber bei allem was Du gequotet und geschrieben hast, wäre sicher auch Platz für eine Begründung/Erklärung gewesen. So lastet der Kern Deiner Aussage imho stark auf Deinem 'imho'.

Ich lerne gerne dazu, weiß auch nicht alles und habe sicherlich auch nicht alles verstanden. Ich lasse mich auch gerne in Frage stellen. Im "schlimmsten" Fall lerne ich ja was dazu, wenn ich falsch liege. Nach Wikipedia scheine ich nicht falsch zu liegen - von daher würde mich freuen, wenn Du Dein "imho" etwas begründen würdest, damit ich verstehe, wie Du zu Deiner ho kommst.

Shade Of Mine schrieb:

Wenn ich jemanden sage: nimm ein Singleton - dan weiß er genau was gemeint ist. Da gibt es dann keine 2 Interpretationen.

Ansonsten muss man eine halbe Stunde lang rumdiskutieren bis alle Beteiligten auf dem gleichen Stand sind.

Beim Singleton sind die Interpretationen bisher vergleichsweise langweilig meiner Erfahrung nach. Bei MVC hingegen öffnet man auch schnell mal die Büchse der Pandora.

Shade Of Mine schrieb:

PS:
und RAII hat mit Stack Variablen nicht viel zu tun - bis auf, dass die C++ Implementierung von RAII sehr oft Stack Variablen verwendet. In Perl gibt es zB keine Stack Objekte und trotzdem RAII.

Meinst Du Scope::Guard?

Zeigmal.

SeppJ schrieb:

asc schrieb:

Xin schrieb:

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

Du hast imho RAII nicht verstanden.

FTFY

Sorry Xin, aber du hast es wirklich nicht verstanden. Du redest dir ein, dass du es verstanden hättest und bist vermutlich sogar stolz darauf, dass du als einziger erkannt hast, dass das etwas triviales ist, was du schon längst wusstest. Aber du bist der einziger der das so sieht, weil du es falsch verstanden hast.

Ich werde jetzt nicht einzeln auf deine Aussagen eingehen, weil es nicht das Thema des Threads ist. Wenn du mehr wissen möchtest, dann lies es dir selber an oder frag bei Unklarheiten im C++-Forum nach. Sei dabei aber offen, etwas neues zu lernen, anstatt darauf zu bestehen, dass es etwas ist was du schon kennst unter einem Buzzwordnamen. Jedenfalls hoffe ich für dich, dass es dir zu denken gibt, wenn gleich mehrere der erfahrenen C++'ler im Forum dir unabhängig sagen, dass du das nicht richtig verstanden hast.

Gut... dann gib mir doch mal einen Tip, wo ich das richtige RAII nachlesen kann.

PS: Ich habe jetzt einige Seiten nachgegoogled... bevor hier einer mit lmgtfu ankommt... überall - inkl. Perllösungen - ist die Aussage die gleiche, wie ich sie hier gemacht habe. Das Objekt wird initialisiert, verwendet, der Scope wird abgebaut, der Destruktor der Variable aufgerufen.
Also wenn ich hier irgendwas nicht verstanden haben, dann werdet bitte entweder konkret, worum es euch hier geht oder lasst es.

Aber wenn alles was man von euch bekommt ist "Du hast es nicht verstanden und sieh zu wie Du damit klarkommst" ist, joah... mehr als googlen kann ich auch nicht.

[Shade Of Mine]

Xin schrieb:

Shade Of Mine schrieb:

Wenn ich jemanden sage: nimm ein Singleton - dan weiß er genau was gemeint ist. Da gibt es dann keine 2 Interpretationen.

Ansonsten muss man eine halbe Stunde lang rumdiskutieren bis alle Beteiligten auf dem gleichen Stand sind.

Beim Singleton sind die Interpretationen bisher vergleichsweise langweilig meiner Erfahrung nach. Bei MVC hingegen öffnet man auch schnell mal die Büchse der Pandora.

Sehe ich anders. Es gibt viele Implementierungen von MVC, aber jeder weiss was gemeint ist. Ich kann sagen "dass hier ist das Model" und jeder versteht die Zusammenhaenge.

Details sind Details und die koennen ruhig verschieden sein. Wichtig ist die gemeinsame Sprache.

Meinst Du Scope::Guard?

Zeigmal.

Was willst du sehen? Perl Objekte sind Reference Counted. Wenn die letzte Referenz hops geht, wird DESTROY aufgerufen.

PS:
hier etwas Code: http://docstore.mik.ua/orelly/perl4/prog/ch12_06.htm

[Xin]

Shade Of Mine schrieb:

Sehe ich anders. Es gibt viele Implementierungen von MVC, aber jeder weiss was gemeint ist. Ich kann sagen "dass hier ist das Model" und jeder versteht die Zusammenhaenge.

Details sind Details und die koennen ruhig verschieden sein. Wichtig ist die gemeinsame Sprache.

Mir scheint, die RAII Geschichte scheitert gerade an genau solch einem Detail. Denn ich liege hier ja scheinbar falsch, womit die gemeinsame Sprache scheitert, und dennoch keiner dieses Detail bisher benennt.

Shade Of Mine schrieb:

Meinst Du Scope::Guard?

Zeigmal.

Was willst du sehen? Perl Objekte sind Reference Counted. Wenn die letzte Referenz hops geht, wird DESTROY aufgerufen.

Und eine Referenz geht hops, wenn sie der entsprechende Scope verlassen wird...!?
Sofern die Antwort ja lautet, wird der Stack des Scopes abgebaut, was den RefCounter runtersetzt und entsprechend DESTROY aufruft. Somit verstehe ich weiterhin nicht, was ich hier nicht angeblich nicht verstanden haben soll oder warum Perl hier überhaupt ins Rennen ging, wenn der Sachverhalt identisch zu C++ ist. Eine Variable auf dem Stack hat einen konstanten RefCount von 1, auch dann, wenn es ein Smart-Pointer ist, der selbst einen RefCount von 1 hat, aber auf ein Objekt zeigt, dass einen beliebigen RefCount besitzt.

Oder Perl macht hier was vollkomemn anderes, dann würde ich das gerne vergleichen können, um zu sehen, was Perl bei RAII so anders macht, als ich RAII verstehe. Um zu sehen, wo ich mich nach SeppJ's Aussage für Neues öffnen sollte.

[Shade Of Mine]

Xin schrieb:

Und eine Referenz geht hops, wenn sie der entsprechende Scope verlassen wird...!?
Sofern die Antwort ja lautet, wird der Stack des Scopes abgebaut, was den RefCounter runtersetzt und entsprechend DESTROY aufruft.

Die Antwort lautet nein. Die Referenz kann auch durch Zuweisung hops gehen.

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

Und eine Referenz geht hops, wenn sie der entsprechende Scope verlassen wird...!?
Sofern die Antwort ja lautet, wird der Stack des Scopes abgebaut, was den RefCounter runtersetzt und entsprechend DESTROY aufruft.

Die Antwort lautet nein. Die Referenz kann auch durch Zuweisung hops gehen.

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. Ob die Resource selbst dann freigegeben würde, entscheidet dann allerdings der RefCounter, womit RAII semantisch ungefähr den Wert hat von "Das Objekt befindet sich nach der Konstruktion in einem validen Zustand", also eher eine Worthülse.

Ich sehe hier irgendwie immer noch nichts Neues. Ich sehe nur, dass das Objekt, dass auf dem Stack liegt ein SmartPtr ist und alles genauso abläuft, wie ich es zuvor beschrieben habe.

Also ist Perl scheinbar nicht das optimale Beispiel mir "richtiges RAII" zu zeigen.
Alternativ sind SmartPtr gleichbedeutend mit RAII unter der Bedingung, dass aufwändigere Objekte nicht auf dem Stack konstruiert werden können... Dann können wir bald Buzzword Bingo spielen.

Vielleicht kann SeppJ ja die Sache noch von einer anderen Seite beleuchten, denn alles was ich bisher bei Google gefunden habe, liefert mir keine neue Perspektive. Das muss an mir liegen und meiner mangelnden Offenheit und meinem Unverständnis von RAII. Das ist eine valide Option. Die Option, dass ich es verstanden habe und mir einfach drei erfahrene C++-Leute was anderes einreden wollen, bleibt allerdings ebenfalls eine Option.

Wenn mir jemand einen Aspekt nennen kann, der von mir unberücksichtigt ist, werde ich das durchaus anerkennen und bejahen. Aber der Spruch "Du hast RAII nicht verstanden" reicht nur, um zu googlen und bisher ergab sich daraus, dass Option 2 nicht ausgeschlossen werden kann.

[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.