C++ und VB.NET?
-
Hallo
VB.NET deutet auf MS Visual Studio hin. Das erlaubt die Kombination der beiden Sprachen in einem Projekt, sie als Einführung hier.
bis bald
akari
-
akari schrieb:
Hallo
VB.NET deutet auf MS Visual Studio hin. Das erlaubt die Kombination der beiden Sprachen in einem Projekt, sie als Einführung hier.
bis bald
akariC++/CLI und VB.NET ja - ISO C++ und VB.NET nicht.
Ich erachte jedoch C++/CLI nicht für Anfänger geeignet.Gruss Simon
-
nki schrieb:
Nun haben wir ein "kleines" Problem: ich programmiere C++ und er VB.NET, jedoch möchte keiner von uns die Sprache wechseln.
Gibt es irgendwelche Möglichkeiten, dass wir dennoch zusammen arbeiten können? Dass ich z.B. seine Klassen in mein Projekt integrieren kann und/oder umgekehrt?
Es gibt mehrere Möglichkeiten, aber das Beste wäre dennoch wenn einer - oder beide - die Sprache ändert. Ein sinnvoller Kompromis wäre hier vermutlich C# (Und man kann VB.Net mit C# kombinieren, sinnvoller wäre aber wirklich wenn ihr beide eine gemeinsame Sprache findet - und unter .Net ist nunmal C# das Optimale).
cu André
-
asc@ausgeloggt schrieb:
und unter .Net ist nunmal C# das Optimale
Schwachsinn.
-
Konrad Rudolph schrieb:
asc@ausgeloggt schrieb:
und unter .Net ist nunmal C# das Optimale
Schwachsinn.
Warum Schwachsinn?
C# ist mit .Net im Einklang entstanden und daraufhin ausgerichtet (im Gegensatz zu VB.Net und C++/CLI, wo Sprachen an ein Framework angepasst wurden sind). Und auch die die Unterstützung von Sprachfeatures sind hier etwas weiter als z.B. VB.Net (zumindestens wenn man vielen Fachbüchern und auch Microsoft selbst glauben schenken mag).
cu André
-
Laut MS ist C++/CLI unter .NET das optimale:
http://msdn.microsoft.com/en-us/library/ms379617.aspx
-
ihr könntet auch den weg gehen, COM-Objekte zu erstellen, die kann dann jeder in der jeweils anderen Umgebung nutzen, natürlich geht das nur so lange, wie ihr euch auf einem Windows-System befindet, afaik wurde COM nie auf ein anderes OS portiert. Ist natürlich für beide auch wieder eine gewisse Einarbeitungszeit von Nöten, allerdings könnt ihr dann eure Komponenten gegenseitig austauschen
-
asc@ausgeloggt schrieb:
Konrad Rudolph schrieb:
asc@ausgeloggt schrieb:
und unter .Net ist nunmal C# das Optimale
Schwachsinn.
Warum Schwachsinn?
Weil das hier:
C# ist mit .Net im Einklang entstanden und daraufhin ausgerichtet (im Gegensatz zu VB.Net
falsch ist.
CLR, CTS, C# und VB.NET wurden absolut parallel entwickelt. Weder C# noch VB sind eher für .NET geeignet. Es gibt auch keine einseitige Entwicklung. In .NET wurde einiger Aufwand betrieben, um VB.NET zu gestalten, ohne allzu große Brüche zu VB6 vorzunehmen. Das Ziel wurde zwar gründlich verfehlt, trotzdem hatte das Design von VB6 ganz erheblichen Einfluss auf .NET (und damit auch auf C#).
Im übrigen ist auch C# nicht aus dem Nichts entstanden. Jeder, der schon mal mit Java programmiert hat, sollte das merken.
Und auch die die Unterstützung von Sprachfeatures sind hier etwas weiter als z.B. VB.Net (…).
Die Aussage ist schlicht und ergreifend falsch. Ich weiß nicht, aus welchem Fachbuch die stammen soll, das ändert aber nichts. C# und VB sind, was die Features angeht, nicht ganz identisch, und jede der Sprachen hat ihre Eigenheiten.
Von einer Version auf die andere werden solche Eigenheiten oft ausgebügelt, dafür aber neue eingeführt. Das gilt aber sowohl für C# als auch für VB.
-
HansiHinterseher schrieb:
Laut MS ist C++/CLI unter .NET das optimale:
http://msdn.microsoft.com/en-us/library/ms379617.aspxDas ist auch nicht die Meinung von Microsoft sondern die von Kenny Karr. Außerdem steht da nichts von optimal sondern nur von „most powerful“.
-
HansiHinterseher schrieb:
Laut MS ist C++/CLI unter .NET das optimale:
http://msdn.microsoft.com/en-us/library/ms379617.aspxDer Artikel ist mir tatsächlich neu, nur unterstütze ich den aus einen Grund nicht:
Neben Effizienz ist Wartbarkeit eine sehr wichtige Eigenschaft, C# liest sich besser als C++/CLI, das den Nachteil hat das die Sprache nachträglich an .Net angepasst wurden ist, und in einigen Punkten kryptisch erscheint.
Zudem fehlt C++/CLI einiges an Features (u.a. die UI-Designer, die unterstützung von partiellen Klassen... letzteres macht z.B. das Arbeiten mit dem .Net Framework 3.0 und höher zwar nicht unmöglich, erschwert es aber. So kann man zum Beispiel WPF und XAML zwar auch ohne partielle Klassen verwenden, es kompliziert die Sache aber spürbar).
cu André
-
Konrad Rudolph schrieb:
Die Aussage ist schlicht und ergreifend falsch. Ich weiß nicht, aus welchem Fachbuch die stammen soll, das ändert aber nichts. C# und VB sind, was die Features angeht, nicht ganz identisch, und jede der Sprachen hat ihre Eigenheiten.
Kannst Du Beispiele nennen? Ich habe es bisher ausschließlich so erlebt, dass Features in VB.NET entweder zeitgleich mit oder eine Version nach C# eingeführt wurden.
-
Konrad Rudolph schrieb:
Das Ziel wurde zwar gründlich verfehlt, trotzdem hatte das Design von VB6 ganz erheblichen Einfluss auf .NET (und damit auch auf C#).
VB6 hatte ebenso Einfluß wie alle anderen großen Sprachen zu der Zeit. Ich behaupte auch nicht das C# aus dem Nichts entstanden ist, so hat es zum Beispiel Einflüsse von C++, Java, VB... aber die Entwicklung wurde speziell für das .Net Framework gemacht - Im Gegensatz zu VB.Net und C++/CLI die darauf (mehr oder weniger gut) angepasst wurden.
cu André
-
asc@ausgeloggt schrieb:
Im Gegensatz zu VB.Net und C++/CLI die darauf (mehr oder weniger gut) angepasst wurden.
Du interpretierst den Entwicklungszyklus von VB falsch. Die Sprache hat zwar noch denselben Namen ist aber faktisch eine andere (wenn auch verwandte) Sprache als VB6, genauso wie C# eine andere (wenn auch verwandte) Sprache als C ist.
LordJaxom schrieb:
Konrad Rudolph schrieb:
Die Aussage ist schlicht und ergreifend falsch. Ich weiß nicht, aus welchem Fachbuch die stammen soll, das ändert aber nichts. C# und VB sind, was die Features angeht, nicht ganz identisch, und jede der Sprachen hat ihre Eigenheiten.
Kannst Du Beispiele nennen? Ich habe es bisher ausschließlich so erlebt, dass Features in VB.NET entweder zeitgleich mit oder eine Version nach C# eingeführt wurden.
- Hintergrundkompilierung
Wird Schritt für Schritt in C# eingeführt, ist aber noch weit hinter VB zurück. - XLinq
Inline-XML im Code, und das Importieren von XML-Namensbereichen in den Code. - Implizites 'Select'
VB erlaubt, bei Linq die Standard-'Select'-Klausel wegzulassen (was logisch ist, weil es, übersetzt, einem Aufruf von '.Select(x => x)' gleichkommt, also der Identität. - 'My'-Namensbereich
Soweit ich weiß, wurde der Plan, das nach C# zu übernehmen, inzwischen vollständig aufgegeben. Hierbei handelt es sich aber nicht nur um eine nützliche Shortcut-Sammlung sondern hier wird vom Compiler auch spezieller Code für die aktuelle Anwendung generiert, z.B. eine streng typisierte Liste der im Projekt enthaltenen Forms. Die streng typisierte Settings- und Ressourcen-Liste (unter C# erreichbar über 'Projektnamespace.Properties.Resources' bzw. 'Projektnamespace.Properties.Settings') kommt auch hierher. - IntelliSense
War anfangs in VB um Längen besser als in C#. In Version 2005 hat C# dann VB überholt und besseren IntelliSense angeboten. Inzwischen (VS 2008) ist VB aber wieder vorne: IntelliSense ist überall verfügbar. In C# nach wie vor nur an gewissen Trigger-Positionen. - 'MyClass'
Das Äquivalent zu einem 'call' in CIL, existiert in C# überhaupt nicht, hier wird *immer* ein virtueller Methodenaufruf verwendet. - 'Is'
Referenzvergleich, geht in C# nur über 'object.ReferenceEquals'. Man kann zwar auch einfach den Operator '=' verwenden, wenn dieser überladen wird, hat er aber eine andere Semantik und führt *keinen* Referenzvergleich mehr durch. Das Resultat sollte zwar stets identisch sein, leider ist das aber nirgendwo garantiert, außerdem ist es ineffizienter. Der VB-Operator 'Is' hingegen wird direkt in eine IL-Anweisung übersetzt. - 'DirectCast' vs. 'CType'
C# besitzt nur zwei Typecasts, '(T)x' und 'x as T'. VB besitzt drei. 'DirectCast' ist ein spezieller Cast-Operator, der nur Upcasts und Unbox-Aktionen zulässt und bei allen anderen Casts den Dienst verweigert. Dadurch ist er effizienter und lesbarer als der allgemeine Typecast.
Gerade die letzten drei Punkte finde ich persönlich interessant, weil sie in VB einige IL-Befehle freischalten, auf die man in C# weder direkt noch indirekt kontrolliert zugreifen kann.
Die Liste ist übrigens nicht vollständig, mehr fallen mir aber gerade nicht ein. Die nächste VB-Version wird aber wahrscheinlich wieder eine Fülle neuer Features einführen, über die C# nicht in der Art verfügt. Man schaue sich einfach mal Paul Vicks Blog an.
/EDIT: Oh, und natürlich native DLR-Unterstützung und generell den ganzen Kram, der mit late binding zu tun hat.
- Hintergrundkompilierung
-
Konrad Rudolph schrieb:
...
Über einige der Features lässt sich streiten, und es geht natürlich in beide Richtungen. Sofern es sich nicht geändert hat z.B.:
a) C# ist im Gegensatz zu VB Standardisiert, und es gibt auch Umsetzungen für andere Betriebssysteme.
b) Anonyme Methoden
c) Statische Klassen
d) Zugriffskontrolle für Properties (getrennt nach set/get)
...Unabhängig davon (aber dies ist subjektiv) entfinde ich C# als deutlich leichter lesbar, logischer und konsistenter. Zudem scheint sich C# tatsächlich immer mehr zu DER Sprache unter .Net zu mausern (Ausnahmen sind z.B. Office Automatisierung). Aber auch das mögen meine Subjektiven Eindrücke sein.
-
asc schrieb:
Konrad Rudolph schrieb:
...
Über einige der Features lässt sich streiten, und es geht natürlich in beide Richtungen. Sofern es sich nicht geändert hat z.B.:
Klar, darum ging es doch aber gar nicht. Eine Liste von Features, die VB aber nicht C# hat, wäre noch viel länger. Es ging hier explizit nur um die (konsequente) Adaptation der .NET-Features in den Sprachen.
a) C# ist im Gegensatz zu VB Standardisiert, und es gibt auch Umsetzungen für andere Betriebssysteme.
VB gibt es inzwischen auch für Mono. Was die fehlende Standardisierung betrifft: Die ist meiner Meinung nach in der Tat das größte Manko, und ist mir (und anderen VB-Entwicklern) auch ein gewaltiger Dorn im Auge.
b) Anonyme Methoden
Hat VB.
c) Statische Klassen
VB hat was „besseres“, nämlich Module. Ich habe sogar überlegt, das in meine Aufzählung aufzunehmen, das hatte VB nämlich schon, *bevor* C# statische Klassen hatte, die wurden dann nachgerüstet.
d) Zugriffskontrolle für Properties (getrennt nach set/get)
Hat VB auch, und zwar schon genauso lange wie C#.
Unabhängig davon (aber dies ist subjektiv) entfinde ich C# als deutlich leichter lesbar, logischer und konsistenter.
Eben, das ist subjektiv, ich finde größtenteils das Gegenteil. Wobei ich keiner Sprache eindeutig den Vorzug geben mag, da beide Sprachen und Schwächen haben.
Zudem scheint sich C# tatsächlich immer mehr zu DER Sprache unter .Net zu mausern (Ausnahmen sind z.B. Office Automatisierung). Aber auch das mögen meine Subjektiven Eindrücke sein.
Ja, sind es. MS-intern wird z.B. immer noch davon geredet, dass VB mehr Benutzer hat, wobei C# aufholt. Im Hinblick auf die DLR scheint Microsoft C# und VB stärker positionieren zu wollen und bei VB den Charakter als dynamische Sprache hinzuzufügen (d.h. optional agiert vollwertiges VB dann als „Skript“sprache).
-
Hi,
danke für die zahlreichen Antworten und Lösungsansätze
Ich habe heute nocheinmal bei mir in der Firma in der Entwicklungsabteilung nachgefragt und einiges, was ihr hier erwähnt habt, ebenfalls gehört.
Wie ist es jetzt genau mit der DirectX-Programmierung?
Ich weiß nur soviel, dass DirectX durch XNA "ersetzt" wird, wenn ich diesen Weg (.NET) einschlagen sollte.
Was ist da dran? Und was würdet ihr mir diesbezüglich empfehlen? C# oder C++/CLI?
Gruß
nki
-
nki schrieb:
Was ist da dran? Und was würdet ihr mir diesbezüglich empfehlen? C# oder C++/CLI?
Tendenziell C#. Nichts gegen C++/CLI, ich sehe dessen Stärken aber vorwiegend als Proxy zwischen der Managed- und Unmanaged-Welt (Wobei ich die Sprache nicht uninteressant finde). Die Syntax wurde zwar gegenüber managed C++ deutlich verbessert, wirkt aber weniger lesbar und der Einstieg ist auch schwerer (zumal man kaum Beispiele für C++/CLI, aber massig für C# und VB findet).
cu André
-
Also wenn ihr etwas macht, dass Wert auf Performance legt würde ich von .NET erstmal abraten und einfach C++ verwenden. (Was ich jetzt mal annehme, wenn du DirectX sagst).
Zur VB/C# Diskussion:
Ich habe einen älteren Herren kennengelernt, der auch VB entwickelt und der hat als ein Argument angegeben, dass er die {,} usw. nicht mag, weil man die so schlecht sieht/übersieht. Ich hatte leider nicht die Chance länger darüber zu reden und weiss daher nicht so genau, wie ernst es ihm damit war.
-
drakon schrieb:
Also wenn ihr etwas macht, dass Wert auf Performance legt würde ich von .NET erstmal abraten und einfach C++ verwenden. (Was ich jetzt mal annehme, wenn du DirectX sagst).
C# kann auch performant sein. Das C++ tendenziell schneller ist, okay (wobei dies wenn ein Codeblock häufig ausgeführt wird noch nicht mal zwangsweise so ist!), aber es stimmt ebenso das DirectX immer mehr Richtung .Net angepasst wird.
Ich bin selbst ein Fan von C++, sehe aber die ewigen Performancegeschichten nicht mehr so nachdem ich mich etwas mehr mit der Materie auseinander gesetzt habe. Man muss dann abwägen was in der Situation sinnvoller ist.
cu André
P.S: Ich komme selbst auch von einen Basicdialekt, den ich auch heute noch gut finde, nur mit VB konnte ich mich noch nie anfreunden (wobei ich Ausrutscher auch in diese Sprache machen musste).
-
C# kann auch performant sein. Das C++ tendenziell schneller ist, okay (wobei dies wenn ein Codeblock häufig ausgeführt wird noch nicht mal zwangsweise so ist!), aber es stimmt ebenso das DirectX immer mehr Richtung .Net angepasst wird.
Klar. Eine abwägung ist auf jeden Fall angebracht. Aber ich persönlich legen sehr viel Wert auf Performance und gehe da auch recht auf die Jagd nach mehr und darum will ich nicht bereits durch die Sprache eingeschränkt sein.
