Tutorial für VC++ 2005 Express?
-
Allerdings bestätigt es mich bei meiner Praxis zu bleiben C++/CLI nur für Wrapperklassen zu gebrauchen, um unmanged C++ objektorientiert in C# ansprechen zu können
Was kann C++ dafür wenn der Anwender die Namensräume nicht auseinander halten kann ?
Eventuell hat ja auch das Objekt "this" einfach ein Element mit dem Namen MouseButtons .
Man könnte die Zeit, die man benötigt um C++/CLI die Schuld zu geben, auch mit dem Thema Namensräume verbringen - und schon wirkt es nicht mehr so komplex
Annehmend das es bei euch in etwa so ausschaute:
namespace EentTest { using namespace System; using namespace System::ComponentModel; using namespace System::Collections; using namespace System::Windows::Forms; using namespace System::Data; using namespace System::Drawing;Klappt ein MouseButtons nicht, da es ein Member innerhalt der Form gibt das so benannt ist. Man muss dem Compiler nun mitteilen was man genau will.
Ein ::MouseButtons klappt nicht, da der Namensraum System::Windows::Forms NICHT im globalen Namensraum steht. Man kann also nur die using Anweisungen in den globalen Namensraum verschieben (was bei Headern keine gute Idee ist), alles sauber nach Definition und Deklaration trennen oder den Namensraum vollständig angeben.
-
Was kann C++ dafür wenn der Anwender die Namensräume nicht auseinander halten kann ?
Was kann der Anwender dafür, wenn der Formulareditor solch unübersichtlichen Code produziert ?
Während man es in C# geschafft hat mit partial Classes den IDE generierten Teil
des Quelltextes in eine separate Datei zu speichern, müllt man in C++, wo man die
Möglichkeit zur Aufteilung hätte, die ganze Headerdatei voll.Da war Borland schon vor zehn Jahren besser.
-
Die IDE ersetzt nicht das Denken beim Programmieren.
Die definition des Formdesigners zur Deklaration zu machen und neu in einer .cpp zu definieren ist wohl für einen Entwickler nicht zu viel verlangt - man müsste dann aber schon wissen was man macht - vorallem wenn man die Trennung nicht vornimmt.
C++ ist KEINE Sprache in der man sich alles zusammenklicken kann. Der Formdesigner ist im Zusammenhang mit C++ insgesammt alles andere als schön und bequem, für Wissenslücken des Entwicklers kann er aber nichts. Er kann auch keine C++ Regeln aushebeln.
Das Problem lässt sich also auf eine Wissenslücke zurück führen (was ja nicht wild ist, die Erklärung wie C++ das sieht steht weiter oben). Ich sehe hier kein verschulden der Sprache, auch wenn man sich in C# scheinbar wesentlich weniger Gedanken um Typen machen muss man aber ähnliche Probleme erzeugen kann.
Das hier ist, aufgrund schwacher C# kentnisse, künstlich erzeugt - jedoch wird man solche Dinge in der Praxis auch antreffen:
namespace hjk { enum a {x = 13} public partial class Form1 : System.Windows.Forms.Form { enum a { y = 13, z = 14,x=13 } private void foobar(hjk.a x) { if (x == a.y) x = a.x; } } }Hier muss nun auch der Namensraum angegeben werden weil die Namensauflösung der Sprache nicht das passende Element erkennt. In dem Falle wäre es aber der Entwickler der das Problem erzeugt, bei C++/CLI ist es die IDE ?
-
Knuddlbaer schrieb:
bei C++/CLI ist es die IDE ?
Das habe ich so nicht gesagt. Meine erste Antwort habe ich ohne es auszuprobieren gegeben. Danach habe ich mich ja in einen zweiten Posting korrigiert.
Das Namensraumproblem habe ich ja am Intellisense gesehen. Deswegen habe ich ja gesagt, es irritiert mich, weil ich diese Kollision in C# nie gesehen habe.
Die Combo C# und C++ setze ich seit fünf Jahren produktiv ein und nichts was du hier schreibst überzeugt mich davon, dass C++/CLI besser ist. Eher habe ich den Eindruck man muss sich um Probleme kümmern, die man in C# gar nicht hat.
Aber sei beruhigt, ich werde mich in Zukunft hier nicht mehr einmischen.
Tschüß
-
Ein Tutorial habe ich zwar immer noch nicht gefunden, aber
dafür etwas nicht weniger nützliches: In der MSDN gibt es
eine Übersicht für äquivalente .Net-Befehle, die sich
bereits als hilfreich herausgestellt hat.http://msdn2.microsoft.com/en-us/library/aa302340.aspx
Alex
-
Niemand sagt das C++/CLI besser ist als C#.
Ja, man muss sich um viele Probleme kümmern die man sicherlich in C# nicht hätte, das ist nunmal der Preis für die Flexibilität die man zahlt. (Alleine der Aufwand durch die Dokumentation zu steigen ist enorm).
Nichts was Du schreibst überzeugt mich davon das C# die einzige Variante ist Dialoge zu erstellen. Kommt also auf eine Glaubensfrage alla C++ vs. Java heraus. Ich sehe aber keinen Grund C# als einzig sinnvolles Mittel fürs Desginen von Formen zu preisen.
Den Link von LionAM ( http://msdn2.microsoft.com/en-us/library/aa302340.aspx ) hätte ich gerne in der FAQ gesehen, so unnütz ist der garnicht.
-
Knuddlbaer schrieb:
Kommt also auf eine Glaubensfrage alla C++ vs. Java heraus.
Hier ein paar Argumente für meine Position:
http://forums.microsoft.com:80/MSDN/ShowPost.aspx?PostID=1032378&SiteID=1
The largest use of C++/CLI is within this interop scenario – i.e. the bridging between native and managed code.
After reviewing the data, our team has decided to refine the product direction.
With this change we will focus less on making Visual C++ a “pure” .NET development tool. This decision is supported by the fact that Microsoft already has tools in Visual C# and Visual Basic that meet the needs of .NET developers. By not having to map to all the new aspects of.NET (such as LINQ or WPF designers), our team can concentrate on building better native and interop features. Despite these changes, please note that we will continue to provide support for C++/CLI as it is fundamental to our interop strategy.
-
thx - werde mal mit den Stichworten die dazu gehören dort ein wenig lesen.
Die Richtung finde ich schade nachdem es sehr viele Verbesserungen im Zusammenhang mit C++/CLI gab - ich denke das diese Linie die dort angestrebt wird nicht vollständig gehalten wird.
Angesicht dessen was man dort liest kann es jedenfalls nicht schaden für neue Projekte mehr C# zu beanspruchen.
(Werde jetzt mal da schmökern gehen)
Schade wo es doch einen neuen Standart mit Möglichkeiten für C++ geben wird und MS doch angekündigt hatte ne mangedcode fähige STL zu liefern
-
Hmm...
http://msdn.microsoft.com/msdnmag/issues/01/07/ctocsharp/
Wenn ich das nach heutigem Standpunkt vergleiche bleibt - bis auf das C# kein Destruktor kennt - kein techischer Unterschied zu C#.
Auch damals wurde die Aussage getroffen, das man C# nehmen muss und C++/CLI kein einzug ins Framework erhält. Dann konnte man doch Managed Code schreiben , dann kam C++/CLI. Wäre schade wenn man nun doch das , was man vor Jahren haben wollte, nach all den Anstrengungen einfach weg wirft.
Man kann also dem ganzen gespannt entegegen schauen und die Lücken für C# nutzen um - sollte man das wirklich war machen - nicht von 0 aus starten zu müssen.
-
Ich sehe es im Prinzip genauso. Man sollte sich alle Optionen offenhalten.
Einen Aspekt der Combo C#/C++ habe ich noch gar nicht angesprochen:
Architektur.
Man hat eine saubere Trennung zwischen managed und unmanaged Code. Wir haben hier mehrere Anwendungen, die aus std C++ Logik bestehen und auswechselbare Oberflächen haben (C#, MFC, Delphi, QT (Win/Linux)).
Das haben wir, wie gesagt, seit 2002 produktiv im Einsatz.
Aber natürlich verwenden wir auch C++/CLI, sonst wäre ich ja nicht hier. Aber nur in komplexen Interop-Szenarien, wo das PInvoke von C# zu viel Arbeit macht, oder mehr Objektorientiertheit gewünscht ist.
-
Hmm... Gut, dann mal Danke fürs gegenhalten, hat mich wach gerüttelt. Ich werde zwar noch ne lange Zeit versuchen so viel wie Möglich in C++ zu machen (ich fühle mich da derzeit wohler weil ich die Resourcen besser unter Kontrolle habe) aber sehe ein das ich mich nicht vor C# drücken kann
(Was ich bisher gelesen hab an C# gegen C++ war ein hervorheben von C#, was da alles besser geht. Aber es gab nichts was nicht genauso in C++ ging oder genau diesen Regeln unterlag. Daher auch C# ein wenig zur Seite gelegt und nur die Beispiele verwendet um diese nach C++/CLI zu bringen.)