Warum diese Speicherverwaltung in obj-c

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

  • Warum diese Speicherverwaltung in obj-c

    Hallo,

    Ich habe mich gestern durch ein Video2brain gewühlt zum Thema Programmieren. War allgemein gehalten. Javascript als Programmiersprache.

    Hier kommt auch meine Frage. Das einzige was mich bei Obj-c nervt ist die Speicherverwaltung bei Objekten. In C#, Java, Actionscript oder Javascript muss ich mich nicht darum kümmern nach der Erzeugung einer Instanz was im Speicher passiert.

    Warum in Obj-c. Was ist der Vorteil? Warum macht Apple das so. Will es nur verstehen. Im V2B meinte er, dass es etwas flexibler macht wie es in Obj-c gehalten ist. Mit den großen Nachteil des großen Aufwandes.

    Habe immer noch Probleme mit strong, weak etc. Kann es einem Programmierfreund von mir nicht erklären, warum wir das so machen. Er programmiert in C# und schlug die Hände vor das Gesicht als er das mit der Speicherverwaltung sah.

    Gibt es eine Seite, wo das wirklich mal für Begriffsstutzige erklärt wird? Damit es wenigstens verständlich ist.

    Grüße

    Martin S.
  • msteffenma schrieb:

    Warum in Obj-c.

    Im Gegensatz zu dem ganzen anderen Gelumpe ist Objective-C komplett auf C basierend.
    Dementsprechend musst Du auch die für C geltenden Speicherregeln beachten.

    msteffenma schrieb:

    Habe immer noch Probleme mit strong, weak etc.

    Wat?
    Das ist doch schon eine riesengroße Vereinfachung.
    Du musst Dich nicht mehr um Retain-Release Zyklen kümmern. Was willst Du denn noch?

    msteffenma schrieb:

    Er programmiert in C# und schlug die Hände vor das Gesicht als er das mit der Speicherverwaltung sah.

    Klar, weil es in C# ja keine weak reference gibt…
    Was für ein Heini!

    msteffenma schrieb:

    Gibt es eine Seite, wo das wirklich mal für Begriffsstutzige erklärt wird? Damit es wenigstens verständlich ist.

    Vermutlich nicht, weil das logisch ist.

    Objekte werden immer im Speicher gehalten, solange etwas auf sie referenziert. Ist nicht nur in Objective-C so, sondern auch in Java und C#. Eigentlich überall.
    Wenn Dein Objekt Auto vom Objekt Besitzer gehalten wird, Dein Objekt Besitzer Dein Objekt Auto hält und Dein Objekt Fuhrpark Dein Objekt Auto hält, hast Du unlösbare Abhängigkeiten.
    Wirfst Du Deinen Fuhrpark weg, sind nach wie vor Auto und Besitzer im Speicher, da sie sich gegenseitig am Leben halten – sie referenzieren aufeinander.

    In Java und C# hast Du genau dasselbe Problem. Dort kannst Du via WeakReference Klassen (System.WeakReference/C#; java.lang.ref.WeakReference/Java) arbeiten.
    An Hand des Namespace sieht man auch, dass dies grundlegende Funktionalitäten sind.

    Und wenn Dein Bekannter dies nicht kennt, sind seine Kenntnisse in der Speicherverwaltung unzureichend, sein C# Code wird sicherlich etliche Speicherlecke beinhalten und es spricht insgesamt nicht unbedingt für seine Qualitäten als Entwickler.

    Das Grundproblem wird bei Objective-C nur etwas weiter in den Vordergrund gerückt: Du musst Dir bereits beim Anlegen der Instanzvariable überlegen, ob die Referenz gehalten werden soll (strong) oder eben nicht (weak).
    «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
  • ich hätte auch noch einmal eine kleine frage zu diesen Thema wann benutzte ich atomic ?
    die Antwort währe jetzt darauf wenn mehre threads auf eine Eigenschaft zugreifen oder ?
    ich wollte das mal testen was passiert wenn es die Eigenschaft nonatomic ist und mehrere threads auf diese Eigenschaft zugreifen aber ich denke man kann das nicht testen weil es zufällig ist manchmal geht es manchmal nicht oder ?
  • msteffenma schrieb:

    In C#, Java, Actionscript oder Javascript muss ich mich nicht darum kümmern nach der Erzeugung einer Instanz was im Speicher passiert.

    Ja, das klappt bei kleinen Programmen vielleicht noch ganz gut. Dafür wird es für Dich richtig hart, wenn Du der Garbage-Collector sich zu Tode sucht und die App auf einmal anfängt zu hängen.
    „Meine Komplikation hatte eine Komplikation.“
  • Vielen, die von einer Garbage Collected-Umgebung zu einer Retain Counting-Umgebung wechseln, haben den Gedanken, dass das ja total umständlich und unpraktisch ist. Es sind einfach zwei verschiedene Ansätze, die beide Vor- und Nachteile haben. Das Thema lässt sich aber nicht "mal eben schnell" erklären, Ressourcenverwaltung ein großes und komplexes Thema ist.

    Bei Retain Counting muss man sich ein paar mehr Gedanken um die richtige Struktur machen (was man eigentlich immer tun müsste, allerdings kommt man mit Garbage Collection oft speicherverwaltungstechnisch mit irgend einem Murks davon). Was bleibt? Man muss Retain Cycles vermeiden, weil die nicht automatisch erkannt und weggeräumt werden.

    Dafür hat man mit Retain Counting mehr Kontrolle über den Zeitpunkt des Deallokierens, es läuft kein Hintergrundprozess, der Rechenzeit und Energie kostet und manchmal dann zuschlägt, wenn man es am wenigsten gebrauchen kann. Und: Debugging von Speicherproblemen in Garbage Collected-Umgebungen ist die Hölle, weil die Fehler nur sehr schlecht reproduzierbar sind. In 99% der Fälle tut Garbage Collection auf magische Weise genau das, was man will. Beim verbleibenden Prozent sitzt man dafür aber richtig in der Tinte. Das Prozent kommt, sobald die Systeme etwas komplexer werden - jeder, der das mal erlitten hat, kann ein Lied davon singen.

    Apple ist mit den Speicherkonventionen + ARC fast alle Qualen losgeworden: Kaum konzeptioneller Mehraufwand, keine Tipperei und keine Querelen einer aktiven Garbage Collection. Kurz: Ein guter Kompromiss.

    Weak References gibt es übrigens auch in Garbage Collected-Umgebungen wie C# und Java (ReakReference). Hat die gleiche Bedeutung, allerdings nicht den Stellenwert, weil es nicht so wichtig ist, zyklische Strukturen zu vermeiden.

    Edit: Na toll, da schreibt man mal drei Sätze und prompt haben Marco und Macmoonshine schon alles fertig diskutiert... mannomann, wie schnell tippt ihr eigentlich? ;)
    Multigrad - 360°-Produktfotografie für den Mac
  • Also ich tippe ja eher langsam. Trotz Zehn-Finger-System. Wegen Ein-Hirn-Denksystem.
    Ich hab wohl einfach nur früher mit dem Tippen angefangen. ;)
    «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
  • Mit dem Programmieren ist es ein wenig wie mit dem Motorrad fahren.

    Früher als ich 16 war habe ich eine 80er bekommen, die in den zwei Jahren die ich sie gefahren bin ca. 10x komplett auseinander genommen, repariert , getuned und wieder zusammen gesetzt habe. Ich wusste bei jeder Schraube wo sie hingehört. Das alles ist nicht wirklich nötig um Mopped fahren zu können und die meisten Jugendlichen heute kaufen sich einen schick aussehenden Roller und wenn was dran ist kommt er in die Werkstatt.

    Also ich mit 12 anfing zu programmieren, hatte der erste Rechner gerademal 8kb Speicher.(und das war schon viel): Das Betriebssystem war um ROM und ich wußte von jedem Byte in dem ROM wofür es war und was es gemacht hat. Ich musste bei jedem Speicher den ich brauchte genau aufpassen das ich ihn auch wieder freigegeben habe wenn er nicht mehr gebraucht wurde und jedes Byte dreimal umdrehen bevor ich es benutze, denn sonst war der Speicher sofort voll. Daher weiß ich auch heute noch wie so ein Computer tickt und ich kann immer noch C-Programme schreiben die mit weniger als 1MB RAM auskommen., was z.B. bei Embedded Systemen recht hilfreich ist.

    Die heutigen Programmierer lernen Java und haben eigentlich überhaupt keine Ahnung was unterhalb ihres Sourcecodes passiert und meistens nehmen sie auch als Source noch fertige Frameworks aus dem Internet so dass sie nicht mal wissen was ihr Programm eigentlich macht.

    Natürlich kann man so auch Programme erstelllen aber es hat eben eine ganz andere Qualität.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Die heutigen Programmierer lernen Java und haben eigentlich überhaupt keine Ahnung was unterhalb ihres Sourcecodes passiert und meistens nehmen sie auch als Source noch fertige Frameworks aus dem Internet so dass sie nicht mal wissen was ihr Programm eigentlich macht.

    Ich würde diesen Umstand allerdings nicht der Jugend allein zum Vorwurf machen.
    Vielleicht bin ich mit meinen 30 aber auch noch viel zu jung für das krückstockschwingende 'Früher war alles besser™' Geseier. ^^

    Damals™ wurde eine ganz andere Qualität an Anwendungen gefordert. Bei Angry Bird, Flappy Bird, Quizduell, WhatsApp und Co. zählt nur mit möglichst wenig Aufwand sich möglichst viral verteilenden Schund zu fabrizieren: Geld scheffeln.
    Dementsprechend wird auch die Ausbildung der 'Nachwuchskräfte' gestaltet: seht zu, dass ihr möglichst schnell Schleifen und Abfragen hingezimmert bekommt. Bekommt ziemlich zügig ein Gespür dafür, was der Kunde möchte. Seit abstrakt genug, um so zu entwickeln dass ihr ein und denselben Kram nur mit anderen UI-Elementen füllen müsst um ein komplett neues Programm rauszuhauen.

    Fragen stellen und sich für im Hintergrund ablaufende Prozesse interessieren soll sich heute niemand mehr.

    Es bleibt also nur zu hoffen, dass sich die Jungs und Mädels so für die Softwareentwicklung interessieren, dass sie sich selbst und in Eigenregie mit den Grundlagen auseinandersetzen.
    In Zeiten, in denen die Gesellschaft durch Ständige Erreichbarkeit und Permanente Ablenkung aktiv daran arbeitet, fokussiertes und konzentriertes Handeln nach allen Regeln der Kunst zu unterbinden, sind derartige Hoffnungen vielleicht sehr optimistisch.
    Die Hoffnung stirbt zuletzt. Am Anfang stirbt der Glaube. ;)
    «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
  • Thallius schrieb:

    Die heutigen Programmierer lernen Java und haben eigentlich überhaupt keine Ahnung was unterhalb ihres Sourcecodes passiert und meistens nehmen sie auch als Source noch fertige Frameworks aus dem Internet so dass sie nicht mal wissen was ihr Programm eigentlich macht.


    Ich find' auch nicht unbedingt, dass früher alles besser war: Ich hab' auch noch mit 6502-Assembler begonnen, dann ging's über 68K-Assembler zu C, C++, Java, Objektive-C. Und jeden Schritt habe ich als deutliche Verbesserung und Erleichterung empfunden (v.a. von Assembler zu C und von C zu den OO-Sprachen). Allerdings hilft es mir in meiner Arbeit ungemein, die Erfahrung von der Pike auf gemacht zu haben. Es gibt bestimmte Dinge, die hat man einfach verstanden, wenn man mal ganz unten etwas gemacht hat (Speicherverwaltung, Pointer, usw.).

    Ich hab' früher sehr viel Schulungen gegeben, u.a. C++, Java und OO-Design. Mit ist da aufgefallen, dass z.B. in den C++-Schulungen Java-Entwickler deutlich mehr Probleme hatten als die Leute, die mal C gemacht haben. Klar gab's da auch einige Starrköpfe, die nix mit OO anfangen konnten, und die mit C++ einfach C programmiert haben. Aber andersrum (von einer höheren Abstraktionsebene kommend) hatten es die Leute schwerer.

    Mein Fazit: Schön das es Objective-C und C++ gibt. Schön, dass ich mit Assembler beginnen musste. Noch schöner, dass ich es heute nicht mehr benötige ^^

    schönen Gruß

    gandhi
  • Marco Feltmann schrieb:

    Thallius schrieb:

    Die heutigen Programmierer lernen Java und haben eigentlich überhaupt keine Ahnung was unterhalb ihres Sourcecodes passiert und meistens nehmen sie auch als Source noch fertige Frameworks aus dem Internet so dass sie nicht mal wissen was ihr Programm eigentlich macht.

    Ich würde diesen Umstand allerdings nicht der Jugend allein zum Vorwurf machen.
    Vielleicht bin ich mit meinen 30 aber auch noch viel zu jung für das krückstockschwingende 'Früher war alles besser™' Geseier. ^^

    Damals™ wurde eine ganz andere Qualität an Anwendungen gefordert. Bei Angry Bird, Flappy Bird, Quizduell, WhatsApp und Co. zählt nur mit möglichst wenig Aufwand sich möglichst viral verteilenden Schund zu fabrizieren: Geld scheffeln.
    Dementsprechend wird auch die Ausbildung der 'Nachwuchskräfte' gestaltet: seht zu, dass ihr möglichst schnell Schleifen und Abfragen hingezimmert bekommt. Bekommt ziemlich zügig ein Gespür dafür, was der Kunde möchte. Seit abstrakt genug, um so zu entwickeln dass ihr ein und denselben Kram nur mit anderen UI-Elementen füllen müsst um ein komplett neues Programm rauszuhauen.

    Fragen stellen und sich für im Hintergrund ablaufende Prozesse interessieren soll sich heute niemand mehr.

    Es bleibt also nur zu hoffen, dass sich die Jungs und Mädels so für die Softwareentwicklung interessieren, dass sie sich selbst und in Eigenregie mit den Grundlagen auseinandersetzen.
    In Zeiten, in denen die Gesellschaft durch Ständige Erreichbarkeit und Permanente Ablenkung aktiv daran arbeitet, fokussiertes und konzentriertes Handeln nach allen Regeln der Kunst zu unterbinden, sind derartige Hoffnungen vielleicht sehr optimistisch.
    Die Hoffnung stirbt zuletzt. Am Anfang stirbt der Glaube. ;)

    Ich komme von der Webentwicklung und ich muss sagen das ganze C zeug macht viel mehr fun :).
    Aber was Marco sagt stimmt. Mein Ausbilder findet gut das ich die Grundlagen lernen will. Aber er sagt auch ich solle meinen Fokus lieber auf Titanium Studio und in Unity richten. Natürlich muss man darauf achten das man nicht jedes Rad neu erfindet, nur wenn ich noch nie ein Rad gebaut habe wie soll ich ein neues Rad erfinden was vielleicht besser ist und ich könnte nicht so gut Räder reparieren ^^