c# im dritten Anlauf
-
loks schrieb:
Ein wichtiger Tipp: Hör auf in C zu denken. Man liest ständig so in der Art. In C würde ich das so machen und wie mache ich dann genau das in C#?
Die Vorgehensweise sollte sein: Ich will Sache X machen und jetzt muss ich schauen wie man Sache X in C# macht _ohne_ den Umweg über C zu gehen. Zur Zeit verrennst Du Dich in teilweise abstrusen Lösungsansätzen weil Du nicht von C loslassen kannst.
Das ist so wie Menschen die versuche Englisch zu sprechen indem sie den Satz erst in Deutsch formulieren und dann Wort für Wort ins Englische übersetzen. Klappt auch nicht.
Und wie andere schon sagten, Dein Problem ist nicht C#, sondern OOP-Konzepte. Du würdest in die gleichen Probleme bei jeder anderen Sprache inklusive C++ rennen (C++, nicht unter C++ kompiliertes C)
Gut erkannt.
Ich wollte tatsächlich ursprünglich existierende Programmierung 1:1 übertragen. Sozusagen Ansi-C von der Konsole mal eben auf GUI portieren.
Daß das nicht zielführend ist, hab ich mittlerweile begriffen. Gib mir ein bißchen Zeit.
Ich arbeite dran.
Pascal
-
pascal2009 schrieb:
[...] die Sichtbarkeit der Methoden und Variablen, das Problem gibt es in C überhaupt so nicht [...]
Im Grunde siehst Du es genau verkehrt herum. Die Sichtbarkeit des OOP (z.B.) ist in Wirklichkeit eine Lösung für das Problem, das selbige in C fehlt. Lies mal "The Design and Evolution of C++" dann verstehst Du (hoffentlich) das OOP Konzepte aus den Schwächen und Mängeln der C-Sprache entstanden sind und das diese Features keine "Probleme" sind, sondern Lösungen.
(PS: okok, OOP Konzepte sind auch unabhängig von C entstanden. Ich meinte damit die OOP-Konzepte von z.B. C++ die man ja auch in C# wiederfindet)
-
Der Zeiger von meineListe[0] würde auf das Element zeigen, der Zeiger von meineListe[1] aber auch. Also zeigen alle auf dasselbe Element, egal wie oft man die Funktion .Add aufruft. Wir hätten dann sagen wir 1000 Zeiger auf ein und dasselbe Element erstellt, also das Gegenteil einer Liste, nämlich nur Zeiger auf ein Objekt. Da muß man ja erstmal drauf kommen. Man denkt, die Liste packt die Werte irgendwo in neue SPeicherbereiche, das tut sie aber nicht. Ergo ist das Arbeiten mit dem Befüllen eines Wertebereichs und Zuweisung zur Liste kontraproduktiv bzw. dem Vorgang nicht angemessen.
Ich versteh das Problem nicht. Wenn du in C einen Pointer hast, per malloc Speicher anforderst und den Speicher wieder und wieder füllst und den Pointer in eine Liste packst hast du das Problem doch auch.
Wobei zwischen 1 und 2 der Unterschied besteht, daß der erste Code besser schreibbar ist und der zweite besser lesbar. Ich würde mich aber unbedingt für die 2. Variante entscheiden, da nicht auszuschließen ist, daß sich die Zusammensetzung und die Reihenfolge der Felder im Laufe der Programmierung auch mal ändern könnte und dann hätte man ins Klo gegriffen plus daß der Fehler je nachdem gar nicht so leicht auszumachen wäre.
Ich würde die erste vorziehen. Konstruktoren sind für die Kapselung zuständig.
-
DarkShadow44 schrieb:
Der Zeiger von meineListe[0] würde auf das Element zeigen, der Zeiger von meineListe[1] aber auch. Also zeigen alle auf dasselbe Element, egal wie oft man die Funktion .Add aufruft. Wir hätten dann sagen wir 1000 Zeiger auf ein und dasselbe Element erstellt, also das Gegenteil einer Liste, nämlich nur Zeiger auf ein Objekt. Da muß man ja erstmal drauf kommen. Man denkt, die Liste packt die Werte irgendwo in neue SPeicherbereiche, das tut sie aber nicht. Ergo ist das Arbeiten mit dem Befüllen eines Wertebereichs und Zuweisung zur Liste kontraproduktiv bzw. dem Vorgang nicht angemessen.
Ich versteh das Problem nicht. Wenn du in C einen Pointer hast, per malloc Speicher anforderst und den Speicher wieder und wieder füllst und den Pointer in eine Liste packst hast du das Problem doch auch.
Wobei zwischen 1 und 2 der Unterschied besteht, daß der erste Code besser schreibbar ist und der zweite besser lesbar. Ich würde mich aber unbedingt für die 2. Variante entscheiden, da nicht auszuschließen ist, daß sich die Zusammensetzung und die Reihenfolge der Felder im Laufe der Programmierung auch mal ändern könnte und dann hätte man ins Klo gegriffen plus daß der Fehler je nachdem gar nicht so leicht auszumachen wäre.
Ich würde die erste vorziehen. Konstruktoren sind für die Kapselung zuständig.
Also du sprichst da ein wichtiges Problem an:
Bibliotheksfunktionen wie List<T> sind im allgemeinen selbstgeschriebenen Funktionen vorzuziehen, da nachgewiesenermaßen fehlerfrei.
Das Problem ist aber, man muß die Funktion auch verstehen, was sie macht, wie sie was macht und welche Seiteneffekte davon ausgehen könnten, das heißt also, nicht nur einfach anwenden, sondern zuvor testen und verstehen. Sonst kommen da Seiteneffekte, die man nicht abschätzen kann, weil man die Funktion nicht wirklich versteht. Es braucht eben seine Zeit.
Was das zweite angeht, wie man mit Konstrukturen kapselt, ist für mich im Augenblick noch chinesische Geheimwissenschaft. Solange das so ist, lege ich eher Wert auf gut lesbaren Code, den man versteht und auch warten kannn.
Daß du dich aber in C# bestens auskennst hab ich schon bemerkt an der Schnelligkeit deiner Codierung. Möglicherweise übersiehst du daher die Schwierigkeiten eines Anfängers, sich da reinzufinden.
Ich baue den Einstieg in C# so auf, daß ich mir Codebeispiele hole, die austeste, und wenn sie funktionieren, die archiviere und mit anderen kombiniere. Dabei kann es durchaus vorkommen, daß ich bestimmte Codeschnippsel nicht verstehe, aber anwende.
Am Ende sollte dann das Verständnis des Ganzen stehen. Am Anfang kann man das nicht erwarten sondern muß froh sein, wenn man das, was man will, überhaupt erstmal ans Laufen bringt.
In Ansi-C hab ich vor 3 Jahren eine Fibu geschrieben, die läuft bis heute ohne einen einzigen Programmabsturz, was bei AnsiC ja nicht unbedingt die Norm ist. Zwei Steuererklärungen wurden damit abgegeben. Das Programm hat aber keine GUI.
Die fehlende GUI ist mein Motiv.
Die GUI hab ich schon ganz gut im Griff, aber das tiefere Verständnis von C#, bis dahin ist es noch ein langer Weg.
Pascal
-
Wenn ich das lese ...
Der Witz ist, um meine Ansi-C FiBu Programmierung, wie ursprünglich gedacht, umzusetzen auf GUI in WinForms, wären die augenblicklichen Kenntnisse in C# völlig ausreichend. Ich hab alles ausgetestet, was das Programm braucht. Die Basisfunktionen sind vorhanden. Insbesondere mit der WinForms komme ich allerbestens zurecht, und der Unterschied zu Ansi-C, bezogen auf den Aufwand von Eingabemasken und Dialog, ist frappierend. Mit Win Forms hat man mit Dialog und Masken überhaupt keinen Aufwand, das sind ja alles nur Click_Events mit vorgegebenen Werkzeugen, dafür muß man in AnsiC an der Konsole schon richtig Aufwand betreiben, alles das fällt ersatzlos weg. Was auch frappierend ist, vom Programmieraufwand her, Listen zu editieren. Das sind in WinForms 2 Click_Events, in AnsiC auf der Konsole sind das ganze Kapitel mit Indexern usf., richtig aufwändige PRogrammierung, die dank WinForms zu 90% entfällt.
Mit den Listen ist es allerdings so, daß ich nach jetzigem Kenntnisstand nur in strings arbeiten kann, also string zerlegen in seine Bestandteile, editieren und wieder zu einem String zusammenfügen und abspeichern als Textdatei. Die Speicherung von list mit zusammengesetzten Typen als binärdatei ist noch in der Mache. Noch nicht ausgetestet.
Ich könnte das Ansi-C Programm aber trotzdem schon ab heute auf GUI portieren.
Aber:
Mit 100%iger Sicherheit würde ich, je mehr ich C# verstehe, das Programm suboptimal (=Scheisse) finden, nämlich das, was unterhalb der GUI läuft, und zunehmend den Wunsch haben, das jetzt mal nach den neueren Erkenntnissen zu "optimieren", was nichts anderes heißt als irgendwann wieder neu zu programmieren, weil die neuen Erkenntnisse immer auch auf die Programmstruktur durchgreifen.
Bevor ich mich also daranmache, soviel Zeit zu investieren, warte ich erstmal ab, bis ich mit meinen C# Kenntnissen besser zufrieden bin. Bisher ist das noch nicht der Fall.
Pascal
-
Himmel nochmal das hier ist nicht Dein persönliches Tagebuch.
-
µ schrieb:
Himmel nochmal das hier ist nicht Dein persönliches Tagebuch.
Ziel: Portierung von Konsole auf GUI
Möglichkeiten: viele
Versuch: WinForms mit C#
Bisheriger Stand:
WinForms no problems, die Basisfunktionen hat man innerhalb 4 Wochen locker drauf.
C#: Die Baisisfunktionen, die man benötigt, kann man auch innerhalb 4 Wochen anwenden. Natürlich hat man da den Sprachumfang nur in Bruchteilen verstanden. Man sucht sich die Bruchteile, die man braucht, und die sollte man allerdings verstanden haben.
.NET Bibliotheksfunktionen unendlich, man muß sich die rauspicken, die man braucht. Sind nicht viele, einige reichen.
Performance: Ziel in ca. 4 Wochen ungefähr erreicht. Ohne Visual Studio und intellisense wäre das dann allerdings viel viel schwieriger und würde länger gebraucht haben.
Soviel zu meinen persönlichen Erfahrungen mit meinem persönlichen Ziel GUI Anwendung programmieren.
Was mich jetzt hier im Boot hält ist, C# noch besser zu verstehen, obwohl das bereits über das ursprüngliche Ziel hinausführt.
Mü, also wirklich ...
Pascal
-
Du hast ein krankhaftes Mitteilungsbedürfnis.
Krieg das auf die Reihe und höre auf zu nerven mit Deinen Fortschrittsberichten. Ansonsten klinke ich mich aus von weiteren Hilfestellungen.
-
µ schrieb:
Du hast ein krankhaftes Mitteilungsbedürfnis.
Krieg das auf die Reihe und höre auf zu nerven mit Deinen Fortschrittsberichten. Ansonsten klinke ich mich aus von weiteren Hilfestellungen.Deine Tipps werde ich wohl noch brauchen. Daher höre ich weisungsgemäß ab sofort auf zu erzählen, daß ich mir monatelang Gedanken gemacht habe wie ich die GUI hinkriege und dann nach einigen Umwegen im dritten Anlauf bei WinForms und C# gelandet bin und innerhalb sehr kurzer Zeit damit sehr schöne Fortschritte gemacht habe und daß ich damit sehr gut zufrieden bin.
Also wirklich!
Pascal
-
pascal2009 schrieb:
hustbaer schrieb:
pascal2009 schrieb:
Also wenn jemals jemand sagen würde, C# wäre einfach zu verstehen, dann laß ich mich in die nächste Anstalt einliefern .............. ich hab größte Probleme mit der C# Denke.
Dir fehlen die ganzen Grundlagen (nicht auf C# bezogen, sondern auf die Programmierung allgemein!). Und so setzt du dich hin und willst ne neue Sprache mit "learning by doing" lernen. Irgendwie klar dass das nicht funktioniert.
Ich hab ganz nette Grundlagen in Ansi-C. Das hab ich glaube ich ziemlich gut begriffen, von der Denke.
Mir ist schon klar dass du das glaubst. Ich versuche nur dir klarzumachen dass es nicht stimmt.
pascal2009 schrieb:
hustbaer schrieb:
Das ist auch genau so. Hängt aber nicht mit der Liste zusammen. Das ist allgemein so wenn man mit Reference Typen arbeitet.
Allgemein ist das gar nicht so und muß auch nicht so sein.
Wenn du in C mit malloc(sizeof(irgendwas)) einen Zeiger setzt und dem einen Wert zuweist, dann ist der Speicherplatz des neuen Elements nicht identisch mit dem Speicherplatz des zugewiesenen Wertes. Daß List<T> so arbeitet, hätte mich nicht überrascht, wenn malloc() genauso arbeiten würde.
Statt zu versuchen zu verstehen was ich meine, sagst du lieber "nein". Das ist wohl nicht so sinnvoll wenn du was dazulernen willst.
- Ich hab "Reference Typen" geschrieben. Gibt's den Begriff in C? Nein? Werde ich dann C meinen?
- Wenn man vergleichbaren Code schreibt, dann ist es in C natürlich das selbe.
Wenn du in C# nen Reference-Type hast der Foo heisst, dann ist *jede* Foo Variable in C# automatisch eine Reference (also im Prinzip so was ähnliches wie ein Zeiger). Immer. Überall. Nicht bloss bei List<T>.
Das ist eine ganz grundlegende Sache, und du hast die offenbar nicht verstanden.Und dann allein schon deine Ausdrucksweise. "Wenn man mit malloc nen Zeiger setzt" ... WTF? Ich kennen niemanden der wirklich Programmieren kann der so redet. Und warum? Weil die Leute die gut programmieren können es im Austausch mit anderen gelernt haben, und im austausch mit anderen lernen sie dann ganz schnell dass man das eben so nicht ausdrückt.
pascal2009 schrieb:
Ich will hier aber nicht über AnsiC streiten, sondern in C# dazulernen.
Echt? Es macht eher den Eindruck als ob es dir hauptsächlich darum ginge dir und der Welt zu beweisen dass du nen Plan von irgendwas hast, von dem dir leider gänzlich der Plan fehlt.
Wenn du dir monatelang den Kopf zergrübelt hast wie du mit C ne GUI machen solltest... ich meine... und dann behauptest du du kannst C? Ja, klar, ne?
-
pascal2009 schrieb:
µ schrieb:
Du hast ein krankhaftes Mitteilungsbedürfnis.
Krieg das auf die Reihe und höre auf zu nerven mit Deinen Fortschrittsberichten. Ansonsten klinke ich mich aus von weiteren Hilfestellungen....
Also wirklich!Ja, also wirklich! Nur dass µ halt Recht hat.
pascal2009 schrieb:
Pascal
Wie lange wird es wohl noch brauchen, bis dir auffällt dass man in Foren seine Beiträge nicht unterschreibt? Monate? Jahre?
Diese Art von Sturheit ist es i.Ü. auch die dich zu nem schlechten Programmierer macht.
-
Und mir reicht es nun auch endgültig. Ich habe den vorherigen Thread entfernt, weil er schlicht und einfach nichts hier verloren hatte. Das ist hier nicht dein Blog, Tagebuch oder sonstwas. Stelle vernünftige Fragen, worauf man vernünftig antworten kann. Ackere vielleicht auch zuerst mal das ganze Buch vollständige durch.
Du ignoriert hier (bewusst?) Beiträge und erzählst wiederholt Mist. Die WinAPI wurde dir auch schon im vorherigen Thread nahe gelegt und hast du bisher völlig ignoriert. Deine grossartigen Kenntnisse in C erachte ich als äusserst fragwürdig. Ich empfehle dir dringend von deiner grossartigen Vorstellung über dich selbst herunterzukommen, dann bist du vielleicht in der Lage etwas zu lernen.
Ich schliesse den Thread hier. Das hat einfach keinen Sinn. Komm mit klaren und korrekt formulierten Fragen wieder. Alles andere werde ich fortan einfach entfernen.
Grüssli
