std::variant, C++17'de, hataya açıktan ve elle yönetilen C tarzı birleşenlerin yerini alması amacıyla güvenli bir birleşim alternatifi olarak tanıtılmıştır. Belirtilen alternatif tiplerinden tam olarak birini her zaman tutma şartını yerine getirerek, derleme zamanında tür güvenliği ve sezgisel değer anlamı sağlar. Bu tasarım, teorik olarak, std::visit veya std::get gibi işlemlerin her zaman üzerinde işlem yapabilecek geçerli bir türe sahip olmasını garanti eder.
valueless_by_exception durumu, tür değiştirme işlemleri sırasında meydana gelen bir istisna nedeniyle değişkenin hiçbir değer taşımadığı belirli bir hata modunu temsil eder. Bu durum, değişkenin mevcut alternatifini yok etmesi ve yeni bir alternatif için yer açması gerektiğinde, yeni alternatifin inşası sırasında bir istisna fırlatıldığında ortaya çıkar. Sonuç olarak, nesne geçerli bir aktif üye olmadan bırakılır ve bu da standart varyantın şartını geçici olarak bozar.
Standart tarafından sağlanan çözüm, bu tekil geçersiz duruma izin vermektir; bu da temel istisna güvenliği garantilerinin korunmasını sağlar. Bu durumda, varyant yok edilebilir ve atanabilir durumda kalır, bu da kaynakların temizlenmesine ve depolama alanına yeni değerlerin yerleştirilmesine olanak tanır. Bu durumdan tamamen kurtulmak için yeni bir değer başarıyla atanmalı veya yerleştirilmelidir; bu, geçerli bir alternatif oluşturarak ve dahili durumu sıfırlayarak şartı geri getirir.
std::variant<std::string, int> v = "hello"; try { v.emplace<std::string>(10000000, 'x'); // bad_alloc atabilir } catch (...) { assert(v.valueless_by_exception()); v = 42; // Kurtarma: geçerli tekrar }
std::variant<PriceUpdate, OrderCancel, TradeExecution> şeklinde temsil edilen piyasa verisi mesajlarını işleyen yüksek frekanslı bir ticaret sistemi düşünelim. Bellek kısıtlı bir senaryoda, büyük bir TradeExecution nesnesi ataması, varyantın önceki PriceUpdate'i yok etmesinden sonra std::bad_alloc fırlatır ve bu da bir valueless varyantın boru hattında iletilmesine yol açar, bu da aşağı akış kodunun geçerli verilerin mevcut olduğu varsayımında bulunması durumunda yayılma hatalarına neden olabilir.
Bir çözüm, her varyant erişimini valueless_by_exception() kontrolleriyle ve herhangi bir ziyaret veya alma işlemi öncesinde manuel kurtarma mantığı ile sarmak olmuştur. Bu yaklaşım, belirsiz davranışa karşı kesin bir güvenlik sağladı, ancak her kullanım noktasında savunma kontrolleri ile kod tabanını da karmaşıklaştırdı; bu da okunabilirliği belirgin şekilde azalttı ve kritik ticaret yolunda kabul edilemez bir gecikmeye neden oldu.
Başka bir yaklaşım, boş durumu varyantın kendisi dışına çıkaran std::optional<std::variant<...>> kullanmayı düşündü. Bu, iç varyantın her zaman geçerli bir tür taşımasını garanti ederek varyantın iç şartını korusa da, her erişimde çifte dolaylama gerektirerek API yüzeyini karmaşıklaştırdı ve yüksek hacimli işleme sırasında önbellek yerelliğini etkileyebilirdi.
Ekip, nihayetinde varyant tür listesinde ilk alternatif olarak std::monostate'i seçti ve böylece varyantın normal tür sistemi içinde açık bir "boş" durum ayırmış oldu. Bu seçim, valueless durumunun tamamen ortadan kaldırılmasını sağladı, çünkü varyant her zaman std::monostate tutabilme olanağına sahip oldu, böylece index() her zaman geçerli bir pozisyon döndürdü ve std::visit ya gerçek verilere ya da boş durum yöneticisine başarıyla iletildi.
Sonuç, ayrılma hatalarını zarif bir şekilde yöneten sağlam bir mesaj işlemcisiydi; böylece bir olağan dışı geçersiz durum yerine monostate alternatifine geçiş yapıldı. Bu tasarım, valuelesslık için çalışma zamanında kontroller gerektirmeden ve çifte dolaylama yükleri yaşamadan katı tür güvenliğini korudu. Geliştiriciler, varyantın her zaman ziyaret edilebilir olduğuna güvenebilir, monostate yöneticisi ise boş mesajlar için bir no-op veya varsayılan davranış olarak işlev görebilir.
Neden std::variant durumu valueless_by_exception'ı, değişkenin her zaman belirtilen türlerden birini tutması gerektiği temel tasarım ilkesini ihlal etmesine rağmen izin verir?
Standart, sıkı bir şartı her durumda korumaktan ziyade güçlü bir istisna güvenliğini önceliklendirir. Tutulan alternatifi değiştirirken, varyant eski değeri yok etmelidir, böylece yeni bir değer inşa ederken kaynak sızıntılarını veya çifte mülkiyet sorunlarını önleyebilir. Eğer bu yeni yapılandırma istisna atarsa, varyant önceki duruma geri dönemeyeceği için bu depolama alanı zaten yok edilmiştir ve yeni duruma geçişi de tamamlayamaz. valueless_by_exception durumu, nesnenin yok edilebilir ve atanabilir olduğunu, ancak geçerli bir alternatifi bulunmadığını gösteren gerekli bir kaçış kapısıdır; bu da eski değerin hala var olduğunu ya da depolamanın başlatılmamış bırakılmasından kaynaklanacak belirsiz davranışları önler.
valueless_by_exception durumuna girmiş bir değişkende std::visit çağrıldığında nasıl bir davranış sergiler ve bu, std::monostate tutan bir değişkeni erişmekten neden farklıdır?**
std::visit, valueless bir varyantla karşılaştığında hemen std::bad_variant_access atar; çünkü aktif tip indeksi variant_npos'dur ve bu, herhangi bir ziyaretçi aşırı yüklemesine karşılık gelmemektedir. Bu, std::monostate'den köklü olarak farklıdır; çünkü bu belirli bir tür listesi içindeki belirli bir indeks pozisyonunu işgal eden geçerli ama boş bir türdür. Bir ziyaretçi, boş durumları normal kontrol akışı içinde zarif bir şekilde ele almak için std::monostate için belirli bir aşırı yükleme sağlayabilir. Valueless durumu, tür bilgilerinin tamamen kaybolduğu gerçek bir hata koşulunu temsil ederken, monostate, tür sisteminin içinde normal bir ziyaret mekanizmasına katılan geçerli, kasıtlı bir boş durumu temsil eder.
Bir değişken, valueless_by_exception durumundan, değişken nesnenin kendisini yok etmeden ve yeniden inşa etmeden kurtarabilir mi ve bu kurtarma işlemlerini hangi özel işlemler kolaylaştırır?
Evet, kurtarma, değişken sarmalayıcısını yok etmeden atama veya emplace işlemleri aracılığıyla mümkündür. v = T{} veya v.emplace<T>(args) işlemlerini yürüttüğünüzde ve T türünün inşası başarılı olursa, varyant valueless durumundan çıkarak yeni türü tutar. Bu, bu işlemlerin otomatik olarak geçerli bir değerle depolamayı yeniden başlattığı ve dahili indeksi variant_npos'dan T pozisyonuna sıfırladığı için mümkündür. Varyanttan okuma yapmak ya da değiştirmeyen gözlemcileri çağırmak durumu değiştirmeyecektir; yalnızca depolamaya yeni bir değer yerleştiren başarılı bir işlem, sınıf şartını geri getirip valueless bayrağını false olarak sıfırlayabilir.