3. C++ oder C#

C++ oder C#

  • F

    es kommt auch drauf an was man machen will.

    ICh kenne mich nun mit C# nicht wirklich so aus. Sollte wohl doch mal wieder mein Visual Studio installieren.

    C# ist plattformunabhängig zumindest laut aussage des herstellers. Also ein auf Windows hergestelles C# programm sollte??? auch auf Linux laufen. So ähnlich wie Java.

    Bei C++ ist das nicht so. Dort muss zumindest das Programm auch auf der anderen Platform compiliert werden.

    Ansonsten sind sich die sprachen im grundlegenden recht ähnlich was wirklich grundelemente angeht.

    Was gibts sonst noch zu sagen. Ich weiss das C++ richtigen Maschinencode erzeugt wie C# das macht weiss ich nicht und wie daher die performance ist.

    0
  • C

    Fedaykin schrieb:

    C# ist plattformunabhängig zumindest laut aussage des herstellers. Also ein auf Windows hergestelles C# programm sollte??? auch auf Linux laufen. So ähnlich wie Java.

    Ich glaub das bedeutet soviel das ein C# Programm mit allen Windowsbetriebssystemen läuft, auf denen das .net Framework installiert ist. Die Linuxplattformunabhängigkeit funktioniert nicht von Haus aus, sondern nur mit Mono.

    0
  • Z

    Mein Tipp

    Wenn dir C++ als erste Programmiersprache nicht zu schwer ist, dann lern das, sonst kannst du erst über C# programmieren lernen.

    Microsoft interpretation von plattformunabhängig ist, dass es auf allen Plattfromen mit ein Microsoft Betriebssystem läuft. Mono ist die CLI implementierung für Linux, aber sie ist nicht 100% kompatible.

    0
  • M

    @Fedaykin
    Ich glaub da würfelst du ein paar Sachen durcheinander. Eine Programmiersprache ist nicht von einer Platform abhängig, sondern höchstens das was die Compiler ausspucken.
    (Es wäre durchaus möglich, dass jemand einen C#-Compiler entwickelt, der ebenfalls Maschinencode erzeugt.)

    Praktisch gesehen hast du natürlich recht. C# wurde dafür entwickelt um den Quellcode in eine Zwischensprache übersetzen zu können, der wiederum für unterschiedliche Betriebssysteme übersetzt werden kann.
    Wobei Microsoft für das Ganze nur die Umgebung für Windows bereitstellt, wodurch die Platformunabhängigkeit sich momentan auf Windows 2000/XP/Vista beschränkt.
    (Bei Java ist das ein kleines bißchen anders, da wird die Laufzeitumgebung für einige Betriebssysteme von SUN direkt bereitgestellt.)

    0
  • F

    naja direkt durcheinaner gewürfelt hab ich da nichts, war nur zu Faul um es genau zu erklären.

    Das Problem mit der Platform Unabhängigkeit gabs ja bei Java auch. Anfangs gabs bei Linux auch nur eine Fremd entwickelte JVM von Blackdown weil die von SUN nicht so toll war ( Oder gab es gar keine ? ) Also würde ich da mal nicht so sehr mit den Schimpfefinger auf MS zeigen.

    Java funktioniert ja über bytecode. Also ein Programm wird in eine art "Pseudo Maschinencode" umgewandelt was eine auf dieser Platform geschriebener Virtueller Prozessor dann in maschinenbefehle umsetzt.

    Wie das nun aber C# macht weiss ich nicht. AFAIK benutzt es eben keinen Bytecode. Ich könnte mir denken es sind eine art von Dynamischen Bibliotheksaufrufen.

    0
  • A

    Naja, schimpft mal nicht so auf MS. Immerhin haben die einiges an die ECMA und ISO übergeben. Hier schreiben einige, das Mono nicht 100% zu .NET kompatibel ist. Richtig. Aber .NET ist ein Produkt und keine Spezifikation. MS muß kein Produkt für Linux entwickeln, warum auch? MS hat mit anderen Firmen (Intel, HP u.a.) eine CLI-Spezifikation ausgearbeitet, die Platformneutral ist. Und darauf beruhen sich erstmal .NET und MONO. Die CLI ist sowohl ECMA- und ISO-Normiert, es wird keiner daran gehindert, eine CLI-Implementierung zu erarbeiten (weshalb MONO ebend nicht von MS bekämpft wird). Auch C# ist ECMA- und ISO-Normiert, und jeder darf einen C#-Compiler implementieren.

    .NET ist ein Produkt, das mind. die CLI und CLR implementiert und weitere Dienste anbietet. Und dieses "weitere Dienste" gehört nunmal MS.

    Übrigens, MS bietet sehr wohl eine Nicht-Windows-Implementierung an! Und zwar mit ROTOR gibt es für FreeBSD eine Referenz-Implementierung der CLI!!! Diese darf aber nur für akademische Zwecke verwendet werden. Aber es zeigt sehr schön, das MS damit selbst beweist, das CLI platformunabhängig über Windows-Grenzen hinweg möglich ist.

    So, kommen wir zu C# vs. C++. C++ hat ein paar Eigenheiten, die man in C# nicht findet. Man kann davon ausgehen, das ein C++-Programmierer es einfacher hat, nach C# zu wechseln, als umgekehrt. Das ist meine pers. Meinung. Weiterhin kann ich C++ unter jeder möglichen und unmöglichen Plattform nutzen. Ich habe ein kleines Spiel und ein Diskmagazin-/Menü für meine SEGA Dreamcast programmiert. Ging ganz easy, weil es C++ Compiler für jede erdenkliche Platform gibt. Würde ich nur C# können, wäre die Einarbeitung in die Dreamcast-Programmierung um einiges schwerer gewesen. Will ich z.B. für ein SymbianOS-Smartphone ein Tool entwickeln, komme ich mit C# nicht sehr weit, sondern kann das standardmäßig nur mit C++ machen. Mit C++ bin ich halt überall universell mit dabei.

    Wenn ich mich auf Mainstream-Platformen bewegen will, z.B. Windows und vielleicht noch Linux, kann man C# sehr wohl in Betracht ziehen. Denn für Mainstream-Platformen gibt es nunmal C# die Code für CLI erzeugt. Ob ich .NET-spezische Implementierungen nutze, oder nur die ECMA-Specs, ist dann die Sache des Programmierers.

    0
  • ?

    Die Lernkurve ist bei C# deutlich einsteigerfreundlicher als bei C++.

    Als Anfänger muss man sich um Dinge wie Plattformunabhängigkeit(die in den meisten Fällen eh nur aus unbegründet ideologischen Denken hervorgeht), Hardwarezugriffe usw. eh nur bedingt kümmern.

    Man sollte sich lieber drauf konzentrieren die Grundlagen zu lernen und da ist C# um einiges klarer. Im Gegensatz zu C++ ist C# wirklich objektorientiert und hat dieses Programmierparadigma nicht nur als Aufsatz. Es gibt weniger Fallstricke und durch die umfangreiche Klassenbibliothek wird man praktsch gezwungen sich aktiv mit Objektorientierung auseinanderzusetzen.

    Wenn man C# wirklich beherscht, dann ist es imo ein Leichtes C++ zu erlernen. Da man aus dem OO Bereich kommt, fällt man nicht sofort in die eher C als C++ Schiene rein, und bis auf Kleinigkeiten bietet C++ auch nicht mehr Sprachfeatures als C#. Zeiger und Co. lernt man implizit durch Werte und Referenztypen in C# - das auf Zeiger umzumünzen ist nun wirklich keine Hürde. Templates in C++ und Generics in C# sind zwar technisch verschieden, programmieren sich aber ähnlich, denke da gibts auch kaum Schwierigkeiten.

    Man sieht schon, meine Argumentationskette läuft daraus hinaus C# zu empfehlen 😉

    Sich mit dem .Net Framework auseinanderzusetzen kann auf keinen Fall schaden da Microsoft diese Technologie arg forciert. Ein Vorteil den du dann sogar hast ist die Sprachunabhängigkeit. Du kannst genauso gut auch dann in C++/CLI einsteigen, hast dein gewohntes Framework um dich herum, kannst aber auch "normales" unmanaged C++ programmieren.

    Zu deiner Ursprungsfrage ob man evtl. beides lernen sollte: Lern eins von beiden, dafür richtig. Beim Programmieren lernen geht es an sich weniger darum eine Sprache zu beherschen, sondern die Konzepte hinter dem Programmieren. Wenn du bissle Erfahrung in OO Programmierung hast, ist es ein leichtes andere Sprachen zu lernen die dieses Paradigma nutzen. Die Sprachen sehen anders aus, aber die Logik ist immer die gleiche. Die Syntax von Sprachen wie Java, C++, C# lernt man in nem halben Tag, wenn man dann OO drauf hat, kann man an sich schon die gesamte Sprache - die Herausforderungen sind die Klassenbibliotheken 🙂 Und da hilft nur Zeit und Erfahrung sammeln um die Klassenbibliothek einer Sprache zu beherschen, das lernt man auch net in men halben Jahr.

    0
  • S

    Fedaykin schrieb:

    ...
    C# ist plattformunabhängig ...

    (std-konformes) C++ auch ! 😃
    Es gibt lediglich kaum C++-Interpreter ....

    Gruß,

    Simon2.

    P.S.: Ich weiß natürlich, dass in C++ die Plattformunabhängigkeit durch einige Spezifika (wie z.B. numeric_limits) eingeschränkt ist ...

    0
  • M

    Warum schimpfe ich auf MS?
    Das die CLI momentan nur von den Windows-Betriebssystem vollständig unterstütz wird, ist doch kein Vorwurf. Ich find CLI sogar richtig gut und Normen sind immer gut.

    Nur von einer Platformunabhängigkeit würde ich zum jetzigen Zeitpunkt nicht sprechen. Es ist ohne Frage möglich, man darf es auch umsetzen aber es hat eben noch keiner in der Art gemacht, dass ich so ohne weiteres platformunabhängig programmieren kann und darum gehts.

    Von den theoretischen Möglichkeiten alleine hab ich nichts.

    0
  • A

    Aber warum soll MS denn für Konkurrenzplattformen eine Implementierung anbieten? Diese Logic verstehe ich nicht. SUN implementiert Java nicht für MacOSX, sondern das macht Apple selbsts. SUN ist nicht in der Pflicht das zu tun. IBM implementiert auch sein eigenes Java für seine eigenen Systeme (zOS usw.). Wäre ja wohl etwas viel verlangt, wenn SUN für jede Platform auf diesem Planeten eine Impl anbietet. Sie machen das, für Windows (einfach unumgänglich) und für Solaris. Fertig. MacOS, zOS u.a. interessiert sie nicht. (was völlig verständlich ist) Also, warum soll MS für andere Platformen/Systeme eine .NET-Impl bereitstellen? Nur weil sie MS heißen? 😕

    0
  • M

    Ich habe ich irgendwas davon geschrieben, das MS das anbieten soll/muß?
    *nach les*
    Nö.. ich habe nur festgestellt, das man aktuell durch die Verwendung von CLI keine Platformunabhängigkeit erreicht.

    Mein Beispiel mit Java war eigentlich nur darauf ausgelegt, das SUN im Gegensatz zu MS ein ziemlich großes Interesse daran hat, das Java-Programme unter x beliebigen Betriebssystemen laufen.
    (und nicht das MS genauso machen müßte wie SUN...
    Wobei mich gerade das skeptisch macht im Bezug auf CLI und Platformunabhängigkeit.
    Man sieht ja am Java, wie schwierig es ist eine platformunabhängige Technik umzusetzen, auch wenn alle Beteiligten sich die Platformunabhängigkeit groß auf die Fahne geschrieben haben. Wie wird das dann bei CLI sein, wo MS das nicht wirklich will?)

    0
  • A

    WIeso will das MS nicht? Du fängst ja schon wieder an, MS was vorzuwerfen:

    Nö.. ich habe nur festgestellt, das man aktuell durch die Verwendung von CLI keine Platformunabhängigkeit erreicht.
    ...
    Wie wird das dann bei CLI sein, wo MS das nicht wirklich will?

    Und die Feststellung beruht auf was? Habe ich anscheinend nicht mitbekommen. FAKTEN FAKTEN FAKTEN bitte!
    Aber ich kann dir gerne sagen, woran man sieht, das MS ein Interesse daran hat: die CLI ist platformneutral spezifiziert. Punkt. Und das wurde nicht von MS alleine designed! Wenn das nicht für Platformunabhängigkeit steht, dann habe ich irgendwas nicht verstanden, was ich aber bezweifel.

    So, das war der technische Grund, warum die CLI platforunabhängig ist. Jetzt kommen wir zu dem evtl. augtretenden moralischen und motivatorischen Grund: Ja, auch hier hat MS gezeigt, das sie gewillt sind. 1. sie haben die CLI der ECMA und ISO übergeben. Wenn DAS kein Hinweis ist, dann erklärst du die gesamte ECMA und ISO für null und nichtig. Aha? Aber das wäre mir auch neu, das ECMA und ISO (dazu geört auch die DIN!) etwas dagegen haben, das jeder sich dieser Normen bedienen darf. 2. MONO wurde bisher von MS nocht nicht verklagt. Und MONO gibt es nicht erst der MS-Novell-Vereinbarung. Weiterhin gibts noch andere CLI-Implementierngen von ganz anderen Firmen, die hier niemandem namentlich bekannt sein dürften.

    Also, liefere bitte Fakten ab. Du stellst behauptungen auf, ohne diese Untermauern zu können.

    0
  • M

    Einigen wir uns darauf das du recht hast und wir reden weiter wenn das erste Programm über die Ladentheke geht, das CLI verwendet und auf mehreren Betriebssystemem lauffähig ist, ok?
    😃

    0
  • Z

    Naja irgendwann war mal so ein Hinweiss in der MSDN, die Informationen dürfen nicht zu den Projekt Mono beitragen *gg*

    0
  • A

    Mathias schrieb:

    Einigen wir uns darauf das du recht hast und wir reden weiter wenn das erste Programm über die Ladentheke geht, das CLI verwendet und auf mehreren Betriebssystemem lauffähig ist, ok?
    😃

    Gerne: http://www.vistadb.net/ :p Und noch ein Zitat von der Homepage:

    New! Native support for Mono
    The same VistaDB assembly for .NET 1.1 runs unchanged on Mono. Build fully managed and typesafe cross-platform database applications for Windows, Linux, Mac OS X, Sun Solaris and BSB operating systems with VistaDB and the Mono Framework.

    Und die News dazu: http://www.vistadb.net/blog/?p=12

    0
  • D

    Artchi schrieb:

    Mathias schrieb:

    Einigen wir uns darauf das du recht hast und wir reden weiter wenn das erste Programm über die Ladentheke geht, das CLI verwendet und auf mehreren Betriebssystemem lauffähig ist, ok?
    😃

    Gerne: http://www.vistadb.net/ :p Und noch ein Zitat von der Homepage:

    New! Native support for Mono
    The same VistaDB assembly for .NET 1.1 runs unchanged on Mono. Build fully managed and typesafe cross-platform database applications for Windows, Linux, Mac OS X, Sun Solaris and BSB operating systems with VistaDB and the Mono Framework.

    Und die News dazu: http://www.vistadb.net/blog/?p=12

    waers in java und die ide integration fuer eclipse gemacht waer man plattform flexibler.

    so rennt grad die db mit mono, und obs gleichwertig lauft is einmal danhingestellt.

    tatsache ist, die plattformunabhaenigkeit von C# und CLI sind hptsaechlich ein gutes mareting argument fuer MS, und solang nicht das gesammte framework fuer andere plattformen verfuegbar is sind C# apps ungefaehr genauso unabhaenig wie c++ apps mit mfc, dh portierung theoretisch eh moeglich, praktisch...

    0
  • .

    Mathias schrieb:

    (Es wäre durchaus möglich, dass jemand einen C#-Compiler entwickelt, der ebenfalls Maschinencode erzeugt.)

    Aber keinen standardkonformen 😉

    daHa schrieb:

    tatsache ist, die plattformunabhaenigkeit von C# und CLI sind hptsaechlich ein gutes mareting argument fuer MS, und solang nicht das gesammte framework fuer andere plattformen verfuegbar is sind C# apps ungefaehr genauso unabhaenig wie c++ apps mit mfc, dh portierung theoretisch eh moeglich, praktisch...

    Es stimmt, dass einige elementare Bestandteil von .NET zB WindowsForms (die aber nicht zum Standard gehören) noch nicht mono oder dotGNU funktionieren, aber das eigentliche Portabilitätsproblem ergibt sich imho daraus, dass man in den .NET-Sprachen auch die WinAPI und andere "alte" DLLs ansprechen kann und das auch durchaus genutzt wird. Ich glaube, das sollte in Mono über eine Brücke zu Wine gelöst werden, ich weiß aber nicht, was daraus geworden ist.

    0
  • Z

    Architektonisch stützt sich die .NET-Libs auf Win32 API und das wollte Microsoft auch so.
    Um Platfromabhäniger zu sein müsste in Mono die WinForms durch ein anderes GUI-ToolKit implementiert wird, so ähnlich wie IBM es mit SWT getan hat.
    Ich spekuliere mal, dass Mono-Projekt dass nicht wollten, wegen offensichtlicher Rechtsstreit, deswegen etablierte Mono GTK#.

    0
  • F

    Hallo,

    also ich habe mich zu erst mit Java beschäftigt, um die OO zuverstehen. Danach kam C++. C++ ist um einiges schwieriger und es ist nicht so leicht wie C# oder Java. Als Anfänger kommt man mit den managed Sprachen besser vorran.

    Da ich ein OpenGL und DirectX Süchtiger bin, habe ich mir dann nach und nach C++ beigebracht (bin immer noch dabei). Einige meiner Kollegen halten mich für bescheuert, weil ich mich heute noch mit C++ so intensiv befasse. Ich bin aber von dieser Sprache verzaubert und mir macht es einfach Spass damit was zu machen. Außerdem ist das Erfolgsgefühl höher, wenn man etwas mit C++ geschafft hat.

    Grüße

    Fireball

    0
  • D

    Da ich ein OpenGL und DirectX Süchtiger bin, habe ich mir dann nach und nach C++ beigebracht

    Was hat das eine mit dem anderem zu tun?

    0
Anmelden zum Antworten