🚀 go-pugleaf

W dniu poniedziałek, 9 października 2017 07:23:19 UTC+2 użytkownik bartekltg napisał:
> 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ć ;-)
> 
pisanie do stringa jest bardzo malo uzyteczne - rzadko spotykane (dla mnie niemal jak yeti mimo ze ostatnio pisalem nawet cos co operuje na tekstach np swoj asembler x86 czy ostatnio klienta irca)

zwykle jako output operacji na stringach zamiast pisania do tablicy (a co tu mowic o pisaniu do strainga) wystarczy printf() (na konsole albo do pliku)

W dniu poniedziałek, 9 października 2017 14:30:37 UTC+2 użytkownik (fir) napisał:
> W dniu poniedziałek, 9 października 2017 07:23:19 UTC+2 użytkownik bartekltg napisał:
> > 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ć ;-)
> > 
> pisanie do stringa jest bardzo malo uzyteczne - rzadko spotykane (dla mnie niemal jak yeti mimo ze ostatnio pisalem nawet cos co operuje na tekstach np swoj asembler x86 czy ostatnio klienta irca)
> 
> zwykle jako output operacji na stringach zamiast pisania do tablicy (a co tu mowic o pisaniu do strainga) wystarczy printf() (na konsole albo do pliku)

co zarazem nie znaczy ze jak ktos chce to realokowalnego stringa mozna sobie zrobic, (np bardzo latwo w c)* - zwlaszcza ze ostatnio przekonalem sie troche do reallocka 

*zob watek "resizable chunks and typesafety" z 11 wrzesnia (i moja nowatorska biblioteke small-icl.c)


 typedef struct
  {
    char* beg;
    char* end;
  }
    chunk;

chunk ResizeChunk(chunk x, int size)
{
    x.beg = (char*) realloc(x.beg, size );

    if((size>0) && (x.beg==NULL)) ERROR_EXIT("AllocChunk failed");

    x.end = x.beg + size -1;
    return x;
}


void main()
{
  chunk dipa;

  dipa = ResizeChunk(dipa, 10);

  dipa = ResizeChunk(dipa, 1000);

}

jako ze reallock 'cacheuje' czy jak to nazwac rezerwe ramu (i to dosyc agresywnie ) to bedzie dzialac calkiem szybko 
(aczkolwiek moja biblioteka sicl jest bardziej oparta na splitach i indeksowaniu (czyli nie zmienia np ramu do ktorego np wpisano plik tekstowy jedynie go indeksuje na wskazniki i pozwala wybrac to co nas 
interesuje co z kolei zwykle zrzuca sie do outputu 
wlasnie printfem czy czyms podovnym, jest to rozwiazanie chyba bliskie idealu)

W dniu poniedziałek, 9 października 2017 14:48:08 UTC+2 użytkownik (fir) napisał:
> W dniu poniedziałek, 9 października 2017 14:30:37 UTC+2 użytkownik (fir) napisał:
> > W dniu poniedziałek, 9 października 2017 07:23:19 UTC+2 użytkownik bartekltg napisał:
> > > 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ć ;-)
> > > 
> > pisanie do stringa jest bardzo malo uzyteczne - rzadko spotykane (dla mnie niemal jak yeti mimo ze ostatnio pisalem nawet cos co operuje na tekstach np swoj asembler x86 czy ostatnio klienta irca)
> > 
> > zwykle jako output operacji na stringach zamiast pisania do tablicy (a co tu mowic o pisaniu do strainga) wystarczy printf() (na konsole albo do pliku)
> 
> co zarazem nie znaczy ze jak ktos chce to realokowalnego stringa mozna sobie zrobic, (np bardzo latwo w c)* - zwlaszcza ze ostatnio przekonalem sie troche do reallocka 
> 
> *zob watek "resizable chunks and typesafety" z 11 wrzesnia (i moja nowatorska biblioteke small-icl.c)
> 
> 
>  typedef struct
>   {
>     char* beg;
>     char* end;
>   }
>     chunk;
> 
> chunk ResizeChunk(chunk x, int size)
> {
>     x.beg = (char*) realloc(x.beg, size );
> 
>     if((size>0) && (x.beg==NULL)) ERROR_EXIT("AllocChunk failed");
> 
>     x.end = x.beg + size -1;
>     return x;
> }
> 
> 
> void main()
> {
>   chunk dipa;
> 
>   dipa = ResizeChunk(dipa, 10);
> 
>   dipa = ResizeChunk(dipa, 1000);
> 
> }
> 
> jako ze reallock 'cacheuje' czy jak to nazwac rezerwe ramu (i to dosyc agresywnie ) to bedzie dzialac calkiem szybko 
> (aczkolwiek moja biblioteka sicl jest bardziej oparta na splitach i indeksowaniu (czyli nie zmienia np ramu do ktorego np wpisano plik tekstowy jedynie go indeksuje na wskazniki i pozwala wybrac to co nas 
> interesuje co z kolei zwykle zrzuca sie do outputu 
> wlasnie printfem czy czyms podovnym, jest to rozwiazanie chyba bliskie idealu)

realizuje to przy tym moja idee stringa czyli ani nie zero na koncu a nie nie basicowe rozmiar na oczatku,
dobry string imo to para dwu wskaznikow begin i end begin pokazuje na pierwszy znak end na ostatni (wcielilem ta idee w zycie i nazwalem taki obiekt chunk - biblioteka sicl jest tego konsekwencją)

W dniu poniedziałek, 9 października 2017 14:54:07 UTC+2 użytkownik (fir) napisał:
> W dniu poniedziałek, 9 października 2017 14:48:08 UTC+2 użytkownik (fir) napisał:
> > W dniu poniedziałek, 9 października 2017 14:30:37 UTC+2 użytkownik (fir) napisał:
> > > W dniu poniedziałek, 9 października 2017 07:23:19 UTC+2 użytkownik bartekltg napisał:
> > > > 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ć ;-)
> > > > 
> > > pisanie do stringa jest bardzo malo uzyteczne - rzadko spotykane (dla mnie niemal jak yeti mimo ze ostatnio pisalem nawet cos co operuje na tekstach np swoj asembler x86 czy ostatnio klienta irca)
> > > 
> > > zwykle jako output operacji na stringach zamiast pisania do tablicy (a co tu mowic o pisaniu do strainga) wystarczy printf() (na konsole albo do pliku)
> > 
> > co zarazem nie znaczy ze jak ktos chce to realokowalnego stringa mozna sobie zrobic, (np bardzo latwo w c)* - zwlaszcza ze ostatnio przekonalem sie troche do reallocka 
> > 
> > *zob watek "resizable chunks and typesafety" z 11 wrzesnia (i moja nowatorska biblioteke small-icl.c)
> > 
> > 
> >  typedef struct
> >   {
> >     char* beg;
> >     char* end;
> >   }
> >     chunk;
> > 
> > chunk ResizeChunk(chunk x, int size)
> > {
> >     x.beg = (char*) realloc(x.beg, size );
> > 
> >     if((size>0) && (x.beg==NULL)) ERROR_EXIT("AllocChunk failed");
> > 
> >     x.end = x.beg + size -1;
> >     return x;
> > }
> > 
> > 
> > void main()
> > {
> >   chunk dipa;
> > 
> >   dipa = ResizeChunk(dipa, 10);
> > 
> >   dipa = ResizeChunk(dipa, 1000);
> > 
> > }
> > 
> > jako ze reallock 'cacheuje' czy jak to nazwac rezerwe ramu (i to dosyc agresywnie ) to bedzie dzialac calkiem szybko 
> > (aczkolwiek moja biblioteka sicl jest bardziej oparta na splitach i indeksowaniu (czyli nie zmienia np ramu do ktorego np wpisano plik tekstowy jedynie go indeksuje na wskazniki i pozwala wybrac to co nas 
> > interesuje co z kolei zwykle zrzuca sie do outputu 
> > wlasnie printfem czy czyms podovnym, jest to rozwiazanie chyba bliskie idealu)
> 
> realizuje to przy tym moja idee stringa czyli ani nie zero na koncu a nie nie basicowe rozmiar na oczatku,
> dobry string imo to para dwu wskaznikow begin i end begin pokazuje na pierwszy znak end na ostatni (wcielilem ta idee w zycie i nazwalem taki obiekt chunk - biblioteka sicl jest tego konsekwencją)


w tym wspomnianym teksie wspomnielem tylko o jednym problemie, c potrzebuje kontroli typow i rozroznienia
miedzy chunkiem na bss-ie (na statycznym ramie) a chunkiem na heapie, bo na pierwszym nie mozna klapnąc reallocka a na drugim mozna, nie wiem jak to najlepiej rozwiazac

jak na dany moment chyba zdefiniuje 2 typy 

typedef struct { char* beg,* end; } chunk;
typedef struct { char* beg,* end; } schunk;

chunk zwykly i reSizowalny i bede kastowal resizowalna na zwykle nieststy - nie wiem jak w praktyce to wyjdzie ale kontrola typu tu musi byc

W dniu sobota, 14 października 2017 00:53:37 UTC+2 użytkownik (fir) napisał:
> 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
> 
> 

o ile takie cos 

"ala ma kota" - "kota" + "psa"

wydaje sie dosyc normalne to co z

"ala mma kota" - "ala" + "edmund"

czy robic jakas algebre nawiasami typu

("ala mma kota" - "ala") + "edmund"

daloby " ma kotaedmund"
a

"ala mma kota" +(-"ala"+"edmund")
daloby "edmund ma kota"
 ciezko powiedziec niby bardziej uzyteczne ale troche brzydkie

o ile wynik dzielenia "ala ma kota" przez " "  daje "ala" "ma" "kota" to co jest tutaj reszta z dzielenia 
 "ala ma lota"%" "

niby mogloby to byc " " " " ale to nie spalenia analogii 9co prawda nie musi),  ale nie wiadomo czy nie ma fajniejszej opcji

jeszcze inna kwestia "kot"/"kot" wynik ""
niby ok aczkoliwek "kot"-"kot" wynik ""
czyli "" robiloby raz za analog 1 a raz za analog 0



> 
> > 
> > co tam jeszcze....
> > 
> > 
> > 

W dniu środa, 18 października 2017 22:20:15 UTC+2 użytkownik M.M. napisał:
>Nie wiem jak wyobrażasz
> sobie napisanie całego kompilatora przez jedną osobę w mniej
> niż wiele miesięcy. 


moge posiedziec jak sobie to wyobrazam, aczkolwiek nie wiem czy pisani etego w takiej ogolnikowej wersji to nie strata czasu, wiec mzoe lpiej nie? jak bede chcial napisac i przemyslec szczegoly to ew napisze posta

kiedys jus pisalem o wstepnym kwalku ktory przepisywal wyrazenie z 4rema operatrami + nawiasy na assembler - zajelo mi to wtedy poltora dnia chyba ale trzeba to bedzie poprawic bo to nie bylo ladnie napisane - to moze byc dobry powod by do tego powrocic dodac ifa fora tablice i bedzie proste c na poczatek

na razie mi sie nie chce tego robic.. nic mnie nie pogania do tego by akurat pisac kompilator

smieszne jest wogole ze jak na to tak popatrzec to ten kod ktory tlumaczy wyrazenia z operatorami versus ten kod ktory 'rozwiazuje' ify i fory jakos diabelnei nie przystaje do siebie - jedno jakos nie przystaje do drugiego.. ale o tym kiedy indziej.. yawn