hast Du schon mal mit malloc Speicher allokiert? Das ist dynamisch.

So geht das:
Edit: Viel besser und ausführlicher ist das hier erklärt.

Michael

mach das lieber mit malloc als mit einem Mutable-Array. Frisst viel weniger performance!

Schau doch mal hier, die Seite(n) sind ganz informativ für den Anfang: cplusplus.com/ref/cstdlib/malloc.html

Gruss
jerry

Original von gritsch
mach das lieber mit malloc als mit einem Mutable-Array. Frisst viel weniger performance!

Fragt sich nur ob Performance dann hier wichtig ist.

Manchmal sind c Kenntnisse bei objc doch von Vorteil.

Manfred

Original von -Nuke-
Fragt sich nur ob Performance dann hier wichtig ist.

"Interessiert es den user, ob er generell 20x so lange warten will wie er eigentlich müsste, weil der entwickler sich nicht sicher war, ob sein code performance braucht?"

Original von M.A.X"Interessiert es den user, ob er generell 20x so lange warten will wie er eigentlich müsste, weil der entwickler sich nicht sicher war, ob sein code performance braucht?"

Naja. Man muss ja nicht gleich übertreiben, oder?

Wenn die Matrix vielleicht max 100x100 groß ist, dann macht es sicherlich keine Unterschied ob nun 0.0002 Sekunden oder 0.0003 Sekunden. Dafür ist der Code besser zu verwenden und Erweiterungsfähig und auch nicht so anfällig vor Programmierfehlern.

Weil wenn du nach deinem Wortlaut jetzt gehst, müssten wir noch Assembler-Code reinhacken und sämtliche Hochsprachen in die Tonne kloppen.

Und wenn nicht NSMutableArray, dann halt aus C++ vector oder list.

Manchmal sind c Kenntnisse bei objc

Welche C-Kenntnisse bei Objective-C. Was haben denn Objective-C-Arrays mit C zu tun?

doch von Vorteil.

Welcher Vorteil denn von Objective-C-Arrays?

meinst du

klar, performance ist immer wichtig.

Nein.

"Premature OPtimization is the root of all evil" (Donald Knuth)

Ich wundere mich schon, dass die Leute hier von performance sprechen.

Welche Performance?
Auf welchem Rechner?
Bei welchen Umständen?

Habt ihr alle Kristallkugel für OS X?

Original von Tom9811

Quellcode

1. array = malloc( size_of( float ) * 5 * 5 );
2. array[7][8] = 3.0;
3. *Boooooom*

Na, so würde das ja auch niemand machen! Klar testest Du vorher immer, wieviel alloziert wurde. Aber ich sehe natürlich worauf Du hinaus willst und das ist berechtigt ;-)).

Gruss
jerry

Na, so würde das ja auch niemand machen!

Naja, ich glaube, dass Buffer Overflows täglich auftreten. Es muss einige geben, die das so machen. Wenn auch mutmaßlich nicht wirklich absichtlich.

Klar testest Du vorher immer, wieviel alloziert wurde.

Jo, wenn man dran denkt, wenn man das richtig nachhält usw. Das bringt dann wieder Probleme mit Seiteneffekten. Zumindest würde ich das Ganze in eine Info-Struktur packen.

Aber ich sehe natürlich worauf Du hinaus willst und das ist berechtigt ;-)).

Jo, denke ich auch. Bereits sich jetzt einen Kopp darum zu machen, was möglicherweise an Performance verloren geht ... Wir wissen ja ncit enmal, wie groß das Array wird, geschweige denn, wie häufig es benutzt wird. Ist doch hier alles Mutmaßung.

Original von Tom9811

Quellcode

1. array = malloc( size_of( float ) * 5 * 5 );
2. array[7][8] = 3.0;
3. *Boooooom*

wer so nen code schreibt braucht sich nicht wundern, dass seine programme nicht laufen. Wenn du erst ein programm schreibst und am ende überlegst, wie du es besser machen kannst, dann hast du nicht nur was falsch gemacht, sondern unheimlich viel Zeit verschwendet. Aber ich geb die diskussion auf. verknöcherte Verbohrtheit im Alter würde ich sagen...

wer so nen code schreibt braucht sich nicht wundern, dass seine programme nicht laufen.

Buffer Overflows sind alltäglich. Ich glaube nicht, dass die alle schlechter programmiren als du. Hier mal eine Liste der Programmierer, die MAX unterlegen sind

"Die PCRE (Perl Compatible Regular Expressions) bezeichnete Bibliothek ignoriert beim Kopieren von Nutzereingaben in einen internen Buffer dessen Größe."
heise.de/newsticker/meldung/63067

"Die Nachrichtenbehandlung zahlreicher Computer-Associates-Produkte enthält Fehler, die sich zu einem aus dem Netz gestarteten Denial-of-Service beziehungsweise zum Einschleusen und Ausführen von fremdem Code ausnutzen lassen."
heise.de/security/news/meldung/63053

"Ulf Harnhammer berichtet über eine Schwachstelle im E-Mail-Client ELM (Electronic Mail for UNIX) in den Versionen 2.5 PL5 bis PL7. Mails mit bestimmten "Expires"-Headern verursachen einen Pufferüberlauf, mit dem sich Code auf den Stack schreiben und starten lässt."
heise.de/security/news/meldung/63056

"Durch einen Buffer Overflow im Sysinternals-ToolProcess Explorer lässt sich Schadcode einschleusen und ausführen."
heise.de/security/news/meldung/63052

"mutt ist ein beliebtes Mailprogramm für Unix-Systeme und auch für Windows. Ein Fehler in den Funktionen zum En- und Dekodieren von Attachments ermöglicht das Überschreiben eines Puffers."
heise.de/security/news/meldung/62992

Aber auch bei Apple sitzen Idioten
"Besonders schwerwiegend, weil aus der Ferne über Buffer-Overflows ausnutzbar, sind die Fehler im Apache-Paket. Ebenfalls zum Einschleusen und Ausführen von beliebigem Code eignet sich der Pufferüberlauf im Directory Service. Die Kerberos-Implementierung hat die erheblichen Fehler der MIT-Version geerbt. Viele der Lücken in den anderen Paketen ließen sich unter Umständen durch per E-Mail eintrudelnde, präparierte Dokumente ähnlich aus der Ferne ausnutzen, um Schaden auf dem System anzurichten oder unautorisierten Zugriff zu erlangen.
heise.de/security/news/meldung/62835

Alles Idioten, nur MAX nicht.

Aber ich geb die diskussion auf. verknöcherte Verbohrtheit im Alter würde ich sagen...

So alt bist du doch noch gar nicht!?

Kirche
Dorf
dalassen

Wenn man _sorgfältig_ programmiert und vor dem Zugriff auf seinen dynamischen Speicher dessen Grenzen prüft, spricht überhaupt gar nichts gegen die Verwendung von normalen C-Arrays. Ich würde es in diesem Fall jedenfalls bevorzugen.

matrx[x][y]...
ist doch viel klarer als
[[array objectAtIndex: i] objectAtIndex: y]

Ganz abgesehen davon, dass in so ein NSArray eben auch nur Objekte wollen.

Buffer Overflows entstehen ja doch meistens durch falsche Annahmen, oder dadurch, das sich die Aufrufumgebungen mit einem mal dramatisch ändern.

Wenn Du _EIN_ einziges Mal ein Programm geschrieben hättest, bei dem es wirklich auf Geschwindigkeit ankommen würde und nicht nur über premature optimization schwafeln würdest, dann hättest du nicht so ne arrogante antwort gegeben. Ich habe nur gesagt, dass es nicht zwangsläufig zu Buffer Overflows kommen muss, nur weil man in C schreibt und dass man, wenn man so ein dämliches beispiel macht wie du es klar ist, dass das passiert. Was DU aber sagst ist, dass diese Entwickler alles Idioten sind, weil sie nicht in cocoa oder sonstwas schreiben und deshalb buffer overflows produzieren. Bis heute habe ich nicht den sinn und zweck dieser deiner Argumentation verstanden. Sag ihn mir uns ich will ruhe geben.