Suchergebnisse
Suchergebnisse 41-60 von insgesamt 105.
-
Zitat: „Original von Tom9811 Sagt mal, merkst du überhaupt noch etwas?“ Ich bemerke den Stil: tu genau dies, tu genau das, frage aber nicht warum, lese erst noch ein paar hundert weitere Seiten, ab Seite 1000 wirst du dann verstehen ... Übrigens - die Seite 1000 existiert hier nicht. Und ich möchte tatsächlich etwas verstehen lernen, nicht aber dressiert werden. Und dieses zu versuchen, überfordert meine Person nicht. Und natürlich verwendet man -dealloc, und zwar dort, wo es Sinn macht, und dan…
-
Zitat: „Original von Tom9811 Polemisch bist doch du. Liest den Kochan, bist intellektuell nicht in der Lage, das Zitat zu verstehen und stellst die Frage, ob ich da didaktische Lücken habe. Das ist wirklich eine Art der Verblendung und Selbstüberschätzung, die man allerseltenst trifft.“ Also bevor jetzt hier ein Atomkrieg ausbricht: wie könnte man denn diese Fragestellung in ein verifizerbares Beispiel umformen?
-
Zitat: „Original von Tom9811 Die Apple-Doku schreibt nichts von vollständig initialisiert oder nicht. Du verstehst einfachste Dinge nicht, liest Zitate nicht richtig und bist jetzt auch noch schlauer als Apple. Das ist mal geil!“ Na ja, Polemik statt Fakten! Ich zweifle, dass sich das gesamte Wissen von Apple in diesen Zeilen kondensiert hat. Da wird es sicher noch einige potente Köpfe geben ...
-
Zitat: „Original von Michael Vielleicht überzeugt Dich Apples Dokumentation zu dealloc: Zitat: „You never send a dealloc message directly. Instead, an object’s dealloc method is invoked indirectly through the release NSObject protocol method (if the release message results in the receiver's retain count becoming 0). See Memory Management Programming Guide for Cocoa for more details on the use of these methods.“ Das erklärt auch Dein Zitat aus "Programming in Objective-C" genauer.“ Nun, für volls…
-
Zitat: „Original von Tom9811 Nein, es ist kontraproduktiv, Grundkonzepte nicht zu verstehen und dann einen Versuch zu starten, über weiterführende Probleme zu diskutieren. Der Rat, dies nicht zu tun, ist produktiv. “ Gerade weil ab der Seiten 320 zum Thema init grundlegende Codierungsmuster präsentiert werden, sollten diese verstanden sein. Da dies (zumindest mir) nicht auf Anhieb gelingen will, stellt sich eben die Frage, woran das liegt. Ich könnte es mir leicht machen, das teure Buch als evtl…
-
Zitat: „Original von Tom9811 Aber auch hier gilt: Du hast die Grundkonzepte der Speicherverwaltung nicht verstanden und kümmerst dich um Spezialeffekte. Das ist nicht sinnvoll.“ Also, diese gebetsmühlenartige Wiederholung dieses Vorwurfs an jemanden, der sich gerade um das Verstehen bemüht, halte ich für sehr kontraproduktiv - mehr sage ich nicht dazu. Im übrigen kann man bei S.G.Kochan in "Programming in Objective-C" auf Seite 343 nachlesen: ".... The dealloc method is called whenever the memor…
-
Zitat: „Original von Tom9811 Mit -release (ggfl. + speziellem Code). Das hatte ich aber schon geschrieben. Ganz gewiss nicht mit -dealloc.“ Nun, ich dachte ein [super dealloc] würde dann die zuvor ja korrekt initialisierten Superklassen abbauen. Aber ein wie auch immer geartetes release auf die Instanz würde doch ein dealloc der tiefsten, zumindestens teilweise noch uninitialisierten Subklasse auslösen, oder sehe ich das falsch?
-
Zitat: „Original von Tom9811 Wenn du nur an den Aufruf von -dealloc denkst, solltest du dringend 100 Seiten zurückschlagen. Abgesehen davon, dass es grundsätzlich falsch ist, ist es hier doppelt falsch, weil du an eine nicht-initialisierte Instanz -dealloc schickst. Wenn schon falsch, dann [super dealloc], was immerhin nur einfach falsch ist.“ Wie dann sollte denn eine Selbstzerstörung konsistent sichergestellt werden?
-
Zitat: „Original von Tom9811 Zitat: „b) oder es scheitert im init, dann müsste konsequenter Weise ja auch noch ein dealloc der Superklasse vorgenommen werden, damit das Speicherloch, welches ohnehin entsteht, da keine Adresse mehr auf das unvollständig initialisierte Objekt verweisen wird, nicht noch größer wird, falls zuvor bereits auf weitere Objekte verwiesen worden ist. Immerhin kann die Superklasse ja nicht autonom aktiv werden, wenn ein init der Subklasse gescheitert ist. “ Bitte lies noch…
-
Zitat: „Original von hns Zitat: „Original von Scharnagl Nun habe ich auf der Mitte der gleichen Seite noch eine Verständnisfrage, es geht um die Abfrage: if (self != nil) ... deren Intention ist es wohl zu verhindern, dass Instanzen nur zum Teil initialisiert werden. Allein, was will man dann ggf. mit solchen uninitialisierten Instanzen? Wäre es nicht sinnvoller, Objective-C würde in solchen Fällen eine Exception auslösen? Vielleicht kann man mir in Bezug auf die Sinnhaftigkeit dieser Fallunters…
-
Nun habe ich auf der Mitte der gleichen Seite noch eine Verständnisfrage, es geht um die Abfrage: if (self != nil) ... deren Intention ist es wohl zu verhindern, dass Instanzen nur zum Teil initialisiert werden. Allein, was will man dann ggf. mit solchen uninitialisierten Instanzen? Wäre es nicht sinnvoller, Objective-C würde in solchen Fällen eine Exception auslösen? Vielleicht kann man mir in Bezug auf die Sinnhaftigkeit dieser Fallunterscheidung ein wenig auf die Sprünge helfen?
-
Zitat: „Original von Tom9811 b) ? Ah, ist gar nicht von mir! Aber das kann eine statische Variable leisten, weil sie Programmglobal ist. Das Static ist für alle Instanzen ein- und dasselbe Static. (Sonst wäre es ja einfach eine Instanzvariable.) Ich würde den Trick aber auch nicht anwenden. Man muss sich das klarmachen. Na ja, er kostet auch nichts. Kann man machen.“ Darum denke ich ja auch, dass sich der gewünschte Effekt nur mit einer Instanzvariablen erreichen ließe, z.B. in dem man prüft, ob…
-
Auf Seite 321 unten wird wiederholt darauf eingegangen, dass es sinnvoll sein kann, eine doppelte Initialisierung einer Klasse zu verhindern. Das sehe ich natürlich ein, dennoch stellen sich mir hierzu folgende Fragen: a) ist eine mehrfache Initialisierung einer Instanz nicht zwingend die Folge eines fehlerhaft angeforderten init's an anderer Stelle? b) wie kann eine einzige statische Variable sinnvoll für diverse Instanzen (keine Singletons) arbeiten?
-
Zitat: „Original von Tom9811 ... Was das allerdings mit der Code-Vervollständigung zu tun hat, verstehe ich nicht. Bitte um Erklärung des vermuteten Zusammenhanges.“ Bislang dachte ich, dass die hierzu notwendigen Informationen aus den Header-Dateien käme, insbesondere auch, wenn die Klasse selber bereits in linkbarer Form vorliegt. Oder gibt es eine Art von Reflection, eine Selbstauskunft einer kompilierten Klasse über ihre gesamten Methoden (eben auch unveröffentlichte)?
-
Zitat: „Original von wolf_10de Natürlich ist das nicht ganz das was man von C++ kennt, aber immerhin eine Möglichkeit, die Klasse in private und public zu "unterteilen" auch wenn's nach aussen hin nix bringt, ich weiß. Ich mache das manchmal trotzdem so, der Übersicht halber.“ Vermutlich werde ich das ebenso machen. Ich sehe sonst Probleme, wenn eine abgeleitete Klasse nur die veröffentlichten Methoden sehen kann beim Import der *.h Datei der Basisklasse. Deswegen sprach ich ja auch entsprechend…
-
Inzwischen bin ich ein wenig weiter gekommen. Hier stockte ich auf Seite 100 über folgenden Satz: "Allerdings schreiben wir hier nicht alle Methoden hin, sondern nur diejenigen, von denen wir wollen, dass sie auch von außen benutzt werden dürfen". Bezieht sich dies nur auf die informationelle Sichtbarkeit, oder hat das auch Auswirkungen auf die tatsächliche Aufrufbarkeit von Methoden? Gibt es nicht auch die Möglichkeit, Methoden explizit als private etc. zu deklarieren? Und welche Auswirkungen h…
-
Zitat: „Original von Tom9811 Aber natürlich sind der Satz an Outlets und Actions (Methoden generell) über alle Instanzen einer Klasse konstant. Daher ist das in der Implementierung auch auf Klassenebene optimiert. Das ändert aber nichts daran, dass es eine Frage der Instanz ist und dies ganz sicher bei Outlets, deren aktuellen Werte sich ja nicht einmal konstant verhalten. Natürlich kann das Outllet A der Instanz A auf etwas anderes zeigen als das Outlet A der Instanz B. …“ Danke für diese verfe…