🚀 go-pugleaf

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++? To kwestie religijne?

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

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

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

Jesteś pewny że ktokolwiek będzie uzywać *KORUTYN* w handlerach przerwań 
na ARMie czy innym 6502? Żartujesz, powiedz proszę.

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

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

> Bo u mnie to jest 20 linijek bardzo prostego kodu.

Bazującego feature jakiegoś kompilatora o niejasnej przyszłosci i 
przenośności.