RTTI | Run-Time Type Information - 1

RTTI, Run-Time Type Information'ın kısaltmasıdır. Çalışma zamanında tür bilgisinin elde edilmesi anlamına gelmektedir. Bunun için ilgili türlerin polimorfik olması gerekmektedir.  Bir türün polimorfik olması için en az bir tane kendisinde veya base türünde virtual bir metodun tanımlanmış olması gerekmektedir. Her sınıfın (objenin degil) kendine özgü bir vtable'ı bulunmaktadır. Basit olarak vtable yapısı aşağıdaki gibidir.

Tür bilgisi vtable içerisinde yer aldığından dolayı böyle bir yapısal ilişki - zorunluluk olmaktadır. type_info değeri aşağıda da görebileceginiz üzere vtable içerisindedir.

 C++ 'da RTTI mekanizmasının 3 farklı kullanım senaryosu vardir:

  • typeid operatörü
  • type_info sınıfı
  • dynamic_cast işlemi 

typeid ve type_info 

typeid operatörü bir nesnenin dinamik tipini öğrenmek için kullanılır. Ve typeid operatörü, bir type_info nesnesini const bir referans olarak döndürür. Daha sonra ihtiyaca göre bu nesneyi diğerleriyle karşılaştırabilir veya türün ismini yazdırabiliriz.


typeinfo ise bir sınıf türündendir. Ve genelde typeid operatörünün geri dönüş değerleri sınıfın == operatörü ile karşılaştırılabilir. Türlerin eşitliği için name karşılaştırmasına göre == karşılaştırması daha  çok tavsiye edilmektedir.


dynamic_cast 

Derleme zamanının aksine çalışma zamanında bir nesne hakkında type cast işlemi sayesinde tür hakkında bilgi almak için kullanılır. Polimorfik olmayan dillerde bu bilgiye gerek yoktur, çünkü tür her zaman derleme zamanında ve dolayısıyla çalışma zamanında bilinir. C++ gibi polimorfik türleri destekleyen bir dilde, türün derleme sırasında bilinmediği durumlar vardır. Bir pointer, temel sınıf türündeki bir nesneyi veya temel sınıftan türetilen herhangi bir sınıf türündeki bir nesneyi işaret edebilir. Bu nedenle RTTI ve dolayisiyla dynamic_cast ile çalışma zamanında tür hakkında bilgi alınmasına yardımcı olunur.


Yukarıdaki örnekte speak fonksiyonu runtime da gelen parametreye göre iki farklı biçimde davranmaktadır. Burada dynamic_cast'in RTTI mekanizması kullanarak bu işi gerçekleştirdiğini unutmayalım.

vtable layout

g++ icin -fdump-class-hierarchy flag değeri ile vtable (virtual function table) layout değerleri incelenebilir. Program derlenirse cpp dosyasi ile ayni isimde ama uzantı olarak .002t.class şekilde bir dosya oluşturulur. Içeriğine bakarsak :

c++filt aracı ile C++ symbolleri demangle edilirse asağıdaki gibi vtable'ın ikinci elemanı typeinfo 'ya ilişkin olduğu görülmektedir.

Note1 : type_info nesnelerinin copy constructor'ları yoktur. Bu nedenle bir containerda saklamak gibi yöntem doğrudan mümkün değildir. Bunun için sarmalayıcı bir sınıf yazarak mümkün hale gelebilmektedir.

Note2: Normalde RTTI, -fno-rtti flag değeri ile disable edilebilir. RTTI in en temel dezavantajlarından biri çalıştırılabilir kodun boyutunun büyümesidir. RTTI yalnızca belirli türler için devre dışı bırakmak/etkinleştirmek mümkün değildir. Etkinleştirildiğinde ise, RTTI hem yerleşik hem de polimorfik olmayan kullanıcı tanımlı türler için otomatik olarak oluşturulur. Bu da calistirilabilir kodun boyutunun cok büyümesine neden olmaktadır.



Metaprogramming | Variadic Templates & Fold Expressions - 1

C++11 değişken parametreli şablonları desteklemektedir. Dile gelen bu araçla birlikte hem sınıf şablonları (class templates) hem de fonksiyon şablonları (function templates) artık istenen sayıda parametreye sahip olabiliyor. Değişken sayıda parametreye "parametre paketi" (parameter pack) deniyor. Bir şablon parametre listesinde typename anahtar sözcüklerini izleyen üç nokta atomundan (ellipsis) sonra gelen isim, söz konusu şablon parametresinin sıfır ya da daha fazla sayıda türe karşılık geldiğine işaret etmektedir. Bu syntax'ta "typename… Types" şablon parametre paketi (template parameter pack), "Types… values" ise fonksiyon parametre paketi (function parameter pack) olarak isimlendirilmektedir. C++17'den önce variadic template yazılırken recursive bir yapıda yazma metodolojisi izleniyordu. Aşağıdaki örnekte görüleceği üzere ikinci printer() fonksiyonu recursive çağrı yapacak şekilde yazılmıştır.


Yukarıda tek parametreli bir template specialization yapıldığını görebilirsiniz. Toplamda iki tane fonksiyona ihtiyaç duyulmuştur. Peki C++17'den sonra durum nedir?


Yukarıda ilk dikkatimizi çeken nokta tek bir fonksiyonla işin halledilmiş olması. Peki bu nasıl gerçekleşti? Aşağıda fold (katlı ifadelerin açılımı) expression 'ların açılımı görülmektedir.


Burada belirleyici nokta operandların hangi sıraya göre yapılacağıdır. 
  • (… op pack)                 ---->   ((pack1 op pack2 op …) op packN
  • (init op … op pack)   ---->   (((init op pack1) op pack2) op …) op packN
  • (pack op …)                 ---->    pack1 op (… op (packN-1 op packN))
Aşağıda genelleştirilmiş şekilde ifade edildiği ve bir örnek üzerinde açıklandığını görebilirsiniz.


Aşağıda ise fold expression ifadelerin nasıl bir container içine yerleştirilebileceğine ilişkin örneği bulabilirsiniz.


Aşağıda ise C++17 öncesi variadic bir toplama fonksiyonunun yazılışı görülmektedir.


fold expression ile aynı fonksiyonun yazılışı aşağıdaki gibidir.


Soru1: aşağıdaki örnekte std::forward kullanılmasının bize ne gibi avanatajı veya dezavantajı vardır?


Soru2: Aşağıdaki kodun çıktısı ne olur?




Metaprogramming | basic implementation of std::enable_if and SFINAE - 1

std::enable_if C++11 ile hayatımıza giren bir özellik ve Metaprogramming yapılırken SFINAE olarak bilinen idiyomun en önemli kullanım senaryosunu oluşturmaktadır. std::enable_if'in olası implementasyonu aşağıdaki gibidir.


Burada kritik nokta birinci template için sınıfın içinde hiç bir bildirim yapılmazken 2. ise template partial specialization olarak isimlendirilen bir özelleştirilmiş şablon sınıfta typedef bildirimi yapılmış olmasıdır. Birinci şablon parametresi true olursa derleyici kod üretimi için bu şablonu kullanacak. Diğer durumlarda ilkini kullanacaktır. Peki bu bize nasıl bir kullanım olanağı sağlıyor? Aşağıdaki örneği inceleyelim:


Yukarıda göreceğiniz üzere T türü int olursa; enable_if'in template 1. parametresi true olarak açılacak, 2. fonksiyon için false olarak açılacak. Yani implemetasyonda görüleceği üzere type bildirimi olmayan sınıfla ilişkilendirilecek ve doğal olarak failure durumu oluşacak. Bir işlev şablonu derleyici açısından şablon tür parametresinin ne olduğunu bilmek/çıkarım yapmak zorundadır. Şablon tür parametresinin olduğu ya açıkça belirtilmesi gerekir ya da derleyici tarafından bir çıkarım yapabiliyor olması gerekir. Bu anlama işlemi aşıldıktan sonra derleyici şablonda şablon tür parametresinin bulunduğu yerlerde gerçek tür bilgisini kullanmaya başlar. Örneğin T türünün geçtiği her yerde int türünü kullanarak yerine koyma (substituition) işlemi yapar. Bu yer değiştirme işleminde bir başarısızlık olursa (substitution failure) derleyici bu durumu hemen bir sentaks hatası olarak değerlendirip derleme hatası olarak işlemi sonlandırmaz. Önce diğer şablon işlev yüklemelerine de (overloads) bakmak zorundadır. Eğer bir başka yükleme işlev çağrısı için geçerli olursa derleyici bu yüklemeyi seçer ve sentaks hatası oluşmaz. Bu şekilde ilk failure'u error olarak ele almayıp işleme devam edip başarılı olması durumlarına Substitution Failure Is Not An Error denilmektedir. Sonuç olarak yukarıdaki örneğimizde programnımız doğru bir şekilde derlenecek ve ekranda "Integral" yazısı görülecektir. 


Yukarıdaki örnekte görüleceği üzere enable_if'i daha basite indirgeyerek anlatmak istersek bizim için compile time template switch diyebiliriz. Belirli şartlar sağlanırsa ilgili fonksiyonun çağrılıp çağrılmamasına karar verme mekanizması diyebiliriz. Ve yukarıdaki örnek için bizim fonksiyonumuz sadece integral türler için çalışacak şekilde yazılmış fakat main içinde bu fonksiyonu double türüyle kullanmaya çalıştığımızda hata verecektir.


Yukarıdaki örnekte ise geri dönüş türü üzerinden enable_if'in kullanılmasına bir örnek verilmiştir. Sınıfın 2 tane check fonksiyonu Car sınıfı hangi türden template açılım yapıldı ise açılım yapılan türün V6Engine türünde ise true dönen fonksiyona açılım yapılacak diğer durumlarda false'a geri dönen fonksiyonun açılımı yapılacak şekilde özelleştirilmiştir.

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.