🚀 go-pugleaf

bartekltg wrote:

> Niby tak, ale w pewnym momencie trafiamy na poziom googlo facebooka
> i takie ilości serwerów już tak tanie nie są:)

Jak się już naprawdę inaczej nie da, to włączamy myślenie.

> Albo biolog napisał sibie na stringach przetwarzanie DNA i mi klaster zapycha...

Trzeba pisać grant o większy klaster. :-)

> A na poważnie, dlaczego string ma być immutable?

Bo zrobienie go mutable nie jest realne technicznie bez pójścia
na zgniłe kompromisy. Znając dokładną wielkość napisu można przydzielić
mu dokładnie tyle pamięci, ile potrzebuje, bez dodawania buforów na
przypadek rozszerzania. Wiedząc, że się nie zmieni można spróbować
zunifikować go z innymi stringami w systemie. Ich bywa dużo, a 
redundancja też bywa duża. Zyski potrafią być dramatyczne, bez
porównania do zabawek w rodzaju COW. Mogę go dać wątkom do przetwarzania
bez potrzeby blokowania, bo jakiś pacjent potencjalnie może dodać
mu literkę. Powodów jest mnóstwo i im bardziej "fejsbuczane" stają
się dane wejściowe, tym bardziej staje się to oczywiste. Ale sprawa
dotyczy nie tylko stringów, tylko wszelkich innych danych 
strumieniowych, np. LOBów.

> Przecież moge chcieć tworzyć string literka po literce.

Możesz chcieć. Literki możesz chcieć dodawać z obu stron -- mieliśmy
na to konkretne przykłady praktyczne. Standardowa implementacja wymaga
do tego czasu liniowego. Obustronnie rosnący kontener tak na wszelki 
wypadek? Beznarzutowo? Zapomnij, do budowania stringów służy 
specjalizowany builder.

> Mogę chcieć zrobić jakieś operacja na nim,
> std::sort czy std::next_permutation
> W tym wypadku będą(?) miał metodę która mi to wywala wynik
> jako string.

Ale to nie są standardowe potrzeby i albo będą wspierane byle jak
(tj. string -> builder -> string), albo zasługują na dedykowaną
implementację.

> std::string nie służy tylko do trzymania napisu, ale
> i przetwarzania, składania.

I to jest błąd na poziomie projektowym.

	Pozdrawiam, Piotr