Zgodnie z zapowiedziami, kontynuacja tematu z ostatniej notki, w której przedstawiałem sposoby umożliwiające w pewnym stopniu na emulacje środowiska wielowątkowego w JS. Teraz, jak obiecałem, nadszedł czas na przedstawienie mojej implementacji, prostej biblioteki umożliwiającej w bardzo prosty sposób emulować wielowątkowość.
Wprowadzenie Wspominałem w poprzedniej notatce, że sam problem zawieszania się i blokowania przeglądarki, przez długo wykonywujący się kod JS mnie za bardzo nie dotyczył - dopóki sam nie musiałem rozwiązać tego problemu.
JavaScript nie posiada wielowątkowości, we wszystkich przeglądarkach (z wyjątkiem Chrome), kod JS wykonywany jest w jednym wątku. Niejeden webdeveloepr “naciął się” na zamrożenie przeglądarki (lub ostrzeżenie w Firefoksie) w czasie wykonywania intensywnego kodu zajmującego zasoby. W takich wypadkach JS blokuje przeglądarkę, podobnie aktualizacje interfejsu użytkownika i zawartość strony, do czasu zakończenia wykonywania bieżącej operacji, co można w prosty sposób doświadczyć, poprzez prostą konstrukcję nieskończonej pętli (symulującej ciężkie obliczenia):
while (true) Taką “ciężką” operacją może być przeliczenie dużej ilości danych, lub chociażby długotrwałe operacje na drzewie DOM (np.
Jednym z impulsów do napisania tej notatki było pojawienie się pewnej informacji na stronie głównej Konnekta, jednego z niegdyś (ponoć) dobrego multikomunikatora zbliżonego w swej idei do Mirandy. Wieść niesie, że wraz z końcem świata, czyli kilka dni temu, oficjalnie po kilku latach umierania projekt został zamknięty, a źródła otwarte:
21 grudnia 2012 roku - w dniu końca świata - po kilku latach nieaktywności, prace zostały oficjalnie zakończone. Tego dnia, zamknięte zostały dotychczasowa strona, oraz forum.
Według obietnicy z pierwszej notki o MPU chciałbym przedstawić najczęściej używany element, który ułatwia wykorzystywanie standardowych algorytmów operujących na zakresach dla danych przechowywanych w zwykłych tablicach.
Oczywiście nie ma żadnego problemu (pomijając wszelkie biblioteki), bo do tej pory tablice w łatwy sposób mogły być używane jako zakresy w dowolnej funkcji algorytmu z STL-a. Przeważnie robiło się to w prosty sposób, podając wskaźnik na początkowy i ostatni + 1 element tablicy. Tak, jak na poniższym przykładzie wypisującym zawartość tablicy:
Wraz ze wzrostem doświadczenia, a raczej ilości “wyklepanych” linii kodu i “przemielonych” projektów rośną nasze zasoby elementów i własnych konstrukcji najchętniej wykorzystywanych w kolejnych projektach. Oczywiście pomijam tutaj sens robienia czegokolwiek co znajduje się w bibliotece standardowej, boost lub jednej z miliona innych popularnych bibliotek. Niemniej, czasami nawet te standardowe i najczęściej używane biblioteki mają jakieś braki lub z innych powodów oferowane przez nie implementacje potrzebnych nam elementów nas nie zadowalają.
Na początku powinienem się do czegoś przyznać. Moje oświadczenie idealnie mogą odzwierciedlać słowa utworu “Nie jestem punkiem” pana Dariusza Paraszczuka, co w moim wykonaniu zabrzmiałoby jakoś tak:
Nie jestem webdeveloperem i nigdy nie byłem,
i nigdy tego przed wami nie kryłem.
Nie jestem webdeveloperem, co nie oznacza,
że nie popieram lub mi uwłacza.
Nie jestem webdeveloperem i być nie chciałem,
bo się po prostu nie nadawałem.
Więc skojarzenia są bezpodstawne,
Jakiś czas temu trafiłem w sieci na artykuł opisujący powody, dla których warto używać nowej odsłony języka C++. Nowy standard oficjalnie został zatwierdzony przez komitet 12 sierpnia 2011 roku, ale na długo przed tym wydarzeniem większość liczących się kompilatorów w jakimś tam stopniu wspierała już nowe możliwości języka. Zatem pewnie większość deweloperów nie tylko zna wiele nowinek, ale stosuje je już w swoich projektach.
Nie chcę tutaj rozdrabniać się nad poszczególnymi nowymi elementami języka i biblioteki standardowej, ani też próbować ewangelizować, edukować, czy choćby prezentować fragmenty kodu.
Od ostatniej notki minęło ponad 2,5 roku. W tym czasie trochę się w życiu i na świecie wydarzyło. Wiele razy także próbowałem tutaj wrócić i mam nadzieję, że wreszcie mi się to udało. Miejsce to stało się już prawie zapomniane, a fajnie byłoby wrócić, do w miarę regularnych, publikacji o ciekawych rzeczach i tematach.
Przeglądając historyczne wpisy miałem wrażenie, że trochę dużo jest tu nudnej treści o niskim poziomie, prezentujące proste, banalne rzeczy i poruszające nudne tematy.
Ostatnio zacząłem trochę pracować nad restrukturyzacją modułów, o czym wspominałem w jednej z poprzednich notek. Wydaje się, że sprawa wygląda dosyć prosto - pomyśleć co aplikacja potrzebuje od modułów i odpowiednio dostosować ich interfejs. No, ale prócz tego warto od razu pomyśleć też nad tym co będzie dostępne w API i wziąć to również pod uwagę. I tak doszedłem do odwlekanej kwestii API.
Na początku myślałem, aby API miało budowę i strukturę podobną do API udostępnianego w mirandzie i tlenie.
Dziś chciałbym pomarudzić o tym jak to genialni programiści olewają i ignorują istnienie tak przydatnego i niezastąpionego wynalazku w C++ jakim są przestrzenie nazw, które rozwiązują problemy kolizji nazw.
Problem kolizji nazw jest szczególnie znany osobom programującym w C i innych językach, gdzie istnieje jedna globalna przestrzeń dla wszystkich nazw i identyfikatorów. Utrudnia to pisanie programów i odrębnych modułów. Do rozwiązania takiego problemu można użyć wiele różnych sposobów i mechanizmów. Jednym z nich (najpopularniejszym) jest stosowanie różnych wymyślnych prefiksów i sufiksów do definiowanych nazw zmiennych i funkcji.