[CppPolska]

Cześć Mirki i Mirabelki kochające #programowanie w #jezykc i #cpp ( ͡º ͜ʖ͡º) Dawno nas tutaj nie było, co nie? Ostatnio trochę skupiliśmy się na grze w życie, ale powoli zaczynamy wychodzić z tej jaskini (⌐ ͡■ ͜ʖ ͡■)

Mamy dziś dla Was nowy wpis od Mariusza Jaskółki, który opowiada o tym, czy język C++ faktycznie jest wolniejszy od C. Spójrzmy na ten nieco clickbaitowy temat z perspektywy eksperckiej.

https://cpp-polska.pl/post/czy-c-jest-wolniejszy-od-cij-kilka-slow-o-zero-cost-abstraction (｡◕‿‿◕｡)

Język C++, w przeciwieństwie do C jest językiem wieloparadygmatowym. Możemy używać go do programowania proceduralnego, strukturalnego, obiektowego, poniekąd funkcyjnego i prawdopodobnie jeszcze jakiegoś innego. W C jesteśmy ograniczeni do pierwszych dwóch. W świecie programistów można spotkać opinie, że C++ poprzez zwiększenie poziomu abstrakcji utracił na wydajności w stosunku do starego, dobrego i szybkiego C. Zbadajmy więc, czy ta opinia ma odzwierciedlenie w rzeczywistości. Porozmawiajmy jednak najpierw trochę bardziej teoretycznie.

Miłej lektury wszystkim! ʕ•ᴥ•ʔ

[Kaczus2B]

@CppPolska: W C spokojnie pisze się obiektowo. Różnice w szybkości działania będą tylko, gdy użyjemy różnych rodzin kompilatorów, albo programiści nie będą umieli zoptymalizować. Nawet C++ ma szanse być szybszy w przetwarzaniu danych z templatami, bo zamiast wywoływania np przy sortowaniu metody porównujące, może być wstawiony kod funkcji porównującej bezpośrednio do algorytmu.

[Razi91]

@Kaczus2B: W C nie pisze się spokojnie obiektowo. Jest to karkołomne i ze sporym narzutem (brak vtable, wbudowanego mechanizmu dziedziczenia). Templatki mogą przyspieszyć kod względem analogicznego kodu z drabinką if-ów, ale może (i to znacznie) zwiększyć ilość wyprodukowanego kodu (każdy typ/zestaw typów to osobna implementacja)

[Kaczus2B]

@Razi91: ciekawe, że twórcy np BOOPSI o tym nie wiedzieli i mechanizmy obiektowe stosowali w latach 80 w C.

[Razi91]

@Kaczus2B: wiesz, można zrobić przeprowadzkę do nowego mieszkania maluchem, ale po co? ( ͡° ͜ʖ ͡°)
Nie twierdzę że się nie da, tylko że na chwilę obecną to karkołomne i głupie.

[Kaczus2B]

@Razi91: nie jest takie karkołomne i takie głupie jak zaczniesz używać. A że nie zawsze możesz użyć C++, to bardzo pomaga, szczególnie jeśli projekt jest duży.

[jm4R]

Obiektowość w C jest sprawą dosyć, nazwałbym to, śliską. Swego czasu, w polskiej literaturze był podział na języki obiektowe i zorientowane obiektowo. Język C należy do pierwszej grupy a do drugiej już nie.
Tak czy owak, nie o tym jest artykuł :)

[Kaczus2B]

@jm4R: nie ma języków obiektowych i nieobiektowych (co najwyżej jedne lepiej wspierają inne gorzej ten paradygmat). Możesz w javie pisac nieobiektowo i w C obiektowo. To, że używasz klasy nie oznacza, że programujesz obiektowo!

[jm4R]

@Kaczus2B: Są języki obiektowe i nieobiektowe (tzn. takie, które wspierają obiektowość lub takie, które jej nie wspierają w ogóle). Ale to są wszystko kwestie definicji, nie ma co zbytnio na ten temat dyskutować.

[Razi91]

@Kaczus2B: A gdzie dzisiaj nie można użyć C++? Przecież ogarnia on ABI C i kompiluje się do tego samego poziomu co C. Chyba tylko jakieś stare sprzęty niewspierane przez GCC albo LLVM.

[Kaczus2B]

@Razi91: są różne urządzenia, gdzie twórcy uważają za stratę czasu przygotowanie środowiska dla c++ i dostępne jest tylko w C. Nie chodzi o jakieś przeciwności związane z brakiem możliwości, tylko i wyłącznie z tym, że wymagaloby to nadmiernej pracy, konstrukcje zazwyczaj są specyficzne, tworzone na rynki niszowe.

[jm4R]

@Kaczus2B: Co rozumiesz przez "przygotowywanie środowiska"?

[Kaczus2B]

@jm4R: dostosowanie bibliotek do specyficznego działania urzadzen - przykład - miałem urządzenie z bardzo uproszczonym systemem, działał tylko malloc, nie działało free, bo założenie było takie, - program/biblioteka startując zabiera tyle pamięci ile potrzebuje i pracuje do wyłączenia urządzenia. Nieskazane były wszelkie fragmentacje pamięci, toteż taka konstrukcja. Oczywiście było więcej zrobionych specyficznych rzeczy dla tego uproszczonego systemu. Teraz dostosowanie do tego wielu kompilatorów, to pewna praca, ktora trzeba wykonać. Może się

[jm4R]

@Kaczus2B: Z tego co piszesz, to wystarczyłoby nadpisanie globalnego operatora delete "¯_(ツ)_/¯"
https://www.geeksforgeeks.org/overloading-new-delete-operator-c/

[AgainPsychoX]

@kaczus2B @jm4R Sam sytuacji gdzie nie miałem malloc/free używałem konstruktora in-place do wcześniej zaalokowanej przeze mnie pamięci globalnej - przez ładne makro nawet znośnie to wyglądało. Wszystkie obiekty, które tworzyłem były już niemal zawsze odgórnie zaplanowane w pamięci - taka specyfika pracy bez systemu zarządzającego pamięcią.

użyć można było tylko C

Wyjątki (i tak upośledzone - przynajmniej na razie)? Okej. Kilka funkcji do łatwiejszego zarządzania pamięcią? No dobra. Ale nie rozumiem, dlaczego

[Kaczus2B]

@AgainPsychoX: a czy ja napisalem, ze jest zly? Ot czasem po prostu szybciej mozna przygotowac srodowisko w C niz w C++, po prostu obecny standard C++ jest duzy, natomiast C jest w zasadzie dosc minimalistyczny, wiec jest mniej pracy. Urzadzenie wychodzi w kilku tysiacach egzemplarzy i jest przeprojektowywane pod nowe potrzeby i znowu trzeba srodowisko poprawic, jesli ma to byc wydajne. Taka nisza w niszy dla C. Moze przez ostatnie 2

[AgainPsychoX]

@Kaczus2B No tak, bo biblioteka standardowa to język XD

Ja też używam niemal zawsze (troche "niestety") środowiska bibliotek z C na np. stmach ale nadal piszę w C++ bo własnie to język sprawia, że jest mi wygodniej.

[Kaczus2B]

@AgainPsychoX: a co mi po jezyku, z ktorego wlasciwosci nie moge skorzystac? A w zasadzie o ile kilkanascie lat temu bym sie oburzal, to teraz traktuje to jak zastane narzedzie i staram sobie zaplanowac prace w zastanym srodowisku. Raz to jest C, czasem C++, ostatnio stare Delphi i troche C#. Jest na to zapotrzebowanie, potrafia za to nagrodzic, to czemu nie.

[jm4R]

@Kaczus2B: Ale o czym my tutaj mówimy? Jeżeli używasz architektury, której nie wspiera gcc, clang czy inny kompilator i sam musisz taki kompilator napisać, to jasne że kompilator C jest dużo prostszy do zrobienia. Jeżeli jednak taki gcc obsluguje Twoją architekturę to na prawdę nie widzę problemu.

[jm4R]

@AgainPsychoX: makro? Są gotowe alokatory, które coś takiego realizują. Makro w C++ nigdy nie będzie ładne. Tego dziadostwa nie da się debugować.

[AgainPsychoX]

@jm4R: To prawda. Ja wtedy użyłem makra, bo szczerze - nie czułem się dobrze w tych kwestiach. Jak będę mieć kolejny taki projekt pewnie postaram się użyć nowszych rozwiązań.