3. C oder C++?

C oder C++?

  • ?

    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

    0
  • H

    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.

    0
  • ?

    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.

    0
  • ?

    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

    0
  • ?

    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

    0
  • G

    Real - in diesem fall hast du recht

    aber darueber redet Optimizer gar nicht

    lies nochmal seine antworten

    mehr sag ich nicht mehr - sinnlose diskussion

    0
  • ?

    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.

    0
  • ?

    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

    0
  • H

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

    0
  • H

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

    0
Anmelden zum Antworten