Textdatei einlesen

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

  • Das war wohl eher eine rhetorische Frage von Michael. Mit return wird ein Wert zurückgegeben und der Codeblock wird verlassen.
    Überprüfen kann man sowas immer gut mit NSLog. Außerdem ist probieren doch um einiges besser als - fragen, versuchen zu verstehen, sich streng daran - halten da man durch das rumprobieren, meiner Meinung nach, viel mehr lernt.

  • Ohne es getestet zu haben:

    Ein NSArray ist ja nicht einfach ein Array, sondern kann ein ganz schön kompliziertes Dingens sein (mit mehreren Kacheln in einer verketteten Liste usw.).

    objectAtIndex:(NSArray) weiß nicht davon, dass zuletzt das gerade vorangegangene Objekt aufgerufen wurde, so dass es mit der Suche ganz von vorne beginnt. nextObject weiß hingegen, dass es lkediglich einen Schritt weiter gehen muss und kann sich daher optimieren, insbesondere ggfls. in der gleichen Kachel bleiben.

    Daher dürfte nextObject(NSObject) ob der zusätzlichen Information performanter sein. Wenn es das nicht wäre, so würde es selbst nur einen objectAtIndex:(NSObject) ausführen ...
    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 Tom9811
    Ohne es getestet zu haben:

    Ein NSArray ist ja nicht einfach ein Array, sondern kann ein ganz schön kompliziertes Dingens sein (mit mehreren Kacheln in einer verketteten Liste usw.).

    objectAtIndex:(NSArray) weiß nicht davon, dass zuletzt das gerade vorangegangene Objekt aufgerufen wurde, so dass es mit der Suche ganz von vorne beginnt. nextObject weiß hingegen, dass es lkediglich einen Schritt weiter gehen muss und kann sich daher optimieren, insbesondere ggfls. in der gleichen Kachel bleiben.

    Daher dürfte nextObject(NSObject) ob der zusätzlichen Information performanter sein. Wenn es das nicht wäre, so würde es selbst nur einen objectAtIndex:(NSObject) ausführen ...

    Ich hab das jetzt mal getestet:

    Quellcode

    1. 2005-08-01 08:16:44.362 ArraySpeedTest[534] time used for array1: 0:83444
    2. 2005-08-01 08:16:44.428 ArraySpeedTest[534] time used for array2: 0:52175
    3. 2005-08-01 08:16:44.478 ArraySpeedTest[534] time used for array3: 0:38645

    Wobei:
    array1: For-Schleife mit Bestimmung der laenge des Arrays im Schleifenkopf. Adressierung des Objekts mit -objectAtIndex:.
    array2: Gleiche wie array1, aber die laenge der Schleife wuerde ausserhalb ermittelt.
    array2: Durchlauf mit Enumerator.

    Jeweils mit 500000 Array-Elementen. Die Zahlen bleiben bei mehreren Tests konstant, gemessen mit gettimeofday().

    Manfred

  • Original von asrael
    Wobei:
    array1: For-Schleife mit Bestimmung der laenge des Arrays im Schleifenkopf. Adressierung des Objekts mit -objectAtIndex:.
    array2: Gleiche wie array1, aber die laenge der Schleife wuerde ausserhalb ermittelt.
    array2: Durchlauf mit Enumerator.

    Nachtrag:
    Der Unterschied zwischen array2 und array3 haengt etwas von der Menge der Array-Eintraege ab. Je weniger Eintraege, desto geringer ist der Abstand.

    Man sieht also, das, wie hns es gesagt hat, die Ermittlung der Schleifenlaenge bei jedem Durchlauf im Kopf sehr viel Zeit braucht. Fast das Doppelte...

    Manfred

  • Jo und man sieht, dass der Enumerator schneller ist. Ich hatte das auch erwartet und schon längere Zeit propagiert:
    macentwicklerwelt.net/index.ph…e=Universal_Binaries#Ints

    Daneben gibt es natürlich noch den von Michael erwähnten Vorteil der Awendbarkeit auf alle Container und den im zitierten Artikel erwähnten Vorteil, dass man keine Bereichsprüfung vornehmen muss.
    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"?

  • Bitte schau dir meinen Code-Snipplet noch einmal an! Machen wir eine Wette um einen abend saufen, dass der if-Block abgebrochen wird?

    "In *C* gibt es kein Schlüsselwort zum Verlassen eines Blocks."

    Und machen wir eine Wette, dass ich mit einem return einen if-Block verlassen kann:

    Quellcode

    1. - aMethod {
    2. NSString* string = [NSSTring string];
    3. if( !string ) { // if-Block starts
    4. return;
    5. // die folgenden Anweisungen werden nicht ausgeführt.
    6. ...
    7. }
    9. // Diese ohnehin nicht, was auch die Aufgabe von return ist
    10. ...
    11. }
    Alles anzeigen


    "In *C* gibt es kein Schlüsselwort zum Verlassen eines Blocks."
    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"?

  • Hä? Du weißt was Du dort schreibst ja?

    Ja. Wie lauten deine Einwände?

    Übrigens hast Du was in deiner Genialen aufzählen vergessen .... exit

    Ich hoffe jetzt, dass du nicht Genitalen meinst. ;)

    Aber ich habe gar nichts aufgezählt. Die Diskussion ging los mit einem return, dass angeblich einen Code-Block verlässt, was falsch ist.

    Dann wurde mit ein break vorgehalten, welches angeblich einen Code-Block verlässt, was falsch ist.

    "In *C* gibt es kein Schlüsselwort zum Verlassen eines Blocks."

    Jedes dieser "Exit-"Schlüsselwörter verlässt soviele Code-Blöcke bis es zu einem dem Schlüsselwort korrespondierenden Code-Block kommt. Von keinem dieser Schlüsselwörter lässt sich sagen, dass es einen Code-Block verlässt. Nenne mir eines und ich schreibe dir ein Beispiel, was das Gegenteil belegt.
    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"?

  • Ich habe nicht einmal gesagt, dass das Verhalten von *C* schlecht ist. Die Variante mit dem allgemein gültigen "exit if ..." finde ich deutlich unflexibler. Ganz im Gegenteil, ich würde mir sogar für jeden Block-Typen ein eigenes "Exit"-Schlüsselwort wünschen oder eine Angabe der Block-Levels, die verlassen werden. Also etwa:

    Quellcode

    1. aMethod {
    2. for( ... ) {
    3. while( ... ) {
    4. break 1; // verlässt den while-Block -> break
    5. break 2; // verlässt den while- und den for-Block -> keine Entsprechung in C
    6. break 3; verlässt den while-, den for- und den Methoden-Block -> return
    7. }
    8. }
    9. }

    Das wäre das Maximum an Flexibilität. Allerdings dürfte das schlechter lesbar sein.

    Dennoch darf man offenbar nichts mit einer Negation formuliertes über *C* schreiben, ohne dass sich Widerspruch regt.
    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"?

  • Du bist kleinkariert.

    Es ist doch Allgemein bekannt das break ein case im switch beendet und Schleifen beendet.
    return verlässt Funktionen, exit das Programm.
    Warum reitest Du nun darauf herum? Langeweile?

    Was verstehst eigenttlich unter Code Block genau? Wie wäre es mit goto? :D

    Sven
    :wq! /dev/null

  • Du bist klein kariert.

    Danke für die persönliche Beleidigung. Darf ich sie an die entsprechenden Normierungsgremien und Compilerbauer weitergeben? Ich habe das nämlich nicht entschieden.

    Es ist doch Allgemein bekannt das break ein case im switch beendet und Schleifen beendet.

    Ja, etwas anderes habe ich ja auch nicht geschrieben,

    return verlässt Funktionen,

    Ebendt(tm)! Funktionen und Methoden, aber nicht Blöcke. Ich hatte hierauf geantwortet:
    "Mit return wird ein Wert zurückgegeben und der Codeblock wird verlassen."

    Und das ist auch wichtig:

    Quellcode

    1. - aMethod {
    2. NSString* string = [NSString string];
    3. if( !string ) {
    4. return;
    5. }
    6. // Wenn return einen Block verlassen würde, würden die folgenden Anweisungen
    7. // ausgeführt. Das stimmt jedoch _nicht_.
    8. [...]
    9. }


    Übrigens war das dem OP offenbar nicht bekannt. Er hat nämlich gesagt, dass er nicht wüsste, ob der folgende Code ausgeführt wird. Lies bitte noch einmal seinen Beitrag!

    exit das Programm.

    Ich habe nie von exit angefangen. Ich habe auch nicht mit return angefangen und auch nicht mit break.

    Was verstehst eigenttlich unter Code Block genau?

    { textdazwischen }

    Wie wäre es mit goto?

    Ein goto verlässt ganz gewiss nicht einen Block und hat damit nun gar nichts zu tun:

    Quellcode

    1. [...]
    2. for( ... ) {
    3. while( ... ) {
    4. if( ... )
    5. goto LABEL; // verlässt 3 Blöcke, nicht einen
    7. [...]
    8. goto LABEL; // verlässt gar keinen Block
    10. LABEL: [...]


    Emoticon

    Wie meinen?
    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"?

  • Ich habe hier gar keine Diskusssion angefangen, sondern lediglich darauf hingewiesen, dass return nicht einen Block verlässt, so wie es gar kein Schlüsselwort gibt, welches einen Block verlässt.

    Ich bin dementsprechend auch nicht mit return gekommen, sondern mein Vorposter.

    Ich verstehe auch nicht, wie sich aus dieser sicher richtigen und extrem kurzen Aussage so ein Thread entwickeln kann. Offenbar liegt es daran, dass geantwortet wird, bevor man die Beiträge im Thread gelesen hat. Oder kannst du mir erklären, wie es kommt, dass auf eine kurze Antwort auf MetalSnake einen Beitrag von Michael bekomme und etwa 123789687123678 von dir?
    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"?

  • Meine beiden ersten Beiträge waren Themen bezogen. Der dritte war eine Antwort auf Deine Aussage das ein break auch ein if verlässt welches im Switch/Case hängt. Daraufhin habe ich nur den Code gepostet das ein break im if überhaupt nicht funktioniert und es logisch ist, das sich das break auf den case Teil bezieht und diesen auch verlässt.

    Was mir wieder auffällt, Du schreibst so löcherrich das man alles aus Deinem Beiträgen herauslesen kann. So langsam aber sicher habe ich das Gefühl das es Absicht ist.


    Und machen wir eine Wette, dass ich mit einem return einen if-Block verlassen kann:

    Und doch Du kamst danach mit return auf meinen Beitrag.

    Sven
    :wq! /dev/null