🚀 go-pugleaf

W dniu 05.10.2017 o 11:48, Borneq pisze:
> C w wersji 98 ma technikę optymalizacji dla stringów coy-on-write, czyli 

tutaj wytłumaczenie:
http://www.gotw.ca/publications/optimizations.htm

On Thursday, October 5, 2017 at 11:48:56 AM UTC+2, Borneq wrote:
> C w wersji 98 ma technikę optymalizacji dla stringów coy-on-write, czyli 
> kopiowanie tylko gdy modyfikujemy (w ogólności - zapisujemy), natomiast 
> przy odczycie mamy wskaźnik do tego samego miejsca.

C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
stringów jest głupi z definicji. Napis to napis, zwykła wartość.
Modyfikacja napisu nie powinna być odpowiedzialnością klasy
std::string.

w.

On Friday, October 6, 2017 at 1:44:20 PM UTC+2, Wojciech Muła wrote:
> On Thursday, October 5, 2017 at 11:48:56 AM UTC+2, Borneq wrote:
> > C w wersji 98 ma technikę optymalizacji dla stringów coy-on-write, czyli 
> > kopiowanie tylko gdy modyfikujemy (w ogólności - zapisujemy), natomiast 
> > przy odczycie mamy wskaźnik do tego samego miejsca.
> 
> C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
> stringów jest głupi z definicji. Napis to napis, zwykła wartość.
> Modyfikacja napisu nie powinna być odpowiedzialnością klasy
> std::string.

I do takich wniosków doszli twórcy Javy. Osobiście jednak nie mam
preferencji ani do jednego, ani do drugiego rozwiązania.

Pozdrawiam

W dniu 06.10.2017 o 15:08, M.M. pisze:
> On Friday, October 6, 2017 at 1:44:20 PM UTC+2, Wojciech Muła wrote:
>> On Thursday, October 5, 2017 at 11:48:56 AM UTC+2, Borneq wrote:
>>> C w wersji 98 ma technikę optymalizacji dla stringów coy-on-write, czyli
>>> kopiowanie tylko gdy modyfikujemy (w ogólności - zapisujemy), natomiast
>>> przy odczycie mamy wskaźnik do tego samego miejsca.

Testy z linku z http://www.gotw.ca/publications/optimizations.htm
preferują ten c C++11, choć gdy łańcuch się nie zmienia to wcześniejsza 
wersja szybsza. ALE gdy porównywałem nie z implementacjami z tego 
przykładu, tylko z std::string, to był on zdecydowanie najszybszy. Nie 
wiem jakich sztuczek używa, bo działa dużo szybciej niż przydzielania 
pamięci na obiekt własnych stringów.

On Fri, 6 Oct 2017 06:08:35 -0700 (PDT), M.M. wrote:

>> C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
>> stringów jest głupi z definicji. Napis to napis, zwykła wartość.
>> Modyfikacja napisu nie powinna być odpowiedzialnością klasy
>> std::string.
> 
> I do takich wniosków doszli twórcy Javy. Osobiście jednak nie mam
> preferencji ani do jednego, ani do drugiego rozwiązania.

Czyli jak jest w Javie?

-- 
pozdrawiam
Roman Tyczka

On Saturday, October 7, 2017 at 11:16:42 AM UTC+2, Roman Tyczka wrote:
> On Fri, 6 Oct 2017 06:08:35 -0700 (PDT), M.M. wrote:
> 
> >> C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
> >> stringów jest głupi z definicji. Napis to napis, zwykła wartość.
> >> Modyfikacja napisu nie powinna być odpowiedzialnością klasy
> >> std::string.
> > 
> > I do takich wniosków doszli twórcy Javy. Osobiście jednak nie mam
> > preferencji ani do jednego, ani do drugiego rozwiązania.
> 
> Czyli jak jest w Javie?

String jest immutable. Wszystkie operacje na stringach tworzą
nowe instancje.

w.

On Saturday, October 7, 2017 at 3:20:51 PM UTC+2, Wojciech Muła wrote:
> On Saturday, October 7, 2017 at 11:16:42 AM UTC+2, Roman Tyczka wrote:
> > On Fri, 6 Oct 2017 06:08:35 -0700 (PDT), M.M. wrote:
> > 
> > >> C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
> > >> stringów jest głupi z definicji. Napis to napis, zwykła wartość.
> > >> Modyfikacja napisu nie powinna być odpowiedzialnością klasy
> > >> std::string.
> > > 
> > > I do takich wniosków doszli twórcy Javy. Osobiście jednak nie mam
> > > preferencji ani do jednego, ani do drugiego rozwiązania.
> > 
> > Czyli jak jest w Javie?
> 
> String jest immutable. Wszystkie operacje na stringach tworzą
> nowe instancje.


Ale chcieliśmy zwiększyć wydajność, nie zmniejszyć ;-)

pzdr
bartekltg

On Monday, October 9, 2017 at 7:23:19 AM UTC+2, bartekltg wrote:
> On Saturday, October 7, 2017 at 3:20:51 PM UTC+2, Wojciech Muła wrote:
> > On Saturday, October 7, 2017 at 11:16:42 AM UTC+2, Roman Tyczka wrote:
> > > On Fri, 6 Oct 2017 06:08:35 -0700 (PDT), M.M. wrote:
> > > 
> > > >> C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
> > > >> stringów jest głupi z definicji. Napis to napis, zwykła wartość.
> > > >> Modyfikacja napisu nie powinna być odpowiedzialnością klasy
> > > >> std::string.
> > > > 
> > > > I do takich wniosków doszli twórcy Javy. Osobiście jednak nie mam
> > > > preferencji ani do jednego, ani do drugiego rozwiązania.
> > > 
> > > Czyli jak jest w Javie?
> > 
> > String jest immutable. Wszystkie operacje na stringach tworzą
> > nowe instancje.
> 
> 
> Ale chcieliśmy zwiększyć wydajność, nie zmniejszyć ;-)

Zacytuję klasyka: "serwery są teraz tanie". :)

w.

On Monday, October 9, 2017 at 9:33:33 AM UTC+2, Wojciech Muła wrote:
> On Monday, October 9, 2017 at 7:23:19 AM UTC+2, bartekltg wrote:
> > On Saturday, October 7, 2017 at 3:20:51 PM UTC+2, Wojciech Muła wrote:
> > > On Saturday, October 7, 2017 at 11:16:42 AM UTC+2, Roman Tyczka wrote:
> > > > On Fri, 6 Oct 2017 06:08:35 -0700 (PDT), M.M. wrote:
> > > > 
> > > > >> C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
> > > > >> stringów jest głupi z definicji. Napis to napis, zwykła wartość.
> > > > >> Modyfikacja napisu nie powinna być odpowiedzialnością klasy
> > > > >> std::string.
> > > > > 
> > > > > I do takich wniosków doszli twórcy Javy. Osobiście jednak nie mam
> > > > > preferencji ani do jednego, ani do drugiego rozwiązania.
> > > > 
> > > > Czyli jak jest w Javie?
> > > 
> > > String jest immutable. Wszystkie operacje na stringach tworzą
> > > nowe instancje.
> > 
> > 
> > Ale chcieliśmy zwiększyć wydajność, nie zmniejszyć ;-)
> 
> Zacytuję klasyka: "serwery są teraz tanie". :)

:-)

Niby tak, ale w pewnym momencie trafiamy na poziom googlo facebooka
i takie ilości serwerów już tak tanie nie są:) Albo biolog napisał 
sibie na stringach przetwarzanie DNA i mi klaster zapycha...

A na poważnie, dlaczego string ma być immutable? 
Przecież moge chcieć tworzyć string literka po literce. 
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. 
Bawiłem się chwilę (czysto rozrywkowo) c#, i tam literki stringa 
są immutable. Więc waliłem .ToCharArray(), robiłem swoje i 
konstruowałem nowego stringa. 
Pomijając wydajność, było to też brzydkie. 
std::string nie służy tylko do trzymania napisu, ale 
i przetwarzania, składania.   

Ale od drugiej strony, jakie zalety ma niezmienny string? 
Szybkie googlanie podaje powody, które można załatwić
const, albo są specyficzne dla określonego jezyka (np cachowanie
hashy stringów, bo są często używane).

pzdr
bartekltg 

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

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.

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.

Pozdrawiam

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)

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

W dniu czwartek, 12 października 2017 16:00:18 UTC+2 użytkownik M.M. napisał:
> > 
> > txt.size += 10;
> 
> Nie szkoda czasu na rozmowy, czy lepiej wywołać:
> string.reserve( string.size() + 10 )
> string.apendreserve( 10 )
> string.size += 10 
> ???
> 
> 
> 
nie rozmiem pytania, jesli mowa o tych granicach rozszerzalnosci to raczej na tym to polega ze nie
powinno sie ich zmieniac (reserve i append_reserve to ttaj ogolnie zle nazwy, lepiej myslec w duchu min i max, choc mozna przemyslec czy min jest wogole potrzebne)

On Thursday, October 12, 2017 at 4:14:10 PM UTC+2, (fir) wrote:
> W dniu czwartek, 12 października 2017 16:00:18 UTC+2 użytkownik M.M. napisał:
> > > 
> > > txt.size += 10;
> > 
> > Nie szkoda czasu na rozmowy, czy lepiej wywołać:
> > string.reserve( string.size() + 10 )
> > string.apendreserve( 10 )
> > string.size += 10 
> > ???
> > 
> > 
> > 
> nie rozmiem pytania, 
Ja nie rozumiem Twojego celu, dlatego po omacku odgaduję, że zależy
Ci na składni:

string.size += 10

Dla mnie to jest rozmowa o przewadze świąt wielkanocy nad wigilią.
Czemu:

string.size += 10

jest lepsze od

string.resize( string.size + 10 )



> jesli mowa o tych granicach rozszerzalnosci to raczej na tym to polega ze nie
> powinno sie ich zmieniac (reserve i append_reserve to ttaj ogolnie zle 
> nazwy, lepiej myslec w duchu min i max, choc mozna przemyslec czy min 
> jest wogole potrzebne)

Pewnie od jakiś zastosowań przydatne. W bibliotece QT są metody dla 
kontenerów append i preppend, a pamięć jest preallokowana z przodu,
więc preppend tylko czasami przesuwa size() elementów.

Jeśli szukasz ogólnie(!) dobrego stringa, bez wskazywania jednego konkretnego
zastosowania, to moim zdaniem QString jest bardzo wygodny przy zachowaniu
wydajności jaka tylko jest możliwa dla takiej funkcjonalności. Jeśli 
wystarczy Ci mniejsza funkcjonalność, to QString może się okazać 
spieprzony.


Pozdrawiam

W dniu czwartek, 12 października 2017 17:02:42 UTC+2 użytkownik M.M. napisał:
> On Thursday, October 12, 2017 at 4:14:10 PM UTC+2, (fir) wrote:
> > W dniu czwartek, 12 października 2017 16:00:18 UTC+2 użytkownik M.M. napisał:
> > > > 
> > > > txt.size += 10;
> > > 
> > > Nie szkoda czasu na rozmowy, czy lepiej wywołać:
> > > string.reserve( string.size() + 10 )
> > > string.apendreserve( 10 )
> > > string.size += 10 
> > > ???
> > > 
> > > 
> > > 
> > nie rozmiem pytania, 
> Ja nie rozumiem Twojego celu, dlatego po omacku odgaduję, że zależy
> Ci na składni:
> 
> string.size += 10
> 
> Dla mnie to jest rozmowa o przewadze świąt wielkanocy nad wigilią.
> Czemu:
> 
> string.size += 10
> 
> jest lepsze od
> 
> string.resize( string.size + 10 )
> 

z tego samego powodu z ktorego 

//int a = 1;
a+=10;

jest lepsze nic

a.assign(a+10)


> 
> 
> > jesli mowa o tych granicach rozszerzalnosci to raczej na tym to polega ze nie
> > powinno sie ich zmieniac (reserve i append_reserve to ttaj ogolnie zle 
> > nazwy, lepiej myslec w duchu min i max, choc mozna przemyslec czy min 
> > jest wogole potrzebne)
> 
> Pewnie od jakiś zastosowań przydatne. W bibliotece QT są metody dla 
> kontenerów append i preppend, a pamięć jest preallokowana z przodu,
> więc preppend tylko czasami przesuwa size() elementów.
> 
> Jeśli szukasz ogólnie(!) dobrego stringa, bez wskazywania jednego konkretnego
> zastosowania, to moim zdaniem QString jest bardzo wygodny przy zachowaniu
> wydajności jaka tylko jest możliwa dla takiej funkcjonalności. Jeśli 
> wystarczy Ci mniejsza funkcjonalność, to QString może się okazać 
> spieprzony.
> 
> 

On Thu, 12 Oct 2017 09:44:36 -0700 (PDT), (fir) wrote:

>> Dla mnie to jest rozmowa o przewadze świąt wielkanocy nad wigilią.
>> Czemu:
>> 
>> string.size += 10
>> 
>> jest lepsze od
>> 
>> string.resize( string.size + 10 )
>> 
> 
> z tego samego powodu z ktorego 
> 
> //int a = 1;
> a+=10;
> 
> jest lepsze nic
> 
> a.assign(a+10)

To się nazywa lukier składniowy i dosłownie NICZEGO nie wnosi do tematu.
Imho wręcz zaciemnia, bo odchodzi od dość naturalnej dla człowieka
konwencji obiektowej.

-- 
pozdrawiam
Roman Tyczka

On Thursday, October 12, 2017 at 6:44:37 PM UTC+2, (fir) wrote:
> W dniu czwartek, 12 października 2017 17:02:42 UTC+2 użytkownik M.M. napisał:
> > On Thursday, October 12, 2017 at 4:14:10 PM UTC+2, (fir) wrote:
> > > W dniu czwartek, 12 października 2017 16:00:18 UTC+2 użytkownik M.M. napisał:
> > > > > 
> > > > > txt.size += 10;
> > > > 
> > > > Nie szkoda czasu na rozmowy, czy lepiej wywołać:
> > > > string.reserve( string.size() + 10 )
> > > > string.apendreserve( 10 )
> > > > string.size += 10 
> > > > ???
> > > > 
> > > > 
> > > > 
> > > nie rozmiem pytania, 
> > Ja nie rozumiem Twojego celu, dlatego po omacku odgaduję, że zależy
> > Ci na składni:
> > 
> > string.size += 10
> > 
> > Dla mnie to jest rozmowa o przewadze świąt wielkanocy nad wigilią.
> > Czemu:
> > 
> > string.size += 10
> > 
> > jest lepsze od
> > 
> > string.resize( string.size + 10 )
> > 
> 
> z tego samego powodu z ktorego 
> 
> //int a = 1;
> a+=10;
> 
> jest lepsze nic
> 
> a.assign(a+10)

Nie wiem co jest lepsze. W C++ size może być obiektem który ma przeładowane
operatory += i -=. Czy jest lepsze? Gdy się uczę nowej biblioteki, to
wolę mieć nazwę funkcji, bo nazwa jednak samodokumentuje kod. Gdy posługuję
się czymś wielokrotnie i znam zachowanie operatorów, to w moim odczuciu 
kod dzięki przeładowanym operatorom jest bardziej przejrzysty. Czyli ja
o jednym i tym samym przypadku raz mówię że operatory zaciemniają kod, a drugi
raz że czynią go bardziej przejrzystym. Na pewno nie wolno nadużywać 
operatorów, bo kontakt nowej osoby z takim kodem może wywołać szok.

Pozdrawiam

M.M. wrote:

> Zazwyczaj to ja kroję włosa na czworo, ale teraz mam wrażenie, że to Wy
> kroicie :)

Dla nas to przez wiele lat była proza życia codziennego. Sądzisz, że
pakowalibyśmy się w projektowanie i implementację własnego stringa
dla przyjemności albo dlatego, że lubimy być niekompatybilni ze światem?

> String to string, ma być wygodny, nie nadaje się do pisania
> wyżyłowanych i wyspecjalizowanych implementacji.

Od strony technicznej w stringu nie ma niczego, co uniemożliwiałoby
wyżyłowaną implementację, gdyby tylko nie był spieprzony od strony 
architektonicznej. To taki niby container, niby builder, elegancko
łączący wady obu przy praktycznym braku zalet. W innych językach
zrobiono to po prostu lepiej. Rzecz jest nie do uratowania.

	Pozdrawiam, Piotr

On Thursday, October 12, 2017 at 10:52:54 PM UTC+2, Piotr Wyderski wrote:
> M.M. wrote:
> 
> > Zazwyczaj to ja kroję włosa na czworo, ale teraz mam wrażenie, że to Wy
> > kroicie :)
> 
> Dla nas to przez wiele lat była proza życia codziennego. Sądzisz, że
> pakowalibyśmy się w projektowanie i implementację własnego stringa
> dla przyjemności albo dlatego, że lubimy być niekompatybilni ze światem?

Zdziwiłem się, bo to zazwyczaj ja stoję po tej stronie barykady ;-)



> > String to string, ma być wygodny, nie nadaje się do pisania
> > wyżyłowanych i wyspecjalizowanych implementacji.
> 
> Od strony technicznej w stringu nie ma niczego, co uniemożliwiałoby
> wyżyłowaną implementację, gdyby tylko nie był spieprzony od strony 
> architektonicznej. 
Mogę poprosić jakieś przykłady na poparcie tego? Proszę, bo chcę
zrozumieć co masz na myśli.


> To taki niby container, niby builder, elegancko
> łączący wady obu przy praktycznym braku zalet. W innych językach
> zrobiono to po prostu lepiej. Rzecz jest nie do uratowania.
Hmmm, ja nie wiem. Dla mnie string to string, biorę i używam. A
jeśli działa za wolno, to coś kombinuję samemu.

Pozdrawiam

M.M. wrote:

> Mogę poprosić jakieś przykłady na poparcie tego? Proszę, bo chcę
> zrozumieć co masz na myśli.

Są zasadniczo trzy główne przypadki użycia danych tekstowych:

1. Budowanie napisu.
2. Pełnoskalowe użycie zbudowanego napisu, z funkcjami wyszukiwania,
regexpami itp.
3. Ograniczone użycie zbudowanego napisu, które traktuje jego zawartość
jako całość i gdzie nie interesuje nas, skąd się napis wziął.

C++ stawia na 2, koślawie łącząc go z 1 i całkowicie ignorując 3.
Tak się jednak składa, że to 3. jest kluczowe dla wydajnego
przetwarzania danych wielkoskalowych, a 2. służy do pokazywania
studentom i zastosowań nieistotnych w rodzaju program_options itp.
drobnicy, gdzie stringów jest maksymalnie kilka tysięcy. Ja mówię
o miliardach. 3 sprowadza się do wzbogaconej o lukier syntaktyczny
std::pair<const char*, std::size_t> i jest wyjątkowo niemedialny.
Pozwala jednak zrobić cuda, w razie potrzeby nawet na zatarcie
źródła pochodzenia danych -- treść może pochodzić z std::string,
mogę sobie skonstruować ten wrapper na gołej tablicy bajtów w pamięci
itp. -- po stronie konsumenta danych tego nie widać. W C++17
(wreszcie!) wprowadzono string_view, choć jak to w komitecie
bywa, zatrzymali się w połowie drogi i nie wyciągnęli kluczowych
wniosków. Choćby takich, że taka warstwa prezentacji jest generyczna
i nadaje się do wszelkich innych koncepcyjnie równoważnych rzeczy,
np. do wyjęcia gołej zawartości std::vector<double>. Trzeba
było wprowadzić std::view<T> i specjalizować go dla znaków.
Ja coś takiego zrobiłem kilka lat temu i nazwałem segmentem.
Sprawdza się znakomicie.

Przyjęcia 2 jako wersji wiodącej i połączenie jej z 1 narzuca
na 1 dramatyczne ograniczenia, które rykoszetem odbijają się na 2.
Pomijając już sprawę wielowątkowości, z chęci redukcji narzutu 
pamięciowego i ogólnych własności takiej konstrukcji wynika,
że string może rosnąć tylko w jedną stronę. Przyjęto, że na
końcu. Wydajnie doklejać znaczków na początek się nie da, bo
trzeba kopiować całe dane w prawo. Ale skoro string może
rosnąć i dane są trzymane w obszarze ciągłym, to kiedyś ten
obszar się wyczerpie i trzeba będzie go powiększać. Kiedy?
Jeśli chcemy oszczędzać pamięć, a w przypadku danych o dużym
wolumenie nawet musimy, to rezerwa musi być mała. Idealnie
jednoznakowa. No ale wtedy na append() kopiuję cały string
co znaczek i budowanie stringa wybucha mi do czasu kwadratowego.
Genialne. No to od drugiej strony: powiększam rezerwę wykładniczo,
co mi złożoność worst case redukuje do O(n log n). Ale moje
dane mogą mieć długość paskudnie interferującą z algorytmem
powiększania i po systemie latają wielkie bufory z krótką
treścią. A ja nie mam na nie miejsca. Można stosować różne
kompromisy między tymi skrajnościami i nawet się z nich doktoryzować,
ale rozwiązaniem poprawnym jest zauważenie, że budowanie stringa
i jego użycie to dwie zupełnie różne czynności i każda z nich
powinna być zaimplementowana optymalnie. Builder nie nakłada
na mnie żadnych ograniczeń na to, od której strony buduję finalny
napis, trywialna implementacja równie dobrze poradzi sobie z obiema.
Podczas budowania nie muszę też niczego kopiować, bo nie ma
najmniejszej potrzeby, by dane tymczasowe znajdowały się w pamięci
ciągłej. Skończy mi się buforek, to sobie dodam następny, jak
w std::deque. Otrzymuję funkcjonalność znacznie bogatszą niż
oryginał przy gwarantowanej i bardzo niskiej złożoności czasowej
operacji. Jeśli alokator poza standardowym API wspiera też pewne
specjalne konstrukcje, np. alokację bloków o ustalonej wielkości,
to gwarancje złożonościowe mogą być nawet formalne, a nie tylko
spodziewane. A gdy wreszcie string powstaje, mogę sprawdzić, czy
już takiego nie budowałem i zwrócić gotowy element, a nie alokować
duplikat. Porównania na równość sprowadzą mi się wtedy do porównania
wskaźników na bufor, bez konieczności zaglądania w znaczki. A to od
razu dramatycznie przyspiesza kontenery unordered. I mnóstwo innych
tego typu implikacji.

Tylko tu trzeba wyjść od skali rzeczywistego zastosowania i popatrzeć
na problem całościowo, bo rozwiązanie opiera się na efekcie synergii
wynikającej z dostosowania różnych składowych biblioteki, a nie z 
ulepszania jednej klasy. Tylko z efektów można wywnioskować, że
komitet nie ma zwyczaju tak działać i wolą się bawić modelowaniem
pojedynczego stringa, by w przykładach ładnie wyglądał. Problem w tym,
że C++ nie ma większego sensu w projektach małoskalowych (wygodniej
przetworzysz sobie swoje dane w Javie lub innym Pythonie, choćby 
dlatego, że nie musisz zarządzać czasem życia obiektu), a do 
wielkoskalowych się nie nadaje ze względu na ograniczenia projektowe
swojej biblioteki standardowej. I trzeba uprawiać rzeźbiarstwo 
artystyczne...

> Hmmm, ja nie wiem. Dla mnie string to string, biorę i używam. A
> jeśli działa za wolno, to coś kombinuję samemu.

Właśnie od tego jest biblioteka standardowa, byś nie musiał robić
samemu, tylko wziąć gotowiec z pudełka i z zadowoleniem używać.
A skoro jednak kombinujesz, i do tego nie Ty jeden, to znaczy, że
z klasą biblioteczną jest coś bardzo nie tak. Własnych wektorów
jakoś ludzie nie piszą, ani mapek. Wzajemnie niezgodnych mutacji
stringa jest za to zatrzęsienie i wcale nie dlatego, że kontener
do napisów jest niesamowicie interesującą problematyką, tylko
wersja referencyjna stwarza więcej problemów niż rozwiązuje
i ludzie sobie to obchodzą jak umieją. "Po owocach ich poznacie je".

	Pozdrawiam, Piotr

On Friday, October 13, 2017 at 12:42:13 AM UTC+2, Piotr Wyderski wrote:
> M.M. wrote:
> 
> > Mogę poprosić jakieś przykłady na poparcie tego? Proszę, bo chcę
> > zrozumieć co masz na myśli.
> 
> Są zasadniczo trzy główne przypadki użycia danych tekstowych:
> 
> 1. Budowanie napisu.
> 2. Pełnoskalowe użycie zbudowanego napisu, z funkcjami wyszukiwania,
> regexpami itp.
> 3. Ograniczone użycie zbudowanego napisu, które traktuje jego zawartość
> jako całość i gdzie nie interesuje nas, skąd się napis wziął.

Hmmmm. 


> C++ stawia na 2, koślawie łącząc go z 1 i całkowicie ignorując 3.
Chyba masz rację. W QT, jak dla moich potrzeb, budowanie napisu jest
bardzo wygodne, a jak mi mało, to mogę także QTextStream skonstruować
na QStringu.

> Tak się jednak składa, że to 3. 
> jest kluczowe dla wydajnego
> przetwarzania danych wielkoskalowych, a 2. służy do pokazywania
> studentom i zastosowań nieistotnych w rodzaju program_options itp.
> drobnicy, gdzie stringów jest maksymalnie kilka tysięcy. 

Do wydajnego przetwarzania dużej ilości drobnicy potrzebny jest 
jakiś szablon obudowujący tablicę o stałym rozmiarze.

template< int MAX_SIZE=32, typename TS=char  >
class String {
  TS string[MAX_SIZE+1];
};


> Ja mówię o miliardach. 
Tak tak.


> 3 sprowadza się do wzbogaconej o lukier syntaktyczny
> std::pair<const char*, std::size_t> i jest wyjątkowo niemedialny.
Przyznaję, brzydkie. Ja bym na powyższym szablonie bazował.


> Pozwala jednak zrobić cuda, w razie potrzeby nawet na zatarcie
> źródła pochodzenia danych -- treść może pochodzić z std::string,
> mogę sobie skonstruować ten wrapper na gołej tablicy bajtów w pamięci
> itp. -- po stronie konsumenta danych tego nie widać. 
No tak.


> W C++17
> (wreszcie!) wprowadzono string_view, choć jak to w komitecie
> bywa, zatrzymali się w połowie drogi i nie wyciągnęli kluczowych
> wniosków. Choćby takich, że taka warstwa prezentacji jest generyczna
> i nadaje się do wszelkich innych koncepcyjnie równoważnych rzeczy,
> np. do wyjęcia gołej zawartości std::vector<double>. Trzeba
> było wprowadzić std::view<T> i specjalizować go dla znaków.
> Ja coś takiego zrobiłem kilka lat temu i nazwałem segmentem.
> Sprawdza się znakomicie.
Trochę się zgubiłem, co zrobiłeś?



> Przyjęcia 2 jako wersji wiodącej i połączenie jej z 1 narzuca
> na 1 dramatyczne ograniczenia, które rykoszetem odbijają się na 2.
> Pomijając już sprawę wielowątkowości, z chęci redukcji narzutu 
> pamięciowego i ogólnych własności takiej konstrukcji wynika,
> że string może rosnąć tylko w jedną stronę. 
Ale zwróć uwagę, że w przypadku dużej ilości malutkich napisów zazwyczaj
lepiej robić memmove i dopisywać na początek, niż zaczynać napis od
'środka' tablicy. 


> Przyjęto, że na
> końcu. Wydajnie doklejać znaczków na początek się nie da, bo
> trzeba kopiować całe dane w prawo. 
Tak, ale statystycznie rzadziej dokleja się na początku. W przypadku
drobnicy, mało znaczków przerzuca się na koniec. Gdy operacja 
doklejania na początku jest wiodąca w danym programie, to można
napisy trzymać w odwrotnej kolejności znaków. Jeśli dla drobnicy
zarezerwujemy kilka bajtów z przodu, to czasem będzie trzeba 
przerzucić bajty do przodu, aby pisać na końcu. Problemy z drobnicą
są, gdy ilość napisów idzie w miliardy, więc rezerwowanie większej
pamięci może skończyć się brakiem pamięci w systemie. 

O ile program nie jest bardzo specyficzny, to tamten powyższy
template wydaje się uniwersalny do drobnicy.



> Ale skoro string może
> rosnąć i dane są trzymane w obszarze ciągłym, to kiedyś ten
> obszar się wyczerpie i trzeba będzie go powiększać. Kiedy?
> Jeśli chcemy oszczędzać pamięć, a w przypadku danych o dużym
> wolumenie nawet musimy, to rezerwa musi być mała. Idealnie
> jednoznakowa. No ale wtedy na append() kopiuję cały string
> co znaczek i budowanie stringa wybucha mi do czasu kwadratowego.

Z pamięci piszę: często realloc umie dodać mały kawałek pamięci na
końcu bez kopiowania całości.


> Genialne. No to od drugiej strony: powiększam rezerwę wykładniczo,
> co mi złożoność worst case redukuje do O(n log n). Ale moje
> dane mogą mieć długość paskudnie interferującą z algorytmem
> powiększania i po systemie latają wielkie bufory z krótką
> treścią. 
By się przydał jakiś autotune string. Mam coś podobnego w
drzewach czerwono czarnych, tyle że nie są auto, ale sam
muszę ustawić flagę jak się drzewo ma przekonfigurować.

Jeśli wiadomo jak string będzie się rozszerzał, to można dostosować
sposób allokacji. A jak nie wiadomo, to lipa.

W Qt jest struktura która automatycznie zmienia się z tablicy 
na stosie w coś podobnego do wektora. Można wydajnie operować 
na małych danych, a jak dojdzie do przekroczenia zakresu, to 
automatycznie zrobi malloc i rozszerza się jak wektor. Ale to
jest rada na sytuację, gdy jest dużo drobnicy, przy czym 
z rzadka z drobnicy robi się długi napis.


> A ja nie mam na nie miejsca. Można stosować różne
> kompromisy między tymi skrajnościami i nawet się z nich doktoryzować,
> ale rozwiązaniem poprawnym jest zauważenie, że budowanie stringa
> i jego użycie to dwie zupełnie różne czynności i każda z nich
> powinna być zaimplementowana optymalnie. Builder nie nakłada
> na mnie żadnych ograniczeń na to, od której strony buduję finalny
> napis, trywialna implementacja równie dobrze poradzi sobie z obiema.
Czy chodzi o C++ Buildera i TString? Używałem tego tak dawno temu, że
nie pamiętam jakie możliwości mają tam stringi.


> Podczas budowania nie muszę też niczego kopiować, bo nie ma
> najmniejszej potrzeby, by dane tymczasowe znajdowały się w pamięci
> ciągłej. 
W QT wszystkie kolekcje głęboką kopię robią dopiero przy 
modyfikowaniu, za to działają nieznacznie wolniej - wada. Zaleta
jest taka, że można bezkarnie sobie pisać 
duża_struktura1 = duża_struktura2



> Skończy mi się buforek, to sobie dodam następny, jak
> w std::deque. Otrzymuję funkcjonalność znacznie bogatszą niż
> oryginał przy gwarantowanej i bardzo niskiej złożoności czasowej
> operacji. Jeśli alokator poza standardowym API wspiera też pewne
> specjalne konstrukcje, np. alokację bloków o ustalonej wielkości,
> to gwarancje złożonościowe mogą być nawet formalne, a nie tylko
> spodziewane. A gdy wreszcie string powstaje, mogę sprawdzić, czy
> już takiego nie budowałem i zwrócić gotowy element, a nie alokować
> duplikat. 
To jakieś hashe byś musiał trzymać, albo drzewo wyszukiwań. Na QStringu
chyba dobrze zadziałałoby operowanie na samych odnośnikach do tych
samych napisów.


> Porównania na równość sprowadzą mi się wtedy do porównania
> wskaźników na bufor, bez konieczności zaglądania w znaczki. 
Tak, to ogromna zaleta unikalności napisów. Ale zwróć uwagę, że
gdy użytkownik wpisze string, to i tak i tak trzeba go 
porównywać z zaglądaniem w znaczki, stosować drzewa poszukiwań i/albo
hashe.


> A to od
> razu dramatycznie przyspiesza kontenery unordered. I mnóstwo innych
> tego typu implikacji.
No tak, porównanie wskaźników jest szybsze niż znaczków. Ale gdy 
mamy dobrą hash-table, to porównań jest mało. Gdy mamy duży zbiór i
losowe strzały (w unorder set są zawsze losowe) w RAM, to wąskim
gardłem jest dostęp do pamięci. Na pewno współdzielone wskaźniki
przyspieszą, ale z powodu losowych strzałów w RAM, tutaj nie
spodziewałbym się dużych przyspieszeń.


> Tylko tu trzeba wyjść od skali rzeczywistego zastosowania i popatrzeć
> na problem całościowo, bo rozwiązanie opiera się na efekcie synergii
> wynikającej z dostosowania różnych składowych biblioteki, a nie z 
> ulepszania jednej klasy. 
Oczywiście. Dlatego zdecydowana większość autorów programów 
szachowych, gdzie wydajność jest bardzo ważna, nie stosuje 
ani jednego kontenera z biblioteki standardowej :D


> Tylko z efektów można wywnioskować, że
> komitet nie ma zwyczaju tak działać i wolą się bawić modelowaniem
> pojedynczego stringa, by w przykładach ładnie wyglądał. 
Jak to nazwałeś, synergia, jest kluczową cechą w dużych bibliotekach.
Osobiście najczęściej używam QT i nie narzekam na brak synergii.
Zwróć jednak uwagę, że synergia nie idzie w parze z wydajnością, 
kontenery z QT zazwyczaj są wolniejsze niż z STL.


> Problem w tym,
> że C++ nie ma większego sensu w projektach małoskalowych (wygodniej
> przetworzysz sobie swoje dane w Javie lub innym Pythonie, choćby 
> dlatego, że nie musisz zarządzać czasem życia obiektu), 
Ja nie zarządzam czasem życia w helołłerdach. Nawet gdybym
miał 50 wycieków pamięci, ale wiem że program się zakończy 
gdy zabraknie pamięci i mnie to nie obchodzi. Jednak wyciek
mam rzadko, bo QVector i inna hash-table same zwolnią gdy 
wykonanie dojdzie do klamerki.


> a do 
> wielkoskalowych się nie nadaje ze względu na ograniczenia projektowe
> swojej biblioteki standardowej. I trzeba uprawiać rzeźbiarstwo 
> artystyczne...
Czasami trzeba napisać swoją bibliotekę, gdy projekt jest wielkoskalowy, 
to relatywny koszt napisania biblioteki jest mały, a gdy zespół, albo
nawet jedna osoba, piszą po raz któryś podobny system, to dostosowują
biblioteki z poprzednich systemów. Jednym słowem, tutaj bardzo mocno z
Tobą się nie zgodzę.



> > Hmmm, ja nie wiem. Dla mnie string to string, biorę i używam. A
> > jeśli działa za wolno, to coś kombinuję samemu.
> 
> Właśnie od tego jest biblioteka standardowa, byś nie musiał robić
> samemu, tylko wziąć gotowiec z pudełka i z zadowoleniem używać.
Ja tak używam biblioteki QT. Na standardową prędzej czy później
bluzgam. Ale gdy jest potrzebna duża wydajność, o której czesto
piszesz, to i tak i tak jest potrzebna biblioteka specyficzna, a
taką bibliotekę programista musi sam albo napisać, albo dostosować z
innego podobnego projektu który robił wcześniej.


> A skoro jednak kombinujesz, i do tego nie Ty jeden, to znaczy, że
> z klasą biblioteczną jest coś bardzo nie tak. 
Tak, tylko nie pomieszajmy paradygmatów. Można kombinować, bo w
bibliotece nie ma, jak to ładnie nazwałeś, ani synergii, ani wygody, ani
funkcjonalności, a można kombinować, bo funkcjonalność jest za 
duża, co skutkuje małą wydajnością.



> Własnych wektorów
> jakoś ludzie nie piszą, ani mapek. 
Ależ piszą i to np. dwie różne dla jednej aplikacji!


> Wzajemnie niezgodnych mutacji
> stringa jest za to zatrzęsienie i wcale nie dlatego, że kontener
> do napisów jest niesamowicie interesującą problematyką, tylko
> wersja referencyjna stwarza więcej problemów niż rozwiązuje
> i ludzie sobie to obchodzą jak umieją. "Po owocach ich poznacie je".

Nie wiem jaka jest prawdziwa przyczyna bibliotecznych wielości 
stringów w C++. Do zwykłego programowania ja używam QStringa i
nawet nie myślę o std::stringu. Gdy mam dużo drobnicy to obudowuję
szablonem stałą tablicę, korzystam z varlenghtarray, itd. Gdy
zobaczyłem jakiś czas temu ile trzeba się namęczyć, aby zrobić
kodowanie std::stringu, to se dałem spokój. QString natywnie 
operuje na utf16, nic nie musi deszyfrować w operacjach typu
'find', a gdy trzeba, to można go eksportować do bardzo wielu
kodowań.

Pozdrawiam

On Friday, October 13, 2017 at 11:41:42 AM UTC+2, M.M. wrote:
> Nie wiem jaka jest prawdziwa przyczyna bibliotecznych wielości 
> stringów w C++. Do zwykłego programowania ja używam QStringa i
> nawet nie myślę o std::stringu. Gdy mam dużo drobnicy to obudowuję
> szablonem stałą tablicę, korzystam z varlenghtarray, itd. Gdy
> zobaczyłem jakiś czas temu ile trzeba się namęczyć, aby zrobić
> kodowanie std::stringu, to se dałem spokój. QString natywnie 
> operuje na utf16, nic nie musi deszyfrować w operacjach typu
> 'find', a gdy trzeba, to można go eksportować do bardzo wielu
> kodowań.

Sam sobie odpowiedziałeś na pytanie: std::string nie jest
wystarczająco dobry (nie wspominając, że pojawił się stosunkowo
niedawno).

w.

On Friday, October 13, 2017 at 3:36:30 PM UTC+2, Wojciech Muła wrote:
> On Friday, October 13, 2017 at 11:41:42 AM UTC+2, M.M. wrote:
> > Nie wiem jaka jest prawdziwa przyczyna bibliotecznych wielości 
> > stringów w C++. Do zwykłego programowania ja używam QStringa i
> > nawet nie myślę o std::stringu. Gdy mam dużo drobnicy to obudowuję
> > szablonem stałą tablicę, korzystam z varlenghtarray, itd. Gdy
> > zobaczyłem jakiś czas temu ile trzeba się namęczyć, aby zrobić
> > kodowanie std::stringu, to se dałem spokój. QString natywnie 
> > operuje na utf16, nic nie musi deszyfrować w operacjach typu
> > 'find', a gdy trzeba, to można go eksportować do bardzo wielu
> > kodowań.
> 
> Sam sobie odpowiedziałeś na pytanie: std::string nie jest
> wystarczająco dobry (nie wspominając, że pojawił się stosunkowo
> niedawno).
> 
> w.

Nie wiem, ja w sumie tylko o kilku szczegółach na jego temat się
wypowiedziałem.

Pozdrawiam

W dniu wtorek, 10 października 2017 03:35:56 UTC+2 użytkownik bartekltg napisał:
> On Monday, October 9, 2017 at 9:33:33 AM UTC+2, Wojciech Muła wrote:
> > On Monday, October 9, 2017 at 7:23:19 AM UTC+2, bartekltg wrote:
> > > On Saturday, October 7, 2017 at 3:20:51 PM UTC+2, Wojciech Muła wrote:
> > > > On Saturday, October 7, 2017 at 11:16:42 AM UTC+2, Roman Tyczka wrote:
> > > > > On Fri, 6 Oct 2017 06:08:35 -0700 (PDT), M.M. wrote:
> > > > > 
> > > > > >> C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
> > > > > >> stringów jest głupi z definicji. Napis to napis, zwykła wartość.
> > > > > >> Modyfikacja napisu nie powinna być odpowiedzialnością klasy
> > > > > >> std::string.
> > > > > > 
> > > > > > I do takich wniosków doszli twórcy Javy. Osobiście jednak nie mam
> > > > > > preferencji ani do jednego, ani do drugiego rozwiązania.
> > > > > 
> > > > > Czyli jak jest w Javie?
> > > > 
> > > > String jest immutable. Wszystkie operacje na stringach tworzą
> > > > nowe instancje.
> > > 
> > > 
> > > Ale chcieliśmy zwiększyć wydajność, nie zmniejszyć ;-)
> > 
> > Zacytuję klasyka: "serwery są teraz tanie". :)
> 
> :-)
> 
> Niby tak, ale w pewnym momencie trafiamy na poziom googlo facebooka
> i takie ilości serwerów już tak tanie nie są:) Albo biolog napisał 
> sibie na stringach przetwarzanie DNA i mi klaster zapycha...
> 
> A na poważnie, dlaczego string ma być immutable? 
> Przecież moge chcieć tworzyć string literka po literce. 
> 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. 
> Bawiłem się chwilę (czysto rozrywkowo) c#, i tam literki stringa 
> są immutable. Więc waliłem .ToCharArray(), robiłem swoje i 
> konstruowałem nowego stringa. 
> Pomijając wydajność, było to też brzydkie. 
> std::string nie służy tylko do trzymania napisu, ale 
> i przetwarzania, składania.   
> 
> Ale od drugiej strony, jakie zalety ma niezmienny string? 

niezmienny string ma na przyklad ta niebagatelna zalete ze jest niezniszczalny, nie mozna go wiec w szczegolnosci zamazac/zepsuc/zniszczyc informacje - wiekszosc stringow jest po to by niesc jakas informacje (np lądja na ekranie czy na kontrolkach itd i nie sa po to by je niszczyc)

na niejako podobnej zasadzie stringi nie sa po to by do nich pisac (tj o ile wejsciowe stringi nie sa po to by je niszczyc to wyjsciowe stringi nie sa po to by je tworzyc) dlatego ze ram nie jest po to by ja opisywac stringami dla dekoracji, jesli ktos tworzy jakis nowy string to po to by on trafil gdzies na zewnatrz a do teo mozna wykorzystac - jak pisalem printfa i stworzyc string na wyjsciu a nie w ramie

pominawszy to resizowalny string mozna zrobic dla zabawy - podalem ilustracje jak mozna i jak wlasciwie nalezy to zrobic

taki string nie bylby raczej w ogolnosci za mocny wydajnosciowo ale mialby chyba dosyc ciekawe wlasnosci 'wygodnosciowo'
- byc moze warto nawet na ten temat troche pomyslec

ciekawa jest na przyklad opcja zmergeowania dwu takich resizowalnych stringow wtedy ten drugi po prostu znika

mozna sobie powyobrazac rozne operacja na takich stringach i zbudowac pewna 'algebre' operacji na takich stringach - i to tym razem bardziej pod wzgledem wygody niz speedu (programistow c tez czasem moze byc stac na wygode ;c choc oczywiscie lepiej wiedziec co sie robi)

przyklady:

dodanie stringa na poczatku

a = b + a;

dodanie stina na koncu

a = a + b;

zmergeowanie stringow:

d=a+b+c;

a.size = 0;
b.size = 0;
c.size = 0;

tutaj co prawda nie wiem czy faktyczni enie warto dodac czegos w rodzaju 'destruktora' by bylo krocej

d=~a+~b+~c; //? dodaj i zresizuj na zero 

w moim siclu mam typ chunks czyli tablice chunkow a dokladnie chunk chunkow,

przy takim typie mozna dodac tez dzielenie stringow

chunks l = txt/'\n';

chunks l = "ala ma kota"/" ";

pytanie czy tekst dzilacy pownien sie znalezc w skladnikach czy powinien byc usuniety..


co tam jeszcze....



 


> Szybkie googlanie podaje powody, które można załatwić
> const, albo są specyficzne dla określonego jezyka (np cachowanie
> hashy stringów, bo są często używane).
> 
> pzdr
> bartekltg

W dniu sobota, 14 października 2017 00:31:41 UTC+2 użytkownik (fir) napisał:
> W dniu wtorek, 10 października 2017 03:35:56 UTC+2 użytkownik bartekltg napisał:
> > On Monday, October 9, 2017 at 9:33:33 AM UTC+2, Wojciech Muła wrote:
> > > On Monday, October 9, 2017 at 7:23:19 AM UTC+2, bartekltg wrote:
> > > > On Saturday, October 7, 2017 at 3:20:51 PM UTC+2, Wojciech Muła wrote:
> > > > > On Saturday, October 7, 2017 at 11:16:42 AM UTC+2, Roman Tyczka wrote:
> > > > > > On Fri, 6 Oct 2017 06:08:35 -0700 (PDT), M.M. wrote:
> > > > > > 
> > > > > > >> C++ ma wybitnie spieprzony design stringów; pomysł mutowalnych
> > > > > > >> stringów jest głupi z definicji. Napis to napis, zwykła wartość.
> > > > > > >> Modyfikacja napisu nie powinna być odpowiedzialnością klasy
> > > > > > >> std::string.
> > > > > > > 
> > > > > > > I do takich wniosków doszli twórcy Javy. Osobiście jednak nie mam
> > > > > > > preferencji ani do jednego, ani do drugiego rozwiązania.
> > > > > > 
> > > > > > Czyli jak jest w Javie?
> > > > > 
> > > > > String jest immutable. Wszystkie operacje na stringach tworzą
> > > > > nowe instancje.
> > > > 
> > > > 
> > > > Ale chcieliśmy zwiększyć wydajność, nie zmniejszyć ;-)
> > > 
> > > Zacytuję klasyka: "serwery są teraz tanie". :)
> > 
> > :-)
> > 
> > Niby tak, ale w pewnym momencie trafiamy na poziom googlo facebooka
> > i takie ilości serwerów już tak tanie nie są:) Albo biolog napisał 
> > sibie na stringach przetwarzanie DNA i mi klaster zapycha...
> > 
> > A na poważnie, dlaczego string ma być immutable? 
> > Przecież moge chcieć tworzyć string literka po literce. 
> > 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. 
> > Bawiłem się chwilę (czysto rozrywkowo) c#, i tam literki stringa 
> > są immutable. Więc waliłem .ToCharArray(), robiłem swoje i 
> > konstruowałem nowego stringa. 
> > Pomijając wydajność, było to też brzydkie. 
> > std::string nie służy tylko do trzymania napisu, ale 
> > i przetwarzania, składania.   
> > 
> > Ale od drugiej strony, jakie zalety ma niezmienny string? 
> 
> niezmienny string ma na przyklad ta niebagatelna zalete ze jest niezniszczalny, nie mozna go wiec w szczegolnosci zamazac/zepsuc/zniszczyc informacje - wiekszosc stringow jest po to by niesc jakas informacje (np lądja na ekranie czy na kontrolkach itd i nie sa po to by je niszczyc)
> 
> na niejako podobnej zasadzie stringi nie sa po to by do nich pisac (tj o ile wejsciowe stringi nie sa po to by je niszczyc to wyjsciowe stringi nie sa po to by je tworzyc) dlatego ze ram nie jest po to by ja opisywac stringami dla dekoracji, jesli ktos tworzy jakis nowy string to po to by on trafil gdzies na zewnatrz a do teo mozna wykorzystac - jak pisalem printfa i stworzyc string na wyjsciu a nie w ramie
> 
> pominawszy to resizowalny string mozna zrobic dla zabawy - podalem ilustracje jak mozna i jak wlasciwie nalezy to zrobic
> 
> taki string nie bylby raczej w ogolnosci za mocny wydajnosciowo ale mialby chyba dosyc ciekawe wlasnosci 'wygodnosciowo'
> - byc moze warto nawet na ten temat troche pomyslec
> 
> ciekawa jest na przyklad opcja zmergeowania dwu takich resizowalnych stringow wtedy ten drugi po prostu znika
> 

a+=~b;


> mozna sobie powyobrazac rozne operacja na takich stringach i zbudowac pewna 'algebre' operacji na takich stringach - i to tym razem bardziej pod wzgledem wygody niz speedu (programistow c tez czasem moze byc stac na wygode ;c choc oczywiscie lepiej wiedziec co sie robi)
> 
> przyklady:
> 
> dodanie stringa na poczatku
> 
> a = b + a;
> 
> dodanie stina na koncu
> 
> a = a + b;
> 
> zmergeowanie stringow:
> 
> d=a+b+c;
> 
> a.size = 0;
> b.size = 0;
> c.size = 0;
> 
> tutaj co prawda nie wiem czy faktyczni enie warto dodac czegos w rodzaju 'destruktora' by bylo krocej
> 
> d=~a+~b+~c; //? dodaj i zresizuj na zero 
> 
> w moim siclu mam typ chunks czyli tablice chunkow a dokladnie chunk chunkow,
> 
> przy takim typie mozna dodac tez dzielenie stringow
> 
> chunks l = txt/'\n';
> 
> chunks l = "ala ma kota"/" ";
> 
> pytanie czy tekst dzilacy pownien sie znalezc w skladnikach czy powinien byc usuniety..
> 

dla uproszczenie mozna by dac na początek ze tak

dzielenia wtedy my uzyc niejako do liczeni podstringow, np

"rabarbar"/"b" 
by dalo {"ra", "ar", "ar"}
czyli
 printf("%d", ("rabarbar"/"b").size - 1 ) wypisaloby 2

dzilenie przez "r" by jednak nie dzialalo chyab zeby dodac puste stringi "". "aba", , "ba", ""  wtedy by niby dzialalo

przydala by sie funkcja na scalenie chunksa spowrotem w chunka ale nie wiem czy zwykle mnozeni by dalo rade

("rabarbar"/"r")*"x"

powinno chyba dac "xabaxbax"

pytanie jak wogole powinno dzialac odejmowanie albo jakies inne opki



> 
> co tam jeszcze....
> 
> 
> 
>  
> 
> 
> > Szybkie googlanie podaje powody, które można załatwić
> > const, albo są specyficzne dla określonego jezyka (np cachowanie
> > hashy stringów, bo są często używane).
> > 
> > pzdr
> > bartekltg

On Saturday, October 14, 2017 at 12:53:37 AM UTC+2, (fir) wrote:
> "rabarbar"/"b" 
> by dalo {"ra", "ar", "ar"}
> czyli
>  printf("%d", ("rabarbar"/"b").size - 1 ) wypisaloby 2

No dobra, nie ukrywam, że mi się podoba, ale zaraz zrobisz jakiegoś
pythono-perala z zacnego C++ ;-)

P.S.

W dniu sobota, 14 października 2017 01:13:47 UTC+2 użytkownik M.M. napisał:
> On Saturday, October 14, 2017 at 12:53:37 AM UTC+2, (fir) wrote:
> > "rabarbar"/"b" 
> > by dalo {"ra", "ar", "ar"}
> > czyli
> >  printf("%d", ("rabarbar"/"b").size - 1 ) wypisaloby 2
> 
> No dobra, nie ukrywam, że mi się podoba, ale zaraz zrobisz jakiegoś
> pythono-perala z zacnego C++ ;-)
> 
idea jest ciekawa ale wcale nie jest jasne ze latwo to dobrze dopracowac 
(a lepiej by nie bylo nie odwalic podobnej kichy jak c++, ogolnie nie jest tak latwo)

W dniu sobota, 14 października 2017 01:24:31 UTC+2 użytkownik (fir) napisał:
> W dniu sobota, 14 października 2017 01:13:47 UTC+2 użytkownik M.M. napisał:
> > On Saturday, October 14, 2017 at 12:53:37 AM UTC+2, (fir) wrote:
> > > "rabarbar"/"b" 
> > > by dalo {"ra", "ar", "ar"}
> > > czyli
> > >  printf("%d", ("rabarbar"/"b").size - 1 ) wypisaloby 2
> > 
> > No dobra, nie ukrywam, że mi się podoba, ale zaraz zrobisz jakiegoś
> > pythono-perala z zacnego C++ ;-)
> > 
> idea jest ciekawa ale wcale nie jest jasne ze latwo to dobrze dopracowac 
> (a lepiej by nie bylo nie odwalic podobnej kichy jak c++, ogolnie nie jest tak latwo)

inna rzecz ze faktycznie python pewnie ma czesc z tych rzeczy (nie pamietam niemal nic z pythona na dzis ale pewne ma cos takiego 
 ""+123 daje "123" (co tu mozna bu uzyc)
 no i na pewno ma dodawanie stringow nie wiem jak z odejmowaniem itd

faktem jest tez ze na gruncie co to nie bardzo by pasowalo bo mimo ze jakby zrobic to moglabybyc ciekawa notacja to wydajnosciowo bylaby to ciezka kicha

np sprwdzenie czy t ma podstring s by wygladalo czy moglo wygladac 
if(t-s!=t) print ( t + " contains " + s);

na gruncie takiego jezyka jak python pewnie daloby sie to nawet troche zoptymalizowac natomiast reguly c raczej kazalyby wyprodukowac t-s a pozniej porownac z t co bylaby oczywiscie zabojcze

tak ze do c to nie pasuje ale mowilem od poczatku ze re resizowalna stringi mozna potraktowac raczej jako zabawke, ktora czasem moglaby sie pewnie przydac

On Saturday, October 14, 2017 at 2:13:59 AM UTC+2, (fir) wrote:

> inna rzecz ze faktycznie python pewnie ma czesc z tych rzeczy (nie pamietam
> niemal nic z pythona na dzis ale pewne ma cos takiego 
>  ""+123 daje "123" (co tu mozna bu uzyc)
>  no i na pewno ma dodawanie stringow nie wiem jak z odejmowaniem itd

PHP i JavaScript, jako języki generujące strony html, a więc jako języki 
często wykorzystywane do przetwarzania tekstu, mają uproszczone budowanie
wyrażeń regularnych (nie trzeba pierdyliona znaków ucieczki i apostrofów),
a php może bezpośrednio zmienne rozwijać w napisach. W języku ogólnego
przeznaczenia, choć takie drobiazgi ułatwiłyby czasami życie, to korzyści
pojawiałyby się bardzo rzadko. Dlatego można żyć z C++ bez natywnych
wyrażeń regexp (a w właściwie, bez natywnych wzorców dla wyrażeń 
regularnych). Gdy w C++ piszę aplikację typowo przetwarzającą tekst to
wtedy składnia bezpośrednio w kodzie:

/wyrażenie{/replacment}/opcje/

by mi się przydała, ale ja w inny sposób uzyskuję przejrzystość. W QStringu
można osadzać poprzez %1 %2 .... %100, a QRegExp ma funkcję do dodawania
znaków ucieczki - naprawdę przez brak wspomagania napisów i regexpów (na
poziomie języka) niewiele tracę.

Pozdrawiam

W dniu sobota, 14 października 2017 12:40:09 UTC+2 użytkownik M.M. napisał:
> On Saturday, October 14, 2017 at 2:13:59 AM UTC+2, (fir) wrote:
> 
> > inna rzecz ze faktycznie python pewnie ma czesc z tych rzeczy (nie pamietam
> > niemal nic z pythona na dzis ale pewne ma cos takiego 
> >  ""+123 daje "123" (co tu mozna bu uzyc)
> >  no i na pewno ma dodawanie stringow nie wiem jak z odejmowaniem itd
> 
> PHP i JavaScript, jako języki generujące strony html, a więc jako języki 
> często wykorzystywane do przetwarzania tekstu, mają uproszczone budowanie
> wyrażeń regularnych (nie trzeba pierdyliona znaków ucieczki i apostrofów),
> a php może bezpośrednio zmienne rozwijać w napisach. W języku ogólnego
> przeznaczenia, choć takie drobiazgi ułatwiłyby czasami życie, to korzyści
> pojawiałyby się bardzo rzadko. Dlatego można żyć z C++ bez natywnych
> wyrażeń regexp (a w właściwie, bez natywnych wzorców dla wyrażeń 
> regularnych). Gdy w C++ piszę aplikację typowo przetwarzającą tekst to
> wtedy składnia bezpośrednio w kodzie:
> 
> /wyrażenie{/replacment}/opcje/
> 
> by mi się przydała, ale ja w inny sposób uzyskuję przejrzystość. W QStringu
> można osadzać poprzez %1 %2 .... %100, a QRegExp ma funkcję do dodawania
> znaków ucieczki - naprawdę przez brak wspomagania napisów i regexpów (na
> poziomie języka) niewiele tracę.
> 

co ulatwialoby zycie i jak zalezy od 
konkretnego zastosowania - ja do czytania tekstow mam swoja biblioteke sicl.c do pisania uzywam glownie printfa (ktory jest tak skomplikowany ze nie w pelni go jeszcze opanowalem tak ze nie do konca jestem w stanie wypunktowac jego braki

(aczkolwiek zdaje sie ma pewne, na przyklad nie jestem pewien ale zdaje sie ze wypisywanie tekstu w kolumnach (co by sie czasem przydalo nie zawsze dziala (choc moge tu sie mylic
bo nie mialem kiedys po prostu czasu 
na zglebianie tego)

podobnie chyba nie jest latwo go 'przeciazyc' na drukowanie wlasnego typu
(tego tez nie jestem pewien)

W dniu sobota, 14 października 2017 13:30:07 UTC+2 użytkownik (fir) napisał:
> W dniu sobota, 14 października 2017 12:40:09 UTC+2 użytkownik M.M. napisał:
> > On Saturday, October 14, 2017 at 2:13:59 AM UTC+2, (fir) wrote:
> > 
> > > inna rzecz ze faktycznie python pewnie ma czesc z tych rzeczy (nie pamietam
> > > niemal nic z pythona na dzis ale pewne ma cos takiego 
> > >  ""+123 daje "123" (co tu mozna bu uzyc)
> > >  no i na pewno ma dodawanie stringow nie wiem jak z odejmowaniem itd
> > 
> > PHP i JavaScript, jako języki generujące strony html, a więc jako języki 
> > często wykorzystywane do przetwarzania tekstu, mają uproszczone budowanie
> > wyrażeń regularnych (nie trzeba pierdyliona znaków ucieczki i apostrofów),
> > a php może bezpośrednio zmienne rozwijać w napisach. W języku ogólnego
> > przeznaczenia, choć takie drobiazgi ułatwiłyby czasami życie, to korzyści
> > pojawiałyby się bardzo rzadko. Dlatego można żyć z C++ bez natywnych
> > wyrażeń regexp (a w właściwie, bez natywnych wzorców dla wyrażeń 
> > regularnych). Gdy w C++ piszę aplikację typowo przetwarzającą tekst to
> > wtedy składnia bezpośrednio w kodzie:
> > 
> > /wyrażenie{/replacment}/opcje/
> > 
> > by mi się przydała, ale ja w inny sposób uzyskuję przejrzystość. W QStringu
> > można osadzać poprzez %1 %2 .... %100, a QRegExp ma funkcję do dodawania
> > znaków ucieczki - naprawdę przez brak wspomagania napisów i regexpów (na
> > poziomie języka) niewiele tracę.
> > 
> 
> co ulatwialoby zycie i jak zalezy od 
> konkretnego zastosowania - ja do czytania tekstow mam swoja biblioteke sicl.c do pisania uzywam glownie printfa (ktory jest tak skomplikowany ze nie w pelni go jeszcze opanowalem tak ze nie do konca jestem w stanie wypunktowac jego braki
> 
> (aczkolwiek zdaje sie ma pewne, na przyklad nie jestem pewien ale zdaje sie ze wypisywanie tekstu w kolumnach (co by sie czasem przydalo nie zawsze dziala (choc moge tu sie mylic
> bo nie mialem kiedys po prostu czasu 
> na zglebianie tego)
> 
> podobnie chyba nie jest latwo go 'przeciazyc' na drukowanie wlasnego typu
> (tego tez nie jestem pewien)

nie wiem tez jak printf (ja uzywam tego z msvcrt.dll) dzis radzi sobie z unicodem..zwykle unikam unikodu

On Saturday, October 14, 2017 at 1:30:07 PM UTC+2, (fir) wrote:

> co ulatwialoby zycie i jak zalezy od 
> konkretnego zastosowania - 
No tak. A przeładowane operatory na napisach i wsparcie dla regexpów na
poziomie jezyka ułatwia życie w bardzo konkretnych sytuacjach, 
mianowicie w aplikacjach przetwarzających tekst - o czym rozmawialiśmy w 
kilku ostatnich postach.

> ja do czytania tekstow mam swoja biblioteke sicl.c 
Pamiętam. 


> do pisania uzywam glownie printfa (ktory jest tak skomplikowany ze 
> nie w pelni go jeszcze opanowalem tak ze nie do konca jestem w 
> stanie wypunktowac jego braki
Ja też lubię starego dobrego print-efa, można szybko i wygodnie wyrzucić 
ładnie sformatowany tekst. Gorzej, gdy chcemy już po napisaniu aplikacji
eksperymentować ze zmianą typów :/

typedef double ftyp;
ftyp x = 0;
printf( "%lf" , x );

Trzeba pisać na zapas:
printf( "%lf" , (double)x );

Ale co gdy chcemy double zmienić na jakiś float256 i dokładnie wyświetlić
wszystkie cyfry znaczące? By trzeba takie manipulacje przewidzieć przed
pisaniem programu, co w przypadku doświadczonych programistów czasami 
nawet jest prawdopodobne:

printf( "%s" , toString( x ) );

Gdy jednak programiści nie przewidzą, to w przypadku użycia strumieni 
wystarczy zaledwie przedefiniować jeden operator w skali całego, dowolnie
dużego programu.


> (aczkolwiek zdaje sie ma pewne, na przyklad nie jestem pewien ale zdaje sie ze wypisywanie tekstu w kolumnach (co by sie czasem przydalo nie zawsze dziala (choc moge tu sie mylic
> bo nie mialem kiedys po prostu czasu 
> na zglebianie tego)

Działa i to w kilku wariantach.


> podobnie chyba nie jest latwo go 'przeciazyc' na drukowanie wlasnego typu
> (tego tez nie jestem pewien)
Jeśli dobrze rozumiem co masz na myśli, to właśnie wyżej napisałem, że z
tym jest problem, chyba że przed pisaniem aplikacji programiści taką
potrzebę przewidzą.

Pozdrawiam

On Saturday, October 14, 2017 at 1:33:44 PM UTC+2, (fir) wrote:

> nie wiem tez jak printf (ja uzywam tego z msvcrt.dll) dzis radzi 
> sobie z unicodem..zwykle unikam unikodu

Trzeba zajrzeć do dokumentacji, albo dać se spokój i użyć QStringa i 
QTextStream :)

Pozdrawiam

W dniu sobota, 14 października 2017 15:39:16 UTC+2 użytkownik M.M. napisał:
> On Saturday, October 14, 2017 at 1:30:07 PM UTC+2, (fir) wrote:
> 
> > co ulatwialoby zycie i jak zalezy od 
> > konkretnego zastosowania - 
> No tak. A przeładowane operatory na napisach i wsparcie dla regexpów na
> poziomie jezyka ułatwia życie w bardzo konkretnych sytuacjach, 
> mianowicie w aplikacjach przetwarzających tekst - o czym rozmawialiśmy w 
> kilku ostatnich postach.
> 

w jakich na przyklad? za jakis czas bede pisac kompilator c i to jest raczej przetwazanie tekstu

najprawdopodobniej bede potrzebowac pare specjalizowanych procedur do tego tekstu czytania

jak pisalem asembler sicl (z jego ogolnymi funkcyjkami do wyodrebniania linijek, slow i 'numberow') w zupelnosci wystarczyl.. do pisania kompilatora c bedzie potrzebne costam ciut wiecej ale pewnie nie tak duzp.. 

mozna by juz dzis troche zastanowic sie jak to zrobic ale nie wiem czy mi sie chce bo wszystko znowu dzis mnie boli 
jak diabli (so called 'constant poisoning')

pytania sa m.in. takie:

- czy przerabiac wejsciowy tekst w c 
na tekst w asmie czy na jakas inną postac? (od razu na kod binarny raczej 
odpada le moznaby na jakąs wewnetrzną 
postac binarno-symboliczna)

na razie chyab nie mam zdania w tym temacie

- jesli na tekst w asmie to i tak przetwazanie tekstu w c na tekst w asmie 
wymaga chyba jakiegos minimalnego kroku posredniego i raczej nieco 'unlikely' chyba byloby robic ten krok posredni rowniez w postaci tekstu (choc zdaje sie
jest to mozliwe)

przy tym podejsciu "text-in - text-midle - text-out" resizowalen stringi moglyby sie moze i przydac (choc muliloby to) 
/ jak regexpy to nie wiem bo nie uzywam

przy tym podejsciu typu budowanie zestawu wewnetrznych tablic z danymi - po czym na ich podstawie wygenerowanie asma albo kodu binarnego raczej nie, bo tekst wejsciowy sluzy wylaczie do czytania awyjsciowy do wypisania (raczej nie nalezy go przepisywac)

narazie jestem jednak diablo obolaly i nie bede sie tym raczej na razie zajmowac









> > ja do czytania tekstow mam swoja biblioteke sicl.c 
> Pamiętam. 
> 
> 
> > do pisania uzywam glownie printfa (ktory jest tak skomplikowany ze 
> > nie w pelni go jeszcze opanowalem tak ze nie do konca jestem w 
> > stanie wypunktowac jego braki
> Ja też lubię starego dobrego print-efa, można szybko i wygodnie wyrzucić 
> ładnie sformatowany tekst. Gorzej, gdy chcemy już po napisaniu aplikacji
> eksperymentować ze zmianą typów :/
> 
> typedef double ftyp;
> ftyp x = 0;
> printf( "%lf" , x );
> 
> Trzeba pisać na zapas:
> printf( "%lf" , (double)x );
> 
> Ale co gdy chcemy double zmienić na jakiś float256 i dokładnie wyświetlić
> wszystkie cyfry znaczące? By trzeba takie manipulacje przewidzieć przed
> pisaniem programu, co w przypadku doświadczonych programistów czasami 
> nawet jest prawdopodobne:
> 
> printf( "%s" , toString( x ) );
> 
> Gdy jednak programiści nie przewidzą, to w przypadku użycia strumieni 
> wystarczy zaledwie przedefiniować jeden operator w skali całego, dowolnie
> dużego programu.
> 
> 
> > (aczkolwiek zdaje sie ma pewne, na przyklad nie jestem pewien ale zdaje sie ze wypisywanie tekstu w kolumnach (co by sie czasem przydalo nie zawsze dziala (choc moge tu sie mylic
> > bo nie mialem kiedys po prostu czasu 
> > na zglebianie tego)
> 
> Działa i to w kilku wariantach.
> 
> 
> > podobnie chyba nie jest latwo go 'przeciazyc' na drukowanie wlasnego typu
> > (tego tez nie jestem pewien)
> Jeśli dobrze rozumiem co masz na myśli, to właśnie wyżej napisałem, że z
> tym jest problem, chyba że przed pisaniem aplikacji programiści taką
> potrzebę przewidzą.
> 
> Pozdrawiam

On Saturday, October 14, 2017 at 5:23:53 PM UTC+2, (fir) wrote:
> W dniu sobota, 14 października 2017 15:39:16 UTC+2 użytkownik M.M. napisał:
> > On Saturday, October 14, 2017 at 1:30:07 PM UTC+2, (fir) wrote:
> > 
> > > co ulatwialoby zycie i jak zalezy od 
> > > konkretnego zastosowania - 
> > No tak. A przeładowane operatory na napisach i wsparcie dla regexpów na
> > poziomie jezyka ułatwia życie w bardzo konkretnych sytuacjach, 
> > mianowicie w aplikacjach przetwarzających tekst - o czym rozmawialiśmy w 
> > kilku ostatnich postach.
> > 
> 
> w jakich na przyklad? 
Wybacz, nie mam siły cytować.


> za jakis czas bede pisac kompilator c 
Po co?


> i to jest raczej przetwazanie tekstu
Tylko w początkowej fazie.


> najprawdopodobniej bede potrzebowac pare specjalizowanych procedur do 
> tego tekstu czytania
Przy pisaniu kompilatora są inne ważniejsze problemy.




> jak pisalem asembler sicl (z jego ogolnymi funkcyjkami do wyodrebniania
> linijek, slow i 'numberow') w zupelnosci wystarczyl.. do 
> pisania kompilatora c bedzie potrzebne costam ciut wiecej ale pewnie 
> nie tak duzp.. 
Do wyodrębnienia tokenów wystarczy to samo :) Ale w C, w przeciwieństwie
do asemblera, jest rekurencyjna struktura. Moje parsery do języków
programowania mają stany. Stanem jest np. "jestem w funkcji", "jestem w
klasie", "jestem w pętli for", "jestem w ciągu znaków", itd. Każdy stan
ma funkcję, funkcje wywołują się rekurencyjnie... Tego w (nie-makro)
asemblerach nie ma.


> mozna by juz dzis troche zastanowic sie jak to zrobic ale nie wiem 
> czy mi sie chce bo wszystko znowu dzis mnie boli 
> jak diabli (so called 'constant poisoning')
Aż tak mocno boli, że apap i ibum nie pomaga?


> pytania sa m.in. takie:
> 
> - czy przerabiac wejsciowy tekst w c 
> na tekst w asmie czy na jakas inną postac? 
Jeśli odpowiesz mi na pytanie, po co pisać kompilator C, to może
będę umiał odpowiedzieć na to pytanie.



> (od razu na kod binarny raczej 
> odpada le moznaby na jakąs wewnetrzną 
> postac binarno-symboliczna)
> na razie chyab nie mam zdania w tym temacie
Ja też na razie nie wiem.


> - jesli na tekst w asmie to i tak przetwazanie tekstu w c na tekst w asmie 
> wymaga chyba jakiegos minimalnego kroku posredniego i raczej nieco 'unlikely'
> chyba byloby robic ten krok posredni rowniez w postaci tekstu 
Jeśli to ma być standard do dalszej przeróbki, (np. dla 
optymalizatorów), to postać tekstowa jest dobra.


> (choc zdaje sie
> jest to mozliwe)
> 
> przy tym podejsciu "text-in - text-midle - text-out" resizowalen 
> stringi moglyby sie moze i przydac (choc muliloby to) 
> / jak regexpy to nie wiem bo nie uzywam

Zobacz ile pracy włożono w napisanie kompilatorów. Gdy włożysz podobną
ilość, to będziesz wiedział co jest wąskim gardłem i czy warto się
martwić zamulaniem dynamicznymi stringami.




> przy tym podejsciu typu budowanie zestawu wewnetrznych tablic z 
> danymi - po czym na ich podstawie wygenerowanie asma albo kodu 
> binarnego raczej nie, bo tekst wejsciowy sluzy wylaczie do 
> czytania awyjsciowy do wypisania (raczej nie nalezy go przepisywac)
Nie rozumiem.


> narazie jestem jednak diablo obolaly i nie bede sie tym raczej 
> na razie zajmowac

Fir, Ty nie pi#$dol, tyko pisz ten kompilator ;-)

Zdrowia

W dniu sobota, 14 października 2017 20:12:36 UTC+2 użytkownik M.M. napisał:
> On Saturday, October 14, 2017 at 5:23:53 PM UTC+2, (fir) wrote:
> > W dniu sobota, 14 października 2017 15:39:16 UTC+2 użytkownik M.M. napisał:
> > > On Saturday, October 14, 2017 at 1:30:07 PM UTC+2, (fir) wrote:
> > > 
> > > > co ulatwialoby zycie i jak zalezy od 
> > > > konkretnego zastosowania - 
> > > No tak. A przeładowane operatory na napisach i wsparcie dla regexpów na
> > > poziomie jezyka ułatwia życie w bardzo konkretnych sytuacjach, 
> > > mianowicie w aplikacjach przetwarzających tekst - o czym rozmawialiśmy w 
> > > kilku ostatnich postach.
> > > 
> > 
> > w jakich na przyklad? 
> Wybacz, nie mam siły cytować.
> 
> 
> > za jakis czas bede pisac kompilator c 
> Po co?
> 
> 
> > i to jest raczej przetwazanie tekstu
> Tylko w początkowej fazie.
> 
> 
> > najprawdopodobniej bede potrzebowac pare specjalizowanych procedur do 
> > tego tekstu czytania
> Przy pisaniu kompilatora są inne ważniejsze problemy.
> 
> 
> 
> 
> > jak pisalem asembler sicl (z jego ogolnymi funkcyjkami do wyodrebniania
> > linijek, slow i 'numberow') w zupelnosci wystarczyl.. do 
> > pisania kompilatora c bedzie potrzebne costam ciut wiecej ale pewnie 
> > nie tak duzp.. 
> Do wyodrębnienia tokenów wystarczy to samo :) Ale w C, w przeciwieństwie
> do asemblera, jest rekurencyjna struktura. Moje parsery do języków
> programowania mają stany. Stanem jest np. "jestem w funkcji", "jestem w
> klasie", "jestem w pętli for", "jestem w ciągu znaków", itd. Każdy stan
> ma funkcję, funkcje wywołują się rekurencyjnie... Tego w (nie-makro)
> asemblerach nie ma.
> 
> 
> > mozna by juz dzis troche zastanowic sie jak to zrobic ale nie wiem 
> > czy mi sie chce bo wszystko znowu dzis mnie boli 
> > jak diabli (so called 'constant poisoning')
> Aż tak mocno boli, że apap i ibum nie pomaga?
> 
> 
> > pytania sa m.in. takie:
> > 
> > - czy przerabiac wejsciowy tekst w c 
> > na tekst w asmie czy na jakas inną postac? 
> Jeśli odpowiesz mi na pytanie, po co pisać kompilator C, to może
> będę umiał odpowiedzieć na to pytanie.
> 
> 
> 
> > (od razu na kod binarny raczej 
> > odpada le moznaby na jakąs wewnetrzną 
> > postac binarno-symboliczna)
> > na razie chyab nie mam zdania w tym temacie
> Ja też na razie nie wiem.
> 
> 
> > - jesli na tekst w asmie to i tak przetwazanie tekstu w c na tekst w asmie 
> > wymaga chyba jakiegos minimalnego kroku posredniego i raczej nieco 'unlikely'
> > chyba byloby robic ten krok posredni rowniez w postaci tekstu 
> Jeśli to ma być standard do dalszej przeróbki, (np. dla 
> optymalizatorów), to postać tekstowa jest dobra.
> 
> 
> > (choc zdaje sie
> > jest to mozliwe)
> > 
> > przy tym podejsciu "text-in - text-midle - text-out" resizowalen 
> > stringi moglyby sie moze i przydac (choc muliloby to) 
> > / jak regexpy to nie wiem bo nie uzywam
> 
> Zobacz ile pracy włożono w napisanie kompilatorów. Gdy włożysz podobną
> ilość, to będziesz wiedział co jest wąskim gardłem i czy warto się
> martwić zamulaniem dynamicznymi stringami.
> 
> 
> 
> 
> > przy tym podejsciu typu budowanie zestawu wewnetrznych tablic z 
> > danymi - po czym na ich podstawie wygenerowanie asma albo kodu 
> > binarnego raczej nie, bo tekst wejsciowy sluzy wylaczie do 
> > czytania awyjsciowy do wypisania (raczej nie nalezy go przepisywac)
> Nie rozumiem.
> 
> 
> > narazie jestem jednak diablo obolaly i nie bede sie tym raczej 
> > na razie zajmowac
> 
dzis czuje sie fatalnie, mam tak zresztą dosyc czesto, watroba i nery chya rozwalone bo pieka strasznie i jakos to przeklada sie chyba na zly stan krwii bo od tego pozniej paskudnie swedzą i pieką mnie zyly w calym ciele

kompilator c glownie chce napisac by moc wniesc i potestowac swoje poprawki do c
- pisanie kompilatora c wydaje sie to 
byc projekt sredniej trdnosci jak na dzis, nie taki trudny da sie to prawdopodobnie zrobic w pare czy parenascie tysiecy lini kodu  w pierwszej wersji - tyle ze jednak zanim sie za to zabiore trzeba bedzie porzadnie odpocząc
i moze zrobic po drodze pare innych prozdrowotnych projektow 'na rozluznienie' i 'na wzmocenienie', tak ze chyba dam sobie jeszcze chyba z rok odpoczynku
(zeby cos takiego zrobic wydaje mi sie
 musze naladowac baterie by mi sie naprawde chcialo to robic, w innym wypadku robilbym to na sile a to nie jest dobre)

inna rzecz ze prawdopodobnie powinienem isc i budowac od mojego asemblera w gore
a nie od c w dól do mojego asemblera
(ale na to tez musze dac sobie troche czasu)

On Saturday, October 14, 2017 at 9:46:37 PM UTC+2, (fir) wrote:
> dzis czuje sie fatalnie, 
Wiele osób tak ma. Nie będę Ci wymieniał moich problemów. Ja biorę co
rano prochy, kawę i daję radę. Kiedyś przez przypadek znalazłem lek
który dość dobrze mi pomaga. Nie ma procha na Twoje problemy?


> mam tak zresztą dosyc czesto
Wiele osób tak ma, moje problemy też są niewyleczalne, ale można doraźnie
pomagać.


> watroba i nery chya rozwalone bo pieka strasznie i jakos to 
> przeklada sie chyba na zly stan krwii bo od tego pozniej 
> paskudnie swedzą i pieką mnie zyly w calym ciele
I nie ma żadnej rady na to?


> kompilator c glownie chce napisac by moc wniesc i potestowac 
> swoje poprawki do c
Czyli chcesz stworzyć swój język wraz z kompilatorem, a doświadczenia 
chcesz zdobyć najpierw na języku C. Jeśli Twój język będzie miał
nieznaczne poprawki względem języka C, to naprawdę nie warto. Jeśli
stworzysz nowy język to... niektórzy powiedzą że nowe języki powinny
powstawać aby wybierać z pośród dużej puli narzędzia jakie się 
lubi i/albo jakie są optymalne do danego zadania. Ja mówię że też
nie warto, bo im więcej różnorodnych narzędzi tym trudniej odnaleźć
się w nowym projekcie, bo prawdopodobnie zrobiony jest w czymś, z
czym programista wcześniej nie miał do czynienia.


> - pisanie kompilatora c wydaje sie to 
> byc projekt sredniej trdnosci jak na dzis, 
Zwróć uwagę, że obecne kompilatory są niedokończone a jak dużo pracy już w
nie włożono. Ciągle można zrobić w kompilatorach lepszą optymalizacja kodu.


> nie taki trudny da sie to prawdopodobnie zrobic w pare czy parenascie 
> tysiecy lini kodu  w pierwszej wersji - 
Tyle że to będzie badziew w porównaniu do istniejących kompilatorów.
Pamiętaj, że możesz napisać swój język kompilowany do języka C z
wstawkami asemblera.


> tyle ze jednak zanim sie za to zabiore trzeba bedzie porzadnie odpocząc
> i moze zrobic po drodze pare innych prozdrowotnych projektow 'na
> rozluznienie' i 'na wzmocenienie', tak ze chyba dam sobie jeszcze 
> chyba z rok odpoczynku
Podświadomość - nad trudnym myślisz w tle, gdy łatwymi rzucasz z rękawa.
Trudny projekt dojrzewa latami równolegle gdy się robi łatwe. 



> (zeby cos takiego zrobic wydaje mi sie
>  musze naladowac baterie by mi sie naprawde chcialo to robic, w 
> innym wypadku robilbym to na sile a to nie jest dobre)
Trzeba się po prostu dobrze zastanowić.



> inna rzecz ze prawdopodobnie powinienem isc i budowac od mojego 
> asemblera w gore
> a nie od c w dól do mojego asemblera
> (ale na to tez musze dac sobie troche czasu)
Nie wiem, ja, jakbym robił nowy język, to bym zrobił kompilowany 
do C, ewentualnie z wstawkami asemblera.

Pozdrawiam

W dniu niedziela, 15 października 2017 13:39:33 UTC+2 użytkownik M.M. napisał:
> On Saturday, October 14, 2017 at 9:46:37 PM UTC+2, (fir) wrote:
> > dzis czuje sie fatalnie, 
> Wiele osób tak ma. Nie będę Ci wymieniał moich problemów. Ja biorę co
> rano prochy, kawę i daję radę. Kiedyś przez przypadek znalazłem lek
> który dość dobrze mi pomaga. Nie ma procha na Twoje problemy?
> 
> 
> > mam tak zresztą dosyc czesto
> Wiele osób tak ma, moje problemy też są niewyleczalne, ale można doraźnie
> pomagać.
> 
> 
> > watroba i nery chya rozwalone bo pieka strasznie i jakos to 
> > przeklada sie chyba na zly stan krwii bo od tego pozniej 
> > paskudnie swedzą i pieką mnie zyly w calym ciele
> I nie ma żadnej rady na to?
> 
> 
no nie wiem, moze heroina.. ?

powaznie mowiac to nie spodziewam sie 
ze ktos mi tutaj zaproponuje lekarstwo - pisze bo jest czasem tak ze jak o czyms mysle to te moje fizykalne męki organicznie mieszają sie jakby z tym o czym pisze - i dla mnie nienaturalnie byloby je rozdzialac - pisze wiec jakby dla kompletnosci, Pominowszy to samo 'narzekanie' daje troche ulgi - dla mnie typowe jest ze jak mnie cos boli to jak sie na tym zaczynam mocno koncentrowac (biore to na warszatat) to zwykle troche pomaga - te bole zreszta nachodza mnie fazami, (czasem słabną) - ostanio jest akurat ta faza ze jest gorzej

W dniu niedziela, 15 października 2017 13:54:56 UTC+2 użytkownik (fir) napisał:
> W dniu niedziela, 15 października 2017 13:39:33 UTC+2 użytkownik M.M. napisał:
> > On Saturday, October 14, 2017 at 9:46:37 PM UTC+2, (fir) wrote:
> > > dzis czuje sie fatalnie, 
> > Wiele osób tak ma. Nie będę Ci wymieniał moich problemów. Ja biorę co
> > rano prochy, kawę i daję radę. Kiedyś przez przypadek znalazłem lek
> > który dość dobrze mi pomaga. Nie ma procha na Twoje problemy?
> > 
> > 
> > > mam tak zresztą dosyc czesto
> > Wiele osób tak ma, moje problemy też są niewyleczalne, ale można doraźnie
> > pomagać.
> > 
> > 
> > > watroba i nery chya rozwalone bo pieka strasznie i jakos to 
> > > przeklada sie chyba na zly stan krwii bo od tego pozniej 
> > > paskudnie swedzą i pieką mnie zyly w calym ciele
> > I nie ma żadnej rady na to?
> > 
> > 
> no nie wiem, moze heroina.. ?
> 
> powaznie mowiac to nie spodziewam sie 
> ze ktos mi tutaj zaproponuje lekarstwo - pisze bo jest czasem tak ze jak o czyms mysle to te moje fizykalne męki organicznie mieszają sie jakby z tym o czym pisze - i dla mnie nienaturalnie byloby je rozdzialac - pisze wiec jakby dla kompletnosci, Pominowszy to samo 'narzekanie' daje troche ulgi - dla mnie typowe jest ze jak mnie cos boli to jak sie na tym zaczynam mocno koncentrowac (biore to na warszatat) to zwykle troche pomaga - te bole zreszta nachodza mnie fazami, (czasem słabną) - ostanio jest akurat ta faza ze jest gorzej

[to wyzej to czywiscie bardzo wyrywkowy 'opis' zagadnienia - ale ostatnio nie jestem w formie (z forma coraz gorzej)]

prawdą jest tak ze jak czlowiek duzo koduje to bardzo zapomina o kondycji,
- jak cos zaczyna bolec to jest wtedy 
jakby naturalny asumpt by o tej kondycji minimalnie sobie przypomniec i dla mnie
to jest dobre "chciec przypominac sobie o tym"
(ktos moglby wtedy powiedziec ze wtedy nalezaloby odstawic kodowanie i skupic sie na formie - ale dla mnie jakos wygodne jest robic jedno i drugie naraz ;c kodowanie pomaga chyba utrzymac kontracje a na samym oboleniu nie moglbym sie chyba tak bardzo skupiac, nudzilbym sie)
- szkoda nieststy ze nie widze zbyt jasno tych kwestii moje moce mentalne (te ktore pozwalaja dosyc wiernie spenetrowac jakies logiczne zagadnienie i orzec cos z sensem) oslably

W dniu niedziela, 15 października 2017 14:06:13 UTC+2 użytkownik (fir) napisał:
> - szkoda nieststy ze nie widze zbyt jasno tych kwestii moje moce mentalne (te ktore pozwalaja dosyc wiernie spenetrowac jakies logiczne zagadnienie i orzec cos z sensem) oslably

one oslably bo same wymagaja duzego napiecia/ koncentracji tj koncentracji
i treningu

kodowanie i moce mentalne (tak jak je tutaj rozumiem *)  to dwie rozne rzeczy,
nieststy ja w ostatnich latach o wiele
lepiej stoje z kodowania o wiele gorzej z
ogolnikowych mocy mentalnych 



* (- w skrocie moge powiedziec ze to takie "myslenie bardziej humanistyczne", takie jak przy czytaniu dobrych ksiazek itd)

W dniu sobota, 14 października 2017 15:45:48 UTC+2 użytkownik M.M. napisał:
> On Saturday, October 14, 2017 at 1:33:44 PM UTC+2, (fir) wrote:
> 
> > nie wiem tez jak printf (ja uzywam tego z msvcrt.dll) dzis radzi 
> > sobie z unicodem..zwykle unikam unikodu
> 
> Trzeba zajrzeć do dokumentacji, albo dać se spokój i użyć QStringa i 
> QTextStream :)
> 
> Pozdrawiam

unicode jest wspierany w winidzie bardzo dawno chyba od win95 (byc moze tylko w swym dialekcie utf-16, nie pamietam)

natomiast czy i od kiedy jest wspierany 
w c to nie wiem - ale chyba tez jest wspierany

tak ze raczej powinno chyba dzialac tyle ze nie uzywalem jeszcze

(ogolnie t pamietam byl kiedys watek o unikode i ja optowalem a utf-32 (tak samo jak optuje za zrobienie 32-bitowych bajtow) aczkolwiek trzeba przyznac ze na
obecnym starym gruncie utf-8 wydaje sie 
z pewnych wzgledow bardzo praktyczny)

On Sunday, October 15, 2017 at 1:54:56 PM UTC+2, (fir) wrote:
> W dniu niedziela, 15 października 2017 13:39:33 UTC+2 użytkownik M.M. napisał:
> > On Saturday, October 14, 2017 at 9:46:37 PM UTC+2, (fir) wrote:
> > > dzis czuje sie fatalnie, 
> > Wiele osób tak ma. Nie będę Ci wymieniał moich problemów. Ja biorę co
> > rano prochy, kawę i daję radę. Kiedyś przez przypadek znalazłem lek
> > który dość dobrze mi pomaga. Nie ma procha na Twoje problemy?
> > 
> > 
> > > mam tak zresztą dosyc czesto
> > Wiele osób tak ma, moje problemy też są niewyleczalne, ale można doraźnie
> > pomagać.
> > 
> > 
> > > watroba i nery chya rozwalone bo pieka strasznie i jakos to 
> > > przeklada sie chyba na zly stan krwii bo od tego pozniej 
> > > paskudnie swedzą i pieką mnie zyly w calym ciele
> > I nie ma żadnej rady na to?
> > 
> > 
> no nie wiem, moze heroina.. ?
> 
> powaznie mowiac to nie spodziewam sie 
> ze ktos mi tutaj zaproponuje lekarstwo - pisze bo jest czasem tak ze jak o czyms mysle to te moje fizykalne męki organicznie mieszają sie jakby z tym o czym pisze - i dla mnie nienaturalnie byloby je rozdzialac - pisze wiec jakby dla kompletnosci, Pominowszy to samo 'narzekanie' daje troche ulgi - dla mnie typowe jest ze jak mnie cos boli to jak sie na tym zaczynam mocno koncentrowac (biore to na warszatat) to zwykle troche pomaga - te bole zreszta nachodza mnie fazami, (czasem słabną) - ostanio jest akurat ta faza ze jest gorzej

A po prostu jak se łykniesz ibuma albo apapa plus leki specjalistyczne
na Twoje dolegliwości? Dużo osób tak robi. Znam gościa z problemem 
ortopedycznym dotyczącym nóg, bolą go kości bardzo mocno, normalnie by 
się nawet nie wyspał. Ma jakiś lek dostosowany do tego rodzaju bólu, 
codziennie bierze od wielu lat i... na rowerze go nie mogę dogonić.

Pozdrawiam

co do QT itd to ja jak nie raz juz pisalem wole pisac na czyste winapi - wtedy 1) nie dosc ze nie mam redystrybuabli to 2) wszystko dobrze dziala do tego 3) poznaje system - mysle ostatnio by zrobic sobie kolejny tour po winapi by jeszcze lepiej poznac jego tajniki, ale nie wiem czy dam rade bo faktycznie to moje zdrowie sie jeszzcze bardzeiej pogorszylo, rwacy bol mnie kompletnie rozwala przeszkadza nawet w czytaniu

On Sun, 15 Oct 2017 09:57:39 -0700 (PDT), M.M. wrote:

> A po prostu jak se łykniesz ibuma albo apapa plus leki specjalistyczne
> na Twoje dolegliwości? Dużo osób tak robi. Znam gościa z problemem 
> ortopedycznym dotyczącym nóg, bolą go kości bardzo mocno, normalnie by 
> się nawet nie wyspał. Ma jakiś lek dostosowany do tego rodzaju bólu, 
> codziennie bierze od wielu lat i... na rowerze go nie mogę dogonić.

fira męczy borelioza, apapem tego nie wyleczysz

-- 
pozdrawiam
Roman Tyczka

On Sat, 14 Oct 2017 08:23:52 -0700 (PDT), (fir) wrote:

> w jakich na przyklad? za jakis czas bede pisac kompilator c i to jest raczej przetwazanie tekstu

Może byś się zainteresował LLVM:

https://en.wikipedia.org/wiki/LLVM

i kompilował do kodu pośredniego:

https://en.wikipedia.org/wiki/Intermediate_representation

To by mogło dać dobry efekt w skończonym czasie.

-- 
pozdrawiam
Roman Tyczka

W dniu środa, 18 października 2017 17:51:15 UTC+2 użytkownik Roman Tyczka napisał:
> On Sun, 15 Oct 2017 09:57:39 -0700 (PDT), M.M. wrote:
> 
> > A po prostu jak se łykniesz ibuma albo apapa plus leki specjalistyczne
> > na Twoje dolegliwości? Dużo osób tak robi. Znam gościa z problemem 
> > ortopedycznym dotyczącym nóg, bolą go kości bardzo mocno, normalnie by 
> > się nawet nie wyspał. Ma jakiś lek dostosowany do tego rodzaju bólu, 
> > codziennie bierze od wielu lat i... na rowerze go nie mogę dogonić.
> 
> fira męczy borelioza, apapem tego nie wyleczysz
> 
teraz mnie meczy cos innego borelioze przechodzilem okolo 2008-9 (najciezej bo pozniej bole tez), sek w tym ze chyba rozwalilem wtedy watrobe i ew jakies inne organy wewn (wyniki badan krwi wychodzą mi zle (poa normami itd), ale wg lekarki nie tak drastycznie zle by oplacalo sie cos z tym radykalnie robic (do czego i ja sie przychylam poniekad dlatego ze wiem jak jest i nie wierze jakos w profesjonalizm tego leczenia, obawiam sie ze sonczylbym po nim w gorszym stanie niz jestem teraz, stan zdrowia mam jednak duzo gorszy niz powinienem miec)

W dniu środa, 18 października 2017 18:00:18 UTC+2 użytkownik Roman Tyczka napisał:
> On Sat, 14 Oct 2017 08:23:52 -0700 (PDT), (fir) wrote:
> 
> > w jakich na przyklad? za jakis czas bede pisac kompilator c i to jest raczej przetwazanie tekstu
> 
> Może byś się zainteresował LLVM:
> 
> https://en.wikipedia.org/wiki/LLVM
> 
> i kompilował do kodu pośredniego:
> 
> https://en.wikipedia.org/wiki/Intermediate_representation
> 
> To by mogło dać dobry efekt w skończonym czasie.
> 
napisanie kompilatora nie jest takie trudne, 
co musisz zrobic? wczytac kod funkcji, rozpoznac predefiniownane konstrukcje i wygenerowac kod - bedac porzadnie wypoczetym gros (wiekszosc) tej roboty mysle moglbym wykonac w tydzien **

spokojnie dam rade, warunkiem jest jednak to ze musze byc naprawde wypoczety bo jak juz sie robi ten kod to trzeba sie zanurzyc w skupienieu i trzeba miec zapas energetyczny (zapas energii)

pomoc mogloby tez wstepne przemyslenie i przetrenowanie paru kawalkow (wtedy to wstepne przetrenowanie odciazy mnie pozniej w glownej robocie)


** to co prawda przy podejsciu z gory do dolu, alternatywnym podejsciem jest przybudowanie asemblera w gore - to drugie byc moze jest trudniejsze (bardziej powolne i byc moze bardziej meczace, wymaga przemyslenia poszczegolnych krokow 0 ale jest tez 
byc moze lepsze /bardziej pro - jeszcze nie wiem ktora droge mam zamiar obrac

On Wednesday, October 18, 2017 at 6:16:00 PM UTC+2, (fir) wrote:
> W dniu środa, 18 października 2017 18:00:18 UTC+2 użytkownik Roman Tyczka napisał:
> > On Sat, 14 Oct 2017 08:23:52 -0700 (PDT), (fir) wrote:
> > 
> > > w jakich na przyklad? za jakis czas bede pisac kompilator c i to jest raczej przetwazanie tekstu
> > 
> > Może byś się zainteresował LLVM:
> > 
> > https://en.wikipedia.org/wiki/LLVM
> > 
> > i kompilował do kodu pośredniego:
> > 
> > https://en.wikipedia.org/wiki/Intermediate_representation
> > 
> > To by mogło dać dobry efekt w skończonym czasie.
> > 
> napisanie kompilatora nie jest takie trudne, 
Dla mnie jest.


> co musisz zrobic? wczytac kod funkcji, rozpoznac predefiniownane 
> konstrukcje i wygenerowac kod - bedac porzadnie wypoczetym gros 
> (wiekszosc) tej roboty mysle moglbym wykonac w tydzien **
Hmmm. Osobiście wykonałem, jak już wspominałem, kilka 
programów do przetwarzania plików napisanych w różnych językach 
programowania, np. w C, C++, PHP, JS, HTML, CSS. Mój program
rozbija pliki źródłowe na rekurencyjną strukturę tokenów i generuje
jakieś wyniki, np. dla C i C++ buduje lepsze pliki make niż
program QMake. Tak więc te programy robią zadanie znacznie 
prostsze niż kompilacja, a napisanie ich zajęło mi kilka dni.
Ostatni błąd w tych programach znalazłem jakieś pół roku po 
tym, jak dzień w dzień ich używałem... Nie wiem jak wyobrażasz
sobie napisanie całego kompilatora przez jedną osobę w mniej
niż wiele miesięcy. Może chcesz kompilator złożyć z gotowych
klocków, a nie napisać?

 
> spokojnie dam rade, warunkiem jest jednak to ze musze byc naprawde 
> wypoczety bo jak juz sie robi ten kod to trzeba sie zanurzyc w 
> skupienieu i trzeba miec zapas energetyczny (zapas energii)
Jak użyjesz jakiś gotowców, to może i w godzinę dasz radę.


> pomoc mogloby tez wstepne przemyslenie i przetrenowanie paru 
> kawalkow (wtedy to wstepne przetrenowanie odciazy mnie pozniej 
> w glownej robocie)
> 
> 
> ** to co prawda przy podejsciu z gory do dolu, alternatywnym podejsciem jest przybudowanie asemblera w gore - to drugie byc moze jest trudniejsze (bardziej powolne i byc moze bardziej meczace, wymaga przemyslenia poszczegolnych krokow 0 ale jest tez 
> byc moze lepsze /bardziej pro - jeszcze nie wiem ktora droge mam zamiar obrac

Hmmmm ja w ogóle nie wiem. Moim zdaniem pisanie kompilatora to bardzo 
pracochłonne zadanie, a pisanie optymalizatorów, które w krótkim czasie
wygenerują lepszy kod niż najnowszy gcc, jest zadaniem i pracochłonnym, i
bardzo trudnym.

Pozdrawiam