STL oder nicht
-
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.
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?
-
naja schrieb:
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).
-
naja schrieb:
...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 antxt += 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.
-
Wer std::transform nicht intuitiv findet, hat halt noch kein C++ gelernt. Es ist ein Konzept und eine Philosophie die im C++-Standard genutzt wird. Man kann es nicht gut finden, aber man sollte auch nicht wollen, das dieses jetzt anderes sein soll. Weil es steht nunmal fest geschrieben und Punkt! Wem es nicht gefällt, hat zwei Möglichkeiten:
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.
-
Hallo
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.
-
Hallo
Also ich nutze ihn und das viele GUI-Frameworks ihn nicht nutzen, hat wohl eher was mit deren Alter zu tun.
chrische
-
Au mann^^ Hätte nie gedacht dass das Thema STL so eine umfangreiche Diskussion auslöst! Aber danke! Jetzt weiß ich mehr über die STL als je zuvor
Gruß Chris
-
naja schrieb:
Mal eine Frage: Kann es sein, dass Du schon mal Java programmiert hast ?
Ja....
Dacht' ich mir's doch.
Aber mal zurück zur Ausgangsfrage: Ich glaube nicht, dass diejenigen, die unter C++ Stringverarbeitung über char* betreiben, durch die Vorbehalte, die Du gegenüber std::string hast, von dessen Nutzung abgehalten werden.
Sie mögen Dir dazu dienen, Java (oder was auch immer) besser zu finden als C++ ... aber dass aus diesen Gründen irgendjemand (Dich eingeschlossen) lieber mit char* programmiert, halte ich für unwahrscheinlich (oder nur die Riesenausnahme).Gruß,
Simon2.
-
naja schrieb:
Ich will Mehtoden die intuitiv sind und nicht etwas wie std::transform usw.
Niemand sagt dass du jedesmal std::transform benutzen sollst, sondern dass damit deine upcase Implementation sagenhaft kurz und intuitiv wird.