std::string encoding

[Nathan]

std::string ist nichts anderes als ein vector<char>, der speziell auf Zeichenketten spezialisiert ist und ein paar Komfortfunktionen hat die keiner braucht (find_last_not_of()? wtf?).

[bjarne stroustrup55]

Nathan schrieb:

std::string ist nichts anderes als ein vector<char>, der speziell auf Zeichenketten spezialisiert ist und ein paar Komfortfunktionen hat die keiner braucht (find_last_not_of()? wtf?).

Nicht ganz, der C++-String hat eine Optimierung für kleine Längen.

[bjarne stroustrup55]

bjarne stroustrup55 schrieb:

Nathan schrieb:

std::string ist nichts anderes als ein vector<char>, der speziell auf Zeichenketten spezialisiert ist und ein paar Komfortfunktionen hat die keiner braucht (find_last_not_of()? wtf?).

Nicht ganz, der C++-String hat eine Optimierung für kleine Längen.

Siehe hier: http://john-ahlgren.blogspot.de/2012/03/small-string-optimization-and-move.html

[Sone]

find_last_not_of()? wtf?

Also ich habe das bereits einige Male gebraucht. Ich sehe nicht ein wieso du das so pauschal runtermachen musst. PI war auch der Meinung, std::string habe zu viele Member - ...

Welches encoding wird laut Standard für std::string verwendet?

Das ist nicht die richtige Frage. std::string macht nämlich nichts Encoding-spezifisches. Daher wäre eine richtige Antwort: Es unterstützt alle.

Vielleicht meinst du auch das interne Encoding mit dem bspw. Zeichenkettenliterale encodet werden...

[Nathan]

PI?
Ich persönlich habe das noch nie gebraucht. Und werde es seit den regulären Ausdrücken vermutlich noch weniger brauchen.

[SeppJ]

bjarne stroustrup55 schrieb:

Nicht ganz, der C++-String hat eine Optimierung für kleine Längen.

Nein. Er hat möglicherweise Optimierungen für Zeichenketten, welche möglicherweise auch eine Optimierung für kurze Längen sein kann.

[Sone]

SeppJ schrieb:

bjarne stroustrup55 schrieb:

Nicht ganz, der C++-String hat eine Optimierung für kleine Längen.

Nein. Er hat möglicherweise Optimierungen für Zeichenketten, welche möglicherweise auch eine Optimierung für kurze Längen sein kann.

Bzw. die Implementierung eines std::string hat die Optimierungen. Denn der C++-String aus dem Standard hat keine. Nur vielleicht eine Implementierung von GCC/VC++ und Konsorten.

[muh]

SeppJ schrieb:

Er hat möglicherweise Optimierungen für Zeichenketten, welche möglicherweise auch eine Optimierung für kurze Längen sein kann.

Welche andere Optimierung wäre denn noch denkbar?

[Nexus]

Sone schrieb:

PI war auch der Meinung, std::string habe zu viele Member

Ja, und da ist er nicht ganz alleine. Das Interface von std::string ist eine Katastrophe.

http://www.gotw.ca/gotw/084.htm

[Sone]

Nexus schrieb:

Sone schrieb:

PI war auch der Meinung, std::string habe zu viele Member

Ja, und da ist er nicht ganz alleine. Das Interface von std::string ist eine Katastrophe.

Dem habe ich nicht widersprochen. find_first_not_of muss aber für Strings in irgendeiner Weise spezialisiert werden, weil es möglich sein sollte es mit einem String-Literal o.ä. aufzurufen.

Das es an std::string gekoppelt ist ist natürlich doof. Eigentlich sollte das für jeden Container gehen, und eine Überladung für char / char16_t /... als Wertetyp ist auch nicht schwer. Nur finde ich es wiederum praktisch, eine Variante in std::string zu haben die auch Bequem für Strings aufzurufen ist.

Ein find_last_not_of wie dieses hier*

template<typename BidirectionalIterator,
         typename ForwardIterator,
         typename ValueT>
BidirectionalIterator find_last_not_of( BidirectionalIterator first,
							         	BidirectionalIterator last,
								        ForwardIterator first2,
								        ForwardIterator last2 )
{
	auto iter = last;

	for(;;)
	{
		if( iter == first )
			break;

		if( std::find(first2, last2, *--iter) != last2 )
			return iter;
	}

	return last;
}

ist mit Strings umständlicher zu bedienen.

std::string str("ABCDEFGHIJ");
char const ptr[] = "AEIOU"; 
auto iter = find_last_not_of( std::begin(str), std::end(str), std::begin(ptr), std::end(ptr) );

(anstatt

std::string str("ABCDEFGHIJ");
auto pos = str.find_last_not_of("AEIOU");

)

Es stimmt jedoch, diese Bequemlichkeit kompensiert die Unflexibilität nicht.

~* Ich konnte nicht widerstehen. Ungetestet.~

[Sone]

Meine Güte, habe ich Sehstörungen? Ich dachte, knivil hätte den Post oben geschrieben...es war Nexus. habe ich irgendeine Leseschwäche?

[kmp]

Also wenn std::string schon eigene Memberfunktionen hat, dann sollen die gefälligst auch optimiert sein (KMP und so). Stattdessen sind sie die unnötigsten Brute-Force-Implementierungen (siehe Sone), die eigentlich besser über reverse_iterator + find_first_not_of implementiert wären.

[SeppJ]

muh schrieb:

SeppJ schrieb:

Er hat möglicherweise Optimierungen für Zeichenketten, welche möglicherweise auch eine Optimierung für kurze Längen sein kann.

Welche andere Optimierung wäre denn noch denkbar?

Optimierung auf die Zeichenketten "Hello World!", "Foo", "Bar" und 252 weitere.

[muh]

SeppJ schrieb:

Optimierung auf die Zeichenketten "Hello World!", "Foo", "Bar" und 252 weitere.

Wie willst du das machen?

std::string s = "Foo";
char *c = &s[1];
*c = '!';

[supersonic]

Youka schrieb:

std::string hält Charaktere als char Array, womit diesen jeweils 1 Byte zur Verfügung steht. Wie dieser nun verwendet wird ist im Standard nicht definiert, wobei man für Windows ANSI und für Unix UTF-8 annehmen könnte anhand der Ausgabe durch OS API Funktionen.

Und wie kann man dann ein File mit
fstream (const string& filename, ios_base::openmode mode = ios_base::in | ios_base::out);
richtig öffnen?
Muss ich meine strings Betriebsystem spezifisch konvertieren?

[SeppJ]

muh schrieb:

SeppJ schrieb:

Optimierung auf die Zeichenketten "Hello World!", "Foo", "Bar" und 252 weitere.

Wie willst du das machen?

std::string s = "Foo";
char *c = &s[1];
*c = '!';

Die Optimierung merkt natürlich, sobald eine non-const Memberfunktion aufgerufen wird und schaltet dann in den normalen Modus.

[muh]

SeppJ schrieb:

Die Optimierung merkt natürlich, sobald eine non-const Memberfunktion aufgerufen wird und schaltet dann in den normalen Modus.

Ohne bad_alloc?

[Sone]

kmp schrieb:

die eigentlich besser über reverse_iterator + find_first_not_of implementiert wären.

Weil du dann Sechs Zeilen Code weniger schreiben musst? Weil es flexibler ist? Aber ich sehe da nur den Umstand, das literarische Programmieren aufzugeben. Der Funktionsname sollte doch schon möglichst für sich sprechen.

[SeppJ]

muh schrieb:

SeppJ schrieb:

Die Optimierung merkt natürlich, sobald eine non-const Memberfunktion aufgerufen wird und schaltet dann in den normalen Modus.

Ohne bad_alloc?

Klar doch! Es ist keine Platzoptimierung. Die Zeichenkette wird ganz normal gespeichert. Und noch ein weiteres Byte, das anzeigt, ob es sich um eine bekannte Sequenz handelt. Bloß die ganzen Suchmemberfunktionen sind optimiert und benutzen einen Lookup-Table für die optimierten Fälle.

[muh]

SeppJ schrieb:

muh schrieb:

SeppJ schrieb:

Die Optimierung merkt natürlich, sobald eine non-const Memberfunktion aufgerufen wird und schaltet dann in den normalen Modus.

Ohne bad_alloc?

Klar doch! Es ist keine Platzoptimierung. Die Zeichenkette wird ganz normal gespeichert. Und noch ein weiteres Byte, das anzeigt, ob es sich um eine bekannte Sequenz handelt. Bloß die ganzen Suchmemberfunktionen sind optimiert und benutzen einen Lookup-Table für die optimierten Fälle.

std::string s = "Foo";
std::string t = "Foo";
char *c = &s[1]; // s welchselt in normalen Modus
std::cout << (s == t) << '\n'; // s checkt sich selber erneut nach jedem der 255 Magic-Strings!?