3. MFC -> tod

MFC -> tod

  • D

    Warum soll QT (womit ich in der obengenannten Auswahl am meisten zu tun hab) nur unwesentlich besser sein als die MFC?
    Ich finde die MFC um einiges umständlicher, und in QT kann ich einfach auch ohne Designer gute Oberflächen erstellen.

    0
  • K

    Selbes gillt imho auch für Gtkmm.
    Da brauche ich keinen Meta-Compiler und kann auch den
    Kompfort eines GUI-Designers genießen.

    0
  • E

    Ich denke, dass Marc++us absolut Recht hat. Möglichst wenig Aufwand in die GUI. Den geistigen Input in das Innenleben der Programme stecken. Beim Anwender spielt auch dort die Musik. Filme in Farbe sind oft schlechter als die alten Schwarzweiß-Schinken. Bei King Kong ist der erste Film immer noch der Beste.

    0
  • F

    Hallo!

    ( ➡ C# ist in meinen Augen auch nur eine Kreuzung aus Delphi und C++ nach MS Vorstellungen.)
    Das ist alles so ungewiss. Und deswegen habe ich jetzt auch angefangen WinAPI zu lernen. Da ist man unabhängig. Auch vom Compiler. Das ist in IMHO ein größes Problem der neuen "Sprachen". Delphi, C#, BASIC sind alle komerziell. C und C++ sind nicht aus kommerziellen Gründen entstanden. Das war eine ihrer Stärken.

    MFG, the flyingCoder.

    0
  • S

    flyingCoder schrieb:

    ( ➡ C# ist in meinen Augen auch nur eine Kreuzung aus Delphi und C++ nach MS Vorstellungen.)

    C# ist ein Java-Clone mit einer stark verbesserten VCL als GUI.

    Das ist alles so ungewiss.

    Nein, nicht alles.
    dotNET wird unter Windows der Standard fuer GUI Anwendungen werden, es sei denn Java liefert bis zum Longhorn-Release noch eine Sensation ab.

    Und deswegen habe ich jetzt auch angefangen WinAPI zu lernen.

    WinAPI wird aber sterben, das ist gewiss.

    Da ist man unabhängig.

    Nein, warum? Mit der WinAPI bist du zwar Sprachunabhaengig, aber dafuer stark Plattform abhaengig.

    0
  • F

    Warum wird die WinAPI sterben? Auf ihr baut doch alles auf!?
    Ich habe mir C# nicht tiefgehender angeguckt. Deswegen frage ich: Ist es nicht so, dass C# dem C Grundsatz, die Sprache möglichst klein zu halten, widerspricht?

    mfg ...

    0
  • M

    flyingCoder schrieb:

    Warum wird die WinAPI sterben? Auf ihr baut doch alles auf!?

    MS gibt in Win64 einfach die nativen WinAPI-Schnittstellen für die ganzen neuen Funktionen einfach nicht mehr bekannt. Dann kannst Du zwar noch Win32-Progs erstellen, aber nicht mehr die Features von Win64 nutzen. Und damit kannst Du keine aktuellen Programme erstellen => finish.

    flyingCoder schrieb:

    Ist es nicht so, dass C# dem C Grundsatz, die Sprache möglichst klein zu halten, widerspricht?

    Zwei Dinge:

    1. C-Grundsätze gelten nicht für C#, da dies eine andere Sprache ist.

    2. Die Sprache C# ist relativ knapp gehalten, besitzt halt viele OO-Features und Schlüsselwörter dafür, aber eigentlich nur das was man dafür braucht. So schlank wie C ist sie nicht, aber das geht ja auch gar nicht.

    0
  • N

    Kane schrieb:

    Selbes gillt imho auch für Gtkmm.
    Da brauche ich keinen Meta-Compiler und kann auch den
    Kompfort eines GUI-Designers genießen.

    Full Ack; Glade(mm)+GTK(mm) ist eine sehr elegante Möglichkeit auch komplexe GUIs zu erstellen.

    0
  • S

    Bis zum Longhorn release lohnt es sich auf alle Fälle noch die Winapi anzuschauen,
    da es bis dorthin noch ein Weilchen dauert und dann dauert es nochmal eine lange
    Zeit bis man wirklich auf NET2 umstellen kann ohne WinXp,Win2k,... auszusperren.
    Von daher mach ich mir da wenig Sorgen, bis in 3Jahren kann ich noch fleißig mit
    der Winapi arbeiten und dann schau ich mir vllt. mal NET2 an wenn ich auf
    Longhorn aufrüsten sollte, bis jetzt hört sich das ja noch gut an, wenn MS da
    nicht wieder Müll wie bei XP einbaut, nen OS das ohne Anfrage ins Inet geht und
    ne Firewall eingebaut hat, erweckt auf mich kein Vertrauen, ich will die gesamte
    Kontrolle über den Netzverkehr haben um mich sicher zu fühlen.

    0
  • ?

    "MS gibt in Win64 einfach die nativen WinAPI-Schnittstellen für die ganzen neuen Funktionen einfach nicht mehr bekannt."

    Das kommt alles irgendwie raus. Dann blüht Win64API richtig auf. 😉

    0
  • M

    ... lustig - wenn nur noch in C# oder VB.NET programmiert wird kann man ja den Quellcode dem Programmen gleich mit beilegen, naja wers mag 😃

    Alle kommerziellen Produkte werden auch weiterhin in C++ programmiert werden, oder glaubt Ihr wirklich die wollen sich so leicht in Ihren Code schaun lassen ?

    0
  • T

    maty schrieb:

    ... lustig - wenn nur noch in C# oder VB.NET programmiert wird kann man ja den Quellcode dem Programmen gleich mit beilegen, naja wers mag 😃

    Wie soll man von C# Programmen den Source anschauen können?

    0
  • M

    Weil man den MSIL disassemblieren kann, da der MSIL-Code eine 1:1 Übersetzung des Quellcodes ist, kann man damit den Sourcecode erhalten (allerdings ohne Kommentare und so Zeugs), fast im Original. Kein Vergleich zu C oder C++, wo dies nahezu unmöglich ist.

    Extrembeispiel: es gibt die Möglichkeit, ein mit VB.net nach MSIL übersetztes Programm revers nach C# zu übersetzen!

    Das Problem ist aber uralt, da Java seit Jahren damit kämpft - es gibt für Java sogenannte "Obfuscatoren", das sind Programme, die den VM-Code so verzwirbeln, daß man den logischen Ablauf nicht mehr so gut erkennen kann. Und demnach war die Lösung für C# einfach, es gibt auch schon Produkte dafür, z.B. den "Dotnetobfuscator".

    @maty: und da es seit Jahren kommerzielle Java-Programme auf dem Markt gibt, scheint dies ja kein wirkliches Hindernis zu sein, oder? Selbst SAP bringt Java-Programme raus... und die wollen sich wirklich nicht in den Quellcode schauen lassen. Dein Argument ist von geringer praktischer Relevanz.

    0
  • K

    Wie wärs wenn man das Problem in zwei Programme aufteilt?
    Ich hab mein GUI-Prog (vielleicht in einer extra GUI-Scriptsprache geschrieben)
    das über ein Interface (Pipes?) mit einem C++/C/Java/WasAuchImmer-Hintergrundprozess kommuniziert.
    Ichh kann dann auch einfach auf eine anderes GUI-Interface wechseln oder
    irgendwas zu recompilen.

    0
  • M

    Das klingt ziemlich clever. 👍

    0
  • Z

    Redest du von XAML?

    0
  • M

    ja Marc++us, mag ja sein aber es sind doch bestimmt mindestens 90 % der kommerziellen Anwendungen , wie Spiele, Betriebsysteme, Office-sachen , und alle andere PC Software in C++ geschrieben.
    Ich glaub also schon das mein Argument von praktischer Relevanz ist. C# ist ja schon mindestens ein Jahr, glaub ich auf dem Markt aber das neue MS Office z.b. ist immer noch in C++ geschrieben, ist das nicht seltsam 😕 ?

    0
  • M

    ...
    http://longhorn.msdn.microsoft.com/lhsdk/core/overviews/about xaml.aspx

    Das bringt's ?

    M.T.

    0
  • S

    maty schrieb:

    C# ist ja schon mindestens ein Jahr, glaub ich auf dem Markt aber das neue MS Office z.b. ist immer noch in C++ geschrieben, ist das nicht seltsam 😕 ?

    Natuerlich ist Office in C++ geschreiben. Denkst du die entwickeln jetzt einfach Office neu, nur weil es .NET gibt?

    Aber ich denke, dass das Office welches mit Longhorn released wird, sehrwohl eine .NET Anwendung ist. Vermutlich zwar managed C++ anstatt C# (denn C++ nach managed C++ ist angeblich recht leicht portierbar) - aber .NET bleibt .NET

    ABer vergiss bitte nicht, dass .NET erst mit Longhorn wirklich wichtig wird. Momentan ist es eine Art Testphase um die Leute an .NET zu gewoehnen.

    0
  • F

    Toll, heißt das jetzt, dass ich meinen teuer-ersparten Petzold gleich aus dem Fenster werfen darf?

    0
Anmelden zum Antworten