Bei sizeof() sollte man genau schauen.

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

  • Bei sizeof() sollte man genau schauen.

    Eigentlich wollte ich das noch an diesen 'Thread'anhängen, aber irgendwie geht das nicht mehr.
    Heute habe ich Spielen mit der lustigen Suchmaschine festgestellt, dass man, wenn man für MKPolylne Punkte sammeln will,
    sich den Speicher dafür mit malloc() besorgen kann.
    Dafür sollte man doch eigentlich dann so etwas wie

    Quellcode

    1. MKMapPoint *points = malloc(sizeof(MKMapPoint) * count);
    2. free(points);

    machen.

    Stattdessen finde ich überall:

    Quellcode

    1. MKMapPoint* pointArr = malloc(sizeof(CLLocationCoordinate2D) * ortResultArray.count);
    wie das hier aus dem Forum.

    Ein der versierteren Blogger hat diesen Fehler gemacht, und jetzt schleppt er sich durch.
    Glücklicherweise sind beide Typen gleich groß, aber das ist, glaube ich, keine Entschuldigung.
    I would be embarrassed if they did not spy on me.
  • Du hast ja Recht.
    Wenn man es nur richtig machen würde.
    Aber wenn Du hier schaust, dann wird eben der Speicher mit dem einen Typ geholt und dann in der anderen Methode verwendet.

    Quellcode

    1. MKMapPoint* pointArr = malloc(sizeof(CLLocationCoordinate2D) * pointStrings.count);
    2. self.routeLine = [MKPolyline polylineWithPoints:pointArr count:pointStrings.count];


    Und das zieht sich durch.

    Ich wollte es ja nur mal gesagt haben.
    I would be embarrassed if they did not spy on me.
  • Wobei man sagen muss, dass C Arrays Per-Reference behandelt und sich daher VLAs nicht zurückgeben lassen. Ich bin jetzt aber deutlich zu faul nachzuschlagen, ob das im von longW verlinkten Code eine Rolle spielt. Aber häufig ist das ein k.o.-Kriterium gegen deren Einsatz.
    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"?
  • Es geht.

    Es gibt manchmal immer noch Warnungen.
    Das ist dann wie mit den Bierflaschen, die man aufschrauben kann, aber dann doch vorsichtshalber, oder aus Tradition, den Öffner benutzt.

    Effektiv ist das nur ein weiterer Punkt gegen das naive Kopieren und Einfügen von Code, den irgendwann irgendwie mal jemand geschrieben hat.
    I would be embarrassed if they did not spy on me.
  • longW schrieb:

    Es geht.

    Es gibt manchmal immer noch Warnungen.
    Das ist dann wie mit den Bierflaschen, die man aufschrauben kann, aber dann doch vorsichtshalber, oder aus Tradition, den Öffner benutzt.

    Effektiv ist das nur ein weiterer Punkt gegen das naive Kopieren und Einfügen von Code, den irgendwann irgendwie mal jemand geschrieben hat.

    Ja, gerade dieses unreflektierte Übernehmen führt da zu Fehlern. Da lagerst du einen Codeblock in eine Funktion aus, machst ein fröhliches "return myArray;" und wunderst dich, dass es auf einmal nicht mehr geht.

    Ich lass' wegen solcher Effekte ohnehin die Finger von C-Arrays wo es nur geht.
    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"?
  • longW schrieb:

    Amin Negm-Awad schrieb:

    Ich lass' wegen solcher Effekte ohnehin die Finger von C-Arrays wo es nur geht.


    Wenn das nur ginge. Stattdessen werden immer noch neue, und sowieso ähnliche Typen eingeführt, wie eben im MapKit: Map Kit Data Types Reference.

    Klar, die tauchen immer wieder dann auf, wenn man große Mengen sich wiederholender skalarer Typen hat. Gibt es schon bei NSBezierPath, man muss also nicht in die Ferne schweifen. Aber glücklicherweise sind das häufig Fälle, in denen sich die Komplexität in Grenzen hält.
    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"?