🚀 go-pugleaf

On Sunday, January 15, 2023 at 8:27:47 PM UTC+1, Jacek Marcin Jaworski wrote:
> Podsumowanie Projektu Liczniki 
> autor: Jacek Marcin Jaworski 
> pseudonim: Energo Koder 
> utworzono: 2022-09-17 
> wersja: 167 z dnia: 2023-01-15 
> system: Linux (distro: Kubuntu) 
> program: LibreOffice 
> Spis treści 
> 1 Wstęp.................................................................................................................................................................. 3 
> 2 licznik.sh............................................................................................................................................................. 3 
> 3 licznik.py............................................................................................................................................................. 3 
> 4 licznik.d............................................................................................................................................................... 3 
> 5 licznik.c++........................................................................................................................................................... 4 
> 6 Porównanie jakości kodu.................................................................................................................................. 4 
> 7 Porównanie ilości kodu..................................................................................................................................... 5 
> 8 Porównanie wydajności.................................................................................................................................... 5 
> 9 Podsumowanie.................................................................................................................................................. 5 
> 10 2022-12-28:...................................................................................................................................................... 6 
> 1 Wstęp 
> Od kiedy zacząłem programować zawsze intrygowało mnie ile linii kodu mają moje programy 
> oraz ile linii mają programy popularnych projektów o otwartych źródłach. Początkowo prowadziło to 
> do cudakowania i szacowania ilości linii ze wzoru: objętość plików z kodem w bajtach / 32 znaki. 
> Wynikało to z obserwacji, że śr. dł. linii w C++ to ok. 32 znaki. 
> 
> W latach 2004-2022 zrealizowałem projekt energo-liczniki. Taka długotrwałość projektu wynika z jego 
> rozszerzania z upływem lat. Od razu miałem zamiar zakodować wersje w Baszu i w Pytonie. W ten 
> sposób chciałem poznać te języki skryptowe. Dodatkowo okazało się, że jest to świetna okazja by 
> poznać wyrażenia regularne. W 2022r. stwierdziłem, że rozbudowana wersja w Pytonie powinna być 
> uproszczona, gdyż algorytm skanowania nie był sprawdzony pod względem poprawności. Dodatkowo 
> mógł on działać poprawnie tylko dla niektórych języków programowania (pochodnych C). W 2022r. 
> spolonizowałem liczniki w Baszu i Pytonie - wynikało to z logicznego wniosku, że w Polsce należy 
> myśleć, mówić, pisać i programować po polsku. W 2022r. zaprogramowałem wersję w D i C++ - dają 
> one takie same wyniki jak wersja w Pytonie. Celem było uzyskanie możliwości porównania tych 
> najważniejszych dla mnie języków programowania. 
> 
> Liczniki to programy w j. C++ i D oraz skrypty w j. Basz i Pyton służą one do badania ilości linii w kodach 
> źródłowych programów. Są to programy konsolowe zwracające wyniki skanowania na konsolę. Wersja 
> w j. Basz ma prostsze opcje. Wynika to z faktu, że opiera się ona na standardowych programach 
> konsoli do przetwarzania tekstów. Wersje w Pytonie, D i C++ mają więcej opcji jednak zwracają wyniki 
> w takim samym formacie co wersja w Baszu. 
> 
> W dawniejszych czasach używałem systemów Linuks i Windows. Z tamtych dawnych czasów wynikało 
> ciekawe spostrzeżenie, że wersja Basz działa szybciej na Linuksie, natomiast wersja w Pytonie działała 
> szybciej na Windowsie. Wyglądało na to, że w Windows funkcje plikowe są b. wolne i b. wolno tworzy 
> on nowe procesy i wolno je likwiduje. Obecnie jednak używam wyłącznie systemu Linuks i nie jestem w 
> stanie porównać działania liczników na systemie Windows. 
> 
> 
> 
> 2 licznik.sh 
> Jest to skrypt w j. Basz. Jest oparty na standardowych programach konsoli takich jak find i wc. 
> Jego cechą szczególną jest to, że używa programu parallel do zrównoleglenia skanowania plików 
> źródłowych. Ciekawe jest to, że na procesorze Intel i7 10510 z 4 podwójnymi rdzeniami użycie parallel 
> spowalnia skrypt. To bardzo dziwne bo znaczy to, że program parallel jest niewydajny mimo banalnego 
> zadania jakie wykonuje. 
> 
> 
> 
> 3 licznik.py 
> Jest to skrypt w języku Pyton. Działa całkowicie sekwencyjnie. 
> 
> 
> 
> 4 licznik.d 
> Jest to program w języku D. Działa całkowicie sekwencyjnie. 
> 5 licznik.c++ 
> Jest to program w języku C++. Jego cechą szczególną jest zastosowanie mojej biblioteki energo- 
> protekcja. W jej skład wchodzi klasa Katalog która jest w stanie pobierać listy plików i w wątkach je 
> klasyfikować wg zadanego wyrażenia regularnego. Została ona użyta w tym programie. 
> 
> 
> 
> 6 Porównanie jakości kodu 
> Rewelacje Zalety Wady Partactwa 
> licznik.sh + Prostota; + Dokumenty - Brak debugera; - exit 1 nie działa w 
> + parallel: miejscowe; - Podatność na f.; 
> Równoległe + F. działają tak jak literówki; - 
> skanowanie standardowe - Proceduralna Przekomplikowane 
> plików; programy konsoli; architektura; getopt; 
> + shellcheck - Brak rozdzielenia - Archaiczna, 
> deklaracji i definicji nietypowa składnia 
> f. wyr. reg.; 
> licznik.py + Składnia oparta + Standardowa - Brak rozdzielenia 
> na wcięciach; składnia wyr. reg.; deklaracji i definicji 
> + Obiektowość: + W konst. i dest. f.; 
> wzorzec wizytator; działają f. wirt. - Utrudniona 
> + Wyjątki; nawigacja po 
> kodzie z powodu 
> nie wydzielenia 
> klas do plików; 
> - Brak IDE z 
> debugerem; 
> licznik.d + Genialna f. + Standardowa - Brak rozdzielenia Niestandardowe 
> getopt; składnia wyr. reg. deklaracji i definicji operatory do 
> + Obiektowość: + W konst. i dest. f.; łączenia tablic i 
> wzorzec wizytator. działają f. wirt. - Utrudniona napisów: ~ i ~=; 
> + Działa nawigacja po 
> dziedziczenie kodzie z powodu 
> operatorów. nie wydzielenia 
> klas do plików; 
> - Brak IDE z 
> debugerem; 
> licznik.c++ + Obiektowość: + Podział QRegularExpressio - W konstruktorach 
> wzorzec wizytator i programu na pliki n: Alternatywa i destruktorach nie 
> jasna architektura; deklaracji i definicji kilku wyr. reg. działają f. wirtualne 
> + Rozdzielnie klas; wymaga - jednak tylko w 
> deklaracji klas i f. niegrupujących odniesieniu do 
> od ich definicji; nawiasów; obiektu *this1; 
> + Wygodna - Nie działa 
> kontrola pam. dziedziczenie 
> sprytnym wsk. operatorów; 
> QSharedPointer; - Ręcznie trzeba 
> + Kl. Katalog z wskazywać f. 
> klasyfikacją ścieżek wstawiane. 
> w wątkach. 
> 
> 
> 
> 
> 7 Porównanie ilości kodu 
> Ilość linii 
> licznik.sh 217 
> licznik.py 290 
> licznik.d 303 
> licznik.c++ 627 
> 
> 
> 8 Porównanie wydajności 
> Czas skanowania kat. energo-protekcja 
> licznik.sh [Sekwencyjne skanowanie plików] 0,120 
> licznik.sh [Równoległe skanowanie plików] 0,316 
> licznik.py 0,114 
> licznik.d 0,359 
> licznik.c++ [Sekwencyjna klasyfikacja ścieżek] 0,246 
> licznik.c++ [Równoległa klasyfikacja ścieżek] 0,049 
> 
> 
> 9 Podsumowanie 
> Liczniki kodowane w różnych językach ujawniły ich silne i słabe strony. 
> 
> W programowaniu kluczowa jest zwięzłość kodu i wyrazistość architektury. Okazuje się, że są to 
> sprzeczne koncepcje. W tym projekcie najczytelniejsza architektura programu w C++ generuje ponad 
> 100% więcej kodu niż równorzędny program w D. 
> 
> licznik.C++ dostaje skrzydeł, gdy klasyfikuje nazwy plików wyrażeniami regularnymi w wątkach. Na 4 
> podwójnych rdzeniach daje to przyspieszenie 5x. To daje w standardzie klasa Katalog z mojej bibl. 
> 
> 
> 
> 1 Czyli w zagregowanych obiektach f. wirt. działają normalnie. 
> energo-protekcja. licznik.C++ można by dodatkowo przyspieszyć skanując pliki źródłowe w wątkach. 
> Nie koduję tego, bo nie zastosuję tego nigdzie indziej - dlatego szkoda na to czasu. 
> 
> licznik.py działa najszybciej w śród rozwiązań sekwencyjnych. 
> 
> licznik.sh w wer. sekwencyjnej działa prawie tak samo szybko jak skrypt w j. Pyton. Gdy w licznik.sh 
> zastosowałem zrównoleglenie skanowania plików źródłowych odnotowałem ponad 3x dłuższy czas 
> działania. Sprawa wyjaśniła się w d. 2022-11-19: wtedy okazało się, że konsolowy program parallel jest 
> skryptem w j. Perl - jasne jest, że użycie j. skryptowego w tym celu to jakiś defekt umysłowy - takich 
> rzeczy się nie robi. Ponad to ze stron GNU wiem, że nawet w 2022r. dalej się coś grzebie przy tym 
> skrypcie. 
> 
> 
> 
> 10 2022-12-28: 
> Wczoraj i dziś pracowałem nad dostosowaniem licznik.C++ do aktualnej wer. mojej bibl. energo- 
> protekcja. 
> 
> W licznik.C++ uzupełniłem brakujące opcje -l|--licencja i -w|--wersja . 
> 
> Ze wszystkich liczników usunąłem opcje -h|--help . 
> 
> W licznik.C++ włączyłem równoległą klasyfikację plików za pomocą wyr. reg. - To spowodowało 5x 
> przyspieszenie na 4 podwójnych rdzeniach. 
> 
> We wszystkich licznikach zmieniłem sposób zliczania linii: teraz zliczają one wyłącznie znaki nowej linii - 
> wynika to z faktu, że narzędzia konsoli (będące podstawą licznik.sh) nie są w stanie stwierdzić czy w 
> ostatniej linii są jakieś znaki, czy nie. W celu unifikacji przyjąłem, że nie obsługuję tego w pozostałych 
> wer. liczników. 
> 
> Przy okazji ponownie przeprowadziłem testy i uzupełniłem to podsumowanie.

Sorry za ignorancje, ale problem o którym piszesz jest trywialny do rozwiązania w C++. Jedynie jeżeli chciałbyś to wielowątkowo napisać to może pojawiłaby się jakaś trudność ale też nie bardzo bo nie ma synchronizacji wątków. Pisałem tutaj kiedyś prosty program do zliczania znaków, myślę że dla linii byłoby jeszcze prościej.