INNER JOIN und WHERE Problem

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

    • Amin Negm-Awad schrieb:

      Es würde ja ausreichen UINT_MAX+1 zu nehmen. Man kann wohl eine Maschine bauen, bei der man es testen kann. Die praktische Relevanz dürfte allerdings gering sein. Es geht mehr darum, dass das einheitlich durchgezogen ist.


      was ist denn einheitlich daran dass zb
      - (NSInteger)numberOfRowsInTableView:(NSTableView *)aTableView
      NSInteger verwendet und nicht NSUInteger?

      ;)
    • Amin Negm-Awad schrieb:

      Fehler sind nicht ausgeschlossen, aber das durchzieht ja das gesamte Cocoa wegen NSNotFound. Also sind es letztlich 63 Bit. (Immer noch deutlich mehr als 32 Bit oder 33 Bit.)


      aber was soll NSNotFound bei einem "numberOf*"? das macht ja keinen sinn. Bei "indexOf*" machts natürlich sinn.

      wäre ja gleich unsinnig bei "count" von NSArray oder einer sonstigen collection NSInteger zu verwenden anstatt NSUInteger...
    • Das soll natürlich nichts mit einem NSNotFound. Mutmaßlich geht das irgendwohin, wo NSInteger steht. Stell dir vor, es wäre ein NSUInteger. Dann könnte man dann ja 0xF… zurückliefen. Wandert das irgendwohin, wo mal ein NSInteger steht, geht das kaputt.

      Es tauchen in Cocoa NSUInteger und NSInteger ständig gemischt auf. Da kann man an vielen Stellen fragen, was das soll. NSNotFound ist so definiert, dass das gut funktioniert. Und mit 63 Bit, die man ohne Nachdenken nutzen kann, kommt man gut aus.
      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"?
    • Amin Negm-Awad schrieb:

      Das soll natürlich nichts mit einem NSNotFound. Mutmaßlich geht das irgendwohin, wo NSInteger steht. Stell dir vor, es wäre ein NSUInteger. Dann könnte man dann ja 0xF… zurückliefen. Wandert das irgendwohin, wo mal ein NSInteger steht, geht das kaputt.

      Es tauchen in Cocoa NSUInteger und NSInteger ständig gemischt auf. Da kann man an vielen Stellen fragen, was das soll. NSNotFound ist so definiert, dass das gut funktioniert. Und mit 63 Bit, die man ohne Nachdenken nutzen kann, kommt man gut aus.


      mit dem argument hätten sie ja auch bei "count" NSInteger verwenden können...
    • Amin Negm-Awad schrieb:

      Nein, weil in einem Array ganz gewiss niemals ein signed auftaucht.


      bei einem numberOf* aber auch nicht. und nur weil das dann irgendwo verwendet werden KÖNNTE wo es einen signed bracuht dies schon mal als signet int zurückzuliefern spräche ja genauso bei NSArray dafür ein signed zu liefern weil man das irgendwo brauchen könnte wo ein signed benötigt wird.
      ich finde es ja nicht arg schlimm, würde aber eben auch nicht von "einheitlich" sprechen.
      es stumpft halt viele ab wenn sie gewohnt sind von (NSUInteger)count einfach auf NSInteger zu casten um es zb bei numberOfRowsForTableView zurückzugeben.
      oder sind die warnings darüber defaultmäßig aus?
      nachtrag: hab nachgeschaut und gesehen dass die warnings "implicit integer conversions" defaultmäßig deaktiviert sind... also merken 95% der programmierer wohl gar nichts von den ganzen casts (außer es gibt mal ein problem wovon aber nicht auszugehen ist).
    • Bei Rows kannst du leicht zurückrechnen (subtrahieren), was immer einen Signed impliziert. Bei einem reinen Container hast du das nicht. (Was übrigens auch relativ gleichgültig ist, weil das Ergebnis von signed->unsigned zwar undefiniert ist, der Standard aber verlangt, dass signed->unsigned->signed == signed ist. Für ints ist das so festgelegt und IIRC gilt das auch für longs. Müsste ich aber nachschauen.)

      Aber ich sage ja auch nicht, dass ich das überaß so typisiert hätte. Dazu habe ich auch zu wenig Ahnung von den Interna. Wie ich schon schrieb, taucht das in Cocoa recht gemischt auf, was uninteressant ist, weil das NSNotFound berücksichtigt und 63 Bit allemal ausreichen. Deshalb sind die Casts praktisch auch problemlos. (Und müssen nicht zu einer Warning fü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"?
    • ja klar, ist es in dem fall kein problem.

      in diesen fällen ist ein cast auch kein problem, ich möchte mir im generellen aber alle warnings anzeigen lassen weil es eben auch genug code gibt bei dem das schon eine rolle spielt (ich spreche jetzt nicht von NSInteger vs NSUInteger weil man diese ja wohl eher selten verwendet wenn man irgendeinen algorithmus implementiert.
      und da man die warnings nicht für alles aktivieren kann außer NS(U)Integer bekommt man diese eben auch dort und muss oftmals casten.

      ich verstehe nicht was ein numberOf* mit indexen zu tun hat. klar hat ein numberOf* im entferntesten etwas mit indexen zu tun. ein array ja aber auch (und dort ist NSInteger ja ok).

      ich sehe nur keinen grund warum sie bei numberOf* NSInteger verwendet haben und bei count NSUInteger. Und auch unter 32 bit wäre ein NSInteger locker groß genug gewesen weil es eh schon weit über dem limit des verfügbaren speichers lag.
      wenn man also sagt dass sich apple eben mal nach lust und laune bei einer methode für das eine und bei der nächsten für das andere entschieden hat, dann ist das für mich vollkommen ok. nur ist es in dem fall für mich in dem fall von "einheitlichkeit" zu reden und das auch noch zu loben.

      so und jetzt ist "feierabend" hier - die piste ruft ;)