Cpp Idioms etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
Cpp Idioms etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

RAII (Resource Acquisition Is Initialization idiom) - 1

Aşağıda gördüğümüz kod geleneksel kaynak erişim ve kaynakların iade edilmesine ilişkin bir örnek senaryodur. Burda 1 numaralı alanda kaynaklar ediniliyor sonra bu kaynaklarla belirli işlemler gerçekleştiriliyor ve ardından 2 numaralı alanda kaynaklar iade ediliyor.  Burada 2 tane senaryoya dikkat çekmek gerekiyor. Birincisi yazılım geliştiricisinin kaynaklarının iadesini UNUTMASI, ikincisi ise kaynakları iade etmeden exceptiona neden olunacak bir işlemin gerçekleşmesi ya da return edilmesi gibi durumlar. İşte bu noktada RAII devreye giriyor ve bu problemlerin çözümüne ilişkin bir senaryoyla karşımıza çıkıyor.


RAII idiyomu diğer bir değişle Resource Acquisition Is Initialization C++' ta popüler bir kaynak yönetim şekli. C++'ta sınıflara ilişkin nesneler yaratılırken constructor ile hayata gelir ve objenin ömrü bittiğinde destructor çağrılarak alınan kaynaklar teslim edilir. Çoğunlukla nesneler local scope içerisinde yaratılırlar ve scope'tan çıkıldığında (normal akışında, return veya exception) ömürleri de biter. Fakat bazı nesneler ise new anahtar kelimesi  ile oluşturulur ki heap'de dinamik hafıza alanında yer tahsis edilerek oluşturulur. Ve delete anahtar kelimesi ile destructor çağrısı yapılarak kaynaklar iade edilir. Bu yaşam döngüsü RAII idiyomunun dışındadır. RAII ismi aslında idiyoma doğru bir karşılık gelen ifade değildir. Aslında idiyomun anlatmak istediği aşağıdaki gibi bir isimlendirme ile daha doğru olarak karşılanacaktır.


Artık isimlendirme bu şekilde yapıldığı için RAII'yi kullanmaya devam edeceğiz ama idiyomu doğru anlamak içinse yukarıdaki isimlendirmeleri de bir kenara not edelim.

RAII'nin faydaları:

  • Exception Safety: exception safe bir kaynak yönetimi sağlamaya olanak sağlayacaktır.
  • Clean Code: kaynakların tahsis edilmesi ile iade edilmesi aynı sınıf içerisinde gerçekleşeceği için temiz bir kod yazımına olanak sağlayacaktır. 
  • Encapsulation: kaynakların yönetimi her sınıfın kendi içerisinde ve dışarıdan erişimi mümkün olmadan sağlandığı için bir encapsulation sağlayacaktır.


Yukarıdaki sınıfa bakarsak artık dosya kaynağına erişim constructor ile gerçekleşiyor, destructorda dosyanın kapatılarak kaynakların iadesini gerçekleştiriyor.


Bu sayede kaynağa erişim sağlayan kodun kaynak yönetimi encapsulation edilmiş oluyor ve kullanıcı tarafta temiz bir kod yazılmasını, dışarıdan kaynak yönetilmesine ihtiyaç kalmadan gerçekleştirilmiş oluyor. Bu konuya ilişkin bir sonraki yazımızda ise exception ve RAII ilişkine değinen yazımızı yazacağız.

ADL (Argument Dependent Lookup) - 1

14:35 ,

Compiler isim araması yaparken bulunduğu isim alanı ve global isim alanı dışında fonksiyon parametresine bağlı olarak bir arama daha yapmaktadir.


Yukaridaki en temel Argument Dependent Lookup örneğinde görebileceginiz üzere normalde alert() fonksiyonu baska bir isim alanı içerisinde olsa da fonksiyonun parametresi ADL namespace içerisinde oldugu için compiler buraya da bakacak ve sonuç olarak fonksiyon uygun fonksiyon çağrısını yapabilecektir.


Yukarida ise global alanda ve ADL namespace'i icerisinde aynı imzalı fonksiyonlar bulunduğu için  compiler ikilemde kalacak ve asağıdaki gibi derleme hatası verecektir.
 

Yukarıdaki hatayı düzeltmek için fonksiyon çağrısını aşağıdaki gibi yapmak mümkündür.


Şimdi ADL'nin daha kompleks problemlerini inceleyelim:


Yukaridaki örnekte ADL devreye girer ve namespace içerisindeki foo fonksiyonunu çağırır diye tahmin yürütsekte ifade geçerli olmayacak ve compıler bar'ı sadece int türünden bir değişkebn olarak görecek ve aşagıdaki gibi hata ile karşılaşırız. 


Asağıda ise beklentilerin tersine sonuclanan ikinci örneği görmek mümkün. Normalde Mercedes sınıfı içerisindeki foo çağrısı doğrudan sınıfın üye fonksiyonu olan foo() 'nun üzerinden yapılmaya çalışacak ve bunun karşılığı olarak parametreli çağrı yapıldığı için hata verecektir. 


Compiler 2 nolu fonksiyon cağrısını yapmak isteyecek 1 nolu fonkiyonu dikkate almayacaktır. Bu nedenle aşağıdaki gibi derleme hatası oluşacaktır. 


Asağıda ise beklentilerin tersine sonuçlanacak olan üçüncü örneği görmek mümkündür. Burada bar fonksiyonu içerisinde extern fonksiyon bildirimi yapılmıştır.


 Ve bunun sonucu olarak 2. örnektekine benzer bir hata ile karşılaşılmıştır.


Eğer extern bildirimi yapılmazsa global foo() fonksiyonunun bulunması derleme hatasına neden olmayacak ve derleme hatasız sonuçlanacaktır.


C++ Idioms | Attorney Client Idiom - 1


C++ için önemli idiomlardan biri de Attorney Client Idiom olarak isimlendirilen idiomdur. Temel olarak nesne yönelimli programlamanın önemli ilkelerinden birisi olan encapsulation'ı bozabilecek durumları ortadan kaldırmak için geliştirilmistir. Encapsulation ilkesinin temeli verinin bütünlüğünü bozabilecek tüm fonksiyonların veya üyelerinin dışarıdan erişime kapalı olmasını sağlamak üzerinedir. Bunun icin sınıfın private bölümü kullanılmaktadır. Bu sayede sınıfın dışarıya sunduğu interface ile implementation kısmı birbirinden ayrılmış olmaktadır. Fakat hayatta her şey siyah/beyaz olmadığı gibi burada da benzer bir durum vardır. Bazen sınıfın private bölümüne sınıfın kendi kodlarının dışında dışarıdan erişilebilmesi durumu bazı problemler için en iyi çözüm haline gelebilmektedir. Bunun için C++ dilinin bize sunduğu friend'lik kavramı üzerinden bu sağlanabilmektedir. C++ 'da bir sınıf bir global işleve, başka bir sınıfın bir üye işlevine ya da başka bir sınıfın tüm işlevlerine bir arkadaşlık (friend) bildirimi ile, kendi private bölümüne erişim hakkı vermektedir. C++’ta friend bildirimiyle, yalnızca sınıfın belirli private öğelerine erişim hakkı vermek gibi bir özellik şimdilik mümkün değil. Eğer bir sınıfa arkadaşlık verirseniz sınıfınızın tüm private öğelerini o sınıfın erişimine açmış oluyoruz. Peki biz bu problemi nasil aşacağız? Ayrıca friend'lik iki sınıf arasındaki bağımlılığı (coupling) arttıran bir durum. Bu da SOLID prensiplerine uymayan bir durum. Sınıfınızın private bölümünde değişiklik yaptığınızda arkadaşlık verdiğiniz sınıfların kodlarında da bakım/değişiklik yapılması gerekmetedir. Bu da istenmeyen bir durumdur. Arkadaşlık vermek en makul çözümse olabilse de bu noktada coupling'i azaltmak için sınıfın private öğelerinin tümünü erişime açmak yerine yalnızca bu ihtiyaca konu private öğeleri erişime açmak daha iyi bir çözüm olacaktir. Bunun için C++ dünyasında kullanılan çözüm iki sınıf arasında bir 3. sınıf oluşturmak ve iki sınıf arasındaki ilişkiyi bu 3. sınıf üzerinden yapmak olacaktir. Iste bu noktada kabul gören çözüm olan Attorney Client Idiyom 'unun nasıl yapıldığına geçmek en mantıklısı olacaktır.


Yukarıdaki örnek için Engine sınıfının m_id ve m_hashValue olarak iki üye elemanı bulunmakta ve bir nedenle bunlardan sadece birini dışarıya açmak istemekteyiz. Bu noktada friend' lik vermek dışında başka bir çözümümüz bulunmadığını düşünelim. Işte bu durumda yukarıdaki gibi vekil bir sınıf (CarAttorney) yaratıp Engine sınıfın friend 'liğini bu sınıfa vererek, gerçek sınıfa ise friendliği bu vekil sınıftan verilerek arada bir katman oluşturulur. Ve hedeflenen sınıf sadece bizim CarAttorney sınıfında implemente ettiğimiz static işlevler dışında verinin bütünlüğünü bozacak hiç bir duruma izin verilmemiş olur.


Arkadaşlık bildirimleri taban sınıflardan kalıtım yoluyla türemiş sınıflara geçmez. Bu ne demek? Taban sınıfın arkadaşlık verdiği Helper sınıfı yukarıdaki örnekte CarAttorney sınıfı türemiş sınıfın (V6Engine) private bölümüne erişmesi mümkün değildir. Ancak taban sınıf tarafından arkadaşlık verilen bir sınıf, taban sınıfın private bölümünde bildirilen bir virtual işlevi taban sınıf göstericisi/referansı ile çağırdığında, dynamic polymorphism gereği türemiş sınıfın virtual işlevinin çağrılması mümkündür. Bu sayede yukarıdaki örnekte BMW sınıfının printHashValue fonksiyonu CarAttorney sınıfı üzerinden yapılan çağrıda türemiş sınıfın ilgili fonksiyonuna doğrudan erişim yetkisi olmamasına rağmen CarAttorney tarafından çağrılacaktır.



CTAD (Class Template Argument Deduction)

CTAD (Class Template Argument Deduction); template fonksiyonlara ilişkin deduction guide line gibi sınıflar için de benzer şekilde C++17 ile standartlara gelmiştir. Bu sayede sınıflara ilişkin doğrudan explicit olarak belirtmeye gerek kalmadan bu görevi de compiler' a havale edilmesi sağlanmıştır. Ve daha kısa ve anlaşılır kodlar yazılmasına olanak sağlanmıştır. CTAD 'ın daha anlaşılır olması için aşağıdaki iki örneğe bakalım.

C++11 oncesi
C++17 öncesi
Yukarıdaki örnek için C++17 öncesi class template argument 'lerini doğrudan (explicit) olarak bildirmemiz gerekmektedir. Aksi halde hata ile karşılaşılmaktadır. Fakat C++17 ile bu problemler çözülmüştür. 

C++17 sonrası
Şimdi tam bir template class yazalım ve C++ 'in  11 - 14 ve 17 standartlarına göre derlemeye çalışalım.


Yukaridaki örneği C++11 ve C++14 ile derlemeye çalıştığımız zaman aşağıdaki gibi bir hata ile karşılaşılmaktadır. Fakat C++17 ile derledigimiz zaman ise sorunsuz derlenebilmektedir.


C++17 öncesi için yukaridaki problem aşağıdaki şekilde kodu güncelledigimiz zaman ortadan kalkmaktadir.


Fakat C++17 öncesi için de farklı bir workaround bulunmaktadır. Örnegin make_pair fonksiyonu ile yukarıdaki 17. satırdaki işlemi make_pair ile explicit olarak tür belirtmeden yapmak mümkündür. 



C++ Style Guide | AAA (Almost Always Auto)


Modern C++'ile birlikte soldan sağa doğru bir bildirim stilinde değişme görülmeye başlanmıştır.Bu değişimin sebebi C++11 ile gelen auto anahtar sözcüğüdür. Bu değişim artık bildirimlerin sol tarafinda sadece auto' nun yer almasını ve diger tüm bildirimleri sağ tarafa aktarmak  şeklinde kısaca söylenebilir. Bu idiyomun genel kabul görmüş hali AAA (Almost Always Auto) olarak C++ dünyasına girmistir. Aşağıda geleneksel olarak yazılmış C++ kodunu görmekteyiz.


 Şimdi yukarıdaki kodu AAA idiyomuna göre değiştirelim.


Aşağıda ise daha kompleks kullanım senaryolarını görebilirsiniz.