🚀 go-pugleaf

On 11/03/2020 07:42, Maciek Godek wrote:
>>> Abstrakcje w C są dobrze dobrane do zadań, do których używa się C.
>> C nie ma abstrakcji poza void*.
> Mechanizmy abstrakcji w C:
> - funkcje

Są w C++.

> - makra

Są w C++.

> - typy uzytkownika (struktury, unie, wyliczenia)

Są w C++, tylko tam są na serio.

> - wskazniki na typy konkretne

Są w C++, tylko tam są na serio.

> - wskazniki na funkcje

Są w C++ tylko tam są na serio.

Natomaist C++ dodaje Ci masę innych rzeczy to tych pseudo abstrakcji. 
Między innymi dodaje prawdziwe abstrakcje takie jak szablony.

Można oczywiście bredzić o tym że funkcja to taki rodzaj abstrakcji. W 
zasadzie za chwile dolecisz to debilnego wniosku że asembler jest 
abstrakcyjny bo ma rejestry i jsr. Daj se spokój.

>> Nikt, potwórzę, nikt nie pisał nic w tym wątku o używaniu coroutines w
>> systemie embedded.
> Ja pisałem o tym od początku.

Nie, Ty miałeś "swoje powody" których nie dało się wydobyć siłą i długo 
trwało zanim objawiłeś światu co ch... komu popsuty kod.

>> Nie, na tym polega usilnie szukanie zastosowań Twójego gównianego
>> kawałka kodu który jest gówniany z definicji, wliczając w to rechot
>> rezty świata na wiki.
> Tzn. na tym, że rozumiem, jak działa to, czego używam?

Ależ masz prawo używać. Jęsli migasz dwiema diodami to przyda się jak 
znalazł.

>>> Nie wiem skąd Ci strzelił ten asm.
>> Bo C to taki abstrakcyjny asembler.
> Argumentum ad sloganum?

Nie, tak wygladały początki Unixa. Mieli do dyspozycji albo assembler 
albo cokoliwek milimter wyżej. I po kilku próbach narodził się C. Jest 
milimetr wyżej. Główna róznica jest taka że ma inne (więcej) typy danych 
niż BCPL. Cała reszta to nieistotne duperele. C powstał po to aby pisać 
bardziej abstrakcyjnie jądra unixa. Nie interesował ich stowrzenie 
języka bezpiecznego, wygodnego, czytelnego. Chodziło o napierniczanie w 
czymś choć odrobinę lepszym niż asm. Cały jezyk C to takie popłuczyny po 
asm. To całe i++ wszak żywcem wyjęte z kilku architektur cpu.

>>> Asembler jest złą abstrakcją, bo mocno utrudnia przenośność programów pomiędzy procesorami.
>> No dostrzegasz ironii?
> ?

Nie dostrzegasz.

>>>> Wręcz odwrotnie, namawiam embedowców aby używali C++ ale NIE używali
>>>> STL.
>>> Czyli, namawiasz żeby używali C++, ale żeby nie używali C++?
>> Masz problem w pojmowaniu że C++ to kilka róznych koncepcji i nie ma
>> obowiązku używać wszystkich.
> "Kilka" to lekkie niedoszacowanie.

Kilka w zastosowaniach embedded. Silne typy, RAII, szablony. Na początek 
wystarczy.

> Ale właśnie sęk w tym, że zawsze znajdzie się w internecie jakiś czesiek

Sebastian.

>, który będzie udowadniał innym, że technologia, której używają, jest zacofana, bo nie jest technologią, której on używa.

Wiadomo, Twój punkt widzenia jest bardziej obiektywny bo jest bardziej 
subiektywny, najmojszy. Zrobisz karierę w polityce.

> A jak mu wykażą, że ta ich technologia jest adekwatna do problemów, które rozwiązują

Ale ty dopiero po solidnym pieprzenięciu w głowę argumentacją wymyśliłeś 
sobie że to ma zastosowanie w jakimś marginalnym, niszowym embedded w 
którym i tak pewnie tego nikt nie robi czegoś równie bez sensu nawet 
majac 60+. Co i tak do dzisiaj traktuje jako wymówkę.

Masz straszne parcie na udowodnienie światu że te dziadowskie korutyny 
mają sens. Sorry, nie mają, tak ogólnie. Jeśli pytałeś czy mozna za 
pomocą kilku mark migać didoami to tak, można. Jesli pytałeś czy te 
korutyny nadają się do czegkolwiek innego to nie, nie nadają się. bez 
względu na to czy napisałeś je w C czy C++. Są do dupy całkiem obiektywnie.