C# ist der Hammer



  • Mastah,
    ich muss dir widersprechen: von der Bequemlichkeit her kannst du nicht alle Ernstes VCL und MFC vergleichen.
    Zwei Welten, die VCL ist imho "wesentlich!" entwicklungsfreundlicher.
    Gruß
    Carsten



  • Original erstellt von <Heinrich>:
    Kann ich dir nur zustimmen. Vor allen Dingen in Sachen GUI.

    ...und nicht nur da! Hast du dir mal folgenden Benchmark angeguckt:
    http://www.middleware-company.com/j2eedotnetbench/

    Der .NET Petstore hat etwa einen 18-fachen "Peak Throughput" gegenüber dem Sun-J2EE-Petstore. 😮 ...außerdem ist man mit C# auch viel produktiver. Der J2EE-Petstore brauchte zum Beispiel 7 mal soviele Codezeilen, wie der .NET-Petstore.

    Ganz klar: C# und .NET gehört die Zukunft. Ist fast 20 mal schneller wie Java und fast 10 mal produktiver. Da kann auch keine andere Sprache, wie z.B. C++ mehr mithalten. Denn wenn man sich die Benchmarks zwischen C++ und Java mal anschaut, dann ist da C++ 2-4 mal schneller, das heißt, dass C# etwa 5-10 mal schneller als C++ ist! 🙂 😃



  • Gregor schreib mal vernünftig deine Meinung und nicht nur immer so eine scheiss Ironie. Man kann da garnicht mehr Unterscheiden was du ernst meinst und was nicht.



  • Im Ernst - Gregor - das glaubst du doch nicht wirklich oder?
    Wenn ich ein minimal Terminal Programm zum testen schreiben mit Zeitmessung sehe ich schon noch einiges an Unterschied von C# zu C++

    Ein Runtime Compiler kann normal nie so schnell werden, wie Optimiertes C++. Außer du Compilierst C++ im Debug Mode ohne alle Optimierungen - oder nur für 16 Bit



  • man SnorreDev das war doch eindeutig ein "scherz" von ihm. da brauchst doch nicht so ernsthaft drauf antworten 🙄



  • Nein, ich glaube das nicht wirklich. 🙂 Ich dachte, das wäre offensichtlich gewesen. Allerdings meint die Firma, die den Benchmark gemacht hat, diesen offensichtlich ernst. ...und ich habe auch in den C#- und .NET-Foren, in die ich manchmal gucke, noch keinen kritischen Kommentar zu diesem Benchmark gesehen. Stattdessen sieht man da die Zustimmung pur.

    Ich schließe mich da eher mal dem Text unter folgendem Link an:
    http://dreambean.com/petstore.html



  • @ich: nein - ein man zu Snorredev gibts noch nicht
    Hab in der Linux Konsole noch keinen Erfolg gehabt mit
    # man SnorreDev

    😃

    Ok - gut - ich habs nicht wirklich erkannt - muß gerade für meinen Abschluß 30 Seiten Docu schreiben und bin etwas angekratzt - sorry



  • mehr und mehr wird Linux verkauft! schon mal daran gedacht, dass C# nicht mit Linux arbeitet? Ich denke nicht dass es sich durchsetzen wird (es gibt noch mehr gründe..)



  • @att309
    Ich nutze auch Linux, aber nach den bisherigen Meldungen der Jahre war nach einem kleinen Boom die Linux Gemeinde wieder rückgängig, außer am Server Markt. Daran sind die User Schuld, die keine Lust haben sich mit dem System auseinander zu setzen, aber who cares.
    Hast du eine Quelle dafür, daß Linux wieder mehr verkauft wird?
    Währe dankbar für nen Link oder ähnliches.



  • Original erstellt von MaSTaH:
    Und zum Thema "UI-Gestaltung genau so einfach wie in Delphi, kein Scheiß WinAPI mehr" (frei zitiert): Hast du schonmal im Visual-Studio die MFC-Wizards und den Resource-Editor entdeckt??? Ist auf jeden Fall auch so einfach wie in Delphi (Delphi sux 😡 )...

    Ähm... ich denke mal das verdient nur ein eindeutiges *lol*.

    Ich will gar nicht von einem Dialog anfangen, der Buttons mit Text und Bild hat (mach mal mit MFC und RC-Edit). Mach doch mal mit MFC und dem RC-Edit einen Dialog, wo das Editfeld am rechten zoombaren Fensterrand hängt und die Buttons für OK und Cancel sich beim zoom mitbewegen. Bereits so eine triviale Aufgabe wird bei MFC aufwendig. Und dann z.B. farbliche Hintergründe für Editfelder, etc. Da rutscht man sofort wieder in WinAPI ab.

    Die VCL (egal ob bei Delphi oder beim C++ Builder) mit der MFC zu vergleichen ist ein schlechter Witz. Und der Hammer ist schon, daß die .NET-GUI-Sachen noch mal eines drauflegen im Vergleich zur VCL.



  • also alles in Richtung VB?



  • @fish
    Wieso alles Richtung VB?
    VCL ist eine recht gute und übersichtliche Klassensammlung, die die WinAPI Wrappt. Finde dagegen ist nichts einzuwenden.

    Und .net ist auch kein VB, eher eine vereinfachte überarbeitete und erweiterte WinAPI oder so ähnlich. ? wenn man das so sagen kann 😉 ?
    Nur das mit dem Runtime Compiling find ich echt müllig. Hardcompiled ist immer noch am besten.



  • Das ist wohl der Punkt. Hätte MS die .NET-Lib als Ersatz für die MFC angeboten auf einem VC++7, der ISO-kompatibel ist, dann wüßte wohl jeder wie die Zukunft aussieht.

    Aber das mit der VM schreckt schon ab...



  • Original erstellt von Marc++us:
    Aber das mit der VM schreckt schon ab...

    Da muss ich dir recht geben. Hab gestern mal in der Firma etwas mit unserer C# Lizenz gespielt und mir mal es einfaches zusammengeschustert. Ich muss sagen,ich mag das Framework (kein Wunder hat ja auch der VCL-Chefentwickler mitgewirkt und Einfluss genommen (-; ) und ich mag auch die IDE... (ähnelt sehr dem Konezpt von Borland mit Objektinspektor und so). Die Sprache selbst wage ich noch nicht zu beurteilen, sieht aber auch ganz nett aus. Egal ob da nun Elemente und Ideen von Java oder sonst was eingewebt sind.

    Was mich allerdings grässlichst stört ist eben die VM. Bei uns fällt die Sprache vorläufig unten raus, denn die Applikationen die wir entwickeln müssen auch noch einem Windows 95 und NT4 gerecht werden und da kommt das .Net Framework leider nicht mehr hin. Auchdie Tatsache, dass ich rund 40MB .Net Framework mit der Applikation vertreiben müsste ist nicht grad das Gelbe vom Ei.

    Übrigens, Marc++us: Wenn ich so - nach einem kurzen überblick - das Framework so anschaue, so steht ihm die VCL 6.0 in nichts nach. Auch die unterstützt Anker (was andere Frameworks wie Ilog schon lange unterstützen).

    -junix



  • Gegen eine VM ist nichts einzuwenden
    wenn es mir Vorteile bringt, wie eben
    Plattformunabhängigkeit.

    Ansonsten ist die VM unnötig wie ein Kropf.



  • So ist es - und die M$ Runtime ist eben nicht Crossplattform.
    Außerdem ist ein Runtime Compiler für echt Performance Kritische Sachen echt in die Tonne zu hauen.

    Wenn ich eine garantierte Reaktionszeit von sagen wir 5 MSek oder noch besser in uSek brauche brauche, ist eine VM noch nicht tragbar. Das wird sich zwar mit den nächsten Rechnergenerationen wieder verbessern, aber dafür baut M$ noch viel mehr Overhead ein, und die Kiste verliehrt mit den ganzen Services, und sonstigem Krempel wieder etwas.



  • Wenn ich eine garantierte Reaktionszeit von sagen wir 5 MSek oder noch besser in uSek brauche brauche

    Wenn man sowas wirklich brauchen sollte, dann macht man das sowieso nicht unter Windows oder Linux.



  • Naja, bei Kommunikation ist eine tiefe Reaktionszeit shcon wichtig. grad wenn man ein protokoll fährt, das mit Timeouts arbeitet...

    -junix



  • Naja - du hast nur bedingt recht. Gut wenn ich z.B. eine Sensorik Steuerung im nano Sekunden Bereich brauche, dann muß ein Realtime OS her - siehe QNX oder ähnliches.

    Wenn man aber Games entwickelt, dann kommt es auch sehr auf die Performance an. Da ist ein Runtime Compiler nicht so toll. Es kommt ja auf jeden Frame an. Und die Zeit, die man dann mehr braucht, um die Daten zu rendern, fehlt einem dann z.B. bei der KI, Physik usw.



  • Jede Sprache hat ihre eigenen Anwendungsgebiete. Und C# ist sicherlich nicht für Games geeignet.


Anmelden zum Antworten