W jednym z pierwszych artykułów niniejszego bloga zastawialiśmy się nad wyborem najlepszego języka programowania dla naszego projektu. O ile niskopoziomowa część, taka jak drivery sprzętu czy obsługa protokołów diagnostycznych są domeną języka C, to przechodząc do wysokopoziomowej części warto pochylić się nad jego młodszym bratem – C++.

Dlaczego? Czy nie lepiej trzymać się jednego języka tak, aby projekt był spójny?

Jest to bardzo trafny argument, pamiętajmy jednak, iż czysty język C ma pewne ograniczenia w swojej formie ekspresji. Cóż… powstał prawie pół wieku temu 🙂 Nie wierzycie?

Ok. Ale w czym konkretnie C++ będzie lepszy od starego, dobrego C?

Przyjrzyjmy się naszym rozważaniom z drugiej części cyklu o widgetach. Wspominałem tam, iż pojęcie widgetu stanowi pewną abstrakcję, bliżej nieokreśloną kształtem, posiadającą jednak pewien dobrze zdefiniowany zestaw akcji (czyli jak powiedział by developer – interfejs). Można więc przyjąć, iż widget jest idealnym, książkowym wręcz przykładem klasy wirtualnej. Na jej bazie można “nadbudowywać” kolejne warstwy konkretnych lub abstrakcyjnych widgetów-klas potomnych. Trudno wyobrazić sobie lepszy język programowania dla systemów wbudowanych, który będzie potrafił poradzić sobie z taką konstrukcją, niż C++.

Stop. Przecież bez najmniejszego problemu można stworzyć namiastkę klas w C.

Można, jednak wciąż będzie to namiastka. Za użyciem prawdziwych klas przemawia wiele argumentów. Po pierwsze pojawia się abstrakcja, która ogromnie upraszcza proces tworzenia i używania widgetów w naszym systemie. Po drugie zakładamy, że będziemy dynamicznie tworzyć wiele instancji widgetów różnych typów. Po trzecie – część kontrolek będzie stanowić jedynie “odmianę” innych, np. widget pomiaru jest niczym innym jak nieco rozbudowanym tekstem statycznym.

A kwestia szybkości? Kod C będzie lepiej zoptymalizowany…

Prawda, jednak niewielka poprawa wydajności zostanie uzyskana kosztem znacznego pogorszenia czytelności i przejrzystości kodu. Brak odpowiednich mechanizmów na poziomie składni języka spowoduje powstawanie “potworków”, które w dłuższej perspektywie będą miały więcej wad niż zalet. Brak dziedziczenia, a co za tym idzie – hierarchii typów w języku C spowoduje, że wszystkie “abstrakcyjne” interfejsy będą musiały nolens volens rzutować niejawnie wskaźniki, struktury… To bardzo nieeleganckie, a co gorsze, niebezpieczne rozwiązanie, które dodatkowo utrudnia jakiekolwiek debugowanie kodu.

Pamiętajmy w tym miejscu również o tym, że tworzymy kod opisujący GUI. Nie wymaga on real-time’owej responsywności – jego wykonanie może trwać nieco dłużej 🙂 Kilka-kilkanaście milisekund to wieczność z perspektywy CPU, dla człowieka to mniej niż mgnienie oka. Walka o pojedyncze cykle zegara nie jest więc absolutnie potrzebna!

Osobiście jestem wielkim fanem języka C – cenię go za minimalizm i zwięzłość semantyki. Pod wieloma względami jest to język idealny do niskopoziomowych zabaw ze sprzętem czy sprytnych algorytmów. jednak w pewnych sytuacjach muszę uznać wyższość jego młodszego brata – i to bez cienia sentymentu!