🚀 go-pugleaf

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?

W dniu piątek, 24 stycznia 2020 20:44:01 UTC+1 użytkownik Borneq napisał:
> 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?

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.

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.

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

W dniu niedziela, 26 stycznia 2020 15:43:22 UTC+1 użytkownik heby napisał:
> 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

?

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

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.

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

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.

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.

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.

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.

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.

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.

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

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

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

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

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.

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

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.

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

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.

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.

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

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.

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

W dniu piątek, 31 stycznia 2020 01:44:05 UTC+1 użytkownik (fir) napisał:
> 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)...

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

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

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

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)

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. 


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
    

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}

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

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

W dniu piątek, 31 stycznia 2020 14:17:46 UTC+1 użytkownik Mateusz Viste napisał:
> 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".

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

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"

W dniu piątek, 31 stycznia 2020 16:19:57 UTC+1 użytkownik (fir) napisał:
> 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"


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)

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?

Pozdrawiam

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?

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)

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

W dniu piątek, 31 stycznia 2020 18:35:58 UTC+1 użytkownik M.M. napisał:
> 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?
> 

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)

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

On Friday, January 31, 2020 at 7:28:45 PM UTC+1, (fir) wrote:
> W dniu piątek, 31 stycznia 2020 18:35:58 UTC+1 użytkownik M.M. napisał:
> > 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?
> > 
> 
> bo nie jest lepszy? 

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

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

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

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)

W dniu piątek, 31 stycznia 2020 21:23:11 UTC+1 użytkownik (fir) napisał:
> 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)

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

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

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

W dniu sobota, 1 lutego 2020 01:09:57 UTC+1 użytkownik (fir) napisał:
> 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
> 
> > 
> > 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

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