Co słychać w nadchodzącym C++14

Ta notatka została oznaczona jako wymagająca dopracowania: img transp.
Zawartość wpisu może ulec zmianie, zatem zapraszam do ponownych odwiedzin w niedalekiej przyszłości :)

Powolnymi, acz zdecydowanymi krokami zbliża się nowy standard języka C++ oznaczony jako C++14. Niektórzy jeszcze nie oswoili się z C++11, a biznes ciągle w epoce kamienia łupanego - C++98/03, bądź “C z klasami”. A tutaj wkrótce kolejna dawka nowości i emocji. Od czasu wejścia obecnego standardu, komitet nieźle przyspieszył, można powiedzieć, że wreszcie chce nadążać za rynkiem i potrzebami. W tym celu planuje co kilka lat wydawać wersję major i_ minor_ nowego standardu tegoż języka, docelowo co 3 lata. Idealnie przedstawia to wykres timeline, jaki można znaleźć na podstronach isocpp.org prezentującej bieżący status prac standaryzacyjnych lub na blogu Herba Suttera (prezentowana niżej wersja pochodzi z czasów pre C++17).

Zmiany wprowadzane w C++14 w zamyśle mają być głównie poprawkami i rozszerzeniami funkcjonalności i elementów wprowadzonych przez C++11. Taki mały minor release, coś czym C++03 było dla C++98. Dopiero kolejny wielki major release, aka C++17 będzie wprowadzał wiele większych zmian i nowości - ale o nim może w niedalekiej przyszłości.

Pierwszy draft nowego standardu został opublikowany 15 maja zeszłego roku, a obecnie aktualny draft to dokument N3797, co nieznaczny jednoznacznie, że w tym roku wejdzie w życie, w takiej lub innej, zmienionej formie. Pamiętamy, jak długo przebiegał proces związany z C++11, początkowo znany jako C++0x, podobnie C++14, znane jako C++1y może mieć małe obsunięcie, ale bądźmy dobrej myśli.

Osobiście C++14 zainteresowałem się w kwietniu zeszłego roku, po konferencji (spotkaniu) komitetu w Bristol. A wszystko zaczęło się od ciekawego i pełnego raportu ze spotkania, opisującego wszystkie propozycje i zmiany wprowadzane w C++, opublikowane na Meeting C++ w serii artkułów “A look at C++14” (part I, II, III i IV). Podobne zestawienie ukazało się po spotkaniu komitetu standaryzującego w Chicago, jesienią zeszłego roku. Dostępny spis papers-ów, które brały udział w dyskusji można znaleźć w artykule “C++ Papers for Chicago” (part I, II, III, IV). Na sesji w Wietrznym mieście, poruszano również kwestie kolejnych standardów, zatem nie wszystkie przedstawione dokumenty i propozycje dotyczą C++14. Ogólnie spora dawka wiedzy do przetrawienia i dyskusje.

Prócz ogólnych poprawek i rozszerzeń C++11, nowy standard definiuje kilka TS (Technical Specification) dla systemu plików (oparta głównie na boost.filesystem) i obsługi sieci. Obie one mają wielkie znaczenie, być może wreszcie zawartość biblioteki standardowej będzie pozwalała na tworzenie coraz bardziej cross-platformowych aplikacji, bez uciekania się do niezależnych implementacji. Ta druga specyfikacja - obsługa sieci - szczególnie mnie interesuje. Bo od jakiegoś czasu, tworząc różne rozwiązania sieciowe, borykam się z prostą, niskopoziomową i przenośną implementacją socketów, szczególnie w podejściu OOP, ale bez zbędnych narzutów. Coś w tym kierunku od czasu do czasu robię, możliwe, że wkrótce ujrzy to światło dzienne.

Oprócz tych większych zmian, które wejdą prawdopodobnie do std::experimental (przypomina mi się TR z C++98/03), z ciekawszych poprawek i usprawnień funkcjonalności z C++11 można wyliczyć kilka najpopularniejszych. Z tych dotykających samego core języka: usprawnienia z lambda i auto - lepsza dedukcja typów i generyczne lambdy (ahh, wreszcie), poluzowanie polityki constexpr, szablony zmiennych, literały binarne, dynamiczne tablice i inne. A z tych związanych z standardową biblioteką: make_unique, shared mutex i lock, std::optional i inne.

Zignoruję tutaj głębsze przedstawianie, bo większość szczegółów i szerszych opisów można znaleźć w dokumentach z propozycjami lub podsumowaniach spotkań, o których było wyżej. Podobnie na isocpp.org pojawiły się małe wzmianki po spotkaniowe “Trip Report” (prawdopodobnie autorstwa Herba Suttera) - po Brtistolu - ISO C++ Spring 2013 Meeting i po chicagowskiej imprezie - Fall ISO C++ meeting.

Co ciekawsze elementy, które mnie zaciekawiły lub na które długo oczekiwałem, na pewno będę starał się w najbliższym czasie szerzej przedstawić. Ewolucja C++ postępuje i wiele się zmienia, także w samym używaniu tego języka. Wiele idiomów poprzestaje być używane, stają się deprecated, bo dużo rzeczy można zrobić inaczej, lepiej i prościej w nowoczesnym C++, ktorego niestety tak mało jeszcze programistów zna i używa.

Trafiłem na ciekawą wzmiankę w jednym z tych raportów, że komitet dąży do doktrynizacji programistów C++, aby oduczyć ich używania new i delete oraz raw pointerów, na rzecz używania inteligentnych wskaźników i helperów typu make_*. Co w większości przypadków pozwoli uniknąć wielu błędów z dangling pointers w C++. I w pewnym stopniu jeszcze bardziej spopularyzuje idiom RAII, dzięki któremu nie potrzeba m.in. znanego z innych języków finally przy wyjątkach. Oczywiście w pewnych sytuacjach niskopoziomowych i specyficznych (ale i nie tylko) czasem trzeba jednak ręcznie bawić się alokacją i zwalnianiem zasobów z wielu różnych względów, chociażby wydajnościowych. Z czym zgadzam się całkowicie. Choć z drugiej strony, gdy widzę różne fragmenty kodu naszpikowane do granic wytrzymałości samymi smart pointerami, bez zastanowienia i przemyślenia, szczególnie shared_ptr w sytuacji, gdy lifetime obiektu (-ów) jest jasny i w pełni znany, to chwytam się za głowę. Programowanie mimo wszystko wymaga myślenia.

Obecnie wiele rzeczy będzie można zrobić na wiele sposobów. Popatrzmy na możliwości jakie daje nam język i biblioteka w kontekście tablic. Mamy zwykłe o stałym rozmiarze i dynamiczne tablice w samym języku oraz ich “odpowiedniki” funkcjonalne w bibliotece standardowej - std::array i std::dynarray, a prócz tego jeszcze stary, poczciwy std::vector:

// static array - compile-time sized
void foo() {

	constexpr size_t n = 16;

	// both on stack
	int tab1[n];
	std::array<int, n> tab2;

	...
}

// dynamic array - run-time sized
void bar(size_t n) {

	int tab1[n];				// on stack
	std::dynarray<int>(n) tab2;	// on heap
	std::vector<int>(n) tab3;	// on heap

	...
}

Jestem ciekaw, jak niektórzy będą sobie radzić z wyborem odpowiedniego kontenera, a każdy ma swoje wady i zalety, czasem lepiej stosować jeden, czasem drugi. Bolączką niektórych programistów, jest nadmierne używanie sterty - alokowanie pamięci dynamicznej dla elementów lub obiektów, które mogłyby bardzo dobrze poleżeć na stosie. Po co marnować cykle na kosztowną alokacje, gdy nie ma żadnych logicznych przesłanek i potrzeb trzymania tego na stercie, a wiele takich obiektów same w sobie trzymają kolejne elementy na stercie - agregator wskaźników lub uchwytów zasobów…

W zeszłym miesiącu (w lutym) również odbyło się kolejne spotkanie komitetu, na Meeting C++ jeszcze przed nim pojawił się raport prezentujący propozycje i dokumenty, jakie będą poruszane na tym spotkaniu - C++ Papers for Issaquah (part I, II, III i IV). Za bardzo nie wczytywałem się jeszcze w treść, więc ciężko mi w tej chwili powiedzieć, czy jest coś związanego i ciekawego w kwestii C++14. Na pewno dużo ciekawych rzeczy, które być może wejdą w niedalekiej przyszłości do naszego ulubionego języka i biblioteki. Trip report z samego zimowego spotkania - Winter ISO C++ meeting.

Ciągle napływają jakieś propozycje i usprawnienia języka na blogu isocpp.org pojawiają się informacje o każdym takim dokumencie, warto czasem rzucić okiem co tam się wyprawia ;)