Guter Stil oder Overhead?

knivil

hmmmm schrieb:

Warum erhöht es die Abhängigkeit zwischen Komponenten, wenn ich eine toUpper-Methode in eine String-Klasse stecke? Warum sollte ich weniger Abhängigkeiten haben, wenn ich eine freie Funktion toUpper(string) habe?

Du hast toUpper von der Stringklasse entkoppelt und kannst Spezialisierungen fuer andere Stringklassen anbieten, ja selbst fuer std::vector<char> std::array<char, 15> oder char -Arrays, die selbst keine Klassen sind. Und mit Templates musst du toUpper wahrscheinlich nur einmal implementieren.

Nexus

Etwas ausführlicher:
Dr Dobbs: How Non-Member Functions Improve Encapsulation

knivil schrieb:

hmmmm schrieb:

Warum erhöht es die Abhängigkeit zwischen Komponenten, wenn ich eine toUpper-Methode in eine String-Klasse stecke? Warum sollte ich weniger Abhängigkeiten haben, wenn ich eine freie Funktion toUpper(string) habe?

Du hast toUpper von der Stringklasse entkoppelt und kannst Spezialisierungen fuer andere Stringklassen anbieten, ja selbst fuer std::vector<char> std::array<char, 15> oder char -Arrays, die selbst keine Klassen sind. Und mit Templates musst du toUpper wahrscheinlich nur einmal implementieren.

Wie frage ich std::vector<char> nochmal nach seinem Encoding?

cooky451

Wie fragst du denn std::string?

Ja, toUpper funktioniert hier nur, wenn man Information-Hidding verletzt und annimmt, man weiß wie der String seine Daten intern hält.

cooky451

Irgendwie verstehe ich nicht, worauf du gerade hinaus willst.

knivil

hmmmm schrieb:

Wie frage ich std::vector<char> nochmal nach seinem Encoding?

Gar nicht. Die Unterstuetzung fuer Utf in C++ ist nicht besonders gut. Aber deswegen kannst du trotzdem eine Klasse UtfString definieren und toUpper dafuer spezialisieren, die das Encoding abfragt.

Ja, toUpper funktioniert hier nur, wenn man Information-Hidding verletzt und annimmt, man weiß wie der String seine Daten intern hält

Wie du siehst, kann das am Typ festgemacht werden. Und warum sollte ich den verstecken?

ist glaub ich sinnlos weietr zu machen.

otze

hmmmm schrieb:

Ja, toUpper funktioniert hier nur, wenn man Information-Hidding verletzt und annimmt, man weiß wie der String seine Daten intern hält.

ähh...nein? Iteratoren?

ähh...nein! Encoding weiterhin undefiniert.

Utf8String Utf16String Utf32String kommen gleich vorbei...

otze

aber das Encoding kennt std::string ja selbst nicht. Ich würde ja jetzt sagen: "locale fragen" aber das geht nicht, wenn du UTF8-kodierst. std::string ist nicht für variable-breite zeichen ausgelegt. UTF-32 (mit unsigned int als char_t) würde aber gehen. Also: richtigen Stringtyp verwenden und dann locale fragen(und facets implementieren). Oder auf wchar_t hoffen und locale fragen. Unter Unixoiden funktioniert das sogar.

Ethon

Ist es nicht offensichtlich, welches Encoding verwendet wird?

ASCII ist ein Subset von UTF-8, also kann man wohl bei jedem 8bit-string annehmen, dass er UTF-8 kodiert ist.
Bei einem 16bit-Typen gehe ich von UTF-16 aus, analog dazu von UTF-32 bei 32bit.

Ein Denkfehler dabei?

otze

Ja, das 8Bit eben nicht UTF-8 bedeutet. Es kann auch zum Beispiel ein beliebiger erweiterter ASCII sein wie unter einigen Systemen üblich. Es muss nicht einmal ASCII kompatibel sein.