21.3.1 basic_string constructors schrieb:

In all basic_string constructors, a copy of the Allocator argument is used for any memory allocation performed by the constructor or member functions during the lifetime of the object.

Der eine Allokator soll also für den kompletten Speicher zuständig sein - das beist sich aber ein wenig mit meinem Ansatz, dass der User das verwendete Array selbst heraussuchen kann.
Dann braucht man für c_str() ja bekanntlich noch einen anderen container...
Ist die Lösung damit noch Standard-Konform? Bzw. gibt es eine Möglichkeit, dass der vector den selben(nicht den gleichen^^) allocator nutzt, wie die deque?

template<
	typename TChar,
	typename traits = std::char_traits<TChar>,
	typename TAlloc = std::allocator<TChar>,
	typename array_type = std::deque<TChar, TAlloc>
>
struct basic_string
{
	struct _m
	{
		array_type content;
		mutable std::vector<value_type, allocator_type> c_str_content;
	} m;

	const char* c_str() const
	{
		m.c_str_content.reserve(size()+1);
		m.c_str_content.assign(begin(), end());
		m.c_str_content.push_back(value_type());

		return &*m.c_str_content.begin();
	}
};

Dann hab ich noch eine Frage zu assign() : Ich habe nirgendwo gefunden, dass bei assign kein zweites Objekt erstellt werden darf und dann einfach geswapt werden darf(also wird das ja mit Sicherheit die bevorzugte Lösung sein - würdet ihr das reserve(size()+1) dann trotzdem lassen oder eher weglassen oder einen anderen weg gehen?

Danke schon mal,
bb

Der eine Allokator soll also für den kompletten Speicher zuständig sein - das beist sich aber ein wenig mit meinem Ansatz, dass der User das verwendete Array selbst heraussuchen kann.
Dann braucht man für c_str() ja bekanntlich noch einen anderen container...
Ist die Lösung damit noch Standard-Konform? Bzw. gibt es eine Möglichkeit, dass der vector den selben(nicht den gleichen^^) allocator nutzt, wie die deque?

Wahrscheinlich nicht. Wenn du dich gleichzeitig ein wenig am Entwurf des neuen Standards orientierst, wirst du erkennen, das alles andere als ein normales Array für die Speicherverwaltung sowieso eher unerwünscht sein dürfte.

unskilled @logged-off schrieb:

Dann hab ich noch eine Frage zu assign() : Ich habe nirgendwo gefunden, dass bei assign kein zweites Objekt erstellt werden darf und dann einfach geswapt werden darf(also wird das ja mit Sicherheit die bevorzugte Lösung sein - würdet ihr das reserve(size()+1) dann trotzdem lassen oder eher weglassen oder einen anderen weg gehen?

Das sollte zulässig sein, im nächsten Standard sowieso (der bestimmt explizit swap(str) als zulässige Implementation für den move-Fall). Einen Vorteil sehe ich darin nicht (wenn man sowieso kopieren muss): wenn der Speicher des ursprünglichen Strings ausreicht, sollte die Wiederverwendung dieses Speichers effizienter sein. Bedenke, das sowieso nur Typen mit einfacher Kopiersemantik als Zeichentypen zulässig sind, im Gegensatz zum allgemeinen Fall brauchen wir uns hier keine Gedanken um Exceptionsicherheit beim normalen Kopieren machen, denn das kann nicht fehlschlagen.

Bedenke, das sowieso nur Typen mit einfacher Kopiersemantik als Zeichentypen zulässig sind, im Gegensatz zum allgemeinen Fall brauchen wir uns hier keine Gedanken um Exceptionsicherheit beim normalen Kopieren machen, denn das kann nicht fehlschlagen.

Guter Hinweis, danke

Naja - der einzige richtige Nachteil sind imho die traits-Fkt.
vor allem find() - da weiß ich noch gar nicht, wie ich das mache...

bb

aber ich hab noch ne Frage zu find_first_of bzw. find:

21.3.6.3 basic_string::find_first_of schrieb:

7.:

size_type find_first_of ( charT c , size_type pos = 0) const
{
 return find_first_of( basic_string<charT,traits,Allocator>(1,c),pos );
}

was ist der Unterschied dieser Fkt und der find-Überladung:

size_type find(charT c , size_type pos = 0) const;

?

Ich konnte keinen finden...

bb

Siehe sonst auch http://www.gotw.ca/gotw/084.htm...

unskilled @logged-off schrieb:

was ist der Unterschied dieser Fkt und der find-Überladung:

Ich habe das gefunden:

<a href= schrieb:

http://www.cplusplus.com/reference/string/string/find/">Notice that unlike member find_first_of, whenever more than one character is being searched for, it is not enough that only one of these characters match, but the entire sequence of characters to find must be matched.

BTW: Hast du dein Passwort vergessen und das der E-Mail-Adresse ebenfalls? :p

BTW: Hast du dein Passwort vergessen und das der E-Mail-Adresse ebenfalls? :p

LOL. Ich habe im anderen Thread fast das gleiche gefragt. :p

zum 1. link - japp, kannte ich schon - aber wenns so nunmal so standardisiert wurde...

zum 2. link (was du gefunden hattest):
wenn mich nicht alles täuscht, steht dort auch kein unterschied sondern nur, dass es unterschiedliche ergebnisse liefert, sobald nicht nur ein zeichen übergeben wird!?

bb

— at(xpos+I) == str.at(I) for all elements I of the string controlled by str

...

— at(xpos) == str.at(I) for some element I of the string controlled by str.

Wenn I nur 0 sein kann, weil der entsprechende String nur ein Zeichen hat, kann es offenbar keinen Unterschied geben. Diese Überladungen existieren offensichtlich nur der Vollständigkeit halber beide als degenerierte Versionen des allgemeinen Falls.

— at(xpos+I) == str.at(I) for all elements I of the string controlled by str

...

— at(xpos) == str.at(I) for some element I of the string controlled by str.

Wenn I nur 0 sein kann, weil der entsprechende String nur ein Zeichen hat, kann es offenbar keinen Unterschied geben. Diese Überladungen existieren offensichtlich nur der Vollständigkeit halber beide als degenerierte Versionen des allgemeinen Falls.

danke

im Gegensatz zu den 100den von find-Fkt, die lediglich traits_type::eq() ist die string-compare-fkt so definiert:

standard schrieb:

int compare(const basic_string &str) const
{
const size_type rlen = std::min(size(), str.size()); //1 Effects: Determines the effective length rlen of the strings to compare as the smallest of size() and str.size().
return traits_type::compare(data(), str.data(), rlen); //The function then compares the two strings by calling traits::compare(data(), str.data(), rlen).
}

standard schrieb:

[traits::compare]
yields: 0 if for each i in [0,n), X::eq(p[i],q[i]) is true; else, a negative value if, for some j in [0,n), X::lt(p[j],q[j]) is true and for each i in [0,j)
X::eq(p[i],q[i]) is true; else a positive value.

traits::compare ist also über eq bzw lt definiert.
ist es nun noch standard-konform, wenn man die string-compare-fkt nicht mittels der traits-compare-fkt sondern direkt mit eq implementiert?

bb

traits::compare ist also über eq bzw lt definiert.

Das betrifft aber nur die Ermittelung des Rückgabewertes. Eine nutzerdefinierte traits-Klasse könnte durchaus in diesen Funktionen noch anders beobachtbares Verhalten zusätzlich einbauen. Mit anderen Worten: im Standardfall char_traits<char>, char_traits<wchar_t> kannst du machen, was du willst, ansonsten ist es problematisch.

unskilled schrieb:

traits::compare ist also über eq bzw lt definiert.

Das betrifft aber nur die Ermittelung des Rückgabewertes. Eine nutzerdefinierte traits-Klasse könnte durchaus in diesen Funktionen noch anders beobachtbares Verhalten zusätzlich einbauen. Mit anderen Worten: im Standardfall char_traits<char>, char_traits<wchar_t> kannst du machen, was du willst, ansonsten ist es problematisch.

Das ich das in diesen beiden Fällen machen kann, hab ich auch schon geschlussfolgert.
Schade - ich hatte gehofft, dass du irgend ne Stelle so deutest, dass man einen dem standard entsprechenden traits-typ angeben muss^^

Fällt jemandem ein Fall ein, wo es sinnvoll ist, dass jmd. ein compare schreibt, welches nicht dem standard-compare entspricht? Mir ist vorhin keiner eingefallen und jetzt auch noch nicht

bb