🚀 go-pugleaf

On 10/03/2020 09:22, Maciek Godek wrote:
>> On 09/03/2020 21:20, Maciek Godek wrote:
>>> A użycie boost::coroutines dokonuje alokacji, czy nie?
>> Nie musi. Czy dokonuje nie wiem, pewnie tak.
> I nadal uważasz, że unikanie C++ na rzecz C jest kwestią religii?

Tak. Coroutines wymagaja stosu, chyba że ktoś wymyślił taki pistolet na 
wodę jak Ty. Tak czy siak musisz ten stos dostarczyć. Czy to C++ czy C 
jest drugorzędne. To czy przez allokacje czy przez statyczny zbiór 
bajtów też jest drugorzędne. Problemem Twoich coroutines jest to że nie 
mają stosu, bo są h..owe. Zrób żeby miały i okaże się że dyskusja o C++ 
nie ma z nimi związku.

Więc jeszcze raz dla wyjaśnienia:

a) masz h.ową implementację coroutines i nie ma to związku z językiem

b) przypadkiem pojawił się temat czy C++ czy C który nie ma sensu do 
analizy na tle corountines

c) "masz swoje powody" których do dzisiaj nie poznaliśmy.

> Sam widzisz, że - nawet jeśli mechanizmy, które oferuje C++ byłyby wygodne
> (a nie są), to tworzą one barierę dla zrozumienia systemu.

Nie. Uzywasz wysokopoziomowego boost::coroutine, który nie dość że jest 
jest w C++ to jeszcze używa ficzerów OS niedostepnych na 
mikrokontorlerach. Dyskutujesz w złym branchu wątku. Widać masz jakiś 
kłopot w udowanianiu swoich racji skoro wyskoczyłeś nagle w środku 
marudzenia o PICach.

> Model operacji C jest stosunkowo prosty, i każdy kompetentny programista powinien go rozumieć.

Więc jesteś dzieciakiem wyznającym zasadę że najlepszą abstrakcją jest 
brak abstrakcji i napierniczanie w asm. Tak widać wszystko i łatwo 
zrozumieć. Tylko czy na pewno o to chodzi w programowaniu czeoś więcej 
niż hello worldy.

> Natomiast model C++a jest skomplikowany, i ta komplikacja ma w dużej mierze przypadkowy charakter.

Model coroutines jest boosta. Napisz sobie inny model, nazwij go, wystaw 
na githubie i tyle. Moze znajdziesz go za 30 lat w standardzie C60 gdzie 
uratuje życie ludziom mrugającym dwoma diodami na raz.

> Zadaję Ci proste, fundamentalne pytanie: czy boost::coroutines, do użycia którego niedawno mnie zachęcałeś, dokonuje alokacji. Ty nie dość, że nie znasz odpowiedzi, to jeszcze nie potrafisz tego łatwo znaleźć w dokumentacji.

Ale ja tego nie muszę wiedzieć. Na tym polega, misiaczku złoty, 
abstrakcja. NIE musisz znać detali implementacyjnych jesli interfejs 
jest zdefiniowany. I po drugie: możesz sobie te detale podmienić jak Ci 
nie pasują. Chcesz coroutines bez allokacji. To sobie napisz. Interfejs 
do nich jest prosty i przejrzysty, implementację możesz napisać na 
makrach, h.. to kogo obchodzi.

> Wcale mnie to nie dziwi. Jeżeli uważasz, że całościowe rozumienie systemu, który się rozwija, jest "kwestią religii", niech będzie i tak. Moim zdaniem jest to raczej kwestia rozsądku i pragmatyzmu.

Wiadomo. Pisz wszystko w asm. Tam nie ma miejsca na nierozumienie. Co 
bardziej zaawansowani potrafią nawet migać diodą.

>> Ale nie ma takiego
>> obowiązku, w końcu stos korutyny możesz mieć statyczny gdzieś obok,
>> albo, wzorem apliakcji embedded, możesz mieć pool allokatora na te stosy
>> i znany rozmiar.
> Każda STLowa kolekcja daje Ci możliwość dostarczenia Twojego własnego alokatora.

Myslisz że zmiana allokatora z malloc na swój zmienia jakoś zasadniczo 
problem fragmentacji pamięci? Programy w embedded często nie allokują 
wcale. Ale to nie przeszkadza mieć porządnie zrobionych coroutines ze 
stosem zamiast pistoleciku na wodę z makrami i switch case.

> Dlatego rozumując po Twojemu, powinieneś raczej zachęcać embedowców do tego, żeby grzęzli w bagnie debugowania ich własnych customowych alokatorów i hulali sobie z wesołymi alokacjami STLowych kolekcji.

Wręcz odwrotnie, namawiam embedowców aby używali C++ ale NIE używali 
STL. Od samego początku. Problemem nie jest *swój* allkokator. Problemem 
jest allokator w ogóle.

>> Więc możesz sobie napisać godek::coroutine i tam może
>> nie być allokacji ale stos, czemu nie.
> Te Twoje rady są coraz lepsze. To, skoro "mogę sobie napisać" (bo to takie łatwe?), może pokaż mi, jak taka implementacja mogłaby wyglądać.

Ile płacisz?

> Chętnie się dowiem.

Istnieją inne drogi poznania niż trolowanie.