MSVC 14.51 ile C++23 Desteği: Sahadan Notlar

⏱️ 9 dk okuma📅 14 Nisan 2026👁️ görüntülenme

Geçen hafta bir müşterinin build sunucusunda garip bir derleme hatasıyla boğuşuyordum. Sorun ne biliyor musunuz? Adam constexpr fonksiyonun içine static değişken tanımlamış, derleyici de bunu yutmuyor. “Bu niye çalışmıyor ya?” dedi. Ben de dedim ki: “Kardeşim, MSVC versiyonun eski. 14.51’e geç, bu artık C++23 ile destekleniyor.” Gözleri parladı. İşte bugün tam da bu konuyu — MSVC Build Tools 14.51 ile gelen C++23 yeniliklerini — sahadan örneklerle anlatacağım.

Bakın, ben ağırlıklı olarak Azure. Bulut tarafında çalışan biriyim ama C++ ile aram hiç kopmadı, dürüst olmak gerekirse. 2004’te hosting şirketinde Linux üzerinde C++ ile küçük sistem araçları yazıyordum. Şimdi Logosoft’ta danışmanlık yaparken bile müşterilerin CI/CD pipeline’larında derleme sorunlarını çözmek bana düşüyor çoğu zaman. Bu yüzden MSVC’nın her yeni sürümü beni doğrudan ilgilendiriyor.

C++23 Neden Bu Kadar Önemli?

Açıkçası, Şunu söyleyeyim: C++20 gerçek bir devrimdi. Concepts, coroutines, modules… Öyle bir sürüm ki herkes “artık modern C++ tamam” dedi. C++23 işe farklı bir şey yapıyor. Devrim değil, evrim. Pratik hayatı kolaylaştıran, “aa bunu niye daha önce yapmadık ki” dedirten iyileştirmeler getiriyor — ve bu bence küçümsenmemesi gereken bir şey, çünkü en büyük verimlilik kayıpları zaten küçük sürtünme noktalarından geliyor.

Microsoft’un MSVC derleyicisi de bu özellikleri yavaş yavaş implemente ediyor. 14.51 ile ciddi bir adım attılar. Hepsini tek seferde getirmediler — ki bu bence mantıklı (ki bu çoğu kişinin gözünden kaçıyor). Mantıklı değil mi? Yarım yamalak implement etmektense parça parça ama sağlam getirmek her zaman daha iyi.

Ha, bir de şunu belirteyim: Bu özellikler /std:c++23preview veya /std:c++latest bayraklarıyla aktif oluyor. Varsayılan ayarlarla derliyorsanız hiçbir şey değişmez. Bilinçli olarak opt-in yapmanız gerekiyor.

Derleme Zamanı Değerlendirmede Büyük Rahatlama

Bence bu sürümün en can alıcı yenilikleri constexpr tarafında. İki özellik var — ikisi de günlük C++ yazımını ciddi şekilde etkiliyor.

Static constexpr Değişkenler constexpr Fonksiyonlarda

Yazının başında bahsettiğim müşteri hikayesini hatırlıyor musunuz — İşte tam olarak bu özellik. Artık şöyle bir şey yazabiliyorsunuz:

constexpr char xdigit(int n)
{
static constexpr char digits[] = "0123456789abcdef";
return digits[n];
}

Eskiden bu kod derleme hatasına neden oluyordu. Niye? Çünkü constexpr fonksiyon içinde static değişken tanımlayamazdınız. Adamlar “ya bu static, derleme zamanında olmaz” diyordu. Ama dur bir saniye — değişken zaten constexpr, yanı değeri derleme zamanında biliniyor. Niye izin vermiyorsun ki? Mantığını hiçbir zaman tam kavrayamamıştım açıkçası.

Hani, Bu kısıtlama yüzünden insanlar ya global scope’a taşıyordu bu tabloları ya da fonksiyonun dışına çıkarıyordu. Kod okunabilirliği düşüyordu. Şimdi artık o sürtünme kalktı. 2023’te bir telekomünikasyon projesinde tam bu yüzden lookup tablolarını global scope’a taşımak zorunda kalmıştık — artık o acının tekrarlanmasına gerek yok. Küçük bir değişiklik gibi görünüyor ama büyük projelerde etkisi baya hissediliyor.

Peki neden?

constexpr Kısıtlamalarının Gevşetilmesi

Bu da fena değil. Şöyle bir senaryo düşünün:

void bar();
// Artık kabul ediliyor, sadece çalışma zamanında çalışır
constexpr void foo()
{
bar();
}

Bunu yaşayan biri olarak söyleyeyim, Eskiden derleyici burada “bar() constexpr değil, foo()’yu constexpr yapma” diye hata veriyordu. Ama aslında foo() çalışma zamanında gayet kullanılabilir. Derleme zamanında çağırmaya kalkarsan tabi ki hata alırsın — ama tanımlamanın kendisi artık sorun değil. Güzel ayrım bu.

Bunun pratikte ne işe yaradığını anlatayım. Diyelim ki bir kütüphane yazıyorsunuz; fonksiyonunuzun bazı kullanım senaryolarında derleme zamanı değerlendirmesi mümkün, bazılarında değil (en azından benim deneyimim böyle). Eskiden ya constexpr koymuyordunuz (ve derleme — kendi adıma konuşayım — zamanı kullanıcılarını kaybediyordunuz) ya da bar()’ı sarmalamanız gerekiyordu. Şimdi “ikisini de yaparım” diyebiliyorsunuz.

Evet, doğru duydunuz.

Kütüphane geliştiricileri için bu özellik kritik. Bağımlılık zincirindeki bir fonksiyonun constexpr durumu değiştiğinde, sizin fonksiyonunuz artık kırılmıyor. Aslında… bu tam olarak “API stabilitesi” meselesi.

Unicode Desteğinde İyileştirmeler

Şunu söyleyeyim, C++ ve Unicode — hmm, tarihsel olarak “karmaşık” bir ilişki desem yeridir. Ama C++23 ile işler düzeliyor. MSVC 14.51’de üç önemli Unicode özelliği geldi.

İlki, sayısal ve evrensel karakter kaçışları (P2029R4). İkincisi, adlandırılmış evrensel karakter kaçışları (P2071R2) — yanı artık \N{LATIN SMALL LETTER A WITH ACUTE} gibi okunabilir kaçış dizileri kullanabiliyorsunuz. Üçüncüsü işe karakter setleri ve kodlamalar konusunda genel bir düzenleme (P2314R4).

Açık konuşayım: Bu özellikler çoğu geliştirici için “arka planda çalışan” şeyler. Ama uluslararası yazılım geliştiren ekipler için — özellikle Türkçe, Arapça, Çince gibi Latin dışı karakter setleriyle çalışanlar için — bu iyileştirmeler çok değerli. Geçen sene bir finans kuruluşunda Türkçe karakter içeren log mesajlarıyla uğraşırken bu tür detayların ne kadar önemli olduğunu bir kez daha anlamıştım. Sız hiç denediniz mi? O seferde saatlerce harcadık, yanı (en azından benim deneyimim böyle) Daha fazla bilgi için GitHub Pages ile Ücretsiz Site Kurulumu: Tam Rehber yazımıza bakabilirsiniz.

Diğer C++23 Dil Özellikleri

Derleme zamanı ve Unicode dışında birkaç özellik daha var. Hepsini tek tek uzun uzun anlatmayacağım ama kısa bir bakış vereyim:

Özellik	Proposal	Ne İşe Yarıyor?
Portable Assumptions	P1774R8	Derleyiciye optimizasyon ipuçları vermek için `[[assume(expr)]]` attribute’u
Labels at End of Compound Statements	P2324R2	C uyumluluğu: blok sonuna etiket koyabilme
CTAD from Inherited Constructors	P2582R1	Kalıtılan constructor’lardan template argüman çıkarımı
Meaningful Exports	P2615R1	Modül export’larında anlam tutarlılığı

Portable Assumptions (P1774R8) bence özellikle ilginç — ve biraz ürkütücü de, dürüst olmak gerekirse. [[assume(x > 0)]] yazdığınızda derleyiciye “bu koşul her zaman doğru” diyorsunuz, derleyici de buna göre optimize ediyor. Tehlikeli mi? Evet, biraz. Yanlış kullanırsanız undefined behavior’a açık kapı bırakıyorsunuz. Ama performans can alıcı kodlarda — mesela oyun motorları, HFT sistemleri — işe yarayabilir. Dikkatli kullanın.

Labels at the end of compound statements işe neredeyse tamamen C uyumluluğu meselesi. C ile çalışan ekipler — evet, hâlâ çok var, şaşırmayın — için hayat kolaylaştırıcı. Büyük bir yenilik mi? Hayır. Ama “niye daha önce yoktu” dedirtiyor.

CWG ve LWG Sorun Çözümleri: Perde Arkası

İşin bir de göze çarpmayan ama kilit tarafı var. MSVC 14.51, bir sürü Core Working Group (CWG) ve Library Working Group (LWG) sorununu da düzeltiyor. Bunlar genelde “edge case” dediğimiz köşe durumlarla ilgili. Normal kullanıcı fark etmez ama standart uyumluluğu açısından çok önemli.

Dikkat Çeken CWG Düzeltmeleri

Mesela CWG 2355 — noexcept belirteclerinin çıkarımı. Template fonksiyonlarda noexcept’in doğru şekilde deduce edilmesiyle ilgili bir sorundu bu. Ya da CWG 2490 — constant expression’larda destructor kullanımındaki kısıtlamalar — valla güzel iş çıkarmışlar —. Çok niş konular gibi görünüyor, haklısınız, ama kütüphane yazarları için gerçekten baş ağrıtıcı şeylerdi bunlar.

Bir de CWG 2484 var: char8_t ve char16_t integral promotion’ları. Unicode desteğiyle de bağlantılı bu. Karakter türlerinin aritmetik işlemlerde nasıl terfi ettiğiyle ilgili bir düzeltme (buna dikkat edin) Daha fazla bilgi için .NET Agent Skills: Üç Yöntem, Tek Sağlayıcı yazımıza bakabilirsiniz.

💡 Bilgi: CWG ve LWG düzeltmeleri genelde “breaking change” olmaz. Mevcut kodunuzun çalışmasını bozmaz ama daha önce yanlış derlenen veya beklenmedik davranış gösteren kodları düzeltir. Yine de büyük projelerde yükseltme sonrası regresyon testi yapmanızı şiddetle tavsiye ediyorum.

LWG Tarafında Neler Var?

Kütüphane tarafında da epey düzeltme gelmiş. std::expected‘ın monadic operasyonlarıyla ilgili sorunlar (LWG 3938), std::generator ile ilgili detaylar, std::format iyileştirmeleri… Liste uzun. Bunların hepsini burada sıralamak yerine şunu söyleyeyim: C++23 kütüphanelerini aktif kullanıyorsanız 14.51’e geçmek ciddi anlamda bug sayınızı düşürebilir. Az önce “ciddi anlamda” dedim ama — aslında bu biraz projeye bağlı, tabi. Yeni özellikleri hiç kullanmıyorsanız etkisi minimal olur. Kubernetes 1.36 Ön İzleme: Neler Geliyor, Neler Gidiyor? yazımızda bu konuya da değinmiştik. Bu konuyla ilgili ChatGPT ile Araştırma: Search ve Deep Research Rehberi yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Copilot Cloud Agent Doğrulama Araçları %20 Hızlandı yazımıza bakabilirsiniz.

Pratikte Nasıl Kullanıyoruz?

Gelelim asıl meseleye. Bu özellikleri nasıl aktif edeceksiniz?

Visual Studio 2022’nın son Preview sürümünü kullanıyorsanız zaten Build Tools 14.51’e sahipsiniz. Proje ayarlarından C++ Language Standard’ı /std:c++23preview veya /std:c++latest olarak değiştirmeniz yeterli. CMake kullanıyorsanız:

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

Ama dikkat — CMake tarafı her zaman bu kadar temiz çalışmıyor. Bilhassa cross-platform projelerde GCC veya Clang’ın C++23 desteğinin farklı bir aşamada olduğunu unutmayın. Geçen ay bir müşteride tam bu sorunu yaşadık: Windows’ta MSVC ile derleniyor, Linux’ta GCC 13 ile derlenmiyor. Sebebi? GCC o spesifik C++23 özelliğini henüz implemente etmemişti. Bu tür projeler için feature test macro’larını kullanmak şart. Gerçekten şart, görmezden gelmeyin.

CI/CD pipeline’larınızda derleme yapıyorsanız — ki yapıyor olmanız gerekiyor — GitHub Code Scanning’de Toplu Düzeltme: PR’lar Hızlandı yazımda bahsettiğim gibi otomatik tarama araçlarıyla yeni derleyici sürümünde regresyon olup olmadığını kontrol edin.

Kurumsal Projeler İçin Tavsiyelerim

Garip gelecek ama, Küçük bir startup iseniz — hemen geçin. Ciddi ciddi söylüyorum. C++23’ün getirdiği constexpr esneklikleri tek başına geçiş sebebi olabilir. Yeni proje başlıyorsanız doğrudan /std:c++latest ile başlayın, neden erteliyorsunuz ki? (evet, doğru duydunuz)

Ama enterprise seviyede bir proje yürütüyorsanız… dur bir dakika. 2024’te bir bankacılık projesinde MSVC versiyonunu yükseltmek 3 aylık bir iş oldu. Üç ay. Niye? Çünkü binlerce birim test var, düzenleyici uyumluluk gereksinimleri var, üçüncü parti kütüphanelerin uyumluluğu var — ve bunların hepsi ayrı ayrı doğrulanması gereken şeyler. Sadece derleyici değiştirmek bile bir “proje” hâline geliyor, inanın.

Tavsiyem şu: Önce bir sandbox ortamda deneyin. Kritik modüllerinizi yeni derleyiciyle derleyin, — itiraz edebilirsiniz tabi — testleri koşun, sonuçları karşılaştırın. Sorun yoksa aşamalı geçiş yapın. Ha bu arada, MSVC’nın PowerShell’de MSI Dönemi Bitiyor: MSIX’e Geçiş Rehberi yazımda bahsettiğim gibi paketleme tarafında da değişiklikler olabiliyor — bunu da gözden kaçırmayın.

C++23 Desteği Tamamlandı mı?

Şöyle söyleyeyim, Hayır. Açık söyleyeyim: henüz tam değil. Microsoft’un kendisi de bunu kabul ediyor zaten. 14.51 ile önemli bir adım atıldı ama tamamlanması için birkaç sürüm daha gerekecek gibi dürüyor. Hele bir de kütüphane tarafında — std::stacktrace, std::flat_map gibi bazı bileşenler hâlâ tam implemente edilmedi.

İşte tam da bu noktada devreye giriyor.

Kağıt üstünde “C++23 preview” deniyor ama pratikte bazı köşeler eksik kalabiliyor. Bu beni biraz hayal kırıklığına uğrattı, açıkçası. GCC ve Clang ile karşılaştırınca MSVC’nın geride kaldığı alanlar var — bunu görmezden gelmek doğru olmaz. Ama Microsoft’un son birkaç yıldaki ivmesi umut verici. Hızlanıyorlar, bu görünüyor.

Bir de learn.microsoft.com dokümantasyonunun güncellenmesi “sürüm tam desteğe geçmeden önce” planlanmış (kendi tecrübem). Yanı şu an dokümanlar tam güncel olmayabilir — feature listesini kontrol ederken buna dikkat edin. Ben birkaç kez yanmıştım bu konuda, sizi uyarmak istedim.

Sıkça Sorulan Sorular

MSVC 14.51’deki C++23 özelliklerini kullanmak için Visual Studio’nun hangi sürümü gerekiyor?

Bakın, visual Studio 2022’nın en son Preview sürümü bu Build Tools’u içeriyor. Release kanalına henüz gelmemiş olabilir, o yüzden Preview kanalını takip etmeniz gerekiyor. Proje özelliklerinden dil standardını /std:c++23preview olarak ayarlamanız yeterli.

constexpr fonksiyonlardaki yeni esneklikler mevcut kodumuzu bozar mı?

Hayır, bu değişiklikler genişletici nitelikte. Eskiden derlenen kod derlenmeye devam eder. Sadece daha önce hata veren bazı kullanımlar artık kabul ediliyor. Yine de kapsamlı projelerinizde regresyon testi yapmanızı öneririm — her ihtimale karşı.

Bunu biraz açayım.

C++23 özellikleri production’da kullanılabilir mi yoksa sadece deneysel mi?

Aslında, Bayrak adında “preview” geçmesi biraz korkutucu ama Microsoft’un implemente ettiği özellikler genelde stabil oluyor. Yine de kritik production sistemleri için ben biraz beklerdim — en azından full support sürümü çıkana kadar. Startup ve yeşil alan projelerde rahatça kullanabilirsiniz.

GCC ve Clang ile cross-platform projede C++23 kullanabilir mıyım?

İtiraf edeyim, Kullanabilirsiniz ama her derleyicinin implementasyon durumu farklı. Feature test macro’larını (__cpp_constexpr, __cpp_static_assert gibi) kullanarak platform bağımsız kod yazmanızı şiddetle tavsiye ediyorum. Her üç derleyiciyi de CI’da test edin.

CWG ve LWG düzeltmeleri beni niye ilgilendirsin?

Eğer standart kütüphaneyi yoğun kullanıyorsanız veya template metaprogramming yapıyorsanız, bu düzeltmeler daha önce fark etmediğiniz bug’ları ortadan kaldırabilir. Kütüphane geliştiricisi değilseniz muhtemelen doğrudan hissetmezsiniz (yanlış duymadınız). Dolaylı olarak bağımlılıklarınız üzerinden etkisi olur.