Hallo an alle Forum-Mitglieder,

ich habe früher viele Jahre lang VB6 programmiert und wollte nun seit einigen Jahren Programmierpause wieder in das Thema einsteigen...jedoch in Visual Basic 2010.
Nun wird ja sowieso alles in den CLI-Code umgewandelt, und da ich schon mit VB6 sehr zufrieden war, sehe ich keinen Grund, nicht weiter bei Visual Basic zu bleiben (anstatt C# oder C++/CLI).

Ein was würde mich jedoch brennend interessieren:
Ich bin in der Sprache C recht fit. Schon oft habe ich gelesen, dass man in C eine DLL schreiben kann (in dieser Code/Funktionen ablegen kann) und die DLL dann einfach in VB.NET einbinden kann.
Was läuft da genau ab? VB.NET braucht ja das FrameWork als Laufzeitumgebung und alles geschieht aus direkter Umsetzung aus dem CLI-Code. Ist es jetzt wirklich so, dass der gesamte Code aus der C-DLL (welcher bereits in Maschinensprache ist) bei Aufruf der Funktionen in absoluten C-Eigenschaften ausführbar ist (also die Geschwindigkeit, Hardwarenähe, usw), ohne dass das FrameWork da einen Strich durch die Rechnung zieht?

Bzw., könnte man als grobes Beispiel mit VB.NET einfach nur eine GUI aufbauen und sämtliche Funktionen zu Berechnungen in C-Schreiben, welche exakt so schnell sind, als hätte man ein reines C-Konsolen-Programm? (sowas habe ich natürlich nicht unbedingt vor...soll nur ein Beispiel sein)

Ich bin leider neu in der ganzen Framework-Geschichte und hoffe, dass meine Frage nicht lächerlich ist
Man ließt nur immer wieder, dass .Net-Programme sehr langsam sein sollen, sogar im Vergleich zu VB6 und Java (wer weiß ob da was dran ist). Wenn ich nun aber weiß, dass ich die Möglichkeit habe, zeitkritische Funktionen trotzdem in C oder sogar darin noch mit Inline-Assembler zu schreiben und einfach so in mein VB.Net Programm einbinden kann, als wäre die Funktion in VB.NET geschrieben, freut mich das

Liebe Grüße,
Andi

sehe ich keinen Grund, nicht weiter bei Visual Basic zu bleiben (anstatt C# oder C++/CLI).

Kennst du beide auch nur ein kleines bisschen?
Das ist nicht nur ne neue Version. Das ist ne total neue Sprache.
Alleine, dass du in VB.NET auf OOP zurückgreifst sollte es schon zu 100% rentabel machen.
Dazu kommt ein rießiges und wunderbares framework usw...

Was die C-DLL angeht. Ja.
Du kannst über das DllImport Attribut Funktionen aus der DLL ausführen. Natürlich läuft der C/ASM-Code dort drinnen mit voller geschwindigkeit. Lediglich Marshalen usw. kann ein ganz ganz klein wenig Zeit in anspruch nehmen. Aber das merkt absolut niemand.

Andi_VB schrieb:

Man ließt nur immer wieder, dass .Net-Programme sehr langsam sein sollen

Hängt vom Entwickler ab.

Oh das hab ich gar nicht gelesen.
Sehr langsam... kann ich nur erwiedern. Hatte bisher noch nie performance probleme, dass iwas zu langsam gewesen wäre und ich habe auch schon performance aufwendige dinge gemacht wie z.b.
Realtime audio decoding + fft + ... usw. und das alles ohne performance probleme. Aber wenn es dir wirklich soo um performance geht kannst du bei c# natürlich auch nochmal nen bisschen was rausholen (unsafe).
Ich würde, wenn du eh schon c programmierst eher auf c# umsteigen.

Aber mal ganz im ernst. Um performance würd ich mir wirklich zu letzt sorgen machen.

.NET-Exe <=> C-DLL - kein Problem. Sieh Dir mal dieses Tut an.

Hi,

danke für die vielen Antworten.

Kennst du beide auch nur ein kleines bisschen?

Naja, Visual Basic 6 hab ich etwa 7 Jahre lang programmiert...hab vor kurzem angefangen mich etwas in Visual Basic 2010 einzulernen. Es ist schon etwas anders als VB6 aber ich finde es trotzdem sehr ähnlich...bzw sagen wir mal genauso leicht :)
In C# hab ich nur mal in Büchern geschnuppert, wie es da so vom Code her aussieht.

Auf meinem Windows 7 x64 Rechner läuft VB6 sehr unstabil...und da man schon zu Windows XP Zeiten nur mit Tricks den üblichen Windows XP Themen Stil zu seinen Anwendungen bekommen hat, hab ich jetzt einfach den Entschluss getroffen, voll auf .NET umzusteigen.

Natürlich habe ich mir sehr viel Gedanken über die zukünftige Sprache gemacht. Es gibt ja etliche Glaubenskriege zwischen C# und VB.Net Aber letztendlich war das Ergebnis immer so, dass es absolut egal ist, ob eine Anwendung in VB oder C# programmiert ist, da bei beiden am Schluss der gleiche CLI-Code rauskommt. Und dann blieb nur die Wahl zwischen .Net allgemein oder zB Java (auch wieder etliche Glaubenskriege)...wobei mir diese Entscheidung sehr viel schwerer fiel und ich mir wahrscheinlich immer noch nicht ganz sicher bin.

Man ließt nur immer wieder, dass .Net-Programme sehr langsam sein sollen

Hängt vom Entwickler ab.

Ja das schon, aber so wie manche leute es darstellen, muss VB.Net um Welten langsamer sein als VB6. Wobei ich mit der Geschwindigkeit von VB6 vollstens zufrieden war.
Ich kann mir das aber irgendwie nicht so vorstellen...die Technik wird doch normal immer besser anstatt schlechter

Aber wenn es dir wirklich soo um performance geht kannst du bei c# natürlich auch nochmal nen bisschen was rausholen (unsafe).

Ich würde, wenn du eh schon c programmierst eher auf c# umsteigen.

Das ist ja eben der Punkt...abgesehen von Syntaxähnlichkeiten soll C# eine absolut andere Sprache als C sein und mit C# und VB sollen auch die gleichen Möglichkeiten existieren und auch den gleichen Code erzeugen. Deshalb sah ich nicht unbedingt einen Grund, auf C# zu wechseln. Sprich: C# und VB können gleich schnell sein, wenn man beide Sprachen richtig anwendet. Gegen C# sprach für mich eher die Syntax, welche ich in C wirklich furchtbar im Vergleich zu VB finde. Allgemein ist C wirklich furchtbar im Gebrauch, wenn man es mit VB vergleicht

Also Performance ist mir nicht so wichtig, solange die Anwendung nicht ruckelt...also jedenfalls nicht sooo wichtig, dass ich auf Windows jetzt mit C++ und Qt oder so programmieren sollte. Hauptsache es hält mit VB6 mit Nun kann es aber passieren, dass in einer einfachen GUI-Anwendung doch mal was flottes dabei sein muss und so hab ich jetzt ein gutes Gefühl, da die Möglichkeit besteht

.NET-Exe <=> C-DLL - kein Problem. Sieh Dir mal dieses Tut an.

Ja das Tut hatte ich auch gelesen. Zu VB6 Zeiten habe ich auch DLLs erstellt und immer darauf zugegriffen. In dem Tut konnte ich jedoch nicht erkennen, ob es genauso einfach geht und ob man die DLL jetzt mit Visual Studio erstellen muss oder auch mit dem GNU GCC (MinGW) erstellen kann. Kann mir hier noch jemand Info geben?

Hi,

Andi_VB schrieb:

so wie manche leute es darstellen, muss VB.Net um Welten langsamer sein als VB6.

Das ist so lange korrekt, wie diese Leute in VB.NET noch die alten VB6-Funktionen benutzen, die immer noch im Framework enthalten sind. Da VB6 auf COM basiert, kommt in .NET noch das Marshalling von Parametern dazwischen, was in zu großem Umfang eine krasse Performancebremse sein kann. Daher gilt: Keine alten VB6-Funktionen verwenden, dann passt das.

Andi_VB schrieb:

dass es absolut egal ist, ob eine Anwendung in VB oder C# programmiert ist, da bei beiden am Schluss der gleiche CLI-Code rauskommt.

Das ist korrekt (bis auf gewisse Einzelheiten, um die sich Otto Normalverbraucher jedoch nicht zu kümmern braucht).

Andi_VB schrieb:

abgesehen von Syntaxähnlichkeiten soll C# eine absolut andere Sprache als C sein

Auch das ist korrekt - C wird in Maschinencode kompiliert und läuft als natives Programm. C# wird in CIL kompiliert und läuft in einer VM (wie Java). Daher kommt auch die Ähnlichkeit zwischen Java und C# (Glaubenskrieg hier: Wer hat die Syntax von wem abgeschrieben).

Andi_VB schrieb:

Also Performance ist mir nicht so wichtig

M.A.Jackson sagte 1975: 2 rules of optimization:
1. Don't do it
2. (for experts only): Don't do it yet.

Andi_VB schrieb:

ob man die DLL jetzt mit Visual Studio erstellen muss

Du erstellst alle Komponenten einer Anwendung mit Visual Studio. Am Anfang kannst du den Projekttyp wählen (Konsole, WinForms oder DLL). DLLs schreibst du genauso in VB.NET / C# und kannst sie als Verweis in verschiedenen anderen VB- oder C#-Projekten einbinden.

Und zu deiner Frage im Titel: Inline-Assembler schreibst du in einer C-DLL, die du dann aus .NET aufrufen kannst. Es fällt nur eine pauschale "Gebühr" für das Konvertieren von Parametern oder Rückgabewerten zwischen der verwalteten und unverwalteten Welt an.

Andi_VB schrieb:

und ob man die DLL jetzt mit Visual Studio erstellen muss oder auch mit dem GNU GCC (MinGW) erstellen kann.

Du kannst irgend eine DLL nehmen, wenn sie für das Betriebssystem kompiliert wurde. Der Compiler ist egal.
Und
1. Du musst die Deklaration kennen, um sie nach .NET zu übertragen.
2. Du musst wissen, ob die DLL für x86 oder für x64 kompiliert wurde, Dein Programm muss dann genau so kompiliert werden. AnyCPU funktioniert nicht, wenn Du von W32 nach W64 oder anders rum wechselst.