vorteile von c++ gegenüber von java

this-*gt*that

Erst 5 Seiten?

Forum, I am disappoint

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.

Java ist doch seit der Übernahme durch Oracle total uninteressant geworden. Oracle versucht Java zu zerstören.

Der Battle findet doch nur noch zwischen C++ und C# statt.

Jockelx

RAII, RAII und nochmals RAII!
Ich muss gerade wieder was in Java (Android) machen und diese try-catch-finally-Orgien machen mich wahnsinnig!

Abgesehen davon, der Performance (der in Java geschrieben Emulator ist sooooo unfassbar lahm) und dass man primitiv-Typen nicht einfach per Referenz übergeben kann, programmiere ich ganz gerne mit Java.

Ach ja, und const vermisse ich auch sehr. Macht ein Programm doch deutlich lesbarer.

krümelkacker

wxSkip schrieb:

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.

Der Typparameter bei Java Generics beschränkt sich auf einen Klassentyp und Variablen dieses Typs sind in Wirklichkeit Referenzen (also vergleichbar mit Zeigern in C++). Dafür muss in C++ auch nicht Code doppelt und dreifach erzeugt werden. Beispiel:

template<>
class vector<void*> {...};

template<class T>
class vector<T*> : vector<void*>
{
  typedef vector<void*> basetype;
:::
  void push_back(T* ptr) { basetype::push_back(ptr); }
  void pop_back() { basetype::pop_back(); }
  size_type size() const { return basetype::size(); }
::: u.s.w.
};

Die Verwendung dieser kleinen inline-Funktionen kostet bei einem optimierendem Compiler nichts. Es werden im Kompilat auch nicht zig push_back Funktionen für dieverse Zeigertypen stehen sondern höchstens eine für void*.

Ich würde sogar heutzutage erwarten, dass Compiler selbst schlau genug sind, den Maschinencode von mehreren Instanzen von Funktionstemplates "zusammen zu legen", falls diese zu 100% identischem Machinencode führen. Damit wäre der void*-Trick von oben dann auch überflüssig. Und in diesem Beispiel ist es dem Vektor wirklich egal, was das für Zeiger sind. Da wird nirgends unterschiedlicher Code für unterschiedliche Zeigertypen verwendet.

Also, ich würde nicht sagen, dass der C++ Ansatz hier inherent zu "code bloat" führt. Wenn da irgendwo Code dupliziert wird, dann liegt das entweder am Design des Programms (beispielsweise unnötig "große" Funktionen, die zig Sachen auf einmal erledigen sollen, wobei einiges aber nicht alles unabhängig von Templateparametern geschiet ... und/oder man verwendet einen Compiler, der es nicht gebacken bekommt, diese Redundanzen zu erkennen.