std::string encoding

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

dot

keines...

Youka

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.

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?).

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

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?

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.

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 = '!';

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.

SeppJ schrieb:

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

Ohne bad_alloc?