vorteile von c++ gegenüber von java

[volkard]

Ethon schrieb:

Java ist in der Industrie recht beliebt da man den Zeit-/Personenaufwand recht gut einschätzen kann.

Das ist ja wie bei den Schrauben und Nieten! Abgesehen davon, daß man Schraubenverbindungen gut lösen kann. Aber mal Fälle angenommen, wo man das gar nicht will, eine Brücke zum Bleistift. Der Niet ist natürlich kostengünstiger, eleganter, performanter und überhaupt. Und dennoch wurde er von den Schrauben verdrängt! Und warum? Nur, weil man Nieten nicht abschätzen kann. Die Qualität der Vebindung hängt viel zu stark von den Fertigkeiten des Niethammerschwingers ab. Aber mit dem Einzug motorischer Niehämmer sehe ich eine ganz große Rennesaince der Nietverbindungen vor uns.

[SeppJ]

Ethon schrieb:

Gibts nicht noch einen C++-to-C Compiler? Dann würde es überall laufen.
Eigentlich schade dass zb der GCC soetwas nicht anbietet ...

Wenn du einen C-Compiler hast, dann hast du auch einen C++-Compiler, denn du kannst den C++-Compiler mit dem C-Compiler bauen.

[Gast]

java_oder_c++ schrieb:

Steffo schrieb:

“Ich würde Klassen [-Vererbung] weglassen.” - James Gosling, Principal Scientist bei Sun Microsystems, 2001 auf die Frage, was er anders machen würde, wenn er Java noch einmal zu entwerfen hätte.

ist vererbung nich eine grundlage des objektorientierten paradigmas?

Wenn du gedankenlos Veerbung einsetzt, wirst du im Laufe des Projektes gegenseitige Abhängigkeiten haben, die den Gesamtüberblick und die Wartung erschweren (außerdem kommt noch Redundanz hinzu, d. h. in Subtypen werden Dinge gemacht, die schlicht unnötig sind).
Wenn du z. B. Klassen hast, die auf folgende Weise erben: D-->C-->B-->A, kannst du dir sicherlich vorstellen, dass bei einem D-Objekt jede Menge unnötige Sachen ausgeführt werden und möglicherweise auch Dinge, die die Datenintegrität gefährden, weil sich Code von den Oberklassen und Code von D gegenseitig in die Quere kommen.
Ich würde nicht soweit gehen und Veerbung komplett verbieten, aber Klassen müssen ausdrücklich für Vererbung entworfen sein, d. h. man muss sich gründlich Gedanken machen, wie man eine Oberklasse aufbaut. Klassen, die nicht für Vererbung konzipiert wurden, sollten man in Java grundsätzlich mit final implementieren - damit verbietet man die Vererbung bei der jeweiligen Klasse. Ein gutes Beispiel für einen gelungenen Vererbungsentwurf, ist die toString-Methode in Java. Bei equals wirds schon kritischer. Weshalb? Weil equals standardmäßig erst mal nur die Identität zweier Objekte vergleicht (a == b). Das musst du als Programmierer wissen! Wenn du dann allerdings die equals-Methode überschreibst, solltest du dann auch die hashCode-Methode überschreiben, weil equals diese Methode benutzt (wertgleiche Objekte sollten gleiche HashCodes haben), dessen Implementierung bei verschiedenen Klassen evtl. anders aussieht. Würde man equals nicht immer automatisch miterben, dann könnte erst gar nicht die Illusion entstehen, dass die equals-Methode automatisch zwei Objekte auf Wertgleichheit prüft, weil man die equals-Methode z. B. über einen Interface einbinden und selbst implementieren müsste.

Was sind also die Alternativen zur Vererbung? Composition und Interfaces!

Liebe Grüße
Steffo

[krümelkacker]

zu mir: Ich habe, bevor ich C++ lernte, 7 Jahre hauptsächlich nur Java programmiert. Jetzt im Moment verwende ich hauptsächlich C++ und auch ein bisschen Matlab.

java_oder_c++ schrieb:

java:
-plattformunabhängig(er)

Das muss man differenzieren. Der Ansatz bei Java ist "compile once, run everywhere", wobei natürlich eine lauffähige VM vorhanden sein muss. Diese lauffähige VM ist aber (typischerweise) in C++ geschrieben. Und ich denke nicht, dass die Hersteller für jedes Betriebssystem und für jede Architektur eine komplett neue VM bauen. Die meisten Teile der VM werden schon Maschinen- und Betriebssystem-neutral geschrieben sein. Wenn man sich an das hält, was der C++ Standard sagt und nur "portable Bibliotheken" verwendet, kann man in C++ Programme erzeugen, die sich nahezu überall kompilieren lassen, also "compile everywhere". Was sagt Dir das bzgl Plattformunabhängigkeit? Böse Zungen behaupten sogar, dass Java nur auf einer Plattform läuft: auf einer virtual machine.

java_oder_c++ schrieb:

-liefert mehr basisfunktionen mit(threads, erweiterte for-schleife, sockets, uvm.)

Das stimmt. Die C++ Standardbibliothek fällt recht mager aus. So richtig schlecht finde ich das jetzt aber auch nicht. Die wichtigsten Dinge werden immerhin nachgebessert. C++2011 hat z.B. brauchbare threading-Funktionalitäten. Sonst wird man oft noch bei Boost, Qt und Poco fündig.

java_oder_c++ schrieb:

c++
-hat pointer (braucht man die/ kann man die nicht umgehen)

Java hat die auch. Die nennen das nur "Referenzen" und alle Variablen eines "Klassentyps" sind automatisch Referenzen, ohne dass man dies extra kennzeichnen müsste wie z.B. in C++ mit dem Stern.

java_oder_c++ schrieb:

-hat mehrfachvererbung (mir fällt kein sinnvolles beispiel ein)

Musst Du ja nicht nutzen. Ich tu's auch recht selten. Und wenn, dann ist das meistens vergleichbar mit Java Interfaces.

java_oder_c++ schrieb:

-ist schneller( habe diesen verleich gefunden:"ein gutes c++-program ist doppelt so schnell wie ein extrem gutes java-program, wenn beide programme das selbe machen".

Ich habe da neulich von einem Trade-Off gelesen. Man kann theoretisch einen Garbage-Collector so tunen, dass er auf Kosten der Geschwindigkeit relativ speichersparend arbeitet. Andersherum kann man den GC auf Geschwindigkeit optimieren, und muss in Kauf nehmen, dass der GC nicht sofort den Müll einsammelt, sondern etwas wartet und nur ein bisschen aufräumt hier und da. Ich finde, das leuchtet auch irgendwie ein. Und sonst gibt es viele Dinge, die in C++ undefiniertes Verhalten hervorrufen (und daher keine Laufzeitchecks oder extra Metadaten benötigen) wohingegen Java ein Verhalten definiert und typischerweise dadurch bremst (NullPointerException, ArrayIndexOutOfBoundsException, etc). Auch wird man in Java gezwungen, Objekte im Freispeicher anzulegen. Man kann nichtmal die "besteht-aus"-Beziehung zwischen Objekten richtig abbilden, da Du in Java neben int, double, etc nur Referenzen als Datenelement in einer Klasse verwenden kannst. Das hat den Nachteil, dass man keinen großen Einfluss auf das Speicherlayout hat, was heutzutage wichtiger ist als früher, wenn es um Performanz geht (effektive Nutzung des Speichercaches).

java_oder_c++ schrieb:

habe aber auch die aussage gefunden, dass c++ und javaprogramme inzwischen gleich schnell seien)

Solche Programme gibt es vielleicht. Aber (a) machen die dann auch etwas nützliches? und (b) sind sie repräsentativ?

java_oder_c++ schrieb:

-braucht weniger speicher/leistung/verwaltungsarbeit, da keine javavm laufen muss. (merkt man das heute noch, oder müsste man, um das zu merken, dafür sehr guten code schreiben?)

Das kommt ganz auf die Anwendung drauf an. Wenn Du Dir den Laufzeit/Speicher-Overhead erlauben kannst, kannst Du natürlich Java verwenden.

java_oder_c++ schrieb:

meine fragen neben den in klammern stehenden sind:
-was kann ich mit c++ machen, das ich nicht, oder nur wesentlich schlechter, mit java machen kann?

Alles, wo es auf Performanz (hohe Geschwindigkeit, niedriger Speicherverbrauch) ankommt.

Cheers!
kk

[Burkhi]

java_oder_c++ schrieb:

...

kann mir bitte jemand schreiben, was zeichen für einen sauberen code sind bzw was man dafür beachten muss.

Zeichen für eine sauberen Programm- Code ist leichte Wartbarkeit, d.h. die Funktion des Programms sollte direkt aus dem Code ersichtlich sein. Dazu gehört eine saubere Kommentierung und aussagekräftige Namen.

Wenn man nach Jahren wieder mal in seinen Programmcode reinschaut und dann nix mehr kapiert, was man damals gemacht hat, dann hat man nicht sehr sauber programmiert.

Idealerweise ist das Programm so geschrieben, dass auch andere sehr schnell da durchsteigen, aber das ist m.E. nicht ganz so easy zu erreichen, da jeder einen eigenen Programmierstil hat, hier helfen aber Designvorgaben, an die sich dann jeder zu halten hat (was in der Praxis aber nicht unbedingt jeder macht).

Auch ist es wichtig, das das Programm stabil läuft, also nicht alle x Stunden, Tage oder Monate einfach mal aussteigt.

Und: Es ist auch in Java möglich, Speicherfresser zu programmieren, wenn das Design unsauber ist.

[krümelkacker]

Burkhi schrieb:

Und: Es ist auch in Java möglich, Speicherfresser zu programmieren, wenn das Design unsauber ist.

Ich schätze Du meinst hier C++. Aber ich denke, die Aussage versteht sich von selbst. Man kann sich in jeder Sprache "ungeschickt ausdrücken".

[Burkhi]

krümelkacker schrieb:

Burkhi schrieb:

Und: Es ist auch in Java möglich, Speicherfresser zu programmieren, wenn das Design unsauber ist.

Ich schätze Du meinst hier C++. Aber ich denke, die Aussage versteht sich von selbst. Man kann sich in jeder Sprache "ungeschickt ausdrücken".

Nein, ich habe Java gemeint.

[*rant*]

Mein Senf:

Java ist inkonsistent, hat aber den Anspruch, sauber zu sein. Alles ist objektorientiert, aber die Primitivtypen zeigen ein vollkommen anderes Verhalten. Packaging ist eine Katastrophe, genau wie die Bindung von public class an ein File. Wieviele Files müssen es denn sein? Haben hier ein kleines Projektchen, das hat schon bald 50 Files! Reflection in Java ist unbrauchbar, sobald Generics zum Einsatz kommen. Die Generics selbst sind ebenfalls komplett unbrauchbar; dann schon lieber wie in C#, wo man sie noch vernünftig benutzen kann.

Die JVMs mit ihrem compile-once, run-everywhere Argument ziehen nicht, denn die JVMs haben überall ihre kleinen Unterschiede. Oops, die Garbage Collection funktioniert auf diesem System anders. Oops, die Garbage Collection funktioniert in diesem Zusammenhang nicht richtig. Schon mal wirklich tief mit Threads und Monitoring programmiert? Nein? Dann los, probieren. Dies schliesst natürlich auch andere Bereiche der umfangreichen Library mit ein, die sich auf jeder Platform ein wenig anders verhält. Im Übrigen sind weite Teile der Class Library Symbole für Overengineering par excellence.

Zum Thema Performance: Sobald ernsthaft Berechnungen durchgeführt werden müssen, kann man Java vergessen. Nein, ich rede nicht von der Fläche eines Kreises oder von 1000 Kreisen, ich rede von ernsthafter Numerik. Wir haben im Studium schon mal diese Erfahrung machen müssen.

Ach, und noch ein sehr grosser Nachteil von Java: Oracle.

[Dravere]

@rant,
Und ich hätte jetzt gedacht, dass du noch Checked Exceptions als riesen Nachteil erwähnst

Grüssli

[*rant*]

Dravere schrieb:

@rant,
Und ich hätte jetzt gedacht, dass du noch Checked Exceptions als riesen Nachteil erwähnst

Grüssli

Oops, ganz vergessen! Danke: CHECKED EXCEPTIONS *kotz*

[roflalter]

/rant/ schrieb:

Packaging ist eine Katastrophe, genau wie die Bindung von public class an ein File. Wieviele Files müssen es denn sein? Haben hier ein kleines Projektchen, das hat schon bald 50 Files!

wenn du dich schon unqualifiziert auskotzt, dann halte dich an die fakten. das ist zumindest großer käse. du kannst mehr als eine klasse in eine datei schreiben. die frage ist nur, warum sollte man das tun?

hast du mehr projektüberblick, wenn du das projekt aus weniger dateien besteht? lol

[this-*gt*that]

Erst 5 Seiten?

Forum, I am disappoint

[Gast]

roflalter schrieb:

/rant/ schrieb:

Packaging ist eine Katastrophe, genau wie die Bindung von public class an ein File. Wieviele Files müssen es denn sein? Haben hier ein kleines Projektchen, das hat schon bald 50 Files!

wenn du dich schon unqualifiziert auskotzt, dann halte dich an die fakten. das ist zumindest großer käse. du kannst mehr als eine klasse in eine datei schreiben. die frage ist nur, warum sollte man das tun?

hast du mehr projektüberblick, wenn du das projekt aus weniger dateien besteht? lol

Wer lesen kann, ist klar im Vorteil. Er hat von public Klassen gesprochen und da hat er vollkommen Recht: Public Klassen müssen in eine seperate Datei, was ich persönlich nicht schlimm finde...

[wxSkip]

Ich habe nicht so viel Erfahrung mit Java, möchte aber auch mal meinen Senf dazugeben:

Ich sehe Templates als (den vielleicht größten) Vorteil für C++ gegenüber Generics. Ich habe erst neulich etwas über Generics gelesen und muss sagen, dass Type Erasure doch eine deutliche Beschränkung ist und man, wenn man sich auskennt, mit Templates viel mächtigere Dinge machen kann. Dafür hat man dann aber in Java kleineren Code als in C++ wegen fehlender Codeduplizierung.

Die Inkonsistenz zwischen primitiven Typen, String und anderen Typen gefällt mir auch nicht so gut. Außerdem fehlt mir Operatorüberladung gerade für Dinge wie Ein-/Ausgabe, eigene Zahlenklassen, Arrays etc. und mich stören die umständlichen Möglichkeiten der Unterscheidung zwischen Stack/Heap bzw. Kopier-/Referenzsemantik.

Dann wären da natürlich noch die fehlenden RAII-Möglichkeiten.

EDIT: Ja, die Überbenutzung von Exceptions finde ich auch etwas störend...

"Normale" Vorteile von C++:
-meist kleine Performancevorteile bei gleichen Algorithmen
-mehr hardwarenahe Möglichkeiten

Vorteile von Java:
-umfangreiche Standardbibliothek
-Eclipse
-nicht so kompliziert
-Reflection für Debugausgaben
-geringere Fehleranfälligkeit für Anfänger wg. Exceptions statt "Programm xxx funktioniert nicht mehr..."

[Ethon]

SeppJ schrieb:

Ethon schrieb:

Gibts nicht noch einen C++-to-C Compiler? Dann würde es überall laufen.
Eigentlich schade dass zb der GCC soetwas nicht anbietet ...

Wenn du einen C-Compiler hast, dann hast du auch einen C++-Compiler, denn du kannst den C++-Compiler mit dem C-Compiler bauen.

Ich meinte eher soetwas:

Input:

template<typename T>
class Foo
{
private:
  T number;

public:
  Foo(T num)
    : number(num)
  { }

  T add(T num)
  {
    number += num;
    return number;
  }
};

int main()
{
  Foo<int> foo(12);
  foo.add(3);
}

Output:

struct Foo_int
{
  int number;
};

void Foo_int__construct1(struct Foo_int* thisp, int num)
{
  thisp->number = num;
}

int Foo_int__add(struct Foo_int* thisp, int num)
{
  thisp->number += num;
  return thisp->number;
}

void Foo_int__destruct(struct Foo_int* thisp)
{

}

int main()
{
  struct Foo_int foo;
  Foo_int__construct1(&foo, 12);
  Foo_int__add(&foo, 3)
  Foo_int__destruct(&foo)
}

[SeppJ]

Ich habe schon verstanden, dass du das meinst. Ja, das gibt es auch. Aber man braucht es nicht, weil man das C++-Programm sowieso auf der Plattform übersetzen kann auf der es den C-Compiler gibt, da es in C geschriebene C++-Compiler und Laufzeitbibliotheken gibt.

[wxSkip]

SeppJ schrieb:

Ich habe schon verstanden, dass du das meinst. Ja, das gibt es auch. Aber man braucht es nicht, weil man das C++-Programm sowieso auf der Plattform übersetzen kann auf der es den C-Compiler gibt, da es in C geschriebene C++-Compiler und Laufzeitbibliotheken gibt.

Und wenn es einen C-Crosscompiler für die Plattform gibt, aber keinen C++-Crosscompiler mit entsprechendem Backend?

[Ethon]

So meinte ich das auch.
Wenn ich Software für einen 50 Mhz Microcontroller mit 2 MB RAM schreibe, dann möchte ich nicht unbedingt auf diesem den GCC kompilieren.

[SeppJ]

wxSkip schrieb:

Und wenn es einen C-Crosscompiler für die Plattform gibt, aber keinen C++-Crosscompiler mit entsprechendem Backend?

Ok, das kann sein . C ist eben noch portabler als C++.

[Tachyon]

wxSkip schrieb:

SeppJ schrieb:

Ich habe schon verstanden, dass du das meinst. Ja, das gibt es auch. Aber man braucht es nicht, weil man das C++-Programm sowieso auf der Plattform übersetzen kann auf der es den C-Compiler gibt, da es in C geschriebene C++-Compiler und Laufzeitbibliotheken gibt.

Und wenn es einen C-Crosscompiler für die Plattform gibt, aber keinen C++-Crosscompiler mit entsprechendem Backend?

Ganz einfach: Dann schreibt man eben schnell einen.