# C++ und Java



## DynamiX (8. Sep 2003)

Wollt mal wissen wie Ihr dazu steht:

In Codingzone.de liefern C++ Progger seeeeeeeeehr überzeugende Argumunte dass C++ besser ist. Könnt ihr mir sagen was (auser plattformunabhängigkeit) gut an Java ist? So langsam glaub ich nämlich auch, dass C++ besser is[/url]


----------



## Stefan1200 (8. Sep 2003)

Naja, in bestimmten Bereichen ist C++ natürlich die bessere Wahl, da man ohne Kenntnisse in DLL Programmierung (was meist C++ ist) mit Java das Betriebssystem und die Hardware nicht direkt ansprechen kann. Also für Hardware Diagnose Programme, Spiele Trainer (Cheatprogramme) und ähnliche Dinge ist C++ natürlich vorzuziehen.

Andererseits sind viele Dinge wie System Tray unter Windows auch als kostenloses Zusatz für Java verfügbar, wenn man weiss wo, ohne das man gleich C++ lernen muss.

Vorteile von Java sind unter anderem, das man sich nicht um Speicherfreigaben kümmern muss. Auch die Systax ist für Anfänger leicht zu verstehen. Weiterhin muss man sich bei Java nicht umgewöhnen, wenn man GUIs auf anderen Betriebssystemen programmieren möchte. Bei C++ muss unter jedem Betriebssystem die GUI anders programmiert werden.

Das Gegenargument bei Java, das Java sehr langsam sein soll, kann heute nicht mehr so richtig stehen gelassen werden, seit dem Java RE 1.4.1 oder gar 1.4.2. Lediglich das starten von Programmen und teile der Swing Oberfläche sind nicht so performant als in C++. Aber an anderen Stellen traue ich meine Augen nicht, wenn ich meine Java Programme regelrecht fliegen sehe, und fast nicht glauben kann, das dies eine Java Application ist.


----------



## mariopetr (8. Sep 2003)

suche nal ne woche lang in c++ nach einem speicherleck. danach wilst du nimmer. ganz zu schweigen von dem deutlich struckturierterem code, den vielen packages, den bussinesextensions, .. . natuerlich wird man mit java so schnell keine treiber oder shooter schreiben, aber dafuer ist ja java auch nicht gedacht.


----------



## Hogo (12. Sep 2003)

Warum nicht? 
  Java ist eine vollständige und komplexe Sprache. Ich wunder mich sowieso, warum sich noch niemand die Mühe gemacht hat ein JOffice oder andere große Programme zu schreiben. Das Manko wird meist auf Swing geschoben, was doch ein wenig hinkt. Aber seit mit Eclipse das SWT gekommen ist, kann man sich über eine flüssige GUI nicht beschweren.
  Ausserdem muss an Java doch mehr dran sein, als plattform Unabhängigkeit. Sonst hätte Microsoft ja nicht auf .Net gesetzt, sonder vielleicht auf MC++.

Gruß,

 Hogo


----------



## stev.glasow (23. Okt 2003)

womit wurde(wird) OpenOffice geschrieben ?


----------



## HeyMan (15. Dez 2003)

des weiteren hat java riesen vorteile im web bereich. ein servlet zB wird beim start 1 mal geladen und beansprucht bei gelegenheit den speicher. danke an tomcat servletcontainer.
wie toll zB c/++ cgi's sind muss ich wohl nicht erwähnen.  :? 

Heyman


----------



## AlArenal (15. Dez 2003)

Hogo hat gesagt.:
			
		

> Ausserdem muss an Java doch mehr dran sein, als plattform Unabhängigkeit. Sonst hätte Microsoft ja nicht auf .Net gesetzt, sonder vielleicht auf MC++.



Ich glaube hier liegt ein Verständnisproblem vor. .NET ist keine Programmiersprache, sondern ein Framework. In allen aktuellen Sprachen von MS gibt es Bindings zu .NET, ebenso gibt es diese mittlerweile in Produkten von Mitbewerbern und auch als Open Source.

Wenn ich in .NET in meinen Visual C++ - Anwendungen einsetze, dann werden die dadurch nicht mehr oder weniger plattformunabhängig.


----------



## Reality (20. Jun 2004)

stevg hat gesagt.:
			
		

> womit wurde(wird) OpenOffice geschrieben ?


Achwas, oder? Nur weil es von Sun ist, ist es doch nicht in Java geschrieben. Mit dem gleichen Argument kam ich mal in einem Linuxforum und einer hat mich ausgelacht.

Liebe Grüße
Reality


----------



## EagleEye (21. Jun 2004)

Reality hat gesagt.:
			
		

> stevg hat gesagt.:
> 
> 
> 
> ...


installiere mal openoffice dann wirste sehn das es in (oder teileweise in java geschrieben ist) weil es um vollständige funktionalität zu haben java braucht


----------



## Oxygenic (22. Jun 2004)

Was heißt besser? Besser WOFÜR? Für die Entwicklung von Treibern, realtime-fähiger Software etc. ist Java natürlich nicht zu gebrauchen. Dass sich in dem Bereich noch nicht mal C++ durchgesetzt hat und C noch Standard ist, idt dabei nur ein Detail am Rande. Hier wäre interessant, welche Maßstäbe und Ansprüche an eine Sprache gestellt werden, ansonsten ist jeder Vergleichsversuch sinnlos.

Aber wenn es darum geht, schnell komplexe Applikationen mit GUI (die noch nicht mal plattformunabhängig sein müssen) zu erstellen, dann ist Java ungeschlagen, da kannst du die Pfriemelei mit C++ vergessen. Soll eine GUI noch plattfomunabhängig sein, wird es ganz interessant - was nimmt der C++-Entwickler? WxGadgets? QT? Und neu compilieren muss er es für jede Plattform auch noch.


----------



## pogo (23. Jun 2004)

das argument das java langsamer ist zählt nichtmehr.
hab derletzt nen bericht gesehen, indem die geschwindigkeit getestet wurde.
da kan heraus, dass java und c++ gleichschnell sind.


----------



## dark_red (23. Jun 2004)

DynamiX hat gesagt.:
			
		

> In Codingzone.de liefern C++ Progger seeeeeeeeehr überzeugende Argumunte dass C++ besser ist.[/url]


Überzeugend? Das sieht für mich nach einer Ansammlung von Halbwissen und Vorurteilen von pubertierenden Schülern aus. Wenn wenigstens die C++ basher etwas C++ verstanden hätten, könnte man ja darüber reden. Zudem trollt der Eine nur rum. 

Nun ja... es gab schon bessere Diskussionen zum Thema. Mich lässt diese kalt. 



			
				DynamiX hat gesagt.:
			
		

> So langsam glaub ich nämlich auch, dass C++ besser is


Nun ja... das kann man so nicht stehen lassen. Man sollte sich davon lösen, dass A besser als B (oder umgekehrt). Zudem ist es auch ein wenig wie mit den Äpfeln und Birnen. Meist wird bei dieser Diskussion Java, als Programmiersprache und Technologie (Framework?) mit C++ als reine Programmiersprache verglichen. Dabei wird vergessen, dass ich mit Java-Syntax sehr wohl auch native Programme schreiben kann, so wie ich mit C++ Code auch Bytecode erzeugen kann.


----------



## Reality (23. Jun 2004)

Hi,


			
				pogo hat gesagt.:
			
		

> das argument das java langsamer ist zählt nichtmehr.
> hab derletzt nen bericht gesehen, indem die geschwindigkeit getestet wurde.
> da kan heraus, dass java und c++ gleichschnell sind.


habe dazu auch einige Tests gelesen, aber die Praxis zeigt bei mir immer etwas anderes. 
Egal ob Eclipse, NetBeans oder JBuilder; sie laufen bei mir alle relativ lahm.
Hat jemand schon mal mit Borland C++ Builder oder anderen Compilern/IDEs gearbeitet die mit C++ programmiert wurden? Ein Doppelklick und schon ist das Ding auf. Auch ruckelt bei mir manchmal JBuilder (Garbage Collector?).

Liebe Grüße
Reality


----------



## Beni (23. Jun 2004)

*Swing* war und ist, geradezu unverschämt, langsam. Der Rest von Java ist unterdessen _brauchbar _schnell geworden, abgesehen vom starten der VM :roll: . Schreib mal ein AWT-Progi...

Und zu Eclipse: 100'000 Icons, Rundungen, mitdenkende Hilfe etc... würde auch in einer anderen Sprache an den Ressourcen zerren.

Die Typen von Codingzone argumentieren mit "haben wir in der Schule gehabt", und, frei übersetzt, "ich will mich nicht anpassen". Naja, finde ich nicht sehr Überzeugend.

Statement zum Schluss: 
"der wahrlich gute Programmierer spricht mehrere Sprachen, und entscheidet abhängig der Aufgabe, welche Sprache geeignet ist."

mfg Beni


----------



## Grizzly (23. Jun 2004)

Beni hat gesagt.:
			
		

> [...]Statement zum Schluss:
> "der wahrlich gute Programmierer spricht mehrere Sprachen, und entscheidet abhängig der Aufgabe, welche Sprache geeignet ist."
> 
> mfg Beni



Dem stimme ich zu.


----------



## dark_red (23. Jun 2004)

Reality hat gesagt.:
			
		

> Hat jemand schon mal mit Borland C++ Builder


Du meinst den C++BuilderX? Mit was wurde der nochmal programmiert? 

SCNR (und ja... sehr provokativ  )


btw... das Ding ist wirklich schneller als andere Swing-Anwendungen. Dafür dass es eine Swing-Anwendung ist, ist es wirlich erstaunlich schnell, trotz der komplexität. Zum Starten braucht es auch "nur" in etwa gleich viel Zeit, wie die "classic" C++Builder (jaja... ich programmiere auch C++  :bae: ). Ich würde sagen, es ist trotzdem leicht träger, aber das liegt in einem Bereich, in dem es kaum spürbar ist.

btw2... ich finde die Idee mit dem C++ Builder X eigentlich super von Borland. Wieder einmal etwas Neues (Cross-Plattform C++, inkl wxWidgets für die GUI usw. ). Allerdings finde ich Borland auch nicht so toll. Habe letzhin einen sehr schlechten Eclipse/JBuilder vergleich von Borland gelesen (Eclipse soll eine unsichere rechtliche Lage haben - da Open Source - und Borland gibt als "Beleg" den SCO-IBM(Linux)-Konflikt an).


----------



## Reality (23. Jun 2004)

Hi,


			
				dark_red hat gesagt.:
			
		

> Reality hat gesagt.:
> 
> 
> 
> ...


ich habe nur den 5er und da flitzt er.
Mit was wurde C++ Builder X geschrieben?

Ausserdem ist es ziemlich oberflächlich zu sagen, dass Java gleich schnell ist wie C++, denn es existieren sehr viele C++ Compiler und alle sind unterschiedlich schnell! Der von MS ist z.B. einiges schneller als der von Borland. 

Ich kann mich übrigens Beni anschliessen. Ein richtig guter Programmierer kann mehrere Sprachen *noch viel vor mir hab*.

Liebe Grüße
Reality


----------



## dark_red (23. Jun 2004)

hehe... Ich habe ja nie behauptet, dass Java und C++ gleich schnell sind. Für nähere informationen über meine Meinung, einfach meinen ersten Post in diesem Thread konsultieren... 

Den C++Builder X hat Borland ironischerweise in Java geschrieben. Ist mehr oder weniger die selbe Oberfläche, wie vom JBuilder 9.

C++BuilderX Download / Demo (Flash)


----------



## Reality (23. Jun 2004)

Kannst du mir verraten, wie man in Java seine Programme in Binärcode compilieren kann? Möchte ich mal ausprobieren.

Liebe Grüße
Reality


----------



## Roar (23. Jun 2004)

Reality hat gesagt.:
			
		

> Kannst du mir verraten, wie man in Java seine Programme in Binärcode compilieren kann? Möchte ich mal ausprobieren.



gar nicht. Java bleibt Java und Bytecode bleibt Bytecode. Ansonsten wär das ja völlig unsinnig.


----------



## Reality (23. Jun 2004)

Auf der ersten Seite schrieb er folgendes:


> Dabei wird vergessen, dass ich mit Java-Syntax sehr wohl auch native Programme schreiben kann, so wie ich mit C++ Code auch Bytecode erzeugen kann.



Ich bin mal so offen und glaube ihm das. Mich würde interessieren wie (ohne JNI versteht sich).

Liebe Grüße
Reality


----------



## dark_re (24. Jun 2004)

der gcj aus der GCC kann  dies zum beispiel. ist allerdings meist eine bastellei. gibt ein paar verrückte, die sich eclipse mal so übersetzt haben. in der tat ist das ein wenig ketzerei.

zu c++ bytcode hatte ich auch einmal einen link. allerdings war das kein java bytecode, sondern ein eigener, der auch eine eigene vm vorausgesetzt hat. leider ist der link verloren gegangen... 

ob das in der praxis gebräuchlich ist, ist nicht so wichtig. es ging mir darum, dass nicht äpfel mit birnen verglichen werden. (oder apfel mit apfelsaft  )


----------



## Oxygenic (25. Jun 2004)

Roar hat gesagt.:
			
		

> Reality hat gesagt.:
> 
> 
> 
> ...



Stimmt zwar nicht, aber macht ja nix.

Es gibt Compiler, die Executeables aus Bytecode erzeugen. IBM hat/hatte mal einen. Ein anderer Vertreter kommt von Excelsior und heißt Jet. Allerdings ist der Name irreführend, die Compilezeit ist gewaltig, und die resultierenden Executeables sind monströs. Nicht zu gebrauchen also.


----------



## ZeusOfCrete (30. Jun 2004)

Hallo zusammen,

eine Programmiersprache grundsätzlich in
"besser oder schlechter als..." einzustufen, führt
meistens nicht weit.

Sicher ist: Die Java - Performance ist besser, als ihr Ruf !

Viele Grüße

Zeus

http://www.kano.net/javabench/
http://www.golem.de/0406/31579.html


----------



## Dr. Morv (21. Okt 2004)

Man kann eine Programmiersprache gar nicht einordnen, da "mehr Möglichkeiten" ja oft "mehr Arbeit für den Progger" heißt. Es kommt also nur darauf an, wonach man geht. Übrigens ist es für mich schon relevant, ob ich mit einer Programmiersprache eine Exe erzeugen kann.  Da ist z.B. QBasic besser als Java, denn mit QuickBasic 4.5 kann man exes erstellen. Aber keiner würde ernst haft behaupten, Basic sei deswegen allgemein besser als Java. Ich denke, C++ lässt einem mehr Dinge auf eigene Verantwortung tun. Dafür kann man auch gemeine Fehler machen wie das zugreifen auf Arrayindizes, die es gar nicht mehr gibt. Dafür hat Java einfachere Multimediamöglichkeiten, aber sehr viele Klassen, die zum Teil recht sinnlos sind (ich darf an den Media Tracker erinnern).


----------



## Grizzly (21. Okt 2004)

Dr. Morv hat gesagt.:
			
		

> [...]Dafür hat Java einfachere Multimediamöglichkeiten, aber sehr viele Klassen, die zum Teil recht sinnlos sind (ich darf an den Media Tracker erinnern).



Ist der MediaTracker nicht zum Prüfen, ob ein Bild vollständig geladen wurde? ???:L


----------



## Roar (21. Okt 2004)

@grizzla: ehm, ja eigentlich schon.

@morv: das argument mit den executables is ja wohl n witz ("argument" ist vielleicht falsch. relevanz, wie du sagtest). das is doch nur ne windumm.explorer-nutzer-end-user-bequemlichkeit. und da java plattformunabhängig ist und zudem zu großen teilen auch andere einsatzgebiete als den desktop hat sind executables bei java fehl am platz :-/

gruß
Roar, _der auch JSmooth benutzt_


----------



## L-ectron-X (22. Okt 2004)

Grizzly hat gesagt.:
			
		

> Dr. Morv hat gesagt.:
> 
> 
> 
> ...



Nicht nur, er dient zum Vorladen (cachen) derzeit nur von Grafikdateien.
Schreibe mal ein Grafik lastiges Applet ohne MediaTracker, dann siehst Du den Unterschied.
Demzufolge würde ich nicht sagen, dass die Klasse MediaTracker "recht sinnlos" ist.

Und außerdem: Wozu exe-Dateien? Es gibt jar-Dateien, die ähnliches leisten.
Wenn man exe-Dateien publiziert, braucht man immer noch ein JRE.


----------



## Grizzly (22. Okt 2004)

Wenn man es _sehr_ abstrakt sieht, hat ein Windows Executable (eine stink normale Anwendung, kein Treiber o.ä.) auch ein JRE bzw. läuft unter einem. Windows stellt dabei die Sandbox dar. Dabei wird der _Byte-Code_ zu einem großen Teil direkt auf dem Prozessor ausgeführt. Und die Windows API entspricht den Java Klassen.
Da aber, wie gesagt, die Byte-Code direkt ausgeführt wird, können Windows Programm nicht unabhängig von der Systemarchitektur ausgeführt werden.


----------



## 0xdeadbeef (22. Okt 2004)

Habe mich jetzt einige Zeit mit Java beschäftigt und werde es auch weiterhin tun, aber es gibt doch einige Dinge, die ich in Java nicht so toll finde:

1) Keine Destruktoren: in C++ kann man seine Klasse sauber abschließen (Handles zurückgeben usw.), indem man diese nötigen Aufräumarbeiten im Destruktor erledigt. In Java gibt es nur die Methode "finalize()", deren Aufruf aber irgendwann mal passiert, wenn die Garbage Collection die Klasse tatsächlich löscht.

2) Die unterschiedliche Behandlung von Basistypen und Objekten ist einigermaßen eigentümlich. Speziell bei der Übergabe als als Parameter wird zwar in beiden Fällen "copy by value" benutzt, weil Objekte in Java aber immer Referenzen sind, bekommt man immer eine Referenz auf ein Objekt, aber niemals auf einen Basistyp. Insofern kann man auch nicht ohne weiteres mehr als einen Basistyp zurückgeben, dazu muß man wieder ein Container-Objekt benutzen. Wesentlich schöner wäre eine gleichartige Behandlung von Basistypen/Objekten und die manuelle Auswahl zwischen "by value" und "by reference" gewesen.

3) Das gleiche Problem dehnt sich auf den Zuweisungsoperator "=" und die Vergleichoperatoren "==" usw. aus. Die Zuweisung von Referenzen mag machnaml noch sinnvoll sein, der Vergleich von Referenzen (speziell >= usw.) ist das aber kaum jemals. Hier merkt man halt, daß das Überladen von Operatoren doch ein interessantes Sprachmerkmal ist, auch wenn es die wenigsten C++-Programmieren selsber benutzen: zumindest für die Bibliotheksfunktionen trägt Operatorenüberladung aber viel zur Eleganz einer Sprache bei.

4) Ich finde es extrem eigenartig, daß es keine unsigned Integertypen gibt. Zudem sind einige der Erweiterungsregeln äußert merkwürdig (byte + byte = int).

5) In Java ist man noch viel stärker als in C++ genötigt, ständig Instanzen zu erzeugen und wieder zu zerstören. Man könnte sogar sagen, daß die inflationäre temporäre Erzeugung von Objekten ein Sprachmerkmal ist. Zum einen gibt es keine einfache/standardisierte Methode, den Inhalt von Objekten zu kopieren, zum anderen benutzen einige Sprachmerkmale diese Features intensiv ("+"-Operator von String erzeugt temporäre Stringbuffer, Wrapperklassen usw.). Ich würde mal die Behauptung wagen, daß diese extrem hohe Frequenz der Objekterzeugung in Java-Programmen (Allokierung + Konstruktor-Aufruf!) großteils für die eher geringe Perfomanz vieler Java-Anwendungen verantwortlich ist.

6) Wrapperklassen sind ziemlich häßliches Design und kosten u.U. auch ziemlich Performanz. Z.B. wenn man Basistypen in einem Vektor o.ä. speichern will.

7) Bis Java1.5 gibt es keine typsicheren Containerklassen. Auch die nun eingeführten Generics sind offensichtlich nicht in jedem erdenklichen Fall 100% typsicher zur Compilezeit.

8 ) Daß man auf die Registry usw. nicht zugreifen kann, ist ja verständlich, aber warum braucht man bereits für Zugriffe auf die serielle Schnittstelle native DLLs, wenn doch auch Sockets platttformübergreifend implementiert sind? Von USB usw. ganz zu schweigen...

9) Zumindest bis v1.5  ist eine variable Anzahl von Parametern möglich, womit z.B. eine Funktion wie "printf" unmöglich ist. Wurde eventuell jetzt geändert, aber sicher bin ich mir jetzt auch nicht.


Es gibt allerdings auch eine Menge Sachen, die mir in C++ nicht so toll gefallen.


----------



## Illuvatar (22. Okt 2004)

1) Und was willst du in Java bitte in einen Destruktor schreiben, wenn alles automatisch aufgeräumt wird? Ich hab noch nie einen gebraucht.
2) Tja eine nichtprimitive Variable enthält halt immer die Speicheradresse, und wenn die kopiert bzw. verglichen wird, hat das eben nix mit dem Inhalt zu tun. Auch meiner Meinung nach ist es eine Schwachstelle von Java, dass es nicht rein objektorientiert wird, allerdings ist es immernoch besser als C++. Vorteil für C# (bzw .NET), wo _alles_ objektorientiert ist, und mit dem Parameter ref "by value" übergeben werden kann.
3) Nunja die fehlende Operatorüberladung kann man positiv und negativ sehen, sinnvoll eingesetzt, ist es sicher gut. Aber: wofür gibt es Object#equals, dass man überschreiben kann? Das macht ja dann auch kein Unterschied mehr zu einem Operator.
4) Hm... wusste ich gar net, stimmt aber, könnte auch short sein, was besser wäre.
5) Juchu... zurück zur prozeduralen Programmierung! Wenn man so blöd ist, zigmal Stringconcatenation zu benutzen statt nem StringBuffer, dann ist das sein Problem.
6) Naja, Autoboxing in Java5 is ja schonmal was. Sonst siehe 2.
7) Ach, wann nicht?
8) Naja, es gibt javax.comm (das kann man bei sun.com runterladen), das ist aber auch nicht für alles die Lösung. Dafür ist Java plattformunabhängig.
9) Und was ist dann OutputStream#printf (String, Object...) ?


----------



## Reality (22. Okt 2004)

Ist ja echt schlimm was die da schreiben...
http://board.codingzone.de/viewtopic.php?t=146&start=0&sid=280b2f535a514f67d8db47c2b941a799


----------



## Beni (22. Okt 2004)

Ja. *Halbwissen (bzw. gar-nicht-Wissen) gepaart mit einer vorgefassten Meinung... ist leider in allen Foren und in allen Threads so, in deren Titel _Java_ und _C++_ vorkommt.

(*z.B. über Dinge wie OOP, verschiedene Lösungswege, Syntax der Sprachen...)


----------



## bummerland (22. Okt 2004)

Reality hat gesagt.:
			
		

> Ist ja echt schlimm was die da schreiben...
> http://board.codingzone.de/viewtopic.php?t=146&start=0&sid=280b2f535a514f67d8db47c2b941a799



alter, nee du... das ist ja echt schlimm, was die da schreiben...  :bahnhof:


----------



## 0xdeadbeef (22. Okt 2004)

@Illuvatar:

zu 1) Die Garbage Collection gibt nur Speicher frei, aber keine Handles für Files usw. In kleinen Programmen ist das üblicherweise kein Problem, aber in großen Projekten kann es zu einem werden. Da ist die Methode über den Destruktor einfach wesentlich schöner, zumal sie ja auch im Fehlerfall funktioniert.

zu 3) equals wirkt nur auf Object -> nicht typsicher und man braucht einen cast. Außerdem ist "==" einfach griffiger und ja auch inkonsequenterweise korrekt bei den Basistypen.

zu 5) War ja nur ein Beispiel und *ich* bin mir der Probleme durchaus bewußt. Trotzdem kann man nicht leugnen, daß Java einen hier und dort zum Anlegen temporärer Objekte verleitet (clone und so).

zu 6) Nur oberflächlich. Der erzeugte Bytecode ist der gleiche.

zu 7) Es gibt dazu einige Diskussionen in den Java.sun.com-Foren. Ich wage es mir nicht, ein Urteil zu bilden, aber es scheint ein Compiler-Bug zu sein:
http://forum.java.sun.com/thread.jsp?forum=316&thread=563260&tstart=0&trange=15

zu 8 )  Ich weiß, aber es existieren nur native (!) Versionen für Win32 und Solaris. Selbst die Linux-Version ist von einem Privatmann portiert (empirisch, da es keinen Quellcode gibt, zudem nur der UART-Teil und nicht der Parallelport). Außerdem scheint mir das ganze etwas buggy. Z.B. werden mehrere der von der Hardware angebotenen Baudraten nicht korrekt unterstützt. Last but not least hat javax.comm eine sehr merkwürdige Methode, seine ini-Datei zu finden, die auch nicht korrekt dokumentiert ist. Mußte die API dekompilieren, um das in den Griff zu kriegen 

zu 9) Ich sagte ja, ich habe da was im Hinterkopf, daß es in der 1.5 dazugekommen ist. Ist allerdings die Klasse PrintWriter, nicht OutputStream. Und ist halt auch ein bisserl spät, genauso wie die Generics.


----------



## stev.glasow (22. Okt 2004)

becstift hat gesagt.:
			
		

> Reality hat gesagt.:
> 
> 
> 
> ...



Wundert dich das noch? Zeig mir eine Seite zu diesem Thema bei der beiderseits kein Mist verzapft wird. Oft gehen die Argumente doch nie über Performance, Platfomabhängigkeit und Syntax hinaus.


----------



## 0xdeadbeef (22. Okt 2004)

@steveq:
Na das sind halt auch die interessantesten Punkte. Das Problem ist halt oft, daß niemand wirklich beide Sprache _intensiv_ programmiert hat. Außerdem hat man halt seine (teils ideologischen) Präferenzen.

Mit zum Beispiel gehen alle Sprachen gegen den Strich, die kein ";" zum Trennen von Befehlen kennen und/oder sich auf die Einrückung anstelle von Klammern verlassen. Egal ob VB, Ruby oder Python: mit diesen Sprachen werde ich einfach nicht warm 
Das ist zwar "nur" Syntax, aber für mich persönlich reicht das manchmal schon.


----------



## Grizzly (22. Okt 2004)

0xdeadbeef hat gesagt.:
			
		

> [...]
> 8 ) Daß man auf die Registry usw. nicht zugreifen kann, ist ja verständlich, aber warum braucht man bereits für Zugriffe auf die serielle Schnittstelle native DLLs, wenn doch auch Sockets platttformübergreifend implementiert sind? Von USB usw. ganz zu schweigen...
> [...]



Das Sockets drin sind, die serielle Schnittstelle sowie USB aber hingegen nicht, ist mir klar. Wenn ich bspw. eine Verbindung zu einem Server im Internet aufbauen möchte, kann ich eigentlich nur über die Sockets gehen. Dabei ist es mir aber relative egal, ob das TCP/IP Paket nachher über die Netzwerkkarte zum Server wandert oder über das an der seriellen Schnittstelle oder am USB angeschlossenen Modem.
Und wenn ich bspw. auf einen USB Stick zugreifen möchte, werde ich das ja auch eher über den Laufwerksbuchstaben bzw. der Mount Point, und nicht direkt.

Es gibt nur ganz wenige Fälle, in denen man den direkten Zugriff braucht. Und in diesen wenigen Fällen braucht man dann halt entweder zusätzliche Bibliotheken oder JNI.

Mir persönlich gefällt an Java einige Teile der API nicht. Sun hällt sich teilweise dabei nicht an die eigenen Design-Empfehlungen. Am schlimmsten ist dabei die Swing - auch unter der Haube.

Java ist momentan mein Leib und Magen Programmiersprache - auch wenn da einige Macken und Probleme sind.


----------



## 0xdeadbeef (22. Okt 2004)

@Grizzly:
Naja, "javax.comm" zeigt ja, wie man die serielle/parallele Kommunikation sauber kapseln kann. Daß das Anfordern einer Baudrate oder das Senden von ein paar Bytes dann in irgendwelchen HW-Registern endet, ist ja gar auf der Interface-Ebene gar nicht sichtbar.
Mir ist irgendwie nicht so transparent, warum das ein so großer Unterschied zur Ausgabe von Musik, Grafiken oder TCP-IP Kommandos sein soll. Ich würde auch mal annehmen, daß USB ab einer bestimmten Protokollebene (ebenfalls) völlig von der Hardware abstrahierbar ist.
Deshalb gestatte ich mit den Luxus, diese Dinge weiterhin als Lücken in der (ansonsten ja sehr umfassenden) Klassenbibliothek zu sehen.

Ich muß Dir aber zustimmen, daß die teils sehr inkonsistente API ebenfalls ärgerlich ist. Auch schon ganz fundamentale Dinge wie: Array.length" (Attribut) aber "String.length()" (Methode) und Vector.size() unterscheiden sich. 

Ich wäre auch froh gewesen, wenn man bei der Sprachdefinition mehr Mut gehabt hätte, sich von C/C++ abzusetzen: beispielsweise finde ich die 1:1-Übernahme des häßlichen Switch-Case-Konstrukts bedauerlich. Wenigstens ein "fallthrough" Keyword anstelle des "break" wäre schonmal ein Ansatz gewesen, denn der Normalfall in einem Switch-Case ist ja aus Sicht eines Programmieres das Verlassen des Cases nicht das Weiterlaufen in den nächsten Case.

Aber um mal ein paar positive Dinge zu nennen: was ich an Java besonders schätze (in keiner besonderen Reihenfolge):

1) Javadoc (ok, unter C++ kann man Doxygen oder so einsetzen, aber es ist halt kein Bestandteil der C++-Kultur)
2) Die mächtige Stringklasse (reguläre Ausdrücke und so. während sich die C++-Fraktion zwischen verschiedene Stringklassen zerfleischt MFC/STL usw.).
3) Die mächtige und relativ zukunfstsichere Swing/JFC-API (während man ansonsten selbst auf einer Plattform den Launen des Anbieters folgen muß).
4) Die IMHO saubere - wenn auch striktere - Behandlung von Exceptions (Klassenhierarchie, während man in C++ irgendwas als Exception benutzen kann).
5) Das integrierte Threadmodell (mir ist unerklärlich, wie man in C++ nach wie vor nur single.threaded Anwendungen in der Norm unterstützen kann)
6) Die Verfügbarkeit großartiger freier Entwicklungstools wie Eclipse und Netbeans
7) Die Mögllichkeit zur Entwicklung von Anwendungen, Applets, Midlets und Servlets mit einer Sprache und ähnlichen Klassenbibliotheken.
8 ) Die sehr gute Unicode-Unterstützung und Lokalisierungsfunktionen.
9) Feste Größe von int usw. (ein stetiges Ärgernis unter C/C++)
10) Explizite Kurzschlußoperatoren (in C teils implementierungsabhängig)  und explizites logisches Xor (fehlt in C(++))
11) Seht guter Compiler, der große Teile der Funktionalität hat, die man für C mit PCLint o.ä. dazukaufen muß.
12) Der Einsatz von Labeln bei continue/break ist eine interessante Lösung als Goto-Ersatz (Verlassen von mehreren Schleifenkörpern auf einmal etc.)
13) Daß Arrays Objekte sind, mag zwar etwas Performance kosten, ist aber sehr elegant (length, Indexprüfung usw.).
14) Weil if (und dergleichen) nur boolsche Ausdrücke zuläßt, sind klassische Zuweisungsfehler nicht möglich ( "if (a=3) {}" ).


----------



## Grizzly (23. Okt 2004)

0xdeadbeef hat gesagt.:
			
		

> @Grizzly:
> Naja, "javax.comm" zeigt ja, wie man die serielle/parallele Kommunikation sauber kapseln kann. Daß das Anfordern einer Baudrate oder das Senden von ein paar Bytes dann in irgendwelchen HW-Registern endet, ist ja gar auf der Interface-Ebene gar nicht sichtbar.
> Mir ist irgendwie nicht so transparent, warum das ein so großer Unterschied zur Ausgabe von Musik, Grafiken oder TCP-IP Kommandos sein soll. Ich würde auch mal annehmen, daß USB ab einer bestimmten Protokollebene (ebenfalls) völlig von der Hardware abstrahierbar ist.
> Deshalb gestatte ich mit den Luxus, diese Dinge weiterhin als Lücken in der (ansonsten ja sehr umfassenden) Klassenbibliothek zu sehen.[...]



Normalerweise spricht man aber nicht die Hardware an der seriellen Schnittstelle an, sondern eher dessen Funktionalität. Bspw. spreche ich bei einem Modem an der seriellen Schnittstelle meist nicht das Modem an, sondern baue eine Verbindung über TCP/IP, das per PPP über die Modem-Verbindung geschickt wird, auf. Bei Druckern an der seriellen/parallelen Schnittstelle gilt ähnliches: Ich spreche den Drucker nicht direkt an, sondern drucke ganz einfach. Der Rest muss vom Betriebssystem und dem Druckertreiber erledigt werden.

Was ich aber nicht ganz verstehe, ist, warum Sun nicht entsprechende Zusatzbibliotheken anbietet. Ich meine, es muss ja nicht im JRE/JDK landen - die meisten Anwendungen brauchen das ja eh nicht - aber optional wäre nett. Wer sich jedoch mal mit der Java Communication API rumgeschlagen hat, weiss, dass die aus dem letzten Jahrtausend stammt (hey, das stimmt sogar  ) und außerdem offiziell nur für Windows und Solaris erhältlich ist (es gibt auch einen Workaround für Linux - Java Comm Serial API How-To for Linux - ist aber halt nur ein Workaround und keine echte Unterstützung).
Es wäre eine super Sache, wenn Sun diese Bibliotheken auch anbieten und vor allem pflegen würde.



			
				0xdeadbeef hat gesagt.:
			
		

> [...]14) Weil if (und dergleichen) nur boolsche Ausdrücke zuläßt, sind klassische Zuweisungsfehler nicht möglich ( "if (a=3) {}" ).



Das stimmt aber auch nur in Deinem Beispiel. Wenn ich bspw. boolean in der Klammer zuweise

```
boolean a = false;
boolean b = true;
if (a = b) { }
```
funktioniert das Ganze schon nicht mehr.


----------



## bummerland (23. Okt 2004)

Reality hat gesagt.:
			
		

> Ist ja echt schlimm was die da schreiben...
> http://board.codingzone.de/viewtopic.php?t=146&start=0&sid=280b2f535a514f67d8db47c2b941a799



Hab die Diskussion da noch mal angestachelt... hehe  :wink:


----------



## stev.glasow (23. Okt 2004)

becstift hat gesagt.:
			
		

> Reality hat gesagt.:
> 
> 
> 
> ...



Hehe. Einiges läuft nämlich echt schneller (hab ich mir sagen lassen  ). Aber durch einige Performanceschwierigkeiten von Swing hat Java seinen Ruf weg.
Mit diesem C++ Code wäre ich aber vorsichtig: bist du dir sicher, dass das nicht doch schneller zu realisieren ist?


----------



## DesertFox (23. Okt 2004)

Wenn ja, dann können es doch sicher die "c++ Profis", die doch so toll für C++ argumentieren und auch dann sicher so toll proggen können, das sicher gut verbessern


----------



## 0xdeadbeef (24. Okt 2004)

Ich würde mal behaupten, es ist sehr, sehr unwahrscheinlich, daß optimaler Java-Code schneller als optimaler C++-Code ist. Es ist aber sicher so, daß gerade bei Operationen mit Basistypen in engen Schleifen Java dank JIT usw. nicht wesentlich langsamer ist als C++.
Das Problem ist immer, was man genau mit was vergleicht. Bereits die diversen Visual-C++-Compiler erzeugen beim gleichen Quellcode teils Programme mit massiv unterschiedlicher Performance. Gerade die neueren Visual-C++-Compiler haben nochmal eine teils dramatisch bessere Optimierung.
Wenn man dann einigermaßen optimalen Java-Code mit ungeschickt implementiertem C++-Code auf einem älteren Compiler vergleicht, mag ein Java-Programm sogar schneller sein. Für eine Pauschalaussage ist das aber sicherlich nicht ausreichend.


----------



## helium (4. Dez 2004)

> Vorteile von Java sind unter anderem, das man sich nicht um Speicherfreigaben kümmern muss.


Naja, C++-Programmierer kennen sogenannte Smart-Poitner, mit denen die Speicherfreigabe voll automatisch statfidnet. Außerdem gibt es auch GC-Bibliotheken. Da man den new-Operator überladen kann könnte man sogar per Klasse entscheiden, wie sie am besten handzuhaben ist.
In der Regel wird aber auf den ganzen aufwand verzichtet und einfach Konsequent Smart-Pointer eingesetzt.



> Die unterschiedliche Behandlung von Basistypen und Objekten ist einigermaßen eigentümlich. Speziell bei der Übergabe als als Parameter wird zwar in beiden Fällen "copy by value" benutzt, weil Objekte in Java aber immer Referenzen sind, bekommt man immer eine Referenz auf ein Objekt, aber niemals auf einen Basistyp. Insofern kann man auch nicht ohne weiteres mehr als einen Basistyp zurückgeben, dazu muß man wieder ein Container-Objekt benutzen. Wesentlich schöner wäre eine gleichartige Behandlung von Basistypen/Objekten und die manuelle Auswahl zwischen "by value" und "by reference" gewesen.



Naja, es gibt nunmal wertartige und referenzartige Objekte. Du kannst zwei Autos haben, beide vom selben Modell, selbes Baujahr, selbe Farbe, ... alles gleich und dennoch sind es zwei verschiedene Autos. Das sind eben Identitäs-Objekte, also refernzartige Objekte. Bei anderen Dingen ist das anders. Egal wie oft du die Zahl 3 an verschiedenen Stellen speicherst es ist immer ein und die selbe Zahl 3. Das ist ein wertartiges Objekt. C# gibt einem mit class und struct die Möglichkeit beides perfekt zu modelieren, Java verzichtet darauf, da der größte Teil der in der Softwareentwicklung vorkommenden Objekte referenzartig ist.



> Ich finde es extrem eigenartig, daß es keine unsigned Integertypen gibt. Zudem sind einige der Erweiterungsregeln äußert merkwürdig (byte + byte = int).


Tja, da sieht man mal wieder, was Java alles von C übernommen hat.



> Und was willst du in Java bitte in einen Destruktor schreiben, wenn alles automatisch aufgeräumt wird? Ich hab noch nie einen gebraucht.


Immer wenn du merkst, das du ein finally brauchst, um etwas garantiert aufzuräumen. RAII ist ein tolles konzept, was dem Programmierer viel Arbeit abnimmt und den Code zudem übersichtlicher hält.



> Nunja die fehlende Operatorüberladung kann man positiv und negativ sehen, sinnvoll eingesetzt, ist es sicher gut. Aber: wofür gibt es Object#equals, dass man überschreiben kann? Das macht ja dann auch kein Unterschied mehr zu einem Operator.


Naja, da gibt's immernoch die Möglichkeit, dass das Objekt null ist. Zudem sind Operatoren deutlich übersichtlicher.



> 14) Weil if (und dergleichen) nur boolsche Ausdrücke zuläßt, sind klassische Zuweisungsfehler nicht möglich ( "if (a=3) {}" ).


Ach. Schreib mal in einem D-Programm

```
if (a=3) {}
```
und du wirst einen Fehler erhalten, weil du innerhalb der Bedingung versuchst zuzuweisen. Schreibst du hingegen

```
if (3) {}
```
ist das vollkommen legal, weil integrale Werte als Wahrheitswerte gesehen werden. Es geht also auch anders. Und Java hat immernoch das Problem, das man boolsche Werte zuweisen kann, was in D logischerweise nicht geht.


Ich will Java keinesfalls schelcht machen, aber die Sprache an sich ist doch eher schwach. Dafür hat Java eine erstklassige Bibliothek!


----------



## 0xdeadbeef (6. Dez 2004)

> > Ich finde es extrem eigenartig, daß es keine unsigned Integertypen gibt. Zudem sind einige der Erweiterungsregeln äußert merkwürdig (byte + byte = int).
> 
> 
> Tja, da sieht man mal wieder, was Java alles von C übernommen hat.


Nein das ist in C/C++ definitiv nicht so...



> > 14) Weil if (und dergleichen) nur boolsche Ausdrücke zuläßt, sind klassische Zuweisungsfehler nicht möglich ( "if (a=3) {}" ).
> 
> 
> Ach. Schreib mal in einem D-Programm
> ...


Ich programmiere kein "D". Ich habe von C/C++ gesprochen und da stimmt meine Behauptung. Daß der "Schutz" in Java für boolesche Typen nicht funktioniert, ist auch klar, aber zu 99% vergleicht man ja Zahlenwerte und da tut es.


----------



## helium (6. Dez 2004)

sigend char + sigend char = int

auch wenn du z.B. ein char an eine elipsis-Funktion übergibtst (...) wird daraus ein int.



> Ich programmiere kein "D". Ich habe von C/C++ gesprochen und da stimmt meine Behauptung.


Dagegen habe ich nie etwas gesagt. Ich habe lediglich eine Sprache aufgeführt, die eine dritte Möglichkeit verwendet. 




> Ich weiß nicht viel über C++, aber ich denke das Java (SE) einfacher (und schneller) zu erlernen und handhaben ist, konkret kann ich nicht werden, ist nur so'n Eindruck den ich habe.


Wenn es nur um die Sprache an sich geht, hast du eindeutig recht. Java ist schneller und einfacher erlernbar. Allerdings musst du dich in jeder OO-Sprache mit Dingen wie Design-Pattern, etc. auseinandersetzen.


----------



## 0xdeadbeef (6. Dez 2004)

helium hat gesagt.:
			
		

> sigend char + sigend char = int
> 
> auch wenn du z.B. ein char an eine elipsis-Funktion übergibtst (...) wird daraus ein int.


Das ist richtig, "byte" ist aber unsigned und wird AFAIK in C nicht automatisch erweitert.


----------



## n0n3 (9. Jul 2006)

Mir hat mal jemand gesagt dass Java in C++ programmiert ist ... irgendso ein C++ Fanatiker das stimmt doch nicht oder?  ???:L 
Abgesehen davon meint er dass Java uneffizient sei ... und umständlich ... und ein Pleitegeier ...


----------



## AlArenal (9. Jul 2006)

Die Java VM ist in C/C++ programmiert. Den Rest kommentiere ich nicht, weil das polemisches undifferenziertes Gefasel ist. Das würde zu nichts führen.

In was hattest du denn gedacht, dass die VM entwickelt ist?

Java hat einige sehr interessante Konzepte aus Smalltalk übernommen, andere hat es etwas verwischt, andere ganz beiseite gelassen. Nehmen wir z.B. mal Squeak als Smalltalk-Vertreter, findet man schnell heraus, dass auch die komplette VM in Smalltalk entwickelt ist. Naja, C++ ist ja auch C++ und kein pures Eiffel


----------



## gekkonier (18. Jul 2006)

Hmmm.

Ich will einen Prototypen schreiben.
C++? neeee.....
Java auch nicht.....
Perl? gar nicht so schlecht...
Ruby, Python? ole, das nehm ich.

Ich will einen Textfilter basteln.
C++? blah
Java? bla blah
Perl? nehm ich, da hab ich schon viel dazu gebastelt was ich wiederverwerten kann.

Ich will eine Webapplikation schreiben?
C++? Scherz, oder?
Java? gutti
Perl, Python, Ruby, PHP? auch gutti - je nachdem halt wie umfangreich

Ich will einen Treiber basteln?
C++? pff, ja klar
C auch gutti
java? lol, oder?
Perl, Python & Co.? rofl

Ich will Numbercrunshen?
Fortan? Hui, das nehm ich....
usw. usf.

Hey Leute, die Diskussion ist sowas von obsolet im Endeffekt.
Man nimmt das Werkzeug was dafür geeignet ist und mit dem man umgehen kann und gut ists.

Oder versucht ihr eine Schraube mit nem Hammer ins Holz zu treiben?


----------



## Lim_Dul (18. Jul 2006)

gekkonier hat gesagt.:
			
		

> Hey Leute, die Diskussion ist sowas von obsolet im Endeffekt.
> Man nimmt das Werkzeug was dafür geeignet ist und mit dem man umgehen kann und gut ists.
> 
> Oder versucht ihr eine Schraube mit nem Hammer ins Holz zu treiben?


Wenn das Holz weich ist und die Schraube spitz und kein Gewinde vorhanden ist 

Ernsthaft. Natürlich hast du recht. Dennoch gibt es auf allen Seiten Fanatiker, die um des flames will jemand anders schlecht machen wollen. Das wird sich nie ändern, höchstens die Themen ändern sich.


----------



## justchris (11. Nov 2006)

stevg hat gesagt.:
			
		

> Ich weiß nicht viel über C++, aber ich denke das Java (SE) einfacher (und schneller) zu erlernen und handhaben ist, konkret kann ich nicht werden, ist nur so'n Eindruck den ich habe.  Am besten ist wohl wenn man von beiden mehr als die Syntax beherscht. Und wenn man sich mal die Stellenangebote für 'wenig denkende Codeklopper' (auch 'Fachinformtiker für Anwendungsentwicklung' genannt; mich eingeschlossen  )  anschaut, ist .Net im speziellen C# auch oft gefragt.



Ich bin erstaunt wie schnell C# gewachsen ist, wenn man sich die Stellenangebote so anschaut. Wird wohl auch noch mehr werden jedenfalls unter Windows. Mono hat wohl auch einen großen Schritt nach vorn gemacht und unterstützt wohl nun auch WindowForms. So langsam bin ich dabei auch mal drüber nachzudenken mir das C#/.NET Framework auch mal anzuschauen, denke da werden in Zukunft viele kleine GUI-Apps mit geschrieben.


----------



## Jango (3. Dez 2006)

justchris hat gesagt.:
			
		

> Ich bin erstaunt wie schnell C# gewachsen ist, wenn man sich die Stellenangebote so anschaut. Wird wohl auch noch mehr werden jedenfalls unter Windows. Mono hat wohl auch einen groï¿½en Schritt nach vorn gemacht und unterstï¿½tzt wohl nun auch WindowForms. So langsam bin ich dabei auch mal drï¿½ber nachzudenken mir das C#/.NET Framework auch mal anzuschauen, denke da werden in Zukunft viele kleine GUI-Apps mit geschrieben.



Das kann ich dir nur raten, mal die Nase in die .Net Sprachen zu stecken. Speziell C#. Bin auch gerade am brueten und das Interesse waechst. Wie weiter oben schon gesagt wurde, hat jede Sprache ihre Nische. Und genau das versucht man mit dem .Net Framwork und seinen Sprachen abzuschaffen. Und es sieht vielversprechend aus. Neben der Plattformunabhaengigkeit gibt es auch noch den Vorteil der portabilitaet von einer .Net Sprache zur anderen. Kurz: Ich kann einen mit C# begonnenen Quellcode problemlos mit J# o.a. fortsetzen.
Wer in Java einen guten Durchblick hat, dem kommt vieles bekannt vor. C# lehnt sehr an Java, aber auch an C++. Man kann sagen, dass sich die Entwickler von C# grosse Muehe gegeben haben, beide Sprachen vom Muell zu trennen und zu einer Neuen zusammen zu basteln. Da ich meine ersten Programmierschritte in C/C++ gemacht habe und auch etwas von Java verstehe(etwas=relativ), faellt mir das nicht gar so schwer. Denn - eine gaenzlich neue Sprache ist das nun wieder auch nicht. Man muss sich eben auf eine Zusammenarbeit mit Java und C++ einstellen. Wem das aus irgend welchen philosophischen Gruenden gegen den Strich geht, ist dort fehl. Aber meine Meinung ist, dass man in der Zukunft sehr sehr oft mit den .Net Sprachen in Beruehrung kommen wird - und man will ja auch auf dem neusten Stand sein. 
Mir machts Spass, C# zu lernen, weil eben viel Java bei ist...


----------



## byte (3. Dez 2006)

Jango hat gesagt.:
			
		

> Neben der Plattformunabhaengigkeit gibt es auch noch den Vorteil der portabilitaet von einer .Net Sprache zur anderen. Kurz: Ich kann einen mit C# begonnenen Quellcode problemlos mit J# o.a. fortsetzen.



1. Wo ist .Net plattformunabhängig?
2. Wo liegt genau der Vorteil darin, .Net Anwendungen mit unterschiedlichen Sprachen zu schreiben? Ändert doch herzlich wenig am Endprodukt.


----------



## Roar (4. Dez 2006)

> Ich kann einen mit C# begonnenen Quellcode problemlos mit J# o.a. fortsetzen.
das stimmt auch nicht, lediglich die .NET bibliothek bleibt bei allen .net sprachen vorhanden. wenn ich mit c# anfange und mit j# weitermachen will muss ich trotzdem den ganzen sourcecode von c# und j# umschreiben, weil es schließlich 2 verschiedene sprachen sind, nur darum, dass mir dann weniger funktionalität zur verfügung steht brauch ich mir keine gedankenzu machen.


----------



## SnooP (4. Dez 2006)

Naja allgemein geht's schonn... - wenn man hinreichend kapselt, kann man ein J# Objekt in C# instanzieren, und das ist ja schonmal was 

zu 1: .Net (also genauer die Runtime und vor allem die "Datentypmenge" CLS) ist allgemein spezifiziert und offen, d.h. jeder der will kann eine eigene .Net Runtime/Sprachumgebung erstellen, wie etwa Mono für Linux und einige Unixe. Darüber hinaus gibt es auch die Referenzimplementierung von MS für Mac und NetBSD... also wenn man so will, ist .Net genauso plattformunabhängig, wie Java... es fehlen evtl. die wirklich vernünftigen Runtimes. Außerdem sind bestimmte Bestandteile von .Net dann wieder nicht in der offenen Spezifikation enthalten, wie etwa die ganzen Fenster-Widget-Dinger... also soo offen dann auch wieder nicht 

zu 2.: Das kann ja schonmal ganz nett sein in einem größeren Team, wenn man beispielsweise Frameworks entwickelt... der fitte Anwender eines Finanzframeworks könnte dann mal eben ne kleine nette Erweiterung in VB schreiben, während der Rest in C# geschrieben wurde - ist also flexibler erweiterbar...
Darüber hinaus findet man heute vermutlich sehr häufig unterschiedlichste Produkte geschrieben in unterschiedlichsten Programmiersprachen... um jetzt nicht jedes Mal alles wegschmeißen zu müssen, was da ist, kann man auch mit .Net alle Teile zusammenbacken. Auch schonmal nen Vorteil


----------



## Jango (14. Dez 2006)

@ byto:


> *Plattformunabhängigkeit * Anwendungen, die auf .NET basieren, laufen in einer Umgebung, die mit der virtuellen Maschine von Java verglichen werden kann, in der erst zur Laufzeit einer Anwendung der Maschinencode erzeugt wird. Die Spezifikation der Laufzeitumgebung (Common Language Runtime – CLR) ist keine geheime Verschlusssache von Microsoft, sondern offen festgelegt. In letzter Konsequenz bedeutet das aber auch, dass sich die Common Language Runtime auch auf Plattformen portieren lässt, die nicht Windows heißen, z.B. UNIX oder Linux. Als Beweis kann hier das Projekt Mono genannt werden, mit dem .NET erfolgreich auf die Linux-Plattform portiert worden ist.



@ roar:


> *Sprachunabhängigkeit* Es spielt keine Rolle, in welcher Programmiersprache eine Komponente entwickelt wird. Eine in C# 2005 geschriebene Klasse kann aus VB.NET, J# oder jeder anderen .NET-konformen Sprache heraus aufgerufen werden, ohne den Umweg über eine spezifizierte Schnittstellentechnologie wie COM/COM+ gehen zu müssen. Darüber hinaus lässt sich beispielsweise eine in Visual C# implementierte Klasse auch aus einer VB.NET-Klasse ableiten – oder umgekehrt.


----------



## byte (14. Dez 2006)

jango hat gesagt.:
			
		

> @ byto:
> 
> 
> > *Plattformunabhängigkeit * Anwendungen, die auf .NET basieren, laufen in einer Umgebung, die mit der virtuellen Maschine von Java verglichen werden kann, in der erst zur Laufzeit einer Anwendung der Maschinencode erzeugt wird. Die Spezifikation der Laufzeitumgebung (Common Language Runtime – CLR) ist keine geheime Verschlusssache von Microsoft, sondern offen festgelegt. In letzter Konsequenz bedeutet das aber auch, dass sich die Common Language Runtime auch auf Plattformen portieren lässt, die nicht Windows heißen, z.B. UNIX oder Linux. Als Beweis kann hier das Projekt Mono genannt werden, mit dem .NET erfolgreich auf die Linux-Plattform portiert worden ist.



Schon klar, aber hier ist imo definitiv Theorie != Praxis. Abgesehen von Mono gibt es .NET ausschließlich unter Windows. Und was Mono angeht: da fehlt wie gesagt einiges und im übrigen ist das Projekt umstritten:



> Die Erfolgsaussichten von Mono sind umstritten, da Teile der Klassenbibliothek möglicherweise Softwarepatente der Firma Microsoft berühren.


----------



## Jango (14. Dez 2006)

Das stimmt nun auch wieder - warten wir es einfach ab, was die Zukunft bringt. In solchen Dingen kann man noch nicht mal orakeln...


----------



## byte (14. Dez 2006)

Ich bin da eh offen für vieles. Nur weil ich in Deutschland geboren bin, muss ich ja nicht mein Leben lang nur Deutsch sprechen.


----------



## Jango (14. Dez 2006)

byto hat gesagt.:
			
		

> Ich bin da eh offen für vieles. Nur weil ich in Deutschland geboren bin, muss ich ja nicht mein Leben lang nur Deutsch sprechen.


----------

