Gruß Chris

Viele Grüße,
Patrick

Deshalb kann und sollte man wohl ungehindert zu "fertigen" Lösungen greifen und zusehen, dass man seine Programme schnell funktionsfähig fertig bekommt

Hi, ich programmiere jetzt schon ne ganze Weile... Und hab mir immer eine Frage gestellt: Warum benutzten sehr viele Programm(deren Quellcode ich mir dann angesehen hab) immernoch char* mit den Funktionen aus string.h ?? Ich finde das ist viel aufwändiger, was es ja auch ist. Deshalb hab ich mich gefragt, ob die Klasse string vlt langsamer ist als char* + string.h? Z.b. das vergleichen von Werten ...strcmp oder string == string... Also was sagt ihr dazu ?

Gruß Chris

Meistens sind es doch alte Libraries und Programme die char* benutzen. Es gibt auf Desktop, Workstations und Servern wirklich keinen Grund groß mit char* zu hantieren. Ganz davon abgesehen, das char* auch noch keine Internationalisierung unterstützt, sondern nur ASCII, ist das einfach kurzsichtig gedacht. Wenn man schon keine Klassen benutzen will (weshalb auch immer), dann doch bitte wchar_t*, dann klappts wenigstens mit der Internationalisierung.

Um auf die String-Klasse zurück zukommen. Die Performance gleicht sich doch dann wieder aus, wenn man mit dem String arbeitet. Von Dummie wurde der Ctor-Aufwand genannt. Toll, ist das etwa die häufigste Situation die auftritt? Oder ist es nicht eher so, das ich einen String einmal erzeuge und ihn dann mehrmals bearbeite? Also das Verhältnis "Erstellen" zu "Bearbeiten" ist doch eher 1:n und nicht 1:1. Und die Bearbeitung eines String-Objektes ist meistens schneller, als die eines nullterminierten C-Strings. Wenn ich also Massenbearbeitung mache, sollte im Normalfall das String-Objekt gewinnen.

Nutzt doch einfach mal die C++-Möglichkeiten anstatt immer wieder auf C-Style zurück zu kommen. Wenn ihr sowieso Nachteile in den Objekten sieht, frag ich mich, warum man dann nicht einfach C programmiert? Sollte man sich doch einfach mal selber eingestehen. Oder sind das alles nur Vermutungen von Euch??? "Ja, also ein char* ist schneller, weil das ja alle benutzen." LOL

...Warum benutzten sehr viele Programm(deren Quellcode ich mir dann angesehen hab) immernoch char* mit den Funktionen aus string.h ??...

Ich glaube, das liegt an der sehr konservativen Einstellung ("Mach ich immer so - funktioniert doch.") vieler Programmierer. Bisweilen tarnt sie sich in "Kontrollwahn" ("Beim strcpy() weiß ich wenigstens, was passiert !"), aber das ist auch entweder nur mangelndes Wissen und/oder mangelnde Bereitschaft, Neues zu lernen. Diese Erfahrung mache ich relativ häufig (und tw. auch von mir selbst), dass man einen gewissen Satz an "Standardtechniken" zur Hand hat, die man immer wieder nutzt - und sich immer weniger Gedanken darüber macht, ob es bessere Techniken gibt.

Schlimm wird es, wenn dieser "programmiertechnische Werkzeugkasten" in die fachliche Definition einfließt - da gab es so manches sehr negative Erlebnis (eines liegt mir nach Jahren noch im Magen .... bzw. auf der täglichen "Erklärliste").

Gruß,

Simon2.

P.S.: Es gibt auch nicht wenige, die "C mit C++-Compiler" programmieren....

Da gibt es schon die Möglichkeit Operatoren zu überladen, aber dann geht nicht mal sowas.

int main() {
	int nr = 11112;
	std::string txt = "Die Zahl ist: ";
	txt += nr;

	std::cout<<txt;
	return 0;
}

Da muss man dann wieder aufwendig mit streams rummachen, um ne Zahl zu konvertieren.

Ein bisschen mehr komfort wäre schon nicht schlecht.

Ich kann deshalb einfach nur empfehlen Boost zu benutzen. Boost sollte man sowieso auf auf seiner Platte haben, nicht nur wegen Strings:
http://www.boost.org/libs/libraries.htm#String

Der std::string ist ja auch nicht wirklich toll. Es gibt keine einfachen Funktionen wie toLower, toUpper, replaceAll usw. die mit dem ganzen String arbeiten.

Ja, die STL-Klassen sind keine eierlegende Wollmilchsau (irgendwo habe ich mal gelesen, daß std::string selbst in der jetzigen Version zu umfangreich ist). Aber da kommt die Zusammenarbeit der STL-Komponenten ins Spiel - Stichwort "Algorithmen"

Da gibt es schon die Möglichkeit Operatoren zu überladen, aber dann geht nicht mal sowas.

int main() {
	int nr = 11112;
	std::string txt = "Die Zahl ist: ";
	txt += nr;

	std::cout<<txt;
	return 0;
}

Da muss man dann wieder aufwendig mit streams rummachen, um ne Zahl zu konvertieren.

Einen C-Programmierer stört es nicht, aufwendig mit sprintf() und strcat() rumzumachen, um Zahlen umwandeln zu können, aber von C++ erwartet er, daß alles mit einem Einzeiler erledigt werden kann Falls dich der explizite Umgang mit Stringstreams stört, kannst du ihn doch auch in einer Hilfsfunktion auslagern (oder vorhandene Funktionen ala boost::lexical_cast<> nutzen).

Also, es ist nicht ganz so komplex.

Noch das toUpper:

string str1("HeLlO WoRld!");
    to_upper(str1); // str1=="HELLO WORLD!"

Also, ich weiß ja nicht... string sollte man eher nicht benutzen. Voll unkomfortabel.

Was wäre denn so schlimm, wenn der + Operator für Zahlen richtig überladen wäre? Wieso muss sich jeder Programmierer sein replaceAll wieder neu schreiben?

Artchi schrieb:

int main() {
    int nr = 11112;
    std::string txt = "Die Zahl ist: ";

    txt += lexical_cast<string>(nr);

    std::cout << txt;
    return 0;
}

Also, es ist nicht ganz so komplex.

Noch das toUpper:

string str1("HeLlO WoRld!");
    to_upper(str1); // str1=="HELLO WORLD!"

Also, ich weiß ja nicht... string sollte man eher nicht benutzen. Voll unkomfortabel.

error C2065: 'lexical_cast': nichtdeklarierter Bezeichner
error C3861: 'to_upper': Bezeichner wurde auch mit einer argumentbezogenen Suche nicht gefunden

Ich hab kein boost auf meiner Platte und es ging ja auch um die STL.

Die Frage war, warum viele bei char* bleiben und nicht std::string nehmen. Da finde ich schon, dass es eine Rolle spielt, wie komfortabel die neue API ist, die ich lernen muss. Wenn man merkt, dass man alle möglichen Funktionen zusätzlich lernen muss anstatt einfache intuitive Methoden zu haben, dann fragen sich sicher manche wieso man jetzt den std::string nehmen soll.

Inwieweit sind die String-Methoden denn unintuitiver als C's char*-Funktionen? (bzw, wie intuitiv sind die char*-Funktionen an sich?)

Was wäre denn so schlimm, wenn der + Operator für Zahlen richtig überladen wäre? Wieso muss sich jeder Programmierer sein replaceAll wieder neu schreiben?

Wozu neu schreiben? Für sowas gibt es Zusatzbibliotheken (btw, in vielen Fällen reicht std::replace() oder std::transform() auch für String-Operationen aus.

Was den op+ für Zahlen angeht: In welchem Format soll der deiner Meinung nach die Zahl umwandeln? (dezimal? hexadezimal? binäre Repräsentation? ...) Wenn du da eine bestimmte Form vorgibst, findest du sofort jemanden, der etwas anderes braucht.

Was wäre denn so schlimm, wenn der + Operator für Zahlen richtig überladen wäre?

Was ist denn "richtig"? Welches Zahlensystem? Welche Genauigkeit? Welche Ausrichtung? Gerade bei Fließkommatypen gibt es sehr viele Möglichkeiten, eine Zahl als Text darzustellen. Die Umwandlung ist nunmal nicht eindeutig, daher gibt es auch kein "richtig".

Man kann natürlich den vermeintlich einfachsten Fall durch den Operator abdecken. Aber dann muss man für alle anderen Fälle eine ganz andere Vorgehensweise anwenden. Das ist IMHO schlimmer.

Stimmt natürlich, dass die char* funktionen nicht intuitiver sind, aber ich will doch was besseres, wenn ich schon wechsle.

Format für Zahlen ist natürlich Dezimal. Anzahl der Nachkommastellen 2. Wer was anderes braucht nimmt eine Methode wie string.appendNumber(nr, format, ...). Man kann doch den + Operator so überladen, dass es den meisten normal Usern passt und für den Rest gibts noch ne andere Funktion.

Wenn die API einem mehr Komfort bringen würde, dann würden sie vielleicht auch mehrere lernen wollen. Am besten wäre es natürlich wenn man so gut wie nichts lernen muss, sondern wenn die Methoden so intuitiv sind, dass man sie automatisch verwendet, was bei den meisten Stringfunktionen und ner guten IDE möglich wäre.

Stimmt natürlich, dass die char* funktionen nicht intuitiver sind, aber ich will doch was besseres, wenn ich schon wechsle.

Also besser als die char*-Funktionen ist std::string auf jeden Fall (z.B. mußt du dich nicht um die Speicherverwaltung und ähnliche Belange kümmern)

Format für Zahlen ist natürlich Dezimal. Anzahl der Nachkommastellen 2. Wer was anderes braucht nimmt eine Methode wie string.appendNumber(nr, format, ...). Man kann doch den + Operator so überladen, dass es den meisten normal Usern passt und für den Rest gibts noch ne andere Funktion.

Meinst du wirklich, jeder User teilt deine Meinung, was "normal" ist? Ich habe eine Klasse lieber kompakter und bin dafür flexibler in der Art, wie ich sie nutzen kann (selbst wenn ich dafür gelegentlich einen kleinen Umweg gehen muß).

PS: Wenn du jetzt anfängst, **** zu erwähnen, schieße ich den Thread ab.

...Es gibt keine einfachen Funktionen wie toLower, toUpper, replaceAll usw. die mit dem ganzen String arbeiten. ...geht nicht mal sowas.
...

Finde ich vollkommen gut !
Was Du da beschreibst, sind "Datentransformationen", wie sie prima in <algorithm> verallgemeinert sind, Eigenschaften der char_traits sind oder Typenkonversionen (locales und Formatierungseigenschaften spielen auch noch rein) sind.

Da bekäme man letztlich eine "extrem fette Klasse", die mit zahllosen Aufgaben überfrachtet wird, die immer weniger mit der eigentlich Aufgabe (Buchstabencontainer) zu tun haben - und letztlich wird man immer wieder etwas vermissen, wenn man erstmal anfängt, immer mehr Fachfremdes reinzupfropfen. Wer unter "Komfort" versteht "Egal um welche Aufgabe es geht, ich will nur die Methoden einer Klasse ansehen müssen.", hat eine falsches Verständnis vom Programmieren.

Die StdLib bietet eine Menge Komfort ... aber eben als "Gesamtkunstwerk" und nicht in Form von fetten Klassen.

Ja, die string-Klasse ist nicht toll ... aber nicht weil sie zu schmal, sondern weil sie zu fett (und mehrdeutig) ist.

Gruß,

Simon2.

Wenn die API einem mehr Komfort bringen würde, dann würden sie vielleicht auch mehrere lernen wollen. ...

Aha - sichere, kürzere und übersichtlichere Programme sind für Dich kein "Komfort ?

Das Lustige ist ja, dass Du gleichzeitig beklagst, man müsse "so viel lernen" ... aber gleichzeitig 87 neue Methoden für std::string forderst:

• Überleg Dir mal in Ruhe, wieviel Parameter (und seien sie getarnt in einem Formatstring - das ist nämlich auch nichts Anderes) oder Varianten von "appendNumber()" es geben muss, wenn Du wirklich ALLE Formen von Darstellungsmöglichkeiten abdecken möchtest.
• Und dann überleg Dir mal, was davon wirklich mit "string" oder mit "Nummer" zu tun hat - üblicherweise fast nichts. Z.B. ob man einen 1000er-Punkt oder Komma oder gar nichts haben möchte, eine Exponentialform, Nachkommastellen, führende Nullen, Basis, .... gehören doch viel eher in den Bereich der "Darstellung" und ggf. der Lokalisierung -> Themen die für alles Andere von den Streams abgedeckt werden, soll man nochmal (oder schlimmer noch: Teilweise hier, teilweise dort) in den Strings implementieren ?
• Und schließlich: Soll man für eigene Typen dann einen ganz anderen Weg beschreiten ? Wenn ich meine eigene Zahlklasse schreibe (myBigInt) klappt alles überhaupt nicht mehr ? Oder läuft ganz anders ? Und wenn ich ein template schreiben möchte, das für myBigInt UND für int arbeiten soll ? ...

Gruß,

Simon2.

Das Lustige ist ja, dass Du gleichzeitig beklagst, man müsse "so viel lernen" ... aber gleichzeitig 87 neue Methoden für std::string forderst:

Das was sie am String falsch gemacht haben ist hierbei vielleicht auch mit entscheidend: Sie hätten mehr Funktionen unabhängig von der Stringklasse halten (nicht alles ist in einer Klasse sinnvoll), und die Zusatzfunktionen dann vielleicht Themensortiert in eigene Header verteilen sollen.

Sowas kann er sich aber auch selbst bauen. Was ich zugeben muss ist, das die Algorithmen manchmal nicht auf den ersten Blick einen auffallen, und die STL nicht unbedingt durch ihre einfache Bedienung glänzt.

Aber man muss immer Kompromisse machen:
Möglichst generisch und flexibel oder einfach, dafür zumeist nicht so gut zu erweitern.

Die STL ist mächtig, aber auch in Teilen so komplex das es leicht ist sie falsch zu verwenden.

cu André

Meinst du wirklich, jeder User teilt deine Meinung, was "normal" ist? Ich habe eine Klasse lieber kompakter und bin dafür flexibler in der Art, wie ich sie nutzen kann (selbst wenn ich dafür gelegentlich einen kleinen Umweg gehen muß).

Bei dezimal würde ich jetzt mal sagen, dass mir da über 95% zustimmen. 2 Nachkommastellen hab ich jetzt einfach mal so gesagt, kann man ja schauen, was am häufigsten gebraucht wird. Ich hätte lieber eine Klasse die etwas mehr enthält, anstatt jedesmal den Umweg gehen zu müssen.

Simon2 schrieb:

Da bekäme man letztlich eine "extrem fette Klasse", die mit zahllosen Aufgaben überfrachtet wird, die immer weniger mit der eigentlich Aufgabe (Buchstabencontainer) zu tun haben - und letztlich wird man immer wieder etwas vermissen, wenn man erstmal anfängt, immer mehr Fachfremdes reinzupfropfen. Wer unter "Komfort" versteht "Egal um welche Aufgabe es geht, ich will nur die Methoden einer Klasse ansehen müssen.", hat eine falsches Verständnis vom Programmieren.

Wenn man den String als Buchstabencontainer sieht dann passt das wohl. Ich finde ein String ist mehr. Der basic_string hat ja schon compare, replace, find..., sowas könnte man dann ja auch in andere algorithm Funktionen auslagern. Meiner Meinung nach sind toUpper und toLower Basisfunktionen für nen String. replaceAll würde ich auch noch dazu nehmen, muss ja nicht mit Regulärenausdrücken sein.

Simon2 schrieb:

naja schrieb:

Wenn die API einem mehr Komfort bringen würde, dann würden sie vielleicht auch mehrere lernen wollen. ...

Aha - sichere, kürzere und übersichtlichere Programme sind für Dich kein "Komfort ?

Was ist denn an

txt += lexical_cast<string>(nr);

sicherer und kürzer als an

txt += nr

?

Das Lustige ist ja, dass Du gleichzeitig beklagst, man müsse "so viel lernen" ... aber gleichzeitig 87 neue Methoden für std::string forderst:

Ich will Mehtoden die intuitiv sind und nicht etwas wie std::transform usw.

• Überleg Dir mal in Ruhe, wieviel Parameter (und seien sie getarnt in einem Formatstring - das ist nämlich auch nichts Anderes) oder Varianten von "appendNumber()" es geben muss, wenn Du wirklich ALLE Formen von Darstellungsmöglichkeiten abdecken möchtest.
• Und dann überleg Dir mal, was davon wirklich mit "string" oder mit "Nummer" zu tun hat - üblicherweise fast nichts. Z.B. ob man einen 1000er-Punkt oder Komma oder gar nichts haben möchte, eine Exponentialform, Nachkommastellen, führende Nullen, Basis, .... gehören doch viel eher in den Bereich der "Darstellung" und ggf. der Lokalisierung -> Themen die für alles Andere von den Streams abgedeckt werden, soll man nochmal (oder schlimmer noch: Teilweise hier, teilweise dort) in den Strings implementieren ?
• Und schließlich: Soll man für eigene Typen dann einen ganz anderen Weg beschreiten ? Wenn ich meine eigene Zahlklasse schreibe (myBigInt) klappt alles überhaupt nicht mehr ? Oder läuft ganz anders ? Und wenn ich ein template schreiben möchte, das für myBigInt UND für int arbeiten soll ? ...

Wie ist es den beim konvertieren mit streams gelöst? Im Grunde ist es bei meinem Vorschlag so ähnlich, was die Parameter an geht. Was machst du bei dem streams mit deinem byBigInt? Warum lagert man sowas in stringstream aus?

CStoll schrieb:

Meinst du wirklich, jeder User teilt deine Meinung, was "normal" ist? Ich habe eine Klasse lieber kompakter und bin dafür flexibler in der Art, wie ich sie nutzen kann (selbst wenn ich dafür gelegentlich einen kleinen Umweg gehen muß).

Bei dezimal würde ich jetzt mal sagen, dass mir da über 95% zustimmen. 2 Nachkommastellen hab ich jetzt einfach mal so gesagt, kann man ja schauen, was am häufigsten gebraucht wird. Ich hätte lieber eine Klasse die etwas mehr enthält, anstatt jedesmal den Umweg gehen zu müssen.

Simon2 schrieb:

Da bekäme man letztlich eine "extrem fette Klasse", die mit zahllosen Aufgaben überfrachtet wird, die immer weniger mit der eigentlich Aufgabe (Buchstabencontainer) zu tun haben - und letztlich wird man immer wieder etwas vermissen, wenn man erstmal anfängt, immer mehr Fachfremdes reinzupfropfen. Wer unter "Komfort" versteht "Egal um welche Aufgabe es geht, ich will nur die Methoden einer Klasse ansehen müssen.", hat eine falsches Verständnis vom Programmieren.

Wenn man den String als Buchstabencontainer sieht dann passt das wohl. Ich finde ein String ist mehr. Der basic_string hat ja schon compare, replace, find..., sowas könnte man dann ja auch in andere algorithm Funktionen auslagern. Meiner Meinung nach sind toUpper und toLower Basisfunktionen für nen String. replaceAll würde ich auch noch dazu nehmen, muss ja nicht mit Regulärenausdrücken sein.

Der Vorteil der STL ist ihre Flexibilität - indem solche Aufgaben in Algorithmen ausgelagert werden, können sie auf alles angewendet werden, was ein paar einfache Grundvoraussetzungen erfüllt (ich muß für eine eigene String-Klasse die ganzen genannten Funktionen nicht neu schreiben, sondern kann mich darauf verlassen, daß std::transform() auch meine CS_string's in Kleinbuchstaben wandeln kann).

Wie ist es den beim konvertieren mit streams gelöst? Im Grunde ist es bei meinem Vorschlag so ähnlich, was die Parameter an geht. Was machst du bei dem streams mit deinem byBigInt? Warum lagert man sowas in stringstream aus?

Streams haben Manipulatoren und Formatflags, mit denen man die Ausgabeformate einstellen kann (klingt kompliziert, aber wenn du es erstmal verstanden hast, ist es ganz intuitiv anwendbar). Und sie bieten die Möglichkeit der Arbeitsteilung - das zu schreibende Objekt weiß, wie es dargestellt werden will (indem es die IO-Operatoren überlädt), der Streambuffer weiß, was er mit der Textform der Ausgabedaten anfangen soll und der Stream kümmert sich darum, daß beide vernünftig miteinander reden können).

...Der basic_string hat ja schon compare, replace, find...,

Schlimm genug !
Was machen denn eigentlich Chinesen mit toUpper() ?
Für mich bleibt es dabei: Groß-/Kleinschreibung hängt am Zeichensatz und nicht am string.

naja schrieb:

...
Was ist denn an

txt += lexical_cast<string>(nr);

sicherer und kürzer als an

txt += nr

?

In diesem Thread ging es ursprünglich nicht um den Vergleich zwischen std::string und "naja-Strings" ( ), sondern um den zwischen std::string und char*-Verwendung - und genau darauf bezog sich meine Aussage "std::string haben gegenüber char* den Vorteil ("Komfort"), kürzer, sicherer und übersichtlicher zu sein".
Habe ich vielleicht nicht ganz klar ausgedrückt und ist jetzt hoffentlich klarer.

naja schrieb:

...
Ich will Mehtoden die intuitiv sind und nicht etwas wie std::transform usw....

Wie kann man die Transformation von Daten den "intuitiver" ausdrücken als über "transform()" ?
Prinzipiell verstehe ich schon, was Du meinst, aber ich denke, dieser Ansatz hält dem Praxistest nicht stand, weil das Feld deutlich komplexer ist als Du Dir das so spontan denkst.
Diese Erfahrung haben ja schon die StdLib-Designer mit string gemacht: Erst denkt man "Ist doch ganz einfach: Einfach eine Funktion, die das macht - ist doch jedem klar, wie das arbeitet." ... und plötzlich ist "Schluß mit intuitiv", weil man in der Flut an "Ist-doch-ganz-einfach"-Funktionen untergeht. Hast Du Dir mal angesehen, wie viele "find()s" string hat und weißt Du "intuitiv", wie die arbeiten ?
Herb Sutter (kein schlechter Mensch) hat einen recht interessanten Artikel über die Nachteile der fetten string-Klasse geschrieben und behauptet, dass das tatsächliche Problem eben genau das ist: Die Klasse ist nicht mehr intuitiv, weil sie total überfrachtet ist mit Dingen, die eigentlich gar nicht in sie hinein gehören.

...
Wie ist es den beim konvertieren mit streams gelöst? Im Grunde ist es bei meinem Vorschlag so ähnlich, was die Parameter an geht. Was machst du bei dem streams mit deinem byBigInt? ...

Streams sind ein Konzept von Datenquellen und -senken mit einer klaren einheitlichen Schnittstelle für alle dahinter versteckten "Datenpools".
Man "klinkt" sich über operator<<() und operator>>() ein, kann Manipulatoren definieren oder bestehende nutzen und den Fehlerstatus einheitlich feststellen - ganz unabhängig davon, mit welchem Datenpool man arbeitet.
Der C++-Standard bietet für spezielle (meist verwendete und am leichtesten zu verallgemeinernde) "Datenpools" bereits Implementationen zur Verfügung (File, Konsole, String). Ich wüsste nicht, was daran unübersichtlich oder inkonsequent sein sollte.
Man kann sich problemlos selbst streams für seine eigenen Datenpools (Netzwerk, Scanner/Drucker, Faxgerät, ...) definieren, die sich exakt gleich verhalten wie die der StdLib...

Mal eine Frage: Kann es sein, dass Du schon mal Java programmiert hast ?

Gruß,

Simon2.

1. eine andere String-Klasse benutzen.
2. die Sprache wechseln.

Alles andere ist nur sinnloses rumgeheule, weil sich dadurch die Situation NICHT ändern wird. Mehr als das Konzept zu erklären kann man hier in diesem Forum auch nicht machen. Alles was darüber hinaus geht, ist vergoldete wertvolle Zeit.

Artchi schrieb:

Alles was darüber hinaus geht, ist vergoldete wertvolle Zeit.

Sehr schön.

chrische

Mal eine Frage: Kann es sein, dass Du schon mal Java programmiert hast ?

Ja.

Es gibt aber auch in C++ z.B. den MFC CString der ein MakeUpper/Lower und Format hat.

Ist ja auch egal. Der std::string bleibt so wie er ist und damit auch so "beliebt" wie er ist.

Also ich nutze ihn und das viele GUI-Frameworks ihn nicht nutzen, hat wohl eher was mit deren Alter zu tun.

chrische