🚀 go-pugleaf

W dniu czwartek, 12 października 2017 01:22:45 UTC+2 użytkownik M.M. napisał:
> On Tuesday, October 10, 2017 at 9:31:03 AM UTC+2, Wojciech Muła wrote:
> > On Tuesday, October 10, 2017 at 3:35:56 AM UTC+2, bartekltg wrote:
> > > A na poważnie, dlaczego string ma być immutable? 
> > > Przecież moge chcieć tworzyć string literka po literce. 
> > 
> > Tu wracamy do tego, co napisałem na początku: C++ spieprzył
> > design stringa. (Chociaż ze string_view jest teraz trochę lepiej).
> > 
> > Powinny być osobne stringi immutable, osobne mutable, albo
> > lepiej buildery do stringów. Zauważ, że są różne sposoby
> > budowania napisów. Z mojej praktyki:
> > * doklejasz po jednym znaku;
> > * doklejasz inne stringi (np. sformatowane liczby);
> > * kasujesz podzakresy;
> > * zamieniasz jedne podciągi na inne;
> > * albo tylko zmieniasz literki (np. lowercase), bez zmiany długości
> > napisu.
> > 
> > Niestety, C++ upchnął za dużo odpowiedzialności w jedną klasę przez
> > co implementacja musi być generyczna, więc dla jednych scenariuszy
> > będzie szybka dla innych nie - i nie wiesz dla których. :)
> > 
> > A może w ogóle pomysł, żeby string musiał ciągłym obszarem pamięci
> > jest przesadą. Łatwiej byłoby przyjąć, że string to zbiór obszarów
> > pamięci. To się da łatwo ukryć za fasadą iteratora.
> > 
> > w.
> 
> Zazwyczaj to ja kroję włosa na czworo, ale teraz mam wrażenie, że to Wy
> kroicie :) String to string, ma być wygodny, nie nadaje się do pisania
> wyżyłowanych i wyspecjalizowanych implementacji.
> 

z tym ze ten wygodny string musi jakis byc,

jak bedzie taki to bedzie mialo jakies konsekwencje a jak bedzie inny bedzie mialo inne - nie znam za bardzo stringa z c++ ale na ile go znam to jest to string spieprzony, string w c (char*) tez jest spieprzony choc mniej

moja propozycja stronga w c padla, nazwalem go chunk
(jesli mowie o mijej implementacji bibliotecznej - jako wbudowany typ moglby miec predefiniowne wersje
np

chars txt = "ala ma kota";
//ew char[] txt = "ala ma kota";

to wyzej to niemal to samo co 

char* txt = "ala ma kota";

tylko ze txt nie jest jednym wskaznikiem a para wskaznikow i na koncu "ala ma kota" nie ma zera

(wskazniki sa dostepne przez txt.begin i txt.end 
jesli string jest realokowalny to mozna zmienic jego rozmiar przez przypisania size

txt.size += 10;

//itd

ten string moim zdaniem jest dosyc porzadny, dzili sie tez jak widac na dwie klasy nie tyle na mutable  i immutable co na resiziwalne i nieresizowalne (co prawda slowko na oznaczenie immutable tez by sie pewnie przydalo)

te ktore maja byc na stercie ja bym chyba robil dodajac slowo heap


heap chars txt;

tym ze satycznego ramu byc moze tez wartoby dac pewien zakers rozszeżalnosci, przez okreslenie folnego i gornego limitu 

chars(2 to 60) txt; czy cos w tym stylu ale tu nie jestem przekonany czy dokladnie tak (w tym wypadku wiadomo by bylo ze i tak zostanie zaalokowane 60 znakow wiec size ktore mialwaloby inne wartosci moze wydawac sie konfudujace ale tak naprawde takie size moglobybyc wygodne (zreszta takie hinty heapowi tez by sie przydaly, kwestia czy mozna robic takie resizowalne stringi na stosie zalezy od implementacji, te bez gornago limitu wydaje sie ze ewentualnie bez dodatkowego stosu chyba nie ale te z
limitami wydaje sie ze mozna nawet na jednym stosie - ( w wiekszosci wypadkow wydaje sie starcza stringi z limitami zwlaszcza na te stosie)