Prawdę mówiąc, większość tych przykładów pokazuje nowe elementy biblioteki standardowej i nie wymaga C++20.
Chociażby std::format jest oparty na libce fmt, która wymaga tylko C++11.
std::expected ma wersję dla C++11 tutaj.
Natomiast std::range jest dostępny od C++14/17.
Chyba jedyne rzecz,y których autentycznie nie dałoby się zrobić przed C++20 to:
koncepty (template <std::integral number>),
uproszczona deklaracja funkcji szablonowej (voidf(auto x, auto y))
std::source_location (bo kompilator musi wygenerować metadane).
No ale domyślam się, że dopiero wprowadzenie bibliotek do standardu spowoduje, że szersze grono developerów zainteresuje się tymi możliwościami.
To tylko zachęta do nauki nowych rzeczy, bo mogą być praktyczne.
Wydaje mi się, że adopcja zmian w takich językach jest bardzo powolna. Pewnie większość programistów nie używa nawet 11. Nie chodzi o to jakiego std używają w kompilatorze, tylko jakiego typu piszą kod.
Ciekawe w jakiej branży jest najwięcej programistów tego języka.
Chyba embedded. Kiedys powiedziałbym, że gamedev, ale obecnie C# jest chyba bardziej popularny w tej branży.
Ludzie w firmach często nawet nie wiedzą, jaka wersja C++ jest wspierana przez dostępne narzędzia.
Mnóstwo ludzi nadal koduje używając praktycznie C++98, pomimo dostępu do feature’ów z C++17 czy 20.
Powszechne jest też przekonanie, że wdrożenie mechanizmów z nowszych wersji standardu powoduje często błędy kompilacji.
Tymczasem prawdziwą przyczyną tego problemów jest zazwyczaj agresywna optymalizacja w nowych kompilatorach, która ujawnia tylko stare błędy w istniejącym kodzie.
Kiedyś recenzowałem kilka źródeł. Proponowałem, że można zastąpić niektóre fragmenty nowocześniejszymi wyrażeniami. Niewiele to dało. Są ważniejsze problemy, niż zmuszanie ludzi do używania nieznanych przez nich elementów języka.
Nowoczesne wyrażenia mają kilka teoretycznych zalet. Mają one wartość jeśli cała reszta jest idealną kulą wody.
Prawdę mówiąc, większość tych przykładów pokazuje nowe elementy biblioteki standardowej i nie wymaga C++20.
Chociażby
std::formatjest oparty na libce fmt, która wymaga tylko C++11.std::expectedma wersję dla C++11 tutaj.Natomiast
std::rangejest dostępny od C++14/17.Chyba jedyne rzecz,y których autentycznie nie dałoby się zrobić przed C++20 to:
template <std::integral number>),void f(auto x, auto y))std::source_location(bo kompilator musi wygenerować metadane).No ale domyślam się, że dopiero wprowadzenie bibliotek do standardu spowoduje, że szersze grono developerów zainteresuje się tymi możliwościami.
To tylko zachęta do nauki nowych rzeczy, bo mogą być praktyczne.
Wydaje mi się, że adopcja zmian w takich językach jest bardzo powolna. Pewnie większość programistów nie używa nawet 11. Nie chodzi o to jakiego std używają w kompilatorze, tylko jakiego typu piszą kod.
Ciekawe w jakiej branży jest najwięcej programistów tego języka.
Chyba embedded. Kiedys powiedziałbym, że gamedev, ale obecnie C# jest chyba bardziej popularny w tej branży.
Ludzie w firmach często nawet nie wiedzą, jaka wersja C++ jest wspierana przez dostępne narzędzia.
Mnóstwo ludzi nadal koduje używając praktycznie C++98, pomimo dostępu do feature’ów z C++17 czy 20.
Powszechne jest też przekonanie, że wdrożenie mechanizmów z nowszych wersji standardu powoduje często błędy kompilacji.
Tymczasem prawdziwą przyczyną tego problemów jest zazwyczaj agresywna optymalizacja w nowych kompilatorach, która ujawnia tylko stare błędy w istniejącym kodzie.
Pan z tego postu https://tech.pr0n.pl/post/41701 twierdzi, że GD jest jedną z trzech największych branży używających C++.
Kiedyś recenzowałem kilka źródeł. Proponowałem, że można zastąpić niektóre fragmenty nowocześniejszymi wyrażeniami. Niewiele to dało. Są ważniejsze problemy, niż zmuszanie ludzi do używania nieznanych przez nich elementów języka.
Nowoczesne wyrażenia mają kilka teoretycznych zalet. Mają one wartość jeśli cała reszta jest idealną kulą wody.