|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > C oder C++? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| 1 2 3 4 -5- | [ - Beitrag schreiben - ] |
|
30.05.2010, 22:11 Uhr Der_Wanderer Posts: 1229 Nutzer |
Die Stabilität ist schon gewährleistet. Man lässt ja nicht jeden x-beliebigen Progger Änderungen einchecken. Und per Versioncontrolle kann man immer genau sehen, wer was gemacht hat und ggf. wieder Rückgängig machen. Wie gesagt, die Entwickler einer solchen API sollten erfahrene Leute sein. > der "Unnütze Mehraufwand" tritt nur EINMAL auf! Der tritt für jeden Entwickler mindestens einmal auf. Jeder Entwickler löst das ein wenig anders, je nach Kentnisstand, Gesinnung und Zeit. > es mag einfach sein, Loadimage{} zu ändern, aber sind da nicht noch > viel mehr verstreute Sprengsel in all den vielen Includes? Wie meinst du das? Alle weiteren Inlcudes, die Bilder laden, tun das über die image.include. Einmal gefixed, geht es überall. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
30.05.2010, 22:40 Uhr inq Posts: 445 Nutzer |
Zitat:du meinst wahrscheinlich Kontrolle der Stabilität ist gewährleistet  und auch das trifft natürlich nur auf die aktuelle Distri zu. Was ich meinte, ist aber die "Gefahr", daß ein "Befehl" in einem Src nicht mehr unbedingt immer und überall dasselbe Resultat liefert. Der Coder, der z.B. seinen Code oder das Prog veröffentlicht, könnte z.b. in der imageinclude irgendwo alles auf maximal 8bit geändert haben. das wird sich niemals in der Distri widerspiegeln (kann und will ja nicht jeder beitragen). bei DType ist das Resultat sowieso extrem von den Umständen abhängig, deshalb sollte das nur ein Bsp sein. Zitat:Meine Anwort auf das Standard-Gemecker des Coders, warum "ich so verdammt viele checks für alles einbauen soll" hast du nicht wirklich angenommen: TU ES!! Der Mehraufwand IST ES WERT! (Es ging ja ursprünglich um eine API, also MUSS es sein). Im Übrigen ist es eine sinnlose Annahme, es gäbe "nie" einen Bug in einer API. oder sonstwo. Weil es niemand weiß. Ist unbestimmte Zukunft. Zitat:Weiß ich nicht, ob das so stringent implementiert ist. Aber ich vermutete einfach, da sind noch andere Incs involviert, z.b. für irgendeine Dos.include oder file.include oder mem.include oder so. gruß inq [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2010, 10:44 Uhr Der_Wanderer Posts: 1229 Nutzer |
@inq: Ja klar, wer am Source was verändert muss logischerweise mit den Konsequenzen leben. Wobei in dem Falle wie ich ihn beschrieben habe die API als Libraries beim User liegen, also nicht als Source jedesmal einkompiliert werden. > Meine Anwort auf das Standard-Gemecker des Coders, warum "ich so verdammt viele checks für alles einbauen soll" hast du nicht wirklich angenommen: Habe ich was nicht gelesen? Hm, klar, alles muss man checken was irgendwie schief gehen kann. > Im Übrigen ist es eine sinnlose Annahme, es gäbe "nie" einen Bug in einer API. Habe ich ja nicht behauptet. Es gibt sogar studien die in etwa berechnen, pro x Zeilen Code werden y Bugs eingeführt. Hängt natürlich von vielen Faktoren ab. > Aber ich vermutete einfach, da sind noch andere Incs involviert, z.b. > für irgendeine Dos.include oder file.include oder mem.include oder so. Ja klar. Ich erfinde in der image.include ja nicht den file i/o neu etc. Die Amiblitz Includes sind in Schichten angeordnet. Z.b. unter der Image.include liegen die Includes für einzelne Fileformate, z.b. png.inlcude, bmp.inlcude und iff-ilbm.include. Die wiederum nutzen die file.include für file i/o. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2010, 13:17 Uhr Thore Posts: 2266 Nutzer |
Öhm, ist es nicht normal daß man Checks einbauet ob ein Objekt alloziiert ist, die Grenzen in Zeichenflächen eingehalten werden und dergleichen? Man sollte generell so programmieren, nicht nur in diesen APIs. Da erspart man sich die eine oder andere Fehlersuche von vornherein... [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2010, 20:39 Uhr Holger Posts: 8116 Nutzer |
Zitat:Ehrlich gesagt, widerstrebt es mit gehörig, "inoffiziell", also für lau, Arbeit zu machen, die dann "offiziell gehosted" wird, sprich, von der dann die Firma, die eben jene Arbeit nicht macht, direkt, auch finanziell, profitiert. Es gibt eigentlich nur drei Szenarien, die aus der Misere führen könnten: 1. die "offiziellen" machen etwas für das Geld, das sie verdienen wollen 2. die "offiziellen" unterstützen eine sinnvolle Entwicklung mit mehr als nur 'nem "offiziell unterstützt"-Adelstitel 2. die "offiziellen", sprich gewinnorientierten, verschwinden endgültig von der Bildfläche Zitat:Kannst Du auch mal Belege für Deine Theorie, Highlevel bedeute zwangsläufig schlechte Performance, bzw. mit den alten APIs würden alle Entwickler automatisch die Lowlevel-Funktionen zur Optimierung nutzen, bringen? Schau Dir doch mal MUI an: die normale MUI-Anwendung interessiert sich nicht die Bohne dafür, ob die eingebetteten Icons 24 Bit TrueColor oder 8 Bit Planar sind oder ob die Buttons nun mit Farbverläufen gefüllt sind oder nicht. Und auch bei 99% aller GUI-Anwendungen, die kein Toolkit wie MUI benutzen, wird nicht für einen planaren oder truecolor Bildschirm optimiert. Und "performanter" sind nur die Anwendungen, die Fenster fester Größe mit topaz/80 öffnen, na danke. Zitat:Das glaubt doch ohnehin keiner. Zitat:Ist doch schön, sollen sie sich mal alle austoben. Ist auch kein Problem, wenn man bei einem der beiden Systeme die Funktionstabellen der Libraries erst noch via "GetInterface" holen muss. Wenn es einfach ein Highlevel-API geben würde, bei dem man beispielsweise "Drucke RAM:foo.txt" sagen könnte. Zitat:Ich sehe da eigentlich eher den zwanghaft-manische Wunsch einer einzelnen Person, diesen Wunsch nach Ausweitung den anderen in den Mund zu legen. Zitat:Ja genau. Drei unterschiedliche Teams beschäftigen sich damit, eine 1:1 Kopie eines OS aus den achtziger Jahren mit ein paar minimalen Verbesserungen und etwas Eye-Candy zu entwickeln, aber dann soll ein einzelner als einziger konzeptionelle Arbeit liefern, natürlich gleich mit vollständiger Implementierung, die so überzeugend ist, das möglichst alle Anhänger, die sich über die Wahl eines der drei Betriebssysteme uneinig sind, sich bei diesen Bibliotheken einhellig positiv äußern, obwohl diese bislang nicht den offiziellen Stempel tragen. Klar, da stimme ich Dir vollkommen zu. Wenn das vollbracht wurde, wäre der Druck tatsächlich hoch genug, dass alle drei OS-Entwickler diese Arbeit bereitwillig für lau abgreifen, äh... übernehmen und als "offiziell" adeln würden. Wobei...100% sicher bin ich mit doch nicht, dass nicht der eine oder andere Anhänger von Reduktion auf Low-Level Schnittstellen ein Haar in der Suppe finden würde. Zitat:Ob sinnvoller oder nicht, sei mal dahingestellt. Beide Ansätze, eine IDE, die den nötigen Code erzeugt, oder eine Bibliothek, die den nötigen Code beinhalten, erfordern, dass es jemand implementiert und dass es von den anderen als sinnvoller Weg akzeptiert wird. Eine normale Vorgehensweise wäre, die Implementierung in einer Bibliothek zu kapseln und dann eine IDE zu entwickeln, die diesen Code nutzen und automatisieren kann. Zitat:Ja, das ist schon gut, dass die Funktion, die man, wie schon gesagt, in 99% der Fälle gar nicht braucht, schon gibt. Jetzt muss man nur noch die Funktionen implementieren, die man in 99% der Fälle eigentlich braucht. Zitat:Das mag beim C64 zutreffen, aber nicht beim AmigaOS, dass die bereits Funktionen vorsetzt, deren interne Funktionsweise nicht dokumentiert und in AOS3, AOS4, MOS und Aros anders implementiert sind. Die in einem Multitasking-System und auf völlig unterschiedlicher Hardware arbeiten, usw. usf. Alles über das "High Level API" gesagte trifft bereits auf AmigaOS selbst zu. Allerdings können noch höher angesiedelte Funktionen auch bekannte Bugs und "merkwürdige Verhaltensweisen" wieder kompensieren, bzw. auf unterschiedlichen Systemen besser im Sinne des Systems implementiert werden, da wesentlich mehr über die Intention des Anwenders bekannt ist. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
31.05.2010, 22:28 Uhr Der_Wanderer Posts: 1229 Nutzer |
Da kann ich Holger nur zustimmen. Eine High-Level API muss nicht zwangsläufig langsamer sein als das gleiche per Low-Level API implementiert. Das gilt nur, wenn man gleich gut oder besser programmieren kann als die API Programmierer UND genauso viel Zeit investieren kann. (oder die HL API das nicht elegant lösen kann). In der Regel kann man aber in eine individual Implementation weniger Zeit investieren als in wiederverwertbaren Code. Es gibt genügend Beispiele, wo z.B. ein einmal sauber implementierter TextView wesentlich bessere und performantere Ergebnisse produziert hätte als ein wildes Text() Geraffel, was immer alles neu zeichnet an vielen Stellen im Code, weil keine Zeit war sich beispielsweise mit Damage Regions und Layern auseinanderzusetzen. Oder ein Insertsort implementiert wurde weil keine Zeit/Wissen für ein Quicksort da war. Optimierungen kann man in folgendes 4-Schichten Modell einteilen: 1. Konzeptionelle Schicht 2. Algorithmische Schicht 3. Ausführungsschicht 4. Hardware Schicht Die Mächtigkeit nimmt von 1. an ab bis zu 4. Viele empfinden das gerade andersherum. Das sind die, die sich nicht mit Komplexitätslehre beschäftigt haben. Eine kurze Erleuterung: 4. Hardware Schicht ist wie schnell die Maschine das Program ausführt. Da können wir erstmal nicht viel dran drehen als Software Entwickler. 3. Ausführungsschicht Hier geht es darum, möglichst schnellen Code zu generieren. Durch die Wahl des Compilers, Sprache, aber auch Tricksereien wie Bitshiften, Register Variablen etc. Hier verliert die HL API etwas, da mindestens ein JUMP mehr zu erwarten ist. Diese Schicht wird von vielen als das Non-Plus-Ultra empfunden und finden deshalb Java oder HL APIs schlecht. Aber: 2. Algorithmische Schicht Hier geht es darum, die Dinge möglichst geschickt, also mit möglichst niedriger Komplexität zu erledigen, z.b. Insertsort vs. Quicksort, lineare Liste vs. Hashliste, kompletten Refresh vs. Partiellen Refresh usw. Hier kann eine HL API punkten, wenn der API Programmierer erfahrener ist als der Anwender oder für ein bestimmtes Problem mehr Zeit investieren kann. 1. Konzeptionelle Schicht Das ist wahrscheinlich am schwierigsten zu verstehen und verschmilzt oft mit 2. Hier geht es darum, ein Programm vom Konzept her schnell zu bekommen. D.h. kann ich z.b. einen Refresh komplett einsparen, weil ich sicher sein kann dass nichts getrashed wurde? Dann kann mein Algorithmus noch so schnell sein oder der Compiler noch so schnellen Code generieren, ist wird immer schneller sein etwas nicht zu tun. Oder kann ich eine Aktion im Hintergrund parallel ausführen, sodass ich Zeit nutze die der Benutzer sowieso mit was anderem beschäftigt ist? Z.b. in einem IDE im Hintergrund kompilieren und Ergebnisse bereits im Sourcecode highlighten. Der Entwickler muss dann nie bewusst kompilieren. Wenn er am Ende eine Exe haben will, dann ist sie i.d.R. bereits da. Oder pre-fetch von Internet Unter-Seiten, während der Benutzer die Hauptseite liest. Wenn er sich dann für einen Link entscheidet, ist die Seite möglicherweise schon da. Früher, zu C64 Zeiten war 4.+3. das wichtigste. Beim Amiga kam langsam 2. dazu. Heute sind 1.+2. oft wichtiger geworden. Und genau da liegen die Stärken einer HL API und die Schwächen eine LL API, weil man das jedesmal neu erfinden muss, und das ist recht sophisticated im Vergleich zu Bit-Tricksereien, dass kann nicht jeder. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 31.05.2010 um 22:39 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.06.2010, 02:02 Uhr whose Posts: 2156 Nutzer |
Zitat: Wozu? Habe ich denn gesagt, daß das zwangsläufig zu schlechterer Performance führen müßte? Du bist anscheinend zu lange aus der aktiven Amiga-Programmierung raus, um die aktuellen Probleme, die sich mit der Zeit und den diversen Spaltungen ergeben haben, noch sicher zu erkennen. Und in Sachen Textverständnis hast Du auch nachgelassen. Zitat: Den Benutzer eines herkömmlichen 68k-Systems wiederum interessiert es nicht die Bohne, ob sich MUI überhaupt für irgendwas interessiert. Wenns anfängt zu lahmen, fängt der Benutzer an zu mosern. Vor allem wenn er vergleichen kann und sieht, daß es auch anders geht. Du hast meinen Standpunkt nach all der Zeit immer noch nicht verstanden, dabei ist es ganz einfach: High Level, schön und grün, aber nicht um jeden Preis. Wohin das führt, sieht man an diversen Druckertreibern in 100MB-Größe. Zitat: Wieso kommst Du jetzt mit "Optimierungen für planar/chunky"? Das hat in unserer Diskussion ziemlich wenig verloren. Oder würdest Du etwa solche Optimierungen erst in der High Level API einführen wollen? Zitat:Zitat:Ist doch schön, sollen sie sich mal alle austoben. Ist auch kein Problem, wenn man bei einem der beiden Systeme die Funktionstabellen der Libraries erst noch via "GetInterface" holen muss. Yay, und mal wieder eine schöne Bestätigung für meine Theorie, daß irgendein ***** immer ein Haar mit der unpassenden Farbe in der Suppe finden wird... Zitat: Wenn, hätte, könnte, würde. Und was bringt das? Tatsache ist doch, daß keiner den Anfang machen will, aus den unterschiedlichsten Gründen. Aber haben wollen irgendwie alle. Zitat:Zitat:Ich sehe da eigentlich eher den zwanghaft-manische Wunsch einer einzelnen Person, diesen Wunsch nach Ausweitung den anderen in den Mund zu legen. http://www.amiga-news.de/forum/thread.php?id=32899&BoardID=7#337121 Mehr muß ich nicht dazu sagen, oder? Du solltest echt mal Urlaub machen... Zitat:Zitat:Ja genau. Blödsinn! Hast Du Deinen Sarkasmus auch nicht mehr unter Kontrolle? Niemand verlangt von dem "Einzelnen" das, was Du hier aufzählst. Aber ich z.B. erwarte von jemandem, der etwas haben will, wirklich konkret umsetzbare Vorschläge und nicht so ein Gestammel wie "... ich hätte aber gern sowas wie Eclipse, noch besser Eclipse... und so ein API wie Java, besser noch Java...". Das führt zu exakt Nichts Zitat: Ernst nehmen kann man Dich momentan nicht, das steht fest. Wann bist Du wieder in der Lage, halbwegs sachbezogen und ohne schwachsinnige Übertreibungen zu diskutieren? Eine entsprechende Lizenz würde dem "Abgreifen für lau" einen Riegel vorschieben. Abgesehen davon, wie kommst Du eigentlich darauf, daß die aktuellen OS-Entwickler aus kaum vorhandenen Resourcen ein güldenes Schloß bauen müßten? Ist es nicht schon ein kleines Wunder, daß die überhaupt etwas auf die Beine bekommen haben? Ich finde es sehr interessant, daß ausgerechnet Du jetzt an die Produzenten schön hohe Ansprüche stellst, obwohl Du ihnen vor nicht allzu langer Zeit die Fähigkeit abgesprochen hast, selbst geringste Hardware-Ansprüche zu erfüllen. Man könnte meinen, Du würdest es am liebsten sehen, daß jedes der momentan verfügbaren Systeme den Bach runtergeht. Abgesehen von AROS natürlich, das kannst DU ja für lau abgreifen... Zitat: Der erste, der ein Haar aus der Suppe zaubern würde, wärst Du. Erst dann kommen die anderen üblichen Verdächtigen. So, können wir jetzt vielleicht mal zu den Sachlichkeiten zurückkehren? Weitere praktische Vorschläge für das gewünschte API zum Beispiel? Mehr Vorschläge für die erfolgreiche Umsetzung? Ich habe bisher die Probleme aufgezeigt, die ich sehe. Wo bleiben die Vorschläge, wie man diese Probleme erfolgreich vermeiden/umgehen könnte? Da könntest gerade Du eigentlich eine Menge zu beitragen. Ok, wegen des Sarkasmus-Flashs bleibt Dir da wenig Kapazität für, aber versuchen könntest Du es ja wenigstens... -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ Dieser Beitrag wurde von whose am 01.06.2010 um 02:16 Uhr geändert. ] [ Dieser Beitrag wurde von whose am 01.06.2010 um 02:17 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
01.06.2010, 08:33 Uhr Thore Posts: 2266 Nutzer |
@all Solche langen Threads bringen ebenfalls nichts. Wer etwas haben will muss auch was dafür tun, da ists auch egal obs für umsonst oder sonstwie ist. Ansonsten heißts, sich mit dem zufriedengeben was man hat. Langsam wird die Diskussion überflüssig. Die meisten Argumente hier sind sowieso abhängig von unterschiedlichsten Faktoren und können nicht verallgemeinert werden. Also, entweder man macht so eine API oder man lässt es bleiben. Offiziell wird es jedenfalls keine geben. Da hilft es auch nicht wie ein Politiker alles gleich wieder totzuquatschen was noch nichtmal geplant ist. [ - Antworten - Zitieren - Direktlink - ] |
|
01.06.2010, 09:50 Uhr Der_Wanderer Posts: 1229 Nutzer |
Schon klar dass so ein Thread nichts ändert. Aber ich wollte mal die Stimmung sondieren. @whose Eine HL API führt i.A. zu kleineren Programmen. Wenn der API Code dynamisch gelinkt wird, dann wird die exe auch kleiner. Wenn der API Code statisch gelinkt wird, wird die exe größer, weil man Dinge mit drin hat die man nicht braucht. Aber das juckt heute keinen mehr. Die menschliche Arbeit ist teuer, die der Maschine billig. Wichtig ist was eine Applikation kann und wie komfortabel sie das kann. Nicht ob ihre Exe ein wenig größer oder kleiner ist. Bei einem Druckertreiber von 100MB ist aber noch was anderes passiert. Möglicherweise sind jede Menge TTF Fonts mit eingebettet oder sowas. Man muss auch nicht von einem Extrem ins andere springen. So eine HL API wie ich sie mir vorstelle würde ja die AmigaOS API nicht verbieten, sondern ergänzen und mit AmigaOS API kooperieren. D.h. wenn ich ein Image Objekt habe kann ich mir durchaus eine Bitmap oder ein Rastport geben lassen, um mit Low-Level Befehlen weiterzuarbeiten. Das ist ja durchaus sinnvoll, da eine HL API nicht alles Erdenkliche leisten kann. Ich sehe aber leider hier, dass so eine HL API aus verschiedenen Gründen angezweifelt wird, und gleichzeitig viele Vorzüge nicht erkannt. Schade. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
01.06.2010, 10:11 Uhr Thore Posts: 2266 Nutzer |
> würde ja die AmigaOS API nicht verbieten, sondern ergänzen und mit AmigaOS API kooperieren Genauso dachte ich es mir auch. Daher wundere ich mich auch über ablehnende Haltung und rumgestreite ob "offiziell" und "inoffiziell". Es muss eben gut durchdacht sein, wenn es sich etabliert wird es vll mal offiziell (siehe MUI, AHI, Poseidon...) [ - Antworten - Zitieren - Direktlink - ] |
|
01.06.2010, 14:20 Uhr Holger Posts: 8116 Nutzer |
Zitat:Zum Beispiel hier: Zitat:Da Du in Bezug auf High-Level APIs ausschließlich Kontra-Argumente bringt, bzw. eigentlich nur dieses eine Mantra runterleierst, kann man nur davon ausgehen, dass Du davon ausgehst, dass High-Level APIs zwangsläufig zu schlechterer Performance führen müssen. Andernfalls wäre es ja nicht so wichtig für Dich, immer wieder auf der zu erwartenden Performance herumzureiten. Zitat:Komisch. Bislang waren es Der_Wanderer und ich, die von Probleme sprachen, während Du damit beschäftigt warst, zu betonen, dass nur die Programmierung über die divergierenden Low Level APIs sinnvoll ist. Zitat:Das ist ja das schöne: Er kann nicht vergleichen. Er hat die Wahl zwischen angeblich langsamer Software, die Toolkits verwendet, und angeblich hochoptimierter Software, die gar nicht existiert. Zitat:Hier geht es nirgendwo um "High Level um jeden Preis". Die Software, deren Komplexität auch ohne High Level APIs von den verbliebenen Amiga-Entwicklern gestemmt werden kann, wurde inzwischen implementiert. Zwanzig Jahre sollten dafür ausreichend gewesen sein. Jetzt geht es aber um die Software, die nicht geschrieben wurde. Keiner will, dass die existierende Software noch mal neu geschrieben wird. Das wurde inzwischen oft genug getan. Zitat:Da Du bislang keinerlei sinnvolles Beispiel dafür bringen konntest, wo ein High-Level API schlechtere Performance bringen würde, habe ich einfach das einzige Beispiel dieses Threads, Bilder und GUI, präzisiert. Weil dieses Beispiel zeigt, dass bereits heute 99% aller Software von diesen "Low Level APIs" abstrahiert ist. Und dass Schnittstellen, die dasselbe Ergebnis mit weniger zu schreibenden Code erreichen, keinerlei Performance-Nachteile haben. Zitat:Dass bei einem der Systeme die Library-Schnittstellen anders funktionieren, ist ein Beispiel für eine Divergenz zwischen den neuen Amiga-Systemen. Die, und nur darum ging es, keine Rolle spielt, wenn man auf einer höheren Ebene programmiert. Aber das stand vorher schon da. Hättest nur richtig lesen sollen, statt irgendetwas hinein zu interpretieren... Zitat:Beiträge wie Deiner dürften eine nicht unbeträchtliche Rolle spielen.Zitat:Wenn, hätte, könnte, würde. Und was bringt das? Tatsache ist doch, daß keiner den Anfang machen will, aus den unterschiedlichsten Gründen. Was ist eigentlich der Sinn Deiner Beiträge? Du redest etwas schlecht "weil es keiner macht" und wunderst Dich, dass es "keiner macht"? Zitat:Eine entsprechende Lizenz würde vor allem der gewünschten Akzeptanz einen Riegel vorschieben. Wenn etwas von allen verwendet werden soll, muss es natürlich auch eine Lizenz haben, die allen erlaubt, es zu verwenden. Zitat:Die aktuellen OS-Entwickler, Aros mal ausgenommen, wollen für ihr Produkt mehr Geld, als Microsoft für sein Betriebssystem. Trotzdem müssen sie natürlich nichts für die Anwendungsentwickler tun, wenn sie nicht wollen, dass etwas diese für ihr System produzieren. Ganz klar. Aber an den "kaum vorhandenen Resourcen" sind sie trotzdem selbst schuld. Der begrenzte Horizont und die Planlosigkeit, mit der entwickelt wurde, hat dazu beigetragen. Einfaches Beispiel, das auch schon hier auf AN diskutiert wurde: ungefähr zwei Jahrzehnte lang unterstützte das AmigaOS nur einen Zeichensatz: iso-latin-1, von der Unicode-Unterstützung im bullet-API mal angesehen. AOS4 hätte die Chance gehabt, direkt auf Unicode zu wechseln. Das wäre mit 99,9% aller alten Programme kompatibel gewesen, vor allem da praktischerweise iso-latin-1 und Unicode gar kein zusätzliches Mapping benötigen. Stattdessen hat man sich darauf fokussiert, Kompatibilität zu der Software zu wahren, die zwischen AOS3.9BB2 und der ersten Release von AOS4 entstand, weil in diesem kurzen Zeitfenster von Hack und Patch das Amiga-Encoding auf iso-latin-9 umdefiniert wurde, allerdings ohne an nur das geringste zu tun, um die dadurch entstehenden Inkompatibilitäten zu beseitigen. Außerdem hat man noch das ganze Gewürge mit verschiedenen Encodings implementiert, jeder Font, jeder Catalog kann jetzt sein eigenes Encoding haben, das lokale System selbst natürlich auch und richtige Unicode-Unterstützung konnte leider nicht implementiert werden, weil der ganze Kram, der mit richtiger Unicode-Unterstützung überflüssig gewesen wäre, schon so viel Ressourcen verbraucht hat. Das heißt aber nicht, dass es keine Anwendungen mit Unicode-Unterstützung gäbe. Und wie implementieren diese das? Richtig, unter Verwendung von High-Level-Toolkits, die diese Beschränkungen des Betriebssystems umgehen. Nur dass diese halt von anderen Systemen kommen, da beim Amiga nichts dergleichen mehr zu erwarten ist. Zitat:Wieso könnte man das meinen? Ich habe es wortwörtlich gesagt, das ich genau das als einzige Möglichkeiten sehe, wenn die kommerziellen Anbieter nicht etwas tun, für das Geld, das sie verdienen wollen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
01.06.2010, 14:35 Uhr Thore Posts: 2266 Nutzer |
Eine neue API bringt im schlechtesten Fall eine schlechte Performance, und im besten Fall die identische Performance mit alternativer ("Low Level") Programmierung. Wenn der Algorithmus allerdings besser gewählt wird aber auch einen Performance-Zuwachs. Man sieht, alle 3 Möglichkeiten sind da. Ich versteh nicht wie man über sowas derartige Diskussionen führen kann. Der_Wanderer hat eine einfache Frage gestellt, wir haben die erörtert, sind auf einen einheitlichen Themenpunkt gekommen. In dem Fall gibts eigentlich keine Kontras, sondern nur Stolpersteine die man vermeiden muss. Wer eine neue API dann verwenden will, kann dies ja machen, wer nicht, der muss ja nicht (daher kein Kontra). Wer eine neue API entwerfen will, sollte sich klar darüber sein, daß seine Bugs auf alle API Anwender eintreffen werden, und daher soll er sauber programmieren. Dem Enduser hingegen ist es völligst egal wie der Programmcode aussieht, wenns stabil und in ausreichender Geschwindigkeit ist. Wer aber denkt, die Plattform ist sowieso tot... wieso seid ihr dann noch im Forum aktiv?....  [ Dieser Beitrag wurde von Thore am 01.06.2010 um 14:36 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
| 1 2 3 4 -5- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > C oder C++? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|