welche Vorteile hat Java gegenüber C++?

[c++]

keine?

[Stone2001]

Original geschrieben von c++
keine?
Das würde ich nicht sagen! Der größte Vorteil dürfte die uneingeschränkte Protierbarkeit sein. Der Bytecode dürfte auch jedem Rechner laufen, auf dem eine Virtual Machine läuft.

Will man dagegen C++ Programme auf anderen Plattform zum laufen bringen, braucht man den Sourcecode und muß diesem extra für die Zielplattform übersetzten. Was z.B. zu einem Ding der Unmöglichkeit wird falls, man eine Windows Oberfläche (geschreiben mit der WinAPI) unter Linux zum laufen bringen will.

[c++]

Was z.B. zu einem Ding der Unmöglichkeit wird falls, man eine Windows Oberfläche (geschreiben mit der WinAPI) unter Linux zum laufen bringen will.Dann nimmt man eben gtk oder wxWindows. Bei java geht es ja auch über die Bibliotheken.
und c++ kann man ja auch interpretieren (CINT).

[beta3]

eine mischung aus java und c++ ist c#
laeuft auf alles, wo das .net framework installiert ist und is so funktionell wie c++

[Stone2001]

Original geschrieben von c++
Dann nimmt man eben gtk oder wxWindows. Bei java geht es ja auch über die Bibliotheken.
und c++ kann man ja auch interpretieren (CINT).
OK, wenn man nur Plattformübergreifende Bibliotheken verwendet, ist auch die Portierung nicht weiter schwer. Vorallem seitdem man C++ neuerdings interpretieren lassen kann.
Wie geht das dann vonstatten? In was wird dann mein C++ Programm übersetzt?

Ein weiterer Vorteil für JAVA wäre die relativ geringe Größe des JAVA-Bytecodes. Durch den geringen Speicherplatzbedarf empfiehlt sich JAVA besonders für eingebette Systeme mit begrenztem Speicher.

[Gast]

Original geschrieben von beta3
eine mischung aus java und c++ ist c#
... und is so funktionell wie c++ nein, eben nicht! ist eher wie java

[Gast]

Original geschrieben von Stone2001
Vorallem seitdem man C++ neuerdings interpretieren lassen kann.
Wie geht das dann vonstatten? In was wird dann mein C++ Programm übersetzt?auch in zwischencode. kenne aber keine anwendung wo c++ interpretiert wird. wozu auch,w enn es einen compiler gibt? höchstens zur laufzeit: skriptsprache

[beta3]

Original geschrieben von Gast
nein, eben nicht! ist eher wie java
ich hab jedenfalls das andere gehoert

[Gast]

;) ;) ;)

[ethrandil]

Okay, hallo hier komme ich :)

Die Java Syntax ist meiner Meinung nach übersichtlicher und auch einfacher (keine pointer-herumquälereien)
Java ist eine Sprache mit der man optische Website-komponenten schreiben kann (geht wohl auch mit activeX, aber naja)
Java ist im Web als solche ^^ Sicherer danke Sandbox
Java ist komplett objektorientiert, wo man bei c++ noch mit globalen variablen herumfuchsiert
Java hat eine klar definierte API und eine große ausswahl an Standardkomponenten.
AWT und SWING sind modern mit Objektorienterter - Event-Listener basierter API ausgestattet
Java hat machtvolle APIS für Web-Server-basierte Anwendungen (EJB).

Okay, aber:
C++ ist schneller, vorallem bei Windows-GUIs. Und natürlich auch bei reinen Rechen-Sachen.
Ich für meinen teil liebe Java aber für die einfache Grafikdarstellung (wenn ise auch recht lahm ist). In c++ hast du nicht mit 9 zeilen ein Fenster :)


Wenn man das ganze aber einsetig betrachtet hat es keinen Vorteil. Aber man muss Java nicht neu kompilieren. C++ ja. (und welcher pure-desktop-anwender tut das??)

[HellHorse]

javadoc ;)

[grakaman]

Wenn der Java JITer dem vom .NET Framework so unendlich überlegen sein soll (was ja viele behaupten), dann frage ich mich allerdings warum er jedes mal für die Ausführung von Java Anwendungen genau so lange benötigt. Zumindest habe ich einmal die Programme beim WebStarter Kit ausprobiert (Notepad ...) und der Start sowie die Ausführung war immer gleich schnell/langsam. Das kommt daher, dass der Bytecode bei jeder Ausführung des Programms neu gejittet wird. Bei Java Application-Servern mag das wohl anders sein, dort wird irgendwie das Compilat gecached, was aber selbst mit dem JITer wohl nichts zu tun haben mag. Beim .NET Framework kompiliert die CLR aber nur einmal den Zwischencode (außer jemand macht einen Neustart). Es ist sogar möglich schon beim Deployment die MSIL zu kompilieren. Auch wenn ich Java nicht kenne, so ist dort meiner Meinung nach ein großer Nachteil, dass es keine einheitliche Framework-Bibliothek gibt (außer der Referenzimplementierung von Sun). Jeder kann sein Framework basteln und es gibt für ein und die selbe Aufgabe die unterschiedlichsten Pakete, weil eben nicht alles von vornherein wohl abgedeckt wird.

MfG

[ethrandil]

Original geschrieben von grakaman
Jeder kann sein Framework basteln und es gibt für ein und die selbe Aufgabe die unterschiedlichsten Pakete, weil eben nicht alles von vornherein wohl abgedeckt wird.
Kommt da nun ganz drauf an, was du meinst :)
Verschiedene Frameworks: Japp, JSP (Struts), ...
gerne, her damit! Wenn sich die Frameworks unterscheiden, dann habe ich gerne die Wahl.

Wenn es jetzt aber um so dinge wi Matrizen &/ Vektoreen geht, da hab ich mir wirklich eigene Klassen geschrieben. Gibt es dafür ein Paket? Und in c# / C++?

[grakaman]

Original geschrieben von ethrandil
Kommt da nun ganz drauf an, was du meinst :)
Verschiedene Frameworks: Japp, JSP (Struts), ...
gerne, her damit! Wenn sich die Frameworks unterscheiden, dann habe ich gerne die Wahl.


Wenn ich z.B. bei .NET eine n Tier Webapplication programmiere, dann habe ich i.d.R.:

- Presentation Tier: Webform + Codebehind
- Business Tier: Remote Objekte (.NET Remoting/WebServices)
- Data Tier: Datenbank

Bei Java hab ich das freilich auch, aber die unterschiedlichsten Ansätze zur Implementierung der Infrastruktur. Vielleicht erzähle ich jetzt auch totalen Unsinn, habe das aber eben so verstanden. Das Bsp. Struts müsste nun so etwas sein wie ASP.NET's Webforms. In der Webform steht der Markup bzw. die Tags der .NET Controls (z.B. WebControls) und in der Codebehind die Logik zur ansteuerung der Controls. Nun gibts aber meiner Meinung nach bei Java noch viel mehr Alternativen als Struts (Qualität sei mal egal). Wenn ich Jahre lang mit Struts gearbeitet hätte und plötzlich irgend etwas anderes vorgesetzt bekomme, so würde ich das für ziemlich blöd empfinden. Es gibt eben keine festen Standards/Richtlinien und jeder gibt sein Käse dazu.


Wenn es jetzt aber um so dinge wi Matrizen &/ Vektoreen geht, da hab ich mir wirklich eigene Klassen geschrieben. Gibt es dafür ein Paket? Und in c# / C++?


Ich kenne mich mit Transformationen bei Grafikprogrammierung nicht sonderlich aus (nur etwas GDI+), aber ja, so eine Klassen gibt es (System.Drawing.Drawing2D.Matrix).

MfG

[ethrandil]

Ja, *jubel* für Java flamen *schwärm*
Original geschrieben von grakaman Nun gibts aber meiner Meinung nach bei Java noch viel mehr Alternativen als Struts (Qualität sei mal egal). Wenn ich Jahre lang mit Struts gearbeitet hätte und plötzlich irgend etwas anderes vorgesetzt bekomme, so würde ich das für ziemlich blöd empfinden. Es gibt eben keine festen Standards/Richtlinien und jeder gibt sein Käse dazu.
Java:
JSP + Struts
JavaEnterpriseBeans
JDBC - Datenbank / Objectrelated-Databasemapping (*gg*)

Und: Klar, es gibt noch mehr :)
Ich empfinde es als Vorteil nicht auf eine Methode angewiesen zu sein! Als Java-Programmierer gewöhnt man sich so auch nicht zu schnell an vorhandene Systeme, und verfällt nicht so einfach in geradeausdenkerei. (nicht das c#-Leute das täten)

Allerdings gibt es doch einige Standards. JSP z.B. ist ein Solcher. JSP definiert eine aus Tags aufgebaute Darstellungssprache, gedacht um Programmieren von Designen zu trennen. Dabei gibt es sogenannte 'Custom-Tags', die Sich dann z.b. Vom Designer einbauen lassen, etc.etc... Struts ist eine Sammlung von solchen Custom-Tags :)
Es gibt noch weitere Frameworks mit denen hab ich mich aber nicht näher beschäftigt (mit Struts auch net).
Aber wenn du nen schicken Standart willst, gerne: http://java.sun.com/j2ee/docs.html
Viel spass beim lesen ;-)

[Gast]

Original geschrieben von ethrandil
1. Die Java Syntax ist meiner Meinung nach übersichtlicher 2. und auch einfacher (keine pointer-herumquälereien)
3. Java ist eine Sprache mit der man optische Website-komponenten schreiben kann (geht wohl auch mit activeX, aber naja)
Java ist im Web als solche ^^ Sicherer danke Sandbox
4 Java ist komplett objektorientiert,
5. wo man bei c++ noch mit globalen variablen herumfuchsiert
6. Java hat eine klar definierte API und eine große ausswahl an Standardkomponenten.
3. AWT und SWING sind modern mit Objektorienterter - Event-Listener basierter API ausgestattet
3. Java hat machtvolle APIS für Web-Server-basierte Anwendungen (EJB).
7.In c++ hast du nicht mit 9 zeilen ein Fenster :)
8. Aber man muss Java nicht neu kompilieren. C++ ja. (und welcher pure-desktop-anwender tut das??) 1. warum?
2. kein problem, kannst auch referenzen nehmen
3. mit c++ auch, braucht man eben bibliotheken. gibt es ja genug.
4. warum vorteil? in c++ kann man auch komplett OO proggen, man ist aber nicht gezwungen
5. falsch, muss man nicht
6. c++ auch
7. mit passenden bibliotheken schon
8. z.b. linuxer

[HellHorse]

@ethrandil
Mir scheint auch grakaman beschwert sich über Wahlfreiheit.
Bei EJB bist du realtiv frei, womit du den Präsenations tier machen willst, muss nicht einmal Java sein. Was ist daran schlecht?

[zeckensack]

Original geschrieben von grakaman
Wenn ich Jahre lang mit Struts gearbeitet hätte und plötzlich irgend etwas anderes vorgesetzt bekomme, so würde ich das für ziemlich blöd empfinden. Es gibt eben keine festen Standards/Richtlinien und jeder gibt sein Käse dazu.Das ist auch gut so. Das nennt man Wettbewerb, und btw, C# erlaubt das auch.
Daß du dich lieber auf Microsoft "Standards" verlassen willst, denn auf "jedermanns Käse" ist mir auch schleierhaft. Historisch betrachtet gibt es keinen größeren Käseproduzenten-und-dann-Support-Einsteller als MS.
Und zur Definition von "Standard" gehört IMO auch deutlich mehr als "wurde von MS geschrieben".

[ethrandil]

Original geschrieben von Gast
1. warum?
2. kein problem, kannst auch referenzen nehmen
3. mit c++ auch, braucht man eben bibliotheken. gibt es ja genug.
4. warum vorteil? in c++ kann man auch komplett OO proggen, man ist aber nicht gezwungen
5. falsch, muss man nicht
6. c++ auch
7. mit passenden bibliotheken schon
8. z.b. linuxer
1. Die Java Syntax ist meiner Meinung nach übersichtlicher, weil sie nur den .-Operator kennt und kein . :: -> (*xx)-> ... Aber das kann Geschmackssache sein
4. Java ist komplett objektorientiert, man kann nicht einfach mal eben ein Progg. hinkladden :) (geht schon, schwierig).
Basiert vielleicht auch auf meiner Progger-Anfangszeit: Ich habe in einem 1k-Seiten-C++-Grundlagenbuch viel überklassen gelesen und war einfach nur platt :) Nach einem Java-cookbook sah das ganz anders aus ....
5. wo man bei c++ noch mit globalen variablen herumfuchsiert muss man nicht... Die Bemerkung war auch rhetorisch, aber da ist Java anders: Man ist eingeschränkt auf Objektorientierung und Modellbildung (weniger bei der Web-Darstellung).
6. Java hat eine klar definierte API und eine große ausswahl an Standardkomponenten, c++ auch, aber finde da mal ne gelungene Übersicht wie http://java.sun.com/j2se/1.4.1/docs/api/ ...
7.In c++ hast du nicht mit 9 zeilen ein Fenster, und wenn doch, dann will ich wissen wie und womit :) Jedenfalls nicht mit nem winapi. ( new Frame("hiho").show(); )
8. Aber man muss Java nicht neu kompilieren. C++ ja. (und welcher pure-desktop-anwender tut das??) Linuxanwender sind meist keine Pure-Desktopanwender. Und außerdem kompiliert der durchschnittliche Suse-Mensch nix neu ... (gibt ja rpm...)
:)

EDIT: Es gibt einen großen Nachteil von Java! Es gibt nichts template-ähnliches (wie hieß das nochmal?) !! Gibts das in c#?

[HellHorse]

Original geschrieben von ethrandil
....
EDIT: Es gibt einen großen Nachteil von Java! Es gibt nichts template-ähnliches (wie hieß das nochmal?) !! Gibts das in c#?
generics?
Kommt mit Java 1.5. Fuer alle Ungeduldigen gibt's schon zwei ea-compiler und passende compiler adapter fuer ant.
Was wirklich nervt an Java ist, dass Sun es zu Beginn nicht richtig hingeriegt hat und wir wegen Marketingversperchungen jetzt mit den Folgen leben muessen. Siehe java.util.Vector, java.awt.Polygon, java.util.Date,...
Zudem ignoriert das Swing-Team konsequent die Existenz des Collection Framework.
Java ist nicht komplett ojektorientiert. Denn es gibt primitives die keine Objekte sind (char, int, long, double,...) und Klassen sind auch keine Objekte.

[Dr.Doom]

Original geschrieben von HellHorse
und Klassen sind auch keine Objekte.
Öhm, naja, irgendwie müssen die Eigenschaften von Objekten auch mal definiert werden. ;)

Ausserdem sehe ich an "komplett objektorientiert" nichts falsches, da steht ja nicht "komplett objektbasiert". :D

[grakaman]

Original geschrieben von HellHorse
Java ist nicht komplett ojektorientiert. Denn es gibt primitives die keine Objekte sind (char, int, long, double,...) und Klassen sind auch keine Objekte.

wäre ja auch schön blöd, wenn Primitives auf dem Heap liegen würden. Imho heißt Objekt auch nicht zwangsweise, dass die Instanz auf dem Heap liegen "muss", sondern dass es sich um einen komplexen Typ handelt. Benutzerdefinierte Klassen sollten aber in Java auch immer auf dem Heap instanziert werden und sind somit Objekte oder was meintest du???

MfG

[Gast]

Versuche mal von einem int eine eigene Klasse abzuleiten. Geht nicht? Deswegen sind es keine "Objekte". Falls man das wirklich so sagt.

In C++ (und Java?) sind Klassen keine Objekte im Speicher, denn sie existieren nur im Quelltext. Es gibt aber Sprachen wo man eine Klasse erst zur Laufzeit zusammenbaut, und diese Klasse ist dann ein Objekt im Speicher. Es geht hier nur um die Klasse und nicht deren Instanzen.

[grakaman]

Original geschrieben von Gast
Versuche mal von einem int eine eigene Klasse abzuleiten. Geht nicht? Deswegen sind es keine "Objekte". Falls man das wirklich so sagt.

In C++ (und Java?) sind Klassen keine Objekte im Speicher, denn sie existieren nur im Quelltext. Es gibt aber Sprachen wo man eine Klasse erst zur Laufzeit zusammenbaut, und diese Klasse ist dann ein Objekt im Speicher. Es geht hier nur um die Klasse und nicht deren Instanzen.

Objekte sind die Instanzen von Klassen und diese sind "für gewöhnlich" bei Java/C# auf dem Heap. Bei Primitives macht es aber aus Performancegründen keinen Sinn, diese auf dem Heap zu speichern. Deswegen sorgt der Compiler bei diesen eingebauten Typen automatisch dafür, dass sie auf dem Stack landen. Bei C++ kannst du ja auch Objekte auf dem Stack speichern. Bei C# kannst du nicht von int ableiten, weil die Klasse sealed ist (wird bei Java auch nicht anders sein).

MfG

[HellHorse]

Ok, primitives (int, long, ...) sind keine Objekte, da es keine Instanzen einer Klasse sind. Dass sieht man ganz einfach daran, dass man die Dinger nicht in eine Collection packen kann, sondern zuerst wrappen muss. Holt man sie dann aus und will irgendwelche mathematischen operationen damit machen, muss man sie wieder unwrappen.

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#11128

The types of the Java programming language are divided into two categories: primitive types and reference types. The primitive types (§4.2) are the boolean type and the numeric types. The numeric types are the integral types byte, short, int, long, and char, and the floating-point types float and double. The reference types (§4.3) are class types, interface types, and array types. There is also a special null type. An object (§4.3.1) is a dynamically created instance of a class type or a dynamically created array. The values of a reference type are references to objects. All objects, including arrays, support the methods of class Object (§4.3.2). String literals are represented by String objects (§4.3.3).

[grakaman]

Original geschrieben von HellHorse
Ok, primitives (int, long, ...) sind keine Objekte, da es keine Instanzen einer Klasse sind. Dass sieht man ganz einfach daran, dass man die Dinger nicht in eine Collection packen kann, sondern zuerst wrappen muss. Holt man sie dann aus und will irgendwelche mathematischen operationen damit machen, muss man sie wieder unwrappen.

http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#11128

Im .NET Framework sind Primitives aber ebenfalls Objekte, da ein Int z.B. die Klasse System.Int32 represäntiert. Es handelt sich schon deshalb um Objekte, weil alles von der Klasse System.Object abgeleitet ist. Und int's sind in .NET freilich auch Instanzen, auch wenn man sie der Korrektheit nicht so nennt, sondern Werte. Und in Collections, z.B. ArrayList, kann ich int's auch ohne Probleme packen, da sie automatisch den Boxing vorgang durchlaufen. Das sollte ja bei Java auch nicht groß anders sein.

MfG

[HellHorse]

Original geschrieben von grakaman
Im .NET Framework sind Primitives aber ebenfalls Objekte, da ein Int z.B. die Klasse System.Int32 represäntiert. Es handelt sich schon deshalb um Objekte, weil alles von der Klasse System.Object abgeleitet ist. Und int's sind in .NET freilich auch Instanzen, auch wenn man sie der Korrektheit nicht so nennt, sondern Werte. Und in Collections, z.B. ArrayList, kann ich int's auch ohne Probleme packen, da sie automatisch den Boxing vorgang durchlaufen. Das sollte ja bei Java auch nicht groß anders sein.

MfG
Java hat (noch) kein autoboxing (ja, auch dass kommt mit 1.5 und auch das geht schon mit dem ea-compiler).
Sorry für die Verwirrung, ich sprach nur von Java.

[Gast]

@Grakaman

Ein Objekt ist "für mich" einfach ein Datum was im Speicher liegt. Das kann vom Datentyp struct, pointer oder sonstwas sein. Völlig egal. Siehe unten für die richtige Definition(en).


Objektorientiert bedeutet nicht, das Objekte irgendwas neu erfundenes sind. Genauso wie es Funktionen auch in nicht-funktionalen Sprachen gibt, diese aber dort nicht so eine zentrale Bedeutung haben.

Auch in C++ gibt es Klassen wie Integer in Klassenbibliotheken. Die eingebauten Typen int/double/... sind aber Typen die vom Compiler gesondert behandelt werden und auch nicht mit der selben Programmiersprache implementiert sein müssen. So sind eingebaute Datentypen in vielen Sprachen z.B. in C programmiert im Unterschied zu den Klassen-Typen, welche in der jeweiligen Sprache vorliegen.

Ich möchte darüber nicht weiterdiskutieren, weil solche Sachen für einen Programmierer meiner Überzeugung nach unwichtig sind, und eher Designer von Sprachen betreffen. Ich programmiere so, wie es die jeweilige Sprache erfordert (für C# gibts ja z.B. Richtlinien, wie man GC-freundlich programmiert) und damit bin ich voll ausgelastet.


"Louis Noser" <louis.noser@freesurf.ch> writes:

> Die Programmierer-Gemeinde spricht gerne von 'Objekten'. Hat jemand eine
> Definition davon?

Sogar mehrere:

| [#1] object
| region of data storage in the execution environment, the
| contents of which can represent values
|
| [#2] NOTE When referenced, an object may be interpreted as
| having a particular type; see 6.3.2.1.

(ISO/IEC 9899:1999, 3.14)

| 1. Objects are created at run time and contain a value of a given
| type. An object can be created and initialized as part of
| elaborating a declaration, evaluating an allocator, aggregate, or
| function_call, or passing a parameter by copy.
| 2. All of the following are objects:
|
| 3. the entity declared by an object_declaration;
|
| 4. a formal parameter of a subprogram, entry, or generic
| subprogram;
|
| 5. a generic formal object;
|
| 6. a loop parameter;
|
| 7. a choice parameter of an exception_handler;
|
| 8. an entry index of an entry_body;
|
| 9. the result of dereferencing an access-to-object value, see
| *Note 4.1::,
|
| 10. the result of evaluating a function_call (or the equivalent
| operator invocation - see *Note 6.6::,
|
| 11. the result of evaluating an aggregate;
|
| 12. a component, slice, or view conversion of another object.

(ISO/IEC 8652:1995)

[grakaman]

Original geschrieben von Gast
@Grakaman

Ein Objekt ist "für mich" einfach ein Datum was im Speicher liegt. Das kann vom Datentyp struct, pointer oder sonstwas sein. Völlig egal. Siehe unten für die richtige Definition(en).


Objekt Orientiert Programmieren beschreibt aber hauptsächlich auch die Beziehung von Objekten untereinander, also Vererbung, Schnittstellen, Überschreiben etc. Und ein Pointer ist kein Objekt, er kann höchstens auf eins zeigen. Structs sind in C# ebenfalls Klassen, die aber landen auch auf dem Stack und werden, wie alle wichtigen builtin Typen, über einen eigenen Alias angesprochen. Dadurch könnte man denken, es wären keine Klassen, sie sind es aber doch. In richtigen OO Sprachen wie C# oder Java basiert eben alles auf Klassen.



Objektorientiert bedeutet nicht, das Objekte irgendwas neu erfundenes sind. Genauso wie es Funktionen auch in nicht-funktionalen Sprachen gibt, diese aber dort nicht so eine zentrale Bedeutung haben.


Doch, im Vergleich zu prozeduraler Programmierung schon.
Mag sein, dass C++ nicht ganz rein OO ist in der Beziehung.


Ich hab auch mal nach einer Definition gesucht :)
http://www.galileocomputing.de/glossar/gp/anzeige-8974

MfG

[HellHorse]

Original geschrieben von grakaman
....
In richtigen OO Sprachen wie C# oder Java basiert eben alles auf Klassen.
....

Tun die primitiven Typen in Java eben nicht, wie aus der JLS ja hervorgeht. Folglich sind es keine Objekte.
Auf welchen Klassen sollen den int's deiner Meinung nach beruhen (in Java)? java.lang.Integer? :D
Falls es doch Objekte sind, wie kommt es dann, dass man auf sie nicht einmal die Methoden von java.lang.Object, von der alle Klassen erben, ausführen kann?

[grakaman]

Original geschrieben von HellHorse
Tun die primitiven Typen in Java eben nicht, wie aus der JLS ja hervorgeht. Folglich sind es keine Objekte.
Auf welchen Klassen sollen den int's deiner Meinung nach beruhen (in Java)? java.lang.Integer? :D
Falls es doch Objekte sind, wie kommt es dann, dass man auf sie nicht einmal die Methoden von java.lang.Object, von der alle Klassen erben, ausführen kann?

Ich habe mal wieder vorschnell von C# auf Java geschlossen, weil ja alle Welt behauptet, diese wären fast gleich (ich kann kein Java). Dann ist das eben in Java nicht so, aber in C# :D

MfG