Grundlegende Unterschiede zwischen C# und JAVA ?
-
Hallo, ich habe mich ein wenig mit C# auseinandergesetzt, nun sehe Ähnlichkeit mit der Programmiersprache JAVA.
Was sind die größten Unterschiede zwischen diesen Objektorientierten Sprachen, was kann die eine besser als die andere?
-
Es gibt massig Posts die sich mit Spraceh X vs. Y beschäftigen. Da ist bestimmt auch eine Spezialisierung für C# und Java dabei.
-
da ich für meinen job neuerdings auch code in c# tippen muss
delegates/lambda - List.Where(x => x.Size > 23); -echt feine sache
nullables (int ? x = null) auch cool
?? operator naja vermisse ich in java nicht
Linq - sehr mächtig
xml für die dokumentation
partial classes - find ich persöhnlich einfach nur scheiße
mit as kann man sicher casten
properties
properties nur mit get/set
konstruktoren selber zum initialisieren zusammenbauen
generics sind den java generics in dem punkt überlegen, dass sie auch zur laufzeit erhalten bleiben
c# hat das schlüsselwort override - in java macht man das seit version 5 über annotations
c# hat für die erweiterte for schleife extra 2 schlüsselwörter
(foreach (int x in
) - find ich in java besser gelöst
namespaces statt pakete
man kann mit this funktionen zu bestehenden klassen hinzufügen - ms hat davon selbst extrem gebrauch gemachtmacht schon spaß, hat vor und nachteile manche sachen hätte ich gerne in java, closures werden kommen
andere möchte ich niemals in java sehen
c# hat gefühlte doppelt so viele schlüsselwörter
-
Java ist Plattformunabhängig und .NET gibts nur für Windows.
(ka obs Tools gibt um .NET auf anderen Systemen zu emulieren)
Wenn du sowieso nur für Windows entwickelst, würde ich eher C# mit .NET empfehlen.
-
Melan schrieb:
Java ist Plattformunabhängig und .NET gibts nur für Windows.
(ka obs Tools gibt um .NET auf anderen Systemen zu emulieren)
Wenn du sowieso nur für Windows entwickelst, würde ich eher C# mit .NET empfehlen.es gibt mono
und warum c# vor java, selbst wenn man nur für windows entwickelt?
denn selbst wenn ich nur für windows entwickeln möchte, sehe ich nicht DEN vorteil, so ist z.B. eclipse dem visual studio gnadenlos überlegen
-
golden_jubilee schrieb:
und warum c# vor java, selbst wenn man nur für windows entwickelt?
denn selbst wenn ich nur für windows entwickeln möchte, sehe ich nicht DEN vorteil, so ist z.B. eclipse dem visual studio gnadenlos überlegenaeh... nein.
c# integriert sich besser in windows. zB wenn du services schreiben willst oder spezielle api funktionen verwenden - geht mit java nur umstaendlich. selbiges bei com einbindung.
und dass eclipse vs ueberlegen ist... aeh... ne, ich sehe nicht wo. es ist vielleicht nicht unterlegen - aber welche features fehlen dir in vs?
-
C# im Vergleich zu anderen Sprachen:
-
Shade Of Mine schrieb:
c# integriert sich besser in windows. zB wenn du services schreiben willst oder spezielle api funktionen verwenden - geht mit java nur umstaendlich. selbiges bei com einbindung.
genau deswegen würde ich wenn ich nur unter Windows entwickle C# nehmen.
Außerdem kann es vielleicht sein, dass .NET die Zukunft wird bei der Entwicklung unter Windows und die WinApi und MFC ersetzten bzw. gleichbedeutend wird.
-
http://www.galileocomputing.de/openbook/csharp/kap34.htm schrieb:
Der größte Unterschied besteht darin, dass sich C# oberhalb der.NET-Frameworks und der .NET-Laufzeit befindet und Java den Frameworks und der Laufzeit von Java übergeordnet ist.
Das verstehe ich absolut nicht
C# ist oberhalb von Framework und Laufzeit
Java ist Framework und Laufzeit übergeordnetAbgesehen davon, dass sich diese beiden Sätze für mich nicht groß unterscheiden, wo ist da der "größte Unterschied" zwischen C# und Java?
-
Melan schrieb:
Außerdem kann es vielleicht sein, dass .NET die Zukunft wird bei der Entwicklung unter Windows und die WinApi und MFC ersetzten bzw. gleichbedeutend wird.
Wann kapiert Ihr das endlich das .NET ein Wrapper der WinAPI ist genau wie MFC, QT, wxwidgets oder was es sonst noch so gibt.
Deswegen wird es die WinAPI geben und in naher Zukunft nicht ersetzt werden!
-
Noch nicht genannt, aber imho sehr wichtig:
C# kennt (auch benutzerdefinierte) Werttypen, also solche, die nicht als Referenz verwaltet sondern tatsächlich kopiert werden.
C# kennt call-by-reference, also z.B. die Möglichkeit, das Zielobjekt einer übergebenen Referenz zu wechseln.
C# kennt mit dem using-Schlüsselwort und dem Disposeable-Pattern eine Möglichkeit, RAII ohne try-finally nachzubilden.
-
Wann kapiert Ihr das endlich das .NET ein Wrapper der WinAPI ist genau wie MFC, QT, wxwidgets oder was es sonst noch so gibt.
Deswegen wird es die WinAPI geben und in naher Zukunft nicht ersetzt werden!WPF nicht.
-
besserwisser schrieb:
Wann kapiert Ihr das endlich das .NET ein Wrapper der WinAPI ist genau wie MFC, QT, wxwidgets oder was es sonst noch so gibt.
Deswegen wird es die WinAPI geben und in naher Zukunft nicht ersetzt werden!Falsch.
Ja, noch ist es zum Teil (aber nicht vollständig) ein Wrapper. Aber es ist bereits angedacht, das sich dies in Zukunft ändern wird. Einzelne Aussichten vermitteln schon zwei Projekte von Microsoft wie Singulary und ich glaube Green (oder wie es heißt) die sich völlig von der API verabschiedet haben (Thema Microkernel mit .Net als Aufsatz).
Ich bezweifel das dies bereits in der nächsten oder übernächsten Windowsgeneration entgültig ist, aber ich würde mich da nicht gänzlich festlegen wollen.
-
In der aktuellen c't steht auch darüber was drin
(Singularity und das andere Zeugs)
-
Shade Of Mine schrieb:
golden_jubilee schrieb:
und warum c# vor java, selbst wenn man nur für windows entwickelt?
denn selbst wenn ich nur für windows entwickeln möchte, sehe ich nicht DEN vorteil, so ist z.B. eclipse dem visual studio gnadenlos überlegenaeh... nein.
c# integriert sich besser in windows. zB wenn du services schreiben willst oder spezielle api funktionen verwenden - geht mit java nur umstaendlich. selbiges bei com einbindung.
und dass eclipse vs ueberlegen ist... aeh... ne, ich sehe nicht wo. es ist vielleicht nicht unterlegen - aber welche features fehlen dir in vs?
sei doch mal ehrlich...
1. eclipse importiert die pakete selber im studio schreib ich immer den namespace hin, nachdem ich rausgefunden habe welcher es ist2. mit eclipse kompiliere ich keinen code der nicht syntaktisch falsch ist, sicher im vs werden mir manche sachen auch markiert, aber eben nicht alles, so passiert es das ich code kompiliere und doch einen trivialen tippfehler hatte
3. die vorschläge die eclipse bietet, wenn man etwas falsch macht sind ja der hammer
4. wo werden mir im vs variablen im code markiert, die z.B: nie gelesen werden?
5. warum muss ich beim ersten mal 2 mal die projekteigenschaften aufrufen? - so ein übler bug ist niemanden aufgefallen(ist bei meinen kollegen das selbe)
6. gute kostenlose svn plugins? - nicht für das vs
7. IntelliSense kann gegen eclipse 3.4 einpacken
8. mindestens einmal am tag gibt es ein problem, weil noch temp dateien rumliegen
9. vs ist eindeutig langsamer
vlt benutze ich es ja nur falsch
aber ich bin seit dem studio 2003 dabei- welches ich - ja das muss man mal sagen als original im schrank zu stehen habe
ich möchte nicht rumflamen, schließlich kann jeder seine ide selber wählen
aber wenn man mich fragt, dann schreib ich halt warum es aus meiner sicht die schlechtere ide ist
-
golden_jubilee schrieb:
1. eclipse importiert die pakete selber im studio schreib ich immer den namespace hin, nachdem ich rausgefunden habe welcher es ist
packages != namespace
Weiterhin macht vieles nicht Eclipse, sondern die Reflection von Java! Eclipse schmeisst die JVM an und fragt über Reflection die Eigenschaften ab. Das ist also kein IDE-Feature, sondern es wird von der IDE dem User lediglich visualisiert und interaktiv angeboten. Schmeiss mal Reflection raus aus Java, und die IDE kann dann auch nichts mehr bzw. die Eclipse-Entwickler müssten erstmal einen Parser bauen.golden_jubilee schrieb:
2. mit eclipse kompiliere ich keinen code der nicht syntaktisch falsch ist, sicher im vs werden mir manche sachen auch markiert, aber eben nicht alles, so passiert es das ich code kompiliere und doch einen trivialen tippfehler hatte
Wenn du selber kompilierst, ist das ja dein Verschulden, oder? Eclipse und Co. kompileren immer dann, wenn du STRG+S drückst. In MSVC drückst du halt STRG+F7. Der Effekt ist der gleiche.
golden_jubilee schrieb:
3. die vorschläge die eclipse bietet, wenn man etwas falsch macht sind ja der hammer
Ja, das ist ein sehr gutes Feature. Kann man so nichts gegen sagen. Aber Java ist auch eine Pipifax-Sprache, da sind Fehlerkorrektur-Vorschläge einfacher zu realisieren. Aber wir vergleichen hier wieder zwei verschiedene Sprachen in unterschiedlich großem Komplexität.
Wer Fehlerkorrektur-Vorschläge unter MSVC braucht, gibt den Error-Code in die MSDN-Index ein, und bekommt meistens einen textuellen Vorschlag. Ist zwar nicht automatisch, aber kann man manuell in MSVC lösen. Ist kein Ersatz, aber es ist auch nicht so, das es nichts gibt.
golden_jubilee schrieb:
4. wo werden mir im vs variablen im code markiert, die z.B: nie gelesen werden?
Der Compiler spuckt Warnings aus... doppelklick auf die Warning und der zeigt dir die Stelle an. Klar, kein 100% Ersatz, aber es gibt was.
golden_jubilee schrieb:
5. warum muss ich beim ersten mal 2 mal die projekteigenschaften aufrufen? - so ein übler bug ist niemanden aufgefallen(ist bei meinen kollegen das selbe)
Der Bug ist mir in MSVC2005 nicht bekannt. Habe mal MSVC2003 gehabt, aber müsste ich lügen.
golden_jubilee schrieb:
6. gute kostenlose svn plugins? - nicht für das vs
Ich benutze AnkhSVN, funktioniert wunderbar:
http://ankhsvn.open.collab.net/golden_jubilee schrieb:
7. IntelliSense kann gegen eclipse 3.4 einpacken
Yo, stimmt. Weiß auch MS und kann man auch in einem der MSVC-Blogs nachlesen. Aber jeder MSVC-user investiert ehrlich gesagt auch lieber in Visual Assist X.
golden_jubilee schrieb:
8. mindestens einmal am tag gibt es ein problem, weil noch temp dateien rumliegen
Aha? Wäre mir neu. Das ist jetzt ehrlich gesagt ein sehr ungenaue und schwer beweisbare Anschuldigung von dir. Ich kanns jedenfalls nicht nachvollziehen.
golden_jubilee schrieb:
9. vs ist eindeutig langsamer
Kann ich nicht bestätigen.
Übrigens, ich arbeite seit mind. 6 Jahren beruflich mit Eclipse. Weiß also sehr wohl zu vergleichen.golden_jubilee schrieb:
vlt benutze ich es ja nur falsch
Nö, du hast nur nicht verstanden, wie die Eclipse-IDE arbeitet und warum sie für Java so tolle Features hat. Aber gibt es diese Features auch 1:1 für C++? (ich meine von Eclipse CDT!!! Denn du hast ja die IDEs verglichen, oder?)
Java- und C++-IDEs zu vergleichen ist nicht sehr klug, wenn man bedenkt wie komplex die beiden Sprachen sind.
Ich kann dir nur empfehlen, VisualAssist X zu benutzen. (Demo gibts kostenlos) Hat sehr nette Features.
-
Artchi schrieb:
Java- und C++-IDEs zu vergleichen ist nicht sehr klug, wenn man bedenkt wie komplex die beiden Sprachen sind.
Ich dachte, es ginge hier um C# und nicht C++?
-
Chewie83 schrieb:
Artchi schrieb:
Java- und C++-IDEs zu vergleichen ist nicht sehr klug, wenn man bedenkt wie komplex die beiden Sprachen sind.
Ich dachte, es ginge hier um C# und nicht C++?
Dann halt C#. C# ist ungefähr vergleichbar vom Konzept mit Java. Auch wenn C# ein paar Features mehr hat als Java. Aber C++ ist trotzdem noch ein anderes Kaliber.
Du kannst ja gerne mal einen C#- oder Java-Compiler implementieren. Und dann einen C++-Compiler. Welchen Compiler wirst du wohl schneller fertig bekommen? Siehste!
Und genau diese Komplexität kann man auch auf IDE-Features bzgl. der Sprachen übertragen.
-
Artchi schrieb:
Aber C++ ist trotzdem noch ein anderes Kaliber.
Eben drum, da stimme ich Dir absolut zu. Aber ich denke, was in Eclipse/JDT bezüglich Refactoring und Fehlerkorrektur möglich ist, sollte doch auch in ähnlicher Form mit C+ funktionieren, insofern muss ich dem Vorposter mit dem Eclipse-VS-Vergleich rechtgeben. Auch wenn ich seit VS 2003 keine Version mehr gesehen hab, aber an den Punkten, die er aufzählt, scheint sich nicht viel getan haben.
-
Shade Of Mine schrieb:
und dass eclipse vs ueberlegen ist... aeh... ne, ich sehe nicht wo. es ist vielleicht nicht unterlegen.
kennst du intellij-idea (ist 'ne java-ide)?
*die* ist eclipse, netbeans und visual studio haushoch überlegen.