Einsteiger Fragen

  • RE: Noch ein paar Einsteigerfragen...

    Original von loonyfoobar
    1) Sollte das @interface immer in einer eigenen Datei (Präfix .h) stehen und nur die Implementation des Objekts in der Datei mit dem Präfix .m?


    Ja.

    Original von loonyfoobar
    2) Wofür genau sind die Bezeichner für Übergabeparameter da und wieso funktionieren diese bei jedem Parameter, nur nicht beim Ersten? Ist ein aussagekräftiger Variablen/Parameter-Name nicht genug?


    So etwas wie Bezeichner gibt es nicht in dem Zusammenhang.

    Original von loonyfoobar
    Bsp.: Ohne Bezeichner (wie ich es gewohnt bin)
    - (void) setBeginAndEnd : (int) begin : (int) end;

    Bsp.: Mit Bezeichner (für mich noch etwas ungewohnt)
    - (void) setBeginAndEnd : (int) begin bezeichner : (int) end;

    Bsp.: Mit zwei Bezeichnern (wäre für mich logisch, funktioniert aber nicht!)
    - (void) setBeginAndEnd bezeichner1: (int) begin bezeichner2: (int) end;



    Was hast du für ein Problem mit

    Quellcode

    1. - (void) setBegin: (int)a andEnd: (int)b;


    Der Selektor der Methode ist setBegin:andEnd:. Er darf auch keine Leerzeichen enthalten wie in deinem letztem Beispiel. Das ist alles zusammen ein Selektor und nicht ein Methoden-Name mit "Bezeichnern".

  • ich bin auch nur anfänger, aber falls ich recht hab spar ich nem experten vielleicht tipparbeit und er kanns mit einem ja absegnen oder andernfalls auch meine denkfehler gleich mitkorrigieren ;).

    zu 1) soweit ich weis ist genau das der sinn der trennung. ob das zwingend so sein muss weiß ich leider nicht.

    zu 2) das konzept kam mir auch verwirrend vor. ich schätze es soll die lesbarkeit der methodenaufrufe erhöhen. das hier kann nicht funktionieren, weil die leerstelle im methodennamen nicht erlaubt ist (siehe eine meiner ersten fragen hier im thread):
    - (void) setBeginAndEnd bezeichner1: (int) begin bezeichner2: (int) end;
    aber so müsste gehen:
    - (void) setBeginAndEndBezeichner1: (int) begin bezeichner2: (int) end;

    dazu noch eine frage von mir, es gibt ja methoden die man mit unterschiedlicher anzahl an parametern aufrufen kann. wenn ich also
    [self setBeginAndEndBezeichner1:meinInt];
    oder
    [self setBeginAndEndBezeichner1:meinInt bezeichner2:meinInt2];
    schreibe, muss die methode dafür dann in beiden varianten implementiert sein, oder kann man eine methode mit unvollständigem parametersatz aufrufen (ob das sinn macht hinge dann wohl davon ab, ob die methode so geschrieben ist, das sie nicht alle parameter zwingend braucht, es geht mir jetzt nur um die grundsätzliche technische möglichkeit)?

    edit: da war dergraf schneller.


    @scharnagl: mein spiel soll in echtzeit ablaufen wie ein klassisches arcade spiel oder RTS. aber es soll natürlich möglich sein den stand der sitzung zu speichern, allein schon wenn das programm geschlossen wird um zwischendurch z.b. mails abzurufen, soll man genau da weiterspielen können, wo man aufgehört hat. aber es sollen keine replays gespeichert werden, die einen ganzen spielverlauf speichern. ich sollte vielleicht mal schauen wie das in RTS games gelöst wird, wo keine replays gespeichert werden.

  • Original von wolf_10deNein das war nicht ironisch gemeint. Ein Spiel hat keine Views (in aller Regel läuft das ja im Vollbild, wie du ja gesagt hast), damit wars das aber schon wieder.
    Die Controller die die Spiellogik abbilden haben ja nix mit denen von MVC zu tun. Ein Controller im Spiel (nehmen wir mal einen Textur-Controller) macht nix anderes als Texturen verwalten sonst nix, ein Controller im MVC bildet das Bindeglied zwischen Daten und View, das ist ein großer Unterschied.
    Was in den Gems geschrieben wird, ist das was ich als Beispiel mit dem Texture-Controller geschrieben habe.
    Bei Spielen geht es sehr viel um Geschwindigkeit, was nicht immer genau das ist was man bei der "normalen" Softwarentwicklung hat. Hier werden sehr viele Sachen immer noch in reinem C gemacht.



    gerade weil ich überhaupt nicht einschätzen kann wo ich mal performance probleme mit dem iphone haben könnte, noch nicht auf dem gerät testen kann und auch wenig über optimierung weiß, hab ich das thema geschwindigkeit bei allem schon im hinterkopf. ich hab hier einen artikel gefunden der performance zwischen objc und c in bestimmten situationen vergleicht:

    memo.tv/nsarray_vs_c_array_performance_comparison
    memo.tv/nsarray_vs_c_array_per…akeobjectsperformselector

    weitere artikel die sich mit grundlegenden performance problemen und der frage obj-c vs c im bezug auf iphone spieleprogrammierung beziehen würden mich natürlich interessieren.

  • Original von MartinH.
    Original von wolf_10deNein das war nicht ironisch gemeint. Ein Spiel hat keine Views (in aller Regel läuft das ja im Vollbild, wie du ja gesagt hast), damit wars das aber schon wieder.
    Die Controller die die Spiellogik abbilden haben ja nix mit denen von MVC zu tun. Ein Controller im Spiel (nehmen wir mal einen Textur-Controller) macht nix anderes als Texturen verwalten sonst nix, ein Controller im MVC bildet das Bindeglied zwischen Daten und View, das ist ein großer Unterschied.
    Was in den Gems geschrieben wird, ist das was ich als Beispiel mit dem Texture-Controller geschrieben habe.
    Bei Spielen geht es sehr viel um Geschwindigkeit, was nicht immer genau das ist was man bei der "normalen" Softwarentwicklung hat. Hier werden sehr viele Sachen immer noch in reinem C gemacht.



    gerade weil ich überhaupt nicht einschätzen kann wo ich mal performance probleme mit dem iphone haben könnte, noch nicht auf dem gerät testen kann und auch wenig über optimierung weiß, hab ich das thema geschwindigkeit bei allem schon im hinterkopf. ich hab hier einen artikel gefunden der performance zwischen objc und c in bestimmten situationen vergleicht:

    memo.tv/nsarray_vs_c_array_performance_comparison
    memo.tv/nsarray_vs_c_array_per…akeobjectsperformselector

    weitere artikel die sich mit grundlegenden performance problemen und der frage obj-c vs c im bezug auf iphone spieleprogrammierung beziehen würden mich natürlich interessieren.


    Vergiss erst mal alles was optimieren angeht, Du stehst ja erst mal ganz am Anfang!

  • Beide Artikel vergleichen den lesenden Zugriff. Wolltest du nicht auch auf das Array schreiben?

    Aber ich kann mich nur wolf anschließen: Premature optimization is the root of all evil (Donald Knuth)
    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
    Aber ich kann mich nur wolf anschließen: Premature optimization is the root of all evil (Donald Knuth)

    An den Spruch musste ich auch denken, wobei der wohl mehreren zugeschrieben wird (en.wikipedia.org/wiki/C._A._R._Hoare#Quotes). Naja, glaube keinem Zitat, dass Du nicht selbst jemanden zugeschrieben hast (macmoonshine) ;)
    „Meine Komplikation hatte eine Komplikation.“

  • Original von macmoonshine
    Original von Amin Negm-Awad
    Aber ich kann mich nur wolf anschließen: Premature optimization is the root of all evil (Donald Knuth)

    An den Spruch musste ich auch denken, wobei der wohl mehreren zugeschrieben wird (en.wikipedia.org/wiki/C._A._R._Hoare#Quotes). Naja, glaube keinem Zitat, dass Du nicht selbst jemanden zugeschrieben hast (macmoonshine) ;)

    Geh mal auf Nachweis [7]. Er selbst will das nicht für sich in Anspruch nehmen. Allerdings wird von Knuth in seinem Buch Structured Program with goto Statements verwendet. Und bei diesem Buchtitel …
    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
    Und bei diesem Buchtitel …

    Der Titel hat anscheinend funktioniert.
    Donald A Knuth: Structured Programming With go to Statements. Computing Surveys, Vol. 6, No. 4, December 1974

    Before beginning a more technical discussion, I should confess that the title of this article was chosen primarily to generate attention. There are doubtless some readers who are convinced that abolition of go to statements is merely a fad. and they may see this title and think, "Aha! Knuth is rehabilitating the go to statement, and we can go back to our old ways of programming again." Another class of readers will see the heretical title and think, "When are die-hards like Knuth going to get with it?" I hope that both classes of people will read on and discover that what I am really doing is striving for a reasonably well balanced viewpoint about the proper role of go to statements. I argue for the elimination of go to's in certain cases, and for their introduction in others.

    I believe that by presenting such a view I am not in fact disagreeing sharply with Dijkstra's ideas, since he recently wrote the following: "Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"


    Sorry für das lange Zitat, aber der Artikel ist grandios. Und an vielen Stellen noch sehr aktuell, obwohl er aus dem Jahr 1974 stammt. Must read.
    Multigrad - 360°-Produktfotografie für den Mac

  • Original von Amin Negm-Awad
    Geh mal auf Nachweis [7]. Er selbst will das nicht für sich in Anspruch nehmen.

    Das hatte ich auch vorher gelesen. Das Witzige daran ist ja, dass er noch einen dritten möglichen Urheber ins Spiel bringt. Und wer erinnert sich schon an Alles, was er so von sich gibt ;)
    „Meine Komplikation hatte eine Komplikation.“

  • Original von mattik
    Original von Amin Negm-Awad
    Und bei diesem Buchtitel …

    Der Titel hat anscheinend funktioniert.
    Donald A Knuth: Structured Programming With go to Statements. Computing Surveys, Vol. 6, No. 4, December 1974

    Before beginning a more technical discussion, I should confess that the title of this article was chosen primarily to generate attention. There are doubtless some readers who are convinced that abolition of go to statements is merely a fad. and they may see this title and think, "Aha! Knuth is rehabilitating the go to statement, and we can go back to our old ways of programming again." Another class of readers will see the heretical title and think, "When are die-hards like Knuth going to get with it?" I hope that both classes of people will read on and discover that what I am really doing is striving for a reasonably well balanced viewpoint about the proper role of go to statements. I argue for the elimination of go to's in certain cases, and for their introduction in others.

    I believe that by presenting such a view I am not in fact disagreeing sharply with Dijkstra's ideas, since he recently wrote the following: "Please don't fall into the trap of believing that I am terribly dogmatical about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"


    Sorry für das lange Zitat, aber der Artikel ist grandios. Und an vielen Stellen noch sehr aktuell, obwohl er aus dem Jahr 1974 stammt. Must read.


    Kannst du mir ein Beispiel nennen, in dem du aktuell ein goto verwendest?
    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 macmoonshine
    Original von Amin Negm-Awad
    Geh mal auf Nachweis [7]. Er selbst will das nicht für sich in Anspruch nehmen.

    Das hatte ich auch vorher gelesen. Das Witzige daran ist ja, dass er noch einen dritten möglichen Urheber ins Spiel bringt. Und wer erinnert sich schon an Alles, was er so von sich gibt ;)

    Damas gab es noch kein Internet.
    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
    Kannst du mir ein Beispiel nennen, in dem du aktuell ein goto verwendest?


    Überall da, wo du eine Schleife mittels break oder eine Funktion vor ihrem Ende mit return verlässt. Du schreibst zwar nicht goto, aber der Effekt ist der selbe. Beides ist eine bequemere und etwas sichere Variante von goto. Und sicherer auch nur insofern, dass man das Label nicht aus versehen an die falsche Stelle setzen kann.

  • wunderbarer anknüpfpunkt für meine frage ob es schlechter stil ist eine schleife mit break zu verlassen. das ging mir neulich durch den kopf...


    @wolf: ok, dann versuch ich mich erstmal auf andere dinge zu konzentrieren. danke.

    @amin: ja, guter punkt, schreibperformance werd ich dann in ferner zukunft selbst mal benchmarken. der spruch ist ne schöne denkstütze :D. danke!

  • Original von dergraf
    Original von Amin Negm-Awad
    Kannst du mir ein Beispiel nennen, in dem du aktuell ein goto verwendest?


    Überall da, wo du eine Schleife mittels break oder eine Funktion vor ihrem Ende mit return verlässt. Du schreibst zwar nicht goto, aber der Effekt ist der selbe. Beides ist eine bequemere und etwas sichere Variante von goto. Und sicherer auch nur insofern, dass man das Label nicht aus versehen an die falsche Stelle setzen kann.

    Nein, das ist gerade kein Goto, weil es eben der Struktur folgt, was Goto gerade nicht macht und nicht machen soll. Du sprichst hier von Implementierungsdetails.

    Du würdest ja auch nicht sagen, dass ich Prozessorregister anspreche.
    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 MartinH.
    wunderbarer anknüpfpunkt für meine frage ob es schlechter stil ist eine schleife mit break zu verlassen. das ging mir neulich durch den kopf...

    Das ist okay, weil es eine Struktur verlässt. Du kannst ja bei Sprüngen sozusagen zwei Orte bestimmen. Den Ursprung und das Ziel.

    Bei Goto kann man von überall nach überall springen. (Wobei das in C nur innerhalb des Stack-Kontextes geht, sonst longjmp usw.)

    break, continue, return springen zwar von jedem Punkt aus etwas heraus, aber immer an einen Punkt des Konstruktes, welches sie umgibt. Das heißt, dass das Konstrukt immer ordentlich abgeschlossen wird. Das ist sozusagen die halbe Miete.

    Goto geht kreuz und quer. Das ist keine Miete. Der letzte Fall, wo so etwas zur Vermeidung von Unbequemlichkeiten notwendig war, waren Fehlerbehandlungen. Aber die sind ja nun mittlerweile auch durch Exceptions strukturiert.

    Mir fällt wirklich aktuell kein Beispiel mehr ein, bei dem Goto sinnvoll wäre. Für mich ist das anachronistisch, ich lasse mich aber gerne von einem Beispiel überzeugen.

    Original von MartinH.[…]
    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
    Mir fällt wirklich aktuell kein Beispiel mehr ein, bei dem Goto sinnvoll wäre. Für mich ist das anachronistisch, ich lasse mich aber gerne von einem Beispiel überzeugen.

    Soweit ich weiß, ist es in vielen Sprachen noch drin, weil es von Compilergeneratoren gerne verwendet wird.
    „Meine Komplikation hatte eine Komplikation.“

  • Original von macmoonshine
    Original von Amin Negm-Awad
    Mir fällt wirklich aktuell kein Beispiel mehr ein, bei dem Goto sinnvoll wäre. Für mich ist das anachronistisch, ich lasse mich aber gerne von einem Beispiel überzeugen.

    Soweit ich weiß, ist es in vielen Sprachen noch drin, weil es von Compilergeneratoren gerne verwendet wird.

    Okay, lass es mich genauer formulieren: Für den Programmierer sinnvoll wäre.
    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"?

  • Ein ehemaliger Kollege hat mal ungefähr Folgendes geschrieben:

    Quellcode

    1. for(int i = 1; i <= 3; i++) {
    2. switch(i) {
    3. case 1:
    4. // auskommentierter Code
    5. break;
    6. case 2:
    7. // auskommentierter Code
    8. break;
    9. case 3:
    10. [self doSomethingTrivial];
    11. break;
    12. }
    13. }
    Alles anzeigen
    Den schreckt wahrscheinlich nichts mehr ab. In einem Gespräch ließ er auch mal die Bemerkung fallen, dass er so programmiert, dass es sehr schwer verständlich ist. Dadurch glaubte er unersetzbar zu sein.

    Ich vermute, dass er Gotos liebt.
    „Meine Komplikation hatte eine Komplikation.“