Nadużywanie preprocesora w C++

Wszyscy wiemy czym jest preprocesor Cpp i jak działa¹. Jest to narzędzie odziedziczone z języka C, operujące na tekście kodu programu, a tym samym nie mające żadnego pojęcia o składni i regułach języka jaki przetwarza. Jest narzędziem, które używane nierozważnie może z łatwością doprowadzić do klęski nasz program. A mimo to wciąż tak wiele programistów piszących swoje aplikacje w C++ go kocha.

Nagminne używanie preprocesora jest też częstym nawykiem wyniesionym z C i nadużywanym w C++. A przecież C++ ma wiele funkcjonalności, dzięki którym możemy zrezygnować z jego korzystania. Oczywiście nie pozbędziemy się go w całości, ale wykorzystywanie go do definiowania stałych, makr i innych pseudofunkcji jest złym pomysłem. Preprocesor powinien być wykorzystywany tylko i wyłącznie do włączania plików oraz sterowania kompilacją i opcjami kompilatora. Poza wyjątkami, każde inne użycie jest pomyłką, która powinna zostać jak najszybciej naprawiona.

Korzystanie z preprocesora w C++ powinno być zaniechane.

Szlag mnie trafia, gdy widzę w kolejnym programie, czy projekcie używanie dyrektywy define preprocesora do definiowania stałych, rozwijanych funkcji lub próby wykorzystania makr do osiągnięcia imitacji generowania parametryzowanych obiektów lub funkcji:

#define SIZE		3
#define NAME		"dupa"
#define max(x,y)	(x > y ? x : y)

Do tego celu w języku C++ mamy stale obiekty poprzedzone specyfikatorem const i funkcje inline rozwijane w miejscu wywołania oraz wzorce template:

const int size = 3;
const char* name = "dupa";

template<typename T>
inline T max(const T& x, const T& y) {
	return x > y ? x : y;
}

W przeciwieństwie do makr, mechanizmy te podlegają ścisłym regułom języka, takim jak chociażby zasięg (widoczność) i kontrola typów. A co za tym idzie są bezpieczniejsze i wygodniejsze.

Jednym z głównych argumentów jakie często zostaje podawane w odpowiedzi na pytanie “czemu używasz makr dla stałych” pada odpowiedź, że “szybkość”, bo przecież w wynikowym kodzie będą odpowiednie wartości a nie “zmienne”. Oczywiście jest to totalną bzdurą.

W C++ stałe zadeklarowane jako const inicjowane znaną wartością, oraz wartością możliwą do wyliczenia i określenia przez kompilator w czasie kompilacji, zostaną zastąpione w wynikowym kodzie odpowiednimi wartościami. Zatem o jaki brak szybkości i wydajności tutaj chodzi?

Programiści nadal kochają preprocesor i nagminnie go używają, a wygenerowane przez nich preprocesorowe potworki wprowadzają zamieszanie i pogorszenie czytelności samego kodu. Nierzadko są też beznadziejnym wyborem, świadczącym o tym, że sam autor chyba tak naprawdę nie zna języka w którym pisze swój program. Bo jeśli byłoby inaczej to przecież skorzystałby z bardziej cywilizowanych, odpowiednich i dedykowanych rozwiązań.

Oczywiście zawsze istnieją wyjątki, gdzie skorzystanie z makr jest niezbędne i wygodne do osiągniecia zamierzonego celu, nie tracąc przy tym estetyki i czytelności kodu źródłowego.

Jedno z życzeń twórcy języka (Bjarne Stroustrup) jest związane z preprocesorem²:

Chciałbym kiedyś dowiedzieć się, że preprocesor Cpp został usunięty. Jednak jedyny realny i odpowiedzialny sposób, który może do tego doprowadzić, polega na tym, aby najpierw sprawić, że Cpp stanie się zbędny, a następnie zachęcić ludzi do używania jego lepszych odpowiedników.

Ja chciałbym tylko, aby programiści zaczęli używać tych lepszych odpowiedników jakie obecnie oferuje im język. Ciekawe czy kiedykolwiek się tego doczekam. Może kiedyś używanie dyrektywy define przez programistów zostanie zniwelowane tylko do specyficznych przypadków i wspomagania kompilacji warunkowej.