znaczacy > comp.lang.* > comp.lang.c

Mateusz Viste (29.01.2020, 00:30)
2020-01-28 o 22:37 +0100, heby napisa?:
> Czyli jednak religia. Co? z okolic "C++ zajmuje du?o" i jaki? inny
> tego typu krap którego pe?no na necie.


C++ to mocno skomplikowana koby?a, która ulega regularnym zmianom.... nie
ka?demu to odpowiada. #muremzama?kiem :)

> Masz prawo do zdania odmiennego od reszty ?wiata.


Nie *ca?ej* reszty ?wiata, bo jest nas co najmniej dwóch. A jak by
dobrze poszuka?, to my?l? ?e i trzeciego by si? da?o znale??.

> Lutownic? te? si? da wbija? gwo?dzie w pap?, dziadek tak robi?.


By? mo?e szybciej wbija? lutownic? któr? si? ma w r?ku, ni? m?otkiem
który le?y pod drabin?? Tak tylko gdybam.

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


Nie wiem jak to wygl?da w ARMie, ale w x86 int handlery s?
domy?lnie nieprzerywalne. ARM ma inaczej?

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


Obs?uga przerwa? w BASICu? Nie przypominam sobie. W ASM lub jakim?
Turbo C ze wstawkami to i owszem, zabawa przednia. Teraz ju? takich
fajnych rzeczy si? nie robi, inna moda, inne komputery, no i ludzie
jacy? tacy mniej cierpliwi...

Mateusz
Maciek Godek (29.01.2020, 09:31)
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?oprzyjemniej 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? zrozwi?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.

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

> 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.
M.M. (29.01.2020, 14:58)
On Tuesday, January 28, 2020 at 11:30:09 PM UTC+1, Mateusz Viste wrote:
> 2020-01-28 o 22:37 +0100, heby napisa?:
> C++ to mocno skomplikowana koby?a, która ulega regularnym zmianom... nie
> ka?demu to odpowiada. #muremzama?kiem :)
> Nie *ca?ej* reszty ?wiata, bo jest nas co najmniej dwóch. A jak by
> dobrze poszuka?, to my?l? ?e i trzeciego by si? da?o znale??.
> By? mo?e szybciej wbija? lutownic? któr? si? ma w r?ku, ni? m?otkiem
> który le?y pod drabin?? Tak tylko gdybam.


No w?a?nie, s? pewne okoliczno?ci w których lepieju?y? C, albo u?ycie C++
niewiele wniesie, i s? to nie a? tak dziwne okoliczno?ci jak'akurat w
r?ku trzymam lutownic?' - o czym na dole.

> Nie wiem jak to wygl?da w ARMie, ale w x86 int handlery s?
> domy?lnie nieprzerywalne. ARM ma inaczej?
> Obs?uga przerwa? w BASICu? Nie przypominam sobie. W ASM lub jakim?
> Turbo C ze wstawkami to i owszem, zabawa przednia. Teraz ju? takich
> fajnych rzeczy si? nie robi, inna moda, inne komputery, no i ludzie
> jacy? tacy mniej cierpliwi...


Przytoczmy kilka faktów:
1) Chyba ka?demu odpowiada pisanie takich samych programów krótszym czasie?
Pisz?c takich samych mam na my?li tak samo wydajnych, tak samo zdebugowanych,
tak samo przetestowanych, tak samo funkcjonalnych.

2) W C++ mamy praktycznie to samo co w C, plus wiele dodatkowych rzeczy. Wi?c
jakby nawet si? uprze?, to w C++ mo?na programowa?tak jak w C je?liby te
dodatkowe cechy nic nie wnosi?y. ?ci?le, sam ten fakt powoduje, ?e C++ nie
mo?e by? gorszy od C w sensie z punktu pierwszego - o czym ju? kto? wspomina?
?e C++ kompiluje C. Ale potocznie zazwyczaj ma si? na my?li programowanie w C++
pe?n? g?b?.

3) C++ znacznie szybciej si? rozwija ni? C i jest ogromny. Je?li chcemy
programowa? w C++, to w czasie gdy uczymy si? nowych fitcherów tego? j?zyka,
by?my mogli sporo kodu naklepa? w prostym i ma?ym j?zyku C. Ostatnio np.
googla?em jak Lambd? przekaza? jako parametr template, nigdywcze?niej
tego nie robi?em. W C bym dane rzutowa? na void* i u?y?wska?nika na
funkcj? - banalne.

4) Gdy si? naprawd? PORZ?DNIE projektuje i implementuje ( i mo?e optymalizuje )
kod w C++, szczególnie w celu re-u?ywania, to nak?ad czasu wprzypadku u?ycia
C++ jest wi?kszy, poniewa? mamy do wyboru znacznie wi?cej elementów. W C mamy
do wyboru wska?nik na funkcj?, makro i copy-paste-modify. W C++ mamy ponadto
funkcj? wirtualn?, wska?nik na funkcj? sk?adow?, lambd? jako argument metody
lub szablonu, no i mamy jeszcze do wyboru szablony, a mo?e zwyk?ym
dziedziczeniem problem by si? da?o za?atwi? bez metod wirtualnych.
Gdy te mo?liwo?ci przemno?ymy przez wygodny interfejs do reu?ywania, to
ogarni?cie ma?ego problemu robi si? lekkim wyzwaniem.

5) Biblioteki - u?ywanie gotowych i dobrych bibliotek w C++ jest znaaaacznie
szybsze, znaaaacznie ?atwiejsze, a je?li u?ywanie bibliotek ma dawa? wydajny
kod, to dzi?ki szablonom w C++ mo?na mie? ?atwiejszy w utrzymaniu i lepiej
zdebugowany kod. Ale pisanie kodu to nie tylko 'u?ywanie biblioteki', ale te?
zrozumienie problemu który biblioteka realizuje, zapoznanie si? z dokumentacj?,
przeczytanie jaki? przyk?adów, bo nawet w C++ nie mo?naoptymalnie u?ywa?
bibliotek je?li u?ywa si? intuicyjnie. Przecie? tragedii ?adnej nie by?o
gdy si? pisa?o w C w WinAPI, w OpenGL, albo gdy pod DOS si? robi?o w?asne
GUI z menu i okienkami - i potem si? tego reu?ywa?o.

Pozdrawiam
Mateusz Viste (29.01.2020, 15:30)
2020-01-29 o 04:58 -0800, M.M. napisa?:
> (ró?ne m?dre rzeczy)


Bardzo ?adnie wypunktowa?e? spraw?, i ze wszystkim si? zgadzam. Dodam
tylko jeden aspekt, który przeoczy?e? - a który mo?e by? bardzo istotny
w ramach pracy zespo?owej.

> 2) W C++ mamy praktycznie to samo co w C, plus wiele dodatkowych
> rzeczy. Wi?c jakby nawet si? uprze?, to w C++ mo?na programowa? tak
> jak w C je?liby te dodatkowe cechy nic nie wnosi?y.


Zdarza?o mi si? widzie? projekty napisane w C - jak Pan Bóg przykaza?.
Pó?niej kto? powiedzia? "no tak, C jest fajne, ale mo?e kompilujmy go
jako C++, ale dalej pisz?c C". No i git, whatever.

Pó?niej kto? (inny) powiedzia? "a mo?e rozlu?nijmy troch? portki i
skorzystajmy z 'new'? To b?dzie takie 'C z new', tu i ówdzie usprawni
pisanie tego i owego, czysty zysk!". No i w sumie - czemu nie.

Jak ?atwo si? domy?le?, potem by?o ju? z górki. Ka?dy dodawa? co? od
siebie i projekt który pocz?tkowo by? sk?adny i konsekwentny, z czasem
przeistoczy? si? w potworka, gdzie ten sam problem rozwi?zuje si? na
kilka ró?nych sposobów w zale?no?ci od tego w jakim czasie i przez kogo
zosta? napisany.

> potocznie zazwyczaj ma si? na my?li programowanie w C++ pe?n? g?b?.


Do tego to niechybnie zmierza. Je?li robi to jedna osoba która
dok?adnie wie co robi i trzyma si? jakich? ustalonych zasad,to nie ma
problemu. Gorzej, kiedy mamy do czynienie z wi?kszym zespo?em, w którym
znajomo?? C++ i jego wszelakich uaktualnie? oraz najrozmaitszych
rozszerze? jest bardzo niejednolita. Kto? powie, ?e to wirtualny
problem, bo od tego jest PM lub wzorce projektowe, ?eby takie rzeczy
u?ci?la? i egzekwowa?... a ?ycie ?yciem.

Mateusz
M.M. (29.01.2020, 16:51)
On Wednesday, January 29, 2020 at 2:30:48 PM UTC+1, Mateusz Viste wrote:
> 2020-01-29 o 04:58 -0800, M.M. napisa?:
> > (ró?ne m?dre rzeczy)

> Bardzo ?adnie wypunktowa?e? spraw?, i ze wszystkim si? zgadzam. Dodam
> tylko jeden aspekt, który przeoczy?e? - a który mo?e by? bardzo istotny
> w ramach pracy zespo?owej.


Dzi?kuj?.

> > 2) W C++ mamy praktycznie to samo co w C, plus wiele dodatkowych
> > rzeczy. Wi?c jakby nawet si? uprze?, to w C++ mo?na programowa? tak
> > jak w C je?liby te dodatkowe cechy nic nie wnosi?y.

> Zdarza?o mi si? widzie? projekty napisane w C - jak Pan Bóg przykaza?.
> Pó?niej kto? powiedzia? "no tak, C jest fajne, ale mo?e kompilujmy go
> jako C++, ale dalej pisz?c C". No i git, whatever.


No tak, czemu nie. Jest kilka wyj?tków. W C++ jest jedna przestrze? nazw
dla typów i zmiennych, a w C s? dwie, bo kompilator rozpoznaje poobowi?zkowym
s?owie kluczowym struct ?e chodzi o typ a nie o zmienn?. Podobnie sprawa
ma si? ze s?owem kluczowym class, w C mo?na by?o tak nazwa? zmienn?, a C++
ju? tego nie skompiluje. C te? ?agodniej podochodzi do konwersji typów...
ale je?li by?o pisane PO BO?EMU, to przej?cie na kompilator C++ mo?e
by? nawet bez ?adnej poprawki.

> Pó?niej kto? (inny) powiedzia? "a mo?e rozlu?nijmy troch? portki i
> skorzystajmy z 'new'? To b?dzie takie 'C z new', tu i ówdzie usprawni
> pisanie tego i owego, czysty zysk!". No i w sumie - czemu nie.


No tak, czemu nie? New samo rzutuje na odpowiedni typ i zna rozmiary typów w
przeciwie?stwie do malloc. Ale czy realloc wspó?pracuje z new i delete to
nie wiem, my?l? ?e nie.

> Jak ?atwo si? domy?le?, potem by?o ju? z górki. Ka?dy dodawa? co? od
> siebie i projekt który pocz?tkowo by? sk?adny i konsekwentny, z czasem
> przeistoczy? si? w potworka, gdzie ten sam problem rozwi?zuje si? na
> kilka ró?nych sposobów w zale?no?ci od tego w jakim czasie i przez kogo
> zosta? napisany.


Trudno jest mi si? ustosunkowa? w krótkiej wypowiedzi.

W jednym ze swoich projektów wydzieli?em pewne specyficzne poj?cie modu?u.
Modu? by? pewnym szablonem, zestawem klas i metod wirtualnych. Gdy programista
próbowa? pisa? niezgodnie z szablonem, to si? nie uruchomi?o. Ale swoje
pliki, metody i klasy móg? dodawa? jak lubi, byle minimalnie przejrzy?cie.
W zamian za lekki ba?agan ka?dy mia? troch? wolno?ci i projekt moim zdaniem
szybciej si? rozwija?. Gdy poprawka jakiego? modu? stawa?a si? bardzo trudna, to
bezbole?nie dla ca?ego projektu mo?na by?o wywali?tylko jeden modu? - ale
takie ryzyko by?o ma?e.

> Do tego to niechybnie zmierza. Je?li robi to jedna osoba która
> dok?adnie wie co robi i trzyma si? jakich? ustalonych zasad, to nie ma
> problemu.
> Gorzej, kiedy mamy do czynienie z wi?kszym zespo?em, w którym
> znajomo?? C++ i jego wszelakich uaktualnie? oraz najrozmaitszych
> rozszerze? jest bardzo niejednolita. Kto? powie, ?e to wirtualny
> problem, bo od tego jest PM lub wzorce projektowe, ?eby takie rzeczy
> u?ci?la? i egzekwowa?... a ?ycie ?yciem.


No wi?c w?a?nie, ba?agan ba?aganowi nierówny.Ba?agan globalny ?le wró?y
kolejnej rozbudowie projektu, ba?agan lokalny oznacza tylko troch? wi?kszy
nak?ad pracy w zamian za to ?e kiedy? troch? czasu zaoszcz?dzili?my na
porz?dkowaniu kodu. Poza tym komentarze rekompensuj? ba?agan.. Ba?agan ma
te? swoje zalety. Szybciej dostarczamy cokolwiek co dzia?a. Gdy porz?dkujemy,
to mamy okazj? jak ula? do testów regresywnych. Osobi?cie zostawiam wersj?
ba?aganiarsk?, nie kasuj? jej, ale u?ywam potem do porównania czy daje takie
same wyniki jak wersja uporz?dkowana. Gdy jest konieczno?? optymalizacji, to
mam wersj? trzeci? kodu który robi to samo i w testach mog? porównywa? wyniki
trzech procedur.

Ale odpisuj? po ?ebkach na pewno pope?niaj?c wiele niedomówie?. Rozwijanie
aplikacji to ogromny temat. Zwykle mamy zestaw wytycznych:
w1, w2, wN

Zestaw prawdopodobnych kierunków rozwoju aplikacji:
z1, z2, zM

i ich prawdopodobie?stw
p1, p2, pM

I mo?liwe technologie w którym rozwi??emy dane zadanie:
r1, r2, rK

Przy u?yciu danej technologii znamy tylko przybli?ony koszt:
k1 = r1(w1,w2,wN,z1*p1,z2*p2,zM*pM)

Do tego koszt jest kosztem wielokryterialnym, dla jednego czas wykonania
jest liniowy i jeden dzie? oczekiwania na produkt to 200z?, dla drugiego
dzie? oczekiwania na ten sam produkt to 1000z?, dla innego oczekiwanie
powy?ej pewnej ilo?ci dni oznacza podniesienie dotychczasowych kosztów razy
dziesi?? bo ma kar?, a inny zatrudnia 200% nadmiarowych programistów bo
od jednego produktu b?dzie zale?a? kontrakt na 100 kolejnychzamówie?...

Jak w obliczu tylu niepewno?ci mo?na si? merytorycznie spiera? o to, czy
dalsze upi?kszanie kodu, szukanie lepszych bibliotek, przej?cie na inny
j?zyk programowania, kolejna refaktoryzacja,
spowoduje ?e ki < min( k1, k2, k{i-1} )
?

Pisanie jednej procedury to in?ynieria, ale pisanie ca?ego systemu to w
du?ej mierze sztuka i intuicja.

Pozdrawiam
heby (29.01.2020, 18:55)
On 28/01/2020 23:30, Mateusz Viste wrote:
> C++ to mocno skomplikowana koby?a


Tak.

> , która ulega regularnym zmianom


Nie. Ulega ewolucji z zachowaniem *prawie* wszystkiego. Helloworldy w C
dzia?aj? tak samo a jak nie dzia?aj? to cz?sto "trudno si? dziwi?".

> ... nie
> ka?demu to odpowiada.


Wolno?? wyboru.
>> Lutownic? te? si? da wbija? gwo?dzie w pap?, dziadek tak robi?.

> By? mo?e szybciej wbija? lutownic? któr? si? ma w r?ku, ni? m?otkiem
> który le?y pod drabin?? Tak tylko gdybam.


Nie, tutaj mamy do czynienia z przypadkiem gdzie m?otek trzymasz ju?
prawie w r?ce (gcc->g++) ale dalej preferujesz lutownic? po dziadku bo
"masz swoje powody".

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

> Nie wiem jak to wygl?da w ARMie, ale w x86 int handlery s?
> domy?lnie nieprzerywalne. ARM ma inaczej?


Chyba nie czaisz problemów w mikrokontrolerach.

Jest sobie SPI. Na tym SPI napierniczaj? bajty. DMA chowa je do bufora w
pamieci. Bywa ?e ten bufor to jeden bajt. Wysy?a przerwanie kiedy jest
pe?ny. Ty robisz sobie swoje korutyny i fancy programowanie makr.
Przepe?nia si? drugi bufor. Nie odebra?e? przerwania. Dupa. To czy
przerwania s? czy nie przerywalne nie ma znaczenia. Problemy s? rózne.
By? mo?e w opisywanym przypadku nie wyst?puj?. Tylko po h... wtedy te
ca?e korutyny?

Oczywi?cie zaraz si? oka?e ?e ten ca?y ARM z przerwaniami to do migania
diod? s?u?y. Tak czy inaczej przerwania to wielow?tkowo?? + restryckje
RT. Miejsca na zabaw? tam du?o nie ma.

> Obs?uga przerwa? w BASICu?


Porównianie by?o do "makrowych korutyn" w których u?ycie "int a" jest
zabronione co redukuje w nich pisany algorytm do poziomu BASICa z lat 70
gdzie wszystko by?o globalne. Lutownica, nawet rozpadaj?ca si? i pod
napi?ciem ci?gle lepiej wbija gwo?dzie ni? m?otek.
heby (29.01.2020, 19:19)
On 29/01/2020 08:31, Maciek Godek wrote:
> Wol? po prostu nie dok?ada? niepotrzebnych zale?no?ci.


Przecie? w?asnie do?o?y?e? niepotrzebn? zale?no?c of ficzera w kompilatorze.

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


J?zyk C++ to rozwini?cie j?yka C. Je?li tylko nie b?dziesz udawa?
czepialskiego profesora to oka?e si? ?e C jest podzbiorem C++ z
nieistotnymi róznicami w detalach dla programisty (albo poprawialne albo
g?upie - tak czy inaczej do zmiany).

> Chyba troch? przeszkadza, skoro atakujesz mnie z tego powodu.


Tu Cie nikt nie atakuje.

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.

Jak si? okazuje ?e kto? pyta "po co" to nerwowo marudzisz o jaki?
powodach. Nie ma ich. To tylko takie hackerstwo. Wylatuje na pierwszym z
brzegu code review.

> C te? jest innym j?zykiem, ni? C++.


Nie, jest podzbiorem C++.

> Po pierwsze, C i C++ s? niekompatybilne.


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

> A je?eli u?ywam rozszerze? GNU C


Przecie? nie chcesz dodatkowych zale?no?ci, prawda?

>, to jest ju? w ogóle niekompatybilne, i zamiana jednego kodu na drugi jest nietrywialna.


Jak si? popsu?o kod to trzeba refaktorowa?. To tylko zwyk?y d?ug
technologiczny a bywa ?e i vendor lockin. Pierwszy raz programujesz ?e
nie wiesz ?e u?ywanie niszowych rozwi?za? generuje d?ug?

> Po drugie, mi si? du?o przyjemniej pisze w GNU C, ni? w C++.


Ludzie maja rózne gusta. Nic na to nie poradz?.

> Je?eli nie potrafisz sobie z tym poradzi?, to mo?e id? do terapeuty.


Ja sobie z tym radz? doskonale. Czyli u?ywam w?a?ciwych narz?dzi tam
gdzie rozwi?zuj? one prawid?owo problemy. Uzywam C tam gdzie nie mam
wyj?cia, u?ywam C++ tam gdzie mi to pomaga, u?ywam Prologa tam gdzie
trzeba wyrwa? lachona. Ka?dy j?zyk ma zastosowanie.

Problem w tym ?e "uzywam C bo nie mam wyj?cia" sprowadza si? zazwyczaj
do jaki? absurdalnych przypadków 8051 z kompiltorem pisanym przez
dyletantów. Tam nie mam wyj?cia.

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


a) nigdzie ich na poczatku nie by?o
b) jak si? pojawi?y to zaproponowa?em lepsze rozwi?zanie
c) rozwi?zanie nie pasuje
d) prawdopodobnie go to b) a? wyjdzie na to ?e masz racj? bo w
specyfikacji napisali ?e kod ma mie? popsute korutyny na makrach w C. No
to wtedy nic nie poradz?. Deadlock.

> I to zaproponowa?e?, mimo ?e nikt Ci? o to nie prosi?.


Taka natura ludzka: jesli kto? si? przewróci to staram si? mu pomóc.

> Dzi?ki temu straci?e? czas zarówno swój, jak i mój.


Mój nie jest nic wart wi?c nie ma czego ?a?owa?. Za Twój przepraszam.

>> To musia?a by? inna firma. Nic si? nie zgadza.

> Tam pomi?dzy Ike? a lotniskiem.


Dalej si? nic nie zgadza.

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


Nie dowiem si? ju? nigdy. Jestem przekonany ?e bez wzgl?du na to co nie
wymy?lisz i tak na koniec oka?e si? ?e to problem wyssany z palca.

>, ani jakie s? jego uwarunkowania.


Poza pewnymi w?skimi dziedzinami inzynierii wysokiego ryzyka, kod pisze
si? pod narz?dzami do tego przystosowanymi. Nie wiem czy korutyna za
zmiennymi gobalnymi do czegokolwiek pasuje. Nie, nie pasuje.

> A mimo tego ca?y czas gadasz, jakby? wiedzia? lepiej.


By? mo?e to do?wiadczenie. Ale przypuszczalnie tylko z?udzenie.

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


W C masz stos jako integraln? cz??c jezyka. Wiec aby coroutines dzia?a?y
w C musisz w nich *jako?* obs?ugiwa? stos. Teraz lepiej?

> Uuu, "a? wo?a? preprocesor".
> <grzmoty i pioruny>


Nie, nie grzmoty i piuruny tylko wyrzucenie z review. Przyznaje, efekty
mniej spektakularne.

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


Ca?y czas chcesz by Ci czyta? w my?lach. To nie jest mo?liwe.

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


[...]
yeld( 42 );
for( i = 6 ; i < 10 ; ++i )
[...]
yeld( i );
[...]

W zasadzie napisanie dowolnego nieco bardziej skomplikowanego generatora
wymaga natychmiast u?ycia workaroundu ze zmiennymi statycznymi.

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.

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


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.

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


Mo?e co? narze?bi? w wolnej chwili. Uzywa?em tego przez jaki? czas z
miernym skutkiem i raczej nie znajduje powodów do powrotu.
heby (29.01.2020, 19:24)
On 29/01/2020 13:58, M.M. wrote:
> No w?a?nie, s? pewne okoliczno?ci w których lepiej u?y? C, albo u?ycie C++


Poka? okoliczno?? kiedy lepiej u?y? kompilator C zamiast C++. Dowoln?
rozs?dn?.

> ?e C++ kompiluje C. Ale potocznie zazwyczaj ma si? na my?li programowanie w C++
> pe?n? g?b?.


Nikt w tym w?tklu nie mówi o programowaniu pe?n? g?b? z u?yciem
obiektowo?ci. W ogóle nie ma tutaj obiektowo?ci poza u?yciem jej w celu
obs?ugi *ewentualnych* szablonów, bo tak to si? robi w C++.

> googla?em jak Lambd? przekaza? jako parametr template, nigdy wcze?niej
> tego nie robi?em. W C bym dane rzutowa? na void* i u?y? wska?nika na
> funkcj? - banalne.


I jakie przy okazji bugogenne. Gdzie? musisz mie? cast. Czy aby na pewno
znasz wszystkie miejsca gdzie ten cast wyst?puje? Wiesz ju? dlaczego
ogólnie szablon jest lepszy ni? void*? Podpowiem: bo wykrywa problem na
kompilacji a nie runtime.
heby (29.01.2020, 20:10)
On 29/01/2020 08:31, Maciek Godek wrote:
>> 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.


Prosz?, wersja z ifami jest nawet wygodniejsza w u?yciu:

#define BEGIN_BAD_COROUTINE( _coroutineState ) \
int& coroutineState = _coroutineState.m_coroutineState; \
if ( coroutineState == 0 ) \
{

#define BAD_YIELD( _result ) \
coroutineState = __LINE__; \
return _result; \
} \
else if ( coroutineState == __LINE__ ) \
{

#define BAD_END_COROUTINE() \
}

struct SimpleState
{
int m_coroutineState = 0;
};

int
coroutine1()
{
static SimpleState state;

BEGIN_BAD_COROUTINE(state);

BAD_YIELD(1);

BAD_YIELD(2);

BAD_YIELD(3);

BAD_END_COROUTINE()

return 4;
}

int
coroutine2()
{
static SimpleState state;

BEGIN_BAD_COROUTINE(state);

BAD_YIELD(10);

BAD_YIELD(11);

BAD_YIELD(12);

BAD_END_COROUTINE()

return 13;
}

int main()
{
for (int i = 0; i < 4; ++i)
{
std::cout << coroutine1() << std::endl;
std::cout << coroutine2() << std::endl;
}
}

Wynik:

1
10
2
11
3
12
4
13
heby (29.01.2020, 20:19)
On 29/01/2020 18:19, heby wrote:
> yeld( 42 );


yield oczywiście, dla czepialskich.
M.M. (29.01.2020, 20:50)
On Wednesday, January 29, 2020 at 6:24:36 PM UTC+1, heby wrote:
> On 29/01/2020 13:58, M.M. wrote:
> > No w?a?nie, s? pewne okoliczno?ci w których lepiej u?y? C, albo u?ycie C++

> Poka? okoliczno?? kiedy lepiej u?y? kompilator Czamiast C++. Dowoln?
> rozs?dn?.


Firma ma kilku pracowników którzy znaj? tylko C i maj? do?wiadczenie w pisaniu
aplikacji w C. Przychodzi do firmy zamówienie na aplikacj? podobn? do tych w
jakich maj? do?wiadczenie i aplikacja nie jest kolosalnie du?a. Maj? do wyboru:
kurs C++ i tworzenie aplikacji w j?zyku w którym nie maj? do?wiadczenia albo
pisanie w C.

Przy okazji mam pytanie, od dawna si? nie interesowa?em: czykompilator gcc i
j?dro linuxa, x-server s? nadal pisane w C?

> > ?e C++ kompiluje C. Ale potocznie zazwyczaj ma si? na my?li programowanie w C++
> > pe?n? g?b?.

> Nikt w tym w?tklu nie mówi o programowaniu pe?n? g?b? z u?yciem
> obiektowo?ci.


Ale potocznie cz?sto pisz?c o C++ ma si? na my?li pe?ny C++, a nawet biblioteki
do C++, a nawet ?rodowisko programowania wspieraj?ce C++, a nawetGUI-bildery i
programy pomocnicze. Z jednej strony to jest totalne mylenie j?zyka programowania z
narz?dziami, z drugiej strony w praktyce po co komu nawet najlepszy j?zyk je?li
ma kiepskie wsparcie? U?ywanie j?zyka programowania z omijaniem pewnych jego
mo?liwo?ci to te? tak jakby programowanie w innym j?zyku, bo podzbiór danego
j?zyka jest innym j?zykiem.

> W ogóle nie ma tutaj obiektowo?ci poza u?yciem jej w celu
> obs?ugi *ewentualnych* szablonów, bo tak to si? robi w C++..


Nie rozumiem.

> I jakie przy okazji bugogenne. Gdzie? musisz mie? cast. Czy abyna pewno
> znasz wszystkie miejsca gdzie ten cast wyst?puje? Wiesz ju? dlaczego
> ogólnie szablon jest lepszy ni? void*? Podpowiem: bo wykrywa problem na
> kompilacji a nie runtime.


Ale zwykle nie ma rzeczy pod ka?dym wzgl?dem lepszych. Szablon w C++ jest
dobry, bo kompilator pilnuje zgodno?ci typów, bo mo?na zrobi? specjalizacj?,
mo?na wygenerowa? wydajn? wersj? w zale?no?ciod parametrów szablonu. Mówi?
?e szablony s? dobre bo si? pope?nia mniej b??dów wzgl?dem makrodefinicji.
Mnie bardzo dziwi taki sposób porównywania, dlaczego porównywa? do czego? co
powodowa?o (szczególnie u niedo?wiadczonych programistów) b??dy wykrywalne
po dwóch dniach debugowania? Szablony maj? okropn? sk?adni? i podobno lepsza w
ogóle nie istnieje. Osobi?cie wcale nie pope?niam mniej b??dów w szablonach ni?
bez szablonów, w?a?ciwie to wielokrotne dziedziczenie z szablonów masakrycznie
komplikuje kod, debugowanie takiego kodu jest trudniejsze ni? zwyk?ego kodu. W
Javie (poprawcie mnie je?li si? myl?) chyba nie ma szablonów, a wskazywanie
typów przy kontenerach jest tylko dla kompilatora? Wi?c na void* te? mo?na. Z
kolejnych wad szablonów, d?ugi czas kompilacji gdy w programie jest bardzo
du?o szablonów. Kolejna wada, trzeba udost?pni? kod ?ród?owy gdy si?
udost?pnia bibliotek? napisan? w postaci szablonów.. Nast?pna wada, kompilatory
czasami wskazuj? b??d daleko od jego wyst?pienia. Szablony w C++ nadal
maj? braki, ale C++20 ju? nadci?ga.

Podsumowuj?c, kiedy? szablonów u?ywano rzadko albo w ogóle nie u?ywano, mia?em
na komputerze 16MB pami?ci RAM, 1GB na twardym dysku, procesor mo?e 5tys razy
wolniejszy i dzia?a? tam niejeden graficzny system operacyjny, graficzne
?rodowisko programowania, a nawet program do grafiki trójwymiarowej. Jakby to
by?o napisane w 'C++ pe?n? g?b?', to nie wiem czy by dzia?a?o nawet 5 lat
pó?niej - ale na pewno jakby ju? zacz??o dzia?a? to by dzia?a?o lepiej i
szybciej by?oby rozwijane o nowe cechy.

Pozdrawiam
heby (29.01.2020, 21:26)
On 29/01/2020 19:50, M.M. wrote:
> Firma ma kilku pracowników którzy znaj? tylko C i maj? do?wiadczenie w pisaniu
> aplikacji w C. Przychodzi do firmy zamówienie na aplikacj? podobn? do tych w
> jakich maj? do?wiadczenie i aplikacja nie jest kolosalnie du?a. Maj? do wyboru:
> kurs C++ i tworzenie aplikacji w j?zyku w którym nie maj? do?wiadczenia albo
> pisanie w C.


A jak im pewnego dnia podmienisz gcc na g++ to co si? stanie? A jak
pewnego dnia dorzucisz im do kodu class scoped_interrupt_disable to co
si? stanie? Wybuchnie im? Odmówi? pracy bo niekoszerne? Do spowiedzi pójd??

> Przy okazji mam pytanie, od dawna si? nie interesowa?em: czy kompilator gcc i
> j?dro linuxa, x-server s? nadal pisane w C?


gcc:



Kernel to problem bia?kowy. W zasadzie to problem jednego konkretnego
zbioru moleku?, ale ludzie i tak robi? swoje:



x-server nie wiem. Nie przypuszczam aby komukolawiek op?aca?o si? to
przepisywa? dla idei, to raczej kod muzealny.

>> Nikt w tym w?tklu nie mówi o programowaniu pe?n? g?b? z u?yciem
>> obiektowo?ci.>

> Ale potocznie


Czyli mówisz o czym? innym ni? ja. Spieraj si? wi?c z kim? innym.

>> W ogóle nie ma tutaj obiektowo?ci poza u?yciem jej w celu
>> obs?ugi *ewentualnych* szablonów, bo tak to si? robi w C++.

> Nie rozumiem.


U?ycie sk?adni obiektowej (struct/class) nie oznacza ?e u?ywa si?
obiektowo?ci. Sk?adnia ta bowiem przydaje si? w szablonach, jest wr?cz
podstaw? pisania z u?yciem generycznych typów w C++. Nie maj?cych nic
wspólnego z programowaniem obiektowym.

> Ale zwykle nie ma rzeczy pod ka?dym wzgl?dem lepszych. Szablon w C++ jest
> dobry, bo kompilator pilnuje zgodno?ci typów, bo mo?na zrobi? specjalizacj?,
> mo?na wygenerowa? wydajn? wersj? w zale?no?ci od parametrów szablonu. Mówi?
> ?e szablony s? dobre bo si? pope?nia mniej b??dów wzgl?dem makrodefinicji.


Prawda.

> Mnie bardzo dziwi taki sposób porównywania, dlaczego porównywa? do czego? co
> powodowa?o (szczególnie u niedo?wiadczonych programistów) b??dy wykrywalne
> po dwóch dniach debugowania?


Mam buga który ukrywa? si? w void* przed ponad 10 lat. Przed oczami
do?wiadczonych programistów. Jedyny powód ?e uda?o si? go znale?? to
*przypadek*.

> Szablony maj? okropn? sk?adni? i podobno lepsza w
> ogóle nie istnieje.


Lepsza pewnie istnieje, ale te? sk?adnia nie jest okropna.

Serio, uwa?asz ?e:

traits< int >::max

to jaka? okropna sk?adnia? Nie czerpiesz aby przypadkiem wiedzy o
szablonach z jaki? grup anonimowych pisaczy w c?

> Osobi?cie wcale nie pope?niam mniej b??dów w szablonach ni?
> bez szablonów, w?a?ciwie to wielokrotne dziedziczenie z szablonów masakrycznie
> komplikuje kod


Ca?e szcz?scie wielokrotne dziedzidzenie szablonów wyst?puje g?ównie w
bajkach i ksi?zeczkach dla niegrzecznych programistów c.

>, debugowanie takiego kodu jest trudniejsze ni? zwyk?ego kodu.


Robie to codziennie od kilkudziesi?ciu lat i cie?ko mi si? zgodzi?.

> W
> Javie (poprawcie mnie je?li si? myl?) chyba nie ma szablonów, a wskazywanie
> typów przy kontenerach jest tylko dla kompilatora?


Java ma typy generyczne. Nie ma wprost ?atwego przeniesienia na C++.
G?ównie dlatego ?e typy w C++ s? przeliczane na etapie kompilacji i
generuj? inne typy. To inna filozofia. Jaba zatrzyma?a si? g?ównie na
vector< int >, C++ jest o eniony dalej, cho? cz?sto eniony krzaków
dalej, przyznaje.

> Wi?c na void* te? mo?na.


To nie jest dyskucja czy mo?na. Mo?na uzy? popsutych korutyn. No
przecie? jak si? ma tak?specyfikacj? to nawet trzeba. Jak co? dzia?a to
nie naprawia?. Lepse jest wrogiem dobrego. Itd itp bzdury.

Na void* nie mo?na bo:
a) generuje to wi?cej b?edów runtime
b) uniemo?liwia skuteczne refaktoringi
c) narz?dzia do lintowania wybijaja sobie z?by
d) narz?dzia do statycznych analiz kodu s? zagubione
e) code review nie przejdzie

Ale oczywis?ie znam milion przyk?adów ?e mo?na mimo to. To "mo?na" to
kwesia zwyk?ej higieny. Mo?na pisa? na void* tak samo jak mo?na mieszka?
przy wysypisku i udawa? ?e to wiejskie zapachy.

> Z
> kolejnych wad szablonów, d?ugi czas kompilacji gdy w programie jest bardzo
> du?o szablonów.


Jeste? nastepnym developerem w tej dyskusji z Atari 65XE jako ci?g??
integracj??

Pracuje na *zaje...e* ogromnej bazie kodu w C++. Kompilacja najd?u?szego
i najbardziej popieprzonego pliku (zawiera g?ównie boost::spirit)
napisanego z palca trwa co? pod 3 sek. Uwierz mi, to jest makabrycznie
du?o zaawansowanego C++ i *tylko* 3 sekundy. Czy ju? umar?e? z nudów?

> Kolejna wada, trzeba udost?pni? kod ?ród?owy gdy si?
> udost?pnia bibliotek? napisan? w postaci szablonów.


Brednia.

> Nast?pna wada, kompilatory
> czasami wskazuj? b??d daleko od jego wyst?pienia.


Brednia w 99% wypadków.

> Podsumowuj?c, kiedy? szablonów u?ywano rzadko albo w ogóle nie u?ywano


Podobnie jak z papierem toaletowym.

>, mia?em
> na komputerze 16MB pami?ci RAM, 1GB na twardym dysku, procesor mo?e 5tys razy
> wolniejszy i dzia?a? tam niejeden graficzny system operacyjny, graficzne
> ?rodowisko programowania, a nawet program do grafiki trójwymiarowej.


Na patrz, a ja mia?em Amig? z 2MB pami?ci chip i na tej konfiguracji
pogania?em SaSC w trybie C++ pisz?c obiektowe programy GUIowe. Mo?e to
czary?

> Jakby to
> by?o napisane w 'C++ pe?n? g?b?', to nie wiem czy by dzia?a?o nawet 5 lat
> pó?niej - ale na pewno jakby ju? zacz??o dzia?a? to by dzia?a?o lepiej i
> szybciej by?oby rozwijane o nowe cechy.


A po chwili si? budzisz i okazuje si? ?e ten sam program kompilowalny w
C i C++ generuje dok?adnie taki sam kod asemblerowy.

No, ale wiadomo, 100x wolniejszy bo to C++. Du?o NOPów si? wstawia na
z?o?? tym wszystkim zaprza?com.
Maciek Godek (29.01.2020, 22:41)
W dniu ?roda, 29 stycznia 2020 18:19:27 UTC+1 u?ytkownik heby napisa?:
> On 29/01/2020 08:31, Maciek Godek wrote:
> > Wol? po prostu nie dok?ada? niepotrzebnych zale?no?ci.

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

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

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

> > Po pierwsze, C i C++ s? niekompatybilne.

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

x.c <<EOF
#include <stdio.h>

int main(int argc, const char *argv[]) {
struct {
int x;
char c;
} s = {
.c = 'a',
.x = 7
};
printf("%c%d\n", s.c, s.x);
return 0;
}
EOF

# gcc x.c
# ./a.out
a7
# g++ x.c
x.c: In function ?int main(int, char**)?:
x.c:10:3: sorry, unimplemented: non-trivial designated initializers not supported
};
^
x.c:10:3: sorry, unimplemented: non-trivial designated initializers not supported

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

> >> 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.
Przedstawia?em pewne rozwi?zanie, które jest stosowalne równie? poza kontekstem, w którym je sformu?owa?em.
Rozwi?zanie oczywi?cie mo?na zasadnie krytykowa?, ale od?wie?anie starego flamewara "C vs. C++" ma umiarkowany sens.

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

> Ca?y czas chcesz by Ci czyta? w my?lach. To nie jest mo?liwe.


Wystarczy, ?e nie b?dziesz proponowa? rozwi?za? odczapy.

> [...]
> yeld( 42 );
> for( i = 6 ; i < 10 ; ++i )
> [...]
> yeld( i );
> [...]


Czas start.

int f(void) {
COROUTINE_START();
static int i;
COROUTINE_YIELD(42);
for (i = 6; i < 10; ++i ) {
COROUTINE_YIELD(i);
}
}

Hmm. Chyba wygl?da do?? tak samo.

> W zasadzie napisanie dowolnego nieco bardziej skomplikowanego generatora
> wymaga natychmiast u?ycia workaroundu ze zmiennymi statycznymi.
> 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.

> 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 procesubez zmiennej globalnej.

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

> Mo?e co? narze?bi? w wolnej chwili. Uzywa?em tego przez jaki? czas z
> miernym skutkiem i raczej nie znajduje powodów do powrotu.


Nie ma potrzeby. Ju? zrobi?em:

#define CO_START() \
static int continuation = 0; \
switch(continuation) { \
case 0:

#define CO_YIELD(value) \
continuation = __LINE__; \
return value; \
case __LINE__:

#define CO_END() default: continuation = 0; }
heby (29.01.2020, 23:25)
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?.

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



"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.
Roman Tyczka (29.01.2020, 23:37)
On Wed, 29 Jan 2020 18:19:23 +0100, heby wrote:

> do jaki? absurdalnych przypadków 8051 z kompiltorem pisanym przez


jaki? jaki'?
jakich? jakich'?

Uprzedzaj?c zarzut o nazizm gramatyczny:

>> I to zaproponowa?e?, mimo ?e nikt Ci? o to nie prosi?.

> Taka natura ludzka: jesli kto? si? przewróci to staram si? mu pomóc.


Popieram ;-)

Podobne wątki