Was ist __bridge ?

macmoonshine · 14. Oktober 2012, 12:03

t-no schrieb:

Da fällt mir ein:
Mir ist schon mehrfach aufgefallen, dass Xcode sich bei neuen Projekten nicht so wirklich darum schert, wenn man kein ARC möchte - das Template geht trotzdem direkt mit einem @autorelease los. Hat dazu schon jemand einen Bugreport verfasst?

...und die Direktive heißt außerdem @autoreleasepool.

Und gerade weak ist doch ein gutes Beispiel für eine Verbesserung.

macmoonshine · 14. Oktober 2012, 12:09

Thallius schrieb:

Das ist also eine Zeile mehr tippen, dafür habe ich die komplette Kontrolle.

Das scheint so, und warum soll ich etwas machen, was der Computer genauso gut kann. Alles, was sich automatisiert machen lässt, soll der machen, nicht ich. Dafür ist er doch da, und alles andere ist Windows.

Steig' doch lieber auf Assembler um, da hast Du noch mehr Kontrolle.

Amin Negm-Awad · 14. Oktober 2012, 13:51

Um das Grundproblem zu lösen:

1. ARC is for objects.
2. void* ist nicht zwingend ein Zeiger auf ein Objekt, weder bei der Übergabe noch beim Empfang.
3. void* ist alles, also vielleicht ein Objekt, vielleicht kein Objekt. (Deshalb wurde da auch nie ein retain gemacht. Oder will jemand einen retain auf int*, was void* ja auch sein kann?)
4. Diesen Fall musste man bei MRC also auch manuell (wie alles andere) behandeln.
5. Weil man mit NSstring* -> void* und void* -> NSString* die Welten wechselt, muss man – wie hier schon richtig mitgeteilt – dem Compiler sagen, wie er wechseln soll.
6. Ob das CF ist oder std-C, spielt dafür keine Rolle. void* ist jedenfalls nicht zwingend ein Objekt.
7. Dass der Compiler 99 % der Fälle richtig behandelt und man ihm in 1 % der Fälle helfen muss, ist deutlich einfacher als 100 % der Fälle selbst zu behandeln. Zumal mich die Fragestellung zweifeln lässt, dass es bei MRC richtig gemacht worden wäre.

Amin Negm-Awad · 14. Oktober 2012, 13:54

t-no schrieb:

… ist übrigens deprecated (ich hab' auch ganz schön geguckt, als ich das gesehen habe).
ARC gegenüber bin ich auch sehr skeptisch: Die Grundidee ist zwar gut, aber das ganze __bridge, __weak und __strong finde ich komplizierter als meinen Speicher von Hand zu verwalten.
Etwas polemisch ausgedrückt: Objective-C wird in Richtung "Idiotenkompatibilität" weiterentwickelt, und darunter "leiden" die Fortgeschrittenen, die es auch ohne ARC hinbekommen haben, die an sich einfachen Regeln zur Speicherverwaltung einzuhalten.
Sicher, jeder vergisst ab und an mal einen release-Aufruf, aber wäre es denn so schlimm, wenn der Compiler diese Fehler offen im Quelltext korrigieren würde, statt im Verborgenen Methodenaufrufe zu synthetisieren und nachher wegzuoptimieren?

Da fällt mir ein:
Mir ist schon mehrfach aufgefallen, dass Xcode sich bei neuen Projekten nicht so wirklich darum schert, wenn man kein ARC möchte - das Template geht trotzdem direkt mit einem @autorelease los. Hat dazu schon jemand einen Bugreport verfasst?

Ich bin fortgeschritten und spare jede Menge Code an ARC. Was mache ich falsch?

Mir scheint es eher so zu sein, dass das Unbekannte unbeherrscht bleibt, weil man mit dem Bekannten zurecht kommt. Diese Diskussion gab es schon bei der Einführung von C, bei der Einführung der OOP, … Nichts scheint mir so konservativ zu sein, wie ein ITler.

Dein letzter Absagt lässt mich allerdings zweifeln, dass du die Dokumentation zu ARC durchgearbeitet hast. ARC ist RC und benötigt daher genau so einen ARP wie MRC, sogar für exakt diesselbe Problemstellung. Da gibt es keinen Unterschied zwischen ARC und MRC.

little_pixel · 14. Oktober 2012, 13:56

Mal eine primitive Frage so zwischenrein:

Wird sich ARC durchsetzen, oder wird es auch verwaisen wie Garbage Collection?

Mir ist schon klar, dass das eine andere Welt ist und als solches nicht vergleichbar ist.

Viele Grüße

Amin Negm-Awad · 14. Oktober 2012, 13:57

Thallius schrieb:

Ich mache gerade mein erstes größeres Projekt in ARC und ich muss sagen ich sehe die große Erleichterung einfach nicht. Wenn ich konsequent meine retain/copy properties mit self.property initialisiere und zuweise und im dealloc oder eben im viewDidUnload oder wo auch immer es wichtig ist direkt beim Anlegen der Property auch den self.property=nil eintippe, dann kann mir nichts passieren.

Das ist also eine Zeile mehr tippen, dafür habe ich die komplette Kontrolle.

Gruß

Claus

Wenn du genau das machst, was der Compiler macht, hast du mehr Kontrolle als der Compiler? Weil du es anders, also falsch machen könntest? Du hast also die Kontrolle, Fehler zu machen?

Hmmmm …

Amin Negm-Awad · 14. Oktober 2012, 13:58

little_pixel schrieb:

Mal eine primitive Frage so zwischenrein:

Wird sich ARC durchsetzen, oder wird es auch verwaisen wie Garbage Collection?

Mir ist schon klar, dass das eine andere Welt ist und als solches nicht vergleichbar ist.

Viele Grüße

Ich habe ja seinerzeit im Buch vorhergesagt, dass sich GC nicht durchsetzen wird. Und damit Recht behalten.

Ich sage in der neuen Auflage vorher, dass sich ARC durchsetzen wird. Und damit werde ich sicher Recht behalten.

macmoonshine · 14. Oktober 2012, 15:32

Amin Negm-Awad schrieb:

Ich sage in der neuen Auflage vorher, dass sich ARC durchsetzen wird. Und damit werde ich sicher Recht behalten.

Davon bin ich auch überzeugt. Wo ist der nächste Buchmacher?

t-no · 14. Oktober 2012, 19:24

Amin Negm-Awad schrieb:

Ich bin fortgeschritten und spare jede Menge Code an ARC. Was mache ich falsch?

Nichts - aber dann musstest du vielleicht auch schon mit __bridge und Co arbeiten.
Findest du, dass das elegant gelöst ist?
Bis vor einiger Zeit war es ja so, dass Apple das Unterstrich-Prefix für Dinge reserviert hat, von denen man nach Möglichkeit die Finger lässt - mein persönlicher Eindruck ist aber, dass es zusehends normal wird, auf dieser Ebene zu programmieren.

Sonderlich nostalgisch bin ich übrigens nicht - mir wäre es sogar lieber, wenn Apple zusätzlich eine komplett neue Sprache etablieren würde statt an wesentlichen Elementen von Objective-C herumzubasteln (aber dafür ist es wahrscheinlich ohnehin schon zu spät - und es wird imho auch verdammt schwierig, eine Sprache zu kreieren, welche die Vorzüge von C so gut mit modernen Konzepten kombiniert).

Amin Negm-Awad · 14. Oktober 2012, 22:12

t-no schrieb:

Amin Negm-Awad schrieb:

Ich bin fortgeschritten und spare jede Menge Code an ARC. Was mache ich falsch?

Nichts - aber dann musstest du vielleicht auch schon mit __bridge und Co arbeiten.
Findest du, dass das elegant gelöst ist?

Ich finde es richtig gelöst. ARC is for objects. void* ist nicht ein Pointer auf ein Objekt. Die Konsequenz ist klar und hätte ich mutmaßlich ebenso gelöst.

t-no schrieb:

Bis vor einiger Zeit war es ja so, dass Apple das Unterstrich-Prefix für Dinge reserviert hat, von denen man nach Möglichkeit die Finger lässt - mein persönlicher Eindruck ist aber, dass es zusehends normal wird, auf dieser Ebene zu programmieren.

1. Apple hatte Unterstrichpräfixe für /eigene/ Bezeichner, insbesondere Instanzvariablen, verboten. Ich habe bereits in der ersten Auflage vor gefühlten 123812398 Jahren geschrieben, dass Apples Gedanke da Quatsch ist. Ich habe dafür sogar ziemlich viel Prügel im Internet kassiert, weil viele Leute lieber nachplapperten als selbst nachzudenken. Das hat Apple inzwischen aufgegeben (quelle surprise, lesen die meine Bücher?).
2. Bei __bridge handelt es sich um ein /fremdes/ Schlüsselwort. Appliger geht es nicht, weshalb es kein Verstoß gegen die Regel ist.
3. In C ist es üblich, dass derlei Schlüsselwörter mit Unterzügen beginnen. Apple hält sich da also nur an den Standard.

Mit Ebenen hat das nichts zu tun.

t-no schrieb:

Sonderlich nostalgisch bin ich übrigens nicht - mir wäre es sogar lieber, wenn Apple zusätzlich eine komplett neue Sprache etablieren würde statt an wesentlichen Elementen von Objective-C herumzubasteln (aber dafür ist es wahrscheinlich ohnehin schon zu spät - und es wird imho auch verdammt schwierig, eine Sprache zu kreieren, welche die Vorzüge von C so gut mit modernen Konzepten kombiniert).

Es wird nicht an wesentlichen Komponenten herumgebastelt. Fast alle Änderungen der letzten Jahre sind Syntactic-Sugar. Auch ARC ist nichts anderes als die Anwendung der ohnehin bekannten Regeln von MRC. (Nur konsequent, was manchen Fehler beseitigt, den man schon immer machte.)

Amin Negm-Awad · 14. Oktober 2012, 22:17

macmoonshine schrieb:

Amin Negm-Awad schrieb:

Ich sage in der neuen Auflage vorher, dass sich ARC durchsetzen wird. Und damit werde ich sicher Recht behalten.

Davon bin ich auch überzeugt. Wo ist der nächste Buchmacher? ;) :D

Ich glaube nicht, dass jemand gegenhält.

Ich habe sogar in der neuen Auflage die Entscheidung getroffen, das Grundprinzip von RC im ARC-Teil zu besprechen und dann einen MRC-Teil hinterzuschieben nach dem Motto: "Und so macht man es selbst!" Also ganz klare Schwerpunktsetzung pro ARC.

Mich würde das außerordentlich überraschen. Zumal eine von mir durchgeführte Analyse zu Internetbeiträgen "ScheiseARC" gezeigt hat, dass die Leute sämtlich bereits unter MRC Fehler im Code hatten und ihnen das jetzt nur auffällt. Die haben aus Angst bestimmt nie den Static-Analyzer angeschmissen.

macmoonshine · 14. Oktober 2012, 23:13

Amin Negm-Awad schrieb:

Ich glaube nicht, dass jemand gegenhält.

Mist, und ich damals schon keine Apple-Aktien gekauft.

Amin Negm-Awad schrieb:

Mich würde das außerordentlich überraschen. Zumal eine von mir durchgeführte Analyse zu Internetbeiträgen "ScheiseARC" gezeigt hat, dass die Leute sämtlich bereits unter MRC Fehler im Code hatten und ihnen das jetzt nur auffällt. Die haben aus Angst bestimmt nie den Static-Analyzer angeschmissen.

So ähnlich ist ehrlich gesagt auch mein Eindruck; dieses Festhalten an MRC hört sich immer so nach einem Geheimwissen an, an dem festgehalten wird, weil man sich damit vom Plebs abhebt.

Amin Negm-Awad · 15. Oktober 2012, 08:17

macmoonshine schrieb:

Amin Negm-Awad schrieb:

Ich glaube nicht, dass jemand gegenhält.

Mist, und ich damals schon keine Apple-Aktien gekauft. ;)

Amin Negm-Awad schrieb:

Mich würde das außerordentlich überraschen. Zumal eine von mir durchgeführte Analyse zu Internetbeiträgen "ScheiseARC" gezeigt hat, dass die Leute sämtlich bereits unter MRC Fehler im Code hatten und ihnen das jetzt nur auffällt. Die haben aus Angst bestimmt nie den Static-Analyzer angeschmissen.

So ähnlich ist ehrlich gesagt auch mein Eindruck; dieses Festhalten an MRC hört sich immer so nach einem Geheimwissen an, an dem festgehalten wird, weil man sich damit vom Plebs abhebt.

Jepp, programmieren als Männlichkeitsbeweis.

Ich habe gerade auch einen Kunden, der besonders komplizierte und dann auch hinreichend häufig antikonzeptionelle Lösungen für ganz toll hält. Tatsächlich ist es eine ziemliche Katastrophe.

lavendelHonig · 15. Oktober 2012, 08:26

Ich habe sogar in der neuen Auflage die Entscheidung getroffen, das Grundprinzip von RC im ARC-Teil zu besprechen und dann einen MRC-Teil hinterzuschieben nach dem Motto: "Und so macht man es selbst!" Also ganz klare Schwerpunktsetzung pro ARC

Freu mich drauf und hoffentlich ist es bald da.

Ich verwende SB und ARC seit offizieller Freigabe und bemühe mich vorher sehr arg bevor ich schimpfe. Deshalb schimpfe ich derzeit nur über das neue Autolayout und immer dann, wenn etwas vorher einfacher zu bewerkstelligen war (also nicht gewohnter) und jetzt verkomplizierter wurde, kann ich gar nicht so falsch liegen.

SB ist ne tolle Sache, ARC funktioniert erstaunlich gut, __bridge stört mich die paar mal gar nicht und hauptsächlich interessiert mich das, was ich auf dem Screen sehe und wie gut meine Mädels und ich damit klar kommen.

Liebe Grüße und eine tolle Woche für alle lieben Menschen hier
Karin

Amin Negm-Awad · 15. Oktober 2012, 08:34

Autolayout ist unbeliebt. Aber es ist ziemlich mächtig, wenn man es verstanden hat.

Das Grundproblem beim Verständnis scheint mir darin zu liegen, dass die generierten Constraints unnötig kompliziert und unintuitiv sind. Ich setze daher immer zunächst die offensichtlichen von Hand, um die generierten loszuwerden. Ich meine aber auch, dass es schon besser geworden sei. Ich habe daraus aber keine historische Arbeit gemacht.

macmoonshine · 15. Oktober 2012, 08:57

lavendelHonig schrieb:

Deshalb schimpfe ich derzeit nur über das neue Autolayout und immer dann, wenn etwas vorher einfacher zu bewerkstelligen war (also nicht gewohnter) und jetzt verkomplizierter wurde, kann ich gar nicht so falsch liegen.

Wenn Du es (noch) nicht verwenden willst, kannst Du es doch auch über den Dateiinspektor ausschalten.

lavendelHonig · 15. Oktober 2012, 09:39

macmoonshine schrieb:

lavendelHonig schrieb:

Deshalb schimpfe ich derzeit nur über das neue Autolayout und immer dann, wenn etwas vorher einfacher zu bewerkstelligen war (also nicht gewohnter) und jetzt verkomplizierter wurde, kann ich gar nicht so falsch liegen.

Wenn Du es (noch) nicht verwenden willst, kannst Du es doch auch über den Dateiinspektor ausschalten.

Na ja, nicht wirklich.
Ich habe Ansichten die liegen nunmal Landscape und welche die liegen Porträt. Das Gefrickel der Einstellung ist einfach nur dämlich, ich bin es sowieso.
Basismethode dafür mal eben so entfernt, man ist ja Apple, und nun geht es los. Problem gelöst, Lösung entfernt und neue Baustelle aufgemacht.

Aber das ist ein anderes Thema und durchaus zeitgemäß. Irgendein Irrer muss sich ja immer in den Vordergrund drängen und aus Lösungen neue Probleme basteln. Zeitgeist halt

Liebe Grüße
Karin

Thallius · 15. Oktober 2012, 10:26

Naja auch ohne Autorisizing war es schon möglich Ansichten in Portrait und Landscape zu machen

Die sauberste Lösung für komplexe UIs ist und bleibt es eh für beide Ansichten ein eigenes View zu erstellen. Leider unterstüzt der IB das immer noch überhaupt nicht und man sieht immer beide Views gleichzeitig (Würde ja schon reichen wenn der IB Hidden Views wirklich hiden würde)

Als Tipp für das Autorisizing kann ich nur gegben. Bevor du das erste Elemtn in das UI ziehst erst einmal das Autosizing ausschalten. Dann alle Elemente einfügen und anordnen. Dann das Resitzing einschalten. Dann hast man die "sauberste" Ausgangsposition für die Constraints. Wenn man jetzt das View im IB resized sieht man schön welche Elemente noch nicht so reagieren wieman möchte und man kann geziehlt diese noch einmal anfassen und kurz hin- und herverschieben, so das die richtigen Constraints gesetzt werden.

Gruß

Claus

lavendelHonig · 15. Oktober 2012, 10:47

Thallius schrieb:

Naja auch ohne Autorisizing war es schon möglich Ansichten in Portrait und Landscape zu machen

Und dafür gab es eine wunderbare Methode, die man sang und klanglos einfach so mal out of order gesetzt hat. Wäre ja auch zu einfach gewesen. :evil:

Ich kann da nur den Kopf schütteln und einfach weiter machen. Mehr geht nicht.

Danke für die Tipps, werde ich nachher angehen, jetzt muss ich erstmal an meinem dicken fetten "NSCompoundPredicate" schrauben. Tolle Geschichte.

Liebe Grüße
Karin

Thallius · 15. Oktober 2012, 10:58

lavendelHonig schrieb:

Thallius schrieb:

Naja auch ohne Autorisizing war es schon möglich Ansichten in Portrait und Landscape zu machen

Und dafür gab es eine wunderbare Methode, die man sang und klanglos einfach so mal out of order gesetzt hat. Wäre ja auch zu einfach gewesen.

Liebe Grüße
Karin

Wie kommst Du denn jetzt darauf ? Wenn du im FileInspector das Autoresizing ausschaltest kannst Du wunderbar genauso mit der Autoresizingmask arbeiten wie früher.

Gruß

Claus