Convenient constructors in ARC

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • gritsch schrieb:

    mir ist grad eingefallen dass zwischen ARC und MRC zur laufzeit ja gar nicht unterschieden werden kann. also fliegen mit convenience-constructor erstellte objekte immer in den ARP.


    Das ist auch nicht ganz richtig. Clang fügt Paare von objc_autoreleaseReturnValue und objc_retainAutoreleasedReturnValue ein, wenn die sowohl im aufrufenden als auch im aufgerufenen Code sind wird der Autorelease Pool umgangen. Das ist aber ein Implementationsdetail das einen eigentlich nicht kümmern sollte.

    Apple Inc. schrieb:


    objc_autoreleaseReturnValue() examines the caller's instructions following the return. If the caller's instructions immediately call objc_autoreleaseReturnValue objc_retainAutoreleasedReturnValue, then the callee omits the -autorelease and saves the result in thread-local storage. If the caller does not look like it cooperates, then the callee calls -autorelease as usual.

    objc_autoreleaseReturnValue objc_retainAutoreleasedReturnValue checks if the returned value is the same as the one in thread-local storage. If it is, the value is used directly. If not, the value is assumed to be truly autoreleased and is retained again. In either case, the caller now has a retained reference to the value.


    Allerdings natürlich ein Zeichen, dass der Compiler effizienter ist als händische Zählung, es sein denn man verletzt die Basic Memory Management Rules und macht seinen Code unwartbar für Andere.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von SteveJ ()

  • chartus schrieb:

    <p>&hellip;ich w&uuml;rde ja sagen, dass das alles egal ist, da der ARC sich eher wenig um eure sleeps k&uuml;mmert sonder nur aufr&auml;umt wenn dem 'd' ein neuer wert zugewiesen wird&hellip; bzw anderweitig die referenz erlischt...</p>


    ich fang mal von hinten an...

    die sleeps sind ja dazu da dass er die methode nicht verlässt.
    ich wollte ja testen ob die objekte (wie eigentlich erwartet) beim verlassen des scopes released werden (und das werden sie natürlich nicht wenn sie im ARP liegen).

    übrigens: ist dir nicht aufgefallen dass dein post so gut wie unlesbar ist?
  • quten geht nicht mehr (zu viele levels?) deshalb hier so:

    Wie oben. Convenience Constructors beginnen nicht mit “alloc”, “new”, “copy”, oder “mutableCopy”, also packen sie das Resultat sinnvollerweise auf den Autorelease Pool, wenn sie kein Singleton zurückgeben. Oder sie haben ein Objektcache, auch denkbar. Was genau ist da jetzt das Problem?[/quote]es ist egal ob ARC mit ARP oder MRC mit ARP - ich dachte mit ARC wird der ARP vermieden aus dem grund den ich ja im ersten post aufzeige!"Convenience" steht aber nicht für ARP oder sonstwas sondern für einen komfortablen weg ein objekt zu erstellen. warum führt man keine neuen Convenience constructors an (von mir aus mit einem speziellen prefix)?und dass MRC besser sein kann (wenn man eben keine flüchtigkeitsfehler macht) kann man auch aus der doku rauslesen: clang.llvm.org/docs/AutomaticReferenceCounting.html
  • gritsch schrieb:


    SteveJ schrieb:

    Wie oben. Convenience Constructors beginnen nicht mit “alloc”, “new”, “copy”, oder “mutableCopy”, also packen sie das Resultat sinnvollerweise auf den Autorelease Pool, wenn sie kein Singleton zurückgeben. Oder sie haben ein Objektcache, auch denkbar. Was genau ist da jetzt das Problem?

    es ist egal ob ARC mit ARP oder MRC mit ARP - ich dachte mit ARC wird der ARP vermieden aus dem grund den ich ja im ersten post aufzeige!"Convenience" steht aber nicht für ARP oder sonstwas sondern für einen komfortablen weg ein objekt zu erstellen.


    Der Autorelease Pool wird ja auch vermieden - aber er ist eben nicht weg. Wenn man viele temporäre Objekte erzeugt ist es eine gute Idee einen Autorelease Block zu nutzen - im Zweifel hilft der Profiler.

    gritsch schrieb:

    warum führt man keine neuen Convenience constructors an (von mir aus mit einem speziellen prefix)?


    Warum sollte man? Ich verstehe Dein Problem immer noch nicht. Du kannst doch prima schreiben

    Quellcode

    1. [[NSString stringWithUTF8String:"Hello"] stringByAppendingString:@", world!"];


    was wesentlich einfacher ist als

    Quellcode

    1. [[[NSString alloc] initWithUTF8String:"Hello"] autorelease] stringByAppendingString:@", world!"];


    und bei ARC vermeidest du vielleicht noch den Autorelease Pool.

    gritsch schrieb:

    und dass MRC besser sein kann (wenn man eben keine flüchtigkeitsfehler macht) kann man auch aus der doku rauslesen: clang.llvm.org/docs/AutomaticReferenceCounting.html


    Ah, wo kann man das rauslesen?
  • SteveJ schrieb:

    gritsch schrieb:


    SteveJ schrieb:

    Wie oben. Convenience Constructors beginnen nicht mit “alloc”, “new”, “copy”, oder “mutableCopy”, also packen sie das Resultat sinnvollerweise auf den Autorelease Pool, wenn sie kein Singleton zurückgeben. Oder sie haben ein Objektcache, auch denkbar. Was genau ist da jetzt das Problem?

    es ist egal ob ARC mit ARP oder MRC mit ARP - ich dachte mit ARC wird der ARP vermieden aus dem grund den ich ja im ersten post aufzeige!"Convenience" steht aber nicht für ARP oder sonstwas sondern für einen komfortablen weg ein objekt zu erstellen.


    Der Autorelease Pool wird ja auch vermieden - aber er ist eben nicht weg. Wenn man viele temporäre Objekte erzeugt ist es eine gute Idee einen Autorelease Block zu nutzen - im Zweifel hilft der Profiler.

    gritsch schrieb:

    warum führt man keine neuen Convenience constructors an (von mir aus mit einem speziellen prefix)?


    Warum sollte man? Ich verstehe Dein Problem immer noch nicht. Du kannst doch prima schreiben

    Quellcode

    1. [[NSString stringWithUTF8String:"Hello"] stringByAppendingString:@", world!"];


    was wesentlich einfacher ist als

    Quellcode

    1. [[[NSString alloc] initWithUTF8String:"Hello"] autorelease] stringByAppendingString:@", world!"];


    und bei ARC vermeidest du vielleicht noch den Autorelease Pool.

    gritsch schrieb:

    und dass MRC besser sein kann (wenn man eben keine flüchtigkeitsfehler macht) kann man auch aus der doku rauslesen: clang.llvm.org/docs/AutomaticReferenceCounting.html


    Ah, wo kann man das rauslesen?


    meine urprungsfrage ist nach wie vor: wenn ARC schon funktioniert, wozu brauchts dann noch den ARP?

    in der doku stehts natürlich nirgends explizit aber man kann rauslesen dass retains und release eingebaut werden wo eigentlich keine sein müssten, der compiler es aber nicht 100% entscheiden kann. auf diese kann man bei MRC manchmal verzichten (auch unter beachtung der guidelines ;-))
  • gritsch schrieb:

    meine urprungsfrage ist nach wie vor: wenn ARC schon funktioniert, wozu brauchts dann noch den ARP?

    Weil ganz simpel ausgedrückt, ARC nichts weiter macht, als dir Tipparbeit abzunehmen. Der Compiler schreibt für dich die ganzen retain, release, autorelease Nachrichten in den Code. An der grundsätzlichen Funktionsweise des Reference Counting in Cocoa ändert ARC gar nichts.
  • gritsch schrieb:


    meine urprungsfrage ist nach wie vor: wenn ARC schon funktioniert, wozu brauchts dann noch den ARP?


    Weil sich an den Basic Memory Management Rules nichts geändert hat. Die sind nicht neu aufgestellt, sondern genau so wie immer - und setzen eben einen Autorelease Pool voraus, den ARC auch benutzt.

    Das der Compiler Aufrufe wegoptimieren kann heisst nicht das er es in 100% der Fälle auch tut. Nur weil der Compiler „60 * 60“ durch 3600 ersetzt wird die Multiplikation nicht überflüssig...

    gritsch schrieb:

    in der doku stehts natürlich nirgends explizit aber man kann rauslesen dass retains und release eingebaut werden wo eigentlich keine sein müssten, der compiler es aber nicht 100% entscheiden kann. auf diese kann man bei MRC manchmal verzichten (auch unter beachtung der guidelines ;-))


    Interessant. Wir hatten ja schon festgestellt, das der Compiler Aufrufe von - autorelease sparen kann die du bei manueller Zählung machen musst. Da du dich ja scheinbar länger mit dem Thema beschäftigt hast, nenn doch mal ein Beispiel in dem manuelle Referenzzählung signifikant effizienter ist.
  • SteveJ schrieb:

    gritsch schrieb:


    meine urprungsfrage ist nach wie vor: wenn ARC schon funktioniert, wozu brauchts dann noch den ARP?


    Weil sich an den Basic Memory Management Rules nichts geändert hat. Die sind nicht neu aufgestellt, sondern genau so wie immer - und setzen eben einen Autorelease Pool voraus, den ARC auch benutzt.

    Das der Compiler Aufrufe wegoptimieren kann heisst nicht das er es in 100% der Fälle auch tut. Nur weil der Compiler „60 * 60“ durch 3600 ersetzt wird die Multiplikation nicht überflüssig...

    gritsch schrieb:

    in der doku stehts natürlich nirgends explizit aber man kann rauslesen dass retains und release eingebaut werden wo eigentlich keine sein müssten, der compiler es aber nicht 100% entscheiden kann. auf diese kann man bei MRC manchmal verzichten (auch unter beachtung der guidelines ;-))


    Interessant. Wir hatten ja schon festgestellt, das der Compiler Aufrufe von - autorelease sparen kann die du bei manueller Zählung machen musst. Da du dich ja scheinbar länger mit dem Thema beschäftigt hast, nenn doch mal ein Beispiel in dem manuelle Referenzzählung signifikant effizienter ist.


    von SIGNIFIKANT hab ich nie was gesagt ;)

    ich dachte eben dass der ARP komplett rausfliegt.
    wenn man eben nicht mehr davon aus geht dass nur alloc, new, copty etc ein retained objekt zurückgibt sondern eben alle methoden, dann brauch tman doch keinen ARP mehr. will jemand das objekt behalten schickt er eben ein retain (und natütlich irgendwann das entsprechende release - das ganze kann dann gerne von ARC übernommen werden ;-))
  • Michael schrieb:

    Der Compiler schreibt für dich die ganzen retain, release, autorelease Nachrichten in den Code.


    Tja, woher weiß denn der Compiler jetzt, wann er ein Release und wann ein Autorelease reinsetzen soll?

    Und warum sendet der beim Verlassen des durch {} begrenzten Scopes kein -release?
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Marco Feltmann schrieb:

    Michael schrieb:

    Der Compiler schreibt für dich die ganzen retain, release, autorelease Nachrichten in den Code.


    Tja, woher weiß denn der Compiler jetzt, wann er ein Release und wann ein Autorelease reinsetzen soll?

    Und warum sendet der beim Verlassen des durch {} begrenzten Scopes kein -release?


    macht er wohl, nur dadurch dass sich das objekt im ARP befindet wird es erst dealloziert sobald der ARP geleert wird - deswegen wollt ich den ja weghaben (es wurde ja getan als wäre das ARC eine wahnsinns revelution...)
  • Marco Feltmann schrieb:

    Michael schrieb:

    Der Compiler schreibt für dich die ganzen retain, release, autorelease Nachrichten in den Code.


    Tja, woher weiß denn der Compiler jetzt, wann er ein Release und wann ein Autorelease reinsetzen soll?

    Und warum sendet der beim Verlassen des durch {} begrenzten Scopes kein -release?

    Der Compiler weiss das durch den Analyzer und schmeisst die Variablen in den Autoreleasepool.
    Kann man bei Mike Ash nachlesen.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.
  • Chris schrieb:

    Marco Feltmann schrieb:

    Michael schrieb:

    Der Compiler schreibt für dich die ganzen retain, release, autorelease Nachrichten in den Code.


    Tja, woher weiß denn der Compiler jetzt, wann er ein Release und wann ein Autorelease reinsetzen soll?

    Und warum sendet der beim Verlassen des durch {} begrenzten Scopes kein -release?

    Der Compiler weiss das durch den Analyzer und schmeisst die Variablen in den Autoreleasepool.
    Kann man bei Mike Ash nachlesen.

    Chris


    nein, in den autorelease-pool wird es beim erstellen des objektes geworfen!
  • Marco Feltmann schrieb:

    Michael schrieb:

    Der Compiler schreibt für dich die ganzen retain, release, autorelease Nachrichten in den Code.


    Tja, woher weiß denn der Compiler jetzt, wann er ein Release und wann ein Autorelease reinsetzen soll?

    Der Compiler kennt genau die gleichen Speicherverwaltungsregeln, die du beim manuellem Reference Counting anwendest.

    Marco Feltmann schrieb:

    Und warum sendet der beim Verlassen des durch {} begrenzten Scopes kein -release?

    Tut er doch. Kommt halt drauf an, wie ein Objekt in dem Scope erzeugt wird:

    Quellcode

    1. int main(int argc, const char * argv[])
    2. {
    3. @autoreleasepool {
    4. NSInteger x = 42;
    5. NSString __weak *s1;
    6. NSString __weak *s2;
    7. {
    8. NSMutableString *foo = [[NSMutableString alloc] initWithFormat:@"%ld", (long)x];
    9. s1 = foo;
    10. NSMutableString *bar = [NSMutableString stringWithFormat:@"%ld", (long)x];
    11. s2 = bar;
    12. NSLog(@"Weak Variablen vor Verlassen des Scopes:");
    13. NSLog(@"s1 = %p", s1);
    14. NSLog(@"s2 = %p", s2);
    15. }
    16. NSLog(@"Weak Variablen nach Verlassen des Scopes:");
    17. NSLog(@"s1 = %p", s1);
    18. NSLog(@"s2 = %p", s2);
    19. }
    20. return 0;
    21. }
    Alles anzeigen
  • gritsch schrieb:

    SteveJ schrieb:

    gritsch schrieb:


    Interessant. Wir hatten ja schon festgestellt, das der Compiler Aufrufe von - autorelease sparen kann die du bei manueller Zählung machen musst. Da du dich ja scheinbar länger mit dem Thema beschäftigt hast, nenn doch mal ein Beispiel in dem manuelle Referenzzählung signifikant effizienter ist.

    von SIGNIFIKANT hab ich nie was gesagt ;)


    Ok, der Compiler kann also Aufrufe weg optimieren die Du machen musst und sorgt für korrektes Speichermanagement, aber du bevorzugst händisches Zählen, weil du insignifikate Optimierungen vornehmen kannst? Klingt nach einem schlechten Plan.

    gritsch schrieb:

    ich dachte eben dass der ARP komplett rausfliegt.


    Wie gesagt, es gibt hier gute Objective-C-Kurse im Forum. Oder mal ein Buch?

    gritsch schrieb:

    wenn man eben nicht mehr davon aus geht dass nur alloc, new, copty etc ein retained objekt zurückgibt sondern eben alle methoden,


    denn geht man eben von etwas Falschem aus. Erster Nachteil: Existierender Code ist mit neuem Code nicht mehr kompatibel, man bräuchte ein neues Object Ownership Model. Damit ist diese Idee schon gestorben.

    gritsch schrieb:

    dann brauch tman doch keinen ARP mehr. will jemand das objekt behalten schickt er eben ein retain (und natütlich irgendwann das entsprechende release - das ganze kann dann gerne von ARC übernommen werden ;-))


    Und das "deferred release"? Geht nicht mehr? Du willst also zum Speichermodell von Core Foundation zurück?

    gritsch schrieb:

    es wurde ja getan als wäre das ARC eine wahnsinns revelution...


    War es 2011. Kann mit Garbage Collection konkurrieren und mit existierendem Code koexistieren. Ziemlich klasse, finde ich - du hast bei weitem nichts vorgeschlagen was da ran kommen würde. Außer: „Ich bleibe auf dem Stand von 2010, das geht ja auch noch“.
  • SteveJ schrieb:

    gritsch schrieb:

    SteveJ schrieb:

    gritsch schrieb:


    Interessant. Wir hatten ja schon festgestellt, das der Compiler Aufrufe von - autorelease sparen kann die du bei manueller Zählung machen musst. Da du dich ja scheinbar länger mit dem Thema beschäftigt hast, nenn doch mal ein Beispiel in dem manuelle Referenzzählung signifikant effizienter ist.

    von SIGNIFIKANT hab ich nie was gesagt ;)


    Ok, der Compiler kann also Aufrufe weg optimieren die Du machen musst und sorgt für korrektes Speichermanagement, aber du bevorzugst händisches Zählen, weil du insignifikate Optimierungen vornehmen kannst? Klingt nach einem schlechten Plan.

    gritsch schrieb:

    ich dachte eben dass der ARP komplett rausfliegt.


    Wie gesagt, es gibt hier gute Objective-C-Kurse im Forum. Oder mal ein Buch?

    gritsch schrieb:

    wenn man eben nicht mehr davon aus geht dass nur alloc, new, copty etc ein retained objekt zurückgibt sondern eben alle methoden,


    denn geht man eben von etwas Falschem aus. Erster Nachteil: Existierender Code ist mit neuem Code nicht mehr kompatibel, man bräuchte ein neues Object Ownership Model. Damit ist diese Idee schon gestorben.

    gritsch schrieb:

    dann brauch tman doch keinen ARP mehr. will jemand das objekt behalten schickt er eben ein retain (und natütlich irgendwann das entsprechende release - das ganze kann dann gerne von ARC übernommen werden ;-))


    Und das "deferred release"? Geht nicht mehr? Du willst also zum Speichermodell von Core Foundation zurück?

    gritsch schrieb:

    es wurde ja getan als wäre das ARC eine wahnsinns revelution...


    War es 2011. Kann mit Garbage Collection konkurrieren und mit existierendem Code koexistieren. Ziemlich klasse, finde ich - du hast bei weitem nichts vorgeschlagen was da ran kommen würde. Außer: „Ich bleibe auf dem Stand von 2010, das geht ja auch noch“.


    doch, ich hab doch vorgeschlagen nicht nur bei alloc, copy etc retained objekte zurückzugeben sondern immer ;)

    edit: quote funktioniert nicht :-/
  • gritsch schrieb:

    SteveJ schrieb:


    gritsch schrieb:

    wenn man eben nicht mehr davon aus geht dass nur alloc, new, copty etc ein retained objekt zurückgibt sondern eben alle methoden,


    denn geht man eben von etwas Falschem aus. Erster Nachteil: Existierender Code ist mit neuem Code nicht mehr kompatibel, man bräuchte ein neues Object Ownership Model. Damit ist diese Idee schon gestorben.

    gritsch schrieb:

    es wurde ja getan als wäre das ARC eine wahnsinns revelution...


    War es 2011. Kann mit Garbage Collection konkurrieren und mit existierendem Code koexistieren. Ziemlich klasse, finde ich - du hast bei weitem nichts vorgeschlagen was da ran kommen würde. Außer: „Ich bleibe auf dem Stand von 2010, das geht ja auch noch“.


    doch, ich hab doch vorgeschlagen nicht nur bei alloc, copy etc retained objekte zurückzugeben sondern immer ;)


    Wie gesagt: Du hast bei weitem nichts vorgeschlagen was da ran kommen würde.
  • SteveJ schrieb:

    gritsch schrieb:

    SteveJ schrieb:


    gritsch schrieb:

    wenn man eben nicht mehr davon aus geht dass nur alloc, new, copty etc ein retained objekt zurückgibt sondern eben alle methoden,


    denn geht man eben von etwas Falschem aus. Erster Nachteil: Existierender Code ist mit neuem Code nicht mehr kompatibel, man bräuchte ein neues Object Ownership Model. Damit ist diese Idee schon gestorben.

    gritsch schrieb:

    es wurde ja getan als wäre das ARC eine wahnsinns revelution...


    War es 2011. Kann mit Garbage Collection konkurrieren und mit existierendem Code koexistieren. Ziemlich klasse, finde ich - du hast bei weitem nichts vorgeschlagen was da ran kommen würde. Außer: „Ich bleibe auf dem Stand von 2010, das geht ja auch noch“.


    doch, ich hab doch vorgeschlagen nicht nur bei alloc, copy etc retained objekte zurückzugeben sondern immer ;)


    Wie gesagt: Du hast bei weitem nichts vorgeschlagen was da ran kommen würde.


    wo ran? an den speicher-haltenden ARP?
  • gritsch schrieb:

    SteveJ schrieb:

    gritsch schrieb:

    SteveJ schrieb:


    gritsch schrieb:

    es wurde ja getan als wäre das ARC eine wahnsinns revelution...


    War es 2011. Kann mit Garbage Collection konkurrieren und mit existierendem Code koexistieren. Ziemlich klasse, finde ich - du hast bei weitem nichts vorgeschlagen was da ran kommen würde. Außer: „Ich bleibe auf dem Stand von 2010, das geht ja auch noch“.


    doch, ich hab doch vorgeschlagen nicht nur bei alloc, copy etc retained objekte zurückzugeben sondern immer ;)


    Wie gesagt: Du hast bei weitem nichts vorgeschlagen was da ran kommen würde.


    wo ran? an den speicher-haltenden ARP?


    An Automatic Reference Counting. Wenn Du den Autorelease Pool los werden möchtest heißt die Alternative Garbage Collection. Die ist blöderweise seit OS X 10.8 abgekündigt, aber wenn du in 2010 lebst macht dir das ja nichts aus.

    Andere schreiben halt schnell einen lokalen Autorelease Pool Block um Code der viele temporäre Objekte erzeugt. Wo da jetzt das Problem ist erschließt sich mir nicht so ganz.

    Klar ist das Speichermodell von Cocoa nicht das einzig denkbare. Java, C# und JavaScript nutzen Garbage Collection. Geht auch. Apple hat sich eben dagegen entschieden.

    Was du gerne hättest hat damals COM gemacht. Ich fand das wahnsinnig kompliziert, weil ich mich bei In-Out-Parametern, Kopien und Objekterzeugung dauernd verrechnete. Aber ich vergaß, Du bist ja perfekt.
  • SteveJ schrieb:

    gritsch schrieb:

    SteveJ schrieb:

    gritsch schrieb:

    SteveJ schrieb:


    gritsch schrieb:

    es wurde ja getan als wäre das ARC eine wahnsinns revelution...


    War es 2011. Kann mit Garbage Collection konkurrieren und mit existierendem Code koexistieren. Ziemlich klasse, finde ich - du hast bei weitem nichts vorgeschlagen was da ran kommen würde. Außer: „Ich bleibe auf dem Stand von 2010, das geht ja auch noch“.


    doch, ich hab doch vorgeschlagen nicht nur bei alloc, copy etc retained objekte zurückzugeben sondern immer ;)


    Wie gesagt: Du hast bei weitem nichts vorgeschlagen was da ran kommen würde.


    wo ran? an den speicher-haltenden ARP?


    An Automatic Reference Counting. Wenn Du den Autorelease Pool los werden möchtest heißt die Alternative Garbage Collection. Die ist blöderweise seit OS X 10.8 abgekündigt, aber wenn du in 2010 lebst macht dir das ja nichts aus.

    Andere schreiben halt schnell einen lokalen Autorelease Pool Block um Code der viele temporäre Objekte erzeugt. Wo da jetzt das Problem ist erschließt sich mir nicht so ganz.

    Klar ist das Speichermodell von Cocoa nicht das einzig denkbare. Java, C# und JavaScript nutzen Garbage Collection. Geht auch. Apple hat sich eben dagegen entschieden.

    Was du gerne hättest hat damals COM gemacht. Ich fand das wahnsinnig kompliziert, weil ich mich bei In-Out-Parametern, Kopien und Objekterzeugung dauernd verrechnete. Aber ich vergaß, Du bist ja perfekt.


    keine sorge, garbage collection bin ich complett übergangen (war auch gut so).

    also so wie die ankündigung von apple klang war/ist ARC ja sowas von genial dass ich dachte dass der ARP ersetzt wurde. es ersetzt einem aber anscheinend nur etwas tipp- und denk-arbeit (jaja, das ist schon viel, aber soooo amazing ist das nun auch nicht).
    ich bin mit dem ARP immer gut ausgekommen nur in zeiten von wenig speicher (iOS etc) und relativ schlechten programmiereren (wieder iOS - man muss ja schnell schnell millionär werden) hätte ich mir mehr erwartet von ARC.

    vielleicht werde ich ja von swift positiv überrascht - eines tages ;)
  • gritsch schrieb:


    also so wie die ankündigung von apple klang war/ist ARC ja sowas von genial dass ich dachte dass der ARP ersetzt wurde. es ersetzt einem aber anscheinend nur etwas tipp- und denk-arbeit (jaja, das ist schon viel, aber soooo amazing ist das nun auch nicht).


    Reference Counting ersetzt ja auch nur etwas Tipp- und Denkarbeit, malloc und free sind immer noch schneller und effizienter. Compiler ersetzen auch nur etwas Tipp- und Denkarbeit, C oder Maschinensprache ist immer noch schneller und effizienter.

    Wie gesagt: ARC kann mit Garbage Collection konkurrieren, funktioniert mit existierendem Code zusammen und ermöglicht dem Compiler Optimierungen die von Hand nicht zu machen sind. Das ist so was von genial - aber scheinbar für manche schwer zu begreifen.

    gritsch schrieb:

    ich bin mit dem ARP immer gut ausgekommen nur in zeiten von wenig speicher (iOS etc) und relativ schlechten programmiereren (wieder iOS - man muss ja schnell schnell millionär werden) hätte ich mir mehr erwartet von ARC.


    Nämlich? Keine Zusammenarbeit mit existierendem Code?

    Ansonsten: Scheinbar hat das Speichermodell von Cocoa es ermöglicht relativ effizient mit dem Speicher umzugehen - das spricht ja für Autorelease Pools. Schlechte Programmierer gibt es auf OS X auch schon seit langem, auf iOS passiert einfach deutlich mehr, also tauchen da auch mehr Anfänger auf.

    [Blockierte Grafik: http://fm.cnbc.com/applications/cnbc.com/resources/files/2014/01/22/comscore.jpg]

    Aber wer programmiert den heute nur noch auf OS X? Auf iOS kann man doch viel schneller reich werden...

    gritsch schrieb:

    vielleicht werde ich ja von swift positiv überrascht - eines tages ;)


    Du wirst enttäuscht sein: Swift nutzt ARC. 2010 war alles besser.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von SteveJ ()