3. Visual Basic vs. C++

Visual Basic vs. C++

  • ?

    Ein solcher Vergleich ist auch nur schwer möglich (wie war das noch mit Äpfeln und Birnen?). Als VBler wirst du wohl schnell gefrustet sein (spreche da aus Erfahrung). Wenn du die Sprache lernen willst ist die nächste Zeit erstmal Essig mit 5-Minuten Klickibunti Sachen (dafür nutze ich VB noch manchmal), nacher wirst du aber froh um die Möglichkeiten sein, die sich dir bieten. Mit VB bist du irgendwann beschränkt in den Möglichkeiten.
    Aber eins lass dir gesagt sein, die Bequemlichkeiten die du dir mit Basic angewöhnst (Variablen nicht deklarieren und zuweisen, Groß/Kleinschreibung) musst du dir mit einiger Selbstdisziplin abgewöhnen.
    Wenn du es für den Spaß machst, dann eigne dir ruhig C++ an. Wenn du die Grundlagen verstanden hast, werden dir GUI Bibliotheken nicht mehr schwer fallen. Aber glaub nicht das es von heut auf morgen geht.

    0
  • G

    Original erstellt von nman:

    • ...ist extrem schnell
      [/list]

    BTW : Wo ist die Geschwindigkeit von VB im Vergleich zu anderen Sprachen wie C++, Java,... anzusiedeln?

    0
  • S

    Original erstellt von Gregor:
    BTW : Wo ist die Geschwindigkeit von VB im Vergleich zu anderen Sprachen wie C++, Java,... anzusiedeln?

    Also bis Version 4 war VB interpretiert - da war es extrem lahm!
    VB6 hat schon schoen was drauf, aber irgendwie unvergleichbar langsamer als C++ (also EXTREM lahm)

    Java wird schneller sein -> aber du kannst VB und Java nicht vergleichen. Eher Delphi und VB. Da duerfte aber Delphi etwas schneller sein...

    0
  • E

    Es lohnt sich auf jeden Fall, C++ zu lernen, da dies die grundlegende Syntax auch für Java und C# ist. Der Einstieg in die GUI-Programmierung ist deutlich schwieriger als bei VB. Das ist der große Nachteil.

    Ich würde auf jeden Fall zu Beginn auch WinAPI-Programmierung empfehlen, da man nur dort das Windows-Innenleben wirklich sieht und genau nachverfolgen kann.

    0
  • M

    Original erstellt von Shade Of Mine:
    VB6 hat schon schoen was drauf, aber irgendwie unvergleichbar langsamer als C++ (also EXTREM lahm)

    Das kann ich nicht unterschreiben.

    Vor allem Arithmetik ist in VB6 sehr langsam, gerade wenn es um Fließkommasachen geht.

    Aber typische Anwendungen von VB wie

    😉 Klickibunti-beladene Helpertools und Darstellungstools
    😉 Datenbankzugriffe und Masken für Datenbankdaten

    geben sich in der Geschwindigkeit nicht viel zu C++-Anwendungen. Kein Wunder, ist dort doch der Flaschenhals eher im Umkopieren von Bitmaps und in Datenbankzugriffen zu suchen.

    Ich habe schon große VB-Anwendungen für Prozeßvisualisierung gesehen, wo man an keinem Punkt des Programms (umfangreiche grafische Displays, ActiveX in VB, etc) gemerkt hat, daß dies ein "langsameres" VB-Programm war.

    Größter Vorteil von VB (DAFÜR IST ES AUCH GEDACHT) ist die Möglichkeit, Programme, die über COM oder ActiveX-Schnittstellen verfügen, miteinander zu verbinden. Mit keinem anderen Tool ist dabei eine solch kurze Entwicklungszeit möglich, selbst die Wrapper von ATL, Borland Builder oder Delphi verursachen mehr Aufwand.

    Schwerwiegender Nachteil von VB ist, daß es für Backend-Anwendungen (also überall da, wo man nicht ständig Dialoge anzeigt und auch mal was verarbeitet) keine guten Sprachmöglichkeiten hat. Die Strukturierungsmöglichkeiten für größere Programme (was man über Klassen, Polymorphie und Templates in OO-Sprachen bekommt) sind schlichtweg nicht vorhanden.

    Daher:
    Frontend in VB -> warum nicht (wenn es reine Windows-Anwendungen sind)
    Backend in VB -> Finger weg

    Ganz klassisch ist z.B. COM-DLL in C++, VB für die Dialoge. Aber da VB einen eingeschränkten Umfang der Sprache hat, lohnt es sich eben nicht wirklich damit Software zu entwickeln. Als Testumgebung und Visualisierungstool für Zwischendurch ja, aber dafür muß man VB nicht wirklich lernen.

    0
  • S

    Original erstellt von Marc++us:
    **Das kann ich nicht unterschreiben.
    **

    Wird schon stimmen was du sagst, aber ich habe trotzdem einen schlechten eindruck von der VB geschwindigkeit:

    ich habe als Ferialjob einmal den Inhalt des Lagers einer kleinen Firma bestimmen und speichern muessen -> dazu haben sie mir ein VB Programm gegeben... ich bin sicher, es hat sehr schnell in die Datenbank geschrieben, aber der arme 433Mhzer hat sich ganz schoen anstrengen muessen, wenn ich mit der GUI interagiert habe...

    naja, wahrscheinlich war die software einfach nur mies 🙂

    0
  • M

    Das ist nicht nett, was Du da dem armen kleinen VB vorwirfst...

    Stellt sich doch zunächst die Frage, welches Datenbankbackend verwendet wurde und mit welchem Provider die Daten geschaufelt wurden.

    Häufig verwenden die Leute MS-Access mit dem JET-OLEDB-Provider unter ADO - was wirklich lahm ist. Dann gibt's die ODBC-Provider, die eigentlich vom SQL-Server kommen. Oder die Datenbank wird nicht als Access angesprochen, sondern ist eine echte SQL-Server-Variante. Und dann kann man unter VB statt ADO auch noch DAO oder direkt ODBC verwenden.

    Jede Variante hat andere Geschwindigkeiten, wobei Access mit JET-OLEDB wohl die langsamste Variante ist, während bereits die Verwendung des MSSQL-Providers auf der gleichen Access-Datenbank einen Faktor 5 schneller ist.

    Die Performance hängt hier also ganz erheblich von den Treibern und der Lage der Datenbank ab (z.B. ist der Zugriff über auf Access über Netz lahm, weil alle Operationen lokal ausgeführt werden und riesige Datenmengen kopiert werden, im Gegensatz zu Netzzugriffen auf SQL-Server-Dateien). Usw.

    Ein C++-Programm wird hier bei gleichen Treibern keinen wesentlichen Geschwindigkeitsunterschied zeigen.

    0
  • P

    Hm, es wird immer so getan, als würde die Sprache die Geschwindigkeit erzeugen,
    das ist aber nicht so. Die Geschwindigkeit hängt in erster Linie vom System ab,
    und erst in zweiter Linie Bestimmt die Sprache in wie weit sie diesen Wert
    ausschöpfen tut.

    Devil

    0
  • P

    Original erstellt von Marc++us:
    **
    Häufig verwenden die Leute MS-Access mit dem JET-OLEDB-Provider unter ADO - was wirklich lahm ist. Dann gibt's die ODBC-Provider, die eigentlich vom SQL-Server kommen. Oder die Datenbank wird nicht als Access angesprochen, sondern ist eine echte SQL-Server-Variante. Und dann kann man unter VB statt ADO auch noch DAO oder direkt ODBC verwenden.

    Jede Variante hat andere Geschwindigkeiten, wobei Access mit JET-OLEDB wohl die langsamste Variante ist, während bereits die Verwendung des MSSQL-Providers auf der gleichen Access-Datenbank einen Faktor 5 schneller ist.

    Die Performance hängt hier also ganz erheblich von den Treibern und der Lage der Datenbank ab (z.B. ist der Zugriff über auf Access über Netz lahm, weil alle Operationen lokal ausgeführt werden und riesige Datenmengen kopiert werden, im Gegensatz zu Netzzugriffen auf SQL-Server-Dateien). Usw.

    Ein C++-Programm wird hier bei gleichen Treibern keinen wesentlichen Geschwindigkeitsunterschied zeigen.**

    Hi,

    über 70% aller Softwareunternehmen die ich kenne sind VB-Klopper. Die meisten sogar im Verwaltungsbereich. Einige mit simplen VBA und Access. Dort ist es den Leuten egal, ob sie auf ihren Datensatz 0,5 oder 2,5 sec warten müssen.

    0
  • D

    hi.
    vb läuft nur auf win.
    mit vb kannst du kein os machen.
    ABER vb ist einfach, schön, und für die meisten programme die sprache(word,win-exes).
    bye
    donay

    0
  • P

    Original erstellt von Marc++us:
    **
    Ich habe schon große VB-Anwendungen für Prozeßvisualisierung gesehen, wo man an keinem Punkt des Programms (umfangreiche grafische Displays, ActiveX in VB, etc) gemerkt hat, daß dies ein "langsameres" VB-Programm war.

    Größter Vorteil von VB (DAFÜR IST ES AUCH GEDACHT) ist die Möglichkeit, Programme, die über COM oder ActiveX-Schnittstellen verfügen, miteinander zu verbinden. Mit keinem anderen Tool ist dabei eine solch kurze Entwicklungszeit möglich, selbst die Wrapper von ATL, Borland Builder oder Delphi verursachen mehr Aufwand.

    Schwerwiegender Nachteil von VB ist, daß es für Backend-Anwendungen (also überall da, wo man nicht ständig Dialoge anzeigt und auch mal was verarbeitet) keine guten Sprachmöglichkeiten hat. Die Strukturierungsmöglichkeiten für größere Programme (was man über Klassen, Polymorphie und Templates in OO-Sprachen bekommt) sind schlichtweg nicht vorhanden.

    Daher:
    Frontend in VB -> warum nicht (wenn es reine Windows-Anwendungen sind)
    Backend in VB -> Finger weg

    Ganz klassisch ist z.B. COM-DLL in C++, VB für die Dialoge. Aber da VB einen eingeschränkten Umfang der Sprache hat, lohnt es sich eben nicht wirklich damit Software zu entwickeln. Als Testumgebung und Visualisierungstool für Zwischendurch ja, aber dafür muß man VB nicht wirklich lernen.**

    Dito!

    Das Problem ist, dass der Standard-VB-Klopper:

    1. 'Fire and forget' programmiert, d.h. gar nicht gezwungen ist, sauber structuriert OOP zu programmieren.
    2. Begrenzte Möglichkeiten mit der win32-API hat und dann bei bestimmten Ansprüchen nur noch Pfuschen und Tricksen kann, zur Lasten der Laufzeitbetrachtung.
    3. Keine saubere Fronend/Backend-Aufteilung hinbekommt. ("3-Schichten-Architektur?! Was ist denn das?!😕")
    4. Komponententechnologie eigentlich nicht wirklich versteht. ("Das machen wir doch eigentlich über Eigenschaftsfenster und Wizard. Ach - wir speichern einfach über Metadaten in der DB zwischen.")
    5. Keine Geduld hat sich den Kramm anzukucken.('Fire and forget')
    6. Auch andere Dinge nicht überblickt, weil er nie richtig programmieren musste.
      Fazit: VB hat nichts mit Programmieren zu tun! 😃

    "Ich nehme eine Tüte Kiesel, den Flachen hier und den Granitblock!"
    Steinigungscene aus "Leben des Brain" 🙂

    cu

    P84

    [ Dieser Beitrag wurde am 23.11.2002 um 15:43 Uhr von Prof84 editiert. ]

    0
  • S

    Original erstellt von donay:
    mit vb kannst du kein os machen.
    ABER vb ist einfach, schön, und für die meisten programme die sprache(word,win-exes).

    hae?
    was willst du uns damit sagen?

    Ein OS will ich sowieso nie schreiben und quasi alle anderen auch nicht. ist also etwas bloedes argument.

    wobei ich denke, dass man durchaus auch einen VB Compiler schreiben koennte und in VB den Kernel implementieren!

    word? was hat word mit VB zu tun?

    0
  • R

    Wenn VB mittlerweile wirklich kompiliert wird und nicht mehr diese zig tausend DLLs braucht (die MS netter Weise auch nicht direkt mit Windos ausliefert ;)), dann könnte man theoretisch auch ein OS damit schreiben.

    Wenn man gedenkt VB Programme nach Unix zu portieren sollte man sich mal folgendes angucken http://www.kbasic.org/1/home.php3

    Ich würde aber niemanden Empfehlen VB zu lernen!

    0
  • M

    Yep, anwenden ist ok für bestimmte Sachen, aber lernen ist nicht wirklich notwendig.

    Aber um das noch mal zu sagen: VB AB VERSION 5 WIRD COMPILIERT!!!!!!!!!!!!!!! Ende der Diskussion. Es ist so.

    Ob dafür DLLs (vbrun.dll) benötigt werden hat überhaupt nichts damit zu tun, ob compiliert oder nicht - die stecken halt die Runtime in eine DLL statt sie in die Exe zu binden. Und Runtimes gibt's nun mal auch bei compilierten Exes. Die Verwendung einer Runtime macht doch keinen Interpreter...

    0
  • R

    Ich meinte ja nicht, dass kompilieren bedeutet, dass man keine DLLs mehr nimmt, das brauch man bei C(++) ja auch, wenn man die std. Library nicht statisch linked. Es ging mir darum, dass man damit kein OS entwickeln kann, wenn man die grundsätzlich zum ausführen braucht (also auch wenn man keine library Funktionen benötigt), weil man dann natürlich kein OS damit entwickeln kann, ausser man schreibt einen Bootloader mit Assembler, der die DLLs und den Kernel lädt. Das wirkliche OS Entwicklung mit Visual Basic natürlich im Endeffekt Blödsinn ist, sollte aber allen klar sein 😉

    0
  • B

    Es gibt kein "VB vs. C++"!
    Jede "Sprache" hat ihre Daseinsberechtigung und ihre Vorteile. Wobei die Vorteile und Nachteile abhängig von der Aufgabenstellung (des jeweiligen Softwareprojektes) sind.
    Und "KlickiBunti" ist VB auch nicht. Für die Oberflächengestaltung trägt allein der Programmier der Software die Verantwortung, nicht die Sprache in der er sie erstellt. Es ist nur ein Frage der Faulheit des Programmierers, wie er mit den Werkzeugen der jeweiligen Sprache umgehen kann (und wie spartanisch dann sein GUI unter C/C++ ausfällt).

    Auch wenn wir hier in einem C/C++ -Forum sind: Es gibt keinen Grund, andere Hochsprachen nicht zu verwenden. Jede für ihren Zweck.

    Meine Empfehlung: @coolrunner: Wenn Du schon VB kannst, ist C++ (oder auch C zunächst) als nächster Schritt ganz gut. Dauert aber etwas mit dem Lernen, denn hinter jeder "Sprache" steckt eine andere Entwicklungs-Philosophie (oder Filosofie? - Ich begreif's einfach nicht).

    Blackbird
    PS: @Kingruedi: Wieso kann man nur in C++ ein OS erstellen? Assembler und Forth sind doch genauso gut. Dass C (und C++) am häufigsten verwendet werden, liegt einfach an der Verbreitung von C.

    0
  • ?

    Deine Antwort ist sehr schön. Woher kennst du dich damit so gut aus? 😕 🙂

    0
  • V

    Original erstellt von Blackbird:
    Es gibt kein "VB vs. C++"!
    Jede "Sprache" hat ihre Daseinsberechtigung und ihre Vorteile. Wobei die Vorteile und Nachteile abhängig von der Aufgabenstellung (des jeweiligen Softwareprojektes) sind.

    Ob man das wirklich so stehen lassen kann?
    Erläutere doch man kurz einen ernsthaften Grund für die jeweilige Sprache (und nicht bloß "hatte nur libs oder nur compiler für bla").
    -cobol
    -brainfuck
    -java
    -fortran
    -forth
    -lisp

    0
  • G

    Original erstellt von volkard:
    **
    Erläutere doch man kurz einen ernsthaften Grund für die jeweilige Sprache (und nicht bloß "hatte nur libs oder nur compiler für bla").
    -cobol
    -brainfuck
    -java
    -fortran
    -forth
    -lisp**

    ...und bitte auch für
    -C
    -C++
    -D 🙂

    [ Dieser Beitrag wurde am 25.11.2002 um 14:21 Uhr von Gregor editiert. ]

    0
  • C

    Nicht zu vergessen:

    - C#
    - Algol
    - Basic
    - Pascal

    0
Anmelden zum Antworten