mutablearry probleme

Original von Tom9811

Überall, wo es um Geschwindigkeit geht, musst du an pure C ran. Ich habe in meiner App einen Absatzzähler und noch so einigen anderen spaß - alles pure-c.

Was ist daran langsam? Das zählt man bei der Eingabe mit.

Äpfel und Birnen. Bitte, ich habe mich Jahrelang mit Absatzzählungen beschäftigt und glaube mir, es sit wirklich kein Kinderspiel. Und wenn ich es in Cocoa geschrieben hätte, hätte keine einziger mein Programm gekauft. ES GEHT EINFACH NICHT OHNE C!! Es geht nicht. Es gibt Gebiete wo man nicht drumrum kommt. 1000 Dank an der ARP und das MVC-Konzept, aber es gibt stellen, wo sie einfach viel zu langsam sind! Aja, wir sprechen hier nicht von 20 Zeilen oder so. Es muss auch in Dokumente mit - sagen wir - 500.000 Wörtern (ca. ein Roman) flüssig laufen.

Im Übrigen: Man kann darüber Bescheid wissen. Es hat bloß keinen Sinn. Und zur Anwendung von NSString-Objekten muss ich nun gar nichts über Autos bzw. C-Strings wissen. Das ist das Prinzip der Kapselung.

Nein, auch hier haben wir anscheinend ganz andere Ansichten. Ich verwende auch NSStrings. Aber wenn leute sich wundern, warum NSMakeRange nicht geht, weil sie ihre Range-Variable mit einem * deklariert haben, dann weiß ich ganz genau, warum fundierte C-Kenntnisse und vor allem auch was Pointer (und somit z.B. strings) angeht, wichtig sind. Strings sind das einfachste Beispiel, um Pointer zu erklären. Und wenn das jemand nicht kann dann weiß ich auch, warum es so viele stabile Software da draußen gibt.

Natürlich gibt es eine Berechtigung für C. Ich habe früher embedded Controller progrmmiert. Das war in Asm. ber wenn ich heute eine OS-X-App aufsetze, brauche ich kein C. Auch nicht für Speed (Auch hier gibt es freilich Ausnahmen.). Etwas mehr nachdenken bringt meist mehr.

Ein Berechtigung für C? C braucht keine Berechtigung. C selber ist die Berechtigung. Etwas mehr Nachdenken bringt meist mehr. An einigen Stellen, wo es schnell sein muss geht es nicht anders. Und das ist überall dort, wo mit vielen Daten gearbeitet werden muss. Erst heute hab ich wieder bemerkt, wie langsam doch Mail ist. Und ich tippe, es liegt nicht nur an einem mangelhaften Konzept, sondern auch daran, dass hier vielleicht zu sehr und zu blind auf Objective-C gesetzt wurde... Etwas mehr nachdenken bringt meist mehr - würde ich auch sagen.

Max

*Schulterzuck* Was soll ich dazu sagen? Du machst e s ja nicht konkret.

Wenn ich einen Text mit 500.000 Wörtern habe, so würde ich eben eine Absatz-Struktur darüber legen und bei Änderungen mitzählen. Ein -count(NSMutableArray) wird sicher nicht jedesmal alle Elemente durchzählen. Jedenfalls muss es das nicht. Und eine bereits gesetzte Variable zurückgeben wird sich in C nicht schneller formulieren lassen als in oC.

Instabil ist jedenfalls ganz sicher Software, die in C programmiert wurde. C ist der Klassiker für unsichere und instabile Software. Genau aus diesem Grund wechseln täglich Firmen von C/C++ weg.

Natürlich muss jemand Structs verstaedn haben, wenn er welche anwendet. Er sioll aber keine C-Strings anwenden, wenn dies nicht unabdingbar nötig ist. In deinem Beispiel kann ich das eben nicht erkennen. Größe eines Objektes (im untechnischen Sinne) ist kein Argument für Langsamkeit.

Wenn du diesen Text zählst, dann machst du das live und nur die Änderungen - das ist klar. Aber! Wenn du sie mit Objective-C zählst und mit objective-C speicherst dauert dass sicher 100 ms länger als ohne. Und das ist der Unterschied, den ein User sofort bemerkt. Wenn du bei jedem Buchstaben 100 ms länger brauchst macht das schreiben einfach keinen Spass, da sich dein Programm mit de zählen beschäftigt. Genau so ist es mit dem zeichnen. Du kannst zwar die Cocoa-methoden verwenden, um einen Text zu zeichnen. Aber wenn du es schnell machen musst wirst du ganz schnell merken, dass es so nicht geht und du musst zu Pure-C und den CoreGraphics wechseln. Und die nehmen nun mal nur C-Strings und Glyph-Arrays.

Dass die Fehler in den Programmen an den C-Stellen auftreten mag gerne sein. Aber du schiebst es auf die Sprache und das ist falsch. Warum machen es denn viele falsch? Vielleicht, weil sie es nicht richtig verstanden haben. Und warum haben sie es nicht richtig verstanden? Weil sie sonst vielleicht immer high-level programmieren, wo die Sprache einem die meisten Fehler verzeiht. Aha, da haben wir doch den Schuldigen: die High-Level-Sprache. Aber nein, das kann es auch nicht sein. Denn sie wollen wir ja benutzen und man kann ihr ja nicht vorwerfen, fehlerverzeihend zu sein. Also bleibt nur einer übrig - der dummer Programmierer, der sich einfach partout weigert, sich intensiv mit den Grundlagen der Programmierung und damit auch mit der zu Grunde liegenden low-level Sprache zu beschäftigen. Punkt, würd ich sagen - es kommt sicher noch ein "aber", oder??

Max

Also, wir können das jetzt ja lange hin und her wenden.

Um bei einem Tastendruck zu checken, ob der einen neuen Absatz einfügt oder einen alten auflöst und dann entsprechend ++ und -- auszuführen, benötige ich in oC sicher keine 100 ms.

Da ich nicht annehme, dass C-Prograymierer dümmer als Java-, oC-, Delfi, Was-Weiß-Ich-Programmierer sind, ist es ein Problem der Spache, nicht der Programmierer. Das Problem korreliert in der Realität mit der Sprache. Es korreliert nicht mit Personen.

Es ist auch einfach nicht richtig, dass oC mehr Fehler verzeiht.Das Gegenteil ist der Fall. Anders als C/C++ -und nebenbei jede andere Programmiersprache der Welt, das wird wohl einen Grund haben- kommt es mit wenigen klar strukturierten Konzepten aus. Das ist einfacher. Wenn etwas einfacher ist, dann macht die gleiche Person weniger Fehler.Sie wird aber nicht dümmer, weil sie cvor einem C-Compiler sitzt und schlauer, weil sie vor einem oC-Compiler sitzt. Sie wird aber merkwürdigerweise sicher bei oC-Programmierung weniger Fehler machen.

Wie gesagt: Die Ferhleranfälligkeit von Apps korreliert mit der Sprache nicht mit der Person. Das kannst du täglich bei Security-Bulletins sehen.

"... Buffer Overflow ..."
"... Heap Overflow ..."
"... wrong casting ..."

Das passiert in anderen Programmiersprachen erst gar nicht.

Es wird alerldings zunehmend besser, weil die Leute langsam einsehen, dass C-Strings Teufelswerk sind.

Vielleicht haben wir uns hier falsch verstanden - mit Absatzzähler meine ich einen Zähler, der Wörter, Anschläge (keine Zeichen!), Absätze, Zeilen und Seiten berechnet (anhand von vorgegebenen Größen) und dann die Absätze in einen View neben dem Text zeichnet, wo die Absatznummern angezeigt werden. Und da braucht das Zeichen eine gewisse Zeit - siehe oben - und aber auch das Speichern der Absatznummern in einer passenden struktur. Und dafür kommt leider nur Pure-C in Frage, alles andere ist glatter Selbstmord. (mal von extrem komplizierten Algorithmen abgesehen, die man dann auch in C schreiben würde *g*)

Ich hab nicht gesagt, dass die Programmierer dumm oder schlau sind. Ich habe nur gesagt, dass sie sich das Wissen nicht angeeignet haben. Das ist nicht schlau, sondern gebildet und das ist ein himmelweiter Unterschied. Mag für dich nicht so sein, ist's aber für mich.

C ist so toll wegen der absoluten Klarheit. DU musst dich um alles kümmern, DU bist der, der Speicher wieder freigibt, DU bestimmst die Aufrufe, die nötig sind. Und das hast du in kaum einer anderen Sprache. Warum basieren denn die meisten modernen Sprachen auf C? Und warum gibt es da so viele dicke Bücher dafür? Weil du mit sehr wenig Befehlen sehr sehr viel erreichen kannst. In Obj-C sind schon allein deshalb mehr Konzepte vorhanden, als dass es alle Konzepte von C mit einbindet, ob du willst oder nicht. Es gibt in oC immer zwei Methoden, Speicher zu verwalten. Dass du meistens die von Obj-C verwendest mag klar sein. Aber hie und da... (ich wiederhole mich).

Max

Wir hatten uns teilweise richtig verstanden. Ich kann dennoch nicht s4ehen, was da solange dauert.

Du bist doch immer in einem aktuellen Absatz. Dann tippt der User ein Zeichen. Da kannst du vier, fünf Fälle unterschieden (normaler Tastendruck, BS, Del, Ret) die je nachdem entsprechede Zähler hoch oder herunterzählen. Über die Absätze legst du ein NSMutableArray welches du an den TableView bindest. Also ich sehe das Problem immer noch nicht.

Wir müssen uns auch nicht über Wörter streiten. Ersetze in meinem Text alles "schlau" durch "gebidet" ich stehe dann immer noch dahinter.

Es bleibt dabei, dass das Problem mit der Sprache korreliert, nicht mit der Person.

oC basiert, was die Syntax angeht, auf C. Es basiert strukturell ganz sicher nicht auf C. C++ basiert strukturell ganz sicher nicht auf C. Java basiert strukturell ganz sicher nicht auf C. Delfi, self, ... eigentlich alles basiert, was die Struktur angeht, ganz sicher nicht auf C. C-Konzepte sind so tot wie Graf Dracula. Was isch gehalten hat, ist alleine die Syntax und die auch nur halbherzig.

Mir ist -um beim Thema zu bleiben- keine moderne Programmiersprache bekannt, die Strings als Arrays darstellt. oC macht das nicht, Java macht das nicht, self macht das nicht, C++ macht das nicht.

Aber was ist ein String denn?? Es ist eine reihe von Buchstaben in einer festen Anordnung - ein array. Keine Sprache nimmt nativ dieses Format, das stimmt. Aber man braucht es zum Austausch zwischen den Verschiedenen Sprachen (z.B. obj-C und C++) und dann wirst du nicht drumrum kommen, das zu beherrschen. Wenn ich was mit core-graphics Zeichen will muss ich ein C-String übergeben. Und dann muss ich wissen was ich da wie übergeben kann und wo ich speicher freiräumen muss. Ist so.

Und du glaubst gar nicht, wie langsam ein NSMutableArray mit 100.000 Elementen sein kann. Das dauet locker 10 ms und das zeichnen mit einer TableView dauert zu lange. Außerdem kannst du damit nicht so tolle features wie oben 3 pixel zum atmen für den text lassen. Also kommt st um -drawString:withAttributes: nicht rum. Da dauern aber ein paar aufrufe gut und genre 120 ms, wenn du das selbe mit CG machst dauert es 20 ms. Und das ist der unterschied, den ich meine. Wenn du die Absätze in einer C-Struktur speicherst hast du selbst bei einem kompletten durchlauf von 10000 objekten eine liste (kein array!) keine messbare Zeit. Die selbe struktur mit obj-c umzusetzen zu wollen wäre glatter selbstmord...

Max

Instabil ist jedenfalls ganz sicher Software, die in C programmiert wurde. C ist der Klassiker für unsichere und instabile Software. Genau aus diesem Grund wechseln täglich Firmen von C/C++ weg.

Warum verwendet man dann eigentlich immernoch C in Bereichen, wo es auf Sicherheit ankommt. Z.B. werden die Microcontroller in Autos, Flugzeugen usw. nach wie vor in C Programmiert. Wenn man weis wo C die Schwaechen hat macht das eben die guten Entwickler aus, die damit umgehen koennen.

Warum Firmen zu anderen Sprachen wechseln ist glaub ich eher die Bequemlichkeit. Viele Software Entwickler wollen ihre Software nur noch auf dem Reisbrett entwerfen, und das geht nunmal mit Objekt Orientierten Sprachen bzw. High Level Sprachen besser. Diese Sprachen kommen zum Teil auch mit Frameworks daher, die kaum etwas vermissen lassen (Bequemlichkeit). Das ist halt bei C ueberhaupt nicht so. Hier muss man noch sehr viel selbst machen und mit Klassendiagrammen ist auch nix.


so long.

Wirtschaftlichkeit ist der Grund, warum viele Firmen auf höhrere Sprachen umsteigen!

Die Software-Firmen wollen nur, dass das Software schnell wie möglich entwickelt wird und auf den Markt kommt. Deshalb nehmen sie die höheren Programmiersprachen wie Java, Delphi, VisualBasic,...

C++ ist für mich immer noch die "mitterle" Programmiersprache. ObjC gehört auch dazu, weil man IMMER noch C verwenden kann.

Die beste Zwischenlösung zwischen höhere Sprachen und Low-Level-Sprachen ist, wenn man C und z.B. ObjC vermischt. C nimmt man für spezielle Algos z.B. Bildbearbeitung. Mit ObjC wird das Ergebnis dargestellt. Z.B. Apple Videoprogramm Motion nimmt CoreGraphics und die Benutzerschnittstelle ist Cocoa - eine geniale Mischung find ich!

@MAX: Was die meisten Computernutzer im Umgang mit den Anwenderpogrammen hasst ist die Fehleranfälligkeit eines Software. Wenn die 500000 Wörter beim erstenmal einmal indexiert werden, würde doch Cocoa ausreichen, weil sonst kaum Unterschied ausfallen wird. (dafür braucht man gute Struktur!)

Ja, Wirtschaftlichkeit ist natuerlich auch ein erheblicher Faktor. Ich bin mir nur nicht so ganz sicher, dass C unwirtschaftlich ist.
Es kommt halt drauf an, was man fuer eine Software macht. Die Visualisierung ist sicherlich bei hoeheren Sprachen leichter, einfacher, schneller zu implementieren und zu machen als bei C.
Dagegen bei Konsolenprogrammen, Diensten usw. ist C sicher gut geeignet und auch nicht unwirtschaftlicher als andere Sprachen.

Original von macfreakz
@MAX: Was die meisten Computernutzer im Umgang mit den Anwenderpogrammen hasst ist die Fehleranfälligkeit eines Software. Wenn die 500000 Wörter beim erstenmal einmal indexiert werden, würde doch Cocoa ausreichen, weil sonst kaum Unterschied ausfallen wird. (dafür braucht man gute Struktur!)

Bitte, glaub mir doch einfach. Ich schreibe seit über 2 Jahren an diesem Thema und habe es schon 10* von Grund auf neu umgebaut. ES IST NICHT SO EINFACH. Es ist verdammt komplex und Cocoa ist einfach zu langsam. Nochmal sag ich es nicht, es ist aber so. Ich mag Cocoa sehr, aber...

Max

Aber dieses "schnell" entwickeln wollen, was uns Stalkingwolf immer als gigantischen Vorteil von Delphi vorhält, hat einen entscheidenden Nachteil. Weil du es so schnell machst, denkst du nicht tiefgründig genug drüber nach, machst du schnell viele Fehler (unter Umständen auch konzeptionelle), findest du nicht den besten (für den Nutzer schnellsten) Weg, das, was du willst zu implementieren und hast am Ende eine mit der heißen Nadel gestrickte Software, die vor Fehlern und Instabilitäten nur so strotzt. Bestes Beispiel sind dafür Microsoft-Programme und neuerdings - leider - auch vermehrt die von Apple.

Max

Und trotzdem kaufen die Leute M$ Produkte ... ohne mal die Alternative wie OpenOffice anzuschauen!

Du hast natürlich recht, dass es mit C viel schneller geht!
Aber man könnte es doch mit ObjC versuchen, wenn man z.B. eigene String-Klasse schreibt und so weiter! Dann geht es performant wie bei C! Und deine selbstgeschriebene String-Klasse kannst du bei anderen Projekte weiternutzen dank OOP!

Das nenne ich wirklich ein Vorteil von der Nutzung von ObjC statt C!

ich habe einen eigenen textStorage und für einen extrem konkreten zweck auch eine eigene String-Klasse genommen. Aber eine eigene String-Implementation schreiben ist purer Schwachsinn. Im Hintergrund müsste ein C-String stehen oder so sonstwas und man verliert die Kompatibilität zu CFString. Das ist nicht performanter. Glaub mir einfach, es ist nicht einfach und es geht nur mit C, das möglichst selten Cocoa-Befehle nutzt, richtig gut. Wie gesagt, ich mache das seit Jahren und habe alles erdenkliche probiert. Die Cocoa-Klassen sind schon nicht schlecht, man muss nur GANZ genau gucken, wie man sie einsetzt und überschreibt. Und da kann es so viele haken geben usw.

Glaubs einfach - Danke

Max

Aber was ist ein String denn?? Es ist eine reihe von Buchstaben in einer festen Anordnung - ein array. Keine Sprache nimmt nativ dieses Format, das stimmt. Aber man braucht es zum Austausch zwischen den Verschiedenen Sprachen (z.B. obj-C und C++) und dann wirst du nicht drumrum kommen, das zu beherrschen. Wenn ich was mit core-graphics Zeichen will muss ich ein C-String übergeben. Und dann muss ich wissen was ich da wie übergeben kann und wo ich speicher freiräumen muss. Ist so.

Was ein String ist, weiß ich gar nicht. Ich wundere mich, dass du es weißt. Ich würde sagen, es hängt von der Maschine ab, die ich programmiere. Noch mehr: Ich würde sagen, es interessiert mich bei einer App nicht.

Richtig, manchmal, wenn man etwa unmittelbar mit C-Funktionen in Berührung kommt, muss man etwas wissen. Absolut richtig. Nur: Das mache ich nicht zum Prinzip, sondern zur Ausnahme.

Was die GEschwindigkeit angeht: Ich glaube immer noch nicht, dass es ein Problem ist. Ich muss den Text nicht durchnudeln, an keiner Stelle. Gut, beim Laden kann man das evtl. machen um die Konsistenz zu üvberprüfen. Spielt aber keine Rolle.

Ansonsten wieß ich auch nicht, wie ich bei einem Text von 500.000 Wörtern auf ein Array mit 100.000 Einträgen kommen soll, wenn nicht ein Absatz durchschnittlich aus 5 Wörtern besteht, was ich für unwahrscheinlich halte. Ich habe jetzt hier mal ein x-beliebiges Buch aufgeschlagen. Da hat ein Absatz > 100 Wörter Macht ein Absatz Array von 500 Einträgen. Ich sehe da kein Geschwindigkeitsproblem.

Das sehe ich genau umgekehrt. Wenn die Entwicklungsumgebung (eischl. Sprache, Framework) einfach und konsequent ist, hast du mehr Zeit, dich um die Struktur deines Problemes zu kümmern. Und du hast gesagt, dass du bereits mehrfach angefangen hast. Das liegt doch daran, dass du dich mit Strukturen deiner HIlfsmittel beschäftigst, anstelle der deines Programmes.

ich antworte mal für beide posts zusammen...

Wenn du schon davon ausgehst, dass jeder Absatz mindestens 100 Wörter haben muss, dann ist mir auch klar, warum du dir keine sorgen machst. Das Programm muss auch nicht mal mit der wimper zucken, wenn du nur ein wort pro Absatz hast. Und wenn das ohne Probs geht, kannst du davon ausgehen, dass es auf älteren, langsameren Rechnern mit von mir aus 100 Wörtern / Absatz und nem netzten kleien Text flüssig läuft.

Das ich es neu angefangen habe, hat mehrere Gründe. Zum einen den, den du genannt hast. Ich habe mich mit den Strukturen meiner Hilfsmittel besser beschäftigt und neue Wege gefunden, es schneller zu machen, indem ich immer tiefer in die materie eingedrungen bin. Mittlerweile bin ich in der tiefst-denkbaren ebene gelandet - im testStorage, früher war ich einer delegate-funktion von einem textView. Aber das ist gar nicht so entscheidend wie die Tatsache, dass ich feststellen musste, dass meine Implementierung bestimmte Kriterien nicht erfüllt hat. Das waren auch unterschiedliche. Z.B. dass man leerzeilen nicht mitzählt (und so auch darstellt), dass es einfach nicht schnell genug war oder dass es Fehler gab, weil es über eine bestimmte methode zu kompliziert war und deshalb eine etwas rechenaufwendigere, aber einfachere her musste.

Um um mal dein beispiel mit der TableView zur darstellung der zahlen zu erläutern: wir wollen einen editor schreiben, der mir die Absatznummern anzeigt, links von meinem text. Du sagst vorher berechnen. ok, kann man machen. Z.B. in eine mutableArray. Aber das sind nicht 500 Einträge, wenn ich 500 absätze mit je 100 wörtern habe, denn ein Absatz wird ja im textView umgebrochen und hat damit mehrere zeilen. ja, ich könnte jetzt ja der tableview eine bestimmte cell-höhe angeben, die den ganzen Absatz richtig überdeckt. Und nehmen wir mal an, dass wird richtig dargestellt, du auf Veränderungen richtig reagieren kannst usw. Dann musst du am Anfang immernoch den kompletten Text layouten (im NSLayoutManager), damit du weißt, wo jetzt hier welche Zeile mit welchen Wörtern genau liegt. Umgehen kannst du ihn nicht (von Hand berechnen), denn der LayoutManager macht das nicht immer unbedingt logisch. Das layouten dauert bis zu 5 minuten (!!!) auf alten rechnern mit langen texten (normalerwiese passiert das im hintergrund) und das kannst du keinem User zumuten.

Ich kann da gut und genren nen roman drüber schreiben...

Wegen den c-Strings: Ich finde es extrem wichtig, zu wissen, mit was man umgeht. Hintergrundwissen ist für mich mit das wichtigste wissen. Alles andere kann jeder, aber wenn du richtig in der Materie stehst gehst du ganz anders damit um. Für mich ist es Prinzip, den Hintergrund zu wissen und wenn möglich immer tiefer vorzustoßen. Das ist hier wahrscheinlich der unterschied und deshalb lohnt es nicht, weiter über diesen aspekt zu diskutieren, denk ich mal...

Max

Also, langsam werde ich etwas sauer. Bitte lege mir nicht in jedem Posting Worte in den Mund, die ich nicht benutzt habe.

Ich habe nicht gesagt, dass jeder Absatz mindestens 100 Wörter haben muss. Würdest du bitte zur Kenntnis nehmen, was ich gesagt habe.

Dank!

Der Rest des Beitrages erübrigt sich damit.

Original von Tom9811
Also, langsam werde ich etwas sauer. Bitte lege mir nicht in jedem Posting Worte in den Mund, die ich nicht benutzt habe.

Ich habe nicht gesagt, dass jeder Absatz mindestens 100 Wörter haben muss. Würdest du bitte zur Kenntnis nehmen, was ich gesagt habe.

Du:

Da hat ein Absatz > 100 Wörter Macht ein Absatz Array von 500 Einträgen. Ich sehe da kein Geschwindigkeitsproblem

Darauf habe ich gesagt:

Wenn du schon davon ausgehst, dass jeder Absatz mindestens 100 Wörter haben muss, dann ist mir auch klar, warum du dir keine sorgen machst.

Lass das "muss" weg und des Satz behält die volle Aussage.

Der Rest des Beitrages erübrigt sich damit.

Ich liebe Totschlagargumente. Vor allem Dingen wegen solchem Krümelscheiß.

Tut mir jetzt echt leid, aber irgendwie habe ich keinen Bock mehr auf diese Diskussion.

Max

Das muss ist jawohl von zentraler Bedeutung. Wenn du vollständig zitierst, wirst du sehen, dass ich zudem von einem x-beliebigen Buch geschrieben habe. Schließlich sprach ich von 500 Einträgen und nciht höchstens 500 Einträgen.

Wenn du das richtige zitieren für Krümelscheiß hältst, erübnrigt sich alelrdings eine Diskussion. Sie erübrigt sich auch deshalb, weil du seit ein paar Beiträgen schreibst, dasss wir dir einfach glauben müssen.