🚀 go-pugleaf

W dniu poniedziałek, 27 stycznia 2020 22:10:25 UTC+1 użytkownik heby napisał:
> On 27/01/2020 21:32, Maciek Godek wrote:
> >> I dlaczego nie możesz uzy kompilatora C++?
> > Mam wiele powodów. Ale nie tego dotyczy ten wątek.
> 
> Rozumiem, więc to kwestie religijne jednak.

Wygląda na to, że dla Ciebie tak.

> >> Nie, poniewa zmiana z gcc na g++ to jaki 10 sekund, a zmiana na Lua to
> >> od kilku do kilkuset godzin i zerowy sens.
> > Zmiana na g++ to też zerowy sens.
> 
> Wręcz przeciwnie. To troche jak zamiana łopaty na koparkę. Też sensu 
> brak jak się kopie dziurę pod kwiatek. Tylko po co wtedy komu korutyny.
> 
> > Pomijając jeszcze tę kwestię, że trzeba go jeszcze najpierw zainstalować.
> 
> To faktycznie showstopper.
> 
> > A później jeszcze zainstalować boosta.
> 
> A to już overkill. Ze dwa polecenia w konsoli to o trzy za dużo.
> 
> > I to u każdego developera, który pracuje nad tym projektem.
> 
> Nie do ogarnięcia przez IT ani tym bardziej developerów, oni się gubią 
> przy byle pingu a co dopiero apt-geta użyć.

Jakiś czas temu pracowałem przy projekcie, do którego używaliśmy jakiegoś samsungowego odpowiednika Raspberry.
Było tam zalecenie związane z tym, w jaki sposób wgrywać obrazy linuksa na pendrajwa. Samsung dawał link do aplikacji na Windowsa, która to robiła.
Aplikacja zajmowała ok. 3 gigabajty, bo interfejs był wykonany w Atomie czy jakimś innym web kicie.
Program dd zajmuje u mnie pod Linuxem 75 kilobajtów, i nie zużywa więcej ramu, niż potrzeba.

Innym razem zajmowałem się ewaluacją androidowych NDKów. Wtedy się dowiedziałem, że do rozpakowania źródeł potrzeba 100GB, a do zbudowania kolejnych 250GB.

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

Ale dla mnie nic z tego nie wynika. Powiem więcej. Uważam, że to głupie.

> >> Użyć boosta, dorobić abstrakcję i zrefaktoryzować jak będzie po co za
> >> kilka lat.
> > "Dorobić abstrakcję"?
> 
> Chyba nie podziewasz się że ktoś będzie chciał używać niestandardowych 
> makr wprost w kodzie w których aż roi się od śmiesznych problemów z 
> okolic "zapomiałem dodać makra _START i wylatuje"?

?
Jak nie dodasz makra _START, to się nie skompiluje.

> > A nie mogę od razu użyć docelowego rozwiązania?
> 
> Możesz. Ale boost::context/coroutine nie jest jeszcze "docelowy". 
> Dlatego owija się w to abstrakcję i izoluje granicę refaktoringu.

No to dzięki. Te Twoje rady są coraz lepsze.
 
> > To jest 20 linijek kodu.
> > A boost ma... no, ile linijek?
> 
> Biliard. W sumie bez znaczenia. U mnie to i tak jeden #include.

A o ile wydłuża czas kompilacji?

> >> Czy potrafisz z całą pewnością wskazać sensowną zaletę side effects
> >> jakiejś implementacji vs szeroko używana bibliteka ktorej spore
> >> fragmenty lądują co jakiś czas w standardzie?
> > Projekt, nad którym pracuję, i tak korzysta już z tego kompilatora i jego różnych rozszerzeń.
> 
> I dlaczego tym rozszerzeniem kompilatora nia ma być g++/boost? Znowu 
> religia?

Jak na razie nasza rozmowa wygląda tak, że Ty sobie używasz jakiejś technologii, i ja sobie używam innej technologii, 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.

Nie wiem, dlaczego to dla Ciebie tak wielki problem.

C++a zdarza mi się używać, i nigdy nie sprawia mi to frajdy. Zawsze jest coś, z czym muszę się użerać z powodu jakichś debilnych naleciałości historycznych albo innych. Interfejsy z STL za każdym razem wprowadzają mnie w błąd. A rozmowy z entuzjastami C++ są zawsze intelektualnie rozczarowujące.

Swego czasu spisałem zbiór zagadnień, przy pracy nad którymi C++ bardziej mi przeszkadzał, niż pomagał. Znajduje się tutaj:

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

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.

Wtedy albo znikają, albo mówią, że nie mają czasu na takie rzeczy, albo, że nie czują potrzeby, żeby nikomu cokolwiek udowadniać. W każdym razie żaden jeszcze nie zaproponował jakiegokolwiek rozwiązania któregokolwiek z tych problemów.

Jeżeli lubisz C++, to sobie w nim programuj. Ja go nie lubię, i mam dobre powody do tego, żeby go nie lubić. Jeżeli Ty jesteś w nim produktywny, używaj go. 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)

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.

> > I to nie jest "side effect", tylko udokumentowane rozszerzenie języka.
> 
> Ja mówie o "[...]żeby wartości argumentów były przechowywane między 
> wywołaniami, to musimy je zapisywać w zmiennych statycznych.[...]".
> 
> 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ć?

> >> Jesteś pewny że ktokolwiek będzie uzywać *KORUTYN* w handlerach przerwań
> >> na ARMie czy innym 6502? Żartujesz, powiedz proszę.
> > No, ja będę. Właściwie to głównie po to opracowałem ten mechanizm.
> 
> A po co w przerwaniu korutyny? Impelemntujesz maszynę stanów? Korutyny 
> są potrzebne kiedy algorytm jest złożony i nie da się go spłaszczyć bez 
> poświęcenia czytelności. Masz aż tak złożone algorytmy w przerwaniach? 
> Jesteś pewny że nie da się ich wyrzucić poza przerwania?

Wszystko się da.
Kwestia tego, czy warto.

> > Ż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? Tutaj tego nie ma. Jest jedna zmienna przechowująca adres etykiety. Analiza tych 20 linijek naprawdę nie jest trudna.

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

> >  Więcej na ten temat pisałem na comp.lang.c.
> > Widzisz w tym jakiś problem?
> 
> 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"?

> > A Ty w dalszym ciągu nie odpowiedziałeś mi na moje pytanie. Czy będzie problem ze wznawianiem tych korutyn w przerwaniach, czy nie będzie?
> 
> 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? Jeżeli chcę się komunikować z przerwania z innymi komponentami systemu, to muszę użyć zmiennej globalnej. Zmienna statyczna to to samo, tyle że komunikuję się jedynie z innymi fragmentami korutyny.

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.

> >> Bazującego feature jakiegoś kompilatora o niejasnej przyszłosci i
> >> przenośności.
> > Tzn. GCC jest "jakimś kompilatorem o niejasnej przyszłości i przenośności"?
> 
> Feature tego kompilatora jest o niejasnej przyszłości.

Mogę łatwo tę przyszłość przewidzieć: pozostanie w GCC na zawsze.

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