C oder C++?

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

[Real]

Hallo Optmizer,
String macht nur bedingt dasselbe, das wollte ich dir mit meinem Beispiel erklären.
Vielleicht kapierst du es, wenn ich es anhand deinem Beispiel erkläre:

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

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

Mal davon abgesehen, dass String neue Objekte erstellt, würde das in einer Schleife (wie in meinem Fall) sehr viel langsamer laufen.

Komm bitte jetzt nicht mit einem knallroten Kopf an, sondern schaue mein Beispiel an:

Wie du schon erwähnt hast, ist dieser Code

x = "a" + 4 + "c";

nichts anderes als das:

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

Würde ich das in eine Schleife beispielsweise so setzen, sieht das folgendermasen aus:

for(int i=0; i<=1000; i++)
{
x = new StringBuffer().append("a").append(4).append("c").toString();
}
System.out.println(x);

Diese Methode würde es bei jedem Schleifendurchlauf jedes mal in String umwandeln.

Diese Methode, wandelt es jedoch nur einmalig in String um:

for(int i=0; i<=1000; i++)
{
x = new StringBuffer().append("a").append(4).append("c");
}
System.out.println.(x.toString());

Wie in dem Javabuch beschrieben, ist der letzte Code effizienter, da eine Umwandlung nur einmalig stattfindet, außerdem muss nicht jedes Mal ein neues Objekt erstellt werden wie bei String.

Ich hoffe du hast mich jetzt verstanden, ansonsten beende ich mit dir das Thema.

Liebe Grüße
Real

[Real]

Achja und vergiss bitte nicht, dass die Praxis, die ich ausprobiert habe meine Theorie beweist, da kannst du noch so rot anlaufen und mich beschimpfen.
Wie gesagt, den Code habe ich gepostet, führe mein Code in StringBuffer aus (ist ja schon so implementiert) und später ersetze alle StringBuffer mit String und du merkst den Unterschied. (Nimm dazu die hohen Werte, die ich dir gepostet habe. Mit String über eine Minute, mit StringBuffer unter 5 Sekunden und das sogar mit höheren Werten.).

Liebe Grüße
Reality

[gomberl]

Real - in diesem fall hast du recht

aber darueber redet Optimizer gar nicht

lies nochmal seine antworten

mehr sag ich nicht mehr - sinnlose diskussion

[Gast]

Roter Kopf? Ne.
Zum Thema: Ich wiederhole mich gern (oder auch nicht) zum dritten mal. Ich sag dir doch, dass das Beispiel im Buch zwar so schon richtig ist. Aber wenn es um String x = "uiasdgf" + 93746 + a; geht, ist das eine andere Situation.
Ich hoffe, du begreifst das jetzt, weil ich hab an deinem Code kritisiert, dass du genau so eine Situation aufwändig und hässlich mit StringBuffern implementierst, in der Überzeugung, dass das schneller ist.
Ich habe nie gesagt, dass das Beispiel in deinem Buch falsch ist, sondern dass es hier einfach nicht zutrifft.

Ich hoffe, das ist jetzt endlich rübergekommen, amsonsten hat das jetzt echt keinen Sinn mehr.

[Real]

Gut, in diesem Fall ja. Aber eben nicht bei Schleifen.
Ich sagte ja, dass man StringBuffer am Besten dazu verwendet, wenn man riesen Texte aneinandergehängt da man das am Besten mit Schleifen realisiert und bei Schleifen verwendet man besser StringBuffer.

Habe mich wohl oft ungenau ausgedrückt und dich manchmal sogar missverstanden, sorry.

Bei einfachen Dingen verwende ich ebenfalls String.

Liebe Grüße
Real

[Helium]

Da fragt man sich doch ernsthaft, wieso in einem Thread namens C oder C++ darüber diskutiert wird, wie man in Java am besten mit Strings umgeht. Das verwirrt mich jetzt ein wenig.

[hohesC]

Das nennt man ersetzen ohne zusätzlichen unnützen Overhead.