🚀 go-pugleaf

W dniu wtorek, 28 stycznia 2020 22:37:38 UTC+1 użytkownik heby napisał:

> >> 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?

Wolę po prostu nie dokładać niepotrzebnych zależności.
Nie wiem, co w tym dziwnego.

> > że Ty sobie używasz jakiejś technologii, i ja sobie używam innej technologii
> 
> Kilka kiepskich makr cieżko nazwać technologią.

Język C to jest technologia, i język C++ to jest inna technologia.

> >, 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.

Chyba trochę przeszkadza, skoro atakujesz mnie z tego powodu.

> > 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.

C też jest innym językiem, niż C++.

> 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.

Po pierwsze, C i C++ są niekompatybilne. A jeżeli używam rozszerzeń GNU C, to jest już w ogóle niekompatybilne, i zamiana jednego kodu na drugi jest nietrywialna. Po drugie, mi się dużo przyjemniej pisze w GNU C, niż w C++.
Jeżeli nie potrafisz sobie z tym poradzić, to może idź do terapeuty.

> > 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

Dokładnie tak. Zaproponowałeś wiele rozwiązań, zupełnie nie rozumiejąc uwarunkowań problemu. I to zaproponowałeś, mimo że nikt Cię o to nie prosił.
Dzięki temu straciłeś czas zarówno swój, jak i mój.

> > 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.

Tam pomiędzy Ikeą a lotniskiem.

> > 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.

Cały czas nie wiesz, jaki problem chcę rozwiązać, ani jakie są jego uwarunkowania. A mimo tego cały czas gadasz, jakbyś wiedział lepiej.

> >>> Ż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.

W C jako takim nie ma czegoś takiego, jak "coroutines", więc nie można powiedzieć, że "tak działają".

> 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 ...

Uuu, "aż wołać preprocesor".
<grzmoty i pioruny>

> >> 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ć...

To nie moja wina, że brakuje Ci wyobraźni.

> >> 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.

No dobrze, to może pokaż, czego nie możesz zrobić bez stosu, a co mógłbyć zrobić, gdybyś miał korutyny ze stosem.

> >> 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.

Rozumiem. Czyli tak sobie gadasz.

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

A czym się różni?

> > 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.

> 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.

No to dajesz. Pokaż te kilka makr.