Zufällige Schriftart auswählen

  • Amin Negm-Awad schrieb:

    Welche Heap-Geschichte gibt es denn zu verstecken? Kannst du mal ein Beispiel und Gegenbeispiel machen?

    Ein vector legt ja (in aller Regel, wohl aber nicht nach Standard?) seinen Speicher auf dem Heap an. Ich merke davon aber nichts und bekomme keinen Pointer zu sehen.
    Ich kann ein etwa shared_ptr auf dem Stack anlegen, der ein Heap-Objekt verwaltet, intern Retain-Counting macht und wenn es vom Stack fliegt (out-of-scope), gibs ein Release and den Pointer.
    Kurz, mit

    C-Quellcode

    1. shared_ptr<int> foo(new int[1024]);
    muss ich mir keine grossen Gedanken machen; "foo" liegt auf dem Stack und wird automatisch freigegeben, wenn der Stack endet, und gibt dabei das Heap-Array frei. Es sei denn, es gab vorher eine Zuweisung an ein anderes Objekt, dann ist "foo" zwar immer noch weg, aber das gleiche Array bleibt im Heap bestehen. Solange, wie noch irgend ein
    smart_ptr irgendwo drauf zeigt. Ganz ohne autorelease und Pools und sonstewas.
    ♥C++

  • Und wo liegt jetzt bei der ganzen Aufzählung der Unterschied zu

    Quellcode

    1. NSMutableArray* foor = [NSMutableArray arrayWithCapacity:100];


    Dein Vorteil von Heapobjekten unter C++ liegt daran, dass Stackobjekte in C++ nicht automatisch behandelt werden. In Objectiev-C gibt es dieses Problem erst gar nicht, weil der ARP existiert.

    Ich merke übrigens auch nichts davon, ob etwas auf dem Heap oder dem Stack liegt. Wie sollte ich auch?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Und wo liegt jetzt bei der ganzen Aufzählung der Unterschied zu

    Quellcode

    1. NSMutableArray* foor = [NSMutableArray arrayWithCapacity:100];


    Dein Vorteil von Heapobjekten unter C++ liegt daran, dass Stackobjekte in C++ nicht automatisch behandelt werden. In Objectiev-C gibt es dieses Problem erst gar nicht, weil der ARP existiert.

    Ich merke übrigens auch nichts davon, ob etwas auf dem Heap oder dem Stack liegt. Wie sollte ich auch?

    Wenn ich self.foo=foor mache, muss ich (bzw. der Setter) ein retain/copy machen und am Ende ein release, wenn "self" released wird. Gut, das mag der Setter für mich übernehmen und die kann man automatisch erzeugen lassen. Ich gebe zu, man muss nicht allzuoft selber retain/release in Obj-C senden.

    Was meinst Du mit "automatisch behandeln"?
    ♥C++

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Und wo liegt jetzt bei der ganzen Aufzählung der Unterschied zu

    Quellcode

    1. NSMutableArray* foor = [NSMutableArray arrayWithCapacity:100];


    Dein Vorteil von Heapobjekten unter C++ liegt daran, dass Stackobjekte in C++ nicht automatisch behandelt werden. In Objectiev-C gibt es dieses Problem erst gar nicht, weil der ARP existiert.

    Ich merke übrigens auch nichts davon, ob etwas auf dem Heap oder dem Stack liegt. Wie sollte ich auch?

    Wenn ich self.foo=foor mache, muss ich (bzw. der Setter) ein retain/copy machen und am Ende ein release, wenn "self" released wird. Gut, das mag der Setter für mich übernehmen und die kann man automatisch erzeugen lassen. Ich gebe zu, man muss nicht allzuoft selber retain/release in Obj-C senden.

    Was meinst Du mit "automatisch behandeln"?

    Eine im ARP erzeugte Instanz wird automatsich entfernt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    zerm schrieb:

    Amin Negm-Awad schrieb:

    Und wo liegt jetzt bei der ganzen Aufzählung der Unterschied zu

    Quellcode

    1. NSMutableArray* foor = [NSMutableArray arrayWithCapacity:100];


    Dein Vorteil von Heapobjekten unter C++ liegt daran, dass Stackobjekte in C++ nicht automatisch behandelt werden. In Objectiev-C gibt es dieses Problem erst gar nicht, weil der ARP existiert.

    Ich merke übrigens auch nichts davon, ob etwas auf dem Heap oder dem Stack liegt. Wie sollte ich auch?

    Wenn ich self.foo=foor mache, muss ich (bzw. der Setter) ein retain/copy machen und am Ende ein release, wenn "self" released wird. Gut, das mag der Setter für mich übernehmen und die kann man automatisch erzeugen lassen. Ich gebe zu, man muss nicht allzuoft selber retain/release in Obj-C senden.

    Was meinst Du mit "automatisch behandeln"?

    Eine im ARP erzeugte Instanz wird automatsich entfernt.

    Stack-Objekte in C++ werden entsprechend auch automatisch behandelt, in dem sie ja eine "Nachricht" bekommen, wenn der Stack aufgelöst wird. shared_ptr schafft das gleiche wie ein ARP, nur müssen die Objekte dafür nicht zentral verwaltet werden, und niemand muss im Hintergrund [drain] senden.
    ♥C++

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    zerm schrieb:

    Amin Negm-Awad schrieb:

    Und wo liegt jetzt bei der ganzen Aufzählung der Unterschied zu

    Quellcode

    1. NSMutableArray* foor = [NSMutableArray arrayWithCapacity:100];


    Dein Vorteil von Heapobjekten unter C++ liegt daran, dass Stackobjekte in C++ nicht automatisch behandelt werden. In Objectiev-C gibt es dieses Problem erst gar nicht, weil der ARP existiert.

    Ich merke übrigens auch nichts davon, ob etwas auf dem Heap oder dem Stack liegt. Wie sollte ich auch?

    Wenn ich self.foo=foor mache, muss ich (bzw. der Setter) ein retain/copy machen und am Ende ein release, wenn "self" released wird. Gut, das mag der Setter für mich übernehmen und die kann man automatisch erzeugen lassen. Ich gebe zu, man muss nicht allzuoft selber retain/release in Obj-C senden.

    Was meinst Du mit "automatisch behandeln"?

    Eine im ARP erzeugte Instanz wird automatsich entfernt.

    Stack-Objekte in C++ werden entsprechend auch automatisch behandelt, in dem sie ja eine "Nachricht" bekommen, wenn der Stack aufgelöst wird. shared_ptr schafft das gleiche wie ein ARP, nur müssen die Objekte dafür nicht zentral verwaltet werden, und niemand muss im Hintergrund [drain] senden.

    Smartpointer behandeln das., nicht Stackobjekte. Smartpointer sind eigene Objekte.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Smartpointer behandeln das., nicht Stackobjekte. Smartpointer sind eigene Objekte.

    Das wird aber erst durch Stack-Objekte ermöglicht.

    Ausserdem, ich bin manchmal gezwungen einen eigenen ARP anzulegen, damit viele/grosse lokale Objekte "schnell genug" freigegeben werden. Sind die Objekte gleich auf dem Stack habe ich das Problem nicht.
    Ich bin grad nicht sicher, wann wird der App-ARP geleert? Durch die Runtime, etwa regelmässig in objc_msgSend (das klappt ja gar nicht so ohne weiteres?), oder durch die NSApplication zwischen den Events?
    ♥C++

  • Richtig, Stackobjekte bergen bestimmte Probleme, die ich durch Smartpointer lösen kann, die erst durch Stackobjekte ermöglicht werden.

    Ja, wenn man in einer Schleife viele große Objekte anlegt, braucht man einen eigenen ARP. Und wie geht das Smartpointern?
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Ja, wenn man in einer Schleife viele große Objekte anlegt, braucht man einen eigenen ARP. Und wie geht das Smartpointern?

    Wenn die Objekte nur innerhalb der Schleife leben sollen, alloziiere ich sie einfach auf dem Stack. fertig.

    Quellcode

    1. for(int i=0; i<10000; ++i) {
    2. std::vector<int> vec(10000,0); /// vector mit 10000 einträgen
    3. ...
    4. /// ende der schleife = ende des scopes = vektor wird freigegeben.
    5. }
    ♥C++

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Ja, wenn man in einer Schleife viele große Objekte anlegt, braucht man einen eigenen ARP. Und wie geht das Smartpointern?

    Wenn die Objekte nur innerhalb der Schleife leben sollen, alloziiere ich sie einfach auf dem Stack. fertig.

    Quellcode

    1. for(int i=0; i<10000; ++i) {
    2. std::vector<int> vec(10000,0); /// vector mit 10000 einträgen
    3. ...
    4. /// ende der schleife = ende des scopes = vektor wird freigegeben.
    5. }

    Es geht nicht um den Container, der überleben soll, sondern um die Zwischenobjekte.

    Und ich sehe immer noch nicht den Vorteil für zwei Arten der Instantierung. Du schreibst die ganze Zeit, was keinen Nachteil darstellt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    zerm schrieb:

    Amin Negm-Awad schrieb:

    Ja, wenn man in einer Schleife viele große Objekte anlegt, braucht man einen eigenen ARP. Und wie geht das Smartpointern?

    Wenn die Objekte nur innerhalb der Schleife leben sollen, alloziiere ich sie einfach auf dem Stack. fertig.

    Quellcode

    1. for(int i=0; i<10000; ++i) {
    2. std::vector<int> vec(10000,0); /// vector mit 10000 einträgen
    3. ...
    4. /// ende der schleife = ende des scopes = vektor wird freigegeben.
    5. }

    Es geht nicht um den Container, der überleben soll, sondern um die Zwischenobjekte.

    Ob das ein Container oder was auch immer ist, ist egal. Wenn es auf dem Stack angelegt wurde, ist es automatisch weg, wenn es aus dem Scope geht. Und wenn das Objekt so gross ist, dass es nicht auf den Stack passt, kann ich auch scoped_ptr nehmen (der auf dem Stack stellvertretend liegt) und das Objekt freigibt, wenn es Out-of-scope wandert; das ist aber üblicherweise gar nicht nötig.

    Amin Negm-Awad schrieb:


    Und ich sehe immer noch nicht den Vorteil für zwei Arten der Instantierung. Du schreibst die ganze Zeit, was keinen Nachteil darstellt.

    In den meisten Fällen reicht es völlig aus, wenn das Objekt, mit dem man Arbeitet, nur auf dem Stack liegt und automatisch freigegeben wird, wenn der Stack verschwindet. Eigentlich ist das wirklich schöne, in meinen Augen, eben diese Scropedness. Würde in Obj-C automatische eine outOfScope Nachricht an Instanzen gesendet werden, könnte man in Obj-C auch den shared_ptr fast nachbauen. Noch =Operator-Überladung bzw. automatischer Copy-C'tor und niemand bräuchte mehr retain/release/autorelease aktiv benutzen; von daher gebe ich Dir aber recht, dass es keinen so grosses Unterschied macht, ob etwas "tatsächlich" auf dem Stack oder auf dem Heap liegt.
    Gut, bei kleinen Objekten ist es sicherlich vorteilhaft, wenn der Speicher nicht jedesmal neu angelegt werden muss. Ich denke, es wird einen Grund haben, dass NSPoint und NSRect PODs sind...
    ♥C++

  • Ich will keinen Shared-Pointer nachbauen. Ich habe RC und ARP. Wieso sollte ich etwas nachbauen wollen, was nur existiert, weil es in C++ kein RC und ARP gibt?

    Das belegt mal wieder den eitlen Selbstzweck von C++.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Ich will keinen Shared-Pointer nachbauen. Ich habe RC und ARP. Wieso sollte ich etwas nachbauen wollen, was nur existiert, weil es in C++ kein RC und ARP gibt?

    Das belegt mal wieder den eitlen Selbstzweck von C++.

    Ich kann genausogut sagen, dass es den ARP in Obj-C nur gibt, weil es kein Shared-Pointer gibt. RC ist in C++ ansonsten üblich, siehe shared_pointer.
    Ich bekomme das gleiche, was der ARP leistet, nur noch mehr. Was ist daran "eiteler Selbstzweck"?
    ♥C++

  • Eben: Du kannst es genauso gut sagen. Wozu benötige ich also zwei Systeme der Instantierung?

    Eitler Selbstzweck ist daran, dass es das Problem "Speicherverwaltung" in jeder Programmiersprache gibt. C++ löste das irgendwann einmal mit Smart-Pointern. Objective-C löste das immer schon mit RC und ARP. Zwei Sprachen, zwei Ansätze.

    Jetzt fragst du, wieso es nicht Smart-Pointer in Objective-C gibt. Diese Frage ist nur dann sinnvoll, wenn es einem darum an sich geht und nicht um die Problemlösung. Die existiert ja bereits.

    Also nur Selbstzweck. (Der ist freilich immer eitel.)

    Ich habe nichts gegen Smart-Pointer, sie sind sogar eine elegante Lösung. Aber sie sind in Objective-C eine überflüssige Lösung. Und ganz gewiss rechtfertigen sie keine Stackinstanzen und damit ein zweites System.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    Na, ja, mit GC ginge es.

    Das glaube ich nicht. Das Objekt liegt ja auf dem Stack und der wird ja bei jedem Funktions- und Methodenaufruf verändert, z. B.:

    Quellcode

    1. [self weiseStringZu]; // Hier ist eine von den o. g. Zuweisungen drin
    2. [self tiefVerschachtelteRekursion];

    Der zweite Aufruf überschreibt Dir zuverlässig Dein Stringobjekt auf dem Stapel.

    Das sollte nicht so sein, weder mit ID noch mit einer INstanz, weil bei jedem Aufruf das Objekt im C-Sinne neu erschaffen wird.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Eben: Du kannst es genauso gut sagen. Wozu benötige ich also zwei Systeme der Instantierung?

    Eitler Selbstzweck ist daran, dass es das Problem "Speicherverwaltung" in jeder Programmiersprache gibt. C++ löste das irgendwann einmal mit Smart-Pointern. Objective-C löste das immer schon mit RC und ARP. Zwei Sprachen, zwei Ansätze.

    Jetzt fragst du, wieso es nicht Smart-Pointer in Objective-C gibt. Diese Frage ist nur dann sinnvoll, wenn es einem darum an sich geht und nicht um die Problemlösung. Die existiert ja bereits.

    Also nur Selbstzweck. (Der ist freilich immer eitel.)

    Ich habe nichts gegen Smart-Pointer, sie sind sogar eine elegante Lösung. Aber sie sind in Objective-C eine überflüssige Lösung. Und ganz gewiss rechtfertigen sie keine Stackinstanzen und damit ein zweites System.

    Ok, sicherlich. Persönlich ziehe ich smart_pointer bzw "Stack-Objekte" dem ARP vor, weil man sich eben noch weniger um retain/release kümmern muss. Ich würde es entsprechend auch nicht schlimm finden, wenn Obj-C das anstelle des ARP übernehmen würde.

    Ich sehe Deinen Punkt. Wirklich brauchen tut man es in Obj-C wirklich nicht. Es sollte in der Regel auch egal sein, oder ein Objekt direkt am Ende des Scopes zerstört wird, ob wenn das nächste mal der ARP geleert wird. Und Exceptions werden ohnehin nicht so wirklich in Obj-C benötigt, als das man es dafür bräuchte.

    EDIT:
    Im Prinzip gibt es ja aber Exceptions in Obj-C. Was passiert, wenn ich lokal(=nur innerhalb einer Methode und nur für diese Methode) ein NSStream öffne, und dann eine Exception fliegt? Bleibt die Resource vom Stream dann für immer blockiert und der einzige Ausweg wäre ein Neustart der Anwendung?
    ♥C++

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von zerm ()

  • ?

    Es gibt auch Exceptions in Objective-C. Diese funktionieren inzwischen sogar intern genau so wie die in C++, weil die unterschiedlichen Systeme Probleme bei Objective-C++ bereiteten.

    Sie kommen bloß außerordentlich selten vor und man versucht sie zu vermeiden, wo es geht.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?