🚀 go-pugleaf

On 29/01/2020 21:41, Maciek Godek wrote:
>> Przecież własnie dołożyłeś niepotrzebną zależnośc of ficzera w kompilatorze.
> Kod i tak już jest zależny od GCC, więc to bez różnicy.

Skoro tak to zmiana na g++ też jest bez różnicy.

>>> Język C to jest technologia, i język C++ to jest inna technologia.
>> Język C++ to rozwinięcie jęyka C.
> Nie jest, i to już od dawna.
> Ze standardu C nie zadziała ci chociażby designated initializers struktur.
> (I w C++20 też nie zadziała)

Czyli jednak spierasz się jak czepialski profesor. Trudno. Wdepnąłeś w 
niszowy mechanizm języka który ma odpowiednik w C++. Dług. Do spłaty 
albo do kreatywnej księgowości. Ewentualnie jak to zwykle bywa zejdzie 
wraz z kodem na śmietnik historii.

>> Masz kiepski kod. Ten kod nazywasz "korutynami".
>> To nie są korutyny. W dodaku okazuje się że wymagają workaroundu aby być
>> w ogóle użyteczne do normalnego programowania, inaczej to pistolecik na
>> kapiszony. Z workaroundem to odbezpieczony granat w gaciach.
> Witaj w świecie programowania w C/C++.

Nie nie nie, to raczej świat kwadratowych kół. Nieustannie wymyślanych 
przez programistów C.

>> Nikt tak nie twierdzi, ale śmiem twierdzić że w Twoim wypadku zmiana z
>> gcc na g++ nic nie spowoduje a może nawet pomoże (warningi, nielegalne
>> konstrukcje itd itp). Czyli są komatybilne w jedną stronę.
> No wiem. Zauważyłem już, że "śmiesz twierdzić" wiele rzeczy, o których nie masz bladego pojęcia.

Z tym pojęciem to nie masz pojęcia.

> Ale zobaczmy.

I zobaczyliśmy kod który w C++ piszę się troszkę inaczej. Spór akademicki.

>>> A jeżeli używam rozszerzeń GNU C
>> Przecież nie chcesz dodatkowych zależności, prawda?
> Nie ma dodatkowych zależności. Jak pisałem, z GCC korzystam tak czy siak.

Czli masz g++ za darmo.

>>>> nie uzywaj coroutines, użyj FreeRTOSa
>>> Dokładnie tak. Zaproponowałeś wiele rozwiązań, zupełnie nie rozumiejąc uwarunkowań problemu.
>> a) nigdzie ich na poczatku nie było
> Bo i problemu nie przedstawiałem.

Bo go pewnie nie ma.

> Przedstawiałem pewne rozwiązanie, które jest stosowalne również poza kontekstem, w którym je sformułowałem.

Strach się bać ile jeszcze problemów wymaga równie popsutych rozwiązań.

> Rozwiązanie oczywiście można zasadnie krytykować, ale odświeżanie starego flamewara "C vs. C++" ma umiarkowany sens.

Nie przypominam sobie abym go odświeżał. Stwierdziłem tylko że kod jest 
fundamentalnie niebezpieczny oraz że można znaleźc gotowe rozwiązanie w 
booscie. I nadepnąłem na odcisk. Cała reszta to tylko trolling 
wynikający ze strachu przed lekarstwem.

>> Cały czas chcesz by Ci czytać w myślach. To nie jest możliwe.
> Wystarczy, że nie będziesz proponował rozwiązań od czapy.

Chcesz mi powiedzieć że można proponować rozwiązania nie z czapy bez 
znajomości prawdziwego problemu? No, to niestety wymaga szklanej kuli.

Po drugie to popruste coroutines są z czapy bez względu na to co niby 
rozwiązują.

>> yeld( 42 );
>> for( i = 6 ; i < 10 ; ++i )
>>      [...]
>>      yeld( i );
>>      [...]
> Czas start.
> int f(void) {
>    COROUTINE_START();
>    static int i;

Jeb. Właśnie użyłeś zmiennej globalnej. Ojej. Co się może stać?

Innymi słowy jesteś krytykowany że twój kod wymaga zmiennych globalnych, 
pytasz "czego nie możesz zrobić bez stosu, a co mógłbyć zrobić, gdybyś 
miał korutyny ze stosem", podaje przykład a ty dajesz przykład korutyny 
bez stosu joko dowód że też da się zrobić.

Łomatko, o co Ci chodzi? Zmienne statyczne w funkcjach są 
problematyczne. Twoje korutyny są problematyczne z tego powodu. To że 
się da nie oznacza że ktokolwiek przy zdrowych zmysłach tak by robił w 
kodzie produkcyjnym.

> Hmm. Chyba wygląda dość tak samo.

Nie, jedno to pure function a druga to side effect. Fundamentalna 
różnica, ludzie poświęcili życie aby wykazać lepszosc jednych nad 
drugimi, tony prac naukowych napisali. Przykro mi że nie dostrzegasz 
tego "detalu".

>> PS. Zmienne statyczne tez nie są potrzebne. Wystarczy dowolny obiekt
>> trzymający stan korutyny. Zaznaczam że jest to tylko niewiele lepsze
>> rozwiązanie bo ten obiekt też musi być śledzony jeśli nie daj Panie
>> korutyny będą się przeplatać. Tak czy owak d...z tyłu.
> Nadal nie podałeś żadnego przykładu.

Nie musiałem, sam napisałeś przed chwilą przykład korutyny która jest 
nie reentrant, thradsafe, wahatever. Moja z boosta jest reentrant, 
threadsafe, whatever.

>> Tym że do tego systemy operacyjne wynalazły różne metody IPC ponieważ
>> jest nieuniknione.
>> W Twoim wypadku używanie zmiennych globalnych nie jest nieuniknione
>> tylko wynika z kiepskiej implementacji.
> To pokaż mi jak przekazać informację z przerwania do procesu bez zmiennej globalnej.

Nigdzie nie napisałem że robi się to bez zmiennej globalnej. Napisałem 
że OSy dają interfejsy IPC bo jest to nieuniknione.

Masz do tego rózne IPC. Od cli/sei, przez mutexy po rury. Do koloru do 
wyboru. W gruncie rzeczy one używają stanów globalnych. Tylko że 
programista jest zwolniony od tego aby to obrabiać na jakimś poziomie. 
Albo robi to samodzielnie cli/sei, albo oddaje częśc abstrakcji 
systemowi jak w muteksowaniu, albo całkiem zdaje się na OS.

Jest to nieuniknione wiec ten problem OSy jakoś starają się generycznie 
rozwiazać.

U Ciebie można tego uniknąć, ale to wymaga napisania czegoś więcej niż 
kilku prostych sztuczek z makrami. I ktoś to już napisał. Ba, napisał to 
w conajmniej kilku biblitekach.

Z resztą dlaczego mam się produkowaćw kółko?

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

"In order to implement general-purpose coroutines, a second call stack 
must be obtained, which is a feature not directly supported by the C 
language.[...]"

Jest nawet coś o Twoich wypocinach:

"[...]"As far as I know, this is the worst piece of C hackery ever seen 
in serious production code." The main shortcomings of this approximation 
are that, in not maintaining a separate stack frame for each coroutine, 
local variables are not preserved across yields from the function, it is 
not possible to have multiple entries to the function, and control can 
only be yielded from the top-level routine. "

Ale spokojnie, Oni też są tylko głupi i trolują.

>    case __LINE__:

Na marginesie: to, o ile mnie pamiec nie myli, nie zadziała z Visualem. 
Ale to naprawdę na marginesie, przecież nie chcesz generować dodatkowych 
zależności.