NSTableView einstieg

ich denke tom meinte statt eines NSDictionary ein NSArray zu nehmen ...

[[NSNumber numberWithInt: i] stringValue] ist momentan ok. Ist ja nicht so, dass ich einen Array mit float-Indices hab

Ja, aber NSNumber kann Floats aufnehmen. Und _möglicherwiese_ hält das NSDictionary ab, überhaupt so ein Dingens auf die Platte zu schreiben. Das ist aber nur eine Vermutung.

Und dafür extra noch einen Array zu erzeugen scheint mir ein wenig übertrieben?

Mir erscheint ein Array die einfachere Datenstruktur gegenüber einem Dictionary. Wieso benötigst du überhaupt ein Dictionary mit Indizes?

da bist du generell auf dem Holzweg.

1. Die Sache mit dem Array für einzelne Buchungsvorgänge(?) ist richtig.

2. Ich nehme an, dass {name, zahl} eine Buchung ist. Wenn du die in ein Dictionary stopfen willst, dann ni9mmst du nicht den Namen als Key, sondern andere Keys, etwa

Key:@"Name" Value:@"Tom"
Key:Amount Value:@9811
(@98.11 soll ein NSNumber-Objekt sein mit dem Wert (int)9811 -- Bitte Geldbeträge _nicht_ in Floats darstellen!)

Dieser Eintrag _pro_ Buchung wird in dem Array vervielfacht. Also hast du dann etwa:

Array:
0:
Key:@"Name" Value:@"Tom"
Key:Amount Value:@9811

1:
Key:@"Name" Value:@"Deconceptional"
Key:Amount Value:@87

2:
Key:@"Name" Value:@"Tom"
Key:Amount Value:@-3012

3:
Key:@"Name" Value:@"Klausel"
Key:Amount Value:@17281

Usw. usf. Ist es das, was du suchst?

warum willst du das in ein dictionary packen mit den indexen die du im array eh schon hast. speicher doch einfach das array ab und fertig!

besser ist einen integer (in cent) zu verwenden als einen float (in €)

Um das ganze zu speichern mach ich ein neues Dictionary, mit dem Array-Index als Key

Wozu denn das? Nimm die Keys, wie ich sie oben beschrieben habe: name und amount. Was willst du mit deinem Index-Key? Du hast da etwas konzeptionell nicht verstanden. Ob es am Nick liegt.

Frage1: was ist gegen [NSNumber numberWithFloat: value] in Dictionarys einzuwenden?

Es ist nichts dagegen einzuwenden, wenn du sie als Value verwendest. Was gegen ihre Verwendung als Key einzuwenden ist, schrieb ich ja bereits: Die Umwandlung in einen Text und zurück führt mindestens bei verschiedenen Maschinen zu verschiedenen Ergebnissen. Damit passen deine Keys nicht mehr. Das will man nicht.

Frage2: Kann es sein, dass NSDictionary in etwa einem Hash-Table entspricht? (ok, die Frage ist ein wenig OT )

Nein, eine Hash-Table lässt sich durch ein Dictionary implementieren, wenn der Hash-Value als Key verwendet wird und das referenzierte Objekt als Value. (Intern benutzt wiederum NSDictionary Hashing, um einen Key schnell zu finden.)

1. Ist der zugriff auf eine nicht referenzierte variable (weiss nicht ob ich da jetzt den richtigen begriff erwischt habe, gmeint ist int x = 0; usw.) schneller als der zugriff auf das gegenstück (NSNumber *myNumber = [NSNumber numberWithInt: 0])?

Jede Indirektion kostet Zeit und Speicher und bringt Flexibilität. Das gilt bereits bei

int x;
x = 0; // Ein Zugriff x<-0

gegen

int* y;

y = &x; // Das meine ich jetzt nicht
*y = 0; // Zwei Zugriffe *(y<-Pointer)<-0

Man bezeichnet übrigens Variablen, die keine Objekte sind, als Skalare.

Was du machst ist jedoch zusätzlich die Objekterzeugung. Das ist deutlich langsamer und fast imemr schnell genug.

Premature optimization is the root of all evil (Hatte ich das schon einmal erwähnt.)

Du trifffst hier eine konzeptionelle Entscheidung, keine Performance-Entscheidung.

2. Kann mir jemand ein Buch zu OO-Design empfehlen? Wenn möglich nichts, das auf eine spezifische Sprache ausgelegt ist...

.de

3. Spricht jemand hier Eiffel?

Ich leider nicht. Ich habe mal in SELF hereingeschnuppert, welches oo Konzepte gut darstellt. Objective-C eignet sich aber auch sehr gut zum lernen. Zwei Einschränkungen existieren:
- Keine Blöcke
- Es gibt Skalare wie int. Die kannst du natürlich einfach nicht benutzen. (Ich komme immer mehr dazu, sie auch nicht als Member-Variablen zu benutzen, sondern nur für so einen Kram wie for-Zähler.)

Zu 1: Ziel ist es, sei dies nun über kurz oder lang, eine Klasse zu schreiben, die mir Matrizen-Berechnungen abnimmt. So wie ich dass sehe, macht es da sinn, wenn ich die Matrix in einem float matrix[][] speicher!?

Das kannst du machen oder zwei verschachtelte Arrays nehmen. Bei einer solch "elementaren" Klasse, die sicher allerorten verwendet wird, würde ich aber zu float[n][m] raten, jedenfalls, wenn die Größe der Matrize bekannt ist. Du solltest darüber nachdenken, ob du die Klasse von NSValue ableitest.

Zu 2: ???

Ich meinte ddas deutschppsrachige Internet.

Zu 3: Ich hab nur gehofft, dass mir jemand agents auf vernünftige art und weise erklären kann...

Dann hättest du das fragen sollen.

Ich kenne Eiffel nicht, es scheinen mir aber beim ersten Blick funktionale Elemente zu sein. Bei funktionallen Programmmeirsprachen beschreibst du die Lösung als -isolierbare- Funktion. Diese Funktion ist wiederum allerdings nur ein Wert, was man in anderen Programmeirsprachen Blöcke nennt.

Hierdurch gewinnst du, dass du einen Source-Block (in C durch {} eingeschlossen) als Wert übergibst und "mit diesem rechnen" kannst, was etwa eigene Programmmkonstrukte definieren lässt. Mal in Objectiive-C-Syntax als Idee:



Agents scheinen genau solche Blöcke zu sein. Aber wie gesagt: Ich kenne Eiffel nicht.

Die Ableitung hat den Vorteil, dass du die Objekt-Funktionalität mitnimmst.

Du kannst damit auch Rechenoperationen durchführuen:

[aValue sizeValue].width + 5;

Ich mutmaße jedoch, dass du eher Matrix-Operationen durchführen willst. Die kannst du dann ja in deinen Subklassen implementieren.

Ich nehme an, dass Genericity mit generischen Datentypen zusammenhängt. Nein, das gibt es nicht in Objective-C, weil Typenlosigkeit dafür herhält.