mutablearry probleme

entschuldigt ihr beiden, wenn meine antworten ein bissel arrogant gewirkt haben. Hatte nen schlechten Tag. Aber nochmal zur Sache:

Ich finde eine enumeration von Strings schließt sich schon vom logischen Aspekt her aus. Wie will man ein string aufzählen? Mit Zahlen geht das, aber für was anderes ist es eher unwahrscheinlich... Und wenn das in C# geht, dann heißt das nicht, dass es gut ist Ich halte nicht viel von C#, ist M$-"Kram".

und wegen dem #define makro. Das lernt man eigentlich in den ersten Stunden, wenn man C lernt. Zumindest war es bei mir so. Ich verstehe einfach nicht, warum alle welt glaubt, sie müsse Cocoa programmieren können, ohne vorher C zu können. Ich kenne ne menge Leute, die Cocoa-programme schreiben. Viele können nichtmal das grundlegendste C und genau das ist das Problem. Ich bekomm dann solche Fragen wie "was ist ein c-string" oder "warum geht dies und das nicht". Ich erkläre es immer, sie glaube es zu verstehen, kommen 5 minuten später wieder und ich erklär's nochmal. Dass sie es dann immernoch nicht verstanden haben ist mir irgendwann auch egal. Hauptsache, das Programm läuft. Ich sage ihnen 500*, dass sie sich mal ein C-Buch oder auch nur Tutorial im Internet anschauen sollen, um wenigstens den Hauch einer Ahnung zu bekommen, aber wieso sollten sie? das Programm läuft und alles ist bestens. Das ist so ähnlich wie bei allen anderen Threads hier, wo gesagt wird, schaut euch doch bitte mal diese und jene Seite an... (ich bezweifle stark, dass sich der Großteil die Seiten dann auch anguckt)
Ich will nicht behaupten, dass ich gut C kann, ich hab's weder studiert oder noch irgendwo gelernt. Ich habe mir ein dickes Buch gekauft, es gelesen und dann irgendwas programmiert. Bei bedarf hab ich nachgeguckt und irgendwann konnte ich es ein bissel. Hey aber n #define-Makro... Leute...

egal, just my 2 cent...
vergesst es. War nicht so gemeint. Nächstes mal bin ich wieder netter...

Max

Manchmal hat man eben schlechte Tage.

Ich halte es auch grundsätzlich nicht für richtig, dass man erst komplett C können muss, weil es in oC viele Dinge gibt, die besser gelöst sind. Da kann C ganz schön verderben.

So ist es etwa mit C-Strings. Natürlich ist es gut, damit umgehen zu können. Manchmal denke ich aber: Mein Gott, wieso hat der Menwsch das gelernt. Jetzt richtet er so ein Chaos an. Immerhin dürften C-Arrays (einschl. der String) sicher einen Großteil der Abstürze und Buffer Overflows ausmachen. Da ist es bei manchem besser, nie davon gehört zu haben.

Die enum-Lösung wird übrigens so nicht funktionieren. Sie aber auch so ein C in oC-Blödsinn (sorry, für das Wort).

Wenn ich mittels Klartexten aufzählen will, dann verwende ich ein Dictionary. Wenn ich das nicht will, dann verwende ich #defines. Ich nehme mir aber doch keineen enum um in einer textuellen Aufzählung nicht-textuelle Inidzes zu bekommen. Das ist von hinten durch die Brust ins Auge.

Komisch ...

im Buch "C++" von Bjarne Stroustrup (C++ Erfinder) steht, dass man Makros möglichst vermeiden soll. Man soll sie nur wenn es notwendig ist einsetzen.

@MAX: jeder hat mal einen schlechten Tag du hast natürlich recht, dass man vorher etwas C können soll, um ObjC zu erlernen. Ich habe aber ein Problem: ich arbeite hier am WindoofXXL und kann nicht üben, ObjC zu schreiben.

Ich finde bei Linux kein gutes IDE für ObjC ... kennt jemand eines?

Ich finde eine enumeration von Strings schließt sich schon vom logischen Aspekt her aus. Wie will man ein string aufzählen? Mit Zahlen geht das, aber für was anderes ist es eher unwahrscheinlich... Und wenn das in C# geht, dann heißt das nicht, dass es gut ist Ich halte nicht viel von C#, ist M$-"Kram".

Ja, mit der Enumeration hast irgendwie recht, dass eine Aufzaehlung irgendwie verbunden ist mit Zahlen, die sich inkrementieren.
Fuer Strings muesste man ein enum wirklich missbrauchen. Und irgendwas missbrauchen wollen wir doch alle nicht.

Nur weil c# von MS ist, heisst es noch lange nicht, dass es schlecht ist. Ich mach das jetzt seit ca. nem halben Jahr. Einiges gefaellt mit besser (z.B. Properties) wie bei Java (weil nur mit Java kann man es eigentlich richtig vergleichen), einiges schlechter. Durch Mono wird das ganze auch noch einigermassen Plattform unabhaengig. Microsoft Fan bin ich ansonsten auch keiner. Alles schlecht zu machen, nur weils von MS kommt finde ich aber nicht richtig.

C sollte man, egal, welche Sprache man programmiert schon mal angesehen bzw. gelernt haben. Das sind wirklich Grundlagen, vorallem wenn man jetzt ObjC macht.
Ich selbst finde C, nach mehreren Jahren ARM Microcontroller und Linux-Treiber Softwareentwicklung immernoch ziemlich geil, weil so minimalistisch und einfach gehalten. Das ist es auch was mich zu ObjC gezogen hat, zum einen auf dem Mac endlich mal Entwickeln und das noch in einer C aehnlichen Sprache. Die Object-Orientierte Erweiterung ist wirklich gut gelungen, kein Vergleich zu C++.

Nach jetzt fast zwei Wochen ObjC und Cocoa Framework Einarbeitung finde ich das alles richtig gut.

so long

Man soll sie ganz, ganz, ganz, ganz, ganz bestimmt nicht zugunsten von Zahlenkonstanten vermeiden. Da bin ich mir ganz, ganz, ganz, ganz, ganz sicher.

C# habe ich mir nur kurz angeschaut. Das scheint schon smalltalkiger zu sein. C++ war nie weirklich OO. Deshalb hat man immer mehr Konzepte hereingebracht, die die Sache nur verkomplizieren. Schu dir die C++-Foren an: Voll von Fragen über Templates. *schauder*

Ich komme urpsürnglich aus er gleichen Ecke, habe aber auch Andendungsentwicklung in C und C++ gemacht. Kein Vergleich zu oC. Die Sprache ist extrem elegant. Manche versuchen bloß immer noch C++-Programme in oC zu schreiben. Das geht in die Hose.

Ich halte es auch grundsätzlich nicht für richtig, dass man erst komplett C können muss, weil es in oC viele Dinge gibt, die besser gelöst sind. Da kann C ganz schön verderben.

da haben wir total konträre Meinungen

So ist es etwa mit C-Strings. Natürlich ist es gut, damit umgehen zu können. Manchmal denke ich aber: Mein Gott, wieso hat der Menwsch das gelernt. Jetzt richtet er so ein Chaos an. Immerhin dürften C-Arrays (einschl. der String) sicher einen Großteil der Abstürze und Buffer Overflows ausmachen. Da ist es bei manchem besser, nie davon gehört zu haben.

nein, ich finde man sollte wissen, wie es funktioniert. Und wenn da die programme abstürzen dann liegt das nicht an der Sprache, sondern am Programmierer
Manchmal muss man einfach mit C-Strings arbeiten. Z.B. wenn es um performance geht. Da kannst du nicht anfangen, groß mit NSStrings zu hantieren, die sind einfach zu langsam. Und deshalb finde ich muss man es können. Manchmal braucht man sie auch, weil eine Core-Funktion ein cString braucht und kein CFString. Was machst du denn dann? An diesen stellen hängen sich die meisten auf. Grundlage ist wichtig und man sollte sie sicher beherrschen. Man geht einfach mit offenen Augen durch die welt. Aja: NSString ist auch nur ein Wrapper für ein CString *g*

Wenn ich mittels Klartexten aufzählen will, dann verwende ich ein Dictionary. Wenn ich das nicht will, dann verwende ich #defines. Ich nehme mir aber doch keineen enum um in einer textuellen Aufzählung nicht-textuelle Inidzes zu bekommen. Das ist von hinten durch die Brust ins Auge.

Zustimmung.

Max

Original von asrael
Nur weil c# von MS ist, heisst es noch lange nicht, dass es schlecht ist. Ich mach das jetzt seit ca. nem halben Jahr. Einiges gefaellt mit besser (z.B. Properties) wie bei Java (weil nur mit Java kann man es eigentlich richtig vergleichen), einiges schlechter. Durch Mono wird das ganze auch noch einigermassen Plattform unabhaengig. Microsoft Fan bin ich ansonsten auch keiner. Alles schlecht zu machen, nur weils von MS kommt finde ich aber nicht richtig.

Das hab ich ja auch nicht gesagt. Ich habe gesagt, dass es schlecht ist und außerdem noch von Microsoft kommt. Ein grund, warum es schlecht ist, ist die Tatsache, dass es sich "C" schimpft und aber nicht dem ANSI-C Standard folgt. Ist die typische Arroganz der Amis, aber egal

Max

jajajaja, der Programmierer ist schuld. Es ist nur verwunderlich, warum es immer C-Programe sind, die Buffer Overflows erzeugen. Offenbar sind C-Programmierer unfähig.

Also stimmt es, dass C ganz schön verdirbt.

Bei C muss man halt genau wissen, was man tut. Wenn man mit Strings hantiert, muss man halt eben aufpassen, dass da nix in die Hose gehen kann.
Genauso in Schleifen und Arrays, da koennen die wildesten Dinger zustande kommen, wenn die schleife nicht rechtzeitig terminiert und Daten ueber Arraygrenzen geschrieben werden. Den Compiler interessierts nicht und das Laufzeitsystem genauso wenig. Da werden halt einfach Werte, die vielleicht anschliessend im Speicher stehen ueberbuegelt.
Trotzdem kann man das der Sprache nicht anlasten, C ist halt nunmal ziemlich lowlevel, da kuemmert sich noch niemand, ausser dem Programmierer selbst, um solche Sachen. Dafuer ist es auch ziemlich schnell und puristisch.

Das man damit trotzdem was anfangen kann, braucht man sich ja nur anschauen, was noch alles damit gemacht wird. Ich wuerde tippen, der gesamte Darwin Unterbau basiert auf C.

so long

Öhm, ich habe *hüstel* rudimentäre Kenntnisse von C.

Aber es ist gleichgültig. Es kommt nicht darauf an, woran es liegt. Tatsache ist, dass C-Code nunmal für BO Ursache ist, ob nun unmitelbar oder mittelbar. Das ist doch ein Streit um des Kaisers Bart.

Und wer in C++ oder oC noch C-Strings benutzt, der gehört ehrlich gesagt gesteinigt. Gleiches gilt übrigens für diejenigen, die ein Arrays in einer For-Schleife mittels Index durchlaufen. STELLT SIE AN DIE WAND, DAMIT ICH DEN ERSTEN STEIN WERFEN KANN!

Ich hab da schon dinger gesehen, auf Arrays ploetzlich ueber einen Zeiger zugreifen und den dann in einer Schleife inkrementieren. Das da was schief gehen kann ist klar.

Nein, ich will jetzt auch nicht dem Programmierer die Schuld fuer BOs in die Schuhe schieben, klar liegts auch mit an der Sprache.
Hoehere Sprachen, haben ganz klar den Vorteil, dass irgendwelche Instanzen (Laufzeit-System oder was auch immer) sich um solche potentiellen Schwachstellen (auch Fehler der Programmierer, weil wir sind alle nur Menschen) kuemmern. Ist heutzutage, wenn die Rechner immer schneller werden, Speicher ohne Ende zur Verfuegung steht, ja auch Zeitgemaess.

so long

Ü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. Und manchmal gibt es Stellen, wo cStings verwendet werden MÜSSEN! wo es nicht anders GEHT! und an diesen stellen kannst du nicht sagen "alle die nicht die highl-level variante nehmen sollte man steinigen". Auch für das Verständnis einer jeden Programmiersprache sind fundierte Grundlagenkenntnisse wichtig.

Das ist ungefähr so wie als wenn Schumi nichts über Autos wüsste - er muss es nur bedienen können um die Technik kümmern sich andere. Aber genau das ist falsch, wenn man die betsen Ergebnisse haben will. Und deshalb ist er auch Weltmeister. Er kann zwar kein Auto bauen, das verlangt auch keiner. Aber er weis ganz genau was in der Kiste vor sich geht und könnte auch mal zur Not selber Hand anlegen (k, schumi macht das nicht, aber in theory there's no difference between theory and praxis - in praxis there is *g* kleiner Scherz am Rande)

Bare Basics sind überall wichtig. man kann unendlich viele Beispiele bringen und man sollte (um mal zum Thema zurück zu kommen) auch dort, wo es möglich und sinnvoll ist High-level schreiben. Ist bequem und sicher und sonstewas. Aber man muss den Hintergrund haben und wenn es drauf ankommt muss man auch die Grundlagen anwenden können, z.B. bei C-Strings.

Noch einwas: asrael hat es gesagt - C ist eine absolut exakte Sprache. Wenn da was schief läuft ist der Programmierer schuld, nicht die Sprache. Alles ist absolut exakt definiert und total puristisch. Aber es ist schnell und vor allem ist es stabil.

my2cent

Max

P.S.: Ich nehme nur for-Schleifen, um arrays zu durchlaufen, ohne Scheiß.

Ja, ich benutze auch for schleifen fuer Arrays.
Der Knackpunkt ist die Terminierung der Schleife. Man kann sich den Index, mit dem man auf Elemente des Arrays zugreift und gleichzeitig damit die Schleife terminiert, fest angeben, anhand der Anzahl der Elemente in der Schleife oder eines #defines, das ist ja ok, da kann auch nix schief gehen, weil man nicht ueber die Arraygrenze hinaus kommten sollte.
Es gibts aber auch Faelle, hab ich selbst schon zur genuege gesehen, wo der Index berechnet wird, wenn man bei der Berechnung einen Fehler gemacht hat und kommt ueber die Arraygrenze hinaus, krachts.

Hoehere Sprachen wie z.B. Java (bei ObjC weis ichs nicht, C und C++ nicht) machen hier eine Arraygrenzen Pruefung. Also bei jeden Zugriff aus ein Array wird ueberprueft, of der Index ausserhalb liegt und wenn, dann wird eine ArrayOutOfIrgendwas Exception geworfen.
Das kostet natuerlich alles Zeit und Resourcen.

so long

anhand der Anzahl der Elemente in der Schleife

Sorry, ich meinte natuerlich die Anzahl der Elemente des Arrays.


so long

Original von macuser
ich auch, warum auch nicht? was soll daran so verwerflich sein?
man kann das zwar auch ueber einen enum machen, aber das ist doch
viel zu umständlich und meiner meinung nach dann auch schlechter zu lesen.

wie willst du min ner enum durch ein array laufen? Vielleicht meinst du einen NSEnumerator? Das ist die zweite Möglichkeit, ich finde sie nicht so gut, weil ich mir z.b. nich sicher sein kann, was passiert, wenn ich in der schleife ein item aus dem array lösche...

Original von asrael
Hoehere Sprachen wie z.B. Java (bei ObjC weis ichs nicht, C und C++ nicht) machen hier eine Arraygrenzen Pruefung. Also bei jeden Zugriff aus ein Array wird ueberprueft, of der Index ausserhalb liegt und wenn, dann wird eine ArrayOutOfIrgendwas Exception geworfen.
Das kostet natuerlich alles Zeit und Resourcen.

Ja, Cocoa macht das auch. die Exception heißt NSRangeException, wenn ich mich nicht irre. Hab ich in letzter Zeit so selten

Max

Ü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.

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.

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.

Das geht ganz schnell schief, gerade wenn du abbrichst.

Ich finde ohnehin, dass Arrays viel zu viel verwendet werden. Der Index hat nichts mit Struktur zu tun. Häufig machen das Leute nur, weil sie es eben aus C kennen. In den allermeisten Fällen ist ein Set performanter.