override w C++, i nie tylko

O braku słowa kluczowego override w C++ zdarzyło mi się już wspominać. Wskazywałem też, że jego niedobór jest całkiem istotnym brakiem, gdyż przypadki nadpisywania metod wirtualnych nie zawsze są zupełnie oczywiste.
Tym bardziej jest mi miło podzielić się odkryciem, które kiedyś poczyniłem na forum Warsztatu. Dowiedziałem się mianowicie, że słówko to do C++ można... dodać!

Jak to? - słychać pewnie pełne zdziwienia głosy. Ano bardzo prosto; zostało to zresztą wyczerpująco przedstawione w oryginalnym poście Esidara. Tutaj pokrótce tylko nakreślę jego ideę, która sprowadza się do genialnego spostrzeżenia, iż C++ zasadniczo radzi sobie bez override. A skoro tak, to jego wprowadzenie jest banalnie i wymaga zaledwie jednej linijki kodu:

I już! Składniowo można go teraz używać dokładnie tak samo jak analogicznego słówka z C#... albo właściwie jakkolwiek inaczej - implementacja jest bowiem na tyle elastyczna, że zaakceptuje każde jego wystąpienie :) To aczkolwiek jest też, niestety, jego wadą...

W porządku, żarty na bok. Żeby ta notka nie była jednak zupełnie bezużyteczna, pokażę jeszcze, jak przekonać Visual C++, by nasze nowe słówko było przezeń kolorowane tak, jak inne słowa kluczowe w C++.
Da się to zrobić, tworząc (lub edytujący istniejący) plik UserType.dat, umieszczony w tym samym katalogu co plik wykonywalny Visual Studio (devenv) - czyli gdzieś w czeluściach Program Files, zapewne. W tymże pliku wpisujemy w nowej linijce override. Jeśli przypadkiem chcielibyśmy kolorować też inne, niestandardowe słowa kluczowe (to pewnie jest bardziej prawdopodobne), to każde z nich należy umieścić w osobnej linijce.
Po zapisaniu pliku i restarcie VS wystarczy teraz wejść w opcje programu, do zakładki Environment > Fonts & Colors, a tam na liście Display items zaznaczyć User Keywords i przyporządkować im wybraną czcionkę i/lub kolor. Możliwe zresztą, że w ogóle nie musimy tego robić, jako że domyślnie własne słowa kluczowe kolorowane są tak, jak te "oryginalne".

Kolorowanie semantyczne

W dzisiejszych czasach niemal każdy edytor plików tekstowych nieco bardziej zaawansowany od windowsowego Notatnika oferuje funkcję kolorowania składni (syntax highlighting) przynajmniej kilku najpopularniejszych języków programowania. W przypadku całych IDE jest to oczywiście funkcjonalność absolutnie oczywista i niezbędna, jednak coraz więcej środowisk oferuje też coś więcej. Coś, co dla odróżnienia nazywam kolorowaniem semantycznym; nie jestem bowiem pewien, czy ten mechanizm ma jakąś ogólnie przyjętą nazwę.

Kodowanie semantyczne w Visual Studio z pluginem AssistX

O co w nim chodzi? Standardowe kolorowanie potrafi między innymi odróżnić słowa kluczowe od identyfikatorów, wyróżniając zwykle te pierwsze innym stylem czcionki, zaś te drugie pozostawiając bez zmian. Wszystkie identyfikatory: nazwy zmiennych, funkcji, typów, stałych, szablonów, itp., są więc formatowane tak samo i wyglądają identycznie.
Trik kolorowania semantycznego polega właśnie na rozróżnieniu tych wszystkich kategorii identyfikatorów. Oczywiście jest to możliwe tylko wtedy, gdy IDE dysponuje bazą danych o całej strukturze projektu. Ale taka baza jest przecież coraz częściej tworzona, tyle że w innym celu: zapewnienia automatycznego uzupełniania poprzez mechanizmy w rodzaju IntelliSense w Visual Studio. Na szczęście ktoś kreatywny wpadł na pomysł, że można ją wykorzystać także w inny sposób - i chwała mu za to :)

Kolorowanie semantyczne ma przynajmniej dwie zalety. Ułatwia ono zorientowanie się w przeglądanym kodzie, zwłaszcza takim który widzimy po raz pierwszy. Ponadto zaś pozwala ono na wczesne wykrycie prostych acz uciążliwych błędów w rodzaju literówek. Sprawiają one bowiem, że dany identyfikator - jako nieznany - jest kolorowany inaczej, co pozwala na łatwiejsze dostrzeżenie pomyłki.
A wady? Jak każdy mechanizm działający w tle, kolorowanie semantyczne zjada trochę zasobów systemowych - m.in. dla niego opłaca się mieć w procesorze więcej niż jeden rdzeń. A poza tym można zwyczajnie nie lubić pstrokatego kodu i preferować bardziej jednolitą kolorystykę... O gustach się przecież nie dyskutuje, a teoretycznie kodować można i w Notatniku :)

HLSL i kolorowanie składni

Niby kod można pisać w Notatniku, ale własnej równowagi psychicznej chyba lepiej zaopatrzyć się w edytor, który oferuje przynajmniej podświetlanie elementów składniowych języka. Wiadomo przecież, że mnogość kolorów poprawia samopoczucie :)
Co więc zrobić, gdy zamierzamy pisać efekty w języku HLSL (lub bardzo podobnym Cg)? Trzeba zdecydować się na jakieś narzędzie. Możliwych jest kilka wyjść:

• Użycie wyspecjalizowanego programu, jak choćby kombajnu nVidia FX Composer 2 czy odrobinę mniejszego CgEddie autorstwa SirMike'a.
• Nakłonienie do współpracy naszego ulubionego środowiska programistycznego, czyli Visual Studio. Od biedy można na przykład wymusić, aby pliki .fx były traktowane jak źródła C++ i kolorowane w ten sam sposób (Tools > Options > Text Editor > File Extenstions). Można też zastosować nieco zmyślniejsze rozwiązanie.
• Wsparcie pluginem naszego uniwersalnego programistycznego edytora, jeśli takowego używamy. Przykładowo, do vima dostępny skrypt z kolorowaniem składni plików .fx. Zaś dla jEdita możemy pobrać schemat kolorowania HLSL autorstwa Rega.

Jak widać, nie jesteśmy więc skazani na surową, czarno-białą czcionkę. A to dobrze, bo po dodaniu tej całej skomplikowanej matematyki, dziwnej semantyki dla danych wierzchołków i niezliczonych dyrektyw kompilacji warunkowej, kod shaderów jest już wystarczająco skomplikowany :)