Problem mit allocate, init und free

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

  • Original von Amin Negm-Awad
    Original von Lucas de Vil
    Original von Amin Negm-Awad
    EIN TUTORIAL ZU OBJECTIVE-C, XCODE UND COCOA
    Ich weiß auch nicht, wieso es besonders dienlich ist, erst einmal alle Namenskonventionen abzulehnen.

    [title stringToUpper];
    Das ist kein Fehler, sondern ein stilistisches Mittel!

    Nein, sondern das Programm.

    Nein, ein stilistisches Mittel.
    Stünde dort 'Ein Tutorial zu OBJECTIVE-C, XCODE und COCOA' könnte ich die Kritik nachvollziehen. Steht da nicht.
    Beachte die oberste Zeile:
    Objective-C, Xcode und Cocoa Tutorial

    Er weiß wie es heißt und geschrieben wird. Außer bei den Überschriften ist es überall richtig.
    Bei 'capitalized letter' ist dieses Wissen hinfällig.
    Es ist ein stilistisches Mittel.
    In den zufällig überflogenen Codeschnippseln passen die Namenskonventionen auch.

    Original von Amin Negm-Awad
    Nein, ich meine nicht sprachliche Ungenauigkeiten. Objekt wird bei ihm ausnahmslos für Instanz verwendet.

    So, wird es das? Ich lese permanent den abstrakten Vergleich mit Dingen aus der nondigitalen Welt heraus. Nach der schwammigen und allgemein gültigen Definition ist auch ein Bauplan ein Objekt, also auch eine Klasse. Schließlich ist ein Bauplan ein Ding und man kann was damit machen. Ihn korrigieren, ihn verwerfen, die auf ihm enthaltene Information nutzen um ein Ding zu bauen.

    Er könnte auf ein Klassenobjekt eingehen, aber wozu? An dem ersten Punkt zum Objekt gibt es noch keine Klasse, die kommt erst später. Davon abgesehen sind Klassen kein grundlegendes Merkmal der objektorientierten Programmierung.

    Original von Amin Negm-Awad
    Der gesagte Text dazu ist inhaltlich fast 1:1 geklaut und dabei aus Unkenntnis verfälscht worden. Missverständnis ist außerordentlich höflich ausgedrückt.

    Für diese haltlose Behauptung hast du auch sicherlich Beweise oder wenigstens Indizien, die du uns zukommen lässt.

    Original von Amin Negm-Awad
    Und es ist für die Beurteilung gleichgültig, ob es etwas kostet.

    Nicht, wenn du Anfängern einen Blick in die Materie werfen lassen willst.
    Bedenke, dass Fachbücher nur dann gekauft werden, wenn sich Mensch für diese Fachrichtung interessiert.
    Nie werde ich mir ein Fachbuch 'Elektrotechnik' zulegen, wenn ich nen kleinen 1 Watt Verstärker basteln will.
    Kostenlose Tutorials sorgen dafür, dass man mit minimalem Grundverständnis maximalen Erfolg erntet. Wenn es dann Spaß macht, kann man sich ja mit den Feinheiten auseinandersetzen.

    Original von Amin Negm-Awad
    Genau und Zuweisung hat etwas mit OOP zu tun, weil ich IDs zuweisen kann. return hat etwas mit OOP zu tun, weil ich IDs zurückgeben kann …

    Ja. Es sei denn, du nennst mir eine objektorientierte Programmiersprache, die ohne Zuweisungen oder ohne Rückgabe auskommt. Sicherlich gehört sowas mehr zur P als zur OO. Das ändert aber nix daran, dass es zur OOP gehört.

    Original von Amin Negm-Awad
    Original von Lucas de Vil
    Dass man existente Objekte komplett verändern kann ohne eine neue Klasse anlegen zu müssen auch.
    Auf Grund der Tatsache, dass man auch zur Laufzeit den Objektbauplan (a.k.a. 'die Klasse') ändern kann fällt die Klasse definitiv in den Bereich von OOP.

    Es gibt Sprachen, die ohne Nachrichten auskommen, aber Klassen kennen. Kay nannte die nicht OOP. Wieso eigentlich?

    Arbeiten diese Sprachen mit Objekten?
    Noch mal: Klassen sind kein grundlegendes Merkmal der OOP, sie haben dennoch in vielen Fällen mit OOP zu tun. In diesem speziellen Beispiel mit dem Fall Objective-C.
    Was nützt dir beim Lernen von Objective-C das Wissen, dass andere Sprachen es anders machen?
    Nichts.

    Original von Amin Negm-Awad
    Jo, so wie das "+", weil ich das in einer Methode verwenden kann, nicht wahr?

    Jo, auch Operatoren sind Teil der objektorientierten Programmierung, weil sie Teil der Programmierung sind.
    Ohne Programmierung gibt es keine OOP.

    Original von Amin Negm-Awad
    Nein, nicht einer. Zum einen hast du mein "schlicht falsch" vorhin noch mit einem "Da gebe ich dir Recht" quittiert.

    Genau das war der eine Fehler.

    Original von Amin Negm-Awad
    Im Abschnitt "Categories, Posing und Prtocols" taucht der Begriff Posing 0 mal auf, ebenso Protocol. Aber gut, dass ist nur "Mehr darstellen, als ich kann."

    Das ist schlicht falsch.
    Der Artikel geht noch weiter.
    Posing
    Sie können dem Objective-C Compiler "überlisten", indem Sie ihm eine Klasse "vortäuschen" die gar keine ist. Dieser Vorgang wird posing genannt und wird von der poseAs: Methode unterstützt (Bei NSObject (anstatt Object!?) als root Klasse heisst die Methode poseAsClass:...

    Und weiters:
    Ein protocol ist eine Liste von Methoden, die sich verschiedene Klassen teilen. Die Methoden, die in einem protocol gelistet werden, haben keine korrespondierenden Implementationen: sie sind dazu gedacht, dass sie von jemand anders implementiert werden (das sind dann Sie als Programmierer!)...

    Auch hier eher allgemein gehalten und mit Fachidiotenwissen lassen sich da Ungereimtheiten feststellen.
    Die Behauptung, es stünde nicht dort, ist jedoch haltlos.
    Deine Recherchen waren schon mal besser, Amin.

    Original von Amin Negm-Awad
    Das in einen Abschnitt zu stopfen, zeugt von tiefem Unverständnis. Die Technologien haben so viel miteinander zu tun wie OOP und "+".

    Haben sie das? Nicht, wenn man als 'gemeinsamen Nenner' definiert, dass man damit 'den Compiler überlisten kann'.

    Original von Amin Negm-Awad
    Ich schlag jetzt mal zufällig ne Seite auf
    *Fahrstuhlmusik*

    +gähn+

    Original von Amin Negm-Awad
    for, do und while sind keine Befehle. In der Aufzählung fehlt for-in. (Offenkundig war er noch nicht so weit beim Abschreiben.)

    Wie würdest du Dinger denn sonst allgemein umschreiben, dass Nicht-Nerds sie dennoch verstehen?
    For...in ist Objective-C2, der normale Objective-C Compiler kann damit soweit ich weiß nicht um. Ergo gehört es da meiner Meinung auch nicht mit rein.

    Original von Amin Negm-Awad
    Nein, weil er nämlich grundsätzlich verstanden hat, wie die Sprache funktioniert.

    Klar, und der komische Ösi da nicht. Nur weil er Objective-C und Cocoa bei den theoretischen Grundlagen zu trennen versucht. Ich versteh schon.
    :rolleyes:
    «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
  • Lucas de Vil schrieb:

    Original von Amin Negm-Awad
    Original von Lucas de Vil
    Original von Amin Negm-Awad
    EIN TUTORIAL ZU OBJECTIVE-C, XCODE UND COCOA
    Ich weiß auch nicht, wieso es besonders dienlich ist, erst einmal alle Namenskonventionen abzulehnen.

    [title stringToUpper];
    Das ist kein Fehler, sondern ein stilistisches Mittel!

    Nein, sondern das Programm.

    Nein, ein stilistisches Mittel.
    Stünde dort 'Ein Tutorial zu OBJECTIVE-C, XCODE und COCOA' könnte ich die Kritik nachvollziehen. Steht da nicht.
    Beachte die oberste Zeile:
    Objective-C, Xcode und Cocoa Tutorial

    Er weiß wie es heißt und geschrieben wird. Außer bei den Überschriften ist es überall richtig.
    Bei 'capitalized letter' ist dieses Wissen hinfällig.
    Es ist ein stilistisches Mittel.
    In den zufällig überflogenen Codeschnippseln passen die Namenskonventionen auch.

    Ich spreche nicht von der Groß-Kleinschreibung. Ich spreche davon, dass wenn er ein Tutorial so nennt, er sich an die Regeln halten muss. Das macht er nicht, etwa verletzt er die KVC-Regeln ohne Not, einfach so aus Jux.

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Nein, ich meine nicht sprachliche Ungenauigkeiten. Objekt wird bei ihm ausnahmslos für Instanz verwendet.

    So, wird es das? Ich lese permanent den abstrakten Vergleich mit Dingen aus der nondigitalen Welt heraus.

    Eben, und die Dinge der non-digitalen Welt sind existente Dinge.

    Lucas de Vil schrieb:


    Nach der schwammigen und allgemein gültigen Definition ist auch ein Bauplan ein Objekt, also auch eine Klasse. Schließlich ist ein Bauplan ein Ding und man kann was damit machen. Ihn korrigieren, ihn verwerfen, die auf ihm enthaltene Information nutzen um ein Ding zu bauen.

    Komisch aber, dass er das immer nur auf das eine oder andere Handy bezieht.

    Lucas de Vil schrieb:

    Er könnte auf ein Klassenobjekt eingehen, aber wozu? An dem ersten Punkt zum Objekt gibt es noch keine Klasse, die kommt erst später. Davon abgesehen sind Klassen kein grundlegendes Merkmal der objektorientierten Programmierung.

    Ach, hat sich jetzt doch die Erkenntnis durchgesetzt?

    Aber Klassen empfangen Nachrichten. Dann müssen sie wohl Objekte sein. Ist ja nicht so ganz unwichtig, wenn man bedenkt, dass man auch mal Instanzen erzeugen will.

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Der gesagte Text dazu ist inhaltlich fast 1:1 geklaut und dabei aus Unkenntnis verfälscht worden. Missverständnis ist außerordentlich höflich ausgedrückt.

    Für diese haltlose Behauptung hast du auch sicherlich Beweise oder wenigstens Indizien, die du uns zukommen lässt.

    Ich dachte, sie sei haltlos:

    Nun gut:
    "Sie ist das » ▹Das Ding an un vöör sich «."
    "Ihr Handy ist ja nicht „das Handy an sich“ sondern ein sehr spezielles, reales Handy:"

    Beispiel der Klassen und Instanzen anhand von Button und Textfeld.

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Und es ist für die Beurteilung gleichgültig, ob es etwas kostet.

    Nicht, wenn du Anfängern einen Blick in die Materie werfen lassen willst.

    Etwas Falsches wird nicht richtig, weil es kostenlos ist.
    Etwas Falsches wird auch nicht richtig, wenn es für einen Anfänger ist.

    Schlimmer: Er verinfacht nicht einfach, wo es Erläuterung, Verständnis bringt. Die Gleichsetzung von Attribut und Eigenschaft bringt gar nichts, sondenr ist einfach falsch. Auch kostenlos falsch.

    Lucas de Vil schrieb:


    Bedenke, dass Fachbücher nur dann gekauft werden, wenn sich Mensch für diese Fachrichtung interessiert.
    Nie werde ich mir ein Fachbuch 'Elektrotechnik' zulegen, wenn ich nen kleinen 1 Watt Verstärker basteln will.
    Kostenlose Tutorials sorgen dafür, dass man mit minimalem Grundverständnis maximalen Erfolg erntet. Wenn es dann Spaß macht, kann man sich ja mit den Feinheiten auseinandersetzen.

    Es macht Spaß, wenn man etwas Falsches lernt?

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Genau und Zuweisung hat etwas mit OOP zu tun, weil ich IDs zuweisen kann. return hat etwas mit OOP zu tun, weil ich IDs zurückgeben kann …

    Ja. Es sei denn, du nennst mir eine objektorientierte Programmiersprache, die ohne Zuweisungen oder ohne Rückgabe auskommt. Sicherlich gehört sowas mehr zur P als zur OO. Das ändert aber nix daran, dass es zur OOP gehört.

    Nein, es gehört nicht zur OOP.

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Original von Lucas de Vil
    Dass man existente Objekte komplett verändern kann ohne eine neue Klasse anlegen zu müssen auch.
    Auf Grund der Tatsache, dass man auch zur Laufzeit den Objektbauplan (a.k.a. 'die Klasse') ändern kann fällt die Klasse definitiv in den Bereich von OOP.

    Es gibt Sprachen, die ohne Nachrichten auskommen, aber Klassen kennen. Kay nannte die nicht OOP. Wieso eigentlich?

    Arbeiten diese Sprachen mit Objekten?

    Selbstverständlich.

    Lucas de Vil schrieb:


    Noch mal: Klassen sind kein grundlegendes Merkmal der OOP, sie haben dennoch in vielen Fällen mit OOP zu tun. In diesem speziellen Beispiel mit dem Fall Objective-C.
    Was nützt dir beim Lernen von Objective-C das Wissen, dass andere Sprachen es anders machen?
    Nichts.

    Richtig, weshalb es angebracht ist zu sagen, dass es Objective-C so macht, nicht OOP.

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Jo, so wie das "+", weil ich das in einer Methode verwenden kann, nicht wahr?

    Jo, auch Operatoren sind Teil der objektorientierten Programmierung, weil sie Teil der Programmierung sind.
    Ohne Programmierung gibt es keine OOP.

    Dann ist ja offenkundig alles OOP.

    Ohne DNA gäbe es sicherlich auch keine OOP. Wer hätte das erfinden sollen? Sicherlich spielt auch Zinkoxid eine bedeutende Rolle.
    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"?
  • Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Nein, nicht einer. Zum einen hast du mein "schlicht falsch" vorhin noch mit einem "Da gebe ich dir Recht" quittiert.

    Genau das war der eine Fehler.

    Ach, echt? Dann war wohl das "Da gebe ich dir allerdings Recht" der andere eine Fehler? Wie viele eine Fehler gibt es denn?

    Aber wir müssen da echt nicht geizen:
    "Der Datentyp kann zur Laufzeit beliebig oft verändert werden."
    Da verwechselt wohl jemand dynamische und schwache Typisierung. Ich kann jedenfalls nicht so einfach den Datentyp ändern.

    Schön ist auch die Grafik hier: infobliss.at/objc/obc116.htm

    Kannst du mir mal erklären, wie die Instanz zusätzliche Methoden bekommt?

    Oder das hier: "Das Erzeugen von neuen Instanzen ist eine Eigenschaft, die nur Klassen können."

    Das ist ja gleich doppelt Murks: Es ist keine Eigenschaft (was ja auch ein Attribut ist) und natürlich können das auch Instanzen.

    Ich nehme an, dass ist jetzt der ganz andere eine Fehler und dann noch der völlig andere eine Fehler, dann der eine Fehler V und der eine Fehler VI.

    Soll ich weiter machen?

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Im Abschnitt "Categories, Posing und Prtocols" taucht der Begriff Posing 0 mal auf, ebenso Protocol. Aber gut, dass ist nur "Mehr darstellen, als ich kann."

    Das ist schlicht falsch.
    Der Artikel geht noch weiter.

    Stimmt, das "weiter" auf der linken Seite habe ich dem Kapitel zugeordnet.

    Lucas de Vil schrieb:


    Posing
    Sie können dem Objective-C Compiler "überlisten", indem Sie ihm eine Klasse "vortäuschen" die gar keine ist. Dieser Vorgang wird posing genannt und wird von der poseAs: Methode unterstützt (Bei NSObject (anstatt Object!?) als root Klasse heisst die Methode poseAsClass:...

    Und weiters:
    Ein protocol ist eine Liste von Methoden, die sich verschiedene Klassen teilen. Die Methoden, die in einem protocol gelistet werden, haben keine korrespondierenden Implementationen: sie sind dazu gedacht, dass sie von jemand anders implementiert werden (das sind dann Sie als Programmierer!)...

    Auch hier eher allgemein gehalten und mit Fachidiotenwissen lassen sich da Ungereimtheiten feststellen.
    Die Behauptung, es stünde nicht dort, ist jedoch haltlos.
    Deine Recherchen waren schon mal besser, Amin.

    Original von Amin Negm-Awad
    Das in einen Abschnitt zu stopfen, zeugt von tiefem Unverständnis. Die Technologien haben so viel miteinander zu tun wie OOP und "+".

    Haben sie das? Nicht, wenn man als 'gemeinsamen Nenner' definiert, dass man damit 'den Compiler überlisten kann'.

    Also, Kategorien überlisten niemanden. Protokolle überlisten auch niemanden.

    Posing ist seit 10.5 deprecated. Es war schon immer eher für Debugging gedacht denn für Produktivcode. Wieso soll ein Anfänger eigentlich etwas lernen, was man allenfalls in Spezialfällen benötigte und inzwischen überholt ist? Damit er verwirrt ist?

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Ich schlag jetzt mal zufällig ne Seite auf
    *Fahrstuhlmusik*

    +gähn+

    Original von Amin Negm-Awad
    for, do und while sind keine Befehle. In der Aufzählung fehlt for-in. (Offenkundig war er noch nicht so weit beim Abschreiben.)

    Wiederholungen?

    Lucas de Vil schrieb:


    Wie würdest du Dinger denn sonst allgemein umschreiben, dass Nicht-Nerds sie dennoch verstehen?
    For...in ist Objective-C2, der normale Objective-C Compiler kann damit soweit ich weiß nicht um. Ergo gehört es da meiner Meinung auch nicht mit rein.

    Genau! Es gehören zwar Erläuterungen zu höchst speziellen und veralteten Technologien herein, die man nicht verwenden sollte, aber auf keinen Fall Erläuterungen zu aktuelen Technologien, deren Verwendung dringend angeraten wird. Übrigens auch zur Fehlervermeidung.

    Lucas de Vil schrieb:


    Original von Amin Negm-Awad
    Nein, weil er nämlich grundsätzlich verstanden hat, wie die Sprache funktioniert.

    Klar, und der komische Ösi da nicht.

    Ja, seine Ausführungen zu Objekten und Typisierung belegen das.

    Lucas de Vil schrieb:


    Nur weil er Objective-C und Cocoa bei den theoretischen Grundlagen zu trennen versucht. Ich versteh schon.

    Die Fehler haben nicht mit Trennung zu tun:
    Dynamische Typisierung ist keine Frage der Trennung.
    Klassenobjekte sind keine Frage der Trennung.
    Bei Posing und Kategorien trennt er nicht, sondern vermischt völlig wesensfremde Dinge. Dass Kategorien ein Sprachmittel sind, Posing+ein Mittel von Cocoa, mus ich dann wohl auch noch erwähnen.

    Sagen wir es also so: Er vermischt und macht dabei Fehler.

    Er hat auch weder de Typisierung noch den Objektbegrif verstanden. Es gibt ja noch viel mehr:
    "Die gemeinsame Struktur und Methoden von Objekten wird Klasse genannt (der Oberbegriff, der Bauplan),"
    Die gemeinsame Struktur von Methoden?
    "Abkömmlinge dieser Klassen werden Instanzen genannt. "
    Mit Abkömmlingen von Klassen bezeichnet man nun etwas ganz anderes.
    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"?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Amin Negm-Awad ()