🚀 go-pugleaf

On Thursday, October 12, 2017 at 2:42:29 PM UTC+2, (fir) wrote:
> z tym ze ten wygodny string musi jakis byc,
No musi. 


> jak bedzie taki to bedzie mialo jakies konsekwencje a jak bedzie 
> inny bedzie mialo inne - 
Owszem.


> nie znam za bardzo stringa z c++ ale na ile go znam to jest 
> to string spieprzony, 
Nie wiem jak porównujesz. Zazwyczaj jeśli coś jest pod jednym względem
spieprzone, to pod innym jest dobre. std::string to chyba coś pośredniego
pomiędzy wygodą a wydajnością. QString jest dla mnie wygodniejszy, a 
może tylko jestem bardziej przyzwyczajony do QStringa?

> string w c (char*) tez jest spieprzony choc mniej
Nie wiem co masz na myśli. Ku ścisłości, to ani w C, ani w C++ nie ma
stringów. Ciąg znaków rozpoczynający się gdzieś w pamięci i kończący
znakiem zero ma to spieprzone, że trzeba iterować aby sprawdzić długość.
A to ma dobre, że nie traci się czasu ani pamięci na dodatkowe pole z
informacją o długości. Raz to jest zaleta, drugi raz wada.


> 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

Twoja propozycja w jednych zastosowaniach będzie lepsza, w innych gorsza - 
jak każda propozycja. Jeśli potrzebujesz, zrób sobie taki string, standard
C, ani C++ nie broni Ci zrobić.


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

Nie szkoda czasu na rozmowy, czy lepiej wywołać:
string.reserve( string.size() + 10 )
string.apendreserve( 10 )
string.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)

Nie wiem... mi to trochę zakrawa na rozmowę czy biały kolor jest lepszy 
czy czarny. W C i C++ jest kilka gotowych sposobów na stringi. Jeśli
Ci nie wystarcza, możesz napisać swój sposób - ja tak robię. Nie wystarczało 
mi drzewo czerwono czarne z bibliotek, napisałem swoje. Potem okazało się,
że moje sprawdza się bardzo dobrze jako ogólna (a wyspecjalizowana do
jednego zadania) struktura, to udostępniłem.

Pozdrawiam