🚀 go-pugleaf

On 27/01/2020 23:17, Maciek Godek wrote:
> Jakiś czas temu pracowałem przy projekcie [...]

Czyli jednak religia. Coś z okolic "C++ zajmuje dużo" i jakiś inny tego 
typu krap którego pełno na necie.

> Nie jest trudno dodawać niepotrzebne zależności.

Wiadomo. Najlepiej wynajdywać kwadratowe koła. Nie przejmuj się, całe 
embedded tak robi; widziałem, liczone w tysiące, procedury zamiany inta 
na tekst. Połowa z bugami. A co dopiero coroutines.

>> Biliard. W sumie bez znaczenia. U mnie to i tak jeden #include.
> A o ile wydłuża czas kompilacji?

Dopadła Cie reglamentacja czasu kompilacji? Masz ograniczenie na 
produkcje promieniowania termicznego w procesach kompilacji wynikające z 
troski o polską energetykę? Kompilujesz całosć za każdym razem? Widzisz 
różnicę pomiedzy 10ms vs 20ms?

> że Ty sobie używasz jakiejś technologii, i ja sobie używam innej technologii

Kilka kiepskich makr cieżko nazwać technologią.

>, i wygląda na to, że z jakichś względów Tobie strasznie przeszkadza to, że nie używam tej technologii, której Ty używasz.

Mi nie przeszkadza bo nie używam popsutych makr które rozwiązują jakiś 
problem generujac inny problem. Przestrzegam innych.

> Nie wiem, dlaczego to dla Ciebie tak wielki problem.

To w ogóle nie jest problem. Świat z utęsknieniem czeka na następny 
zbiór makr rozwiązujących problemy które nie istnieją gdzie indziej.

> A rozmowy z entuzjastami C++ są zawsze intelektualnie rozczarowujące.

Ostro :D

> https://www.quora.com/Is-C++-really-as-hard-as-people-say/answer/Panicz-Godek

Masz prawo do zdania odmiennego od reszty świata.

> Czasem, kiedy w odpowiedzi na moje różne krytyki C++ pojawiają się gorliwi wyznawcy, którzy przekonują mnie, że "chuja się znam", odsyłam ich do tej listy problemów.

Całość tego blogowego wpisu była C++ vs inne języki. A tu rozmawiamy C++ 
vs C. Musiałem wiec przegapić tą "listę" która ma odniesienie do naszej 
dyskusji.

Nikt tutaj nie przekna Cie do pisania w C++ bo wcale nie musisz. Skoro 
piszesz programy używając muzealnych technik zamiast wspaniałego 
scheme/lispa to możesz miec "jakieś powody". Ja tylko zwracam uwagę że 
zamiana technologii na C++ i pisanie dalej w C z małymi wstawkami w C++ 
nikomu dupy nie urwało choć nie jednego pewnie zmusiło do spowiedzi i 
pokuty w lokalnej grupie wyznaniowej.

> W każdym razie żaden jeszcze nie zaproponował jakiegokolwiek rozwiązania któregokolwiek z tych problemów.

Zabawne bo ja własnie zaproponowałem. Zmień na C++, użyj 
boost::coroutine. Potem dorzuciłeś że to arm i przerwania. Skoro tak to: 
nie uzywaj coroutines, użyj FreeRTOSa gdzie coroutines dostaniesz jako 
cooperative multitasking. Albo nawet preemptive jak trzeba. Przy okazji 
za friko dostaniesz rozwiązanie drobnostek takich jak "komunikowanie się 
przerwań przez zmienne globlane" itp detale

> Ja go nie lubię, i mam dobre powody do tego, żeby go nie lubić.

Nie, masz tylko ideologię i religię. Tak jak dekarze który nie używają 
młotków bo nie lubią. Lutownicą też się da wbijać gwoździe w papę, 
dziadek tak robił.

> Ja w swoim życiu widziałem projekty, które grzęzły tylko od tego, że ktoś na początku podjął decyzję o użyciu tego właśnie języka.
> (Nota bene, widziałem je właśnie w tej firmie, w której pracujesz)

To musiała być inna firma. Nic się nie zgadza.

> I jeżeli Ty masz ochotę dostrajać się do tempa pracy komitetu standaryzacyjnego C++, to to jest Twoja sprawa. Ja mam inne pomysły na korzystanie ze swojego życia, i wolę korzystać z rozwiązań, które rozumiem, i które działają już teraz.

Ale one nie działają. Dostarczyłeś popsutą bibliotekę do coroutines 
która ma rozwiązywać problemy które rozwiązuje się inaczej.

>> No to się ktoś by zdziwił w handlerze przerwania ARMa że mu się jakieś
>> zmienne statyczne nadpisują w sąsiednim przerwaniu z sąsiedniego przerwania.
> A dlaczego miałoby się tak dziać?

Bo przerwania, bywa, przychodzą za szybko. Szczególnie jak się w nich 
robi zbędną algorytmikę. Bywa że przychodzą *za* szybko.

> Kwestia tego, czy warto.

Nie warto. Pisanie na zmiennych statycznych/globalnych jest hardkorowe i 
tak robią Prawdziwi Programiści.

>>> Żeby móc sobie pisać wątki na przerwaniach.
>> OK, oczywisćie sprawdziłeś overheat przełaczanai stosów i zapisywania
>> kontekstu rejestrów?
> Jakiego przełączania stosów?

Tak działają coroutines w C/C++ bo w tym języku stos jest elementem 
kontekstu wykonywania kodu.

> Tutaj tego nie ma.

I dlatego nie masz tak naprawdę coroutines. Masz popsutą bibliotekę do 
rozwiązywania absurdalnie nikłego zakresu problemów w porównaniu do 
prawdziwych coroutines. Nie wykluczam że wystarczającą do "przerwania w 
ARMie" aczkolwiek dalej jestem zaszokowany ile się w tym przerwaniu musi 
dziać że aż trzeba na pomoc wołać preprocesor ...

>> Zaryzykuje: a sprawdziłeś co oferuje FreeRTOS?
> Oczywiście. Mam dobre powody, dla których stosuję właśnie to rozwiązanie, które stosuję.

Masz dobre powody aby nie używać C++ i FreeRTOSa. Poza religią nie znam 
sensownych, "blog" nie pomógł w ich identyfikacji. Co robić...

>> W zasadzie tak: przerwania, jak to przerwania, powinny być szybkie.
>> Korutyn bym tam nie wsadzał. Szczególnei takich z okolic "workaround
>> przez zmienne statyczne".
> Jaki "workaround"?

Niemożność używania stosu. To ogranicza zastosowanie do marginalnej 
ilosci przypadków, w dodatku prawdopodobnie rozwiązywalnych ładniej 
switch/case.

>> Oczywiscie że odpowiedź zależy od zabyt dużej liczby czynników aby miała
>> sens. Ale ponieważ mam pod ręką fusy: masz problem z przekazywaniem
>> wartości pomiędzy wywołaniami i sugerujesz zmienne statyczne i pracujesz
>> z przerwaniami. Co może pójść źle?
> A w czym to przeszkadza?

W niczym. Przy bardzo dużej uwadze, wyszarpaniu sobie żył i głebokiej 
modlitwie masz szansę napisać cały program na side effectach przez 
zmienne globalne i może nawet cudem zadziała. W końcu jakoś te programy 
w BASICu na 8-bit pisali.

>Jeżeli chcę się komunikować z przerwania z innymi komponentami systemu, to muszę użyć zmiennej globalnej.

To inny przypadek.

> Zmienna statyczna to to samo, tyle że komunikuję się jedynie z innymi fragmentami korutyny.

Ale prawdziwe korutyny *NIE* ograniczają używania stosu. Używasz i 
działa tak jak się spodziewasz.

> Jedyny potencjalny problem jest taki, że ktoś użyje zmiennej automatycznej zamiast statycznej. Jestem świadomy tego problemu, i dlatego napisałem o nim w pierwszym poście.

To nie jest jakiśtam problemik. To dyskwalifikacja bo w środku tych 
korutyn nie działa nawet prymitywny C. To nie są coroutines, to tylko 
kilka jumpów o fancy nazwach.

>> PS. Mała uwaga: coroutines wymagają *czegoś* ze stosem. kopiowania,
>> podmieniania, czegokolwiek. To jest ten brakujący ficzer w implementacji.
> Korutyny wymagają możliwości wznawiania kontekstu wykonawczego.

Który w języku C wymaga stosu. Stos jest częscią kontekstu. Nie masz w 
korutynie przechowania pełnego kontekstu, nie masz korutyn tylko jakieś 
jumpy którym bliżej do asemblera niż C.

PS. Podpowiem Ci: Twój pomysł da się rozwiązać kilkoma makrami i 
ukrytymi w nich "switch/case" bez używania magicznych ficzerów 
kompilatora. Też tym sposobem da się osiągnąć "korutynę" bez zmiennych 
automatycznych. I też w kilku linijkach. I też kompletnie bez sensu w 
prawdziwych zastosowaniach. Bo tak naprawdę to jest tylko popsuta 
maszyna stanów. A nie coroutine.