C oder C++?

[Gregor]

Real schrieb:

Ich kann zwar das Gelernte umsetzen, aber nur irgendwelche Klassen aufzurufen, das mir dies und das erledigt ist für einen Anfänger nicht das wahre, da ich gerne kapieren will was da vorsichgeht!

Wenn du wissen willst, was da vor sich geht, dann empfehle ich dir, ein Buch über Rechnerarchitektur usw. zu lesen. Da erfährst du mehr, als wenn du C lernst.

[Gregor]

gomberl schrieb:

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.

Ich habe es schon wieder vergessen, also könnte mir einer von euch mal erklären, was passieren sollte, wenn ich eine Datei mit 5 Bytes habe und 10 mal eine Methode "liesNächstesByte" aufrufe? Warum sollte in so einem Fall keine Exception ausgelöst werden? Vielleicht weil der Programmierer immer perfekt ist und solche offensichtlichen Fehler in der Realität garnicht vorkommen?!

[Gast]

Ist jetzt sowieso nur noch bedingt ein Thema:

Java API Dokumentation schrieb:

This iterated read continues until one of the following conditions becomes true:

The specified number of characters have been read,
The read method of the underlying stream returns -1, indicating end-of-file, or
The ready method of the underlying stream returns false, indicating that further input requests would block.

[Real]

Hi,

Optimizer schrieb:

@Real: ja lol, du benutzt überall append(), wenn du da Strings hernimmst, müssen die erstmal in StringBuffer konvertiert werden.

Nö, umgekehrt. xxx.toString();

Du hast also nicht Strings mit StringBuffer verglichen. Wo ist denn jetzt genau das Problem, mehrere Strings nacheinander auszugeben?
Und wenn du sie unbedingt konkatenieren willst, dann mach das alles in einer Anweisung mit '+', dann legt die VM gleich einen großen StringBuffer an und haut blitzschnell alles rein.

ich habe StringBuffer dort implementiert, wo ich es für effizient hielt.
Einen Vergleich mit String? Den habe ich! Ich habe einfach StringBuffer mit String ersetzt, alles schön mit "+" angehängt und es war langsam wie die Sau als ich die oben genannten Werte eingab.

Liebe Grüße
Real

[Gast]

Real schrieb:

Einen Vergleich mit String? Den habe ich! Ich habe einfach StringBuffer mit String ersetzt, alles schön mit "+" angehängt und es war langsam wie die Sau als ich die oben genannten Werte eingab.

Liebe Grüße
Real

Nein, du hast keinen Vergleich, weil '+' über StringBuffer realisiert wird, ich bereits sagte:

Java API Dokumentation schrieb:

String buffers are used by the compiler to implement the binary string concatenation operator +. For example, the code:

x = "a" + 4 + "c"
is compiled to the equivalent of:

x = new StringBuffer().append("a").append(4).append("c")
.toString()

Es ist also reine Geschmacksache, ob man wie du schreibt:

kapitalAusgabe= kapitalAusgabe.append(i).append(". Jahr: ").append(preis).append(" € \n");

Oder wie ich schreibt:

kapitalAusgabe  +=  i + ". Jahr: " + preis + " € \n";

Dein ganzer H4ck (ich bezeichne es mal unfreundlicherweise so) ist in dem Glauben enstanden, dass du dann mehr Performance hast. Aber die Leute, die Java entwickeln, sind doch auch nicht blöd.

daten.write(kapitalAusgabe.toString());
    daten.newLine();
    daten.write("________________________");
    daten.newLine();

Hältst du das auch für effizienter als

daten.write(kapitalAusgabe + "\n______\n"    // toString() wird implizit aufgerufen

?

Wie du siehst, ist es eh vollkommen gleich, was du machst. Und wenn es z.B. um Zuweisungen (kopieren!) geht, dann kann ein immutable String punkten, wegen der von mir genannten Gründe.
Dann noch frohes optimizern...

[Real]

Hi,
wir sprechen hier aber immernoch von Java?!

"HauptFenster.java": Fehler #: 354 : Inkompatible Typen; java.lang.String wurde gefunden, java.lang.StringBuffer ist erforderlich in Zeile 211, Spalte 24

Zudem schreiben es auch alle Java-Bücher so.

Auszug aus javabuch.de Kapitel 49 Performance-Tuning

001 String s;
002 s = "";
003 for (int i = 0; i < 20000; ++i) {
004   s += "x";
005 }

Das Programmfragment hat die Aufgabe, einen String zu erstellen, der aus 20000 aneinandergereihten "x" besteht. Das ist zwar nicht sehr praxisnah, illustriert aber die häufig vorkommende Verwendung des +=-Operators auf Strings. Der obige Code ist sehr ineffizient, denn er läuft langsam und belastet das Laufzeitsystem durch 60000 temporäre Objekte, die alloziert und vom Garbage Collector wieder freigegeben werden müssen. Der Compiler übersetzt das Programmfragment etwa so:

001 String s;
002 s = "";
003 for (int i = 0; i < 20000; ++i) {
004   s = new StringBuffer(s).append("x").toString();
005 }

Dieser Code ist in mehrfacher Hinsicht unglücklich. Pro Schleifendurchlauf wird ein temporäres StringBuffer-Objekt alloziert und mit dem zuvor erzeugten String initialisiert. Der Konstruktor von StringBuffer erzeugt ein internes Array (also eine weitere Objektinstanz), um die Zeichenkette zu speichern. Immerhin ist dieses Array 16 Byte größer als eigentlich erforderlich, so daß der nachfolgende Aufruf von append das Array nicht neu allozieren und die Zeichen umkopieren muß. Schließlich wird durch den Aufruf von toString ein neues String-Objekt erzeugt und s zugewiesen. Auf diese Weise werden pro Schleifendurchlauf drei temporäre Objekte erzeugt, und der Code ist durch das wiederholte Kopieren der Zeichen im Konstruktor von StringBuffer sehr ineffizient.

Eine eminente Verbesserung ergibt sich, wenn die Klasse StringBuffer und ihre Methode append direkt verwendet werden:

001 String s;
002 StringBuffer sb = new StringBuffer(1000);
003 for (int i = 0; i < 20000; ++i) {
004   sb.append("x");
005 }
006 s = sb.toString();

Hier wird zunächst ein StringBuffer erzeugt und mit einem 1000 Zeichen großen Puffer versehen. Da die StringBuffer-Klasse sich die Länge der gespeicherten Zeichenkette merkt, kann der Aufruf append("x") meist in konstanter Laufzeit erfolgen. Dabei ist ein Umkopieren nur dann erforderlich, wenn der interne Puffer nicht mehr genügend Platz bietet, um die an append übergebenen Daten zu übernehmen. In diesem Fall wird ein größeres Array alloziert und der Inhalt des bisherigen Puffers umkopiert. In der Summe ist die letzte Version etwa um den Faktor 10 schneller als die ersten beiden und erzeugt 60000 temporäre Objekte weniger.

Ich gab dir sogar mein Wort, dass ich es getestet habe, sogar den Quellcode den du selbst testen konntest und du glaubst mir nicht.

Liebe Grüße
Real

[SIDEX]

Hallo alle zusammen

also ich habe gelesen und gelesen und habe hier immer noch keine antwort gefunden
mich würde auch interessieren womit ich anfangen soll C oder C++? was mich interessiert ist auch Linux, Netzwerk programmierung und Spiele Entwicklung.

was ist denn dafür besser? C oder C++?
was C/C++ angeht bin ich noch ein totaler anfänger und stehe vor der entscheidung womit ich anfangen soll. habe aber auch schon 2 jahre erfahrung in delphi (ich weiß ich weiß bin ein überläufer ) also ein totaler anfänger bin ich nicht.

mfg SIDEX

[Real]

Hi SIDEX,

SIDEX schrieb:

Hallo alle zusammen

also ich habe gelesen und gelesen und habe hier immer noch keine antwort gefunden
mich würde auch interessieren womit ich anfangen soll C oder C++? was mich interessiert ist auch Linux, Netzwerk programmierung und Spiele Entwicklung.

was ist denn dafür besser? C oder C++?
was C/C++ angeht bin ich noch ein totaler anfänger und stehe vor der entscheidung womit ich anfangen soll. habe aber auch schon 2 jahre erfahrung in delphi (ich weiß ich weiß bin ein überläufer ) also ein totaler anfänger bin ich nicht.

wenn du bei Linux Systemprogrammierung betreiben willst, dann ist ganz klar C angesagt, da Linux und die meisten Programme in C geschrieben sind.
Man kann sicher nichts falsch machen, wenn man mit C anfängt und sich später evtl. C++ anschaut und beide Vorteile kombiniert.

Liebe Grüße
Reality

[Gregor]

Real schrieb:

Man kann sicher nichts falsch machen, wenn man mit C anfängt und sich später evtl. C++ anschaut und beide Vorteile kombiniert.

Es gibt ja Leute in diesem Forum, die der Meinung sind, dass diese Reihenfolge den Stil versaut. Wenn man in dieser Reihenfolge lernt, dann wird es für den Lernenden schwer, in C++ nicht so wie in C zu programmieren. Das sollte man aber eigentlich gerade nicht tun. Wenn man es macht, sollte man lieber ganz auf C++ verzichten.

Insgesamt geht der Trend eher zu Sprachen, die stärker von der darunterliegenden Maschine abstrahieren. In Zukunft wird sicherlich immer weniger C benötigt werden.

[Mr. White]

@REAL: Man sollte aber die Programmierung nicht an _einer_ Sprache ausmachen! Ich habe von COBOL über SCHEME, c/c++ bis hin zu Java und VB schon mal alles im Einsatz gehabt(haben müssen ).

Du solltest Dir immer erst Dein Problem genau anschauen und danach die dafür geeigneteste Sprache auswählen! In Deinem jetzigem Fall wäre es c/c++.

Gregor schrieb:

Insgesamt geht der Trend eher zu Sprachen, die stärker von der darunterliegenden Maschine abstrahieren. In Zukunft wird sicherlich immer weniger C benötigt werden.

ACK

Grüssle

[Real]

Hallo Gregor,
das dürfte für uns kein Problem sein, da wir uns bei den schon mit OOP beschäftigt haben- er mit Delphi und ich mit Java (was ja C++ sehr ähnlich ist von der Syntax).
Und meine Java-Kenntnisse werde ich auch nicht gehen lassen, da
1. ich einen Vergleich haben und Erfahrung sammeln will
2. das mein zukünftiger Beruf vielleicht vorraussetzt
3. ich das in der Schule lerne.

@Mr. White:
Was heist ACK?

Liebe Grüße
Real

[Mr. White]

ACK = Acknowledge, Zustimmung

[rüdiger]

ACK == ACKnowledge (ist slang und kommt vom TCProtokoll :))

[gomberl]

@Real: lies dir doch bitte nochmal optimizers beitraege durch.
er sagt ja auch das + und += nicht gut sind weil sie ja im hintergrund auch stringbuffer objekte benutzen

ich stimme gregor nicht ganz zu
ich komme aus der prozeduralen welt und es hilft auch im OO bereich immer noch wenn man weiss was darunter liegt und wie das mit pointer funktioniert, was die v-table ist und wie die organisiert ist, wie man mit C auch OO programmieren kann und so weiter. also find ich basiswissen schon gut in C - aber allzu stark sollte man sich nicht reinsteigern. etwas assembler hilft hier sicher auch wesentlich staerker um die grundzuege des programm ablaufs zu verstehen

das man jetzt C statt C++ fuer systemprogrammierung benutzen soll, will ich mal ueberhoert haben.
C hat IMO gar keinen geschwindigkeitsnachteil (oder nur marginal) gegenueber C++. das bedeutet das ich sehr wohl C++ einsetzen kann und auch wenn es viele nicht glauben so ist ein gut geschriebenes OOP doch sehr performant und verkuerzt die entwicklungszeit (damit meine ich sinnvoll eingesetzte OO und nicht OO wo immer es geht - und hier noch ne klasse, da noch ne klasse, und noch 2000 interfaces)

gomberl

[Gregor@Uni]

gomberl schrieb:

ich stimme gregor nicht ganz zu
ich komme aus der prozeduralen welt und es hilft auch im OO bereich immer noch wenn man weiss was darunter liegt und wie das mit pointer funktioniert, was die v-table ist und wie die organisiert ist, wie man mit C auch OO programmieren kann und so weiter. also find ich basiswissen schon gut in C - aber allzu stark sollte man sich nicht reinsteigern. etwas assembler hilft hier sicher auch wesentlich staerker um die grundzuege des programm ablaufs zu verstehen

Da hast du mich etwas falsch verstanden. Ich habe nicht gesagt, dass man nicht wissen sollte, was tatsächlich abläuft. Ich bin der Meinung, dass man das wissen sollte. Allerdings denke ich auch, dass "C lernen" kein geeignetes Mittel ist, um sich dieses Wissen anzueignen. Ich habe weiter oben schon gesagt, was ich besser finden würde. Trotzdem geht der Trend zu Sprachen, die stärker von der Maschine abstrahieren, aus dem einfachen Grund, dass man Abstraktionsmechanismen benötigt, um die immer größer werdende benötigte Komplexität zu beherrschen. Diese Mechanismen werden auf Prozessoren und somit in maschinennahen Sprachen nicht direkt unterstützt.

Gregor@Uni

[Real]

Hi,

gomberl schrieb:

@Real: lies dir doch bitte nochmal optimizers beitraege durch.
er sagt ja auch das + und += nicht gut sind weil sie ja im hintergrund auch stringbuffer objekte benutzen

ich konnte folgendes lesen:

Wie du siehst, ist es eh vollkommen gleich, was du machst.

Liebe Grüße
Real

[Gast]

Du siehst aber nie die Ganzheit.

er sagt ja auch das + und += nicht gut sind weil sie ja im hintergrund auch stringbuffer objekte benutzen

Genau! Wenn du mehrere Strings ausgeben willst, so habe ich dir empfolen, dass über mehrere print-Aufrufe nacheinander zu machen. Das ist theoretisch die effizienteste Lösung.

Wenn du das nicht machst, dann ist es egal, ob du Strings mit '+' verknüpfst oder StringBuffer appendest.
Aber, wenn dir

kapitalAusgabe= kapitalAusgabe.append(i).append(". Jahr: ").append(preis).append(" € \n");

besser gefällt, oder du dich dabei besser fühlst, bitte. Jeder wie er will.

Und das Beispiel aus dem Buch passt nicht zum Thema. Die Frage ist, ob man schreiben soll

kapitalAusgabe= kapitalAusgabe.append(i).append(". Jahr: ").append(preis).append(" € \n");

oder

String x = bla + "bla" + ...;

Das ist eine völlig andere Situation. Ich habe dir die Java API Dokumentation zitiert und dem ist zu entnehmen, dass bei einer verkettung von Ausdrücken mit '+' ein temporärer String-Buffer erstellt wird.

Das Beispiel aus deinem Buch ist eine völlig andere Situation, da konvertierst du einen String erstmal implizit in einen StringBuffer, erstellst dann jedes mal einen neuen mit dem du appendest und wirfst den alten weg. Und am Ende wandelst du das wieder in nen String um.
Natürlich nimmt man für sowas gleich einen StringBuffer, weil es darum geht, eine Zeichenkette 93465792354mal zu verändern!

Das hat aber nichts mit der obigen Problematik zu tun, wo nur ein temp-Objekt erstellt wird, egal wie viele Sachen du anhängst. Und am Ende hast du einen schönen String der von den Vorteilen, die String gegenüber StringBuffer hat, profitiert.

"HauptFenster.java": Fehler #: 354 : Inkompatible Typen; java.lang.String wurde gefunden, java.lang.StringBuffer ist erforderlich in Zeile 211, Spalte 24

Häh? Woher soll ich jetzt wissen, was du gemacht hast, um diese Meldung zu bekommen?

[Real]

Hi,

Optimizer schrieb:

Natürlich nimmt man für sowas gleich einen StringBuffer, weil es darum geht, eine Zeichenkette 93465792354mal zu verändern!

davon redete ich doch die ganze Zeit! Bei großen und langen Auflistungen ist StringBuffer vorzuziehen.

Wenn du das nicht machst, dann ist es egal, ob du Strings mit '+' verknüpfst oder StringBuffer appendest.

Du liegst sowas von falsch! Ich habe den Unterschied ausprobiert und das Buch bestätigt mir, dass bei String eine Anhänung von "+" sehr viel langsamer ist, als mit StringBuffer mit append!

Lies noch einmal nach.

Liebe Grüße
Reality

[Helium]

Wenn es auf der Plattform, auf der ich arbeiten soll einen C und einen C++ Compiler gibt und ich die Freie Wahl habe bin ich doch nicht bekloppt und greife zu C. Egal, ob es um irgendwelche super Low-Level-Hardware-pur-Sachen geht, oder um irgendwas ganz weit abstrahiertestes.

Wenn ich will, kann ich doch jede C-Bibliothek verwenden. Wofür gibt's denn extern "C"? Auch sonst kann ich fast jeden C Code in C++ übersetzten, wenn er nicht gerade irgendwelche besonderheiten von C99 einsetzt. Viele C++-Compiler bieten Fähigkeiten von C99, obwohl sie nicht offizieller Teil von C++ sind (z.B. restricted, long long, ...)

und aus 'nem.

void foo ();

gegebenenfalls mal ein

void foo (...);

zu machen, oder ähnliches, damit der Compiler es frist, ist wohl auch nicht so das Problem.

Also Real: Solltest du vorhaben auf einer der Major-Plattformen (Windows, Linux, MacOS, *BSD, ...) zu arbeiten, dann ist es aus meiner sicht totaler Schwachsinn auf C zu setzten.

Und wegen der Frage, warum Unixe in C und nicht in C++ geschrieben sind: Der Code ist meist frei zugänglich. Du kannst dich also mal hinsetzten und aus dem prozeduralen design ein objektorientiertes machen.

[Gast]

Du liegst sowas von falsch! Ich habe den Unterschied ausprobiert und das Buch bestätigt mir, dass bei String eine Anhänung von "+" sehr viel langsamer ist, als mit StringBuffer mit append!

Ich gebe es auf. Du willst es einfach nicht einsehen, dass es das selbe ist!
Der Compiler generiert den selben Code!

Zu diesem Punkt habe ich bereits folgendes zitiert:

String buffers are used by the compiler to implement the binary string concatenation operator +. For example, the code:

x = "a" + 4 + "c"
is compiled to the equivalent of:

x = new StringBuffer().append("a").append(4).append("c").toString()

Dabei wird ein temporäres Objekt erzeugt.

Das Beispiel in deinem Buch behandelt eine andere Situation, als String x = "iulsdfg" + a + "uosgdf" + b; aber das willst du auch nicht einsehen.

Stattdessen leitest du von diesem unpassenden Beispiel ab

davon redete ich doch die ganze Zeit! Bei großen und langen Auflistungen ist StringBuffer vorzuziehen.

, was völliger Blödsinn ist. Wenn man keinen mutable String braucht, braucht man auch keinen Buffer zu nehmen, sondern kann das implizit über die Konkatenation mit '+' machen und anschließend mit einem imutable String arbeiten.
Und obendrein scheinst du gar nicht zu wissen, wie man Strings anwendet, ich kann mir die besagte Compilermeldung gar nicht anders erklären. Vielleicht machst du es völlig falsch, und deshalb ist es so langsam. Die Konstrukte in deinem Code schauen sowieso zum großen Teil mehr als seltsam aus.

Wie auch immer, du weisst sowieso alles besser, ignorierst Fakten bzgl. der Sprache Java und leitest aus einem unpassendem Beispiel, was am Thema vorbei ist, in irgendeinem Buch etwas absurdes her und lässt dir nichts sagen.
Viel Glück noch, wahrscheinlich wirst du es brauchen.

P.S. Und ja, du hast Recht, Java ist wirklich "der größte Müll", an deiner Stelle würde ich es lassen.