Sporo algorytmów jako swoje parametry przyjmuje różnego typu funkcje, które potem są wykorzystywane w trakcie ich działania. Prostym przykładem są tu wszelkiego rodzaju sortowania czy wyszukiwania, umożliwiające często podanie własnego predykatu (funkcji zwracającej wartość logiczną). W bardziej skomplikowanej wersji może chodzić chociażby o algorytm genetyczny lub przeszukujący drzewo gry, który wykorzystuje do działania jakąś funkcję oceniającą (np. osobników w populacji).
Na takie okazje różne języki programowania oferują różne narzędzia, lecz w większości przypadków sprowadzają się one do jednego z poniższych:
Niektóre języki nie mają jednak ani wskaźników, ani delegatów – w nich zwykle stosuje się sposób następny.
()
. Może więc to być zwykły wskaźnik, jakaś ładna zewnętrzna implementacja mechanizmu delegatów (np. FastDelegate) lub jakikolwiek obiekt z przeciążonym operatorem nawiasów ()
. Właśnie te ostatnie nazywa się zwykle funktorami, a jeśli ktoś nieco bardziej zagłębił się w bibliotekę STL, na pewno nie raz się z nimi spotkał.Trzeba też powiedzieć, że właściwie istnieje też inny sposób: zamiast samej funkcji przekazywanie jej… nazwy. “I niby jak ją potem wywołać?”, można zapytać. Ano to już indywidualna kwestia każdego języka – w tym przypadku zwykle interpretowanego :)
W takiej dużej aplikacji jak IDE ilość opcji jest na tyle spora, że część z nich pochowana jest głęboko w czeluściach wielopoziomowego menu. Często nie znaczy to jednak, że są one mniej przydatne; na pewno jednak są trudniej dostępne. Dodatkowo też ilość klawiszy na klawiaturze jest ograniczona, więc nie wszystkie opcje mogą mieć przypisane skróty klawiszowe… Chyba że zastosuje się jakieś sztuczkę :)
W vimie i jego pochodnych taką sztuczką były polecenia wpisywane od dwukropka (na czele z najbardziej przydatnym, czyli
Jak to działa? Otóż bardzo prosto: po wciśnięciu specjalnej kombinacji ‘aktywującej’ (np. Ctrl + K) nic się wprawdzie nie dzieje, ale aplikacji przełącza się w tryb pozwalający na wykrycie drugiej kombinacji (np. Ctrl + C), która odpowiada już konkretnej akcji. Całość można więc zapisać jako Ctrl + K,C; oznacza to po prostu: wciśnij i przytrzymaj Ctrl, a potem naciśnij kolejno K i C. Nic specjalnie trudnego, prawda? :)
A jakież to wspaniałe opcje IDE są dostępne w ten sposób? Ano jest ich całkiem sporo, spośród których wylistuję kilka:
/* */
czy #if 0/#endif
, żeby wyłączyć jakiś kawałek kodu z kompilacji :) Mamy bowiem takie oto skróty:
//
z początku każdej linijki)for
), pozwalając przy tym na łatwą zmianę ich szczegółów (np. nazwy zmiennej będącej licznikiem pętli).try
–catch
, if
, itd.Polecam przynajmniej jednokrotne spróbowanie każdej z powyższych opcji. Możliwe, że w ten sposób odkryjecie coś, czego brakowało wam przez cały czas :) Nie jest to też kompletna lista – więcej skrótów/opcji można znaleźć przeglądając menu Edit.
Teoretycznie najlepszym sposobem na usuwanie elementów z pojemników STL jest posłużenie się idiomem erase
–remove
:
W praktyce bywa on dość kłopotliwy jeśli stosowany predykat (tutaj oznaczony jako funktor ToBeDeleted
) musi być napisany specjalnie do tego celu. Zresztą gra często nie jest warta świeczki, bo implementacje algorytmów w rodzaju remove
to w środku często nic innego, jak zwykłe pętle.
No a pętle możemy przecież napisać sobie sami, prawda?… Otóż nieprawda – zwłaszcza jeśli wcześniej nie pomyślimy przez chwilę. Łatwo bowiem wyprodukować coś takiego:
Z poprawnością ma to niewiele wspólnego. Jeśli bowiem natrafimy na element do usunięcia, to po dokonaniu tego (w nagłówku pętli) zinkrementujemy iterator, który na ów usunięty element wcześniej pokazywał. W ten sposób możemy pominąć element następny, bo go zwyczajnie “przeskoczymy”. Odpowiednik powyższej pętli używający zwykłego licznika i operatora []
jest zresztą obarczony identycznym problemem.
Jak więc usuwać? Umiejętnie, rzecz jasna :) Skoro po skasowaniu jednego elementu pozostałe przesuną się o jedno miejsce do tyłu, nie powinniśmy zawsze bezmyślnie przechodzić dalej. Trzeba to robić tylko wtedy, gdy dany element zostawiliśmy w spokoju:
To w sumie całkiem oczywiste, jeśli chwilę się nad tym zastanowić. Bowiem – w przeciwieństwie do dodawania – usuwanie elementów z kontenerów wymaga właśnie chwili zastanowienia :]
Jeśli tylko liczymy coś bardziej skomplikowanego niż rozmieszczenie kontrolek w oknie, to niechybnie zaczniemy potrzebować którejś ze stałych matematycznych – na przykład π. Co wtedy robimy? Ano całkiem często skutkuje to włączeniem do programu deklaracji typu:
Nie jest to oczywiście wielkie zło (a już na pewno mniejsze niż bezpośrednie korzystanie z definicji typu π = 4atan(1)), ale w większości przypadków jest to też wyważanie otwartych drzwi. Potrzebne stałe mamy bowiem często już gdzieś zdefiniowane – trzeba tylko wiedzieć, gdzie ich poszukać:
M_PI
, M_E
, a nawet M_LN10
czy M_SQRT2
zdefiniowane w math.h lub cmath. Definicje te nie są jednak częścią standardu, więc dbające o zgodność kompilatory (czyli większość kompilatorów w ogóle) wymagają pewnych #define
‘ów przed dołączeniem ww. nagłówków. I tak dla Visual C++ jest to _USE_MATH_DEFINES
, a dla GCC bodajże prawie dowolne z makr _SOURCE
(jak _GNU_SOURCE
czy _ALL_SOURCE
).DX3DX_PI
i D3DX1BYPI
(1/π) – co nie dziwi, bo przecież w grafice więcej do szczęścia nie potrzeba ;) Obie te stałe są zdefiniowane w d3dx#math.h (gdzie #
to numer wersji DirectX), który to nagłówek jest dołączany automatycznie jeśli korzystamy z D3DX.PI
i E
zdefiniowane jako statyczne pola klasy System.Math
. W Javie klasa java.lang.Math
zawiera dwa identycznie zdefiniowane pola.Jak zatem łatwo zauważyć, wynajdywanie koła w postaci definicji π czy e jest w wielu przypadkach nieuzasadnione :]
Visual Studio 2008 zasadniczo służy do pracy z .NET Framework w wersji 3.5, ale ma tę przyjemną cechę, że pozwala określić używaną przez projekt wersję frameworka. A to oznacza, że można zdecydować się na wersję 2.0, co pozwala na współpracę także z edycją 2005.
Pewnym problemem pozostaje jednak fakt, że próba załadowania w Visual Studio 2005 solucji stworzonej w edycji 2008 kończy się takim oto uroczym komunikatem:
Co z tym zrobić?… Można oczywiście utworzyć nową, pustą solucję, a potem dołączyć do niej projekty z tej oryginalnej. To dość kłopotliwe, a VS wymaga też, aby solucje tworzyć zawsze w pustym lub nieistniejącym katalogu. Ostatecznie musielibyśmy więc przekopiować ją wpierw w docelowe miejsce, a potem zająć się przyłączaniem doń naszych projektów. Warto też zauważyć, że stworzenie zupełnie nowej solucji oznacza utratę wszelkich niestandardowych konfiguracji budowania projektów; w gruncie rzeczy bowiem właśnie te konfiguracje to – poza samą listą projektów – jedyna istotna rzecz przechowywana w pliku .sln.
Na szczęście jednak ów plik jest zwykłym plikiem tekstowym, którego format tak naprawdę nie zmienił się od dawna (jak sądzę co najmniej od wersji 2001). Dlatego całkiem prawdopodobne jest to, że jedyną przeszkodą przy wczytywaniu nowej solucji w starszym VS jest… numer wersji zapisany w pierwszym wierszu pliku:
Microsoft Visual Studio Solution File, Format Version 10.00
Nie zaszkodzi więc zmienić owe 10.00 (VS 2008) na 9.00 (VS 2005) i ponownie spróbować otworzyć solucję. Jeśli próba się powiedzie, oszczędzimy sobie pracochłonnego kombinowania. A jeśli nie… to pewnie warto pomyśleć o upgrade ;]