C oder C++?

Hallo,
eins vorweg: Ich habe mehrmals die Suchenfunktion benutzt und wurde leider nicht fündig.

Ich habe mal eines Sommers angefangen C++ zu lernen als ich dann schliesslich in die neue Schule kam, verkündete der Lehrer, dass wir Java lernen werden. Nun, ich war etwas enttäuscht und ich wurde immer enttäuschter, da Java sehr beschränkt ist. Darum habe ich mir vorgenommen, dass ich einfach C oder C++ parallel lernen werde.

Nun frage ich mich, was soll ich lernen?!

C ist sehr hardwarenah und imho nach Assembler die schnellste Sprache. Ich interessiere mich ebenfalls sehr für Linux, das auch in C implementiert wurde.
Darum würde ich persönlich mich für C entscheiden.

Frage: Was spricht für C++? Imho ist es nicht ganz so schnell und hardwarenah wie C.

Über eine Aufklärung würde ich mich freuen.

Liebe Grüße
Real

rüdiger

1. Geschwindigkeitsaussagen kann man nicht über Sprachen treffen! Nur über Implementierungen. Es ist absolut dämlich zu sagen, dass Sprache a langsammer ist als Sprache b, wenn man nur deren Syntax betrachtet.

2. was verstehst du unter Hardwarenah?

für C++ spricht, dass es so coole Features gibt, wie Templates, Klassen, Namespaces und Boost.

Hallo

kingruedi schrieb:

1. Geschwindigkeitsaussagen kann man nicht über Sprachen treffen! Nur über Implementierungen. Es ist absolut dämlich zu sagen, dass Sprache a langsammer ist als Sprache b, wenn man nur deren Syntax betrachtet.

Wer macht das? Benchmarks liefern nun mal Fakten, da braucht man nicht empfindlich reagieren, wenn seine Lieblinssprache etwas kritisiert wird.

2. was verstehst du unter Hardwarenah?

Z.B. Systemprogrammierung

für C++ spricht, dass es so coole Features gibt, wie Templates, Klassen, Namespaces und Boost.

Hmm, schade das ich in C darauf verzichten müsste! Gibt´s da andere Methoden?!

Liebe Grüße
Real

Floh

wenn du in der schule java lernst, solltest du imho eher c++ lernen als c, da dir in c die klassen fehlen werden.

Helium

Wer macht das? Benchmarks liefern nun mal Fakten, da braucht man nicht empfindlich reagieren, wenn seine Lieblinssprache etwas kritisiert wird.

Nein, du verstehst das Falsch. Für C (und auch C++) gibt es tausende von verschiedenen Compilern. Der ICC optimiert beispielsweise verammt gut und erzeugt wesentlich schnelleren Code, als viele andere Compiler. Es ist aber immer die selbe Sprache. Es ist genausogut möglich, das ein Compiler für C so schlechten Code generiert, dass eine normale Lösung langsamer ist, als eine durchschnittliche Java-Lösung des selben Problems auf beispielsweise Suns VM.

Z.B. Systemprogrammierung

Was ist Systemprogrammierung? Beispiel: Mit entsprechenden Bibliotheken kannst du in VB direkt den Com-Port ansprechen, genauso, wie du in C++ mit entsprechenden Bibliotheken den Com-Port ansprechen kannst.

Hmm, schade das ich in C darauf verzichten müsste! Gibt´s da andere Methoden?!

Inwiefern auf C verzichten? C ist zu 99% eine Teilmenge von C++. Die nterschiede sind winzig. Der miste Teil könte (synthatisch gesehen) als eine pure Eweiterung C gegenüber gesehen werden.
Sematisch ist der Unterschied natürlich gigantisch: In programmiert man prozedural, in C++ objektorientiert.

rüdiger

Real schrieb:

Hallo

kingruedi schrieb:

1. Geschwindigkeitsaussagen kann man nicht über Sprachen treffen! Nur über Implementierungen. Es ist absolut dämlich zu sagen, dass Sprache a langsammer ist als Sprache b, wenn man nur deren Syntax betrachtet.

Wer macht das? Benchmarks liefern nun mal Fakten, da braucht man nicht empfindlich reagieren, wenn seine Lieblinssprache etwas kritisiert wird.

du verstehst es nicht. Du kannst immer nur Geschwindigkeiten von Implementierungen messen. Deswegen kannst du auch nur Implementierungen vergleichen. Anders ist das nicht möglich!

(btw. wär ich gern mal an den von dir genannten Benchmarks interessiert )

2. was verstehst du unter Hardwarenah?

Z.B. Systemprogrammierung

das kannst du natürlich auch in C++ machen. C++ und C sind ja sehr eng verwandt

für C++ spricht, dass es so coole Features gibt, wie Templates, Klassen, Namespaces und Boost.

Hmm, schade das ich in C darauf verzichten müsste! Gibt´s da andere Methoden?!

nein, C++ wurde ja entworfen um diese Features in C einzuführen.

Hallo,
danke für die Antworten! Was ich will, ist erst mal weg von Java! Das ist der größte Mist der Welt (zumindest ist es nicht das, was mich interessiert)!

Gut, dann hätte ich ein paar Fragen:
Wenn C++ bessere Features als C bietet, wieso wurde dann später nicht Unix, Linux, BSD und all die Betriebssysteme nicht mit C++ implementiert? Wieso ist der Interpreter von PHP in C geschrieben? Seine Gründe wird es doch wohl haben.

Du kannst immer nur Geschwindigkeiten von Implementierungen messen. Deswegen kannst du auch nur Implementierungen vergleichen. Anders ist das nicht möglich!

Ja, das meine ich ja. Es ist allgemein bekannt, das Java-Software langsamer sind als ein Programm, das denselben Zweck in C oder C++ erfüllt. Ich mein das jetzt sehr verallgemeinert.

Liebe Grüße
Real

Hallo,
danke für die Antworten! Was ich will, ist erst mal weg von Java! Das ist der größte Mist der Welt (zumindest ist es nicht das, was mich interessiert)!

Cool, du lernst es gerade erst, aber es ist auf jeden Fall schon mal der größte Mist der Welt.

Ja, das meine ich ja. Es ist allgemein bekannt, das Java-Software langsamer sind als ein Programm, das denselben Zweck in C oder C++ erfüllt. Ich mein das jetzt sehr verallgemeinert.

Das meinst du deshalb verallgemeinert, weil du nicht programmieren kannst und nicht verstehst, wie sich die Performance eines Programms zusammensetzt.
(Hast du ja bereits unter Beweis gestellt)

HumeSikkins

Helium schrieb:

Was ist Systemprogrammierung?

Das kannst du vielerorts nachlesen. Du willst mir doch nicht erzählen, dass sich Visual Basic für die Systemprogrammierung genauso eignet wie C?

Ich verstehe eure Einwände zwar, aber man muss deshalb imo auch nicht so tun, als ob alles eines Suppe wäre. Wer nah an die Maschine ran will, der ist mit C (und auch C++) eindeutig besser dran, als mit VB.

HumeSikkins

Optimizer schrieb:

Ja, das meine ich ja. Es ist allgemein bekannt, das Java-Software langsamer sind als ein Programm, das denselben Zweck in C oder C++ erfüllt. Ich mein das jetzt sehr verallgemeinert.

Das meinst du deshalb verallgemeinert, weil du nicht programmieren kannst und nicht verstehst, wie sich die Performance eines Programms zusammensetzt.
(Hast du ja bereits unter Beweis gestellt)

Verallgemeinert stimmt das doch durchaus. Schließlich bekommt man auch die Java-Features nicht umsonst. Ob der Geschwindigkeits- und Speicheranforderungsunterschied in der Praxis relevant ist, hängt natürlich von der Situation ab. Deshalb kann man aber nicht gleich so tun, als gäbe es keine Kosten.

Die Welt ist sicher nicht schwarz-weiß (nach dem Motto: C ist schnell und Java lahm), es ist definitiv aber auch nicht alles grau (nach dem Motto: Alles ist gleich. Unterschiede ergeben sich nur aus der Inkompetenz des Programmierers oder der Schwäche einer Implementation).

Hallo

Optimizer schrieb:

Hallo,
danke für die Antworten! Was ich will, ist erst mal weg von Java! Das ist der größte Mist der Welt (zumindest ist es nicht das, was mich interessiert)!

Cool, du lernst es gerade erst, aber es ist auf jeden Fall schon mal der größte Mist der Welt.

Für mich ist es Mist, weil ich mit Java nicht mal ein CD-ROM Laufwerk öffnen könnte. Bei Java muss ich mich auf triviale Dinge einlassen und kann nicht Programme programmieren, die speziell für das OS gedacht sind.

Ja, das meine ich ja. Es ist allgemein bekannt, das Java-Software langsamer sind als ein Programm, das denselben Zweck in C oder C++ erfüllt. Ich mein das jetzt sehr verallgemeinert.

Das meinst du deshalb verallgemeinert, weil du nicht programmieren kannst und nicht verstehst, wie sich die Performance eines Programms zusammensetzt.
(Hast du ja bereits unter Beweis gestellt)

Nun, ich habe schon ein Fremdwörterbuch programmiert mit Datenbankanbindung, habe auch einige Tuning-Tips ausprobiert. Beispielsweise habe ich StringBuffer statt String benutzt. Aber ich will eben hardwarenah und speziell für das System programmieren und Java ist deswegen für mich ein Mist, weil es nicht diese Zwecke erfüllt.
Gut, es gibt einige Tricks, wie man dies und das in Java realisieren könnte, aber da kommen beispielsweise bei Windows dlls im Spiel und schon ist die Plattformunhabhängigkeit futsch. Was nützt mir da noch Java?!

Zudem ist Java umständlich! Schon mal ein einfaches I/O in Java realisiert oder einige Daten als Text-File gespeichert?!

Liebe Grüße
Real

CMatt

Wenn C++ bessere Features als C bietet, wieso wurde dann später nicht Unix, Linux, BSD und all die Betriebssysteme nicht mit C++ implementiert?

das neuen Zeug ist doch c++.. diese ganzen Internet/Browser/IIS interfaces, der XML krahm, Streaming Devices, DirectX (immer mehr), GDI+, bla.., blub.. fast alles COM oder DCOM... kann mir auch schlecht vorstellen das MS seine .Net platform in C und Assembler schreibt..

CMatt

Zudem ist Java umständlich! Schon mal ein einfaches I/O in Java realisiert oder einige Daten als Text-File gespeichert?!

Schon mal in C++ ne GUI mit 150 Dialogen, datenbankanbindung, Netzwerk, vielen klick bunti buttons, für Windows, Linux, BSD, MAC,.. gleichzeitig programmiert?

Das was du da schreibst ist doch absoluter käse... Klar ist java schrott wenn damit bitschieben auf nen I/O karte geht.. aber ebenso ist c++ für das bsp oben schrott.

Nun, ich habe schon ein Fremdwörterbuch programmiert mit Datenbankanbindung, habe auch einige Tuning-Tips ausprobiert. Beispielsweise habe ich StringBuffer statt String benutzt.

Respekt! Besonders im Bezug darauf, dass man wenn möglich, StringBuffer nicht nutzen soll, wenn man Strings nutzen kann.
Hängt natürlich vom genauen Verwendungszweck ab, aber deine Aussage ist so allgemein, dass StringBuffer in den allermeisten Fällen wohl die schlechtere Wahl ist. Außerdem wirst du damit nicht großartig die Performance eines Programms beeinflussen können.

Überhaupt schreibst du absoluten Mist. So ein BufferedReader/BufferedWriter für I/O ist IMO keinesfalls schlechter/langsamer als der ofstream in C++, und ja, ich habe schon mal was in eine Datei geschrieben und finde das weder in C++ noch in Java schwer.

Java ist sicherlich in den meisten Fällen weniger umständlich, weil es ein sehr ausführliches, plattformunabhängiges (<- relativ) API mit sich bringt und überhaupt viel vorgefertigt hat und einem viel Arbeit und Sorgen abnimmt.

Gegen Java sprechen ganz andere Dinge (es hat auch einige Nachteile, aber höchstwahrscheinlich nicht die, an die du glaubst), aber die kannst du nicht begreifen, denn du bist ganz offensichtlich nicht in der Lage, diese Dinge zu verstehen, wenn du ein Fremdwörterbuch für was besonderes hältst.
Es ist immer auch eine Frage, was für welchen Zweck geeignet ist, aber du bist sicher nicht in der Lage, eine für deine Zwecke geeignete Sprache auszuwählen, da sich deine "Systemprogrammierung" anscheinend auf das Nutzen von DLLs beschränkt.

Bashar

Real schrieb:

Wenn C++ bessere Features als C bietet, wieso wurde dann später nicht Unix, Linux, BSD und all die Betriebssysteme nicht mit C++ implementiert? Wieso ist der Interpreter von PHP in C geschrieben? Seine Gründe wird es doch wohl haben.

Das ist eine gute Frage, die du sicherlich auch an die Entwickler von Linux, BSD und PHP stellen kannst. Objektive Kriterien gegen C++, für C, sind aber z.B.:

C++ Compiler unterscheiden sich stark im Konformitätsgrad, d.h. man muss, wenn man auf einen gemeinsamen Nenner kommen will, sehr viele Abstriche bei fortgeschrittenen Features wie Templates, Exceptions und Namespaces machen (siehe z.B. Coding-Richtlinien des Mozilla-Projektes)
C Compiler sind verbreiteter als C++ Compiler. Es gibt effektiv auf jeder Plattform einen C-Compiler, wenn auch rudimentär. Das reicht aber, um z.B. PHP oder auch GTK+ darauf zu portieren.
[ die folgenden Argumente unter der Prämisse betrachten, dass effektiv der einzige (?) freie C++ Compiler der gcc ist) ]
3a) gcc wurde erst kürzlich mit der Version 3 halbwegs standardkonform. Beim Übergang von 2 zu 3 hat sich aber z.B. das Binärinterface (ABI) geändert, was zu hohem Aufwand beim Updaten führt. Ergo wird das nicht gemacht (bzw. erst in den letzten Monaten/Jahren)
3b) gcc übersetzt C++ sehr viel langsamer als C
3c) die erzeugten Programme sind sehr viel größer als entsprechende C-Äquivalente

Subjektive Kriterien:
4) C++ bringt ein eigenes Denkmodell mit sich, dass mit den in der Betriebssystementwicklung oder im Compilerbau ( PHP-Interpreter) vorherrschenden kollidiert. Man muss also entweder seine Philosophie an die von C++ anpassen, oder die von C++ irgendwie zurechtbiegen, oder praktisch auf C-Level zurückgehen.
5) Objektorientierung kann man sehr schön übertreiben, insbesondere wenn es an Erfahrung mangelt. Man will nicht, dass beispielsweise Linus Torvalds, dem ich mal eine ausserordentliche Kompentenz in Sachen Betriebssysteme unterstelle, plötzlich ein mittelmäßiges bis grottiges C++-OS produziert, bis er in OO so gut ist, dass er den alten Standard wieder erreicht.

Zwangsstopp hier

Hallo Optimizer,

Optimizer schrieb:

Respekt! Besonders im Bezug darauf, dass man wenn möglich, StringBuffer nicht nutzen soll, wenn man Strings nutzen kann.

Kennst du überhaupt den Unterschied zwischen String und StringBuffer?!
Wenn du in String etwas anhängst/veränderst, was macht das Objekt String?! Was macht StringBuffer?! Wenn du den Unterschied weisst, dann erkennst du warum String nicht nur mehr Speicher frisst, sondern auch deutlich langsamer ist.

Hängt natürlich vom genauen Verwendungszweck ab, aber deine Aussage ist so allgemein, dass StringBuffer in den allermeisten Fällen wohl die schlechtere Wahl ist.

Falsch! (Für was hat man eigentlich StringBuffer erfunden, wenn es immer die Schlechtere Wahl ist?!)
Wenn es um Sicherheit geht, ist String besser, sonst nie! :p

Außerdem wirst du damit nicht großartig die Performance eines Programms beeinflussen können.

Kommt drauf an! Wenn du eine fette Liste zusammnhängender Strings ausgibst, ist String um ein vielfaches langsamer als StringBuffer.
Ich hab´s mal in einer Schleife probiert. String braucht über eine Minute und StringBuffer nur wenige Sekunden (unter 5). Wieviele String ich angehängt habe und wie oft die Schleife durchloffen worden ist, weiss ich nicht mehr, aber probier´s am Besten selbst aus.

Überhaupt schreibst du absoluten Mist. So ein BufferedReader/BufferedWriter für I/O ist IMO keinesfalls schlechter/langsamer als der ofstream in C++

Nein, tut mir Leid das sagen zu müssen, aber du schreibst absoluten Mist! Warum tust du das? Keiner deiner genannten Behauptungen habe ich jemals erwähnt, sage mir bitte wo!
Ich wollte dir jediglich übermitteln, dass es in Java umständlicher (weder langsam, noch schwer, noch sonst irgendwas) ist.

Gegen Java sprechen ganz andere Dinge (es hat auch einige Nachteile, aber höchstwahrscheinlich nicht die, an die du glaubst), aber die kannst du nicht begreifen, denn du bist ganz offensichtlich nicht in der Lage, diese Dinge zu verstehen, wenn du ein Fremdwörterbuch für was besonderes hältst.

Tu ich nicht, ich wollte dir nur mitteilen, auf welchem Stand ich gerade bin.
Erzähl mir bitte die Nachteile von Java.
Wie gesagt gefällt mir Java nicht, da ich damit nicht hardwarenah proggen kann und OS-spezifisch, darum habe ich mich entschieden erst mal in C anzufangen und dann später mit C++, so kann ich beide Vorteile kombinieren.

Es ist immer auch eine Frage, was für welchen Zweck geeignet ist, aber du bist sicher nicht in der Lage, eine für deine Zwecke geeignete Sprache auszuwählen, da sich deine "Systemprogrammierung" anscheinend auf das Nutzen von DLLs beschränkt.

Sag bitte, wo habe ich das erwähnt?
In diesem Satz den du erwähnst, kam der Satz "beispielsweise" vor und noch weiter oben erwähnte ich, das ich an Linux interessiert bin (und mich auch teilweise damit beschäftige - bald kommt Debian drauf).

Ich würde gerne dein Anliegen erfahren, warum du dir irgendwelche Geschichten zusammenreimst!
Ich bin hier Gast und kann hier nichts editieren, zeig mir bitte deine erwähnten Behauptungen.

Hallo Bashar!
Deine Gründe klingen logisch, aber C ist soweit ich weiss noch hardwarenhäer als C++. Ich werde mal in einem Linux-Forum nachfragen.

Liebe Grüße
Real

Shade Of Mine

Real schrieb:

aber C ist soweit ich weiss noch hardwarenhäer als C++

Was kannst du in C machen was du in C++ nicht kannst?

Hallo Real,

Kennst du überhaupt den Unterschied zwischen String und StringBuffer?!
Wenn du in String etwas anhängst/veränderst, was macht das Objekt String?! Was macht StringBuffer?! Wenn du den Unterschied weisst, dann erkennst du warum String nicht nur mehr Speicher frisst, sondern auch deutlich langsamer ist.

Ja, den kenne ich. Ein String ist eine immutable Sequenz von Zeichenketten. Aus diesem Grund können sie wesentlich effizienter implementiert werden, weil sie einfach neu erstellt werden, wenn du an ihnen arbeitest. length und andere Eigenschaften sind Konstanten. Wenn du z.B. den String nach Uppercase konvertierst, wird der eigentliche String überhaupt nicht angefasst, sondern es wird ein neuer erstellt (was in Java übrigens ziemlich schnell geht), der die passenden Daten enthält und eine Referenz darauf zurückliefert.
Außerdem können Strings im Gegensatz zu StringBuffers geshared werden.
String a = b;
bewirkt nur die Kopie eines Zeigers. So einfach kannst du das in C++ bestenfalls mit der Copy-on-write Technik erreichen, die einigermaßen aufwändig zu implementieren ist und auch Overhead erzeugt. Btw. die std::string implementierung von meinem Compiler nutzt diese Vorgehensweise nicht, da wird wirklich jedesmal der String kopiert.

StringBuffer dagegen sind mutable und können entsprechende Vorteile nicht genießen. Sie sind dafür gedacht, dass wenn man einen StringBuffer ändert, alle Referenzen darauf diese Änderung mittragen. Der '+' Operator nutzt übrigens StringBuffer (vlg. Java API Dokumentation).

Falsch! (Für was hat man eigentlich StringBuffer erfunden, wenn es immer die Schlechtere Wahl ist?!)
Wenn es um Sicherheit geht, ist String besser, sonst nie!

Ok, zu StringBuffer siehe oben. Manchmal braucht man halt die Eigenschaften von veränderlichen Strings.

Kommt drauf an! Wenn du eine fette Liste zusammnhängender Strings ausgibst, ist String um ein vielfaches langsamer als StringBuffer.
Ich hab´s mal in einer Schleife probiert. String braucht über eine Minute und StringBuffer nur wenige Sekunden (unter 5). Wieviele String ich angehängt habe und wie oft die Schleife durchloffen worden ist, weiss ich nicht mehr, aber probier´s am Besten selbst aus

Ist nicht langsamer. Der Sourcecode würde mich interressieren. Es hat dir ja keiner gesagt, dass du '+' benutzen sollst, um mehrere Strings auszugeben (wie gesagt, '+' ist über StringBuffer implementiert).
Mehrere print's erfüllen genau den selben Zweck.

Ich wollte dir jediglich übermitteln, dass es in Java umständlicher (weder langsam, noch schwer, noch sonst irgendwas) ist.

Was genau ist umständlicher, besonders in Bezug auf I/O und im speziellen File I/O ?

Tu ich nicht, ich wollte dir nur mitteilen, auf welchem Stand ich gerade bin.
Erzähl mir bitte die Nachteile von Java.

Für mich persönlich sprechen ein paar sprachliche Beschränkungen gegen Java. Zum Glück kommen jetzt bald Generics. Ich vermisse Templates (homogene Container), const-correctness, Referenzen auf primitive Typen und Operator overloading, zumindest bei allen Operatoren außer '==', '!=' und offizielle Unterstützung für DirectX (die auch nie kommen wird).

Es gibt viele Anwendungen (vielleicht die meisten), wo ich Java vorziehe, weil es IMO einfacher und produktiver ist. Ich sehe aber auch ab und zu Dinge, die ich lieber in C++ löse.
Aber deine Begründungen, warum Java überhaupt keine Existenzberechtigung hat, ist IMO nicht nachvollziehbar.

Shade Of Mine

Optimizer schrieb:

Außerdem können Strings im Gegensatz zu StringBuffers geshared werden.
String a = b;
bewirkt nur die Kopie eines Zeigers. So einfach kannst du das in C++ bestenfalls mit der Copy-on-write Technik erreichen, die einigermaßen aufwändig zu implementieren ist und auch Overhead erzeugt.

Wozu? Java macht doch auch kein Copy-On-Write, wozu soll ich das also machen? Sind ja 2 verschiedene Sachen. Ich share einfach auch das Objekt:

shared_ptr<string> p(new string("hallo"));
shared_ptr<string> p2(p);

Btw. die std::string implementierung von meinem Compiler nutzt diese Vorgehensweise nicht, da wird wirklich jedesmal der String kopiert.

Sehr kluge entscheidung des Herstellers.

Was genau ist umständlicher, besonders in Bezug auf I/O und im speziellen File I/O ?

EOF ist eine Exception?
Ich muss BufferedReader, Writer und sonstwas erstellen.
Also gerade IO gefällt mir in Java weniger gut.

Aber deine Begründungen, warum Java überhaupt keine Existenzberechtigung hat, ist IMO nicht nachvollziehbar.

wo hat er das gesagt?

gomberl

JUHUUUUUUU

FLAMEWAR

EOF ist eine Exception?
Ich muss BufferedReader, Writer und sonstwas erstellen.
Also gerade IO gefällt mir in Java weniger gut.

das mit eof geb ich dir - das hatten wir schon mal an anderer stelle.

hier sei angeführt das java einen anderen ansatz zur dateibearbeitung hat als alles das ich kenne. es gibt das file (quasi der pointer auf die file structur in gutem alten C), die streams zum einlesen und auslesen und den reader und writer (schreiben und lesen)
das alles macht es universell auf allen plattformen einsetzbar ohne das man an der implementierung was ändern müsste

man hat ausserdem wesentlich mehr möglichkeiten verschiedenste dinge objekt orientiert zu schreiben

also ich mag das - auch wenn es mehr aufwand als in C++ ist

ich würde Real nicht so abtun, er hat halt keine lust sich wo einzuarbeiten und hat sicher viele vorurteile die auch andere haben
aber wenn es nicht sein bier ist soll er halt mit C schreiben
wenns wirklich tief runtergehen soll empfehle ich assembler
da gehts dann rund

gomberl