Evet arkadaşlar, bu hafta da C++ 17 ile işimizi kolaylaştıracak birden fazla kabiliyete hızlıca değiniyor olacağım.
Malum, C++ 20 çıktı, C++ 23 de yolda, bir an önce onlara yetişiyor olmamız lazım 🙂 İlaveten, uEngine de fırından çıktı o çocuğa ilişkin de yazacaklarımız olacak elbette.
Şimdi gelin, değineceğimiz kabiliyetlere bir göz atalım:
- nested namespaces
- using ile birden fazla tipin dahil edilmesi
- Mesaj içermeyen static_assert
- __has_include
Gördüğünüz üzere, oldukça fazla kalem var ama açıkçası çok da karmaşık olmadıkları için kısaca bilgiler verip geçiyor olacağız. Detaylandırmamı istediğiniz kabiliyet olursa, her zaman yorumlarda belirtebilirsiniz.
İçerik
Nested Namespaces
Evet, iç içe isim uzayları olarak nitelendirebileceğimiz bu kabiliyet isminde de anlaşılacağı üzere daha kolay ve okunabilir bir şekilde, isim uzaylarını tanımlamanıza olanak sağlamakta. Hemen bir örnek ile daha yakından bakalım. C++ 17 öncesinde, iç içe isim uzaylarını aşağıdaki gibi tanımlamanız gerekmekteydi (elbette kabiliyeti göstermek için örneği biraz zorladım):
|
1 2 3 4 5 6 7 |
namespace uEngine{ namespace Networking{ namespace FTP{ /* ... */ } } } |
bunu artık
|
1 |
namespace uEngine::Networking::FTP{ /* ... */ } |
diyerek de tanımlayabileceksiniz.
Bu yaklaşıma ilişkin öneriye ve detaylarına https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4026.html adresinden ulaşabilirsiniz. Bunun sıkıntısına ve C++ 17 öncesinde nasıl çözümler geliştirildiğine göz atmak için https://seanmiddleditch.github.io/unnest-c-namespaces/ sayfasına göz atabilirsiniz.
Her ne kadar genel olarak olumlu kabul görse de, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0816r0.pdf gibi yaklaşımlar da mevcut.
Ben açıkçası, tanımlama açısından kolaylık getireceği kanısındayım.
using ile birden fazla tanım ile kullanımı
C++ 17 öncesinde using ile bir tane tipi dahil etmeye yönelik deklerasyon yapabiliyordunuz ama C++ 17 ile aynı anda birden fazla tip tanımının kullanım da mümkün olabilmekte. Hemen bir örnek ile inceleyelim:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
#include <iostream> using namespace std; namespace uEngine::Networking::FTP{ class FTP{}; constexpr unsigned int cDefaultFTPPort {21}; } namespace uEngine::Networking::HTTP{ class HTTP{}; constexpr unsigned int cDefaultHTTPPort {80}; } int main() { using uEngine::Networking::FTP::cDefaultFTPPort, uEngine::Networking::HTTP::cDefaultHTTPPort; cout << "Varsayilan FTP Portu: " << cDefaultFTPPort << '\n' << "Varsayilan HTTP Portu: " << cDefaultHTTPPort << '\n'; return 0; } |
Mesaj içermeyen static_assert:
static_assert, sizlere derleme zamanında bir takım uyumsuzluklar hakkında bilgilendirmek için kullanılabilecek ve C++ 11 ile dile kazandırılan bir kabiliyetti. Bu kabiliyet ile birlikte, verilen bir boolean (derleme zamanında hesaplanabilecek) değerlendirme ışığında hata mesajı verilmekteydi. Örneğin 32Bit derleyici ile kodun derlendiğinden emin olmak için aşağıdaki gibi kod parçası ekleyip, ilgili kodu 64 Bit derleyici de derlediğinizde:
|
1 2 3 4 |
int main() { static_assert(sizeof(void*) == 4, "32 bitlik derleme yapilmali!"); return 0; } |
|
1 2 |
"main.cpp:15:5: error: static assertion failed: 32 bitlik derleme yapilmali! static_assert(sizeof(void*) == 4, "32 bitlik derleme yapilmali!");" |
gibi bir hata alırsınız. C++ 17 ile birlikte, static_assert’in ikinci parametresine ihtiyaç kalmadı. Şöyle ki, aşağıdaki gibi bir kullanım da artık mümkün:
|
1 2 3 4 |
int main() { static_assert(sizeof(void*) == 4); return 0; } |
Bu durumda alacağınız hata ise, aşağıdaki gibi olacak:
|
1 2 |
"main.cpp:15:5: error: static assertion failed static_assert(sizeof(void*) == 4);" |
__has_include
C++ 17 ile gelen bir diğer kabiliyet, özellikle, çoklu platformlar için yazılım geliştirenlerin işini kolaylaştıracak nitelikte. Ama şunu da söylemem gerekiyor ki, bu kabiliyet ile sunulan şeyleri başka mekanizmalar ile de yapabiliyorduk fakat bu biraz daha temiz ve tanımlı yol sunmakta. Hemen referans sayfasında (ve öneride olan https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061r1.html) bulunan, std::optional ile ilgili örneğe bir bakalım. Bu örnekte, ilgili başlık dosyasının olup/olmamasına göre, kullanılan optional dosyası değiştirilmekte:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
#if __has_include(<optional>) # include <optional> # define have_optional 1 #elif __has_include(<experimental/optional>) # include <experimental/optional> # define have_optional 1 # define experimental_optional 1 #else # define have_optional 0 #endif // Optional var mi #if have_optional == 1 #ifndef experimental_optional std::optional<int> oint; // Yokmus #else std::experimental::optional<int> oint; #endif |
Ayrıca, https://www.cppstories.com/2019/07/hasinclude/ sayfasında, özellikle benim de daha önce OpenGL uygulaması geliştirirken başvurduğum ve sıkıntı yaşadığım bir konuya nasıl çözüm getirdiğini göstermiş. Bazı platformlar için, OpenGL başlık dosyalarının bulunduğu dizinler değişiklik gösterebilmekte. Bu sebeple, birden fazla platforma hitap eden kütüphaneler geliştirirken bu hususa dikkat etmeniz gerekiyor. Ör. aşağıdaki kodta APPLE için nasıl bir yol izlendiği gösterilmiş:
|
1 2 3 4 5 6 7 |
#ifdef __APPLE__ # include <OpenGL/gl.h> # include <OpenGL/glu.h> #else # include <GL/gl.h> # include <GL/glu.h> #endif |
burada açık bir şekilde __APPLE__ makrosuna atıf var. __has_include ile bu kod parçası aşağıdaki gibi yazılabiliyor ve bu sayede sadece APPLE değil benzer kullanıma sahip bütün platformları da kotarmış oluyoruz.
|
1 2 3 4 5 6 7 |
#if __has_include(<GL/gl.h>) # include <GL/gl.h> # include <GL/glu.h> #else # include <OpenGL/gl.h> # include <OpenGL/glu.h> #endif |
Evet sevgili yazılımperver dostlarım bir C++ yazımın daha sonuna geldik. Bir sonraki yazımda görüşmek dileğiyle, bol kodlu günler 🙂
Kaynaklar
- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4026.html
- https://seanmiddleditch.github.io/unnest-c-namespaces/
- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0816r0.pdf
- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061r1.html
- https://www.cppstories.com/2019/07/hasinclude/