3. C++ Bibliotheken im Umfang wie Java?

C++ Bibliotheken im Umfang wie Java?

  • A

    lololer schrieb:

    GUI im Standard, LOL. Der std::string ist schon grottig genug, so dass jede Lib nen anderen verwendet.

    Falsch. Der std::string mag nicht der Weisheit letzter Schluß sein, das eigentliche Problem ist aber eher das die UI-Frameworks ÄLTER als std::string sind.

    0
  • S

    lololer schrieb:

    ...std::string ist schon grottig genug, so dass jede Lib nen anderen verwendet.

    DAS ist ja mal eine sehr exotische Lesart. 😮 🤡

    Ich bin wahrlich nicht der Meinung, dass std::string optimal (oder nur "gut") definiert ist - aber die "Alternativen", die mir bislang begegnet sind
    - haben dieselben Schwächen,
    - zusätzlich neue und
    - sind oftmals älter und deutlich stärker an "char*"-Handling orientiert.

    Es wird schon einen Grund haben, warum sich keine dieser ach so tollen Alternativen wirklich als "Quasistandard" durchgesetzt haben... :p

    Gruß

    Simon2.

    0
  • ?

    Also zB über den QString kann ich nicht meckern. Wesentlich angenehmer zu benutzen als std::string und hat natürlich eine ganze latte mehr an features.

    0
  • Administrator

    KuhTee schrieb:

    Also zB über den QString kann ich nicht meckern. Wesentlich angenehmer zu benutzen als std::string und hat natürlich eine ganze latte mehr an features.

    Eine ganze Latte mehr an Features, welche grundsätzlich gar nichts mit einem String zu tun haben. QString ist völlig überladen an Features, die Klasse ist nicht sauber in ihre Aufgaben aufgetrennt.

    Im übrigen wäre es mir neu, dass QString wirklich mehr Features unterstützt, als die C++ Standardbibliothek an Möglichkeiten anbietet. C++ verteilt eben diese Möglichkeiten nur auf die std::basic_string Klasse, die Algorithmen, die basic_istream und basic_ostream Klassen, usw. usf ...

    Grüssli

    0
  • ?

    Dravere schrieb:

    KuhTee schrieb:

    Also zB über den QString kann ich nicht meckern. Wesentlich angenehmer zu benutzen als std::string und hat natürlich eine ganze latte mehr an features.

    Eine ganze Latte mehr an Features, welche grundsätzlich gar nichts mit einem String zu tun haben. QString ist völlig überladen an Features, die Klasse ist nicht sauber in ihre Aufgaben aufgetrennt.

    Im übrigen wäre es mir neu, dass QString wirklich mehr Features unterstützt, als die C++ Standardbibliothek an Möglichkeiten anbietet. C++ verteilt eben diese Möglichkeiten nur auf die std::basic_string Klasse, die Algorithmen, die basic_istream und basic_ostream Klassen, usw. usf ...

    Bei der komischen Philosophie hätten sie sich std::string gleich sparen können und std::vector<char> nehmen können. Diese "String ist nur ein Container und alle Funktionen sind wo anders"-Idee ist doch nur Chaos.

    0
  • D

    9 schrieb:

    Bei der komischen Philosophie hätten sie sich std::string gleich sparen können und std::vector<char> nehmen können. Diese "String ist nur ein Container und alle Funktionen sind wo anders"-Idee ist doch nur Chaos.

    Also std::string kann schon ein bischen mehr als std::vector. Es gibt sogar Leute, die finden, dass er viel zu viel kann 😉

    Die "komische Philosophie" finde ich persönlich manchmal schwerer verständlich bzw. durchschaubar. Derart designte Libs mögen stärker von einer guten Dokumentation abhängen oder eine steilere Lernkurve haben. Trotzdem gibt es gute Argumente dafür, nicht alle nur denkbaren Funktionen direkt in eine Klasse zu packen. Ich würde das nicht von vornherein verteufeln.

    Stefan.

    0
  • P

    9 schrieb:

    Bei der komischen Philosophie hätten sie sich std::string gleich sparen können und std::vector<char> nehmen können. Diese "String ist nur ein Container und alle Funktionen sind wo anders"-Idee ist doch nur Chaos.

    std::string hat noch sehr viel (zu viel) mehr Funktionalität als std::vector, z.B. die ganzen substring-Geschichten und so weiter.

    0
  • O

    9 schrieb:

    Bei der komischen Philosophie hätten sie sich std::string gleich sparen können und std::vector<char> nehmen können. Diese "String ist nur ein Container und alle Funktionen sind wo anders"-Idee ist doch nur Chaos.

    Nein, vector<char> ist sicher nicht die richtige Lösung. Aber dass es in die Richtung geht, dass string nur ein Container ist, ist sicherlich nicht schlecht. Meiner Meinung nach sollte ein guter String ein auf verschiedene Zeichensätze optimierter Container sein. Ach was red ich da, einer? Mehrere! Für verschiedene Anforderungen verschiedene Strings! Der random access String, bei dem ich selbst mit utf8 noch super Zeichen rumschubsen kann gegen den cstring der für die C Anbindung den Speicher am Stück vorhält. Und da alle komplexere Funktionalität wie substring Bildung ausgelagert ist, kann jeder seine eigene Stringklasse einfach hinzufügen und von dem bereits fertigen Code profitieren.

    0
  • N

    Ich denke mal, es wäre noch interessant gewesen, std::string mehr als Adapter denn als eigener Container zu konzipieren. Als normalerweise unterliegenden Container könnte man std::vector nehmen, momentan ähnelt std::string dem sowieso ziemlich. Aber zum Beispiel wenn man eine grössere Datei in einen String einlesen will, würde sich die Datenstruktur von std::deque wohl besser eignen. So wäre man diesbezüglich etwas flexibler und nicht an ein dynamisches Array gebunden.

    0
  • D

    Nexus schrieb:

    Ich denke mal, es wäre noch interessant gewesen, std::string mehr als Adapter denn als eigener Container zu konzipieren. Als normalerweise unterliegenden Container könnte man std::vector nehmen, momentan ähnelt std::string dem sowieso ziemlich. Aber zum Beispiel wenn man eine grössere Datei in einen String einlesen will, würde sich die Datenstruktur von std::deque wohl besser eignen. So wäre man diesbezüglich etwas flexibler und nicht an ein dynamisches Array gebunden.

    Ohne zu wissen, wie std::deque implementiert ist, gehe ich mal davon aus, dass es sich eben nicht um ein dynamisches Array handelt 😉

    Wenn man aber std::string nicht als Array implementiert, handelt man sich mEn damit zu viele Nachteile ein. Z.B. müsste man für c_str() den String kopieren. Wohin? Was ist mit konkurrierenden Zugriffen? Auch find() und Konsorten wären wohl weniger effizient.

    Außerdem ist das Einlesen ganzer Dateien nicht unbedingt etwas, das man mit std::string (effizient) machen können sollte (oder gar muss). Das ist irgendwie kein typischer Anwendungsfall für die Klasse. Dann hätte ich schon lieber die Möglichkeit, std::string billig kopieren zu können (copy on write).

    Stefan.

    0
  • P

    Nexus schrieb:

    Ich denke mal, es wäre noch interessant gewesen, std::string mehr als Adapter denn als eigener Container zu konzipieren. Als normalerweise unterliegenden Container könnte man std::vector nehmen, momentan ähnelt std::string dem sowieso ziemlich. Aber zum Beispiel wenn man eine grössere Datei in einen String einlesen will, würde sich die Datenstruktur von std::deque wohl besser eignen. So wäre man diesbezüglich etwas flexibler und nicht an ein dynamisches Array gebunden.

    Klingt nach einem interessanten Ansatz, mit dem man mal etwas rumexperimentieren könnte *notier*.

    0
  • N

    DStefan schrieb:

    Ohne zu wissen, wie std::deque implementiert ist, gehe ich mal davon aus, dass es sich eben nicht um ein dynamisches Array handelt 😉

    Ich meinte damit auch eher std::vector . 😉
    std::deque ist normalerweise als Array von Arrays implementiert.

    DStefan schrieb:

    Wenn man aber std::string nicht als Array implementiert, handelt man sich mEn damit zu viele Nachteile ein. Z.B. müsste man für c_str() den String kopieren. Wohin? Was ist mit konkurrierenden Zugriffen? Auch find() und Konsorten wären wohl weniger effizient.

    Daran habe ich vorher auch gedacht, besonders an c_str() . Doch wann braucht man c_str() ? Hauptsächlich, um Kompatibilität zu C-Schnittstellen zu ermöglichen (nebenbei für den Dateinamen bei std::fstream ). Also lange nicht immer. Braucht man immer Random-Access für Strings? Wohl auch nicht. Die Default-Implementierung wäre dann wie bisher nutzbar, aber für spezielle Ansprüche eignet sich vielleicht eine andere Datenstruktur besser, und dann kann man auch deren Nachteile in Kauf nehmen.

    Dynamische Arrays sind einfach sehr schlecht, was Einfügungen/Löschungen in der Mitte oder am Anfang angeht. Die Reallokation bei grosser Anzahl Elemente ist ebenfalls nicht gerade schnell (auch wenn das oft vernachlässigt werden kann). Stell dir einen String vor, der als verkettete Liste programmiert ist. Du kannst nun wahnsinnig einfach und performant sämtliche Vorkommen eines Teilstrings durch einen anderen ersetzen. Wenn bei einem dynamischen Array nicht beide gleich gross sind, handelt man sich unter Umständen massive Performancenachteile ein.

    pumuckl schrieb:

    Klingt nach einem interessanten Ansatz, mit dem man mal etwas rumexperimentieren könnte *notier*.

    Könnte ich bei Gelegenheit eigentlich auch mal ausprobieren... Wenn wir ein paar Resultate haben, könnten wir darüber auch nochmals ausführlicher diskutieren, wäre sicher spannend. Ich muss allerdings schauen, momentan habe ich noch einige andere Dinge vor. 🙂

    0
  • ?

    Nexus schrieb:

    Stell dir einen String vor, der als verkettete Liste programmiert ist. Du kannst nun wahnsinnig einfach und performant sämtliche Vorkommen eines Teilstrings durch einen anderen ersetzen.

    Dafür deutlich mehr (>2x) Speicherverbrauch. Denn zu jedem char muss man noch nen pointer auf den nächsten speichern. Und wenn man nicht massive Performance-Probleme bekommen will, wenn man von hinten durch den String iteriert, muss man noch nen zweiten Pointer auf das vorherige Element speichern. wohlgemerkt, pro char!

    0
  • N

    CHARming schrieb:

    Dafür deutlich mehr (>2x) Speicherverbrauch. Denn zu jedem char muss man noch nen pointer auf den nächsten speichern. Und wenn man nicht massive Performance-Probleme bekommen will, wenn man von hinten durch den String iteriert, muss man noch nen zweiten Pointer auf das vorherige Element speichern. wohlgemerkt, pro char!

    Ja, das ist eben der Preis. Für die meisten Fälle lohnt es sich wohl nicht und ein dynamisches Array eignet sich am besten. Das heisst ja nicht, dass es nicht auch manchmal anders sein kann. Zudem gibt es ja noch std::deque als Zwischenlösung.

    0
  • ?

    DStefan schrieb:

    Z.B. müsste man für c_str() den String kopieren. Wohin?

    class KasFString
{
        vector<char> stringdata;
    public:
        const char* c_str() const { return &stringdata[0]; }
};

    Wo liegt das Problem dabei ?

    0
  • V

    pumuckl schrieb:

    Nexus schrieb:

    Ich denke mal, es wäre noch interessant gewesen, std::string mehr als Adapter denn als eigener Container zu konzipieren. Als normalerweise unterliegenden Container könnte man std::vector nehmen, momentan ähnelt std::string dem sowieso ziemlich. Aber zum Beispiel wenn man eine grössere Datei in einen String einlesen will, würde sich die Datenstruktur von std::deque wohl besser eignen. So wäre man diesbezüglich etwas flexibler und nicht an ein dynamisches Array gebunden.

    Klingt nach einem interessanten Ansatz, mit dem man mal etwas rumexperimentieren könnte *notier*.

    Ich experimentiere derzeit damit herum. Soll mal ein Webserver werden. Socket liest in eine Queue<char>. Strings wird es so gar nicht geben, nur Container (Ranges, die ihre Elemente besitzen) und Ranges(, die ihre Elemente nicht be4sitzen). Bis eine Anfrage abgearbeitet ist, wird einfach in der Queue der Speicher nicht gepoppt, womit alle "Strings" ohne Kopieren auskommen, bis am Ende zu send(), was dann kopieren darf, wenn der Speicher in zu kleinen Happen rumliegt und sendfile(), was kopieren muß, wenn der Dateiname zufällig auf zwei Seiten verteilt ist (beides dürfte eher selten vorkommen). Bin noch gar nicht weit, aber der Ansatz fühlt sich GUT an.

    0
  • D

    KasF schrieb:

    DStefan schrieb:

    Z.B. müsste man für c_str() den String kopieren. Wohin?

    class KasFString
{
        vector<char> stringdata;
    public:
        const char* c_str() const { return &stringdata[0]; }
};

    Wo liegt das Problem dabei ?

    Lies mal Nexus' Posting. Er wollte gerade nicht den String als dynamisches Array repräsentiert haben.

    Stefan.

    0
  • ?

    DStefan schrieb:

    Lies mal Nexus' Posting. Er wollte gerade nicht den String als dynamisches Array repräsentiert haben.

    Ok, danke.

    0
  • T

    @DStefan
    ich denke unter "dynamischem array" verstehen die meisten ein auf dem heap angelegtes array (new[]) und kein std::vector / std::deque / ....

    Simon

    0
  • D

    theta schrieb:

    @DStefan
    ich denke unter "dynamischem array" verstehen die meisten ein auf dem heap angelegtes array (new[]) und kein std::vector / std::deque / ....

    Simon

    Aber genau das macht std::vector doch. Vielleicht sollte man "verwaltetes dynamisches Array" sagen?

    Stefan.

    0
Anmelden zum Antworten