vorteile von c++ gegenüber von java

[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.

[muemmel]

Hi,

eigentlich sind doch Java und C# beides Kinder von C++ und Delphi, die von C++ mehr das Aussehen und von Delphi mehr dfie Charaktereigenschaften/Mentalität geerbt haben.

Gruß Mümmel

[shadow]

muemmel schrieb:

Hi,

eigentlich sind doch Java und C# beides Kinder von C++ und Delphi, die von C++ mehr das Aussehen und von Delphi mehr dfie Charaktereigenschaften/Mentalität geerbt haben.

Gruß Mümmel

Dieses Argument gefällt mir ganz gut
Die Spracheigenschaften/-komplexität von C++ und die RAD inkl. Overhead von Delphi (eine Möglichkeit das zu interpretieren) ...

[Bashar]

Welches Argument? Das ist doch nur eine Behauptung. Bei C# ist sie wegen Anders Hejlsberg offensichtlich berechtigt, bei Java aber nicht.

[otze]

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 ...

AFAIR macht der Comeau genau das.