🚀 go-pugleaf

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