ich möchte mit einem Kumpel zusammen ein kleines Projekt programmieren, in welchem wir uns bestimmte Aufgabenbereiche teilen wollen.

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?

Ich habe im Internet bereits einen C++ to VB Konverter gefunden, jedoch wäre uns das nicht so lieb, denn wer weiß, was das Ding für Code erzeugt und bei größeren Projekten wäre ein solcher Converter eventuell nicht sonderlich zuverlässig?

Hat jemand eine Idee, wie wir das umsetzen können?

Gruß

nki

Natürlich wäre es möglich einen Wrapper zu schreiben, der euch die Sprachabhängigen Konstrukte verbirgt. Also anstatt std::string zu benutzen, schreibt ihr einne Wrapper, der my::string heisst, oder so. Alles sehr frickelig.

Also würde ich euch eher raten eine Sprache zu wählen (Wobei es halt auf das Projekt ankommt, welche geeigneter ist) und dann hald die andere Sprache zu gebrauchen. Soo schwer ist der Umstieg ja meist nicht.

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

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

C++/CLI und VB.NET ja - ISO C++ und VB.NET nicht.
Ich erachte jedoch C++/CLI nicht für Anfänger geeignet.

Gruss Simon

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é

und unter .Net ist nunmal C# das Optimale

Schwachsinn.

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é

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.

Laut MS ist C++/CLI unter .NET das optimale:
http://msdn.microsoft.com/en-us/library/ms379617.aspx

Das ist auch nicht die Meinung von Microsoft sondern die von Kenny Karr. Außerdem steht da nichts von optimal sondern nur von „most powerful“.

Laut MS ist C++/CLI unter .NET das optimale:
http://msdn.microsoft.com/en-us/library/ms379617.aspx

Der 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é

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.

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é

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.

...

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

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

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é

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.

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.

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