aus textBox nach INI schreiben
-
Das ist C++/CLI Du Honk und nicht C/C++
-
Fatzke schrieb:
Das ist C++/CLI Du Honk und nicht C/C++
Vielen Dank! Ist das dein übliches Niveau auf dem du dich unterhältst?
Wie zu sehen ist, steht der Beitrag in C++/CLI und nicht in C/C++
-
Du musst dich aber auch nicht wundern, wenn nur du solche Antworten erhälst.
Schon allein das
[quote="fuchsle"
Vielen Dank für den Hinweis, jedoch habe ich nicht behauptet, dass ich die Express Version nutze. Daher gehe ich davon aus, dass es gehen sollte.
[/quote]ist Unfug. Es gibt da keinen Unterschied zwischen Express und den Kaufversion.
-
nn schrieb:
Du musst dich aber auch nicht wundern, wenn nur du solche Antworten erhälst.
Schon allein das
[quote="fuchsle"
Vielen Dank für den Hinweis, jedoch habe ich nicht behauptet, dass ich die Express Version nutze. Daher gehe ich davon aus, dass es gehen sollte.ist Unfug. Es gibt da keinen Unterschied zwischen Express und den Kaufversion.[/quote]
Ok, aber was habe ich dann daran falsch verstanden?
Jochen Kalmbach schrieb:
Vielen Anfänger, welche C/C++ lernen wollen, suchen sich nach einer kostenlosen Entwicklungsumgebung und stossen dann früher oder später auf die Visual Studio 2008/2010 Express Edition.
Und ein Anfänger will natürlich gleich sichtbare Erfolge sehen und beginnt logischerweise gleich mit einer Fenster-Anwendung.
Leider enthält die VC2008/2010 Express Edition nur WinForms als graphische Oberfläche. Deshalb entwicklen die meisten dann nicht mit C/C++, sondern mit C++/CLI, was eine komplett andere Sprache ist und für die meisten nur zu Verwirrung führt.
Ich Rate jedem Anfänger davon ab VC 2008/2010 Express Edition für graphische Oberflächen zu verwenden, aus folgenden Gründen:
- Der WinForms-Designer ist miserabel, da er die Implementierung von Methoden in der h-Datei vornimmt, was spätestens zu Problemen führt, wenn man mehr als ein Form hat und auf Methoden/Properties des anderen Forms zugreifen will (da man dann zyklische Abhängigkeiten in den h-Dateien hat, die man nur lösen kann, wenn man die Implementierung in die cpp-Datei verlegt)
- Wenn man die Anwendung verteilen will, so muss man neben dem .NET-Framework auch die C-Runtime installieren; das muss man bei einer reinen .NET-Anwendung (z.B. C#) nicht
- C++/CLI ist primär als InterOp Sprache zwischen .NET und native Code gedacht; das sieht man auch schon daran, dass seit VC2008 auch der Data-Wizward für C++/CLI entfernt wurde. Daraus ergibt sich gleich der nächste Punkt:
- Der Data-Wizard wurde in VC 2008 entfernt um auch deutlich zu machen, dass der Focus auf native-managed InterOp liegt
- Ca. 99% aller Beispiele im Internet sind mit C#; man findet fast keine Beispiele in C++/CLI
- C++/CLI ist eine eigene Sprache und hat mit (ISO) C/C++ nichts zu tun; und das ganze zu mischen ist meistens noch viel sinnfreier, es sei denn, man weiss was man tut (was zu 99% nicht der Fall ist; zumindest in den Fragen, die ich aus den Foren entnehme)
- C++/CLI wird oft als “Erweiterung” von C/C++ gesehen. Diese Sicht ist aber komplett falsch! Ganz einfacher Beweis: Versuch in einen STL-Vector ein CLR Objekt reinzustopfen (z.B. std::vector). Wenn es gehen würde, dann könnte man C++/CLI als Erweiterung sehen. Es geht aber nicht. Deshalb sind es zwei komplett getrennte Welten!
- In VS 2010 wird es für C++/CLI Projekte kein Intellisense geben; das deutet auch stark darauf hin, dass es nicht als primäre Sprache für .NET geeignet ist
Empfehlung für Anfäger:
Wenn Ihr unbedingt graphische Oberflächen (RAD) machen wollt, dann nehmt lieber C# (gibt es auch als Express Edition).
Wenn Ihr wirklich C/C++ lernen wollt, dann nehmt die Professional-Version mit der MFC oder eine freie GUI-Bibliothek wie wxWidgets, GTK oder QT.Empfehlung für Microsoft:
Wenn Ihr auch mit VC++ Anfänger erreichen wollt, dann liefert bitte die MFC in der Express-Edition mit; oder bindet von mir aus wxWidgets einDurch diesen Beitrag bin ich von einem Unterschied ausgegangen.
Ehrlichgesagt hätte ich eine Frage in diesem Bezug. Unterscheidet sich C++/CLI komplett von C/C++? Also würde es für mich einen Unterschied bedeuten, wenn ich C/C++ für die Konsolenprogramme und C++/CLI für GUI verwende oder ob ich C/C++ für Konsolen und C# für GUI verwende?
-
Nochmals an ALLE,
ich habe sicher nicht die Absicht mit unqualifizierten fragen und Beiträgen das Forum zu belasten und euch eurer Zeit zu berauben.
Aber wie man meiner Beiträge entnehmen kann hänge ich irgendwie in der Luft.
Ich danke den Vereinzelten trotzdem für ihre Gedult.
-
C++/CLI ist dazu gemacht die unmanaged Welt (also hauptsächlich C und C++) und die Managed Welt (C#, VB.net usw.) miteinander zu verbinden.
Dafür ist es gut. Und nur dafür. Ganz bestimmt nicht dafür C++ zu lernen.
Dieser Formulardesigner, den du da benutzt, ist eher Spielzeug. Er erzeugt grottenschlechten Code und ist unzuverlässig.
-
Nach dieser klaren Antwort und den vielen Beiträgen darüber, dass es mehr Beispiele zu C# gibt, darf ich das nun für einen der es eh noch lernen muss als Rat sehen sich lieber gleich C# an zu eigenen?
Dann schau ich mir die Geschichte mal an. Und danke nochmals.
-
C# sollte man sowieso können, wenn man C++/CLI verstehen will. Das halte ich für eine Vorbedingung.
Was du also machen könntest, ist GUI-Programmierung in C# lernen, bei C++ erstmal bei der Konsole bleiben. Wenn du beides einigemassen kannst, kannst du immer noch mittels C++/CLI deinen C++ Code von C# aus benutzen. Das wird aber selten nötig sein.
Alternativ kannst du mit Visual Studio auch GUIs in C++ schreiben, z.B. recht einfach als Dialoganwendung mit der MFC. Oder schau dir Qt an, das kann man auch in Visual Studio integrieren.
Es gibt da viele Wege, eventuell erkundigst du dich mal, was in deinem Kurs vorkommt. (Sollte es C++/CLI sein, wechsle den Kurs
-
fuchsle schrieb:
Bin ein Neuling was das C/C++ programmieren betrifft. Und stehe vor der "einfachen" Aufgabe werte in einer INI Datei zu manipulieren
Noch Fragen!?
Die Express Edition hat...
...keine MFC
...keinen Ressourcen Editor
...keinen Weitergabe-Assistenten
-
ich mach mich mal schlau was in meinem Kurs dran kommen soll. Aber danke dir erstmal.