🚀 go-pugleaf

W dniu poniedziałek, 27 stycznia 2020 20:51:25 UTC+1 użytkownik heby napisał:
> On 27/01/2020 20:24, Maciek Godek wrote:
> > Konkretnie dlatego, że rozwijam system w języku C, i potrzebuję mechanizmu dla języka C.
> 
> I dlaczego nie możesz uzy kompilatora C++?

Mam wiele powodów. Ale nie tego dotyczy ten wątek.

> >> W systemach gdzie się przydaje na 100% jest C++. W 99.9%
> >> wypadków wystarczy zamienić gcc na g++.
> > Tak. Można też np. osadzić interpreter Lua, który też wspiera coroutines.
> 
> 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. Pomijając jeszcze tę kwestię, że trzeba go jeszcze najpierw zainstalować. A później jeszcze zainstalować boosta.
I to u każdego developera, który pracuje nad tym projektem.
Żeby używać ficzeru, którego zaimplementowanie zajmuje 20 linijek w C. I to w dodatku implementacji, co do której nie wiem, czy nie będzie z nią problemu w kontekście, w którym chcę go użyć. I to po to, żeby później refaktoryzować kod, kiedy ficzer wejdzie do standardu. O ile oczywiście komitet nie zmieni go na tyle, że przestanie się nadawać do moich zastosowań.

Dzięki, ale nie, dzięki.

> >> Po co komu coroutines w C skorą są/będą w C++?
> > To teraz powiedz mi:
> > - czy powinienem teraz korzystać z coroutines ze standardu, który jeszcze nie został zatwierdzony, czy może raczej wziąć teraz boosta, a później usuwać zależności i refaktoryzować do standardu?
> 
> Użyć boosta, dorobić abstrakcję i zrefaktoryzować jak będzie po co za 
> kilka lat.

"Dorobić abstrakcję"?

A nie mogę od razu użyć docelowego rozwiązania?

To jest 20 linijek kodu. 

A boost ma... no, ile linijek?

> > - w jaki sposób te korutyny są w booście albo w standardzie zaimplementowane? Czy potrafisz z całą pewnością powiedzieć, że nie będzie problemu ze wznawianiem ich w interrupt handlerach na ARMach?
> 
> "[...] Pomysł opiera się na rozszerzeniu kompilatora GCC [...]"
> 
> 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 to nie jest "side effect", tylko udokumentowane rozszerzenie języka.
I to nie jest "jakaś implementacja", tylko jedna z najczęściej używanych implementacji.

> 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.
Żeby móc sobie pisać wątki na przerwaniach.  Więcej na ten temat pisałem na comp.lang.c.
Widzisz w tym jakiś problem?

> > Czy może potrzebuję nadać im jakiś magiczny atrybut w rodzaju "nothrow", żeby mieć pewność, że to zadziała dla mojego use case'u?
> 
> Dlaczego masz nadawać nothrow? Jak exception spadnie na dno stosu to w 
> dowolnej implementacji dzieją się interesujace rzeczy.

Rzecz w tym, że zarówno wyjątki, jak i korutyny są mechanizmem transferu sterowania. Nie do końca rozumiem, jak działają wątki w C++, ani tym bardziej jak działają korutyny w C++.

Co więcej, nie interesuje mnie to do tego stopnia, żebym chciał poświęcać czas na uczenie się tego i analizę wszystkich sytuacji, w których coś może pójść nie tak.

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?

> A już najbardziej interesujace rzeczy dzieją się jak ten exception jest 
> wywołany z Twojego C...

Cóż. Rzecz wygląda tak, że zarówno wątki, jak i korutyny, to mechanizmy kontroli sterowania. Byłbym wręcz zaskoczony, gdyby okazało się, że te dwa mechanizmy w standardzie C++20 nie będą wchodziły sobie w paradę, i trzeba będzie czekać do C++32, aż to naprawią. Takie historie przecież już były. Choćby z "range based for", na którą trzeba było czekać kilkanaście lat, a jak już dodali, to okazało się, że jest skopana.

> > Bo u mnie to jest 20 linijek bardzo prostego kodu.
> 
> 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"?

GCC jest, przede wszystkim, szeroko używanym kompilatorem o otwartych źródłach i bogatej dokumentacji, z dużym wsparciem ze strony przemysłu hardware'owego.