Sorunun geçmişi
C++20'de std::span'ın tanıtımı, C++ Çekirdek İlkeleri'nin gsl::span'inden uzun süredir var olan bir idiyomun standartlaşmasını işaret etti. Tasarım hedefi, ham işaretçi-uzunluk çiftlerini API'lerde değiştirmek suretiyle ardışık diziler üzerinde maliyetsiz bir soyutlama sağlamaktı. Komite, performans özelliklerini ham işaretçilerle uyumlu tutmak için sahiplik anlamlarını açıkça reddetti ve bu, std::string_view'un felsefesi ile uyumlu hale getirildi. Bu karar, C tarzı dizilerle ve eski kodlarla birlikte çalışabilirlik ihtiyacından kaynaklandı ve tahsisat yükü getirmeden devam etti. Sonuçta, std::span, özellikle ömür yönetimi ile ilgili olarak, sahip olmayan görünümlerin temel sınırlamalarını miras aldı.
Problemin tanımı
Tehlike, bir std::span prvalue konteynerden, örneğin değerle dönen bir fabrika fonksiyonunun dönüş değeri olan std::vector<T>'den başlatıldığında ortaya çıkar. Bu senaryoda, geçici vektör tam ifadelerin sonunda yok edilir, ancak std::span vektörün tahsis edilmemiş yığın depolama alanına olan iç işaretçileri korur. std::span, derleyicinin ömür analizinde ham işaretçi çiftinden ayırt edilemeyen basit bir kopyalanabilir tür olduğundan, dil bu sarkan referans için zorunlu bir tanılayıcı sağlamaz. C++20 standardı, std::span'ın ödünç alınmış bir aralığı modellediğini belirtse de bu kavram yalnızca aralık tabanlı döngüler ve algoritmaları etkiler, temel depolama ömür kurallarını değil. Bu durum, söz diziminin güvenli kapsayıcı kullanımı ile harmanlandığı için yanlış bir güven duygusu yaratır, oysa tanımsız davranış, yerel bir değişkene işaretçi döndermekle benzerlik gösterir.
Çözüm
Aşırı önlem almak, ömür uzatma ilkelerine sıkı sıkıya bağlı kalmayı ve statik analizden yararlanmayı gerektirir. Geliştiriciler, std::span'in referans gösterdiği sahiplik konteynerinin ömründen daha uzun yaşadığından emin olmalıdır, bu da genellikle görünümü oluşturmadan önce konteynerin adlandırılmış bir değişken olarak bildirilmesiyle gerçekleştirilir. Geçici öğelerden yapılacak başlangıçları yakalamak için cppcoreguidelines-pro-bounds-lifetime kontrolü ile Clang-Tidy gibi araçların kullanılması önerilir. API tasarımı için, işlevler std::span'ı lvalue argümanlar için değer olarak kabul etmeli, ancak çağırıcının depolama geçerliliğini koruması gerektiğine dair ön koşulları belgelendirmelidir. Sahiplik anlamlarının gerekli olduğu durumlarda, std::unique_ptr<T[]> veya doğrudan std::vector'ı tercih edin ve std::span'ı yalnızca çağıranın ömrü garanti ettiği işlev parametresi geçişi için kullanın.
#include <span> #include <vector> #include <iostream> std::vector<int> generate_buffer() { return std::vector<int>(1024, 42); // Geçici vektör } void process(std::span<int> data) { // Eğer veriler sarkıyorsa tanımsız davranış std::cout << data.front() << '\n'; } int main() { // Sarkıyor: geçici tam ifade sonrası yok process(generate_buffer()); // Güvenli: kapsayıcı span'den daha uzun yaşıyor auto buffer = generate_buffer(); std::span<int> safe_view(buffer); process(safe_view); }
Gerçek zamanlı bir ses işleme motorunda, bir karıştırıcı iş parçacığı std::vector<float> değerini döndüren bir codec sarmalayıcısından ayrıştırılmış PCM verilerini aldı. Karıştırıcı, kopyalama yapmaktan kaçınmak için DSP algoritmasına geçmek üzere hemen bir std::span<float> oluşturdu ve her geri çağrıda kilobaytlarca ses verisi kopyalamak zorunda kalmadı. Kalite güvencesi sırasında, uygulama, çöp toplayıcının (bir köprülenmiş C# ortamında) tetiklendiği bir zamanda bozulmuş ses artefaktlarıyla birlikte aralıklı olarak çökmekteydi ve bu, C++ tampon erişimiyle çakışıyordu.
Mühendislik ekibi, ömür uyumsuzluğunu çözmek için üç ayrı yaklaşımı düşündü.
İlk yaklaşım, karıştırıcı iş parçacığına ait önceden tahsis edilmiş bir dairesel tampon içine vektör verilerini kopyalamayı içeriyordu. Bu, std::span'in her zaman geçerli belleğe işaret etmesini sağladı ve sarkan referansları tamamen ortadan kaldırdı. Ancak, memcpy işlemi kanal başına yaklaşık 5 mikrodetik sürüyor ve bu da ses geri çağrısı için 1 milisaniyelik sert gerçek zamanlı süre sınırını aştığı için bu çözüm düşük gecikmeli gerekmeleri için uygunsuz hale geldi.
İkinci yaklaşım, codec sarmalayıcısının bir referans parametresi std::vector<float>& doldurmasını önermişti, döndürme yerine. Bu, vektörün ömrünü çağıranın kapsamına uzatıyordu. Geçiciliği ortadan kaldırsa da, API'nin değişmezlik garantilerini bozuyor ve çağıranı vektörün kapasitesini yönetmeye zorluyordu; bu da her çağrı yerinde karmaşık nesne havuzlama mantığına yol açtı ve kodun netliğini azalttı.
Üçüncü yaklaşım, std::shared_ptr<std::vector<float>> tutan ve std::span<float>'ye örtük dönüşüm yapan özel bir AudioBufferHandle sınıfı kullanıyordu. Karıştırıcı, işleme için span'ı hemen çıkartarak bu referans tutucusunu kabul etti; referans tutucunun yıkıcı işlemi, vektörü DSP işlemi tamamlanana kadar canlı tutuyordu. Bu yaklaşım, sıfır kopyalama gerekliliğini korurken RAII ile birlikte ömür güvenliğini sağladığı için seçildi ve referans sayma yükü, ses işleme yüküne göre önemsizdi.
Sonuç, ASAN (AdresSızıntıDenetleyici) ve TSAN (İş ParçacığıSızıntıDenetleyici) kontrollerinden geçerek yoğun yük altında çökme yaşamayan bir ses boru hattıydı, ancak geliştiricilerin span'ı referans tutucunun ömründen daha uzun süre saklamalarını önlemek için dikkatli bir dokümantasyon gerektiriyordu.
Neden std::span<int> s = {1, 2, 3}; gibi bir süslü başlangıç listesi kullanılarak başlatılan bir std::span sarkan bir işaretçi ile sonuçlanırken, std::vector<int> v = {1, 2, 3}; süresiz olarak geçerli kalıyor?
Süslü başlangıç listesi, geçici bir std::initializer_list<int> oluşturarak, kavramsal olarak otomatik depolama süresi olan tamsayıların geçici bir dizisine işaretçi tutar. std::span, bu başlangıç listesine, çıkarım kılavuzları aracılığıyla bağlandığında, geçici dizinin işaretçilerini yakalar. Geçici dizi tam ifadelerin sonunda yok edilir ve span'ı sarkan halde bırakır. Buna karşılık, std::vector bir yerleştiriciye sahiptir ve elemanları, vektör yok edilene kadar kalıcı olacak yığın depolamaya kopyalar. Adaylar genellikle tanımlama listelerinin sözdizimini kapsayıcı kurucularıyla karıştırır; oysa std::span herhangi bir tahsisat veya kopyalama yapmadığı için sadece bir görüş görevi görür.
std::span'ın otomatik depolama süresi ile nasıl etkileşimde bulunduğu ve bir fonksiyondan döndüğünde neden bir constexpr span'ın yerel statik olmayan bir diziye işaret etmesinin tanımsız davranışa yol açabileceği nedir?**
std::span bir literal türdür, constexpr kullanımına izin verir, ancak constexpr yalnızca başlangıçların derleme zamanında değerlendirilebilir olmasını zorunlu kılar; bu, temel dizinin depolama süresini değiştirmez. Eğer bir fonksiyon yerel statik olmayan bir dizi tanımlayıp buna bir constexpr std::span döndürürse, dizi otomatik depolama süresine sahiptir ve fonksiyon çıkışında yok edilir; bu da span'ı hemen geçersiz kılar. Karışıklık, adayların constexpr değişkenlerin otomatik olarak statik depolama sürelerine sahip olduğunu veya derleyicinin sabit ifadelerde sarkan durumları önleyebileceğini varsaymasından kaynaklanır; oysa std::span sadece işaretçileri kapsar ve otomatik değişkenlere işaret eden işaretçiler, constexpr niteliklerinden bağımsız olarak geçersiz hale gelir.
Bir fonksiyondan dahili olarak bir konteyner oluşturarak güvenli bir şekilde döndürülebilmesine engel olan spesifik kısıtlama nedir ve bu, benzer ancak ince farklı kısıtlamalarla karşılaşan std::string_view ile nasıl bir tezat oluşturur?
Hem std::span hem de std::string_view sahip olmayan görünümler olsa da, std::string_view genellikle statik depolama süresine sahip string literal'lerle kullanılır ve bu da sarkan问题leri gizler. Bir fonksiyon, std::vector veya std::string oluşturup bunlara bir span/görünüm döndürmeye çalıştığında, konteyner fonksiyon çıkışında yok edilir ve görünüm geçersiz olur. Anahtar fark şu ki, std::string_view null ile sonlanan string literal'lerine (const char[]) bağlanabilir ve bunlar statik ömre sahiptir, bu da şu tarz kalıpların güvenli olmasını sağlar: std::string_view get() { return "literal"; }, oysa std::span, geçici bir dizi oluşturulmadığı sürece diz mermilerine bağlanamaz. Adaylar sıklıkla std::span'ın std::string_view'dan daha genel olduğunu ve string literal depolama için özel bir durumu olmadığını gözden kaçırarak, yerel konteynerlerden span döndürmenin koşulsuz olarak güvensiz olduğunu unutur.