Überblick - C++ / C# / VB.NET

  • VB.NET

Es gibt 15 Antworten in diesem Thema. Der letzte Beitrag () ist von Mad Andy.

    Überblick - C++ / C# / VB.NET

    Hallo,

    ich würde mal einen bzw mehrere darum bitten, mir
    bzw der Comminuty eine Übersicht über die Unterschiede
    und Vor- bzw Nachteile der ganzen Varianten zu liefern.

    Worin besteht der Unterschied zwischen C++ und C# ?
    Was ist "besser", VB.NET oder lieber C++ / C#
    Womit ist "mehr" möglich ?
    Was von denen ist anspruchsvoller ?

    Hatte mir mal C++ und C# angeschaut, also da
    nützen meine "Vorkenntnisse" reichlich wenig.
    Damit komme ich sogut wie gar nicht klar.

    Mit freundlichen Grüßen
    Lexeaus
    *Verschoben* Handelt sich um eine allg. Programmierfrage

    Hi!

    Also vb.net und C# sind bis auf ein paar Kleinigkeiten von den Möglichkeiten her gleichzusetzen. Verwenden beide das jeweilig eingestellte .net Framework.

    C++ hingegen verwendet das jeweilige Betriebssystem API (unter Windows das WindowsAPI ;)) und Libs, die man dazu Linkt (z.B. XML Parser). Von sich aus unterstützt C++ die Variablentypen, die die CPU kann, also nur Zahlen, und dazu kommen 2 Varianten von Strings (CStrings = Byte-/Zeichen-Arrays und Std::String, ähnlicher dem VB-String). Ein großer, jedoch verwirrender Vorteil von C++ sind Zeiger. Das kannst du dir etwa so vorstellen, dass du keine Variablen übergibst, sondern Speicheradressen (Zahlen), die auf die Variable verweisen. Der Vorteil davon ist, dass man recht schnell arbeiten kann -> Geschwindigkeitsoptimierungen.
    Ein Manko (was aber gezielte Optimierungen ermöglicht) ist, dass normale Variablen von C++ beim Verlassen des jeweiligen Gültigkeitsbereiches (z.B. ende einer Funktion) vernichtet werden und Variablen, die mittels New auf den sog. Heap gespeichert werden nie automatisch gekillt werden. New gibt einen Pointer zurück, mit dem man selbst ungenutzte Variablen freigeben muss -> Mögliche Speicherleaks. Die Optimierungen gegenüber .net bestehen darin, dass bei .net ein Programm mitläuft, dass immer schaut, welche Variablen denn bereits ungenutzt sind (keine Referenz mehr haben) -> frisst Leistung.

    Joa, dazu kommt noch, dass bei C++ eigentlich alles Maschinenbefehle sind, bei .net handelt es sich um eine Sprache, die erst zur Laufzeit in Prozessorbefehle umgewandelt werden -> frisst wieder Leistung / Zeit.

    Der irrsinnige Vorteil von .net ist eben das fette Framework, das man bei C++ teils durch API-Funktionen und teils durch kostenlose Libs ersetzen kann. Die C# Syntax ist laut Microsoft eine Mischung aus C++ und Java. Die Aufrufe von C# sind die gleichen wie die von vb.net (eben das Framework), lediglich die Syntax unterscheidet sich. Wenn du dich mit den geschweiften Klammern von C++ und C# wirklich nicht anfreunden kannst, ist wohl VB eher was für dich ^^
    Danke für den guten Beitrag,
    ja du hast recht, diese Klammern verwirren mich =P
    Aber für die .net Programme werden ja, irgentwie auch logisch,
    das Netframework benötigt, also bei C++ wirds nichts zusätzlich benötigt ?
    Weil manche Rechner kein aktuelles Framework haben, wäre es
    natührlich besser , man programmiere in C++.

    Zum Thema der Leistung.
    Ich meine heutzutage sollte es keine Probleme mehr diesbezüglich
    geben, oder sehe ich das falsch ?
    Bei, nur um mal ein Beispiel zu nennen, 8 GB Ram ( wer wohl :P ? :rolleyes: )

    Wie gesagt, wenn ich irgentwann mal doch interesse darin finde,
    werde ich mir das mal ganz in Ruhe anschauen, habe mir ja immerhin
    bis jetzt im großen und ganzen alles selber beigebracht
    -> Stundenlanges Tutorial lesen, googlen und Foren durchstöbern.

    mfg
    Lexeaus

    PS.: ich habs wohl letzter zeit mit den falschen foren :P , entschuldige

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „lexeaus“ ()

    Hi!

    Erm.. joa, also unter Windows ist es üblich das meiste statisch zu Linken (alles direkt in die Exe rein), was nicht wirklich "ökonomisch" ist, aber es erlaubt das Programm auf jedem Windows auszuführen, solange die Libs nicht auf spezielle Windows-API-Funktionen zurückgreifen. Andernfalls gibts die DLLs, die den Vorteil haben, dass man sie getrennt updaten kann.
    Man kann DLLs aber auch zusammen mit der .exe ausliefern -> kein langwirriges Setup im Gegensatz zu .net.
    DLLs, dies hald immer gibt sind die vom Betriebssystem.

    Die 8GB sind nie vollständig ausgelastet und beinhalten auch mehr als nur laufende Programme ;)
    Ich meinte eigentlich auch (eher) die CPU-Leistung. Bei einigen Anwendungen kommt man um C++ nicht herum, weils einfach zu lang dauern würde. Sony Vegas (Video Schnitt) verwendet für das Programm selbst .net 3.0, die rechenintensiven DLLs im Hintergrund sind aber teils in C++ geschrieben, das ist also auch möglich. Eine andere typische Anwendung sind "Highend" Games, bei denen man wirklich alles ausm Rechner rausholen will oder minimale Anforderungen bei niedrigen Einstellungen haben will. HDR-Berechnung frisst beispielsweise enorm viel CPU-Leistung.
    Ich weiss nicht ob es jetzt angebracht ist
    hier das im Thread anzuhängen, aber
    passt ja irgentwie schon ins Thema, ansonsten
    mach ich einen neuen Thread, aber ich hab ja
    schon mehr als genug hier =P
    Ich habe mir schon mehrere Sachen über die
    dll Sachen bei vb.net durchgelesen, blicke da
    aber noch nicht so ganz wirklich durch.
    Wofür sind die dlls ( ich hab in erfahrung gebracht,
    das dort functionen enthalten sind ) diese kann man
    doch aber auch direkt in das eigentlich programm
    unterbringen oder sehe ich das falsch ?
    Wofür dann dlls ?
    Klassen spielen bei .Net eine große Rolle (Objektorientierte Programmierung).

    Die ActiveX dll's von VB sind nicht das gleiche wie C++ oder Delphi dll's. Bei VB sind es ausgelagerte Klassen.

    Als Beispiel erstellen wir uns eine Additionsklasse:

    VB.NET-Quellcode

    1. Public Class Addition
    2. Public Function Addieren(Byval zahl1 As Integer, Byval zahl2 As Integer) As Integer
    3. Return zahl1 + zahl2
    4. End Function
    5. End Class


    Wenn wir diese Klasse als dll exportieren können wir so auf sie zugreifen:

    Erst Verweis setzten, danach Aufrufen:

    VB.NET-Quellcode

    1. Class Form1
    2. Sub testen()
    3. Dim addierer As New unserdllname.Addition
    4. Msgbox(addierer.addieren(1,2))
    5. End Sub
    6. End Class
    Hi!

    Beim Betriebssystem gibts DLLs, die du aufrufst, bzw. bei .net das Framework aufruft. Das wär Speichermäßig ein absoluter Overkill in jedem Programm das ganze OS mitzuliefern. Abgesehen davon gäbe es dann keine Updates und die Betriebssystemversion wäre auch egal.

    Im OpenSource-Bereich haben sich die DLLs durchgesetzt, damit mehrere Projekte unabhängig voneinander laufen können und alles am neuesten Stand sein kann.
    Bei ClosedSource-Programmen ist es oft so, dass es DLLs nur gibt um diese extern/getrennt Patch (updaten) zu können oder weil ein und die selben Funktionen mehrfach verwendet werden. Plugin-Systeme beruhen auch meistens auf DLLs mit vorgegebenen Funktionene bzw. Schnittstellen.

    Wenn du dir einige OpenSource-Lizenzen durchliest, siehst du auch, dass du oft bei DLLs nicht dazu verpflichtet bist dein Programm auch OpenSource zu machen, jedoch schon, wenn du den Quelltext oder das Programm in dein Programm einbettest (statisches Linken ist nichts anderes).

    Das gleiche gilt eigentlich bei jeder Programmiersprache: Unabhängige Entwicklung, mehrfachverwendung, Updates, Pluginsystem.


    Edit:
    noname: Die Frage war nicht, wie das aussehen könnte, sondern der Zweck von DLLs...
    Hehe, der Wille zählt,
    okey soweit verstanden,
    also ist es für normal nutzer nicht umbedingt
    notwendig, dlls zu verwenden ? solange
    man keine updatefunktion benutzt ...

    edit :

    wobei der punkt mit der mehrfachanwendung /update und plugin
    eigentlich sehr gut ist, nur wie gesagt, bei kleineren projekt
    jedoch ohne bedeutung, wie ich finde
    Hi!

    Bei ner Updatefunktion musst du auch nicht unbedingt auf DLLs zurückgreifen, die .exe musst du sowieso beenden, damit du sie überschreiben kannst. Es geht dabei eher darum (bei größeren Projekten) DLLs getrennt aktualisieren zu können. Bei kleinen Anwendungen ist das auch bei Updates sinnlos.
    Man kann mit C++ gegen das Framework linken und die Framework funktionen mit dem schnellen C++ mischen. Durch das umständliche herumcasten und ist das aber mehr Aufwand als Vorteil :(
    Abgesehen verleitet es einen dazu das WinAP oder andere unmanaged Sachen, die nicht nötig sind, mit dem Framework zu mischen, was unsauber ist.
    Ich persönlich muss sagen, dass ich inzwischen lieber C# programmieren würde statt vb.net.
    Warum ?

    Die Syntax ähnelt einfach mehr den der anderen Programmiersprachen und ich finde den Umstieg zwischen vb.net und anderen Sprachen nicht immer sehr angenehm. Da ich auch C++ programmieren muss, fällt mir das besonders schwer.

    Sicherlich ist vb.net übersichtlicher als andere Sprachen und hat auch andere Vorteile.
    Aber wie gesagt der Umstieg... ;)
    Hi, ja. Ich hab auch mit VB angefangen, weils wohl am einfachsten zu lernen ist. Iwas-End ergibt anfangs mehr Sinn als {}.

    Hab noch vergessen dazu zu sagen, dass bei der Mischung von Managed und Unmanaged Code auch Probleme mit der Speicherfreigabe entstehen. Der Garbage Collector kümmert sich logischerweise nicht um unmanaged Sachen -> kann zu Mem Leaks kommen. Und wenn man vergisst dem GC zu sagen, dass man auf ne Managed Variable eine Unmanaged Referenz hat, löscht der einem die Variable vor der Nase weg :(
    Die Frage ansich ist aber natürlich auch, ob es noch Sinn man resourcen in C++ zu stecken, da ebend vb.net und C# die Sprachen der Zukunft sind (meine Meinung).
    Microsoft macht außerdem immer mehr Druck..
    Da werden die Prozessorhersteller früher oder später gezwungen sein mitzuziehen.

    Und wenn ich jetzt schon Zeiger und vom Garbage Collector höre, wird mir ganz anders :cursing:
    Hi!

    Das Problem von .net ist, dass es nicht Plattformübergreifend entwickelt wird ("Microsoft-Monopol") und somit wirds immer was anderes geben (z.B. Java). Für Berechnungen (Spiele, Animation, Videoschnitt), die die Hardware richtig fordern, wird (vorerst) C++ dableiben, für Anwendungssoftware hat .net sicher seinen Anreiz - glücklichweise funktioniert ja doch einiges mit Mono, wodurch auch in der Nicht-Windows-Welt .net nicht soo verhasst ist.

    So wie du jetzt von .net "schwärmst" haben andere früher von Delphi gedacht (gutes, einfaches, großes Framework dahinter + Unix-/Linux-Klon) und mittlerweile ist der Marktanteil trotzdem recht gering geworden. Ich vermute fast, dass sich in Zukunft (für kostenlose Programme) auch Scripting durchsetzen könnte (siehe z.B. Python + GTK, unter Linux schon länger beliebt).