3. Visual Basic vs. C++

Visual Basic vs. C++

  • 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
  • G

    EDIT : Ich habe meinen Beitrag einfach mal zensiert, weil ich Blackbird nicht abschrecken möchte! 🙂

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

    0
  • V

    ich hab die liste bewußt mit nur 6 sprachen sehr kurz gehalten und auch noch zwei offensichtliche fälle eingebaut. macht mir das nicht kaputt mit lauter weiteren anfragen bevor Blackbird was für diese 6 gefunden hat (oder seine aussage zurücknimmt).

    0
  • R

    Original erstellt von 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.

    Hab ich das gesagt? Wo soll ich das den gesagt haben? Nirgends!

    Außerdem hat nicht jede Sprache eine Daseinsberechtigung!

    0
  • D

    Original erstellt von volkard:
    -cobol

    Erlernen der englischen Sprache.

    -brainfuck

    Der Name sagt: Geschlechtsverkehr für das Gehirn. Kann ja wohl nicht schaden. Oder?

    -java

    Hmm, keine Ahnung. Aber es muss gut sein. Microsoft hat es schließlich nachgemacht. Sonst hätten sie es gekauft :).

    -fortran

    Sinnvoll für traditionsbewusste Programmierer, die obskure Berechnungen schnell durchführen wollen.

    -forth

    Sinnvoll für traditionsbewusstere Programmierer, die immer mit dem speicherärmsten Gerät programmieren wollen und meistens etwas von Maschinenbefehlen verknüpfen und toll und so faseln.

    -lisp

    Nützlich zum Implementieren eines Lisp-Systems in Lisp.

    0
  • M

    Manche Sachen sind ohnehin schwer verständlich - mir ist Forth irgendwann in den frühen 80ern erstmalig über den Weg gelaufen, im Zusammenhang mit Maschinensteuerungen und Robotersteuerungen. Bißchen gespielt damit, war ganz lustig.

    Ich weiß nur nicht, warum ich damit heute ein OS programmieren können sollen muß????

    0
  • R

    @DanielE.

    😃 *ROFL*

    0
Anmelden zum Antworten