Referencje do r-wartości. Semantyka przeniesienia to jedna z kluczowych koncepcji nowoczesnego języka C++, która zadebiutowała w C++11. Sam język potrzebował …
W odróżnieniu od std::unique_ptr, std::shared_ptr opiera się na współdzieleniu właśności (ang. shared ownership) przechowywanego zasobu. Z tego powodu możemy posiadać wiele inteligentnych wskaźników typu std::shared_ptr, wskazujących na ten sam obiekt w pamięci.
Ten koncept ma bardzo dużo wspólnego z realizacją automatycznego odśmiecania pamięci w innych językach programowania, ponieważ klasa std::shared_ptr ma zaimplementowany mechanizm tzw. zliczania referencji.
Do tej pory wpisy na temat C++11 dotyczyły bardzo ważnych i przydatnych zmian w języku. Jednak to zarządzanie pamięcią i wskaźniki doczekały się największych, fundamentalnych usprawnień w nowym standardzie – jednym z najważniejszych są tzw. inteligentne wskaźniki.
Oczywiście nadal można ręcznie zarządzać pamięcią w C++ – to fundament języka. Nie wyklucza to jednak wprowadzania nowych rozwiązań, które przyczyniają się do drastycznych zmian w sposobie zarządzania życiem obiektów i jednocześnie eliminują większość paskudnych błędów.
Czasami zachodzi potrzeba uniemożliwienia wywołania konkretnej funkcji. A dokładniej – zadbania o to, żeby zdefiniowanej wcześniej funkcji nie można było użyć w kodzie importującym/używającym wcześniej zdefiniowanych konstrukcji.
Najciekawsze są sytuacje, w których kompilator samodzielnie jest w stanie wygenerować teoretycznie potrzebne funkcje i użyć ich, co pozbawia nas niejako kontroli nad tym procesem. Przykładem są tutaj choćby funkcje szablonowe, czy też automatycznie generowane konstruktory oraz operatory w klasach.
W poprzednim wpisie z serii C++11 opisałem specyfikator override. Niejako w parze z nim występuje specyfikator final, który również odnosi się do przeciążania funkcji wirtualnych w klasach pochodnych.
Mówiąc krótko: jeśli nie chcemy, żeby funkcja wirtualna była dalej przeciążana (w kolejnych klasach pochodnych w hierarchii), możemy użyć słowa final w deklaracji funkcji – dokładnie tak samo, jak wykorzystujemy override.
Do każdego aspektu języka, z którego korzystamy, możemy mieć mniejsze lub większe uwagi. Oczywiście również posiadam swoją subiektywną listę niedociągnięć, jeśli chodzi o język C++.
Pomimo tego, że bardzo docieniam polimorfizm i sposób zaimplementowania tego mechanizmu, za niedopracowane uważam kwestie związane z dziedziczeniem i wykorzystaniem funkcji wirtualnych w C++.
Większość programistów języka C++ zna doskonale typy wyliczeniowe (enum), zdefiniowane w standardzie C++98/03. Jest to wygodne, często wykorzystywane narzędzie. Jest to jednak również funkcjonalność, która posiada kilka zauważalnych niedociągnięć, przez co użycie typów wyliczeniowych nie jest tak przyjemne i odporne na błędy, jak mogłoby być.
W standardzie C++11 doczekaliśmy się pod tym względem malutkiej rewolucji – zdefiniowane zostały tzw. silne typy wyliczeniowe (ang. strongly-typed enums).
Dzisiejszy temat dotyczy jednego z najbardziej zdumiewających problemów poprzednich standarów języka C++. Dlaczego zdumiewających ? Między innymi dlatego, że udało mu się przetrwać dzielnie kilkanaście lat (!), pomimo swojej nieskomplikowanej natury – chodzi o podwójne nawiasy kątowe.
Ale jak to się stało ?
Spójrzmy na poniższy kod:
Standard C++11 zajął się na poważnie jedną z kluczowych kwestii w kontekście języka – oznaczaniem wskaźników pustych (nieważnych). Nowościami są tutaj słowo kluczowe nullptr, oznaczające wskaźnik pusty oraz typ wskaźnika pustego, czyli std::nullptr_t.
nullptr jest literałem, który powinien być używany w kodzie źródłowym i oznacza wskaźnik pusty. Czym różni się on od wartości NULL, która wywodzi się z języka C i była do tej pory stosowana również w C++ ?
Poprzednio rozmawialiśmy o znaczeniu słowa kluczowego auto w C++11. Zakresowa pętla for jest często używana w parze ze słowem auto. Sam pomysł jest rozwinięciem koncepcji zwykłej pętli for o funkcjonalności, które w innych językach programowania są realizowane np. poprzez pętlę foreach.