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

  • Problem mit allocate, init und free

    Hallo,
    ich bin neu bei cocoa und bin dabei folgendes tutorial zu machen:
    infobliss.at/objc/obc123.htm
    . Das problem ist nun, dass ich den code exakt wie im tut habe, jedoch trotzem immer fehlermeldungen bekomme. Hier mal der code:

    Brainfuck-Quellcode

    1. #import <stdio.h>
    2. #import <objc/Object.h>
    3. // ------- @interface Abschnitt ----------
    4. @interface Bruch: Object
    5. {
    6. int zaehler;
    7. int nenner;
    8. }
    9. - (void) ausdrucken;
    10. - (void) setzeZaehler: (int) z;
    11. - (void) setzeNenner: (int) n;
    12. @end
    13. // ---------------- @implementation Abschnitt ----------------
    14. @implementation Bruch;
    15. -(void) ausdrucken
    16. {
    17. printf (" %i/%i ", zaehler, nenner);
    18. }
    19. -(void) setzeZaehler: (int) z
    20. {
    21. zaehler = z;
    22. }
    23. -(void) setzeNenner: (int) n
    24. {
    25. nenner = n;
    26. }
    27. @end
    28. // ----Programm Abschnitt------
    29. int main (int argc, char *argv[])
    30. {
    31. Bruch *meinBruch;
    32. // Bildung einer Instanz
    33. meinBruch = [Bruch alloc];
    34. meinBruch = [meinBruch init];
    35. // Setzen von Zähler und Nenner
    36. [meinBruch setzeZaehler: 1];
    37. [meinBruch setzeNenner: 2];
    38. // Anzeigen des Bruchs via printf
    39. printf ("Der Wert von meinBruch ist:");
    40. [meinBruch ausdrucken];
    41. printf ("\n");
    42. [meinBruch free];
    43. return 0;
    44. }
    Alles anzeigen

    In den zeilen 49, 50, 61erhalte ich die fehlermeldungen
    "'Bruch' may not respond to '+alloc' (Messages without a matching method signature assumed to return 'id' and accept '...' as arguments)"

    und
    "'Bruch' may not respond to '-init'"

    und
    "Bruch may not respond to free"

    Hat da jemand eine idee, woran das liegen könnte? KOmmt das evtl daher, dass das tutorial von xcode 2.4 stammt???

    Vielen Dank im voraus!!
    Stefan
    mac book pro mac os x 10.6
    xcode 3.2
  • Ich habe nun aus dem Bruch: Object ein Bruch: NSObject gemacht. Die ersten beiden warnungen sind nun weg, die warnung in zeile 61 bleibt jedoch.
    Wenn ich auf build and run klicke, erscheint in der console zwar "der wert von meinbruch ist 1/2", jedoch kommen dann viele kryptische fehlermeldungen und am ende:
    "terminate called after throwing an instance of 'NSException'
    Program received signal: “SIGABRT”."

    hängt das mit der warnung in zeile 61 zusammen?

    Die ganze console ließt sich:

    Quellcode

    1. "Loading program into debugger…
    2. Program loaded.
    3. run
    4. [Switching to process 1855]
    5. Running…
    6. Der Wert von meinBruch ist: 1/2
    7. 2010-04-09 17:36:12.518 tut13b[1855:a0f] *** __NSAutoreleaseNoPool(): Object 0x100110ee0 of class NSCFString autoreleased with no pool in place - just leaking
    8. 2010-04-09 17:36:12.521 tut13b[1855:a0f] -[Bruch free]: unrecognized selector sent to instance 0x10010a400
    9. 2010-04-09 17:36:12.522 tut13b[1855:a0f] *** __NSAutoreleaseNoPool(): Object 0x100104fc0 of class NSCFString autoreleased with no pool in place - just leaking
    10. 2010-04-09 17:36:12.522 tut13b[1855:a0f] *** __NSAutoreleaseNoPool(): Object 0x100110ff0 of class NSException autoreleased with no pool in place - just leaking
    11. 2010-04-09 17:36:12.523 tut13b[1855:a0f] *** __NSAutoreleaseNoPool(): Object 0x100115950 of class _NSCallStackArray autoreleased with no pool in place - just leaking
    12. 2010-04-09 17:36:12.524 tut13b[1855:a0f] *** __NSAutoreleaseNoPool(): Object 0x1001159b0 of class _NSCallStackArray autoreleased with no pool in place - just leaking
    13. 2010-04-09 17:36:12.525 tut13b[1855:a0f] *** __NSAutoreleaseNoPool(): Object 0x100115c30 of class NSCFString autoreleased with no pool in place - just leaking
    14. 2010-04-09 17:36:12.526 tut13b[1855:a0f] *** __NSAutoreleaseNoPool(): Object 0x100116660 of class NSCFString autoreleased with no pool in place - just leaking
    15. 2010-04-09 17:36:12.526 tut13b[1855:a0f] *** __NSAutoreleaseNoPool(): Object 0x100115ab0 of class NSConcreteMutableData autoreleased with no pool in place - just leaking
    16. 2010-04-09 17:36:12.527 tut13b[1855:a0f] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[Bruch free]: unrecognized selector sent to instance 0x10010a400'
    17. *** Call stack at first throw:
    18. (
    19. 0 CoreFoundation 0x00007fff8321dd24 __exceptionPreprocess + 180
    20. 1 libobjc.A.dylib 0x00007fff885fc0f3 objc_exception_throw + 45
    21. 2 CoreFoundation 0x00007fff83277160 +[NSObject(NSObject) doesNotRecognizeSelector:] + 0
    22. 3 CoreFoundation 0x00007fff831efd3f ___forwarding___ + 751
    23. 4 CoreFoundation 0x00007fff831ebe88 _CF_forwarding_prep_0 + 232
    24. 5 tut13b 0x0000000100001761 main + 180
    25. 6 tut13b 0x00000001000015f0 start + 52
    26. 7 ??? 0x0000000000000001 0x0 + 1
    27. )
    28. terminate called after throwing an instance of 'NSException'
    29. Program received signal: “SIGABRT”.
    30. sharedlibrary apply-load-rules all
    Alles anzeigen


    danke schonmal für die antwort!
    mac book pro mac os x 10.6
    xcode 3.2
  • Original von nepleurepas
    jap, das wars, dankeschön. Dann haben sich wohl nicht unwesentliche dinge geändert von xcode 2.4 zu der heutigen version...
    nein, da hat sich nichts geändert... Das Tutorial war anscheinend schon immer falsch ;)

    => wer glaubt noch was im Internet steht?
  • Original von nepleurepas
    mist, hat echt einen soliden eindruck gemacht, und war alles sehr ausführlicg erklärt! naja kann man nix machen

    Wahrscheinlich ist es aber nur ein sogar nachvollziehbarer Flüchtigkeitsfehler. Z.B. wenn der Tutorial-Schreiber in einem 40-Stundenjob mit der libc und malloc/free zu tun hatte. Und abends das Tutorial geschrieben. Vielleicht sollte man ihm einfach ein Feedback geben, dann stolpert wenigstens kein anderer mehr drüber.

    Wenn das Tutorial sonst gut lesbar ist dann spricht ja nichts dagegen es durchzuarbeiten. Nur darf man sich dann nicht 100%ig drauf verlassen. Dafür gibts dann hier das schöne Forum wo man sowas diskutieren kann...
  • Nicht zwingend.
    Ich kenn das Tutorial nicht, aber wenn der wirklich und wahrhaftig von Object ableitet (wovon ich ausgehe), dann ist -free komplett richtig.
    In dem Fall ist das Tutorial ein reines Objective-C Tutorial ohne irgend ein Framework hintendran.

    Man beachte den Header fünf Seiten davor:

    Quellcode

    1. #import <stdio.h>
    2. #import <objc/Object.h>


    Der Fehler liegt einfach daran, dass du dem Compileraufruf kein -lobjc mitgegeben hast.
    Das kannst du aber gar nicht wissen. ;)

    Nimm mal nur den ursprünglichen Code, öffne n Terminal, wechsel in das entsprechende Verzeichnis und gib ein:
    gcc -Wall -O0 -lobjc main.m

    Dann sollte das ohne Probleme klappen.
    «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
  • Original von hns
    Original von Amin Negm-Awad
    Du hast zwar Recht, bei dem genannten Tutorial habe ich mich aber schon immer gefragt, ob es besonders freakig oder besonders fehlerhaft ist.
    Wohl beides, also freakerhaft...

    Ich kann diese Kritik nicht nachvollziehen.
    Es ist ein Objective-C Tutorial. Der besagte Teil des Tutorials soll das Erstellen einer eigenen Klasse demonstrieren.

    Man kann sich darüber streiten, wieso die Stolperfallen wie -lobjc nicht aufgezeigt werden.
    Das kann man aber auch bei kressevaders Objective-C Tutorial mit dem eigenen 'Lebenszyklus', also der Speicherverwaltung zu Fuß.

    Ich persönlich sehe es weder als freakig noch fehlerhaft an, sondern als grundlegend.
    Weiterhin bin ich der Meinung solche Tutorials sind hervorragend für das Verständnis von Objective-C, nehmen sie doch ein wenig des vermeintlichen Voodoos aus dem Cocoa- oder GNUStep-Framework.

    Hab da übrigens mal ein wenig weitergeblättert.
    Erst vier Seiten später wird wirklich mit Xcode gearbeitet.
    infobliss.at/objc/obc127.htm
    Ich kann dem Autor nur vorwerfen, dass nach dem Code nirgendwo steht, wie ich diesen zu compilieren habe um ihn ausprobieren zu können. Sonst ist alles prima.

    hns: Freakerhaft ist ja wohl eher das Basteln eigener komplexer Frameworks quasi von 0 auf an. ;)
    «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
  • EIN TUTORIAL ZU OBJECTIVE-C, XCODE UND COCOA

    Ich weiß auch nicht, wieso es besonders dienlich ist, erst einmal alle Namenskonventionen abzulehnen.

    Die Ausführungen zu Objekten sind ebenso ungenau wie missverständlich wie zu Polymorphie.

    Klassen haben nichts mit OOP zu tun. Das ist ganz grundlegend falsch.

    Man kann zu Attributen nicht Eigenschaften sagen, weil das verschiedene Dinge sind. Das ist ganz grundlegend falsch.

    Usw. usf. …

    Mir scheint das eine Collage von Fremdbeiträgen zu sein, die nicht richtig verstanden wurden.

    Und in der Tat: Freakerhaft wäre das Basteln des eigenen Systems. So klingt das zuweilen, weil es wenig mit den bestenden Begriffen von OOP, Objective-C und Cocoa zu tun hat. Das meinte ich genau damit, dass es entweder besonders freakig oder besonders fehlerhaft ist.

    Jedenfalls ist eine Sammlung von "Guck mal, so toll kann ich X" kein Tutorial, bloß weil es vorgibt, von "ganz unten" anzufangen.

    Bei Kresse ist das anders. Der weiß, wovon er spricht.
    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"?
  • 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!

    Original von Amin Negm-Awad
    Die Ausführungen zu Objekten sind ebenso ungenau wie missverständlich wie zu Polymorphie.

    Missverständnisse kommen durch Ungenauigkeit, zu Genaues wird schnell langweilig.
    Der schmale Grat und so. Daneben gilt: das Tutorial kost nix.

    Original von Amin Negm-Awad
    Klassen haben nichts mit OOP zu tun. Das ist ganz grundlegend falsch.

    Nein. Klassen haben insofern etwas mit OOP zu tun, als dass sie in einigen OOP-Sprachen eingesetzt werden um einen Objektbauplan zu haben.
    Dass man auch durch Prototyping Objekte schick zurechtbauen kann ist richtig.
    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 ist schlicht falsch, sie als Merkmal der objektorientierten Programmierung zu deklarieren.
    Da gebe ich dir Recht.
    Es ist ausgesprochen verwirrend für Klassenfetischisten, wenn ihnen bei einer vernünftigen Programmiersprache plötzlich klar wird, dass die Dinger nur ein Bauplan und keine definitive Repräsentation des Objektes sind, man den Bauplan also beliebig ändern kann.
    Auch da gebe ich dir Recht.

    Dennoch: obwohl Klassen kein Merkmal der objektorientierten Programmierung sind (sonst hieße es ja klassenorientierte Programmierung), haben sie definitiv mit OOP zu tun.

    Original von Amin Negm-Awad
    Man kann zu Attributen nicht Eigenschaften sagen, weil das verschiedene Dinge sind. Das ist ganz grundlegend falsch.

    Das stimmt allerdings.

    Original von Amin Negm-Awad
    Usw. usf. …

    Hui, ein Fehler rechtfertigt ein Usw. usf. ...?

    Original von Amin Negm-Awad
    Bei Kresse ist das anders. Der weiß, wovon er spricht.

    Ohne ihn jetzt persönlich angreifen zu wollen:
    - er wusste nicht, dass Object eine Methode namens -name kennt, die einen cString liefert
    - er wusste nicht, dass Objective-C bei dynamischer Typisierung vom Rootobjekt ausgeht
    - er wusste nicht, dass sein Tutorial demnach nur funktioniert, wenn das Array mit dem richtigen Typen typisiert wird, es aber Fehlermeldungen gibt, wenn mit id typisiert wird

    Ich bin beim ersten Testen darauf gestoßen und wollte die Schuld erst auf Windows schieben. Das war schlichtweg falsch, das Problem war die Existenz der Methode -name in der Klasse zu Object.

    Mittlerweile weiß er es. +lacht+
    Magst du ihm jetzt auch Fehlerhaftigkeit und Freaktum unterstellen?
    «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
  • Original von nepleurepas
    okay... wer ist kresse? Ein buch autor? gibt es ein einsteiger tutorial von ihm?würde es natürlich schon gern richtig lernen...

    Ein User hier im Forum.
    Ein Buch gibt es von ihm nicht, du kannst nur Seminare bei ihm buchen.
    Buch und Seminare gibts vom Amin.
    Ich beziehe mich auf dieses Tutorial von ihm.
    Die Tutorials sind meiner Meinung nicht zwingend einstiegsgeeignet.
    Besorg dir lieber einführende Literatur.
    Eine Auswahl findest du über den grünen 'Shop'-Button.
    «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
  • 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.

    Wenn ich mich nicht an das Programm halte, ist es entweder Unwissenheit oder Bosheit.

    Original von Lucas de Vil
    Original von Amin Negm-Awad
    Die Ausführungen zu Objekten sind ebenso ungenau wie missverständlich wie zu Polymorphie.

    Missverständnisse kommen durch Ungenauigkeit, zu Genaues wird schnell langweilig.
    Der schmale Grat und so. Daneben gilt: das Tutorial kost nix.

    Nein, ich meine nicht sprachliche Ungenauigkeiten.Objekt wird bei ihm ausnahmslos für Instanz verwendet. 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.

    Und es ist für die Beurteilung gleichgültig, ob es etwas kostet.

    Original von Lucas de Vil
    Original von Amin Negm-Awad
    Klassen haben nichts mit OOP zu tun. Das ist ganz grundlegend falsch.

    Nein. Klassen haben insofern etwas mit OOP zu tun, als dass sie in einigen OOP-Sprachen eingesetzt werden um einen Objektbauplan zu haben.
    Dass man auch durch Prototyping Objekte schick zurechtbauen kann ist richtig.

    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 …

    Original von Amin Negm-Awad
    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?

    Original von Lucas de Vil
    Original von Amin Negm-Awad
    Es ist schlicht falsch, sie als Merkmal der objektorientierten Programmierung zu deklarieren.

    Da gebe ich dir Recht.
    Es ist ausgesprochen verwirrend für Klassenfetischisten, wenn ihnen bei einer vernünftigen Programmiersprache plötzlich klar wird, dass die Dinger nur ein Bauplan und keine definitive Repräsentation des Objektes sind, man den Bauplan also beliebig ändern kann.
    Auch da gebe ich dir Recht.

    Dennoch: obwohl Klassen kein Merkmal der objektorientierten Programmierung sind (sonst hieße es ja klassenorientierte Programmierung), haben sie definitiv mit OOP zu tun.

    Jo, so wie das "+", weil ich das in einer Methode verwenden kann, nicht wahr?

    Original von Lucas de Vil
    Original von Amin Negm-Awad
    Man kann zu Attributen nicht Eigenschaften sagen, weil das verschiedene Dinge sind. Das ist ganz grundlegend falsch.

    Das stimmt allerdings.

    Original von Amin Negm-Awad
    Usw. usf. …

    Hui, ein Fehler rechtfertigt ein Usw. usf. ...?

    Nein, nicht einer. Zum einen hast du mein "schlicht falsch" vorhin noch mit einem "Da gebe ich dir Recht" quittiert. Und das war ein anderes Thema. Aber man braucht das gar nicht:

    Ich schlag jetzt mal zufällig ne Seite auf
    *Fahrstuhlmusik*
    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 in einen Abschnitt zu stopfen, zeugt von tiefem Unverständnis. Die Technologien haben so viel miteinander zu tun wie OOP und "+".

    Ich schlag jetzt mal zufällig ne Seite auf
    *Fahrstuhlmusik*

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

    Original von Lucas de Vil
    Original von Amin Negm-Awad
    Bei Kresse ist das anders. Der weiß, wovon er spricht.

    Ohne ihn jetzt persönlich angreifen zu wollen:
    - er wusste nicht, dass Object eine Methode namens -name kennt, die einen cString liefert
    - er wusste nicht, dass Objective-C bei dynamischer Typisierung vom Rootobjekt ausgeht
    - er wusste nicht, dass sein Tutorial demnach nur funktioniert, wenn das Array mit dem richtigen Typen typisiert wird, es aber Fehlermeldungen gibt, wenn mit id typisiert wird

    Ich bin beim ersten Testen darauf gestoßen und wollte die Schuld erst auf Windows schieben. Das war schlichtweg falsch, das Problem war die Existenz der Methode -name in der Klasse zu Object.

    Mittlerweile weiß er es. +lacht+
    Magst du ihm jetzt auch Fehlerhaftigkeit und Freaktum unterstellen?

    Nein, weil er nämlich grundsätzlich verstanden hat, wie die Sprache funktioniert.
    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"?