C++ Bibliotheken im Umfang wie Java?

[Tippgeber]

DStefan schrieb:

mad_martin schrieb:

@DStefan:

Für den Markt? Wer bitte macht denn C++ für "den Markt"? Wer will damit Geld verdienen? Microsoft? Die verweisen für sowas auf DotNet. Borland? Die haben ihre VCL.

Ich frage mich ernsthaft, was du mit "für den Markt" meinst.

Es gibt mehr Märkte als die, auf denen man Geld verdient. Und ich habe in meinem Beitrag auch überhaupt nicht vom Geldverdienen gesprochen.

Sondern von Nachfrage nach bestimmten Eigenschaften (im weitesten Sinne) von Programmiersprachen, sowie dem Maß, in dem C++ Standard-Libs diese Nachfrage meines Erachtens befriedigen/berücksichtigen.

Ich dachte wirklich, ich hätte mich klar genug ausgedrückt...

Stefan.

Dann wäre es aber sinnvoller diese Bibliotheken als getrennte ISO Standards zu definieren, so können Compiler-Hersteller diese Bibliotheken implementieren, wenn sie wollen. Dazu dann in den Standard aufnehmen wie ein Programm per Präprozessor feststellen kann ob die gewünschte Bibliothek vorhanden ist.

[nullArgument]

pumuckl schrieb:

Wozu eine GUI-Bibliothek in den Standard einer Sprache aufnehmen, wenn von den darin entwickelten Anwendungen bei weitem nicht jede eine GUI hat/braucht?

Wozu Sprachmittel wie goto in eine Sprache aufnehmen, wenn bei weitem nicht jede Anwendung diese braucht? Ist doch egal wenn ein paar Anwendungen die Klassen nicht nutzen, dann werden sie eben nicht dazu gelinkt. Es ist halt einfach ein Graus in C++, dass ich für jeden Standardmist verschiedene Bibliotheken brauch (und mich um die Installation beim Kunden kümmern muss).

[Nexus]

nullArgument schrieb:

Wozu Sprachmittel wie goto in eine Sprache aufnehmen, wenn bei weitem nicht jede Anwendung diese braucht? Ist doch egal wenn ein paar Anwendungen die Klassen nicht nutzen, dann werden sie eben nicht dazu gelinkt.

Es besteht ein kleiner Unterschied zwischen goto und einem GUI-Framework. Erstens besteht goto hauptsächlich aufgrund der Kompatibilität zu C, wirklich oft angewandt wird es in modernem C++ nicht (das gilt für einige Sprachmittel). Zweitens ist es ein Sprach- und kein Bibliotheksfeature. Erstere kann man nicht oder nur kompliziert nachrüsten, während Bibliotheken auch nachträglich programmiert werden können.

Davon abgesehen hat C++ nicht den Anspruch, eine Standardbibliothek mit so vielen Features anzubieten. Leider basieren viele Vergleiche von Programmiersprachen auf oberflächlichem Feature-Abzählen. Welchen Sinn hat es, wenn sich C++ wie C# oder Java entwickelt? Dafür gibt es ja diese Sprachen. Die Stärken von C++ liegen woanders, und in diese Richtung bewegt sich auch der neue Standard. Meiner Meinung nach ist das hauptsächlich die Programmiersprache selbst. Genauer gesagt meine ich Konzepte, die einem einen effektiven Einsatz der Sprache ermöglichen - ohne sich dabei auf ein spezifisches Anwendungsgebiet wie GUI oder lineare Algebra zu beschränken. Zum Beispiel Templates, die können überall eingesetzt werden. Oder RValue-Referenzen, um ein Feature von C++0x zu nennen.

Natürlich wäre es nützlich, man hätte in C++ eine standardisierte GUI. Ich selber würde das auch sehr schätzen. Aber ganz so einfach ist das nicht umzusetzen, allein schon der Standardisierungsprozess. Man sieht ja, wie lange es mit C++0x dauert. Und das liegt nicht an der Unfähigkeit der Entwickler, sondern daran, dass C++ um viele Technologien erweitert wird, die noch nicht so stark erforscht wird und deshalb genau abgewägt werden (Concepts wurden beispielsweise vorläufig entfernt, weil man nichts überstürzen will, aber endlich mal ein neuer Standard herauskommen soll). Bei all dem ist es wohl kein triviales Unterfangen, etwas derart Plattformabhängiges wie GUI in den Standard aufzunehmen. Alleine schon der Gedanke, wie die einzelnen Bestandteile (z.B. Widgets) vom Standard genau definiert werden sollen, damit auch verschiedene Implementierungen zum ungefähr gleichen Ergebnis führen, macht mir etwas zu schaffen.

[lololer]

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

[asc]

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.

[Simon2]

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.

[KuhTee]

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.

[Dravere]

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

[9]

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.

[DStefan]

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.

[pumuckl]

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.

[otze]

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.

[Nexus]

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.

[DStefan]

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.

[pumuckl]

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

[Nexus]

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.

[CHARming]

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!

[Nexus]

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.

[Gast]

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 ?

[volkard]

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.