Original von longW
Sie sind unzweifelhaft Bestandteil der Norm, da gebe ich Dir Recht.
Und damit integraler Bestandteil der Sprache.
Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen
Original von longW
Sie sind unzweifelhaft Bestandteil der Norm, da gebe ich Dir Recht.
Original von tjp
Original von longW
Und deswegen reicht es bei Cocoa aus, die eine Dokumentation von Apple zu lesen. Die gilt für alle von Apple verfügbar gemachten Implementierungen.
Ja wirklich? Seit wann kann man ein beliebiges Cocoa Programm ohne Änderungen am Sourcecode direkt gegen GNUstep compilieren?
Original von longW
Du liest zwar viel, aber nicht genau genug. Habe ich behauptet, das ich Quellen nicht ändern möchte?
kmr schrieb:
Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
Original von Lucas de Vil
Mir persönlich isses wurscht, da ich nach wie vor der Meinung bin Plattformunabhängigkeit in Bezug auf das Betriebssystem hilft zwar dem Entwickler, schadet aber dem Anwender.
Original von Lucas de Vil
Wenn ich mich mal einmischen darf: so wie ich die Sache sehe, geht die gesamte Diskussion um das Fehlen einer Standardbibliothek einzig und allein darum, dass ich egal für welches Betriebssystem grundlegende Komponenten wie beispielsweise Maps/Dictionarys und Strings ohne eine einzige Anpassung am Code nutzen kann.
Original von Lucas de Vil
STL macht es da einfach, weil der ganze Krams da drin zusammengefasst wurde und es einfach mit C++ fest verwoben ausgeliefert wird. Umstellungsprobleme gibt es dann nur wenn irgendwelche externen Bibliotheken geändert wurden. Dennoch sind Maps und Strings immer identisch gegeben.
Original von Lucas de Vil
Cocoa/GNUStep macht es etwas komplizierter, da hier wirklich alles drin hängt. Ich kann meine Anwendung nicht in Core-ObjC klöppeln und mich dann für die GUI für ein Framework 'Cocoa', 'GNUStep' oder 'QuantumSTEP' entscheiden. Hier hängt alles ineinander zusammen, nicht bloß die Kernfunktionalität. Selbst wenn hier NSString, NSArray und NSDictionary immer gegeben sind, so muss ich zumindest die Imports anpassen.
Original von tjp
Original von Amin Negm-Awad
Natürlich gibt es kein Dokument. Und? Das heißt doch nicht, dass ich erblinde. Es geht auch nicht um alle verfügbaren Fälle. Es geht um GNUStep. Wieso baust du dir eine Situation, die nicht existiert?
So existiert doch! Eine beliebige Cocoa Anwendungen ist nicht portabel, da GNUstep eben nicht 100% der Cocoa Funktionalität abdeckt. Wenn Du das nicht siehst bist Du wirklich blind.
Original von tjp
Original von longW
Und deswegen reicht es bei Cocoa aus, die eine Dokumentation von Apple zu lesen. Die gilt für alle von Apple verfügbar gemachten Implementierungen.
Ja wirklich? Seit wann kann man ein beliebiges Cocoa Programm ohne Änderungen am Sourcecode direkt gegen GNUstep compilieren?
Original von tjp
Original von Lucas de Vil
Wenn ich mich mal einmischen darf: so wie ich die Sache sehe, geht die gesamte Diskussion um das Fehlen einer Standardbibliothek einzig und allein darum, dass ich egal für welches Betriebssystem grundlegende Komponenten wie beispielsweise Maps/Dictionarys und Strings ohne eine einzige Anpassung am Code nutzen kann.
Soweit richtig
Original von tjp
Original von Lucas de Vil
STL macht es da einfach, weil der ganze Krams da drin zusammengefasst wurde und es einfach mit C++ fest verwoben ausgeliefert wird. Umstellungsprobleme gibt es dann nur wenn irgendwelche externen Bibliotheken geändert wurden. Dennoch sind Maps und Strings immer identisch gegeben.
Streiche STL und setze C++ Standard Library, die C++ Standard Library erhält deutlich mehr Funktionalität als nur die übernommenen Teile der STL.
Original von Lucas de Vil
Cocoa/GNUStep macht es etwas komplizierter, da hier wirklich alles drin hängt. Ich kann meine Anwendung nicht in Core-ObjC klöppeln und mich dann für die GUI für ein Framework 'Cocoa', 'GNUStep' oder 'QuantumSTEP' entscheiden. Hier hängt alles ineinander zusammen, nicht bloß die Kernfunktionalität. Selbst wenn hier NSString, NSArray und NSDictionary immer gegeben sind, so muss ich zumindest die Imports anpassen.
Nein
- Eine Standard Library ist kein Framework zur Applikationsentwicklung
- Es gab früher einmal Openstep for Mach x86 und 68k (Nachfolger von NEXTSTEP für HP-PA, SPARC, 68k und x86), Openstep for Windows und Openstep for Solaris.
[/list=1]
Früher war es möglich einmal ein Openstep Programm zu entwickeln und auf alle Plattformen zu portieren durch ein simplen Recompile. Bis auf die Windows Version sah auch alles immer gleich aus und funktionierte auch gleich. Auch die Solaris Version sah und fühlte sich nicht anders an als echtes Openstep for Mach. Man konnte beim Einloggen sich für den OPEN LOOK, CDE oder Openstep Desktop entscheiden. Das alles war zwar kommerziell, aber für den zahlungsbereiten Profi gab es Möglichkeiten die Anwendungen einfach und kostengünstig auf allen Plattformen anzubieten. Apple hat diese Möglichkeiten entsorgt.
GNUstep und Cocoa sind nun einmal nicht identisch, sondern GNUstep ist ein freier Clone von Cocoa und hinkt daher dem Original immer hinterher. Man weiß daher nie mit Sicherheit was denn nun wirklich zu 100% funktioniert. Bestenfalls kann man unter GNUstep Software entwickeln und nach Cocoa portieren. Aber spätestens bei Multimedia Ansätzen kann man auch das Vergessen.
[/quote]
Was Du alles weisst! Du hast bestimmt unter OpenStep schon alles rauf und runter kompliert.
Sicherlich warst Du auch '14-'18 dabei.
[quote]Original von tjp
Das alles wäre noch nicht einmal so schlimm, wenn Cocoa sich besser mit anderen Programmiersprachen vertragen würde.
[/quote]
Mit welchen denn? Und warum?
Wie schon gesagt, für Dich sind Äpfel und Birnen immer Obst. Dann hat man mit Pflaumen und Kirschen auch keine Probleme.
Also gibt es auch keinen Pflaumenkuchen oder Kirschtorte, sondern nur Obstgebäck.
Das erinnert mich an das appetitanregende Konzept der Sättigungsbeilagen.
[quote]Nur das ist nicht der Fall. So wird es schwierig um einen bestehenden Applikationskern ein GUI für MacOS X zu bauen, mit Carbon war das sehr viel einfacher. Das macht die Portierung von Software auf MacOS X zusätzlich teurer. Objective-C++ ist wirklich keine Hilfe, da es zu einem anachronistischen C++ Programmierstil zwingt der etwa auf dem Niveau von C with Classes ist.
[/quote]
Da hast Du Recht, Objective-C++ ist anachronistisch.
Das Niveau kann ich nicht beurteilen, sicherlich nicht meines.
[quote][quote]Original von Lucas de Vil
Mir persönlich isses wurscht, da ich nach wie vor der Meinung bin Plattformunabhängigkeit in Bezug auf das Betriebssystem hilft zwar dem Entwickler, schadet aber dem Anwender.[/quote]
Plattformunabhängigkeit verringert drastisch den Wartungsaufwand und damit die Entwicklungskosten, und wenn man den Applikationskern isolieren kann fällt das im GUI noch nicht einmal auf.[/quote]
Also den kleinsten gemeinsamen Nenner mit dem alleinstellenden Merkmal: möglichst klein!
Fangen wir doch mit der Bildschirmauflösung an, bevor wir uns in technischen Details verlieren.
Das Schöne ist, dass Du es nicht nur nicht begreifen willst, sondern tatsächlich nicht kannst. Dein Paradigma greift nicht.
kmr schrieb:
Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
Original von Lucas de Vil
Nu steig ich gar nicht mehr durch.
Und das liegt nicht an der Uhrzeit.
Original von longW
Original von Lucas de Vil
Nu steig ich gar nicht mehr durch.
Und das liegt nicht an der Uhrzeit.
Dann hast Du es ja begriffen.
kmr schrieb:
Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
Original von tjp
Original von Lucas de Vil
Wenn ich mich mal einmischen darf: so wie ich die Sache sehe, geht die gesamte Diskussion um das Fehlen einer Standardbibliothek einzig und allein darum, dass ich egal für welches Betriebssystem grundlegende Komponenten wie beispielsweise Maps/Dictionarys und Strings ohne eine einzige Anpassung am Code nutzen kann.
Soweit richtig
Original von tjp
Original von Lucas de Vil
STL macht es da einfach, weil der ganze Krams da drin zusammengefasst wurde und es einfach mit C++ fest verwoben ausgeliefert wird. Umstellungsprobleme gibt es dann nur wenn irgendwelche externen Bibliotheken geändert wurden. Dennoch sind Maps und Strings immer identisch gegeben.
Streiche STL und setze C++ Standard Library, die C++ Standard Library erhält deutlich mehr Funktionalität als nur die übernommenen Teile der STL.
Original von tjp
Original von Lucas de Vil
Cocoa/GNUStep macht es etwas komplizierter, da hier wirklich alles drin hängt. Ich kann meine Anwendung nicht in Core-ObjC klöppeln und mich dann für die GUI für ein Framework 'Cocoa', 'GNUStep' oder 'QuantumSTEP' entscheiden. Hier hängt alles ineinander zusammen, nicht bloß die Kernfunktionalität. Selbst wenn hier NSString, NSArray und NSDictionary immer gegeben sind, so muss ich zumindest die Imports anpassen.
Nein
- Eine Standard Library ist kein Framework zur Applikationsentwicklung[/Quote]
Na, also, geht doch.
[quote]Original von tjp- Es gab früher einmal Openstep for Mach x86 und 68k (Nachfolger von NEXTSTEP für HP-PA, SPARC, 68k und x86), Openstep for Windows und Openstep for Solaris.
[/list=1] [/Quote]
Und jetzt gibt es GNUStep.
Dir ist schon klar, dass GNUstep openstep-vollständig ist?
[quote]Original von tjp
Früher war es möglich einmal ein Openstep Programm zu entwickeln und auf alle Plattformen zu portieren durch ein simplen Recompile. Bis auf die Windows Version sah auch alles immer gleich aus und funktionierte auch gleich.[/Quote]
Also funktionierte es auf Linux wie Openstep, nicht wie Linux?
Also funktionierte es auf Windows wie Openstep, nicht wie Windows?
Also funktionierte es auf $system wie Openstep, nicht wie $system?
Das ist sinnvoll, verhält es sich in meinem Arbeitsalltag doch so, dass ich dieselbe Anwendung auf ganz vielen Systemen benutze. Oder doch eher ganz viele Anwendung auf demselben System?
Hmmmmmm, welche Einheitlichkeit sollte man da wohl fördern?
[quote]Original von tjp
Auch die Solaris Version sah und fühlte sich nicht anders an als echtes Openstep for Mach. Man konnte beim Einloggen sich für den OPEN LOOK, CDE oder Openstep Desktop entscheiden. Das alles war zwar kommerziell, aber für den zahlungsbereiten Profi gab es Möglichkeiten die Anwendungen einfach und kostengünstig auf allen Plattformen anzubieten. Apple hat diese Möglichkeiten entsorgt.
GNUstep und Cocoa sind nun einmal nicht identisch, sondern GNUstep ist ein freier Clone von Cocoa[/Quote]
Nope, GNUstep implementiert Openstep vollständig. Und Clone stimmt ohnehin nicht.
[quote]Original von tjp
und hinkt daher dem Original immer hinterher. [/Quote]
So wie jede Erweiterung in der C++-Welt dem Standard.
[quote]Original von tjp
Man weiß daher nie mit Sicherheit was denn nun wirklich zu 100% funktioniert. Bestenfalls kann man unter GNUstep Software entwickeln und nach Cocoa portieren. Aber spätestens bei Multimedia Ansätzen kann man auch das Vergessen.[/QUote]
Schmarren, was funktioniert, sagt die GNUstep ganz genau.
[quote]Original von tjp
Das alles wäre noch nicht einmal so schlimm, wenn Cocoa sich besser mit anderen Programmiersprachen vertragen würde. Nur das ist nicht der Fall.[/Quote]
Und das ist gut, etwas anderes wäre schlimm, nämlich, wenn sich Cocoa mit dem statischen C++ vertragen würde. Es wäre dann nicht mehr Cocoa. Das Ding ist für Anwendungsentwicklung, wofür C++ völlig ungeeignet ist.
[quote]Original von tjp
So wird es schwierig um einen bestehenden Applikationskern ein GUI für MacOS X zu bauen, mit Carbon war das sehr viel einfacher. Das macht die Portierung von Software auf MacOS X zusätzlich teurer. Objective-C++ ist wirklich keine Hilfe, da es zu einem anachronistischen C++ Programmierstil zwingt der etwa auf dem Niveau von C with Classes ist.[/Quote]
Jede Art der C++-Verwendung zwingt zu einem völlig anachronistischen Programmierstil.
[quote]Original von tjp
[quote]Original von Lucas de Vil
Mir persönlich isses wurscht, da ich nach wie vor der Meinung bin Plattformunabhängigkeit in Bezug auf das Betriebssystem hilft zwar dem Entwickler, schadet aber dem Anwender.[/quote]
Plattformunabhängigkeit verringert drastisch den Wartungsaufwand und damit die Entwicklungskosten, und wenn man den Applikationskern isolieren kann fällt das im GUI noch nicht einmal auf.[/quote]
Wenn man den Applikationskern isolieren kann, verwendet man für den einfach kein Cocoa.
Allerdings glaube ich schon, dass es auffällt, wenn man etwa kein Observing hat. Dann hat man wieder diese schönen Okay-Buttons.