Warum hat C++ so eine aufwendige Syntax?

Shade Of Mine

DEvent schrieb:

Im grunde kann man das ganze abkuezen: Mir gefaelt C++ einfach nicht, weil es viel zu viele Altlasten hat. Deswegen ist auch Java, C#, RubyOnRails usw. im kommen, weil sie eben keine Altlasten haben.

Ich will keine Diskussion diesbezüglich: aber diese Sprachen haben sehr wohl altlasten - die reichen zwar nicht so weit zurück, aber in ein paar jahren sind die altlasten auch wieder ein problem. bei java zB hast du enorme probleme mit der bytecode kompatibilität was neue features betrifft. das erkennt man zB an der generics implementierung.

altlasten hat jede sprache - denn eine trennung der altlasten bedeutet real world code wegzuschmeissen. und da spielen die leute nicht mit.

warum java etc im kommen hat einen anderen grund. php ist zB auch ganz gross und es hat unendliche C altlasten drin

Artchi

Diese ganzen Fakten, wie verschiedene Lib-Typen usw., sind nichts neues und gibts seit 20 Jahren. Also ich frage jetzt einfach mal: warum erzählt ihr uns das?

DEvent

Artchi schrieb:

Diese ganzen Fakten, wie verschiedene Lib-Typen usw., sind nichts neues und gibts seit 20 Jahren. Also ich frage jetzt einfach mal: warum erzählt ihr uns das?

Weil ich hoffe das man diese Nachteile der Sprache endlich verbessert. Denn ich mag eigentlich die Sprache C++. Wenn ich sie nicht moegen wuerde, dann waere sie mir egal und ich wuerde nie wieder darueber ein Wort verlieren.

Nein, der kleinste gemeinsame Nenner ist die C++ Standardbiliothek (und die sollte jeder Compiler haben).

Ich kann also eine Lib schreiben mit Compiler x unter System y, die Klassen exportiert, und diese Klassen dann in System g unter Compiler h wieder importieren?

Gegenfrage: Wieso sollte man das verbieten?

Weil Header eigentlich nur das Interface bekannt geben sollen.

Wenn ich schon dabei bin: Wieso muss man in den Headers auch private-Member bekanntgeben?

Simon2

DEvent schrieb:

...
Mich stoert nicht das include, sondern was dazu gehoert. Dazu gehoeren die include-guards, vergisst man die, gibts Stress. ...
Dann kann man in den Headern Variablen deklarieren. Wieso ist sowas erlaubt?

Das liegt (wie eigentlich fast alles, was Javaprogrammierer an C++ bemängeln) doch nur daran, dass #include deutlich mächtiger ist als import. Man hat eben eine Präprozessorprogrammierung, die es in Java nicht gibt. "Automatische include-guards" würden Code wie folgenden unmöglich machen:

//DATA.vals
"Hier stehen meine"
"20 MB TEST-Daten"
"drin"

//Modul.cpp
char TestData[] =
#include "DATA.vals"
;

char TestData_Kopie[] =
#include "DATA.vals"
;

DEvent schrieb:

...
Man braucht keine namespaces zu benutzen.

Du monierst die Existenz des globalen Namespace ?

DEvent schrieb:

...
Dann gibt es soviele Bibliothek-Typen, wie es Systeme und Compiler gibt.
...

In Java brauche ich auch für jedes System meine eigene Runtime. Wer nicht wirklich kompiliert, sondern nur zur Laufzeit interpretiert, verlagert das Problem eben auf die Laufzeit.
Die mangelnde Vereinheitlichung bzgl. Compiler(versione)n halte ich auch für eine echte Schwäche von C++.

DEvent schrieb:

...
Dann die Compiler-Zeit. Auch mit prebuffered Headers dauerte es Ewigkeiten, wenn man mal ein wichtiges Interface geaendert hat....

In Java wird ja auch nicht "kompiliert". Verglichen mit dem Job, den C++-Compiler machen (Typsicherheit zur Compilezeit, Optimierung auf gewünschte Plattform, Auslinken, ...) macht der jbuild so gut wie nichts.

Wie oben schon angedeutet: Die meisten Einwände gegen C++ von Javaisten beklagen, dass C++ Dinge kann, mit denen sie nicht klarkommen. Es sind nur in den allerseltensten Fällen Dinge, die C++ NICHT kann, sondern viel öfter ein ZUVIEL.

Viele dieser Dinge sind aber beileibe nicht "überflüssig", sondern ermöglichen oftmals erst die Umsetzung interessanter Programmierkonzepte (z.B. RAII, const-correctness, Metaprogrammierung, ....). In der Vielfalt der Konzepte liegt für mich gerade der Reiz von C++.

Gruß,

Simon2.

hääää schrieb:

wär is päle dofg

CStoll schrieb:

die x-te Reinkarnation eines ***** (ich bin nicht ganz sicher, wie die erste Inkarnation hieß, die (x+1)-te ist Undertaker (mit einer Sicherheit von 99,9%)).

Artchi schrieb:

Das ist so ein Typ, der nach jeder Blamage hier wieder mit einem neuen Nickname im Forum auftaucht. Und immer wieder die gleichen Threads startet und versucht es immer wieder. Anscheinend ist er ein bischen *mach_eine_deutliche_handbewegung*

weiß ich doch ich wollts nur nochmal von euch hörn

@Mr.N:
java und c++ sind beide müll weil
echo "hello world"
is viel kürzer !!1einz *mach_eine_deutliche_handbewegung*

Artchi

DEvent schrieb:

Mich stoert nicht das include, sondern was dazu gehoert. Dazu gehoeren die include-guards, vergisst man die, gibts Stress.

Yo, ist eine Altlast die mich auch stört. Eine IDE sollte dies wenigstens unterstützen, was z.B. VC++ auch macht. Erstelle ich eine neue H-Datei, packt VC++ autom. seinen Includeguard rein. Hier sollten IDEs die Sprachdefizite versuchen zu lindern. Aber im Prinzip ist das ein Thema das es seit bestimmt 30 Jahren gibt. (weiß nicht wie alt C ist)

DEvent schrieb:

Dann kann man in den Headern Variablen deklarieren. Wieso ist sowas erlaubt?

Warum nicht?

DEvent schrieb:

Man braucht keine namespaces zu benutzen.

In der hier heiß gelobten SPrache Java braucht man auch keine Packages definieren. Kann genauso zum Namenskonflickt führen. Ist dort auch nur eine freiwillige Angelegenheit.

DEvent schrieb:

Wozu sind die dann gut?

Um Namenskonflickte zu vermeiden.

DEvent schrieb:

Das man sie nicht benutzen braucht, fuert entweder dazu, dass jeder eine eigene Praefix-Style zu seinen Typen drannsetzt, oder aber das ich Probleme kriegen kann, obwohl ich alles richtig mache. (QtObject oder CString oder so ein Bloedsinn, wieso nicht einfach namespaces?).

Puh, ich weiß nicht wie oft ich das noch sagen muß: QObject, CString usw. sind vor dem C++-Standard entstanden. Da gab es offiziell keine Namespaces. Wollen wir jetzt auf Kamellen rumreiten, die vor 10 Jahren galten? Oder wollen wir über den aktuellen Stand reden?

DEvent schrieb:

Dann gibt es soviele Bibliothek-Typen, wie es Systeme und Compiler gibt. In Java habe ich nur die vorkompelierten Class-Dateien. Die werden von jedem Java-Compiler verstanden. Das der ISO Standard keine Angaben zu Bibliotheken macht, fuert doch nur dazu, dass man sich auf den kleinsten Nenner einigen muss.

Das ist so nicht richtig. ISO Standard macht sehr wohl Angaben zu Bibliotheken. Es gibt eine Std-Lib. Das ist Fakt und wurde hier im Forum immer wieder genannt.

DEvent schrieb:

Im grunde kann man das ganze abkuezen: Mir gefaelt C++ einfach nicht, weil es viel zu viele Altlasten hat. Deswegen ist auch Java, C#, RubyOnRails usw. im kommen, weil sie eben keine Altlasten haben.

Dann steig doch auf Java, C# oder Ruby um. Die können doch alle deine Wünsche besser erfüllen. (meine ich ernst!)

Undertaker

Artchi schrieb:

Das ist so ein Typ, der nach jeder Blamage hier wieder mit einem neuen Nickname im Forum auftaucht. Und immer wieder die gleichen Threads startet und versucht es immer wieder.

der startet überhaupt nix, der schreibt nur viel dazu. manchmal vielleicht etwas zu polemisch, aber da müsst ihr durch

Artchi

DEvent schrieb:

Artchi schrieb:

Diese ganzen Fakten, wie verschiedene Lib-Typen usw., sind nichts neues und gibts seit 20 Jahren. Also ich frage jetzt einfach mal: warum erzählt ihr uns das?

Weil ich hoffe das man diese Nachteile der Sprache endlich verbessert.

Deine Hoffnung ist vergeblich. Warum? Weil niemand vom C++ Komitee hier diese unsinnigen Java vs. C++ Threads liest.
Wenn du es besser/anders haben willst, mußt du ein Proposal schreiben und es dem C++ Komitee vorlegen. Die warten auf Proposals, die haben sich sogar mal "beschwert" das die Community denen zu wenig Material und Feedback gibt.

Hier im Forum bringt das rum geheule absolut nichts.

DEvent schrieb:

Nein, der kleinste gemeinsame Nenner ist die C++ Standardbiliothek (und die sollte jeder Compiler haben).

Ich kann also eine Lib schreiben mit Compiler x unter System y, die Klassen exportiert, und diese Klassen dann in System g unter Compiler h wieder importieren?

Nein, weil du jetzt von Maschinencode ausgehst, und der geht prinzipiell (unabhängig von C++) nicht auf einer fremden Plattform. Selbst wenn ich mit Java Maschinencode erzeuge, wird dein Wunsch nicht in Erfüllung gehen.

Was du haben willst, geht nur mit Plattformen wie Java oder .NET. Wenn du DAS brauchst, dann steige auf die Sprachen der jeweiligen Plattformen um, die können das.

DEvent schrieb:

Gegenfrage: Wieso sollte man das verbieten?

Weil Header eigentlich nur das Interface bekannt geben sollen.

Wenn ich schon dabei bin: Wieso muss man in den Headers auch private-Member bekanntgeben?

Weil es den Klassenaufbau beschreibt. Das ist das Konzept, weil es eine Altlast ist und das damals nunmal ein Verkaufsargument pro C++ war, weil man C-Projekte für C++ begeistern wollte. Auch wenn das heute nicht mehr so sein mag. That's racing!

Hat sich erledigt. Hab mir eine Playstation 3 gekauft.

Undertaker

Mr. N schrieb:

Außerdem: du hast schon gemerkt, dass das Java-Beispiel wesentlich komplexer ist? Nochmal zum vergleichen:
#include <iostream>
int main() {
  std::cout << "Hello World! << std::endl;
}
versus
package dem.mrn.sein.helloworld;

class MyHelloWorld {
  public static void main(String [] arguments) {
    System.out.println("Hello World!");
  }
}

ja, den C++ code kannst du sogar noch runterkürzen, indem du die 'cout' zeile gegen ein simples 'puts' ersetzt.

Mr. N

Jester schrieb:

Mr. N schrieb:
std::string a = "x", b = "x";
a==b; //true
Na, der war mal wieder mit Anlauf.
String a = "x";
    String b = "x";
    if(a==b) System.out.println("a==b");
    else System.out.println("a!=b");
magst Du das mal ausprobieren?

Das untermauert übrigens auch weiter Deine Aussage, dass Du auch diese J-Geschichte bestens beurteilen kannst.

So, gerade habe ich Gregor gefragt, wie das denn ist. Du hast mein Beispiel falsch nach Java übersetzt. Du schriebst:

String a = "x";
    String b = "x";

Es sollte aber sein:

String a = new String("x");
    String b = new String("x");

Und dann gilt a==b nicht mehr.

Ich nenne ein perfekt zutreffendes Beispiel, erwähne Java nichtmal, will also nur sagen, dass ich Value-Semantik toll finde und du kommst mit dem hier. Aber Gregor sagt ich soll mich nicht aufregen, hat er vermutlich auch Recht damit.

Simon2

Artchi schrieb:

...

DEvent schrieb:

Gegenfrage: Wieso sollte man das verbieten?

Weil Header eigentlich nur das Interface bekannt geben sollen.

Wenn ich schon dabei bin: Wieso muss man in den Headers auch private-Member bekanntgeben?

Weil es den Klassenaufbau beschreibt. Das ist das Konzept, weil es eine Altlast ist ...

Ersterem würde ich zustimmen, Zweiterem nicht.
Wer seine private-Sachen verstecken will, kann problemlos Idiome wie "pimpl" verwenden.
Ich würde gerade einem Javaisten antworten: Warum muss ich in Java meine Implementierung in einem Header bekanntgeben ? (also nicht nur die Deklaration, sondern sogar deren Definition).

Insgesamt muss man IMO hier unterscheiden zwischen

#include: Präprozessortechnik zur "Texteladen aus Datei"
"Header": Konzept der Trennung von Interface und Implementierung.

Gruß,

Simon2.

Mr. N schrieb:

new String("x");

soviel zu deinem sachverständnis von java

Kann man auch Spiele für die Playstation 3 in Java schreiben?

Jester

Mr. N schrieb:

Es sollte aber sein:

String a = new String("x");
    String b = new String("x");

Also mit Verlaub, dann klappt zwar das Beispiel, aber die korrekte Übersetzung von std::string a = "x"; nach Java ist String a = "x"; und nix anderes. Du kannst Dich natürlich jetzt noch ein bißchen winden, kannst aber auch einfach zugeben, dass Du es nicht wußtest und Dein Beispiel daher einfach nicht das gezeigt hat was Du zeigen wolltest.

C++ Strings
http://www.c-plusplus.net/forum/viewtopic-var-t-is-188380-and-start-is-0-and-postdays-is-0-and-postorder-is-asc-and-highlight-is-.html
LOL

thordk

Simon2 schrieb:

Ich würde gerade einem Javaisten antworten: Warum muss ich in Java meine Implementierung in einem Header bekanntgeben ? (also nicht nur die Deklaration, sondern sogar deren Definition).

weil es in java das konzept eines tatsächlichen interfaces gibt. wenn du nicht willst, dass jemand deine implementierung sieht, dann schreibst du deine klasse, übersetzt sie in bytecode und lieferst nur die .class datei aus, inklusive seperatem interface und eines class-loaders.

Undertaker

thordk schrieb:

wenn du nicht willst, dass jemand deine implementierung sieht, dann schreibst du deine klasse, übersetzt sie in bytecode und lieferst nur die .class datei aus...

http://members.fortunecity.com/neshkov/dj.html

Zeus

Ob es nur decompiler für Java gäbs *gg*

Mr. N

Jester schrieb:

Mr. N schrieb:
Es sollte aber sein:
String a = new String("x");
    String b = new String("x");
Also mit Verlaub, dann klappt zwar das Beispiel, aber die korrekte Übersetzung von std::string a = "x"; nach Java ist String a = "x"; und nix anderes. Du kannst Dich natürlich jetzt noch ein bißchen winden, kannst aber auch einfach zugeben, dass Du es nicht wußtest und Dein Beispiel daher einfach nicht das gezeigt hat was Du zeigen wolltest.

Mit Verlaub, die Korrekte Übersetzung ist String a = new String("x"); da in C++ ein NEUER STRING mit Inhalt KOPIE EINES LITERALS (Typ char const []) erzeugt wird. (Korrekterweise gibt es gar keine Übersetzung für den Code, weil String etwas ganz anderes ist als std::string.)

Was soll ich nicht gewusst haben? Du bist mit einem Java-Vergleich angetanzt, ich habe nur gezeigt, was ich an C++ toll finde.

Value-Semantik ist toll.