C++ und VB.NET?

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é

Konrad Rudolph

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.

asc

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.

Konrad Rudolph

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).

nki

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

asc

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é

drakon

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.

asc

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).

drakon

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.

nki

Danke für eure Ratschläge!

Was ich bisher so gehört habe, werde ich wahrscheinlich eher zu C# tendieren.

Ich hab es mir vorhin schonmal angeschaut und eine kleine WinApp erstellt. Auf den ersten Blick war's etwas ungewohnt, gerade weil #includes so direkt nicht mehr unterstützt werden, soweit ich das bisher beurteilen kann. Stattdessen wird vielmehr mit Namespaces gearbeitet.

PS: Kennt sich jemand mit XNA aus? Das soll doch die DirectX-Schnittstelle (auch von MS) für C# sein, soweit ich weiß oder? Gibt es große Unterschiede zwischen DX und XNA?

Gruß

nki

drakon

Afaik geht das sehr gut. Wenn du DX bereits kennst, ist glaube ich vieles recht ähnlich und du solltest beim Umstieg keine grosse Mühe haben.