Coroutines w (GNU) C

[Maciek Godek]

Jeśli by to kogoś interesowało, to dziś "wymyśliłem" prosty sposób na implementację "coroutines" w C.

Pomysł opiera się na rozszerzeniu kompilatora GCC pozwalającym na przechowywanie etykiet dla goto w zmiennych, i możliwości skakania do tych zmiennych:

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Interfejs jest taki, że na początku funkcji musimy wywołać makro

COROUTINE_START()

i dalej możemy użyć

COROUTINE_RETURN(wartość)

co zadziała jak normalne wyjście z funkcji, albo

COROUTINE_YIELD(wartość)

co spowoduje przerwanie egzekucji funkcji, przy czym kolejne wywołanie
funkcji spowoduje jej kontynuowanie za ostatnio wykonanym wyrażeniem COROUTINE_YIELD.

Na przykład kod może wyglądać tak:

int coroutine() {
COROUTINE_START();

printf("started\n");
COROUTINE_YIELD(1);

printf("stage 1\n");
COROUTINE_YIELD(2);

printf("stage 2"\n");
COROUTINE_YIELD(3);

printf("finishing\n");
COROUTINE_RETURN(4);
}

Drobny problem jest z przekazywaniem parametrów: jeżeli chcemy, żeby wartości argumentów były przechowywane między wywołaniami, to musimy je zapisywać w zmiennych statycznych.

Implementacja składa się z nieco ponad 20 linii kodu:

#define COROUTINE_START() \
static void *coroutine_continuation = \
&&coroutine_start; \
goto *coroutine_continuation; \
coroutine_start: \
do {} while(0)

#define COROUTINE_RESTART \
coroutine_continuation = &&coroutine_start

#define COROUTINE_RETURN(...) \
COROUTINE_RESTART; return __VA_ARGS__

#define _COROUTINE_LABEL(line) coroutine_##line
#define COROUTINE_LABEL(line) _COROUTINE_LABEL(line)

#define COROUTINE_YIELD(...) \
coroutine_continuation = \
&&COROUTINE_LABEL(__LINE__); \
return __VA_ARGS__; \
COROUTINE_LABEL(__LINE__): \
do {} while(0)

[Borneq]

On 1/24/20 12:44 PM, Maciek Godek wrote:
> Jeśli by to kogoś interesowało, to dziś "wymyśliłem" prosty sposób na implementację "coroutines" w C.
>

A nie znane z C : setjmp/longjmp?

[Maciek Godek]

Kiedyś dla zabawy napisałem sobie implementację wątków w oparciu o setjmp.h:

https://github.com/panicz/hubertos/blob/master/hubertos.c

Ale to jest w moim odczuciu raczej ciężki mechanizm (podobnie
jak call/cc w Scheme) i raczej wolę go nie używać w produkcyjnym kodzie.

Natomiast jeżeli idzie o powyższą implementację coroutines, to jest
bardzo prosta, i chociaż jest parę sposobów, na jakie można ją źle użyć
(np. zmienne automatyczne będą miały w po przywróceniu sterowania
nieokreślone wartości, i można omyłkowo napisać "return" zamiast
COROUTINE_RETURN), to ogólnie wydaje się raczej spolegliwym mechanizmem.

Zresztą moja intencja użycia jest właśnie taka, żeby sobie przy ich
pomocy robić "takie jakby wątki" w kodzie opartym na przerwaniach.

[Borneq]

On 1/24/20 10:26 PM, Maciek Godek wrote:
> Zresztą moja intencja użycia jest właśnie taka, żeby sobie przy ich
> pomocy robić "takie jakby wątki" w kodzie opartym na przerwaniach.

Głównym problemem przy wątkach a nawet coroutinach jest oddzielny stos
dla każdego włókna, gdzie może być wołana funkcja rekurencyjna.

[heby]

On 24/01/2020 12:44, Maciek Godek wrote:
> Jeśli by to kogoś interesowało, to dziś "wymyśliłem" prosty sposób na implementację "coroutines" w C.

https://www.boost.org/doc/libs/1_70_0/libs/coroutine/doc/html/index.html

[Maciek Godek]

?

[heby]

On 26/01/2020 20:00, Maciek Godek wrote:
>> https://www.boost.org/doc/libs/1_70_0/libs/coroutine/doc/html/index.html
> ?

Nie wiem o co pytasz bo się nie dosłał tekst pytania, ale odpowiem w ciemno:

Nie ma sensu pisać czegoś co już jest, w dodatku boostowe coroutines
używają boost::context, a te znowu ośmielają się twierdzić że:

https://www.boost.org/doc/libs/1_67_0/libs/context/doc/html/context/performance.html

[Maciek Godek]

W dniu niedziela, 26 stycznia 2020 20:44:16 UTC+1 użytkownik heby napisał:
> On 26/01/2020 20:00, Maciek Godek wrote:
> >> https://www.boost.org/doc/libs/1_70_0/libs/coroutine/doc/html/index.html
> > ?
>
> Nie wiem o co pytasz bo się nie dosłał tekst pytania, ale odpowiem w ciemno:
>
> Nie ma sensu pisać czegoś co już jest

To jest dla C++.
C++20 ma mieć coroutines w standardzie (a Microsoft Visual C++ wspiera już od jakiegoś czasu, tak że efektywnie można sobie pisać C# w C++ np. na UWP)

Moje rozwiązanie jest dla C.

[heby]

On 27/01/2020 07:53, Maciek Godek wrote:
> Moje rozwiązanie jest dla C.

A po co? W systemach gdzie się przydaje na 100% jest C++. W 99.9%
wypadków wystarczy zamienić gcc na g++.

Po co komu coroutines w C skorą są/będą w C++?

[Maciek Godek]

W dniu poniedziałek, 27 stycznia 2020 19:12:00 UTC+1 użytkownik heby napisał:
> On 27/01/2020 07:53, Maciek Godek wrote:
> > Moje rozwiązanie jest dla C.
>
> A po co?

Konkretnie dlatego, że rozwijam system w języku C, i potrzebuję mechanizmu dla języka C.

> 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.
Albo zmienić pracę.

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

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

Czy może potrzebuję nadać im jakiś magiczny atrybut w rodzaju "nothrow", żeby mieć pewność, że to zadziała dla mojego use case'u?

Bo u mnie to jest 20 linijek bardzo prostego kodu.

[heby]

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.

[Maciek Godek]

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.

[heby]

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.

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

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

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

> To jest 20 linijek kodu.
> A boost ma... no, ile linijek?

Biliard. W sumie bez znaczenia. U mnie to i tak jeden #include.

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

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

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

> Żeby móc sobie pisać wątki na przerwaniach.

OK, oczywisćie sprawdziłeś overheat przełaczanai stosów i zapisywania
kontekstu rejestrów?

Zaryzykuje: a sprawdziłeś co oferuje FreeRTOS?

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

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

Korutyny w c++ działaja tak samo jak cooperative mutitasking w C.
Zapamiętuje się stos, rejestry i przepina na inny "fiber". Wsio.
Technologia z lat 70 gdzieś chyba.

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

Ależ niestety musisz. Przez ten kod na statycznych zmiennych jesteś
zmuszony do analizy i to choelrnie cieżkiej bo masz praktycznie
preemptive multitasking, w przerwaniach. Albo ciezka analiza albo game over.

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

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

PS. Mała uwaga: coroutines wymagają *czegoś* ze stosem. kopiowania,
podmieniania, czegokolwiek. To jest ten brakujący ficzer w implementacji.

[Maciek Godek]

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.

[heby]

On 27/01/2020 23:17, Maciek Godek wrote:
> Jakiś czas temu pracowałem przy projekcie [...]

Czyli jednak religia. Coś z okolic "C++ zajmuje dużo" i jakiś inny tego
typu krap którego pełno na necie.

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

Wiadomo. Najlepiej wynajdywać kwadratowe koła. Nie przejmuj się, całe
embedded tak robi; widziałem, liczone w tysiące, procedury zamiany inta
na tekst. Połowa z bugami. A co dopiero coroutines.

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

> że Ty sobie używasz jakiejś technologii, i ja sobie używam innej technologii

Kilka kiepskich makr cieżko nazwać technologią.

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

> Nie wiem, dlaczego to dla Ciebie tak wielki problem.

To w ogóle nie jest problem. Świat z utęsknieniem czeka na następny
zbiór makr rozwiązujących problemy które nie istnieją gdzie indziej.

> A rozmowy z entuzjastami C++ są zawsze intelektualnie rozczarowujące.

Ostro :D

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

Masz prawo do zdania odmiennego od reszty świata.

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

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.

> 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 gdzie coroutines dostaniesz jako
cooperative multitasking. Albo nawet preemptive jak trzeba. Przy okazji
za friko dostaniesz rozwiązanie drobnostek takich jak "komunikowanie się
przerwań przez zmienne globlane" itp detale

> Ja go nie lubię, i mam dobre powody do tego, żeby go nie lubić.

Nie, masz tylko ideologię i religię. Tak jak dekarze który nie używają
młotków bo nie lubią. Lutownicą też się da wbijać gwoździe w papę,
dziadek tak robił.

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

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

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

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

> Kwestia tego, czy warto.

Nie warto. Pisanie na zmiennych statycznych/globalnych jest hardkorowe i
tak robią Prawdziwi Programiści.

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

> Tutaj tego nie ma.

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

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

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

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

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

To inny przypadek.

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

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

To nie jest jakiśtam problemik. To dyskwalifikacja bo w środku tych
korutyn nie działa nawet prymitywny C. To nie są coroutines, to tylko
kilka jumpów o fancy nazwach.

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

Który w języku C wymaga stosu. Stos jest częscią kontekstu. Nie masz w
korutynie przechowania pełnego kontekstu, nie masz korutyn tylko jakieś
jumpy którym bliżej do asemblera niż C.

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. Też tym sposobem da się osiągnąć "korutynę" bez zmiennych
automatycznych. I też w kilku linijkach. I też kompletnie bez sensu w
prawdziwych zastosowaniach. Bo tak naprawdę to jest tylko popsuta
maszyna stanów. A nie coroutine.

[Mateusz Viste]

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]

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.

[M.M.]

On Tuesday, January 28, 2020 at 11:30:09 PM UTC+1, Mateusz Viste wrote:
> 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.

No właśnie, są pewne okoliczności w których lepiej uż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.

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

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, nigdy wcześ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 w przypadku 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żna optymalnie 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]

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

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 po obowią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.

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

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 kolejnych zamó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]

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]

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]

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]

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]

On 29/01/2020 18:19, heby wrote:
> yeld( 42 );

yield oczywiście, dla czepialskich.

[M.M.]

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 C zamiast 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: czy kompilator 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 nawet GUI-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.

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

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

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:

https://lwn.net/Articles/542457/

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

https://pograph.wordpress.com/2009/04/05/porting-cpp-code-to-linux-kernel/

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.

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

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ń od czapy.

> >> 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 );
> [...]

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.

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

To pokaż mi jak przekazać informację z przerwania do procesu bez 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]

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

>> yeld( 42 );
>> for( i = 6 ; i < 10 ; ++i )
>> [...]
>> yeld( i );
>> [...]
> 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?

https://en.wikipedia.org/wiki/Coroutine

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

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


--
pozdrawiam
Roman Tyczka

[Maciek Godek]

W dniu środa, 29 stycznia 2020 22:25:33 UTC+1 użytkownik heby napisał:
> >> yeld( 42 );
> >> for( i = 6 ; i < 10 ; ++i )
> >> [...]
> >> yeld( i );
> >> [...]
> > 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ć?

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

To, czy użyjesz zmiennej automatycznej, czy statycznej, to tylko drobna różnica w implementacji. Funkcjonalnie ten kod jest identyczny.
A jeżeli nie jest, to pokaż mi proszę różnicę.

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

Korutyna nie jest "pure function".
Poczytaj sobie może troszkę, zanim zaczniesz używać terminologii.
Czyste funkcje w ogóle nie mają czegoś takiego, jak "przebieg sterowania".

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

No to pokaż mi różnicę behawioralną. Pokaż, jak jedna się może zepsuć, a druga nie może, bo na razie to tak sobie gadasz.

[heby]

On 29/01/2020 22:37, Roman Tyczka wrote:
>> do jakiś absurdalnych przypadków 8051 z kompiltorem pisanym przez
> jaki? jaki'ś
> jakich? jakich'ś
> Uprzedzając zarzut o nazizm gramatyczny:

Nie padnie. Jestem zwykłym leniem gramatycznym i zbywam takie zaczepki
głębokim ziewem. ;)

[M.M.]

On Wednesday, January 29, 2020 at 8:26:51 PM UTC+1, heby wrote:
> 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ą?

Nie wiem co się stanie. Prosiłeś o przykład, więc podałem. Wszystko ma
swoje wady i zalety, nawet C++ ma wady względem C, a jako nadzbiór nie
powinien mieć wad. Koszt przeszkolenia jest nie do przeskoczenia.

Dlatego ja się nie dam nabrać więcej na nowe super technologie. Programowało
się kiedyś na kartach perforowanych, potem w kodzie binarnym, potem w asemblerach
gorszych, potem w lepszych, potem w makroaseblerach, w końcu w gorszych
językach wysokiego poziomu, w lepszych i w najlepszych... Nie zaprzeczam że
nastąpił rozwój technologii wytwarzania oprogramowania, ale po pierwsze nie
wierzę że ten rozwój nie wpadał i nie wpada w ślepe uliczki, a po drugie,
jest takie prawo w ekonomii którego nazwy już nie pamiętam, ale mówi ono o
tym, że od pewnego momentu trzeba niewspółmiernie dużo pracy włożyć w
udoskonalanie, aby uzyskać minimalnie lepsze efekty. Jak myślisz, ile pracy
trzeba włożyć, żeby przyspieszyć trabanta rozpędzający, a ile, aby
przyspieszyć najszybszy samochód na świecie i tym samym pobić rekord prędkości?

Podobnie jest od jakiegoś czasu z językami programowania, języki rozbudowane i
dopracowane o milion procent, dają przyspieszenie procesu wytwarzania
oprogramowania o kilka procent. A nakład środków na przeszkolenie personelu
lub samego siebie jest tym większy, im język bardziej rozbudowany. Zmiana
technologii opłaca się dopiero na dłużą metę, do większych projektów.

>
> > 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:
>
> https://lwn.net/Articles/542457/
>
> Kernel to problem białkowy. W zasadzie to problem jednego konkretnego
> zbioru molekuł, ale ludzie i tak robią swoje:
>
> https://pograph.wordpress.com/2009/04/05/porting-cpp-code-to-linux-kernel/
>
> 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.

Spokojnie, ja jeszcze nie jestem pewny o co się spieramy :)
Napisałem o tym z jakim sposobami używania określenia 'programowanie w C++'
się spotkałem, dlatego żeby wiedzieć o czym rozmawiamy.

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

Dlaczego?

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

Chyba nadal nie rozumiem. A jakie wnioski z tego płyną?

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

A ja zapewne mam niejeden taki błąd w szablonach.

>
> > Szablony mają okropną składnię i podobno lepsza w
> > ogóle nie istnieje.
>
> Lepsza pewnie istnieje, ale też składnia nie jest okropna.

No dobrze, ja nie lubię, ale kilku dyskutantów przed laty też mówiło że
nie lubi.

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

Racja, takie proste przypadki są bardzo przejrzyste. Miałem na myśli sytuacje
gdy jeden szablon jest parametryzowany kilkoma innymi szablonami i jeszcze
dziedziczy z innego szablonu. Potem gdzieś w klasie jakaś statyczna tablica,
wszystko w kilku wersjach zależne od kompilacji warunkowej... Naprawdę w
takich sytuacjach mocno tęsknię za minimalistycznym C++ albo za Javą, ale
cóż, przyznaję, że ani w Javie, ani w minimalistycznym C++ takiego efektu
nie uzyskam. Natomiast nie przyznam że szablony stanowią elegancką i
przejrzystą składnię, sprzyjającą analizie kodu i sprzyjającą pisaniu kodu
pozbawionego błędów. Tak się mówi że szablony stanowią antidotum na błędy, bo
porównuje się je zwykle do najbardziej błędogennych konstrukcji języka, jak
wlaśnie do makr, albo do rzutowania na void*.

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

Wielokrotnie w sensie że jedna klasa (szablon) dziedziczy z bezpośrednio z
kilku to owszem rzadko spotykana konstrukcja i niekoniecznie zalecana.
Ale pośrednie wielokrotnie dziedziczenie, typu X dziedziczy z Y, Y z Z, a Z
może z kolejnych - to sytuacja częsta. Gdy każde jeszcze ma jakieś parametry i
typy - to naprawdę zazwyczaj dostawałem oczopląsu gdy analizowałem swój własny
kod po krótkim czasie. Myślę że każdy programista uznałby za łatwiejszy w
analizie kod np. Javy.

> >, debugowanie takiego kodu jest trudniejsze niż zwykłego kodu.
>
> Robie to codziennie od kilkudziesięciu lat i cieżko mi się zgodzić.

Może zwykle używasz szablonów po bożemu, a nie do optymalizacji kodu? No i
szablony porównujesz to do makr i void* - czyli do czegoś najbardziej
błędogennego. Jeśli używam w pewien określony sposób szablonów, to też
nie mam z nimi problemów. Ale gdy np. cały algorytm genetyczny parametryzuję
kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
edytor nie wie jakie metody będą miał parametry.

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

To wszystko prawda, choć z review to zależy gdzie :-) Nie chciałem
absolutnie powiedzieć, że macie olać szablony i wrócić do void*.
Chciałem powiedzieć, że jeśli sobie radzono bez szablonów i system
operacyjny z GUI działał na 16MB RAM i pentium I 160MHz - to nie
ulegajmy złudzeniu, że te szablony aż tak niesłychanie dużo wnoszą.
Nigdy nie negowałem szablonów, ale też nigdy nie powiem, że brak
szablonów to strona czarna, a programowanie z szablonami to strona
biała.

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

Mam nadzieję że już jest zrozumiałe, iż nie namawiam nikogo do zrezygnowania z
szablonów, szczególnie używanych po bożemu, tylko zwracam uwagę na to, żeby
nie traktować szablonów jako czegoś dzięki czemu technologia wytwarzania
oprogramowania przyspieszyła o kiladziesiąt procent, bo bez szablonów była
już całkiem szybkim samochodem, który trudo przyspieszać w nieskończoność.

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

Nie, po prostu czasami mam w kodzie nasrana pełno szablonów, jeden szablon
jest parametryzowany innymi, te inne też są parametryzowane jeszcze innymi, a
niektóre są w kilku wersjach. Jeśli zmieniam warunki kompilacji warunkowej to
muszę czekać 30 sekund na pełną rekompilację (relatywnie) małego programiku, a
test często też trwa 30 sekund. Po prostu Ty używasz szablonów inaczej niż ja, i
odpisałeś ze swojej perspektywy. Ja jeśli sięgam po szablony to jest też
jakieś prawdopodobieństwo że chcę optymalizować kod, np. chcę wygenerować
skrojony sporawy kod na miarę konkretnego przypadku do rozwiązania.

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

Ja przed chwilą dodałem do kompilacji -DOPCJA_X i czekałem na pełną
kompilację z 30 sekund na dwóch rdzeniach. Jak jeszcze jest pomiędzy
kompilacją -fprofile-generate i -fprofile-use to czekam 2 minuty aby
zrobić 30 sekundowy test.

> > Kolejna wada, trzeba udostępnić kod źródłowy gdy się
> > udostępnia bibliotekę napisaną w postaci szablonów.
>
> Brednia.

To chętnie się dowiem dlaczego, myślałem że szablony to nagłówki niezbędne
do wygenerowania konkretnej wersji kodu, jak to udostępnić w wersji
binarnej bez źródeł?

> > Następna wada, kompilatory
> > czasami wskazują błąd daleko od jego wystąpienia.
>
> Brednia w 99% wypadków.

U mnie w około 30% przypadków jest to prawda.

>
> > Podsumowując, kiedyś szablonów używano rzadko albo w ogóle nie używano
>
> Podobnie jak z papierem toaletowym.

Tylko że papier toaletowy nie ma nic wspólnego z programowaniem, a (nie)używanie
szablonów ma sporo.

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

Może czary, a może to (w jakimś stopniu) dzięki void* ?

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

Przecież to jest oczywiste, że każda konkretyzacja szablonu oznacza nie
tylko różny kod, ale nowy dodatkowy kod. Co nie znaczy, że nie można
używać szablonów tak, aby łatwo zrobić kilka eksperymentów i wybrać
wariant generujący najmniejszy kod.

> No, ale wiadomo, 100x wolniejszy bo to C++. Dużo NOPów się wstawia na
> złość tym wszystkim zaprzańcom.

Hmmmm a to zaprzańcy ;-)


Pozdrawiam

[heby]

On 29/01/2020 22:40, Maciek Godek wrote:
>> Jeb. Właśnie użyłeś zmiennej globalnej. Ojej. Co się może stać?
> No. Co się może stać?

Się stan może pomieszać między korutynami.

>> 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ć.
> To, czy użyjesz zmiennej automatycznej, czy statycznej, to tylko drobna różnica w implementacji.

Nie, to różnica między programowaniem funkcyjnym a tym drugim.

> Funkcjonalnie ten kod jest identyczny.

Nie. Bo zależy to od reszty kodu którego nie widać. Konkretnie kod *nie*
pure nie da się ocenić patrząc tylko w jedną funkcję.

> A jeżeli nie jest, to pokaż mi proszę różnicę.

Dwie identyczne korutyny przeplatające się w jednym flow będa się zakłócać.

Dwie identyczne korutyny nie przeplatajace się, ale będące w różnych
wątkach będa się zakłucać.

Poprawnie napisana bibliteka do coroutines nie będzie miała tych wad
ponieważ zadba o *osobny* stos per wywołanie. Tak robi każda znana mi
bibliteka do korutyn w jezykach imperatywnych. W tych innych pewnie też.

>> 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".
> Korutyna nie jest "pure function".

Nie ma przeszkód aby była. Przykładowo spora częśc wzorca projektowego
"generator" jest pure i jest korutyną. Iteratory są korutyną i są
zazwyczaj pure. W ogóle, wiele rzeczy jest pure. Bez znaczenia czy to
korutyny czy zwykłe funkcje.

Tylko nie u Ciebie. U Ciebie każde użycie zmiennej kończy się byciem
"nie pure". Chyba że zastosujesz lokalny kontener na zmienne, ale wtedy
musisz zarządzań nim poza korutynami. I tak wynalazłeś właśnie
cooperative multitasking, tylko kwadratowy.

> Poczytaj sobie może troszkę, zanim zaczniesz używać terminologii.

O ba, Panie, ja to stosuje od dawna. Przeczytałem to z jakieś 20 lat
temu, obecnie bazuje wyłącznie na własnej ignorancji.

> Czyste funkcje w ogóle nie mają czegoś takiego, jak "przebieg sterowania".

No i wychodzi na to że nie czaisz bazy. Moja *funkcja* jest pure. Twoja
nie. Obie są korutynami.

Ja mogę napisać "nie pure" funkcje jak chcę lub muszę.

Ty nie możesz napisać pure poza duperelowatymi funkcyjkami bez stanu. Bo
mechanizm ma fundamentalną wadę. Stan jest poza lokalnym stosem. Game over.

>> 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.
> No to pokaż mi różnicę behawioralną. Pokaż, jak jedna się może zepsuć, a druga nie może, bo na razie to tak sobie gadasz.

Och, puśc tą samą korutynę 2x w jednym flow, na przemian.

Moja zadziała, twoja zaplącze się we wspólnym stanie.

Nie ma manipulacji stosem, nie ma korutyn. Jest tylko "jump oriented
programming".

[Maciek Godek]

W dniu środa, 29 stycznia 2020 22:48:44 UTC+1 użytkownik M.M. napisał:
> > > Szablony mają okropną składnię i podobno lepsza w
> > > ogóle nie istnieje.
> >
> > Lepsza pewnie istnieje, ale też składnia nie jest okropna.
>
> No dobrze, ja nie lubię, ale kilku dyskutantów przed laty też mówiło że
> nie lubi.

Ja też nie lubię. Jest koszmarna. I niejednoznaczna. I nierozstrzygalna.

[Maciek Godek]

W dniu środa, 29 stycznia 2020 22:56:31 UTC+1 użytkownik heby napisał:
> On 29/01/2020 22:40, Maciek Godek wrote:
> >> Jeb. Właśnie użyłeś zmiennej globalnej. Ojej. Co się może stać?
> > No. Co się może stać?
>
> Się stan może pomieszać między korutynami.

Pokaż przykład.

> Dwie identyczne korutyny przeplatające się w jednym flow będa się zakłócać.

Podaj przykład.

> Dwie identyczne korutyny nie przeplatajace się, ale będące w różnych
> wątkach będa się zakłucać.

Semantyka korutyn w różnych wątkach nie jest nawet dobrze określona.
Nie wiadomo, jak się powinno zachowywać.

> >> 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".
> > Korutyna nie jest "pure function".
>
> Nie ma przeszkód aby była.

Jest zasadnicza. Korutyna ma swój stan wewnętrzny, który z definicji jest mutowalny.
A czysta funkcja robi tylko jedno: odwzorowuje wejście w wyjście. Zawsze dla tego samego wejścia ma dać to samo wyjście. Nie ma stanu wewnętrznego.

I to jest dość kolosalna przeszkoda.

> > Czyste funkcje w ogóle nie mają czegoś takiego, jak "przebieg sterowania".
>
> No i wychodzi na to że nie czaisz bazy. Moja *funkcja* jest pure. Twoja
> nie. Obie są korutynami.

Korutyna to nie jest funkcja. Tutaj masz definicję, proszę:
https://pl.wikipedia.org/wiki/Funkcja

> >> 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.
> > No to pokaż mi różnicę behawioralną. Pokaż, jak jedna się może zepsuć, a druga nie może, bo na razie to tak sobie gadasz.
>
> Och, puśc tą samą korutynę 2x w jednym flow, na przemian.

Nie wiem o czym mówisz. Napisz kawałek kodu, to będę wiedział.
Problem jest taki, że określenie "ta sama korutyna puszczona 2x w jednym flow" nie jest jednoznaczna, bo nie wiem, co masz na myśli mówiąc "ta sama korutyna". Kawałek kodu wszystko wyjaśni.

[Maciek Godek]

W dniu środa, 29 stycznia 2020 22:56:31 UTC+1 użytkownik heby napisał:

> Och, puśc tą samą korutynę 2x w jednym flow, na przemian.

Postanowiłem spróbować. Zmiksowałem ze sobą parzyste i nieparzyste wywołania tej samej korutyny w jednym flow:

void jeden_flow(void) {
ta_sama_korutyna(); // wywołanie nieparzyste
ta_sama_korutyna(); // wywołanie parzyste
ta_sama_korutyna(); // wywołanie nieparzyste
ta_sama_korutyna(); // wywołanie parzyste
}

dla porównania tutaj mam po prostu ciąg wywołań tej samej korutyny, bez przemieszania:


void bez_miksowania(void) {
ta_sama_korutyna(); // pierwsze wywołanie
ta_sama_korutyna(); // drugie wywołanie
ta_sama_korutyna(); // trzecie wywołanie
ta_sama_korutyna(); // czwarte wywołanie
}


Ku mojemu zdziwieniu, oba zachowały się dokładnie tak samo.

[heby]

On 29/01/2020 22:48, M.M. wrote:
>> 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ą?
> Nie wiem co się stanie. Prosiłeś o przykład, więc podałem.

Ten przykład nie tłumaczy problemów w C++ tylko w białku.

> Wszystko ma
> swoje wady i zalety, nawet C++ ma wady względem C

W sensie że jest bardziej restrykcyjny? Słyszałme kiedyś że to wada. Do
dzisiaj nie wiem dlaczego.

>, a jako nadzbiór nie
> powinien mieć wad. Koszt przeszkolenia jest nie do przeskoczenia.

Napisałem Ci że nic nie musisz szkolić poza "chłopaki, od dzisiaj w
każdym przerwaniu na arma na początku ma stać scoped_interrupt_disable
sid(); i h...". A jak któryś podskoczy to w łeb. Koniec szkolenia. Po
roku nie dadzą sobie tego siła odebrać.

> nastąpił rozwój technologii wytwarzania oprogramowania, ale po pierwsze nie
> wierzę że ten rozwój nie wpadał i nie wpada w ślepe uliczki

Kiedyś ludzie uważali BCPL za spełenienie marzeń. Sam się kompiluje,
można zrobić bootstrap na dziwnym systemie, architektura wręcz zdjęta z
tablicy uczelni, *uproszczona* składnia.

I wiesz co, trafiłem kiedyś przez zupełny przypadek na kolesia który nie
dość że pisał jeszcze koło 2000 roku w tym cudzie to jeszcze przez
nastepne 10 lat miał do niego straszny sentyment.

Widzisz, to co piszesz to białko.

Mam takie a takie doświadczenia, widziałem to i tamto, wnioskuje z tego
to i owo.

A na koniec okazuje się że programy w C++ nie dość że są czytelniejsze
od tych w C, to często są szybsze, łatwiejsze w analizie i refaktoringu.

Tylko że białko. Białko wie lepiej, szczególnie jak się na czymś nie zna.

No więc dowiedziałem się że C to gówno. BCPL był lepszy.

Białko ...

>, a po drugie,
> jest takie prawo w ekonomii którego nazwy już nie pamiętam, ale mówi ono o
> tym, że od pewnego momentu trzeba niewspółmiernie dużo pracy włożyć w
> udoskonalanie, aby uzyskać minimalnie lepsze efekty. Jak myślisz, ile pracy
> trzeba włożyć, żeby przyspieszyć trabanta rozpędzający, a ile, aby
> przyspieszyć najszybszy samochód na świecie i tym samym pobić rekord prędkości?

To teraz z tej analogi zrób casta na konkret.

To jaki język jest tym najszybszy na świecie?

Rust chyba obecnie jest na karuzeli terndów?

I co to ma w ogóle do dyskusji o tym że zmiana z gcc na g++ dodaje od
razu za darmo masę możliwosci które w C wymagają pisania kwadratowych kół?

>> Czyli mówisz o czymś innym niż ja. Spieraj się więc z kimś innym.
> Spokojnie, ja jeszcze nie jestem pewny o co się spieramy :)

Podobno o wyższość C++ nad C i odwrotnie.

Tylko że ja się o to nie spieram. Ja tylko protestuje przeciwko
bredzeniu o tym że zmiana z gcc na g++ jest niemozliwa, bezsensowna i
korutyny nie muszą mieć stosu a programiści muszą się szkolić z używania
prymitywnego RAII.

> Napisałem o tym z jakim sposobami używania określenia 'programowanie w C++'

Wieć programowanie w C++ to programowanie z dowolnym ficzerem dostępnym
w g++ a niedostepnym w gcc. Na przykłd z użyciem RAII, które to jest
swoją drogą krytycznie potrzebne w embedded i jednoczesnie skandalicznie
olewane przez embedded. Bo kwadratowe koła łatwiej się produkuje niż
kupuje okrągłe.

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

Bo obiektowośc wymaga *OBIEKTÓW* a nie klas.

>> 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.
> Chyba nadal nie rozumiem. A jakie wnioski z tego płyną?

Że traits< int >::max to nie jest programowanie obiektowe, natomiast to
jest programowanie w C++.

I tego faktu nie zmienia to że gdzieś w nagłówku jest [...] class traits
[...].

"class" mogło by się nazywać "type" i być może tą prostą sztuczką ludzie
przestali by bredzić że używanie klas w C++ to pisanie obiektowe.

>> 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*.
> A ja zapewne mam niejeden taki błąd w szablonach.

Nie, znalezienie bładu w szablonach który ujawnia się w runtime jest
naprawdę wyższą szkoła jazdy. Zrobienie błedu w void* który ujawnia się
w runtime to trywializm.

Szablony powodują że błedy w runtime stają się sporadyczne. Przenoszone
są na kompilacje.

Wiadomo, nie każdy potrafi czytać komunikaty błędów. Ale naprawdę od
kilkudziesiąciu lat jest coraz lepiej z jakością błedów. Proponuje
zobaczyć co wyświetla clang w przypadku błedów kompilacji. Jest bardzo,
bardzo dobrze.

>> traits< int >::max
>> to jakaś okropna składnia? Nie czerpiesz aby przypadkiem wiedzy o
>> szablonach z jakiś grup anonimowych pisaczy w c?
> Racja, takie proste przypadki są bardzo przejrzyste.

I w tym momencie zamieniasz gcc na g++. Znalazłeś jeden powód aby użyć
C++ to go używasz, jest za darmo.

> Miałem na myśli sytuacje
> gdy jeden szablon jest parametryzowany kilkoma innymi szablonami

Poniżej promila z promila zastosowań szablonów wymaga takich wygibasów.

Dam przykład: boost::spirit.

To jest bardzo skomplikowana bibliteka na bardzo pokręcoanych szblonach.

Ale dla user końcowego jest wręcz bajecznie prosta.

Te szablony w szablonach to taka Baba Jaga dla niegrzecznych
programistów C. Straszy się nią i jak widać skutecznie.

> takich sytuacjach mocno tęsknię za minimalistycznym C++ albo za Javą

Prawie cały boost to ukrycie skomplikowanych szablonów za bajecznie
prostymi interfejsami.

Pewnie, możesz zobaczyć boost::mpl czy fusion i pokazać mi przykłady
gdzie jest cieżko.

Ale oni naprawdę się napracowali aby to całe mpl było *bajecznie* proste
po stronie usera mimo komplikacji w środku.

Najwyczajniej, powtarzasz mity. C++ moze byc skomplikowany. Ale boost
pokazał że ta komplikacja nie musi przeciekać do usera.

> pozbawionego błędów. Tak się mówi że szablony stanowią antidotum na błędy, bo
> porównuje się je zwykle do najbardziej błędogennych konstrukcji języka, jak
> wlaśnie do makr, albo do rzutowania na void*.

Stanowią warstwę chroniącą przed pewną klasą problemów. Akurat tych
upierdliwych, bo w runtime.

Stanowią jeszcze wiell innych rzeczy, ale void* nie jest alternatywą dla
szablnów. Za void* nie ma żadnych sensownych argumentów.

>> Całe szczęscie wielokrotne dziedzidzenie szablonów występuje głównie w
>> bajkach i ksiązeczkach dla niegrzecznych programistów c.
> Wielokrotnie w sensie że jedna klasa (szablon) dziedziczy z bezpośrednio z
> kilku to owszem rzadko spotykana konstrukcja i niekoniecznie zalecana.

Myśle że 90% konstrukcji z boosta jest trywialna.

> Ale pośrednie wielokrotnie dziedziczenie, typu X dziedziczy z Y, Y z Z, a Z
> może z kolejnych - to sytuacja częsta.

Prawie nie spotykana w kodzie usera. Używa się jej w booscie czy stl,
ale mechanizmy widoczne jako API są strywialziowane.

> Gdy każde jeszcze ma jakieś parametry i
> typy - to naprawdę zazwyczaj dostawałem oczopląsu gdy analizowałem swój własny
> kod po krótkim czasie. Myślę że każdy programista uznałby za łatwiejszy w
> analizie kod np. Javy.

Więc masz kiepskie doświadczenia wynikające z kiespkiego doboru przykładów.

>> Robie to codziennie od kilkudziesięciu lat i cieżko mi się zgodzić.
> Może zwykle używasz szablonów po bożemu, a nie do optymalizacji kodu?

Używam C++. W tym szablonów. Szablony są od dziesiątek lat coraz lepiej
wspierane przez kompialtory (komunikaty błedów) i debuggery (pokazywanie
zawartości). Nijak nie wiem czemu foo<int> miało by być bardzie
skomplikowane do debugu. Jedyna przeszkoda to czasem dłuższe nazwy
typów. Tylko że tam się zagląda raz na rok.

Znowu deminizujesz. Debug kodu z szblonami wyglada tsak samo jak w C. No
może przesadzam: w C używając void* jesteś w d... od razu.

> nie mam z nimi problemów. Ale gdy np. cały algorytm genetyczny parametryzuję
> kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
> edytor nie wie jakie metody będą miał parametry.

Masz zły edytor.

> To wszystko prawda, choć z review to zależy gdzie :-) Nie chciałem
> absolutnie powiedzieć, że macie olać szablony i wrócić do void*.
> Chciałem powiedzieć, że jeśli sobie radzono bez szablonów i system
> operacyjny z GUI działał na 16MB RAM i pentium I 160MHz - to nie
> ulegajmy złudzeniu, że te szablony aż tak niesłychanie dużo wnoszą.

Znowu to samo.

Mam młotek, ale lepiej wbijać gwoździe lutownicą.

Mam szablony, ale przecież void* to tylko kilka wad z którymi da sie żyć.

Ja rozumiem jeszcze jak by za używanie szblonów trzeba było płacić.

Ale są za friko.

To PO CO ich nie uzywać?

> nie traktować szablonów jako czegoś dzięki czemu technologia wytwarzania
> oprogramowania przyspieszyła o kiladziesiąt procent, bo bez szablonów była
> już całkiem szybkim samochodem, który trudo przyspieszać w nieskończoność.

Szablony rozwiazują dobrze kreśloną klasę problemów z jakością kodu.

W C nie ma nic co mogło by to zastapić poza modlitwą.

>> Jesteś nastepnym developerem w tej dyskusji z Atari 65XE jako ciągłą
>> integracją?
> Nie, po prostu czasami mam w kodzie nasrana pełno szablonów, jeden szablon
> jest parametryzowany innymi, te inne też są parametryzowane jeszcze innymi, a
> niektóre są w kilku wersjach. Jeśli zmieniam warunki kompilacji warunkowej to
> muszę czekać 30 sekund na pełną rekompilację

Przyznam że "pełna rekompilacja" to zjawisko niepotykane przy prawidłowo
opisanym projekcie.

Jesteś pewien że masz wszystko dobrze że masz potrzebę pełnej rekompilacji?

>> 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?
> Ja przed chwilą dodałem do kompilacji -DOPCJA_X i czekałem na pełną
> kompilację z 30 sekund na dwóch rdzeniach. Jak jeszcze jest pomiędzy
> kompilacją -fprofile-generate i -fprofile-use to czekam 2 minuty aby
> zrobić 30 sekundowy test.

Czyli to nie jest noramlna praca w programowanie. To wyjątek, kiedy
robisz redefinicję.

Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny że
nie powinien być uważany za reprezentacyjny.

>>> Kolejna wada, trzeba udostępnić kod źródłowy gdy się
>>> udostępnia bibliotekę napisaną w postaci szablonów.
>> Brednia.
> To chętnie się dowiem dlaczego, myślałem że szablony to nagłówki niezbędne
> do wygenerowania konkretnej wersji kodu, jak to udostępnić w wersji
> binarnej bez źródeł?

usenet to za mało aby to opisać bo zależy od sytuacji.

Kod nie musi akceptować *dowonych* szablonów na przykład. I biblioteka
udostępnia impelemntcje dla tych kilku przypadków.

Mniej wiecej to to samo co biblioteka w C. Masz funckje przyjmującą inty
i floaty. To samo w C++, możesz podać szablon z intem i floatem.

To jeden z przykładów że *NIE* musisz *zawsze* udostępniać kodu
szablonowego.

>>> Następna wada, kompilatory
>>> czasami wskazują błąd daleko od jego wystąpienia.
>> Brednia w 99% wypadków.
> U mnie w około 30% przypadków jest to prawda.

Użyj clanga.

>>> Podsumowując, kiedyś szablonów używano rzadko albo w ogóle nie używano
>> Podobnie jak z papierem toaletowym.
> Tylko że papier toaletowy nie ma nic wspólnego z programowaniem, a (nie)używanie
> szablonów ma sporo.

Z faktu że ktoś kiedyś robił kupę bez papieru nie wynika że papier jest
zbędny obecnie.

Najzwyczajniej kiedyś go nie było.

Podobnie jak kiedyś nie było C++.

>> 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?
> Może czary, a może to (w jakimś stopniu) dzięki void* ?

Nie, C++ z szablonami. SaSC miał translator z C++ na generowany C.

Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z
wyborem języka C czy C++. Ma związek jedynie z kiepskimi programistami,
przyrostem danych i rozbudową OSów.

>> A po chwili się budzisz i okazuje się że ten sam program kompilowalny w
>> C i C++ generuje dokładnie taki sam kod asemblerowy.
> Przecież to jest oczywiste

Nie jest. Dla znacznej częsci wyznawców C, bazujących na opiniach z
facebooka świat wygląda tak że "C++ dużo zajmuje". Ta taka kolejna
teoria spiskowa obok antyszczepionkowców i niejedzących.

>, że każda konkretyzacja szablonu oznacza nie
> tylko różny kod, ale nowy dodatkowy kod.

Nie. Tak. Zależy.

[heby]

On 29/01/2020 23:05, Maciek Godek wrote:
>> Się stan może pomieszać między korutynami.
> Pokaż przykład.

static int a = 1;
a = 2;

Ku naszemu zaskoczeniu a będzie równe 2.

>> Dwie identyczne korutyny przeplatające się w jednym flow będa się zakłócać.
> Podaj przykład.

Ten powyżje powinien wystarczyć.

>> Dwie identyczne korutyny nie przeplatajace się, ale będące w różnych
>> wątkach będa się zakłucać.
> Semantyka korutyn w różnych wątkach nie jest nawet dobrze określona.

Jest określona dokłądnie tak samo jak zwykłych funkcji. Pod warunkeim że
to korutyny a nie jump oriented programming.

> Nie wiadomo, jak się powinno zachowywać.

Dokładnie wiadomo. Tak samo jak funkcje/procedury.

>>> Korutyna nie jest "pure function".
>> Nie ma przeszkód aby była.
> Jest zasadnicza. Korutyna ma swój stan wewnętrzny, który z definicji jest mutowalny.

Może sobie mieć. Istotne jest że stan ten nie przecieka nigdzie poza nią.

Tak samo pure funkcja może mieć sobie w środku mutowalne "int a".

I sobie mutuje.

I nie przecieka poza tą funkcję.

Własnie odkryłeś że funkcje pure mogą mieć mutowalne, prywatne zmienne w
środku i dalej być pure.

> A czysta funkcja robi tylko jedno: odwzorowuje wejście w wyjście. Zawsze dla tego samego wejścia ma dać to samo wyjście. Nie ma stanu wewnętrznego.

Ależ ma. Na ten przykład :

foo() {
int a = 1;
a = 2
return a;
}

Jeśli zatrzymasz ja w połowie to ma stan wewnętrzny. Ale on nie jest
widoczny poza tą funkcją, nie jest dostępny również w korutynie poza nią.

Bycie pure to nie jest nie posiadanie kompletnie żadnego stanu. To jest
nie ingerowanie w stan poza tą funkcją. W C/C++ do tego używa się
zazwyczaj stosu.

> I to jest dość kolosalna przeszkoda.
>>> Czyste funkcje w ogóle nie mają czegoś takiego, jak "przebieg sterowania".

To zabawne, bo moje korutyny też nie mają. Robią yield() i z ich puktu
widzenia nic się nie stało, jadą dalej. yield() to takie puste wywołanie
która nic ciekawego nie robi z ich puktu widzenia.

>> No i wychodzi na to że nie czaisz bazy. Moja *funkcja* jest pure. Twoja
>> nie. Obie są korutynami.
> Korutyna to nie jest funkcja. Tutaj masz definicję, proszę:
> https://pl.wikipedia.org/wiki/Funkcja

Korutyna zachowuje się jak funkcja z wieloma punktami wyjścia i
hermetycznym stanem pomiędzy.

Natomaist jeśli chcesz sprowadzić dyskusję do poziomu upierdlowego
profesora to trudno. Sedno tkwi nawet nie w tym czy korutyna to funkcja
czy nie. Sedno jest w tym że masz gównianą impelemntację na którą nawet
w głupiej wikipedii wylali wiado pomyj bo tylko tyle można o niej
powiedzieć.

>> Och, puśc tą samą korutynę 2x w jednym flow, na przemian.
> Nie wiem o czym mówisz. Napisz kawałek kodu, to będę wiedział.
> Problem jest taki, że określenie "ta sama korutyna puszczona 2x w jednym flow" nie jest jednoznaczna, bo nie wiem, co masz na myśli mówiąc "ta sama korutyna". Kawałek kodu wszystko wyjaśni.

Napisz w swoim kodzie flow w którym ta sama korutyna pracuje na przemian
na dwóch róznych danych wejściowych.

I odpal ją naprzemiennie.

I wiesz co, postanowiłem że kodu nie napiszę. To poniżej godności żeby
udowaniać komuś rzeczy oczywiste.

[heby]

On 29/01/2020 23:22, Maciek Godek wrote:
> Ku mojemu zdziwieniu, oba zachowały się dokładnie tak samo.

Więc aby zachęcić Cię do dalszych eksperymentów pozwój że każda z tych
grup, czyli przysta i nieparzysta, dostanie inny zestaw danych
wejściowych i niech na nich popracuje.

Powiedzmy niech jedna liczy fibonacciego od 1 a druga, nietypowo, od 1000.

I naprzemiennie, a co. W końcu to korutyny.

[Maciek Godek]

W dniu czwartek, 30 stycznia 2020 00:01:59 UTC+1 użytkownik heby napisał:

> >>> Korutyna nie jest "pure function".
> >> Nie ma przeszkód aby była.
> > Jest zasadnicza. Korutyna ma swój stan wewnętrzny, który z definicji jest mutowalny.
>
> Może sobie mieć. Istotne jest że stan ten nie przecieka nigdzie poza nią.

W korutynach właśnie przecieka.

Jeżeli mam:

int c() {
while(1) {
yield(1);
yield(2);
}
}

to jaka będzie wartość wyrażenia c()?

> Tak samo
pure funkcja może mieć sobie w środku mutowalne "int a".
>
> I sobie mutuje.
>
> I nie przecieka poza tą funkcję.
>
> Własnie odkryłeś że funkcje pure mogą mieć mutowalne, prywatne zmienne w
> środku i dalej być pure.

Mylisz "funkcje pure" z hermetyzacją.

> > A czysta funkcja robi tylko jedno: odwzorowuje wejście w wyjście. Zawsze dla tego samego wejścia ma dać to samo wyjście. Nie ma stanu wewnętrznego.
>
> Ależ ma. Na ten przykład :
>
> foo() {
> int a = 1;
> a = 2
> return a;
> }
>
> Jeśli zatrzymasz ja w połowie to ma stan wewnętrzny. Ale on nie jest
> widoczny poza tą funkcją, nie jest dostępny również w korutynie poza nią.

Funkcji nie da "się zatrzymać", bo ona "się nie wykonuje".
Ona odwzorowuje wejście w wyjście,

> Bycie pure to nie jest nie posiadanie kompletnie żadnego stanu. To jest
> nie ingerowanie w stan poza tą funkcją. W C/C++ do tego używa się
> zazwyczaj stosu.

Może lepiej idź już spać.

> > I to jest dość kolosalna przeszkoda.
> >>> Czyste funkcje w ogóle nie mają czegoś takiego, jak "przebieg sterowania".
>
> To zabawne, bo moje korutyny też nie mają. Robią yield() i z ich puktu
> widzenia nic się nie stało, jadą dalej.

Jeżeli "jadą", to mają przebieg sterowania.
Przebieg sterowania to jest właśnie "jechanie".
I ono jest czymś istotnym dla korutyny.

Tutaj masz, proszę, poczytaj sobie:
https://www.quora.com/What-is-functional-programming/answer/Panicz-Godek

> Korutyna zachowuje się jak funkcja z wieloma punktami wyjścia i
> hermetycznym stanem pomiędzy.

Funkcja nie ma czegoś takiego jak "punkt wyjścia". Funkcja odwzorowuje dziedzinę w przeciwdziedzinę.

> I wiesz co, postanowiłem że kodu nie napiszę. To poniżej godności żeby
> udowaniać komuś rzeczy oczywiste.

No ja wiem. Nie zaskakuje mnie to.
Pierdolić potrafi każdy. Ilustrować swoje tezy przykładami już niekoniecznie.

Kodu nie napiszesz, ale nie dlatego, że to "poniżej godności", tylko dlatego, że to, co do tej pory mówiłeś o korutynach, nie miało sensu.

Określenie, żeby "odpalać naprzemiennie tę samą korutynę" jest całkowitą bzdurą.

Naprzemiennie możesz odpalać dwie różne rzeczy, a nie "dwie te same rzeczy", bo "dwie te same rzeczy" to jest jedna i ta sama rzecz.

[M.M.]

On Wednesday, January 29, 2020 at 11:41:53 PM UTC+1, heby wrote:
> On 29/01/2020 22:48, M.M. wrote:
> >> 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ą?
> > Nie wiem co się stanie. Prosiłeś o przykład, więc podałem.
>
> Ten przykład nie tłumaczy problemów w C++ tylko w białku.

W jakim białku?

>
> > Wszystko ma
> > swoje wady i zalety, nawet C++ ma wady względem C
>
> W sensie że jest bardziej restrykcyjny? Słyszałme kiedyś że to wada. Do
> dzisiaj nie wiem dlaczego.

Podałem przykład, ale Ty na to coś o jakimś białku.

>
> >, a jako nadzbiór nie
> > powinien mieć wad. Koszt przeszkolenia jest nie do przeskoczenia.
>
> Napisałem Ci że nic nie musisz szkolić poza "chłopaki, od dzisiaj w
> każdym przerwaniu na arma na początku ma stać scoped_interrupt_disable
> sid(); i h...". A jak któryś podskoczy to w łeb. Koniec szkolenia. Po
> roku nie dadzą sobie tego siła odebrać.

To faktycznie nie rozmawiamy o C++, tylko o czymś w rodzaju co napisałeś
"wystarczy jeden ficzer z C++". Co dobrego z takiej rozmowy wyniknie?

>
> > nastąpił rozwój technologii wytwarzania oprogramowania, ale po pierwsze nie
> > wierzę że ten rozwój nie wpadał i nie wpada w ślepe uliczki
>
> Kiedyś ludzie uważali BCPL za spełenienie marzeń. Sam się kompiluje,
> można zrobić bootstrap na dziwnym systemie, architektura wręcz zdjęta z
> tablicy uczelni, *uproszczona* składnia.

Niestety nie miałem przyjemności z BCPL.

> I wiesz co, trafiłem kiedyś przez zupełny przypadek na kolesia który nie
> dość że pisał jeszcze koło 2000 roku w tym cudzie to jeszcze przez
> nastepne 10 lat miał do niego straszny sentyment.
>
> Widzisz, to co piszesz to białko.

Nie wiem jak używasz określenia białko.

> Mam takie a takie doświadczenia, widziałem to i tamto, wnioskuje z tego
> to i owo.

Nie wiem w czym problem.

> A na koniec okazuje się że programy w C++ nie dość że są czytelniejsze
> od tych w C, to często są szybsze, łatwiejsze w analizie i refaktoringu.

Sekundę. Programy w C++ mogą być czytelniejsze od tych w C i to mogą być
znacznie czytelniejsze, tak samo jak mogą być łatwiejsze w analizie i
refaktoringu. Ale jeśli są mocno zoptymalizowane pod kątem szybkości
działania, to na pewno nie są ani czytelne, ani łatwe w analizie, a już w
ogóle są fatalne w rozbudowie i refaktoringu.

> Tylko że białko. Białko wie lepiej, szczególnie jak się na czymś nie zna.

Pierdolisz.

> No więc dowiedziałem się że C to gówno. BCPL był lepszy.
>
> Białko ...
>
> >, a po drugie,
> > jest takie prawo w ekonomii którego nazwy już nie pamiętam, ale mówi ono o
> > tym, że od pewnego momentu trzeba niewspółmiernie dużo pracy włożyć w
> > udoskonalanie, aby uzyskać minimalnie lepsze efekty. Jak myślisz, ile pracy
> > trzeba włożyć, żeby przyspieszyć trabanta rozpędzający, a ile, aby
> > przyspieszyć najszybszy samochód na świecie i tym samym pobić rekord prędkości?
>
> To teraz z tej analogi zrób casta na konkret.
>
> To jaki język jest tym najszybszy na świecie?
>
> Rust chyba obecnie jest na karuzeli terndów?
>
> I co to ma w ogóle do dyskusji o tym że zmiana z gcc na g++ dodaje od
> razu za darmo masę możliwosci które w C wymagają pisania kwadratowych kół?

Już pisałem jaka jest analogia i nie przeczyłem możliwościom C++. Nie można
jednej technologii ulepszać bez końca, a już na pewno nie można stałym
nakładem kosztów/pracy ulepszać o stałą wartość, efekty stają się coraz
mniejsze, a języki programowania są ulepszane od dawna. Dopóki nie
będzie jakiegoś przełomu w technologiach wytwarzania oprogramowania, to
nie należy się już spodziewać, że taki czy inny zestaw nowych ficzerów
znacząco udoskonali technologię. W moim przypadku dobre biblioteki najbardziej
przyspieszają tworzenie oprogramowania. Bajeranckie cechy języka... to
nawet spowalniają, bo programista myśli czego lepiej użyć. W Javie się
szybciej programowało, ale efekt w C++ jest lepszy.

>
> >> Czyli mówisz o czymś innym niż ja. Spieraj się więc z kimś innym.
> > Spokojnie, ja jeszcze nie jestem pewny o co się spieramy :)
>
> Podobno o wyższość C++ nad C i odwrotnie.

Bez kontekstu nie wiem jak się o to spierać. Templates można porównywać do
błędogennych makrodefinicji i void*. Templaty można robić po to, aby pomóc
kompilatorowi w wykrywaniu błędów na etapie kompilacji. Ale też templates
można porównywać do ładnego kodu z metodami wirtualnymi i templaty można
pisać w celu agresywnej optymalizacji kodu pod kątem czasu wykonania. Niby
to samo, a za każdym razem zupełnie inna sytuacja. A co dobrego z tej rozmowy,
to zupełnie nie wiem... Ktoś kto nie wie że templaty mogą posłużyć do
optymalizacji kodu, ale taki kod tylko w banalnych przypadkach jest
czytelny - to się dowie. Ja na razie nic się nie nauczyłem.

> Tylko że ja się o to nie spieram. Ja tylko protestuje przeciwko
> bredzeniu o tym że zmiana z gcc na g++ jest niemozliwa, bezsensowna
> i
> korutyny nie muszą mieć stosu a programiści muszą się szkolić z używania
> prymitywnego RAII.

Nie wiem, moje korutyny mają stos i są odporne na wątki - chyba że to co
ja mam jeszcze nie nazywa się korutyną.

> > Napisałem o tym z jakim sposobami używania określenia 'programowanie w C++'
>
> Wieć programowanie w C++ to programowanie z dowolnym ficzerem dostępnym
> w g++ a niedostepnym w gcc. Na przykłd z użyciem RAII, które to jest
> swoją drogą krytycznie potrzebne w embedded i jednoczesnie skandalicznie
> olewane przez embedded. Bo kwadratowe koła łatwiej się produkuje niż
> kupuje okrągłe.

A wyżej napisałeś że spieramy się o wyższość języka C nad C++ lub odwrotnie.
Język to nie jeden ficzer, a w praktyce nawet spór o cały język jest jałowy, bo
co komu nawet z najlepszego języka jak nie ma do niego narzędzi?

> >>>> 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.
> > Dlaczego?
>
> Bo obiektowośc wymaga *OBIEKTÓW* a nie klas.

Nie wiem, a co z tego rozgraniczenia dobrego dla Ciebie i dla mnie?

>
> >> 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.
> > Chyba nadal nie rozumiem. A jakie wnioski z tego płyną?
>
> Że traits< int >::max to nie jest programowanie obiektowe, natomiast to
> jest programowanie w C++.

Też nie wiem co z tego dobrego dla mnie i dla Ciebie.

>
> I tego faktu nie zmienia to że gdzieś w nagłówku jest [...] class traits
> [...].
>
> "class" mogło by się nazywać "type" i być może tą prostą sztuczką ludzie
> przestali by bredzić że używanie klas w C++ to pisanie obiektowe.
>
> >> 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*.
> > A ja zapewne mam niejeden taki błąd w szablonach.
>
> Nie, znalezienie bładu w szablonach który ujawnia się w runtime jest
> naprawdę wyższą szkoła jazdy. Zrobienie błedu w void* który ujawnia się
> w runtime to trywializm.

Programowałem i z użyciem szablonów i z void*. Tyle że szablonów zwykle używam
do poprawy wydajności. Swoją osobistą statystykę mam zdecydowanie na korzyść
void* - w sensie że mniej błędów popełniałem. Ale powtarzam, ja czasami używam
szablonów zupełnie inaczej niż 90% programistów.

>
> Szablony powodują że błedy w runtime stają się sporadyczne. Przenoszone
> są na kompilacje.
>
> Wiadomo, nie każdy potrafi czytać komunikaty błędów. Ale naprawdę od
> kilkudziesiąciu lat jest coraz lepiej z jakością błedów. Proponuje
> zobaczyć co wyświetla clang w przypadku błedów kompilacji. Jest bardzo,
> bardzo dobrze.
>
> >> traits< int >::max
> >> to jakaś okropna składnia? Nie czerpiesz aby przypadkiem wiedzy o
> >> szablonach z jakiś grup anonimowych pisaczy w c?
> > Racja, takie proste przypadki są bardzo przejrzyste.
>
> I w tym momencie zamieniasz gcc na g++. Znalazłeś jeden powód aby użyć
> C++ to go używasz, jest za darmo.

Nie rozumiem w jakim momencie, gcc szablonów nie kompiluje, a rozmawialiśmy w
tym akapicie o szablonach.

> > Miałem na myśli sytuacje
> > gdy jeden szablon jest parametryzowany kilkoma innymi szablonami
>
> Poniżej promila z promila zastosowań szablonów wymaga takich wygibasów.

Jeśli podajemy jawnie wydajność jako zaletę templates, to zwykle używa
się tego typu wygibasów.

>
> Dam przykład: boost::spirit.
>
> To jest bardzo skomplikowana bibliteka na bardzo pokręcoanych szblonach.
>
> Ale dla user końcowego jest wręcz bajecznie prosta.

Tak, o to właśnie chodzi. Moje mikro-biblioteki też są w jakimś stopniu proste,
ale są wierzchołkiem góry lodowej. Niewidoczna część pod wodą stanowi
pierdylion eksperymentów z szablonami, makrami, opcjami kompilatora, z
oczekiwaniem na koniec pracy kompilatora, z uganianiem się za syntax error w
innym pliku niż pokazał kompilator....

> Te szablony w szablonach to taka Baba Jaga dla niegrzecznych
> programistów C. Straszy się nią i jak widać skutecznie.

Nie wiem do czego nawiązujesz.

> > takich sytuacjach mocno tęsknię za minimalistycznym C++ albo za Javą
>
> Prawie cały boost to ukrycie skomplikowanych szablonów za bajecznie
> prostymi interfejsami.

Co nie znaczy że proces jego powstawiania (czytaj: technologia tworzenia
wysokiej jakości oprogramowania z użyciem szablonów) był tak samo
majestatyczny jak efekt końcowy dla ostatecznego użytkownika. Nawet to
są różne spojrzenia na to samo magiczne słowo 'template'. Raz tworzymy
oprogramowanie korzystając szablonów, drugi raz przygotowujemy szablony do
reużycia.

> Pewnie, możesz zobaczyć boost::mpl czy fusion i pokazać mi przykłady
> gdzie jest cieżko.
>
> Ale oni naprawdę się napracowali aby to całe mpl było *bajecznie* proste
> po stronie usera mimo komplikacji w środku.

I widzisz, może zgadzamy się co do wszystkiego. Dotarliśmy w końcu do mojego
statystycznego punktu widzenia :D Też się kilka razy w życiu ciężko
napracowałem, żeby reużycie było bajecznie proste i jeszcze dawało wydajny
program. Z punktu widzenia osoby która się napracowała, praca z szablonami
nie jest taka bajeczna, jak z punktu widzenia osoby używające ich.


> Najwyczajniej, powtarzasz mity.

Nie powtarzam, nie rozumiemy się po prostu. Niby i Ty, i ja piszemy o
szablonach. Ale na szablony można patrzyć z kilku perspektyw, do mojej
chyba przed chwilą dotarliśmy.

> C++ moze byc skomplikowany.

Zależy jak porównywać, np. względem Javy jest koszmarnie skomplikowany.

> Ale boost pokazał że ta komplikacja nie musi przeciekać do usera.

A no właśnie, to inne porównanie i zgadzam się z Tobą że nie musi. A jakie
miłe jest programowanie z użyciem QT, naprawdę bardzo podobnie do Javy.

> > pozbawionego błędów. Tak się mówi że szablony stanowią antidotum na błędy, bo
> > porównuje się je zwykle do najbardziej błędogennych konstrukcji języka, jak
> > wlaśnie do makr, albo do rzutowania na void*.
>
> Stanowią warstwę chroniącą przed pewną klasą problemów. Akurat tych
> upierdliwych, bo w runtime.

Może tak naprawdę spieramy się o to, że Ty uważasz iż szablony bardzo
usprawniają technologię oprogramowania, a ja że usprawniają ją w mniejszym
stopniu? Nie zgadzam się też, że trudno popełnić błąd w runtime programując z
wykorzystaniem szablonów.

> Stanowią jeszcze wiell innych rzeczy, ale void* nie jest alternatywą dla
> szablnów. Za void* nie ma żadnych sensownych argumentów.

Nie wiem, trudno mi się wypowiedzieć, bo od wielu lat void* zdarza mi
się użyć może raz na rok. Może z 15 lat temu używałem regularnie, też
dawałem radę. I nie chcę powiedzieć po prostu że kiedyś bez papieru
dawali radę, ale że jak dawali radę, to ten papier toaletowy nie jest aż
takim panaceum, tylko jakimś kolejnym małym ulepszeniem.

> >> Całe szczęscie wielokrotne dziedzidzenie szablonów występuje głównie w
> >> bajkach i ksiązeczkach dla niegrzecznych programistów c.
> > Wielokrotnie w sensie że jedna klasa (szablon) dziedziczy z bezpośrednio z
> > kilku to owszem rzadko spotykana konstrukcja i niekoniecznie zalecana.
>
> Myśle że 90% konstrukcji z boosta jest trywialna.

Pisałeś też że się napracowali przy booście, czy miałeś na myśli że
napracowali się przy pozostałych 10ciu procentach?

> > Ale pośrednie wielokrotnie dziedziczenie, typu X dziedziczy z Y, Y z Z, a Z
> > może z kolejnych - to sytuacja częsta.
>
> Prawie nie spotykana w kodzie usera. Używa się jej w booscie czy stl,
> ale mechanizmy widoczne jako API są strywialziowane.

Ok, to już opisałem wyżej, nie rozumieliśmy się, bo pisałem z punktu
widzenia kogoś kto takich konstrukcji używa.

> > Gdy każde jeszcze ma jakieś parametry i
> > typy - to naprawdę zazwyczaj dostawałem oczopląsu gdy analizowałem swój własny
> > kod po krótkim czasie. Myślę że każdy programista uznałby za łatwiejszy w
> > analizie kod np. Javy.
>
> Więc masz kiepskie doświadczenia wynikające z kiespkiego doboru przykładów.

Czysta złośliwość czy kryje sie za tym coś konstruktywnego? Co to są
kiepskie doświadczenia?

> >> Robie to codziennie od kilkudziesięciu lat i cieżko mi się zgodzić.
> > Może zwykle używasz szablonów po bożemu, a nie do optymalizacji kodu?
>
> Używam C++. W tym szablonów. Szablony są od dziesiątek lat coraz lepiej
> wspierane przez kompialtory (komunikaty błedów) i debuggery (pokazywanie
> zawartości). Nijak nie wiem czemu foo<int> miało by być bardzie
> skomplikowane do debugu. Jedyna przeszkoda to czasem dłuższe nazwy
> typów. Tylko że tam się zagląda raz na rok.

Na razie rozumiem, że dobre doświadczenia są wtedy gdy się tam zagląda
raz na rok, a gdy ktoś akurat nad tym pracuje, to nabiera kiepskich
doświadczeń.

> Znowu deminizujesz. Debug kodu z szblonami wyglada tsak samo jak w C. No
> może przesadzam: w C używając void* jesteś w d... od razu.

Miałem na myśl nie nie tylko śledzenie linia po linii wykonania kodu w
programie do debugowania, tyko generalnie usuwanie błędów. Gdy oglądam
kod z 'wirtualnym typem' który dopiero w trakcie kompilacji będzie na
kilka sposobów konkretyzowany, to wcale nie jestem bardziej pewny jego
bezbłędności, niż gdy patrzę na kod zwykłej procedury. W zasadzie to
chyba mam odwrotnie, co do zwykłych procedur szybciej nabieram przekonania
że są poprawne. A swoją drogą w programach do debugowania też było
sporo błędów i gorzej sobie radziły na szablonach.

> > nie mam z nimi problemów. Ale gdy np. cały algorytm genetyczny parametryzuję
> > kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
> > edytor nie wie jakie metody będą miał parametry.
>
> Masz zły edytor.

Może, a jaki Ty masz?

> > To wszystko prawda, choć z review to zależy gdzie :-) Nie chciałem
> > absolutnie powiedzieć, że macie olać szablony i wrócić do void*.
> > Chciałem powiedzieć, że jeśli sobie radzono bez szablonów i system
> > operacyjny z GUI działał na 16MB RAM i pentium I 160MHz - to nie
> > ulegajmy złudzeniu, że te szablony aż tak niesłychanie dużo wnoszą.
>
> Znowu to samo.
>
> Mam młotek, ale lepiej wbijać gwoździe lutownicą.
> Mam szablony, ale przecież void* to tylko kilka wad z którymi da sie żyć.

Nie, nie to chciałem powiedzieć. Mam szablony, używam szablonów, ale jestem
świadomy że z void* też działało, więc te szablony to nie żadne panaceum, ale
jakieś kolejne ulepszenie.

> Ja rozumiem jeszcze jak by za używanie szblonów trzeba było płacić.

Bo trzeba, nic nie jest za darmo. Tą opłatą była/jest:
- konieczność szkolenia personelu,
- konieczność nabrania doświadczenia przez personel,
- wiele lat implementacji w kompilatorach,
- problemy bo kompilatory różnie to wspierały,
- targi o to jak powinny wyglądać w standardzie,
- próby łamania standardu przez niektóre firmy,
- o wydłużonym czasie kompilacji, zwiększonym rozmiarze kodu i słabym
pokazywaniu właściwej linii z syntax error - już pisałem.
- o tym jak to wygląda z punktu widzenia kogoś kto przygotowuje
wygodny szablon - też już pisałem.

>
> Ale są za friko.
>
> To PO CO ich nie uzywać?

To nie do mnie pytanie, ja mówię żeby ich używać, tylko studzę emocje, bo
nie są, nie były całkiem za friko, a w przypadku płatnych bibliotek nigdy
nie będą za friko i nie są aż takim wybawieniem skoro na void* też działało.

> > nie traktować szablonów jako czegoś dzięki czemu technologia wytwarzania
> > oprogramowania przyspieszyła o kiladziesiąt procent, bo bez szablonów była
> > już całkiem szybkim samochodem, który trudo przyspieszać w nieskończoność.
>
> Szablony rozwiazują dobrze kreśloną klasę problemów z jakością kodu.

Zgoda, ale wprowadzają też inne problemy. Choć podsumowanie dziś wypada na
korzyść szablonów, to po odjęciu wad, to podsumowanie nie jest rewelacyjne.

> W C nie ma nic co mogło by to zastapić poza modlitwą.

Zewnętrzne programy narzędziowe pełny rolę generyków, sam jeden większy
generator napisałem do generowania sieci neuronowych. No i był void* i
makra ;-)

> >> Jesteś nastepnym developerem w tej dyskusji z Atari 65XE jako ciągłą
> >> integracją?
> > Nie, po prostu czasami mam w kodzie nasrana pełno szablonów, jeden szablon
> > jest parametryzowany innymi, te inne też są parametryzowane jeszcze innymi, a
> > niektóre są w kilku wersjach. Jeśli zmieniam warunki kompilacji warunkowej to
> > muszę czekać 30 sekund na pełną rekompilację
>
> Przyznam że "pełna rekompilacja" to zjawisko niepotykane przy prawidłowo
> opisanym projekcie.
>
> Jesteś pewien że masz wszystko dobrze że masz potrzebę pełnej rekompilacji?

Bym musiał napisać (i potem pilnować) specjalne pliki make, które uwzględniają
kompilację warunkową. Nie wiem co gorsze, modlić się czy nie mam błędu w
pliku make, czy czekać te 30 sekund.

>
> >> 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?
> > Ja przed chwilą dodałem do kompilacji -DOPCJA_X i czekałem na pełną
> > kompilację z 30 sekund na dwóch rdzeniach. Jak jeszcze jest pomiędzy
> > kompilacją -fprofile-generate i -fprofile-use to czekam 2 minuty aby
> > zrobić 30 sekundowy test.
>
> Czyli to nie jest noramlna praca w programowanie. To wyjątek, kiedy
> robisz redefinicję.

Dla mnie to jest norma zawsze wtedy, gdy pracuję pod wodą góry lodowej.
Poza tym owszem, to jest wyjątek.

> Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny że
> nie powinien być uważany za reprezentacyjny.

Nie wiem czy kiepski przypadek, sam przyznałeś że ludzie od boosta
się napracowali ciężko...

>
> >>> Kolejna wada, trzeba udostępnić kod źródłowy gdy się
> >>> udostępnia bibliotekę napisaną w postaci szablonów.
> >> Brednia.
> > To chętnie się dowiem dlaczego, myślałem że szablony to nagłówki niezbędne
> > do wygenerowania konkretnej wersji kodu, jak to udostępnić w wersji
> > binarnej bez źródeł?
>
> usenet to za mało aby to opisać bo zależy od sytuacji.
>
> Kod nie musi akceptować *dowonych* szablonów na przykład. I biblioteka
> udostępnia impelemntcje dla tych kilku przypadków.
>
> Mniej wiecej to to samo co biblioteka w C. Masz funckje przyjmującą inty
> i floaty. To samo w C++, możesz podać szablon z intem i floatem.
>
> To jeden z przykładów że *NIE* musisz *zawsze* udostępniać kodu
> szablonowego.

Nie rozumiem, ale ok, poszukam, poczytam, może coś jest na

>
> >>> Następna wada, kompilatory
> >>> czasami wskazują błąd daleko od jego wystąpienia.
> >> Brednia w 99% wypadków.
> > U mnie w około 30% przypadków jest to prawda.
>
> Użyj clanga.

Ostatnio używam g++, ale wiem że powinienem spróbować i clanga.

> >>> Podsumowując, kiedyś szablonów używano rzadko albo w ogóle nie używano
> >> Podobnie jak z papierem toaletowym.
> > Tylko że papier toaletowy nie ma nic wspólnego z programowaniem, a (nie)używanie
> > szablonów ma sporo.
>
> Z faktu że ktoś kiedyś robił kupę bez papieru nie wynika że papier jest
> zbędny obecnie.

No nie, mamy papier, żyje się trochę lepiej, ale musimy za niego zapłacić,
go produkować, oczyszczać w oczyszczalniach ścieków, musimy iść po niego
do sklepu, musimy go wypakować z paczki i powiesić koło kibla, kto wie czy
nie ma jakiś ustaw prawny o papierze (na pewno jest, bo to może rzutować na
stan zdrowia), a jak się uzależnimy od papieru i raz zapomnimy go kupić, to
chodzimy z obsraną dupą do czasu użycia starej metody. Podobnie są koszty
użycia szablonów, Ty to nazywasz kiepskim przypadkiem, a ja mam poczucie
pełnego obrazu gdy też te kiepskie przypadki wezmę pod uwagę, bo biblioteki
szablonów same nie powstają i nie zawsze są darmowe.

>
> Najzwyczajniej kiedyś go nie było.
>
> Podobnie jak kiedyś nie było C++.
>
> >> 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?
> > Może czary, a może to (w jakimś stopniu) dzięki void* ?
>
> Nie, C++ z szablonami. SaSC miał translator z C++ na generowany C.

Tak. Były generyki i w C, tylko na poziomie narzędzi a nie języka.

>
> Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z
> wyborem języka C czy C++. Ma związek jedynie z kiepskimi programistami,
> przyrostem danych i rozbudową OSów.

Też mi jest trudno się wypowiedzieć, w sumie nie biorę udziału w
programach których kod wynikowy nie mieści się na DVD. Myślę jednak
że zdublowanie kodu ma największy wpływ.

>
> >> A po chwili się budzisz i okazuje się że ten sam program kompilowalny w
> >> C i C++ generuje dokładnie taki sam kod asemblerowy.
> > Przecież to jest oczywiste
>
> Nie jest. Dla znacznej częsci wyznawców C, bazujących na opiniach z
> facebooka świat wygląda tak że "C++ dużo zajmuje". Ta taka kolejna
> teoria spiskowa obok antyszczepionkowców i niejedzących.
>
> >, że każda konkretyzacja szablonu oznacza nie
> > tylko różny kod, ale nowy dodatkowy kod.
>
> Nie. Tak. Zależy.

Ok, chyba i tak, i tak nic pożytecznego z tej rozmowy. Pewnie byśmy
musieli wyprodukować jeszcze z 10 postów żebyśmy się dobrze zrozumieli.
Jak do tego czasu nerwy by nikomu nie puściły, to może potem byłaby jakaś
nauka ;-)

Pozdrawiam

[Tomasz Kaczanowski]

W dniu 2020-01-29 o 18:24, heby pisze:

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

Dzięki swojej prostocie, łatwiej jest przygotować kompilator C niż C++
na eksperymentalną platformę. Więc jeśli nie masz gotowych narzędzi
kompilującej kod na daną platformę, to przystosowanie nawet już
istniejącego kompilatora jest po prostu prostsze, więc zajmuje mniej
czasu, a czasem może mieć to znaczenie.


--
http://kaczus.ppa.pl

[heby]

On 30/01/2020 04:40, M.M. wrote:
>> Ten przykład nie tłumaczy problemów w C++ tylko w białku.
> W jakim białku?

Problemy z C++ to głównie problemy białkowe:
a) muszę używać new bo inaczej się nie da
b) szwagra kumpla zięcia ciotka to miała taki przypadek że zainkudowała
coś i exec zrobił się bilin razy większy
c) void* jest czytelniejsze niż Foo*
d) po C++ krowy mleka nie dają
e) ten sam asembler, ale jest wolniejszy bo szwagier sprawdzał
f) "mam swoje powody"

>> W sensie że jest bardziej restrykcyjny? Słyszałme kiedyś że to wada. Do
>> dzisiaj nie wiem dlaczego.
> Podałem przykład, ale Ty na to coś o jakimś białku.

Bo wszystkie problemy jakie padły w tym wątku sa białkowe.

>> Napisałem Ci że nic nie musisz szkolić poza "chłopaki, od dzisiaj w
>> każdym przerwaniu na arma na początku ma stać scoped_interrupt_disable
>> sid(); i h...". A jak któryś podskoczy to w łeb. Koniec szkolenia. Po
>> roku nie dadzą sobie tego siła odebrać.
> To faktycznie nie rozmawiamy o C++, tylko o czymś w rodzaju co napisałeś
> "wystarczy jeden ficzer z C++". Co dobrego z takiej rozmowy wyniknie?

Być może komuś uratuje dupę jak zampomni postawić sei() przy returnie "w
przerwaniu ARMa".

Jeden mały ficzer ratujący dupę wydaje się być całkiem sensowny jak za 0zł.

Ale nie, bo "mam swoje powody".

>> Kiedyś ludzie uważali BCPL za spełenienie marzeń. Sam się kompiluje,
>> można zrobić bootstrap na dziwnym systemie, architektura wręcz zdjęta z
>> tablicy uczelni, *uproszczona* składnia.
> Niestety nie miałem przyjemności z BCPL.

Śladowe ilości można było odszukać, najbliżej, w Amidze; w okolicy
połowy lat 80. DOSa miała napisanego w BCPLu. Skutkiem ubocznym
wszystkie pointery API DOSa wymagały arytmetyki >>2 <<2. H... wie po co :D

> Nie wiem jak używasz określenia białko.

Jako decydowanie o technologii na podstawie pozaracjonalnych doświadczeń
przez ludzie składających się z białka z domieszką uprzedzeń. Jedną z
najbardziej zdumiewających rzeczy jakie zrozumiałem o porogramistach
jest to że to ludzie bardziej uprzedzeni do wszystkiego niż przeciętny
wyborca konserwatystów.

>> Mam takie a takie doświadczenia, widziałem to i tamto, wnioskuje z tego
>> to i owo.
> Nie wiem w czym problem.

W tym że podejście racjonalne polega na czymś zgoła odmiennym.

>> A na koniec okazuje się że programy w C++ nie dość że są czytelniejsze
>> od tych w C, to często są szybsze, łatwiejsze w analizie i refaktoringu.
> Sekundę. Programy w C++ mogą być czytelniejsze od tych w C i to mogą być
> znacznie czytelniejsze, tak samo jak mogą być łatwiejsze w analizie i
> refaktoringu.

Nie, one *zazwyczaj* są. Pozawalają wyrazić algorytm bez pieprzenia się
z pisaniem go w asemblerze, do którego w gruncie rzeczy sprowadza się C,
a szczególnie taki poprzetykany void*.

> Ale jeśli są mocno zoptymalizowane pod kątem szybkości
> działania, to na pewno nie są ani czytelne, ani łatwe w analizie, a już w
> ogóle są fatalne w rozbudowie i refaktoringu.

Obawiam się że w programowaniu ważniejsza jest złożoność algorytmiczna
nad hackerskie optymalizacje kodu. Tym zajmuje się kompilator.

I uwaga: wszystkie sztuczki z C++ z szablonami generują równie szybki i
równie hackerski kod co C. Tyle że łatwiej to czytać, rozumieć i
refaktorować niż sieczkę kwadratowych kół w C.

>> I co to ma w ogóle do dyskusji o tym że zmiana z gcc na g++ dodaje od
>> razu za darmo masę możliwosci które w C wymagają pisania kwadratowych kół?
> Już pisałem jaka jest analogia i nie przeczyłem możliwościom C++. Nie można
> jednej technologii ulepszać bez końca, a już na pewno nie można stałym
> nakładem kosztów/pracy ulepszać o stałą wartość, efekty stają się coraz
> mniejsze, a języki programowania są ulepszane od dawna. Dopóki nie
> będzie jakiegoś przełomu w technologiach wytwarzania oprogramowania, to
> nie należy się już spodziewać, że taki czy inny zestaw nowych ficzerów
> znacząco udoskonali technologię. W moim przypadku dobre biblioteki najbardziej
> przyspieszają tworzenie oprogramowania.

Na 99% masz do nich dostęp w C++. Nastepny pusty argument.

> Bajeranckie cechy języka... to
> nawet spowalniają, bo programista myśli czego lepiej użyć.

Odwrotnie. Programista nie myśli jak jest zbudowany std::container,
używa move i ma najszybszą z możliwych implementację. Pisanie w C++
opiera się na pewnych obietnicach: napisz co chcesz a my zrobimy to tak
dobrze jak się da, albo przynajmniej najlepiej jak potrafimy.

Bibliteki nie są doskonałe. Ale są coraz doskonalsze a lata 90 słusznie
mineły.

> Bez kontekstu nie wiem jak się o to spierać. Templates można porównywać do
> błędogennych makrodefinicji i void*.

Nijak się nie da. Templates nadają sens wskaźnikom. void* odbiera ten
sens. To tak jak byś pisał we wspomnianym BCPLu. Wszystko jest "wordem"
i sam se zgaduj co dostałeś jako argument. No wiec masa programistów C
pisze właśnie w takim BCPLu. Wszystko jest void* i tylko cicha modlitwa
pozwala upewnić się że to jest jednak Foo*.

>> Tylko że ja się o to nie spieram. Ja tylko protestuje przeciwko
>> bredzeniu o tym że zmiana z gcc na g++ jest niemozliwa, bezsensowna
>> i
>> korutyny nie muszą mieć stosu a programiści muszą się szkolić z używania
>> prymitywnego RAII.
> Nie wiem, moje korutyny mają stos i są odporne na wątki - chyba że to co
> ja mam jeszcze nie nazywa się korutyną.

Korutyna ma mieć stos. Piszą to w pierwszym zdaniu o korutynach na wiki.

Ale Maciek ma inny internet, inzynierię i wszechświat. U nie go nie
muszą. Stąd cała dyskusja, która tradycyjnie już odpłyneła w kierunku
nastepnego nudnego flame starych dziadków. Przypuszcalnie za 30 lat
będziemy się spierać w sanatoriach waląc się laskami po łbach.

>> Wieć programowanie w C++ to programowanie z dowolnym ficzerem dostępnym
>> w g++ a niedostepnym w gcc. Na przykłd z użyciem RAII, które to jest
>> swoją drogą krytycznie potrzebne w embedded i jednoczesnie skandalicznie
>> olewane przez embedded. Bo kwadratowe koła łatwiej się produkuje niż
>> kupuje okrągłe.
> A wyżej napisałeś że spieramy się o wyższość języka C nad C++ lub odwrotnie.

Bo tak wyszło. Pierowtny temat to napisanie kilku mark w celu emulacji
czegoś czego autor nie pojmuje jak ma działać.

> Język to nie jeden ficzer, a w praktyce nawet spór o cały język jest jałowy, bo
> co komu nawet z najlepszego języka jak nie ma do niego narzędzi?

Do C++ jest całkiem sporo narzędzi. Nie narzekałbym.

>>>> Użycie składni obiektowej (struct/class) nie oznacza że używa się
>>>> obiektowości.
>>> Dlaczego?
>> Bo obiektowośc wymaga *OBIEKTÓW* a nie klas.
> Nie wiem, a co z tego rozgraniczenia dobrego dla Ciebie i dla mnie?

To dośc istotne przycięcie powoduje że ludzie przestają widzieć C++ jako
"coś gdzie obowiązkowo używa się new".

>> Że traits< int >::max to nie jest programowanie obiektowe, natomiast to
>> jest programowanie w C++.
> Też nie wiem co z tego dobrego dla mnie i dla Ciebie.

Dla innych może wynikać. Na przykład mogą w swoim zdumieniu zobaczyć że
powyższa linijka nie kompiluje się do milairda megabajtów. Ona się
kompiluje do ... niczego.

Zazwyczaj programiści C właśnie tak widzą C++: dużo pisania więc
wolniej. Nie przychdozi im do głowy że to pisanie jest po to aby
kompilator sprawdzał typy a nie generował kod.

>> Nie, znalezienie bładu w szablonach który ujawnia się w runtime jest
>> naprawdę wyższą szkoła jazdy. Zrobienie błedu w void* który ujawnia się
>> w runtime to trywializm.
> Programowałem i z użyciem szablonów i z void*. Tyle że szablonów zwykle używam
> do poprawy wydajności. Swoją osobistą statystykę mam zdecydowanie na korzyść
> void* - w sensie że mniej błędów popełniałem. Ale powtarzam, ja czasami używam
> szablonów zupełnie inaczej niż 90% programistów.

Mam doświadczenia dokładnie odwrotne. W dodatku moje są zbliżone do
obserwacji ludzi zajmujacych się teorią programowania - silne typy są
bezpieczniejsze niż uniwersalne dane. U mnie liczy się jakość, nie
wygoda pisania.

>> I w tym momencie zamieniasz gcc na g++. Znalazłeś jeden powód aby użyć
>> C++ to go używasz, jest za darmo.
> Nie rozumiem w jakim momencie, gcc szablonów nie kompiluje, a rozmawialiśmy w
> tym akapicie o szablonach.

"gcc" to tylko taki koncept kompilatora C. Jak się uprzesz to oczywiście
za pomocą gcc skopilujesz plik .cpp (z pewnymi detalami, ale pal sześć).
Tu chodzi o metaforę: zamień swój kompilator z C na C++, to jest za darmo.

>>> gdy jeden szablon jest parametryzowany kilkoma innymi szablonami
>> Poniżej promila z promila zastosowań szablonów wymaga takich wygibasów.
> Jeśli podajemy jawnie wydajność jako zaletę templates, to zwykle używa
> się tego typu wygibasów.

*W* środku biblitek. U klienta? Nie, raczej nie. Tam się to kończy
std::shared_ptr< Foo > a to że w środku ktoś sprawdza trywialnosc
konstruktora wielopoziomowymi szablonami to nie jest ani istotne ani
widoczne.

>> Ale dla user końcowego jest wręcz bajecznie prosta.
> Tak, o to właśnie chodzi. Moje mikro-biblioteki też są w jakimś stopniu proste,
> ale są wierzchołkiem góry lodowej. Niewidoczna część pod wodą stanowi
> pierdylion eksperymentów z szablonami, makrami, opcjami kompilatora, z
> oczekiwaniem na koniec pracy kompilatora, z uganianiem się za syntax error w
> innym pliku niż pokazał kompilator....

Sprawdź co oferuje clang w kwesti przejrzystości błedów. gcc już od
dawna nie ma nic wspólnego z wygodą kompilowania. Da się? Da.

>> Te szablony w szablonach to taka Baba Jaga dla niegrzecznych
>> programistów C. Straszy się nią i jak widać skutecznie.
> Nie wiem do czego nawiązujesz.

Do bredzenia o tym że cośtam powiększa aplikacje o magabajty "bo trzeba
rozwijać szablony". Łomatko. Rozwijam szablony i raz mam 0 bajtów a raz
gigabajty. Na tego typu opinie nalezy natychmiast mówić "Stop". Generują
tylko atmosere podobną do antyszczepionkowców. Podobno użycie RAII
powoduje autyzm.

>>> pozbawionego błędów. Tak się mówi że szablony stanowią antidotum na błędy, bo
>>> porównuje się je zwykle do najbardziej błędogennych konstrukcji języka, jak
>>> wlaśnie do makr, albo do rzutowania na void*.
>> Stanowią warstwę chroniącą przed pewną klasą problemów. Akurat tych
>> upierdliwych, bo w runtime.
> Może tak naprawdę spieramy się o to, że Ty uważasz iż szablony bardzo
> usprawniają technologię oprogramowania, a ja że usprawniają ją w mniejszym
> stopniu?

To zdajnie powyżej to nawet nie do końca się do szablonów odnosi.
Bardziej do silnych typów. Tak silnych że drą japę na kompilacji, czego
void* nie potrafi.

> Nie zgadzam się też, że trudno popełnić błąd w runtime programując z
> wykorzystaniem szablonów.

Kawestia oceny. Przypadki kiedy typ nie pasuje są u mnie zredukowane do
prawie 0.

> Nie wiem, trudno mi się wypowiedzieć, bo od wielu lat void* zdarza mi
> się użyć może raz na rok. Może z 15 lat temu używałem regularnie, też
> dawałem radę. I nie chcę powiedzieć po prostu że kiedyś bez papieru
> dawali radę, ale że jak dawali radę, to ten papier toaletowy nie jest aż
> takim panaceum, tylko jakimś kolejnym małym ulepszeniem.

I jest za darmo. Znaczy nie papier tylko C++.

>> Myśle że 90% konstrukcji z boosta jest trywialna.
> Pisałeś też że się napracowali przy booście, czy miałeś na myśli że
> napracowali się przy pozostałych 10ciu procentach?

Nie jest istotne kto się naprawcował *przy* booscie. Istotne jest ile
napracuje się klient tego API. No więc niewiele. O wiele mniej niż
straszy się młodych studentów oferujac im w zamian łupanie kamieni void*.

>>> Gdy każde jeszcze ma jakieś parametry i
>>> typy - to naprawdę zazwyczaj dostawałem oczopląsu gdy analizowałem swój własny
>>> kod po krótkim czasie. Myślę że każdy programista uznałby za łatwiejszy w
>>> analizie kod np. Javy.
>> Więc masz kiepskie doświadczenia wynikające z kiespkiego doboru przykładów.
> Czysta złośliwość czy kryje sie za tym coś konstruktywnego? Co to są
> kiepskie doświadczenia?

Kiepskie przykład to na przykład analiza closures w boost::spirit. Tam
jest cieżko. I jestem pewny że jeśli ktoś chciałby mi złośliwie wykazać
że boost jest trudny to wyjmie przykłąd z okolicy boost::spirit, mpl czy
fusion. To są złe doświadczenia. Przy uzywaniu takim jak na początku
watku, czyli "małych kawałeczków C++ usprawniajacych pracę" takie
kobylaste szablony nie tylko się nie trafiają ale i sensu nie mają.
Przyjdzie czas to ktoś to doceni. Na razie wolałbym aby embedowcy
zauważyli że ktoś w zeszłym wieku wymyślił RAII. To już by było naprawdę
miłe.

>> Używam C++. W tym szablonów. Szablony są od dziesiątek lat coraz lepiej
>> wspierane przez kompialtory (komunikaty błedów) i debuggery (pokazywanie
>> zawartości). Nijak nie wiem czemu foo<int> miało by być bardzie
>> skomplikowane do debugu. Jedyna przeszkoda to czasem dłuższe nazwy
>> typów. Tylko że tam się zagląda raz na rok.
> Na razie rozumiem, że dobre doświadczenia są wtedy gdy się tam zagląda
> raz na rok, a gdy ktoś akurat nad tym pracuje, to nabiera kiepskich
> doświadczeń.

Nie, to oznacza że kłopoty z debugiem kodu szablonowego praktycznie nie
wystepują w praktyce. Czasem się tam zagląda, w 50% przypadków brakuje
const albo miał być pointer a jest referencja. Ale to widać od razu, bez
debugowania. Ostatni raz rozwijałem mapę stl jakieś 2 lata temu szukając
dlaczego nie działa. Kodu biblitecznego stl/boost praktycznie sie nie
debuguje mimo że mój kod jest nimi przesiąknięty na wylot.

> Miałem na myśl nie nie tylko śledzenie linia po linii wykonania kodu w
> programie do debugowania, tyko generalnie usuwanie błędów. Gdy oglądam
> kod z 'wirtualnym typem' który dopiero w trakcie kompilacji będzie na
> kilka sposobów konkretyzowany, to wcale nie jestem bardziej pewny jego
> bezbłędności, niż gdy patrzę na kod zwykłej procedury. W zasadzie to
> chyba mam odwrotnie, co do zwykłych procedur szybciej nabieram przekonania
> że są poprawne. A swoją drogą w programach do debugowania też było
> sporo błędów i gorzej sobie radziły na szablonach.

Znowu chciałem przypomnieć że lata 90 słusznie mineły.

>>> nie mam z nimi problemów. Ale gdy np. cały algorytm genetyczny parametryzuję
>>> kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
>>> edytor nie wie jakie metody będą miał parametry.
>> Masz zły edytor.
> Może, a jaki Ty masz?

Np. VS + Visual Assist. Visual assist poniekąd potrafi domyślać się
detali związanych z szablonami, i prawidłowo podpowiadać. I gubi się
czasem, tak. Trudny język, ciężko o dobry edytor, ale nie jest tak że
nie ma *nic*.

>> Mam młotek, ale lepiej wbijać gwoździe lutownicą.
>> Mam szablony, ale przecież void* to tylko kilka wad z którymi da sie żyć.
> Nie, nie to chciałem powiedzieć. Mam szablony, używam szablonów, ale jestem
> świadomy że z void* też działało, więc te szablony to nie żadne panaceum, ale
> jakieś kolejne ulepszenie.

Tu jest zupełnie inaczej. Silne typy są lepsze niż void*, mniej więcej
zawsze. Mimo to ludzie używający void*, czasami wymieniając ich wady,
dalej nie widzą sensu zmieny na silne typy. Problemem jest brak
logicznego argumentu dlaczego. W dodatku wielu reaguje skrajnie
alergicznie na pytanie "Dlaczego używasz void* skoro silne typy są za
darmo". To jest religia białkowa.

>> Ja rozumiem jeszcze jak by za używanie szblonów trzeba było płacić.
> Bo trzeba, nic nie jest za darmo. Tą opłatą była/jest:
> - konieczność szkolenia personelu,

Używają int, float. Nagle muszą użyć Foo. To jakaś katastrofa?

> - konieczność nabrania doświadczenia przez personel,

Mieli na to ostatnie 40 lat.

> - wiele lat implementacji w kompilatorach,

Które od wielu lat je mają.

> - problemy bo kompilatory różnie to wspierały,

Zaznaczam po raz kolejny że lata 90 słusznie mineły.

> - targi o to jak powinny wyglądać w standardzie,

Zakończone standardem.

> - próby łamania standardu przez niektóre firmy,

Które nie wpływają na 99.9% kodu pisanego w C++ najmniejszym stopniu
oraz identyczne problemy występują w każdym, dowlnym języku i kompilatorze.

> - o wydłużonym czasie kompilacji, zwiększonym rozmiarze kodu i słabym

Atari 65XE słabo się sprawdza jako ciągła integracja, podobnie klikanie
w "rebuild".

> pokazywaniu właściwej linii z syntax error - już pisałem.

To dobrze, bo w clangu też to zauważyli

> - o tym jak to wygląda z punktu widzenia kogoś kto przygotowuje
> wygodny szablon - też już pisałem.

Ale to nikogo nie obchodzi po stronie klienta.

>> Szablony rozwiazują dobrze kreśloną klasę problemów z jakością kodu.
> Zgoda, ale wprowadzają też inne problemy.

Nie. Ich naduzywanie może generować problemy. Zastapienie void* silnym
typem nie tylko jest oczywistym rozwiązaniem problemów z jakoscią kodu
ale wręcz zmusza do poprawy jego jakości podczas pisania.

Perwsze słyszę aby silne typy miał jakieś wady vs void*.

Na marginesie: void* to nie brak typu. To typ. Coś jak by pisać w javie
kastujac wszystko do Object i spowrtoem za każdym razem. Po h.. ?

> Choć podsumowanie dziś wypada na
> korzyść szablonów, to po odjęciu wad, to podsumowanie nie jest rewelacyjne.

Stosujesz typową metodę dyskutowania: będę wyważony, to będę brzmiał
mądrze. Tylko że te "nie jest rewelacyjne" jest troche smutne w
zderzeniu z faktem że szablony są <division by zero exception> razy
lepsze od void*.

>> W C nie ma nic co mogło by to zastapić poza modlitwą.
> Zewnętrzne programy narzędziowe pełny rolę generyków, sam jeden większy
> generator napisałem do generowania sieci neuronowych. No i był void* i
> makra ;-)

Kto komu broni generować kod z void*. Pisanie void* z palca jest porażką
a nie generowanie.

>> Jesteś pewien że masz wszystko dobrze że masz potrzebę pełnej rekompilacji?
> Bym musiał napisać (i potem pilnować) specjalne pliki make, które uwzględniają
> kompilację warunkową.

I robisz to co 30 sekund? Czy może robi to ciągła integracja?

> Nie wiem co gorsze, modlić się czy nie mam błędu w
> pliku make, czy czekać te 30 sekund.

To nie ty czekasz. To ciągła integracja czeka. Ty popijasz kawę, albo
robisz coś innego.

>> Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny że
>> nie powinien być uważany za reprezentacyjny.
> Nie wiem czy kiepski przypadek, sam przyznałeś że ludzie od boosta
> się napracowali ciężko...

Nie widzę związku.

Zmieniasz globalnego define. Wymaga to rekompilacji wszystkiego.
Argument że wtedy jest wolno jest taki sam w C jak i w C++.

>> Z faktu że ktoś kiedyś robił kupę bez papieru nie wynika że papier jest
>> zbędny obecnie.
> No nie, mamy papier, żyje się trochę lepiej, ale musimy za niego zapłacić,

> go produkować, oczyszczać [...]

Niekiedy daleko idace analogie są błedne.

C++ jest za friko.

Napisanie Foo* zamiast void* jest za friko.

RAII jest za friko.

W ogóle wszystko jest za friko.

Upierdiwy profesor powie że plik kompiluje się 1.7ms dłużej. I będzie
miał rację. Ten 3-ci rodzaj racji. Coś jak uszczędzanie na plastikowych
słomkach w prywatnych samolotach.

>>>> 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?
>>> Może czary, a może to (w jakimś stopniu) dzięki void* ?
>> Nie, C++ z szablonami. SaSC miał translator z C++ na generowany C.
> Tak. Były generyki i w C, tylko na poziomie narzędzi a nie języka.

Nie rozumiesz. SasC to był również normalny C++. To że w środku
konwertował to na C i kompilował, to detal. Nieistotny. Niewidoczny.

Miałem więc kompilator C++ na 2MB RAMu bez swapa i dało się w tym pisać
obiektowe i okienkowe aplikacje o przyzwoitej wydajnosci. Ba, o
wydajności zbliżonej do tej z C. Róznica była głównie w tym że ten
konwerter był *bardzo* kiepski.

>> Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z
>> wyborem języka C czy C++. Ma związek jedynie z kiepskimi programistami,
>> przyrostem danych i rozbudową OSów.
> Też mi jest trudno się wypowiedzieć, w sumie nie biorę udziału w
> programach których kod wynikowy nie mieści się na DVD. Myślę jednak
> że zdublowanie kodu ma największy wpływ.

Całe szczęscie C++ nie dubluje kodu sam z siebie jesli ludzie nie piszą
byle jak.

[heby]

On 30/01/2020 08:40, Tomasz Kaczanowski wrote:
>> Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną
>> rozsądną.
> Dzięki swojej prostocie, łatwiej jest przygotować kompilator C niż C++
> na eksperymentalną platformę.

Przypomnij mi który obecnie używany i popularny kompilator C/C++
generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?

> Więc jeśli nie masz gotowych narzędzi
> kompilującej kod na daną platformę, to przystosowanie nawet już
> istniejącego kompilatora jest po prostu prostsze, więc zajmuje mniej
> czasu, a czasem może mieć to znaczenie.

Szczególnie jak odkrywasz że współczesne kompilatory to jakieś
frontendy, backedy, kody pośrednie, maszyny wirtualne itd itp ...

[heby]

On 30/01/2020 00:54, Maciek Godek wrote:
>> Może sobie mieć. Istotne jest że stan ten nie przecieka nigdzie poza nią.
> W korutynach właśnie przecieka.
> Jeżeli mam:
>
> int c() {
> while(1) {
> yield(1);
> yield(2);
> }
> }
> to jaka będzie wartość wyrażenia c()?

1 i 2. W zależności od numeru wywołania. Gdzie tu wycieka jakiś stan
wewnetrzny? Napisałeś generator. Generator generuje. Dostałeś co
chciałeś. W czym problem?

>> Własnie odkryłeś że funkcje pure mogą mieć mutowalne, prywatne zmienne w
>> środku i dalej być pure.
> Mylisz "funkcje pure" z hermetyzacją.

Nie, nie mylę.

Pure function [...] Its evaluation has no side effects (no mutation of
local static variables, non-local variables, mutable reference arguments
or I/O streams).

Nic to nie piszą o tym że nie wolno mutować lokalnych zmiennych. Ale
spokojnie, to tylko internet, na pewno kłamią.

>>> A czysta funkcja robi tylko jedno: odwzorowuje wejście w wyjście. Zawsze dla tego samego wejścia ma dać to samo wyjście. Nie ma stanu wewnętrznego.

Korutyna może być pure gdy nie mutuje świata poza nią. Ale nie jest
fukcją tylko generatorem. Czyli ma *wiele* wyjśc a nie jedno. Ot i cała
tajemnica.

Twoje rozwiązanie ze zmiennymi statycznymi powoduje że nie jest pure. To
nie powoduje że nie działa. To powoduje tylko tyle że jest mało
użyteczne w świecie gdzie "pure" jest preferowane ... czyli prawie wszędzie.

> Funkcji nie da "się zatrzymać", bo ona "się nie wykonuje".
> Ona odwzorowuje wejście w wyjście,

Korutyne da się zatrzymać. Taka jej istota. Da się ją w tym stanie
przeplatać z innymi korutynami, ba nawet tymi samymi ale pracującymi z
innym kontekstem (w normalnych implementacjach: stosem).

I korutyna może ale nie musi zwracać nic, jedną lub wiele wartości.

>> Bycie pure to nie jest nie posiadanie kompletnie żadnego stanu. To jest
>> nie ingerowanie w stan poza tą funkcją. W C/C++ do tego używa się
>> zazwyczaj stosu.
> Może lepiej idź już spać.

Radze poczytać internety w kwesti co to jest pure.

Korutyna to nie jest funkcja w rozumieniu "pure function" ale moze byc
"pure coroutine".

Twoje nie są z powodu fundamentalnego błedu implementacyjengo w jump
oriented programming. Moje z boosta mogą, ale nie muszą być "pure". Mam
wybór.

>> To zabawne, bo moje korutyny też nie mają. Robią yield() i z ich puktu
>> widzenia nic się nie stało, jadą dalej.
> Jeżeli "jadą", to mają przebieg sterowania.
> Przebieg sterowania to jest właśnie "jechanie".
> I ono jest czymś istotnym dla korutyny.

Zaś kolor niebieski jest niebieski.

> Tutaj masz, proszę, poczytaj sobie:
> https://www.quora.com/What-is-functional-programming/answer/Panicz-Godek

Mam kilka książek, niektóre nawet czytałem. Dziękuję.

>> Korutyna zachowuje się jak funkcja z wieloma punktami wyjścia i
>> hermetycznym stanem pomiędzy.
> Funkcja nie ma czegoś takiego jak "punkt wyjścia". Funkcja odwzorowuje dziedzinę w przeciwdziedzinę.

Widzisz, problem jest w tym że jesteś czepialski i nie rozumiesz metafor.

Nie, korutyna nie jest funkcją ani nie ma obowiązku być pure.

To o co chdozi w tej dyskusji to fakt że:
a) moje korutyny mogą być bez side effectów i znimi, mam wybór
b) Twoje, z powodu dziadowskiej implementacji, mogą mieć tylko side
effecty lub wymagają dodatkowego kodu do zarządzania ich stanem, pzoa
tym posiadają masę wad, wszystkie wymienione na wiki.

> Pierdolić potrafi każdy.

Dlatego masz pełne prawo pisać na usenecie dowolnie bezuzyteczne kawałki
kodu, ale musisz pamietać że reszta świata może i ma prawo a nawet
obowiązek popukać się w czoło.

> Kodu nie napiszesz, ale nie dlatego, że to "poniżej godności", tylko dlatego, że to, co do tej pory mówiłeś o korutynach, nie miało sensu.

Napisałeś kod nazywając to "korutynami" który nie ma z nimi wiele
wspólnego. Zostałeś nawet z tego powodu wyśmiany, jak setki przed tobą
piszących ten sam kod, na głupiej wikipedii.

I mówisz że to co mówie nie ma sensu.

Nie miewasz przypadkiem czasem wrażenia że cały świat jest przeciwko Tobie?

> Określenie, żeby "odpalać naprzemiennie tę samą korutynę" jest całkowitą bzdurą.

Oczywiście. Dalej nie pojmujesz że istnieje coś takiego jak "kod" i
"kontekst wywołania".

W przypadku C tym konteksem jest stos.

Nic dziwnego że tego nie widzisz, twoje korutyny to kod i kontekst
zmielone razem w zmiennych statycznych.

> Naprzemiennie możesz odpalać dwie różne rzeczy

Widziałeś kiedyś dwa wątki pracujace na tych samych instrukcjach
maszynowych w tej samej pamieci, RÓWNOLEGLE?

To teraz użyj wyobraźni aby sobie wyobrazić że ta sama korutyna może
pracować na dwóch róznych kontekstach wywołania, naprzemiennie, nie
zakłucając się. boost to potrafi. Bo używa kontekstu stosu a nie
zmiennych statycznych.

> , a nie "dwie te same rzeczy", bo "dwie te same rzeczy" to jest jedna i ta sama rzecz.

Zgubiłem biedaku kontekst wywołania kodu i stąd te problem w pojmowaniu
dlaczego Twoje korutyny są tylko pośmiewiskiem na wikipedii.

[Maciek Godek]

W dniu czwartek, 30 stycznia 2020 23:11:51 UTC+1 użytkownik heby napisał:
> On 30/01/2020 00:54, Maciek Godek wrote:
> >> Może sobie mieć. Istotne jest że stan ten nie przecieka nigdzie poza nią.
> > W korutynach właśnie przecieka.
> > Jeżeli mam:
> >
> > int c() {
> > while(1) {
> > yield(1);
> > yield(2);
> > }
> > }
> > to jaka będzie wartość wyrażenia c()?
>
> 1 i 2. W zależności od numeru wywołania. Gdzie tu wycieka jakiś stan
> wewnetrzny?

Miejsce zatrzymania jest stanem wewnętrznym.

> Napisałeś generator. Generator generuje. Dostałeś co
> chciałeś. W czym problem?

Udostępniłem stan wewnętrzny konsumentowi.
Nie ma problemu. Tylko to nie jest "pure function".

> >> Własnie odkryłeś że funkcje pure mogą mieć mutowalne, prywatne zmienne w
> >> środku i dalej być pure.
> > Mylisz "funkcje pure" z hermetyzacją.
>
> Nie, nie mylę.
>
> Pure function [...] Its evaluation has no side effects (no mutation of
> local static variables, non-local variables, mutable reference arguments
> or I/O streams).
>
> Nic to nie piszą o tym że nie wolno mutować lokalnych zmiennych. Ale
> spokojnie, to tylko internet, na pewno kłamią.

Jasne, możesz sobie robić co chcesz, jeżeli stan nie jest widoczny z zewnątrz.
A w przypadku powyższej korutyny stan jest widoczny z zewnątrz, bo albo jesteś w takim stanie, że dostaniesz 1, albo w takim, że dostaniesz 2.

> >>> A czysta funkcja robi tylko jedno: odwzorowuje wejście w wyjście. Zawsze dla tego samego wejścia ma dać to samo wyjście. Nie ma stanu wewnętrznego.
>
> Korutyna może być pure gdy nie mutuje świata poza nią. Ale nie jest
> fukcją tylko generatorem. Czyli ma *wiele* wyjśc a nie jedno. Ot i cała
> tajemnica.

?

Gdzie tak piszą?

> Twoje rozwiązanie ze zmiennymi statycznymi powoduje że nie jest pure. To
> nie powoduje że nie działa. To powoduje tylko tyle że jest mało
> użyteczne w świecie gdzie "pure" jest preferowane ... czyli prawie wszędzie.

Gdzie "pure" co jest preferowane?
"Pure mineral water"?

> > Funkcji nie da "się zatrzymać", bo ona "się nie wykonuje".
> > Ona odwzorowuje wejście w wyjście,
>
> Korutyne da się zatrzymać. Taka jej istota. Da się ją w tym stanie
> przeplatać z innymi korutynami, ba nawet tymi samymi ale pracującymi z
> innym kontekstem (w normalnych implementacjach: stosem).

Dlatego nie jest "czysta" w takim sensie, w jakim "czysta funkcja" jest "czysta".

> I korutyna może ale nie musi zwracać nic, jedną lub wiele wartości.

A czysta funkcja musi zwrócić wartość.

> >> Bycie pure to nie jest nie posiadanie kompletnie żadnego stanu. To jest
> >> nie ingerowanie w stan poza tą funkcją. W C/C++ do tego używa się
> >> zazwyczaj stosu.
> > Może lepiej idź już spać.
>
> Radze poczytać internety w kwesti co to jest pure.

No to dajesz linki do tych swoich internetów.

> Korutyna to nie jest funkcja w rozumieniu "pure function" ale moze byc
> "pure coroutine".

Łooo!
I pewnie może też być "pure fun".

> >> Korutyna zachowuje się jak funkcja z wieloma punktami wyjścia i
> >> hermetycznym stanem pomiędzy.
> > Funkcja nie ma czegoś takiego jak "punkt wyjścia". Funkcja odwzorowuje dziedzinę w przeciwdziedzinę.
>
> Widzisz, problem jest w tym że jesteś czepialski i nie rozumiesz metafor.
>
> Nie, korutyna nie jest funkcją ani nie ma obowiązku być pure.
>
> To o co chdozi w tej dyskusji to fakt że:
> a) moje korutyny mogą być bez side effectów i znimi, mam wybór

Nie mogą, bo yield jest side effectem. Chyba że nie jest, to wtedy nie są korutynami, tylko funkcjami.

> Nie miewasz przypadkiem czasem wrażenia że cały świat jest przeciwko Tobie?

Raczej nie.

> > Naprzemiennie możesz odpalać dwie różne rzeczy
>
> Widziałeś kiedyś dwa wątki pracujace na tych samych instrukcjach
> maszynowych w tej samej pamieci, RÓWNOLEGLE?
>
> To teraz użyj wyobraźni aby sobie wyobrazić że ta sama korutyna może
> pracować na dwóch róznych kontekstach wywołania, naprzemiennie, nie
> zakłucając się. boost to potrafi. Bo używa kontekstu stosu a nie
> zmiennych statycznych.

Boost potrafi. Moje rozwiązanie nie potrafi (chyba że ktoś by chciał generować ten sam kod funkcji wielokrotnie z makra, ale to średni pomysł).
Dlatego problem, że "dwie te same korutyny będą sobie nawzajem nadpisywać stan", nie może wystąpić.

[heby]

On 30/01/2020 23:58, Maciek Godek wrote:
> Boost potrafi. Moje rozwiązanie nie potrafi (chyba że ktoś by chciał generować ten sam kod funkcji wielokrotnie z makra, ale to średni pomysł).
> Dlatego problem, że "dwie te same korutyny będą sobie nawzajem nadpisywać stan", nie może wystąpić.

Wiadomo, można zawsze z buga zrobić feature.

"Dzięki temu że nie działa nam w kalulatorze dodawanie masz zaletę że
nie wiesz ile wisisz urzędowi skarbowemu".

Powodzenia!

PS. Twój kod też to może w ograniczonej formie potrafić. Dodaj kontekst
do makr. Nie, to dalej będzie do dupy, ale zatrzyma się tylko na
okrężnicy a nie dwunastnicy. Zawsze jakiś postęp.

[(fir)]

W dniu czwartek, 30 stycznia 2020 22:45:28 UTC+1 użytkownik heby napisał:
> On 30/01/2020 04:40, M.M. wrote:
>
> > Bajeranckie cechy języka... to
> > nawet spowalniają, bo programista myśli czego lepiej użyć.
>
> Odwrotnie. Programista nie myśli jak jest zbudowany std::container,
> używa move i ma najszybszą z możliwych implementację. Pisanie w C++
> opiera się na pewnych obietnicach: napisz co chcesz a my zrobimy to tak
> dobrze jak się da, albo przynajmniej najlepiej jak potrafimy.
>

zdeczka osobliwa ta dyskusja ;c, ale moge cos dodac bo akurat ostatnio natknalem sie na ciekawy przypadek: testowalem ile zajmie sortowanie 1e6 intow (na moim starym kompie)

qsort z c byl dpsyc wolny 250 ms, std::sort z c++ 111 ms, i niech teraz usenetowy kolega zgadnie ile zajal w stosunku do tego c++owego std::sorta kawalek prostego c (nie moj, znaleziony w necie)...

[Maciek Godek]

Zapomniałeś wkleić linki wyjaśniające, czym są "pure coroutines".

[Maciek Godek]

Pytania:
- czy testowałeś na tych samych danych?
- czy używałeś tego: https://github.com/ccurtsinger/stabilizer/blob/master/README.md

[Tomasz Kaczanowski]

W dniu 2020-01-30 o 22:47, heby pisze:

> On 30/01/2020 08:40, Tomasz Kaczanowski wrote:
>>> Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną
>>> rozsądną.
>> Dzięki swojej prostocie, łatwiej jest przygotować kompilator C niż C++
>> na eksperymentalną platformę.
>
> Przypomnij mi który obecnie używany i popularny kompilator C/C++
> generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?

a co to ma do rzeczy, jeśli musisz przystosować bibliotekę standardową
do specyfiki nowego systemu?

>
>> Więc jeśli nie masz gotowych narzędzi kompilującej kod na daną
>> platformę, to przystosowanie nawet już istniejącego kompilatora jest
>> po prostu prostsze, więc zajmuje mniej czasu, a czasem może mieć to
>> znaczenie.
>
> Szczególnie jak odkrywasz że współczesne kompilatory to jakieś
> frontendy, backedy, kody pośrednie, maszyny wirtualne itd itp ...

tak... rozmawiamy o c i c++, czy językach korzystających z maszyn
wirtualnych?

--
http://kaczus.ppa.pl

[Mateusz Viste]

2020-01-30 o 16:44 -0800, (fir) napisał:
> qsort z c byl dpsyc wolny 250 ms, std::sort z c++ 111 ms, i niech
> teraz usenetowy kolega zgadnie ile zajal w stosunku do tego c++owego
> std::sorta kawalek prostego c (nie moj, znaleziony w necie)...

No ale wojna hebo-maćkowa dotyczy wyższości C++ nad C. heby zresztą
słusznie zauważa, że gdyby zupełnie wyeliminować z tego całego
programowania człowieka, to C++ byłby bardzo fajny. Trochę jak
socjalizm.

Ty natomiast porównujesz implementację jednego libc do drugiego - a to
już coś zupełnie innego, związek z językiem jest bardzo luźny i odległy.

Mateusz

[(fir)]

a kto tu mowi o jezykach? w tym watku padla cala masa dzikich twierdzen, ja chce sie odniesc do tych tekstow ze 'lata 90te slusznie minely' i ew troche do historii z szablonami ;c

akurat sortowanie (w szczegolnosci sortowanie intow) to kawalek kodu ktory zwykle jest relatywnie dlugi wiec potrafi
zwolnic kompa (pozatym jest dosyc znanym, slawnym case w swieice programowania) itd wiec wychodzi na to ze to std::sort powinni chyba zrobic dobrze, nie tak ze pice of code w c wziete z netu bedzie
szybsze tylko raczej wolniejsze

a wynik mojego testu jest raczej zaskakujacy (ale nie mowie czy bylo szybsze, moze bylo wolniejsze (moge dodac ze byl to najlepszy wynik jaki udalo mi sie osiagnac kawalkami kodu w c do sortowania) tylko zadaje pytanie jak poprzedni kolega mysli o ile to bylo szybsze lub wolniejsze od std:sort

przy okazji nie twierdze niczego bo takie uogolnianie spraw (zwlaszcza bledne) nie jest jak dla mnie specjalnie przydatne (wiec nie che uogolniac podaje konkretny przypadek, wyniki testu w sortowaniu 1e6 intow w tablicy std:sort kontra najlepszy jaki znalazlem 40-linijkowy kawalek kodu w c)

[(fir)]

W dniu piątek, 31 stycznia 2020 08:52:47 UTC+1 użytkownik Mateusz Viste napisał:

> 2020-01-30 o 16:44 -0800, (fir) napisał:
> > qsort z c byl dpsyc wolny 250 ms, std::sort z c++ 111 ms, i niech
> > teraz usenetowy kolega zgadnie ile zajal w stosunku do tego c++owego
> > std::sorta kawalek prostego c (nie moj, znaleziony w necie)...
>
> No ale wojna hebo-maćkowa dotyczy wyższości C++ nad C. heby zresztą
> słusznie zauważa, że gdyby zupełnie wyeliminować z tego całego
> programowania człowieka, to C++ byłby bardzo fajny. Trochę jak
> socjalizm.
>

w tm watku szczerze owiac pada masa szalenczo glupich wierdzen dlatego przpomina filmy barei czy cos w tym stylu

(nie che nawet sie do tego odnosic bo widzac jakosc tych twierdzen mozna by sie spodziewac podobnej jakosci odpowiedzi ;c
a to by mnie chyba zabilo, mowiac metaforycznie (inaczej mowiac nie mam
czasu na takie dyskusje ;c)

[M.M.]

C++ jest (nie licząc drobiazgów) nadzbiorem C, więc nie może być
gorszy.


Kiedyś jak napisałem na egzamin coś w C++, to dostałem zjeby bo
pójdę pracować do biedniejszej firmy, albo na liunxa, a tam C++
nie ma, a jak użyłem new to już w ogóle dostałem takie zjeby, bo
new jest łogroooomne a mój program na zaliczenie ma tylko 10 linijek,
więc new stanowi jego 99% kodu wynikowego. Co gorsza miało to
na mnie zbyt duży wpływ, potem zadawałem sobie nie raz bezsensowny
trud żeby rozwiązać coś przy pomocy prostszych narzędzi. Ale to
była historia, ostatnio na mikrokontroler pisałem program w
C++ z szablonami i dzięki temu łatwiej mogłem zarządzać eksperymentami i
wybrać najmniejszą wersję która w ogóle mieściła się w pamięci
mikrokontrolera. W C bym uzyskał podobny efekt i to nawet podobnym
nakładem pracy, ale do zarządzania eksperymentami na pewno bym musiał
dużo więcej się napracować w Co.


Wracając do teorii, jeśli mamy nadzbiór fitczerów, to język nie może
być gorszy. A jednak jeśli według rankingów 5-7% programistów wybiera
czysty C i według tych samych rankingów 12-15% wybiera najpopularniejszy
język w danym czasie, to z czym mamy do czynienia? Wszyscy programiści
programujący w C dokonali złego wyboru czy coś jest na rzeczy?

Kiedyś myślałem że ludzie grający w lotto to idioci, bo esperancja mówi
wyraźnie, że średnio tracimy 50%. W przypadku lotto rzecz w tym, że czasami
3 złote (czy tam ile na kupon) nie jest 100tys razy mniejsze od potencjalnej
wygranej 300tys, tylko np. milion razy. Choć 300tys / 3 = 100tys, to w
pewnych (i to częstych sytuacjach) z uwzględnieniem korzyści jakie można
mieć z 3 zł i z 300tys zł, włąśnie 300tys / 3 = milion. Jak ktoś opłacił
rachunki i ma na jedzenie, to ma jeszcze parę groszy w kieszeni, to za
te parę groszy nic sensownego nie może zrobić, nawet jakby je wrzucał do
skarbonki przez lata. Po głębszej analizie gracze w gry które teoretycznie
są przegrane przestają być osobami które dokonują błędnych decyzji.

Może jakby się głębiej przyjrzeć programistom C, to ich wybór też wcale
nie jest bezsensowny? Mi się narzucają dwa argumenty o których już
pisałem:
1) Mniej fitczerów oznacza mniej zastanawia się nad sposobem rozwiązania
danego problemu, piszemy sztancowo, z szablonu, a code review częściej
przechodzi.
2) Koszt szkolenia, czas na szkolenie, czas na zdobycie doświadczenia. W
C++ niedoświadczony programista może wpaść w wiele pułapek.
3) Gdzieś słyszałem argument, że wolą programistów w C, bo są tańsi od
programistów w C++.
4) Jeśli jest masa fitczerów i masa pułapek, to w każdej firmie, jeśli
nie w każdym projekcie, jest narzucane co można, a czego nie można.
Przychodzi doświadczony programista z firmy A do firmy B. Robi w
istniejącym projekcie kawałek dobrej roboty. A potem dowiaduje się że
u nas nie można protected, szablony maksymalnie tylko z jednym
parametrem, zakaz wielodziedziczenia, w takich przypadkach w
ogóle agregacja zamiast dziedziczenia, itd. Zanim zmieni nawyki, minie
trochę czasu, albo się nawet zniechęci.


A tak jeszcze co do szkolenia... Dużo programuję w C++. Lambdę użyłem w
praktycznym problemie może jeden raz w życiu. Potem chciałem użyć
ponownie. Minęło tyle czasu, że zapomniałem składnie. Musiałem odszukać w
dokumentacji. Nie wiem czy z uwzględnieniem czasu na szukanie informacji o
składni bym nie rozwiązał danego problemu szybciej ze starymi wskaźnikami na
funkcję.


Pozdrawiam

[M.M.]

Przepraszam, nie będę kontynuował, ponieważ za dużo tekstu bym musiał
napisać, żebym został zrozumiany tak jak wyobrażam sobie w chwili
pisania tegoż tekstu :) Zadam tylko pytanie: dlaczego według rankingów
aż około 5-7% programistów wybiera C, gdy język najbardziej popularny w
danym czasie wybiera np. 12-15%. Coś nie tak z tymi programistami od C
jeśli są tylko zalety z przejścia na C++, czy to jednak jakaś mądrość
tłumu?

Pozdrawiam

[john.sto...@gmail.com]

Sorki pisze z telefonu.. gdyby tak było to by znaczyło że dowolny patologiczny duren moze zrobić wlasciwie wymyslec lepszy język dodając do języka C dowolna nieważne jak głupie kupkę gowna.

Cpp trzeba rozliczać przez to co wnosi w stosunku do tego jakby było napisać to w C. I tak cpp jest na niesłusznie nobilitowany przez to że C jest jego czescia. Gdyby rozliczać czyste czesc cpp słone to by wyszedł prawie czysty crap. O tyle nie zupełnie totalny bo pewne drobne poprawki są trafione ale te poprawki to jednak małe elementy w morzu crapu ;( {fir}

[Maciek Godek]

W dniu piątek, 31 stycznia 2020 13:00:00 UTC+1 użytkownik M.M. napisał:
> On Friday, January 31, 2020 at 8:52:47 AM UTC+1, Mateusz Viste wrote:
> > 2020-01-30 o 16:44 -0800, (fir) napisał:
> > > qsort z c byl dpsyc wolny 250 ms, std::sort z c++ 111 ms, i niech
> > > teraz usenetowy kolega zgadnie ile zajal w stosunku do tego c++owego
> > > std::sorta kawalek prostego c (nie moj, znaleziony w necie)...
> >
> > No ale wojna hebo-maćkowa dotyczy wyższości C++ nad C. heby zresztą
> > słusznie zauważa, że gdyby zupełnie wyeliminować z tego całego
> > programowania człowieka, to C++ byłby bardzo fajny. Trochę jak
> > socjalizm.
> >
> > Ty natomiast porównujesz implementację jednego libc do drugiego - a to
> > już coś zupełnie innego, związek z językiem jest bardzo luźny i odległy.
>
> C++ jest (nie licząc drobiazgów) nadzbiorem C, więc nie może być
> gorszy.

To zależy pod jakim względem.

Stosunkowo niedawno napisałem takie coś, i się okazało jakoś bardzo popularne.

https://www.quora.com/Is-it-still-worthwhile-to-learn-C-given-that-C-can-do-almost-everything-better/answer/Panicz-Godek

Jednym z problemów, jaki mam z C++, dość dobrze opisał wcześniej Mateusz: że najpierw jest noga w drzwi ("po co w C, skoro jest C++, i wystarczy zamienić gcc na g++?"), a później równia pochyła ("no, to skoro już mamy C++ to użyjmy jeszcze przeciążania operatorów i skorzystajmy z tego, że preprocesor szablonów jest Turing-complete")

I finalnie wychodzi, że kod jest niespójny, bo jakaś młodzież zapragnęła wcisnąć jakieś nowe ficzery, ktoś kiedyś wziął coś z boosta, a teraz weszło do standardu, ale nikt nie ma czasu tego zrefaktoryzować, czasy kompilacji jednego modułu przekraczają pół godziny, a komunikat o błędzie związanym z brakiem średnika nie zmieściłby się na rolce papieru toaletowego (i to tego, co do którego producent deklaruje, że ma długość czterech rolek)

A mówiąc jeszcze szerzej, baza kodu w C++ jest mocno niespójna.

I na przykład w Windowsowych nagłówkach do Bluetootha można znaleźć rzeczy w rodzaju:

template <typename D> typename consume_Windows_Devices_Bluetooth_GenericAttributeProfile_IGattSession<D>::SessionStatusChanged_revoker consume_Windows_Devices_Bluetooth_GenericAttributeProfile_IGattSession<D>::SessionStatusChanged(auto_revoke_t, Windows::Foundation::TypedEventHandler<Windows::Devices::Bluetooth::GenericAttributeProfile::GattSession, Windows::Devices::Bluetooth::GenericAttributeProfile::GattSessionStatusChangedEventArgs> const& handler) const
{
return impl::make_event_revoker<D, SessionStatusChanged_revoker>(this, SessionStatusChanged(handler));
}

A że ludzie uczą się przez naśladowanie wzorców, to potem sobie wyobrażają, że tak powinny wyglądać profesjonalne programy.

Dodatkowo masz taką sytuację, że w jednym języku masz ficzery, które wzajemnie się kłócą. Na przykład: możesz sobie w C++ używać setjmp/longjmp. No, chyba że używasz RAII, to wtedy zmiana kontekstu staje się "undefined behavior", czy, jak to śpiewała Anita Lipnicka, "wszystko się może zdarzyć"

[Mateusz Viste]

2020-01-31 o 04:54 -0800, Maciek Godek napisał:
> możesz sobie w C++ używać setjmp/longjmp. No, chyba że używasz RAII,
> to wtedy zmiana kontekstu staje się "undefined behavior", czy, jak to
> śpiewała Anita Lipnicka, "wszystko się może zdarzyć"

Kolega zdaje się nie do końca jest na bieżąco: kilka lat później Beata
Kozidrak nagrała sequel. "Plama na ścianie".

Mateusz

[Maciek Godek]

Te rewizje standardu zaczęły się ukazywać tak często, że ciężko nadgonić.

[(fir)]

W dniu piątek, 31 stycznia 2020 13:07:28 UTC+1 użytkownik M.M. napisał:
>
> Przepraszam, nie będę kontynuował, ponieważ za dużo tekstu bym musiał
> napisać, żebym został zrozumiany tak jak wyobrażam sobie w chwili
> pisania tegoż tekstu :)

a to szkoda bo ten watek byl wbitnie rozrywkowy ;x przebul chyba nawet znacznie starsza tworczosc niejakiego A. Jarząbka (tutaj u mnie nagromadzenie zdumienia z tego co czytam bylo chyba kilkukrotnie wieksze ;c )

[(fir)]

W dniu piątek, 31 stycznia 2020 13:29:10 UTC+1 użytkownik john.st...@gmail.com napisał:
> Sorki pisze z telefonu.. gdyby tak było to by znaczyło że dowolny patologiczny duren moze zrobić wlasciwie wymyslec lepszy język dodając do języka C dowolna nieważne jak głupie kupkę gowna.
>
> Cpp trzeba rozliczać przez to co wnosi w stosunku do tego jakby było napisać to w C. I tak cpp jest na niesłusznie nobilitowany przez to że C jest jego czescia. Gdyby rozliczać czyste czesc cpp słone to by wyszedł prawie czysty crap. O tyle nie zupełnie totalny bo pewne drobne poprawki są trafione ale te poprawki to jednak małe elementy w morzu crapu ;( {fir}

wyzej powinno byc "gdyby rozliczac czystą czesc c++ alone, to wyszedlby prawie czysty krap"

[(fir)]

dodam moze co w c++ jest wg mnei dobre
(te nieliczne rzeczy)

1) te drobne poprawki glownie to ze mozna uzyc "const int tab_max = 10000;" jako rozmiaru tablicy przy deklaracji..jest to akurat debilne w c ze nie mozna... plus jeszcze pare innych drobnych mao zauwazalnych poprawek wlasciwie do c (nie che mi sie przypominac i wyliczac..)

2) sama idea wlaczanie funkcji do struktur (ktora ja nazywam w skrocie tematem 's+f', chodzi mi o to ze valu oop jak w c++ uwazam za crap ale ta drobna idea ma sens (ale dla mnie nie wynika ona ani z c++ ani z OOP tylko z pewnej symetrii dot klecenia wyrazen w programowaniu dajacej wieksze srodki wyrazu) [z tej idei cos takiego jak OOP w c++ nie wynika choc wynika z niej cos w czesci podobnego do podzbioru OOP a w innej czesci go przekracza..dlugo by o tym jednak pisac)

3) przeciazanie operatorow - prawdopodobnie mniej ale teoretycznie i zapewne robione w nieco lepszej skladni i w nieco innej wersji niz w c++ jest to cos ciekawego (ale zaznaczam ze 'z teoretycznego punktu widzenia' jak z praktycznego to nei wiem bo nie uzywalem nigdy ani nie rozwazalem tego nawet nigdy na sucho..ale teoretycznie to daje mozliwosci)

[M.M.]

To niech kolega kontynuuje, a ja będę miał rozrywkę ;-)

Poważnie postawiłem pytanie (trzeci raz w tym wątku):

Dlaczego według rankingów aż około 5-7% programistów wybiera C, gdy

[(fir)]

nie rozumeim logicznego zwiazku co ma wibierenie c w 5-7 % a wybieraniem najbardziej popukarnego 12-15 % ? jaki jest zwiazek miedzy tymi dwiema
rzeczami?

na pytanie "czemu ludzie wybueraja c skoro c++ jest lepszy ?" moge opdowiedziec, zalozenie ze c++ jest lepszy (jesli kolega tak mysli, nie mam sily sprawdzac co dokladnie kto powiedzial) jest kolegi zludzeniem

nie mam jednak nic przeciwko pisaniu w tzw trybie c++ (sam niektore kody pisze w zdaje sie ansi C ale wiekszosc kodow kopiluje w trybie zgodnosci z jakims tam starym c++ (tez chyab z 89) tylko wylaczam wszystkie mozliwe c++ owe specyfiki itp i oczywiscie pisze wwylacznie c - a robie to ze wzgledu wlasnie na ten "const int tab_max = 10000;" bo ciezko mi zdzierzyc uzywanie emumow do tego celu..ale mimo wszystko nie nazywam mojego kodu c++em - i wolabym zeby nikt tak nie twierdzil bo moge sie naprawd wpienic ;c (bo takie wciskanie kitu na podstawie 'formalnosci' mnie strasznie wpienia szczerze mowiac)

[M.M.]

On Friday, January 31, 2020 at 5:43:48 PM UTC+1, (fir) wrote:
> W dniu piątek, 31 stycznia 2020 17:15:08 UTC+1 użytkownik M.M. napisał:
> > On Friday, January 31, 2020 at 4:19:57 PM UTC+1, (fir) wrote:
> > > W dniu piątek, 31 stycznia 2020 13:29:10 UTC+1 użytkownik john.st...@gmail.com napisał:
> > > > Sorki pisze z telefonu.. gdyby tak było to by znaczyło że dowolny patologiczny duren moze zrobić wlasciwie wymyslec lepszy język dodając do języka C dowolna nieważne jak głupie kupkę gowna.
> > > >
> > > > Cpp trzeba rozliczać przez to co wnosi w stosunku do tego jakby było napisać to w C. I tak cpp jest na niesłusznie nobilitowany przez to że C jest jego czescia. Gdyby rozliczać czyste czesc cpp słone to by wyszedł prawie czysty crap. O tyle nie zupełnie totalny bo pewne drobne poprawki są trafione ale te poprawki to jednak małe elementy w morzu crapu ;( {fir}
> > >
> > > wyzej powinno byc "gdyby rozliczac czystą czesc c++ alone, to wyszedlby prawie czysty krap"
> >
> > To niech kolega kontynuuje, a ja będę miał rozrywkę ;-)
> >
> > Poważnie postawiłem pytanie (trzeci raz w tym wątku):
> >
> > Dlaczego według rankingów aż około 5-7% programistów wybiera C, gdy
> > język najbardziej popularny w danym czasie wybiera np. 12-15%. Coś nie
> > tak z tymi programistami od C jeśli są tylko zalety z przejścia na C++,
> > czy to jednak jakaś mądrość tłumu?
> >
> nie rozumeim logicznego zwiazku co ma wibierenie c w 5-7 % a wybieraniem najbardziej popukarnego 12-15 % ? jaki jest zwiazek miedzy tymi dwiema
> rzeczami?

Miałem na myśli lepszy sposób porównywania. Jeśli napiszę, że 5% osób
wybiera język programowania C, to osoba niezaznajomiona z tematyką,
albo w pośpiechu nawet osoba zaznajomiona, może pomyśleć że 5% to
bardzo mało. Jeśli podam dwie liczby, mianowicie te 5% i 15% to widać że
język C wybiera zaledwie 3 razy mniej programistów niż wybrało język
najbardziej popularny. To nadal niedoskonałe porównanie, ale i tak
lesze niż 5% do całkowicie nieokreślonych 95%.

> na pytanie "czemu ludzie wybueraja c skoro c++ jest lepszy ?" moge opdowiedziec, zalozenie ze c++ jest lepszy (jesli kolega tak mysli, nie mam sily sprawdzac co dokladnie kto powiedzial) jest kolegi zludzeniem

Zadając powyższe pytanie absolutnie nic nie myślę, tylko oczekuję
odpowiedzi: dlaczego wybierają goły C, jak mają (naprawdę lub na niby)
lepszy C++ zupełnie za darmo?

> nie mam jednak nic przeciwko pisaniu w tzw trybie c++ (sam niektore kody pisze w zdaje sie ansi C ale wiekszosc kodow kopiluje w trybie zgodnosci z jakims tam starym c++ (tez chyab z 89) tylko wylaczam wszystkie mozliwe c++ owe specyfiki itp i oczywiscie pisze wwylacznie c - a robie to ze wzgledu wlasnie na ten "const int tab_max = 10000;" bo ciezko mi zdzierzyc uzywanie emumow do tego celu..ale mimo wszystko nie nazywam mojego kodu c++em - i wolabym zeby nikt tak nie twierdzil bo moge sie naprawd wpienic ;c (bo takie wciskanie kitu na podstawie 'formalnosci' mnie strasznie wpienia szczerze mowiac)

Rozmawialiśmy, że szkolenie zajmuje czas, a mam go przeznaczyć na rozmowę z
której będzie (w porywach) niewiele nauki ;-) Po prostu pytam, dlaczego
wybierają (tak często) C, skoro C++ jest 'lepszy' i całkowicie za darmo?

Pozdrawiam

[(fir)]

bo nie jest lepszy? wiec to pytanie zakladajace ze to dziwne skoro jest lepszy sie dezaktualizuje?

nawiasem mowiac co do c/c++ ->

niektorzy ludzie ktorzy pisza w c++ mysle nie wiedzą jak sie poprawnie pisze w c
(a przynajmniej jak ja pisze) i wydaje im sie ze w c sie wiecej nameczą skoro nie ma vectora czy jeszcze kilku rzeczy ale
fakty sa takie ze jak popisac w tym c to po nauczeniu sie jak to sie robi (co dla jako tako ogarnietego programisty nie zajmie strasznie duzo czasu) pozniej nie ma zadnych tego typu problemow

a zalety sa bardzo duze i sa takie (sam nie pisuje w c++ poza znajomsocia podstaw wiec moze nie wumienie wszystkich ;c )

1) nie ma babrania sie z szablonami i calym tym krapem (ktory jest totalnie bezsensowny) - kod jest prostszy szybszy (w czytaniu i pracy nad nim) ktrotszy, ladniejszy itd

2) nie ma babrania sie z OOP (mniej wiecej jak wyzej) w szczegolnosci z rozmaitymi wskaznikami (kod jest prostszy szybszy itd..)
(zamist babrania sie z oop polecam staranna prace nad dll-kami i prawdziwym kodem)

proponuje sprobowac, a jak nie to nie, wszystko mi jedno
(zaznaczam przy tym gwoli formalnosci ze mimo ze na dzis umiem dosyc ok pisac w c, napisalem kilka rzeczy to nie mam zarazem super doswiadczenia w pisaniu tysiecy rzeczy zwlaszcza w trybie pisania "na ilosc" (a mniej w moim typowym trybie pisania dla sztuki ;c) ale akurat nie ma to zdaje sie kluczowego znaczenia bo c i tak bedzie lepsze.. klocic sie nie mam jednak zamiaru bo nie mam czasu na takie komiczne dyskusje)

[(fir)]

W dniu piątek, 31 stycznia 2020 18:35:58 UTC+1 użytkownik M.M. napisał:
>

> Rozmawialiśmy, że szkolenie zajmuje czas, a mam go przeznaczyć na rozmowę z
> której będzie (w porywach) niewiele nauki ;-)

znowu nie rozumiem zwiazku - o jakis szkolenie chodzi ? o czas na nauke c++ i calego tego srodowiska? co ma to wspolnegoz rozmowa?

jesli chodzi o czas na nauke c++ to oczywiscie ze to ma bardzo wazne znaczenie..zamiast c++ lepiej uczyc sie w tym zcasie chocby bibliotek lub np internalsow...
sam c i tak jest za skomplikowany imo c wcale nie jesttaki prosty jak sie wydaje (bo sa setki drobnych i nieoczywiostych sztuczek i zagadnien ktore trzeba znac i rozumiec - juz c jest tak naprawde monstem skomplikowania imo poki sie go nei nauczy - po tym jest prosty i szybki do piisania

al enie chodzi tylko o to inny wazny powod toz e nie tzreba sie babrac w szablonach, lambdach itd (i uczyc tych dziwnych rzeczy o jezyku) i nie trzeba sie babrac w OOP - jest to naprawde gigantyczna zaleta

inne zalety sa tez takie ze jak nie masz mozliwosci poswiecanie uwagi na tego typu durnoty to sila rzeczy zajmiesz sie raczej centru problemu czyli samymi mechanikami programow

a sa zapewne i inne wazne zalety ale nie pisze w c++ wiec nie tak latwo mi wmienic

[heby]

On 31/01/2020 13:07, M.M. wrote:
> pisania tegoż tekstu :) Zadam tylko pytanie: dlaczego według rankingów
> aż około 5-7% programistów wybiera C, gdy język najbardziej popularny w
> danym czasie wybiera np. 12-15%. Coś nie tak z tymi programistami od C
> jeśli są tylko zalety z przejścia na C++, czy to jednak jakaś mądrość
> tłumu?

Białko. W dodatku programiści zazwyczaj nie wybierają języka.

Mają:
a) ulubione
b) uprzedzenia
c) mentorów od 7 boleści
d) bibliteki
e) specyfikacje
f) ignorancje
g) gotowe zespoły
h) lenistwo
i) autyzm
...

Zakładanie że wybór języka programowania podyktowany jest suchą oceną
jego przydatności w danym zastosowaniu jest naiwne. Białko nie wybiera
uzywając logiki, przynajmniej w znacznej częsci tych %.

[heby]

On 31/01/2020 08:35, Tomasz Kaczanowski wrote:
>> Przypomnij mi który obecnie używany i popularny kompilator C/C++
>> generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?
> a co to ma do rzeczy, jeśli musisz przystosować bibliotekę standardową
> do specyfiki nowego systemu?

A co to ma do rzeczy kiedy ta bibliteka wymaga przystosowania do
pozostałym dziesiątek języków programowania gdzie C++ jest tylko jednym
z wielu frontendów? I w dodatku w 95% ta bibliteka składa się z wywołań
C wiec musisz ją i tam napisać jeśli chcesz C.

Bibliteki std w C++ są w postaci kodu źródłowego i poza poprawą bugów i
zdefiniowaniem ile ma size_t wiele pracy nie wymagają.

>> Szczególnie jak odkrywasz że współczesne kompilatory to jakieś
>> frontendy, backedy, kody pośrednie, maszyny wirtualne itd itp ...
> tak... rozmawiamy o c i c++, czy językach korzystających z maszyn
> wirtualnych?

Rozmawiamy o maszynach wirtualnych w środku kompilatora.

Od prostych drzew, przez drzewa optymalizujące po wirtualną architekturę
rejkestrową albo stosową. Na samym końcu, naprawdę na samiuteńkim, lezy
sobie generator kodu do języka maszynowego danej architektury. To
śladowy element całości procesu kompilacji jeśli chcemy porównać
trudność pisania kompilatora.

Polecam nie bredzić tylko zainteresować się:

https://gcc.gnu.org/onlinedocs/gccint/index.html

(etapy pośrednie generacji kodu GENERIC, GIMPLE, RTL).

https://en.wikipedia.org/wiki/GNU_Compiler_Collection#GENERIC_and_GIMPLE

Oraz:

https://llvm.org/

Oczywiscie generowanie kodu pośredniego ma też przeciwników, np część
naukowców uważa że to jest niewydajna metoda:

https://www.youtube.com/watch?v=pP_zIJSp3WA

Ale jest też bardzo stara:

https://en.wikipedia.org/wiki/UNCOL

Innymi słowy, mój przyjacielu: dopisanie do gcc/llvm *nowej* platformy
sprowadza się do napisania backendu, który jest ułamkiem samego
kompilatora. A jak już go napiszesz do dostajesz w zasadzie za darmo
wsparcie dla *WSZYSTKICH* języków z fronendu. Do C i C++ tak samo
dostaniesz jak do Pascala którego nawet nie planowałeś.

Odpowiedź więc na pytanie: czy ciezko napisać C++ na nową platformę?
brzmi: prawie dokładnie tak samo ciezko jak do C.

[M.M.]

Ale pod jakim względem lepszy?

W C muszę:
1) Użyć programu zewnętrznego do wygenerowania wektora intów (lub innego typu).
2) Potem napisać:
#include "MyVectorInt.h"
.....
struct TMyVectorInt v;
int i;
TMyVectorInt_init( &v );
for( i=0 ; i<10 ; i++ ) {
TMyVectorInt_append( &v , rand() );
}
for( i=0 ; i<TMyVectorInt_size( &v ); i++ ) {
printf("%d\n" , (int)TMyVectorInt_get( &v , i ) );
}
TMyVectorInt_free( &v );


Tymczasem w C++ wystarczy:
#include <vector>
...........
using std;
vector<int> v;
for( int i=0 ; i<10 ; i++ ) {
v.append( rand() );
}
for( int i=0 ; i<10 ; i++ ) {
cout << v[i] << endl;
}

Oczywiście plik nagłówkowy vector nie powstał sam, ale program do
generyków w C też nie powstał sam. Poza tym tak jakby w tym
przykładzie w C++ 2-3 razy mniej kodu, a przejrzystość porównywalna?
Jeśli programista zapomni TMyVectorInt_free to ma wyciek, w C++ o
tym pamięta kompilator. Więc chyba nie jest lepszy pod względem
zwięzłości kodu?

> wiec to pytanie zakladajace ze to dziwne skoro jest lepszy sie dezaktualizuje?

Może trochę przegiąłem z formą tego pytania.

>
> nawiasem mowiac co do c/c++ ->
>
> niektorzy ludzie ktorzy pisza w c++ mysle nie wiedzą jak sie poprawnie pisze w c

Fakt, sam też już robię dużo sytnax error gdy używam kompilatora C.

> (a przynajmniej jak ja pisze) i wydaje im sie ze w c sie wiecej nameczą skoro nie ma vectora czy
> jeszcze kilku rzeczy ale fakty sa takie ze jak popisac w tym c to po nauczeniu sie jak to sie robi
> (co dla jako tako ogarnietego programisty nie zajmie strasznie duzo czasu) pozniej nie ma zadnych
> tego typu problemow

Chyba nie tylko moim zdaniem używanie bibliotek w C++ jest dużooooooo
łatwiejsze, ale projektowanie dobrego reużywlnego kodu w C++ jest
moim zdaniem dużo trudniejsze w C++.

> a zalety sa bardzo duze i sa takie (sam nie pisuje w c++ poza znajomsocia podstaw wiec moze nie wumienie wszystkich ;c )
>
> 1) nie ma babrania sie z szablonami i calym tym krapem (ktory jest totalnie bezsensowny) - kod jest
> prostszy szybszy (w czytaniu i pracy nad nim) ktrotszy, ladniejszy itd

Jeśli programista nie projektuje bibliotek szablonów, tylko ich używa, to programowanie z
użyciem szablonów nie jest aż tak uciążliwe aby nazwać je babraniem się. Jeśli projektuje
bibliotekę to owszem, praca z szablonami stanowi katorżniczy wysiłek, kod jest mniej
przejrzysty, trudniejszy w analizie i zwykle zawiera więcej błędów niż kod bez szablonów.
Ale w C++ można też tworzyć biblioteki bez szablonów, na zasadzie "C z klasami" - tyle że
wtedy efekt dla użytkownika nie bedzie tak wyśrubowany.

> 2) nie ma babrania sie z OOP (mniej wiecej jak wyzej)
> w szczegolnosci z rozmaitymi wskaznikami (kod jest prostszy szybszy itd..)

Ja w gołym C programowałem bardzo mocno obiektowo i kod innych programistów który
oglądałem też był mocno obiektowy. Natomiast zgodzę się, że zaprojektowanie dobrych
hierarchii klas często jest trudniejsze niż rozwiązanie problemu w sposób czysto
proceduralny. W C++ też często piszę proceduralnie, a przerobienie na klasy i
zoptymalizowanie przez szablony zostawiam na potem. Zgodzę się że rozwiązanie
problemu w oparciu o hierarchię klas może wolniej działać niż rozwiązanie
proceduralne.... No i pewnie w końcu ktoś zapyta: co to za programowanie w C++
bez szablonów i hierarchii klas? Cóż... dla mnie to też taki zubożony C++, a
nie normalny C++, bardziej podobne do C niż do pełnego C++. Czy to można nazwać
programowaniem w C++? Formalnie tak, ale jak spojrzę na kod i widzę tylko
procedry i struktury, to chce sie powiedzieć że to bardziej do C podobne.

> (zamist babrania sie z oop polecam staranna prace nad dll-kami i prawdziwym kodem)
> proponuje sprobowac, a jak nie to nie, wszystko mi jedno

Co to jest prawdziwy kod? Masz na myśli pisanie kodu do rozwiązania problemu, zamiast
szukania sub-optymalnej formy do wyrażanie tego za pomocy wielu fitczerów C++?
Jeśli tak, to popieram, ale potem reużywalność, refaktoryzacja, rozbudowa,
analiza - są trudniejsze.

> (zaznaczam przy tym gwoli formalnosci ze mimo ze na dzis umiem dosyc ok
> pisac w c, napisalem kilka rzeczy to nie mam zarazem super doswiadczenia w
> pisaniu tysiecy rzeczy zwlaszcza w trybie pisania "na ilosc" (a mniej w moim
> typowym trybie pisania dla sztuki ;c) ale akurat nie ma to zdaje sie
> kluczowego znaczenia bo c i tak bedzie lepsze.. klocic sie nie mam jednak
> zamiaru bo nie mam czasu na takie komiczne dyskusje)

No ale gołe C jest nawet bez międlenia nazw i trzeba pisać struct przed
nazwą typu w deklaracji zmiennej... Dosłownie w C bym nie chciał programować,
ale często, jakieś w miarę akceptowalne rozwiązanie, można naskrobać
w takim C++ który bardziej przypomina C.

Pozdrawiam

[M.M.]

Uważam w ogóle że oddzielenie kodu C++ od kodu maszynowego tak bardzo
utrudnia optymalizację, że w praktyce uniemożliwia przeprowadzenie
pewnych optymalizacji. Maszyna pośrednia by musiała wiedzieć coś o
kodzie C++, a to uniemożliwiłoby generowanie z innych języków do
maszyny pośredniej.

>
> Ale jest też bardzo stara:
>
> https://en.wikipedia.org/wiki/UNCOL
>
> Innymi słowy, mój przyjacielu: dopisanie do gcc/llvm *nowej* platformy
> sprowadza się do napisania backendu, który jest ułamkiem samego
> kompilatora. A jak już go napiszesz do dostajesz w zasadzie za darmo
> wsparcie dla *WSZYSTKICH* języków z fronendu. Do C i C++ tak samo
> dostaniesz jak do Pascala którego nawet nie planowałeś.
>
> Odpowiedź więc na pytanie: czy ciezko napisać C++ na nową platformę?
> brzmi: prawie dokładnie tak samo ciezko jak do C.

Pozdrawiam

[(fir)]

nie wiem co to za badziewie ale tak sie w c nie pisze

pisalem wlasnie otym ze wiekszosc programistow w c++ chyba nie uwmie pisac w c, to jest pewie z miesiac nauki wiec nie bede tu siedzial miesiaca i dawal tutoriali (tutoriali popawnego pisania w c) tym bardziej ze mozna sie tego naprawde samemu nauczyc

[heby]

On 31/01/2020 20:43, M.M. wrote:
> Uważam w ogóle że oddzielenie kodu C++ od kodu maszynowego tak bardzo
> utrudnia optymalizację, że w praktyce uniemożliwia przeprowadzenie
> pewnych optymalizacji.

Każdy kod pośredni daje gorsze wyniki niż kompilacja wprost
(teoretycznie). Każda kompilacja wprost jest trudniejsza niż kod pośredni.

Świat nie jest optymalny. Jest wystarczająco dobry.

Kompilacja wprost przy obecnych językach to by była katastrofa ponieważ
złożoność frontendu i backendu u jest absurdalna. Relaksujemy nieco
jakość i znajdujemy jakiś punkt w rozsądnej odległości od optimum przy
okazji dostając unifikacje bardzo ciezkiego kodu kopilatora,
odpowiedzielnego za optymalizacje.

> Maszyna pośrednia by musiała wiedzieć coś o
> kodzie C++, a to uniemożliwiłoby generowanie z innych języków do
> maszyny pośredniej.

I maszyna na niektórych etapach ma specyficzne dla danej plaformy
konstrukcje. Przykładowo wysokopoziomowe drzewo C++ ma specyficzną
konstrukcję co pozwala na propagacje pewnych cech C/C++ niżej do
następnej warstwy:

https://gcc.gnu.org/onlinedocs/gccint/C-and-C_002b_002b-Trees.html#C-and-C_002b_002b-Trees

Im niżej tym mniej wiadomo o fronendzie a więcej o backendzie.

[(fir)]

W dniu piątek, 31 stycznia 2020 20:46:51 UTC+1 użytkownik (fir) napisał:
> >
> nie wiem co to za badziewie ale tak sie w c nie pisze
>
> pisalem wlasnie otym ze wiekszosc programistow w c++ chyba nie uwmie pisac w c, to jest pewie z miesiac nauki wiec nie bede tu siedzial miesiaca i dawal tutoriali (tutoriali popawnego pisania w c) tym bardziej ze mozna sie tego naprawde samemu nauczyc

na ten koszmarek wyzej nie moge nawet patrzec, jak ja che w c miec cos w rodzaju wektora to pisze


void test39890830()
{
rchunk dipa;
dipa = ResizeChunk(dipa, 100);
dipa = ResizeChunk(dipa, 3000);
}

rchunk to struktora dwu wskaznikow,
pierwszy to wskaznik na ram na heapie dla realloca a drugi to wskaznik na ostatni bajt (mozna tez wersje wskaznik, size
zamiast wskaznik, wskaznik (byc moze nawet ta z size jest lepsza ale z powodow historycznych narazie na ogol uzywam wersji z dwoma wskaznikami)

caly kod to tego

typedef struct { char* beg,* end; } rchunk;

schunk ResizeChunk(rchunk x, int size)
{
x.beg = (char*) realloc(x.beg, size );
if((size>0) && (x.beg==NULL)) ERROR_EXIT("ResizeChunk failed");
x.end = x.beg + size - 1;
return x;
}


czyste mile (prawie ze genialne pod pewnymi wzgledami) c

nie trzeba sie babrac z zadnym stlowym krapem - no ale jak mowie styl w pisaniu w c sobie trzeba wypracowac

[M.M.]

Tzn jak się w C nie pisze? Nie pisze się bez międlenia nazw?

> pisalem wlasnie otym ze wiekszosc programistow w c++ chyba nie uwmie pisac w
> c, to jest pewie z miesiac

Zależy co kto już umie. Ja nic nie wie o komputerach i nie zna podstaw
matematyki, to z dwa lata mogą być mało.

> nauki wiec nie bede tu siedzial miesiaca i dawal
> tutoriali (tutoriali popawnego pisania w c) tym bardziej ze mozna sie tego
> naprawde samemu nauczyc

Nie wiem o czym piszesz, ja pisałem że w C++ jest międlenie nazw, a w C
tego nie ma, a to jest baaardzo wygodne.

Pozdrawiam

[heby]

On 31/01/2020 13:54, Maciek Godek wrote:
> Jednym z problemów, jaki mam z C++, dość dobrze opisał wcześniej Mateusz: że najpierw jest noga w drzwi ("po co w C, skoro jest C++, i wystarczy zamienić gcc na g++?"), a później równia pochyła ("no, to skoro już mamy C++ to użyjmy jeszcze przeciążania operatorów i skorzystajmy z tego, że preprocesor szablonów jest Turing-complete")

"Napierw używa się certyfikowanego kopilatora C żeby było bezpiecznie a
potem jest równia pochyła bo nagle cały zespół używa void* i
certyfikacja psu na budę."

Serio nie słyszałeś nigdy o jakiś podstawach inzynierii programowania,
standardach, pracy zespołowej, normach, specyfikacjach, coding
standardach, zabronionych konstrukcjach, wzorcach proejktowych, code
review? Serio, myślisz że przychodzi jakiś młody gniewny i rzuca jakaś
nową technologią i reszta to łyka?

> I finalnie wychodzi, że kod jest niespójny, bo jakaś młodzież zapragnęła wcisnąć jakieś nowe ficzery

A więc jednak na serio myślisz że to się tak odbywa ...

[M.M.]

On Friday, January 31, 2020 at 8:53:27 PM UTC+1, heby wrote:
> On 31/01/2020 20:43, M.M. wrote:
> > Uważam w ogóle że oddzielenie kodu C++ od kodu maszynowego tak bardzo
> > utrudnia optymalizację, że w praktyce uniemożliwia przeprowadzenie
> > pewnych optymalizacji.
>
> Każdy kod pośredni daje gorsze wyniki niż kompilacja wprost
> (teoretycznie). Każda kompilacja wprost jest trudniejsza niż kod pośredni.

Zgadzam się.

> Świat nie jest optymalny. Jest wystarczająco dobry.

Tego już nie wiem. Ale zazwyczaj każda optymalizacja jest optymalizacją
wielokryterialną, a jednym z kryteriów jest też czas napisania kompilatora, a
nie tylko jakość generowanego przez niego kodu.

> Kompilacja wprost przy obecnych językach to by była katastrofa ponieważ
> złożoność frontendu i backendu u jest absurdalna. Relaksujemy nieco
> jakość i znajdujemy jakiś punkt w rozsądnej odległości od optimum przy
> okazji dostając unifikacje bardzo ciezkiego kodu kopilatora,
> odpowiedzielnego za optymalizacje.

Tak, to bardzo rozsądne.

>
> > Maszyna pośrednia by musiała wiedzieć coś o
> > kodzie C++, a to uniemożliwiłoby generowanie z innych języków do
> > maszyny pośredniej.
>
> I maszyna na niektórych etapach ma specyficzne dla danej plaformy
> konstrukcje. Przykładowo wysokopoziomowe drzewo C++ ma specyficzną
> konstrukcję co pozwala na propagacje pewnych cech C/C++ niżej do
> następnej warstwy:

Nie wiedziałem, to faktycznie poszerza możliwości optymalizacji kodu
wynikowego.

> https://gcc.gnu.org/onlinedocs/gccint/C-and-C_002b_002b-Trees.html#C-and-C_002b_002b-Trees
>
> Im niżej tym mniej wiadomo o fronendzie a więcej o backendzie.

Nie znam zagadnienia, ale logika tak właśnie podpowiada.


Pozdrawiam

[heby]

On 31/01/2020 21:09, M.M. wrote:
>> Świat nie jest optymalny. Jest wystarczająco dobry.
> Tego już nie wiem. Ale zazwyczaj każda optymalizacja jest optymalizacją
> wielokryterialną, a jednym z kryteriów jest też czas napisania kompilatora, a
> nie tylko jakość generowanego przez niego kodu.

I w efekcie opłaca się pisać nieoptymalne kompilatory, ale rózniące się
tylko o promile od optimum, za to pisać je 100x szybciej (sprawdzić czy
to nie gcc).

LLVM powstał praktycznie w mgnieniu oka tylko dlatego że dobrał
*sensowny* kod pośredni i sensowne abstrakcje. Kiedy gcc miotało się w
dziesiątkach lat legacy kodu o żałosnej jakości LLVM przyszedł i pozamiatał.

[(fir)]

W dniu piątek, 31 stycznia 2020 21:05:03 UTC+1 użytkownik M.M. napisał:
>
> Tzn jak się w C nie pisze? Nie pisze się bez międlenia nazw?
>

a co to jest miedlenie nazw? manglowanie?

w c sie pisze tak by kod byl logiczny
ladny, z dobrymi opisowymi nazwami, podzielony na schludne pliki a pliki by byly pogrupowane w kody sluzace do robienia sensownych dll-ek

genarelnei w c sie pisze tak by kod byl ladny to wyzej to jakis potworek wiec tak sie w c nie pisze..tzreba wiedziec co sie ma w c do dspozycji i tak napisac by to bylo proste i ladne

nieststy jak mowie to wymaga pewnie z miesiaca pisania jak ktos juz umie kodowac dobrze np w c++, bo trzeba sobie
wypracowac podstawowe srodowiskko, zwyczaje, konwencje, ew znalezc ulubione libki (by to dobrze wypracowac wiadomo ze moze i zejsc ponad rok.. mi samemu anuczenie sie jako takiego kodowania w c zajelo duzo wiecej (praeie 10 lat ale to bylo nie tylko uczenie sie c ale programowania roznych rzeczy w ogole)

[Mateusz Viste]

2020-01-31 o 21:07 +0100, heby napisał:
> Serio nie słyszałeś nigdy o jakiś podstawach inzynierii
> programowania, standardach, pracy zespołowej, normach,
> specyfikacjach, coding standardach, zabronionych konstrukcjach,
> wzorcach proejktowych, code review?

To w dużych i poważnych korpo, które rzucają pieniędzmi na prawo i lewo.

Ale tak, jak nie każdemu pasuje C++, tak samo nie każdy ma ochotę kisić
się w korpo. W zdrowym startupie kod ma być na wczoraj, ma działać na
tyle dobrze żeby klient się nie zorientował że są bugi, a jeśli już coś
się skitłasi to z marszu musi to naprawić na produkcji ktokolwiek, kto
akurat jest pod ręką.

> A więc jednak na serio myślisz że to się tak odbywa ...

Zależy gdzie. Ale tak - odbywa się.

Mateusz

[(fir)]

pozatym sorki za lekkie rozdraznienie ale od takich dyskusji mijaja godziny pozytek moze i jakis jest ale mialem inne plany na wieczór, chocby poogladanie jakiegos filmu (czyt tam dzisiejszego meczu G2 w lola) - dlatego lekko drazni mnie jak ktos zadaje mi pytania, ja nie che byc zbyt nieuprzejmy ale zarazem nie mam az tyle czasu by odpowiadac rozwlekle na pytania jak sie pisze w c ..kodow w c jst duzo, sam nie oglada wiekszej ilosci kodow innych ludzi ale generalnie programisci w c pisza jako tako ladne kody i mozna zobaczyc jak to sie z grubsza robi (co prawda sporo robi pewne bledy np uzywaja zlych zbyt krotkich nazw, uklad procedur czy plikow tez pozsotawia czesto sporo do zyczenia itd...ale ogoleni c to c czyli w pewnym sensie synonim jakosci

[heby]

On 31/01/2020 21:34, Mateusz Viste wrote:
>> A więc jednak na serio myślisz że to się tak odbywa ...
> Zależy gdzie. Ale tak - odbywa się.

Dlatego sugerowałbym nie pokazywać patologii jako normy. Patologie
istnieją tak samo w C++ jak i w C. I odpowiada za nie głównie białko a
nie język.

[Mateusz Viste]

2020-01-31 o 21:51 +0100, heby napisał:
> Dlatego sugerowałbym nie pokazywać patologii jako normy.

To niekoniecznie patologia. Tzn. z punktu programisty, który poza kodem
niczego nie widzi, to może i jest - ale taki lamentuje kilka tygodni,
że "nie mam czasu sobie porefaktoryzować", "to nie moja wina że robię
błędy, to CI nie wychwyciło" itp. A potem się zwalnia i idzie do korpo,
gdzie będzie mógł masturbować się z kolegami nad wirtualnymi funkcjami,
wielodziedziczeniem, lambdą czy innym polimorfizmem. W startupie nie ma
czasu na takie rozmyślania - ma być szybko i skutecznie, coby
handlowiec mógł zafakturować i szukać następnego klienta.

> Patologie istnieją tak samo w C++ jak i w C. I odpowiada za nie
> głównie białko a nie język.

W 100% się zgadzam. Niestety tego "białka" nie da się wyeliminować,
więc póki co trzeba działać w taki sposób, by to białko było możliwie
łatwo wymienialne i robiło możliwie jak najmniej szkód. Trzymanie się C
to nie jest panaceum, ale z braku laku może być prostym i tanim sposobem
na utrzymanie jako takiej spójności i zapewnienie że każdy ziom z
zespołu będzie w stanie ogarnąć co i jak, jeśli na niego trafi pilny
core dump do zdiagnozowania.

Mateusz

[Maciek Godek]

W dniu piątek, 31 stycznia 2020 21:07:02 UTC+1 użytkownik heby napisał:

> > I finalnie wychodzi, że kod jest niespójny, bo jakaś młodzież zapragnęła wcisnąć jakieś nowe ficzery
>
> A więc jednak na serio myślisz że to się tak odbywa ...

Nie jest tak, że "myślę, że to się tak odbywa".
Jest tak, że widzałem, że to się tak odbywa.
W poważnych międzynarodowych firmach technologicznych.

Przy okazji, co z tymi linkami?
Czy udostępnianie źródeł do artykułów, które potwierdziłyby Twoje teorie dotyczące "pure coroutines", też jest poniżej godności, tak jak ilustrowanie kodem potencjalnych problemów, które mogą się pojawić w kodzie przy stosowaniu takich czy innych rozwiązań?

[heby]

On 31/01/2020 22:28, Maciek Godek wrote:
> Nie jest tak, że "myślę, że to się tak odbywa".
> Jest tak, że widzałem, że to się tak odbywa.
> W poważnych międzynarodowych firmach technologicznych.

I dlatego to wszystko wina C++ a RAII powoduje autyzm.

> Przy okazji, co z tymi linkami?

Jakimi linkami?

> Czy udostępnianie źródeł do artykułów, które potwierdziłyby Twoje teorie

Udostępniłem Ci artykuł na Wiki gdzie kilku ważnych ludzi umarło ze
śmiechu na widok jeszcze jednego kwadratowego koła z
switch/case/__LINE__. Naprawdę nie jesteś ani pierwszy ani ostatni. Ale
bronisz tego chorego pomysłu jak niepodległości bo przecież nie może być
tak że to obiektywne g. Ojczyzna potrzebuje takich.

https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

[Maciek Godek]

W dniu piątek, 31 stycznia 2020 22:40:46 UTC+1 użytkownik heby napisał:
> On 31/01/2020 22:28, Maciek Godek wrote:
> > Nie jest tak, że "myślę, że to się tak odbywa".
> > Jest tak, że widzałem, że to się tak odbywa.
> > W poważnych międzynarodowych firmach technologicznych.
>
> I dlatego to wszystko wina C++ a RAII powoduje autyzm.
>
> > Przy okazji, co z tymi linkami?
>
> Jakimi linkami?

Napisałeś tak:
> Radze poczytać internety w kwesti co to jest pure.
>
> Korutyna to nie jest funkcja w rozumieniu "pure function" ale moze byc
> "pure coroutine".

No, to ja czekam na linki do tych internetów.

> > Czy udostępnianie źródeł do artykułów, które potwierdziłyby Twoje teorie
>
> Udostępniłem Ci artykuł na Wiki gdzie kilku ważnych ludzi umarło ze
> śmiechu na widok jeszcze jednego kwadratowego koła z
> switch/case/__LINE__.

No, "umarło ze śmiechu" to chyba nie.
Dokładny kontekst, z którego pochodzi podany przez Ciebie cytat, jest właśnie na tej stronie, do której linkujesz poniżej. I brzmi on w pełnej okazałości tak:

"PuTTY is a Win32 Telnet and SSH client. The SSH protocol code contains real-life use of this coroutine trick. As far as I know, this is the worst piece of C hackery ever seen in serious production code."

Autorem cytatu jest jednocześnie autor programu PuTTY.
Czyli "umiera ze śmiechu", jednocześnie korzystając z tego rozwiązania.

> Naprawdę nie jesteś ani pierwszy ani ostatni. Ale
> bronisz tego chorego pomysłu jak niepodległości bo przecież nie może być
> tak że to obiektywne g. Ojczyzna potrzebuje takich.

Nie "bronię tego chorego pomysłu jak niepodległości". Podzieliłem się tym pomysłem, gdyby ktoś miał ochotę z niego skorzystać. W kontekście problemów, z którymi w ostatnim czasie się zmagałem, jest użyteczny (i to bardziej użyteczny, niż bardziej ogólne rozwiązania, które proponowałeś).

Ale ma swoje ograniczenia (jak zresztą wszystko).

W każdym razie nie o to pytam. Pytam o "pure coroutine".
Bo na Wiki nic o tym nie ma.

[(fir)]

W dniu piątek, 31 stycznia 2020 21:03:04 UTC+1 użytkownik (fir) napisał:
> W dniu piątek, 31 stycznia 2020 20:46:51 UTC+1 użytkownik (fir) napisał:
> > >
> > nie wiem co to za badziewie ale tak sie w c nie pisze
> >
> > pisalem wlasnie otym ze wiekszosc programistow w c++ chyba nie uwmie pisac w c, to jest pewie z miesiac nauki wiec nie bede tu siedzial miesiaca i dawal tutoriali (tutoriali popawnego pisania w c) tym bardziej ze mozna sie tego naprawde samemu nauczyc
>
>
>
>
> na ten koszmarek wyzej nie moge nawet patrzec, jak ja che w c miec cos w rodzaju wektora to pisze
>
>
> void test39890830()
> {
> rchunk dipa;
> dipa = ResizeChunk(dipa, 100);
> dipa = ResizeChunk(dipa, 3000);
> }
>
> rchunk to struktora dwu wskaznikow,
> pierwszy to wskaznik na ram na heapie dla realloca a drugi to wskaznik na ostatni bajt (mozna tez wersje wskaznik, size
> zamiast wskaznik, wskaznik (byc moze nawet ta z size jest lepsza ale z powodow historycznych narazie na ogol uzywam wersji z dwoma wskaznikami)
>
> caly kod to tego
>
> typedef struct { char* beg,* end; } rchunk;
>
> schunk ResizeChunk(rchunk x, int size)
> {
> x.beg = (char*) realloc(x.beg, size );
> if((size>0) && (x.beg==NULL)) ERROR_EXIT("ResizeChunk failed");
> x.end = x.beg + size - 1;
> return x;
> }
>

i co? zaden komentarz co do zestawienia tego kawalka w c (ktory sam wymyslilem i na podobnych pomyclach oparlem cala moja biblioteke do tekstow sickle.c) vs c++ owy stlowy crap?

tam wyzej oczywiscie w uzywaniu tego lepiej dodac static, by ten reallocowy seed sie nie gubil wtedy nie bedzie wyciekow, ew trzebby przed wykjsciem z funkci resizowac do zera

[(fir)]

moze jeszce dodam slowo o wymyslaniu kola od nowa, to jeden z ulubionych tekstow rozmaitych durni /durniow

prawda jest taka ze jak ktos sie na czyms zna i che zrobic pewne rzeczy naprawde dobrze (nie tylko w programowaniu, zapewne i w muzyce, w mechanice czy prawdopodobnie w czymkolwiek innym) to musi wymyslec ta rzecz od nowa, wymyslic kolo od nowa poprostu po to by to doglebi zrozumiec, odnowic w sobie prawdziwa jakosc rozumienia

tymzasem rozliczni durnie powtarzaja te kawalki o wymyslaniu kola chyba glownie po to by obronic sie przed mozliwoscia zrozumienia ronych rzeczy i nauczeia ich sie robic dobrze - czyli zalatwiaja sobie jakby patent na bycie wiecznymi patałachami

(sork ze uzywam mocnych slow ale ostatnio jestem chyba lekko bardziej rozdrazniony a juz jakis czas temu zaczalem tracic cierpliwosc dla bredni roznych gluptakow ;, )

[M.M.]

Nie wiem jaka jest prawda, nie mam dostępu do stosownych danych aby
wyciągnąć rzetelne wnioski. Ale myślę sobie tak... Jak ktoś cokolwiek
programuje, to podstawy logiki i matematyki musi mieć ogarnięte, a to
wymaga pewnego poziomu intelektualnego. Jak używa języka programowania w
którym jest arytmetyka wskaźników i sporo ryzykownych elementów, i do tego
jak radzi sobie, to też wskazuje na jego jakiś sensowny poziom intelektualny.
I taka osoba nieracjonalnie wybiera gorszy język programowania... Coś mi
tutaj nie pasuje.

Pozdrawiam

[heby]

On 01/02/2020 05:20, M.M. wrote:
> wymaga pewnego poziomu intelektualnego. Jak używa języka programowania w
> którym jest arytmetyka wskaźników i sporo ryzykownych elementów, i do tego
> jak radzi sobie, to też wskazuje na jego jakiś sensowny poziom intelektualny.
> I taka osoba nieracjonalnie wybiera gorszy język programowania... Coś mi
> tutaj nie pasuje.

Poziom intelektu nie wiele wspólnego z racjonalnymi wyborami.
Przeceniasz siłe logiki w podejmowaniu decyzji.


Przykład: firma robi sterowniki. Tak nie za trudne, jakieś wejścia,
jakieś sterowanie, ogólnie nic skomplikowanego. Wybrali PICa, pod koniec
lat 90. Nie był to zły wybór.

Pech chce że projekt ewoluuje. W następnych wersjach wymagają obliczeń.
Takich raczej męczących dla CPU. Dodatkowo okazuje się że muszą ogarniać
już system RT bo obliczeń duzo, zdarzeń dużo i zaczyna brakować czasu CPU.

Wydawało by się że sensowne jest przejscie na szybszy procesor.

Rzeczywistośc wygląda tak że od kilkudziesięciu lat siedzą dalej na
PICach. Tych samych. Prawie tych samych, one są już na wylocie i z
którymi jest kłopot z zakupem bo są nieprodukowane lub produkcja się
kończy. Dlaczego? "Jak działa to nie ruszaj". W rzeczywistości mają
kolosalny dług technologiczny bo rozwijali soft w asemblerze i tylko
dorabiają idiotyczne wiejskie powiedzonka żeby to jakoś usprawiedliwić.

Problem w tym że tak naprawdę nie działa i muszę ruszać bo za chwile ich
nie kupią. Ale nowych ich nie kupią bo mają asembler. Wybór języka
okazał się być dead end projektu.

To taki przykład "na gorąco" jak wygląda dynamika dostosowania się do
zmian. I używanie logiki przez ludzi naprawdę dobrze rozumiejących
arytmetykę wskaźnikową. Jeden z tych ludziów zapytał mnie co mogą
zrobić. O 20 lat za późno. Pytam o powody tego asm do dzisiaj i dlaczego
PICe. "Kolega znał tośmy wybrali". Przypuszczam że ten "kolega" nie
potrzebował już asemblera po 20 latach pracy, pisał wprost binarnie kod.

Rozmawiamy o małej firmie która miała możliwość w ciągu tych 20 lat
posprzątania. Tymczasem doskonalili się w produkcji gówna void* w asm i
wylądowali tam gdzie każdy taki projekt czyli na śmietniku.

Potwarzam, intelekt praktycznie nic nie ma wspólnego z mądrością
wyborów. Decydują czynniki pochodzące czysto z biologii. Mechanizmy, czy
to duże korpo czy mała firemka, podobne.

[Piotr Gałka]

W dniu 2020-02-01 o 09:07, heby pisze:

> Przykład: firma robi sterowniki. Tak nie za trudne, jakieś wejścia,
> jakieś sterowanie, ogólnie nic skomplikowanego. Wybrali PICa, pod koniec
> lat 90. Nie był to zły wybór.

Jesteśmy malutką firmą.
Na początku lat 90-tych klient zamówił opracowanie urządzenia
dostarczając nam narzędzia do PICa (programator produkcji Microchipa,
rozmiaru prawie A4 z wymiennymi modułami do różnych obudów). Na potrzeby
projektu mieliśmy 10 szt PICów. Pierwsze 5 spaliliśmy bo ten ich
programator włączając VPP między stanem początkowym 5V a końcowym 21V
przechodził po drodze przez 45V. Zwykłe blank-check zabijało scalak.
Po namierzeniu problemu i zmodyfikowaniu tego programatora natknęliśmy
się następnie na 3 różne błędy w PICu. Dwa udało nam się obejść, ale
trzeci nas rozłożył. Według naszych pomiarów procesor przegapiał mniej
więcej jedno na 3000 zboczy które miały dawać przerwanie, a odbieranie
tych przerwań to była kluczowa sprawa.
Wysyłaliśmy faxy do Microchipa - bez odpowiedzi. Jakiś rok później
odbyło się pierwsze seminarium Microchipa w W-wie. Tam obiecali, że
przyślą nam erratę. Półtora miesiąca później dostaliśmy faxem tę erratę
- zawierała 6 błędów (w tym te 3 które sami odkryliśmy). Aby obejść ten,
który nas rozłożył proponowali dołożenie zewnętrznego układu
synchronizującego zbocza przerwań z zegarem procka.
Gdybyśmy to wiedzieli przed projektem płytki....

Nasza decyzja - nigdy więcej PICów.

> Rzeczywistośc wygląda tak że od kilkudziesięciu lat siedzą dalej na
> PICach.

Siedzimy od wielu lat na Xmegach.

> W rzeczywistości mają
> kolosalny dług technologiczny bo rozwijali soft w asemblerze....

> Pytam o powody tego asm do dzisiaj

Bootloader mamy w assemblerze.
Nigdy nie programowałem mikrokontrolerów i żaden z nas nie jest
wykształconym programistą. Z tego co brat mi mówi to on nie widzi
możliwości napisania efektywnego SHA256 na Xmega w C. O ile pamiętam
(rozmowa była z 5 lat temu) to problem polega na tym, że C zabiera z
definicji kilka rejestrów i brakuje dla przechowywania stanu SHA256. A
ciągłe przerzucanie danych między rejestrami a RAMem kilkukrotnie
spowalnia obliczenia.

> i dlaczego PICe.

Z mojego punktu widzenia (projektuję schematy/płytki) Xmegi są na prawdę
fajne. 7 UARTów, 3 SPI, 2 I2C, 16 wejść analogowych, przerwania z każdej
nogi pozwala mi zawsze tak podłączyć peryferia abym nie musiał korzystać
z drugiej strony płytki dla ścieżek sygnałowych.

> Potwarzam, intelekt praktycznie nic nie ma wspólnego z mądrością
> wyborów. Decydują czynniki pochodzące czysto z biologii. Mechanizmy, czy
> to duże korpo czy mała firemka, podobne.

Sugerujesz jakoby decyzje były głównie na zasadzie 'przyzwyczajenie'.
Ja to widzę inaczej.
Prawie przy każdym kolejnym projekcie zastanawiamy się, czy stać nas
przy tej okazji na skok technologiczny, co spowoduje opóźnienie go
szacunkowo o pół roku. Nasze doświadczenie nam mówi, że jak się nam
wydaje, że coś nam zajmie t to zazwyczaj zajmuje 3t.
No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na
wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy
jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż
znajdziemy na to czas.
P.G.

[(fir)]

no taka jest realnosc firm, ale szczerze mowiac, ona nie jest dobra..

a czy ta firma lub takie firmy nie zarabiaja na tyle wystarczajao zeby moc poswiecic 20-30% czasu na rozwoj/research ? (zwlaszcza jesli to jest sensowny potrzebny research a nie siedzenie przy kompie i ogladanie netu)..?

[Maciek Godek]

W dniu piątek, 31 stycznia 2020 22:28:22 UTC+1 użytkownik Maciek Godek napisał:
> W dniu piątek, 31 stycznia 2020 21:07:02 UTC+1 użytkownik heby napisał:
>
> > > I finalnie wychodzi, że kod jest niespójny, bo jakaś młodzież zapragnęła wcisnąć jakieś nowe ficzery
> >
> > A więc jednak na serio myślisz że to się tak odbywa ...
>
> Nie jest tak, że "myślę, że to się tak odbywa".
> Jest tak, że widzałem, że to się tak odbywa.
> W poważnych międzynarodowych firmach technologicznych.

Nota bene, niektóre duże firmy nawet całkiem otwarcie chwalą się jakością kodu, którą uzyskali dzięki użyciu C++ do swoich projektów:

https://www.youtube.com/watch?v=rHIkrotSwcc

[M.M.]

On Saturday, February 1, 2020 at 1:04:30 PM UTC+1, Piotr Gałka wrote:

> Sugerujesz jakoby decyzje były głównie na zasadzie 'przyzwyczajenie'.
> Ja to widzę inaczej.
> Prawie przy każdym kolejnym projekcie zastanawiamy się, czy stać nas
> przy tej okazji na skok technologiczny, co spowoduje opóźnienie go
> szacunkowo o pół roku.

Ja to powyżej w swoich kilku wypowiedziach nazwałem, może trochę 
błędnie, kosztem szkolenia.

> Nasze doświadczenie nam mówi, że jak się nam
> wydaje, że coś nam zajmie t to zazwyczaj zajmuje 3t.

3t przy skoku technologicznym to raczej bardzo optymistyczny scenariusz, 3t
i 5t w inżynierii oprogramowania zdarza się przy znanej technologii.

> No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na
> wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
> Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy
> jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż
> znajdziemy na to czas.

A jakby kogoś zatrudnić, albo wynająć z zewnętrznej firmy, kto ma wyczucie
kompilatora C++ i mniej/więcej wie jak zaimplementować, albo jakie
eksperymenty przeprowadzić, aby uzyskać dany efekt? W niektórych firmach
odpowiadali mi, że głównym problemem jest ryzyko z wdrażania nowej osoby. Co u
Was uniemożliwia zwerbowanie dodatkowych mocy przerobowych - jeśli mogę spytać?

Pozdrawiam

[Tomasz Kaczanowski]

W dniu 2020-01-31 o 20:33, heby pisze:

> On 31/01/2020 08:35, Tomasz Kaczanowski wrote:
>>> Przypomnij mi który obecnie używany i popularny kompilator C/C++
>>> generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?
>> a co to ma do rzeczy, jeśli musisz przystosować bibliotekę standardową
>> do specyfiki nowego systemu?
>
> A co to ma do rzeczy kiedy ta bibliteka wymaga przystosowania do
> pozostałym dziesiątek języków programowania gdzie C++ jest tylko jednym
> z wielu frontendów? I w dodatku w 95% ta bibliteka składa się z wywołań
> C wiec musisz ją i tam napisać jeśli chcesz C.
>
> Bibliteki std w C++ są w postaci kodu źródłowego i poza poprawą bugów i
> zdefiniowaniem ile ma size_t wiele pracy nie wymagają.

Powiem tak, nie wiem, nie ja przystosowywałem kompilatory, a pracowałem
kilka lat temu przy tym. O ile kompilator C dało się zrobić bardzo
szybko, to kompilator C++ (trochę tez przez brak czasu osoby tym się
zajmującej, ale i powstające problemy, bo jednak kod wynikowy był z
niewiadomych przyczyn niestabilny, możliwe że chodziło o zarządzanie
pamięcią, nie wiem, nie zajmowałem się tym, mogę stwierdzić tylko na
podstawie tego, że jednak nie było to ot pstryknięcie palcami) powstał
jak odchodziłem z firmy i był wciąż eksperymentalny i tylko uzywany do
testów, ze względu właśnie na brak stabilności kodów wynikowych.

Więc jak to jest takie pstryknięcie palcami to fajnie, pewnie na wielu
platformach tak jest, przynajmniej tych popularnych, ale nie zawsze z
takich się korzysta i tu koszt jest dużo wyższy.

--
http://kaczus.ppa.pl

[Piotr Gałka]

W dniu 2020-02-02 o 00:00, M.M. pisze:

>> No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na
>> wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
>> Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy
>> jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż
>> znajdziemy na to czas.
>
> A jakby kogoś zatrudnić, albo wynająć z zewnętrznej firmy, kto ma wyczucie
> kompilatora C++

Chyba nie zdajesz sobie sprawy ile to by było komplikacji na wstępie i
później jakby trzeba było coś w tym poprawić.

C++ uczyłem się w 92 z ksera oryginału książki Stroustrupa. Jak w 93
ukazało się polskie tłumaczenie przeczytałem jeszcze raz.
Na tej podstawie napisałem w C++ makro assembler'51 i coś mnie podkusiło
(ambicja), że koniecznie muszę go przerobić na jednoprzebiegowy (nie
załapałem, że to miało sens gdy źródło było na tasiemce perforowanej a
gdy źródło jest na HDD to co za problem przeczytać kod jeszcze raz).
Konieczność przechowania różnych danych do drugiego przebiegu zjadała
pamięć i natknąłem się na problemy przy dłuższych źródłach (PC miał 640k
RAMu). Przeciążenie operatora new pozwoliło mi wydłużyć assemblowane
źródło 2x.
Dopóki używaliśmy 51-ki brat korzystał wyłącznie z mojego assemblera bo
inne się wykładały na wyliczeniach danych do ustawiania UARTa z
częstotliwości zastosowanego kwarca (liczyły na 16 bitach a ja na 32).

Uważam, że mam wyczucie C++ (w wersji z tamtych czasów), ale
programowaniem zajmuję się tydzień/dwa w roku więc ... nie nadążam za
nowymi standardami. Poza tym używam nadal głównie C++ Buildera 5 (on też
nie nadąża :) ).
Mam też Buildera 2010. Pewnie bym się przeniósł gdyby nie jego fjuczer -
tylko raz daje się uruchomić po jednym resecie komputera. Znalazłem w
sieci jakieś obejścia do tego, ale nie miałem wystarczającej presji aby
je wdrażać.

W związku z treścią dyskusji właśnie przeszukałem wszystkie moje *.h w
poszukiwaniu void* i wyskoczył mi tylko ten mój assembler z 1996r.
Pewnie przeciążenie operatora new tego wymagało.

Nigdy nie nauczyłem się korzystać z zewnętrznych bibliotek.
AES, CMAC, HMAC, SHA napisałem sobie sam (w C++).
Moje źródło zawierające:
- CRC32,
- AES128,
- AES256,
- szyfrowanie tymi AES w trybie CTR (counter),
- CMAC,
- SHA256,
to jedynie 87 linijek h i 268 liniej cpp (ale może nie być przenoszalne
do środowiska o odwrotnym ułożeniu bajtów, choć nie jestem tego pewien).
Jakby ktoś chciał mogę zapodać.

> i mniej/więcej wie jak zaimplementować, albo jakie
> eksperymenty przeprowadzić, aby uzyskać dany efekt?

Każdy nasz program wymaga ciągłego rozwoju, a czasem natychmiastowej
interwencji (zdarzało nam się siedzieć w pracy do 4-ej rano).
Musiałby to być ktoś na stałe i o takiej samej dyspozycyjności jak my.

> W niektórych firmach
> odpowiadali mi, że głównym problemem jest ryzyko z wdrażania nowej osoby.

Ryzyko i czas, czas, czas.

> Co u Was uniemożliwia zwerbowanie dodatkowych mocy przerobowych - jeśli mogę spytać?

Dzień wolności podatkowej, który w Polsce przypada pod koniec czerwca, a
w USA w połowie kwietnia. To jest czynnik, który tam pozwala małym
firmom się rozwijać, a u nas je zabija.

Poza tym nie jesteśmy pełną gębą biznesmenami i bycie człowiekiem
stawiamy wyżej od rachunku ekonomicznego (pracownikom od montażu zawsze
płaciliśmy bliżej średniej niż minimalnej).
Kryzys 2008 dopadł nas w 2010 (i trzymał do 2015). Biorąc kolejne
kredyty udało nam się nie zwolnić żadnego pracownika choć nie mieliśmy
dla nich roboty. Jeszcze się nie wygrzebaliśmy, a tu już się szykuje
kolejny kryzys :(

Poza tym.
Nasze dotychczasowe kontakty z firmami ściśle softwareowymi każą nam
przyjmować, że większość programistów nie umie myśleć o ograniczeniach
sprzętu.

Przykład z ostatniego miesiąca.
Brat coś grzebie w kontrolerze korzystając po stronie PC z
oprogramowania jednej z takich firm. Coś zmienia w ustawieniu kart i
klika jakiś przycisk w stylu "Uaktualnij dane w kontrolerze". W
kontrolerze ma 5 kart więc uaktualnienie to powinny być jakieś ms więc
od razu sprawdza, czy działa - nie działa to klika jeszcze raz i jeszcze
raz. Na ekranie żadnej informacji, że trwa jakiś proces więc wydaje się,
że program uważa, że zrobił co trzeba. Przyczyną nie było to co napiszę
dalej ale przy okazji prześledzenie komunikacji ujawniło, że oni w
takiej sytuacji zamiast wysłać 2 rozkazy:
- wpisz te 5 kart,
- wykasuj karty od 6 do 32000.
robią:
- usuń kartę 1,
- wpisz kartę 1,
....
-usuń kartę 32000,
-wpisz puste dane dla karty 32000.
I kolejne naciśnięcia klawisza wstawiały w kolejkę kolejne takie procesy.

To jakaś kpina.
Rozkaz wpisz karty, gdy dane są zgodne z zawartością nie zużywa flasha
bo najpierw jest sprawdzane, czy dane są zgodne.
Rozkaz wpisujący wszystkie karty danej strony wymaga tylko jednokrotnego
jej przeprogramowania.
Ale rozkaz skasuj kartę (która jest) wymaga przeprogramowania strony
flash. Potem wpisanie tych samych danych w to samo miejsce - znów.
Nie wiem ile kart jest na stronie, ale jeśli np 30 to taka procedura
powoduje konieczność 60 krotnego przeprogramowania flash (zamiast
średnio 0.5 raza (0 lub 1 raz)).
Kontroler, który załóżmy powinien przeżyć 30 lat, zużyje się 120 razy
szybciej - czyli po 3 miesiącach.
Gdybym nie wiedział, że głupota pomyślałbym, że sabotaż.

Pomysł 'my robimy hardware' firma softwareowa robi oprogramowanie na PC
(bo zrobi to na pewno lepiej od nas) mieliśmy w okolicy +- 1997.
Przepytaliśmy pod tym kątem wszystkie firmy softwareowe na Infosystemie
- absolutne zero zainteresowania. Nie chcieli bawić się z hardware.
Pisali wtedy programy typu kosztorysowanie budowlanki, czy zarządzanie
aptekami - więc pomysł upadł.

W okolicy 2014 zgłosiło się da nas kilka firm softwareowych, że chcieli
by mieć sprzętową kontrolę dostępu, rejestrację czasu pracy, czy podobne
zagadnienia dobrze zintegrowane z ich oprogramowaniem.
Opracowaliśmy więc system pod takim kontem.
Współpracę utrudnia to, że o komunikacji rozmawiamy innymi językami :)
Oni mają problem się dostosować do nas, a my nie jesteśmy w stanie się
dostosować do nich.

A to, że jesteśmy nadal w Xmega a nie w jakimś linuxie to ....
Firma przeprowadzająca audyt bezpieczeństwa nie była w stanie w żaden
sposób się wpiąć w naszego RS485, czy dobrać do komunikacji z serwerem.
Jedyne co zasugerowali to zablokowanie strony www kontrolera po
instalacji bo np. ataki przez przepełnienie bufora.
Odpisaliśmy, że z tego co wiemy to taki atak może być skuteczny tylko,
gdy program jest wykonywany z RAMu - więc nie u nas. Nie wiem, czy
blokujemy to www, czy nie - to brat pisze.
P.G.

[(fir)]

to szkoda ze tak malo zarabiecie.. o ile dzis programistom placi sie przyzwoicie to wgladaloby ze i firmom powinno sie plaic przyzwoicie, wiec to troche chyab dziwi ze tak kiepsko w takim biznesie

[Piotr Gałka]

W dniu 2020-02-03 o 16:49, (fir) pisze:

>
> to szkoda ze tak malo zarabiecie.

Też tak myślę :)
Ale lubię robić to co robię.

Produkcja sprzętu to w pewnym sensie konkurowanie z chińczykami :(

> . o ile dzis programistom placi sie przyzwoicie to wgladaloby ze i firmom powinno sie plaic przyzwoicie, wiec to troche chyab dziwi ze tak kiepsko w takim biznesie

Bo trzeba być firmą z kapitałem i prowadzić bezwzględnie biznes i to w
dużej skali.
A my 'kapitał zakładowy' gromadziliśmy z naszych pensji wynoszących
rzędu 13$ :(.

Gdyby Dzień Wolności Podatkowej był ze 2 miesiące wcześniej to przez te
30 lat moglibyśmy się rozwinąć, a tak to ..... piiiip.
P.G.