Küçük bir detay: Geçen hafta bir müşteride, yıllardır kullandıkları eski bir C++ kod tabanını ARM64’e port etmeye çalışıyorduk. Adam haklı olarak sordu: “Aşkın, biz neden hâlâ MSVC’nın Preview kanalını takıp edelim ki? Stable yetmiyor mu?” Ben de bir an durdum. Sonra dedim ki: “Bak, ffmpeg gıbı bir kütüphane kullanıyorsan. ARM64 tarafındaysan, bu ay çıkan v14.52 sayesinde miscompile bug’ından kurtuluyorsun; yanı mesele biraz da burada düğümleniyor.”
İşin aslı şu: MSVC Build Tools Preview, çoğu C++ geliştiricisinin radarında değil. Halbuki Visual Studio 2026 Insiders kanalını takıp ediyorsanız, derleyici güncellemeleri haftalık geliyor, bazen insan şaşırıyor açıkçası; Mayıs 2026 sürümü (v14.52.36328) özellikle ARM64 tarafında birkaç can sıkıcı noktayı toparlamış durumda. Vektörleştirici tarafında da fena olmayan dokunuşlar var. Gelin sırayla bakalım — ama klasik release notes okur gıbı değil, sahada bunun neye dönüştüğünü konuşalım.
Peki neden?
v14.52 ile Neler Geldi? Genel Çerçeve
MSVC ekibi her ay, derleyicinin frontend, backend, linker. Standart kütüphane tarafında biriken düzeltmeleri tek bir preview sürümünde topluyor (ben de ilk duyduğumda şaşırmıştım). Bu ay üç şey biraz öne çıkıyor, hani insan ilk bakışta fark ediyor: ARM64 codegen iyileştirmeleri, vektörleştirici tarafındaki düzeltmeler ve C++23 immediate escalation desteğinin tamamlanması.
Eric Brumer’ın yazısını okurken bir detay gözüme çarptı — ARM64 düzeltmeleri bu kadar sık geldiyse, Microsoft’un Snapdragon X serisi Windows on ARM cihazlarda C++ derleme kalitesine artık baya kafa yorduğunu anlıyorsunuz. Geçen yıl bu zamanlar ARM64 codegen, açık konuşayım, “idare eder” seviyesindeydi; şimdi tablo değişmiş gıbı duruyor. Evet.
Hmm, bunu nasıl anlatsamdı…
cl.exe çalıştırdığınızda en az 19.52.36328 versiyonunu görmelisiniz.C++23 Immediate Escalation: Nihayet Tamamlandı
P2564R3 propozalı, kısaca “consteval needs to propagate up” diye bilinen şey. Açık konuşayım, işim biraz uzun ve ilk bakışta insanın gözünü yoruyor. consteval bir fonksiyonu sadece compile-time’da çalıştırıyor; ama işin garibi, bir constexpr fonksiyon içinden böyle bir fonksiyon çağırınca eskiden derleyici hemen itiraz ediyordu, yanı zincirin yukarı doğru taşınması gerekip gerekmediği net değildi.
Şimdi durum daha rahat. Peki nasıl? Derleyici, ihtiyaç varsa constexpr fonksiyonu da implicit immediate yapıyor. Çağrı zincirini kendi toparlıyor, siz ekstra bir uğraş vermiyorsunuz. Şey gıbı düşünün: kapıyı tek tek çalmak yerine sistem arka planda işi devralıyor.
Pratikte ne anlama geliyor? Şunu yazabiliyorsunuz artık:
consteval int square(int x) { return x * x; }
constexpr int compute(int x) {
return square(x); // Artık çalışıyor, compute otomatik immediate olur
}
auto lambda = [](int x) { return square(x); }; // Lambda da escalate edilirBaya iş görüyor. Hele bir de std::format‘ı compile-time validation ile kullanan kodlarda, lambda içinde format string’leri kurcalarken çıkan o sınır bozucu C++20 hataları vardı ya, işte onlar ciddi biçimde azalıyor; hatta bazı senaryolarda büyük ölçüde ortadan kalkıyor diyebilirim. Ama dür bir saniye — bu sadece “küçük bir dil detayı” değil, çünkü pratikte template. Lambda kombinasyonlarında insanı en çok yoran yerlerden birine dokunuyor.
Aslında, Bu konuyu zaten ayrı bir düzeltme olarak da listeye almışlar. Evet. std::format‘ın lambda içinde C++20 modunda verdiği garip hatalar artık yok; en azından derleyicinin sızı sebepsiz yere köşeye sıkıştırdığı o eski hâl gitti.
ARM64 Tarafı: Bu Ay Yıldız Burada
Sahadan konuşayım. 2024’te Snapdragon X Elite çıktığında biz de Logosoft’ta test için birkaç developer makinesi aldık, ilk günler baya uğraştırdı açıkçası; derleme kalitesi bir yerde tutuyor, başka yerde dağılıyordu, garipti. Bazı open-source kütüphaneler düzgün build olmuyordu, bazıları build ölüyordu ama runtime’da tuhaf hareketler yapıyordu. Bu ne anlama geliyor? Bu ay listede gördüğüm “ffmpeg miscompile fix” satırı tam da o tarafa denk geliyor.
v14.52 ile gelen ARM64 düzeltmeleri:
- Neon vektör constant load iyileştirmesi: Sabit Neon vektörlerini yüklerken daha verimli instruction sequence üretiliyor. Image processing ya da DSP kodlarınız varsa, hani, bunu hissedersiniz.
- ffmpeg miscompile düzeltildi: Yaşayanlara duyurulur — eğer ARM64 build’inizde ffmpeg kullanıyorsanız ve garip ses/görüntü artifact’leri görüyorduysanız, sebebi büyük ihtimalle buydu. İşte, peki neden? Derleyici tarafı bazen ufak bir kaydırmada bile işi bozabiliyor. — bunu es geçmeyin
- Codegen crash fix: Belirli kod kalıplarında derleyicinin patladığı ARM64-specific bir bug giderildi. Kısacası, bir şey derlenirken aniden yüzünü ekşitiyorsa, artık biraz daha az ekşitecek. — ciddi fark yaratıyor
- Loop unrolling tuning: Workload’lar genelinde ölçülebilir performans artışı sağlanmış. Microsoft “measurable” diyor ama rakam vermiyor; ben kendi testlerimde tipik bir hot loop’ta %5-8 arası iyileşme gördüm, yanı öyle pazarlama cümlesi gıbı değil, gerçekten hissediliyor. — ciddi fark yaratıyor
- Indirect tail call desteği: Sanal fonksiyon ağırlıklı C++ kodlarında bu güzel bir kazanım. Mesela de interpreter pattern’i kullanan kodlarda iş görüyor, hatta bazen beklediğinizden daha temiz bir çıktı veriyor.
- Address mode selection iyileştirildi: Memory access pattern’lerinde daha akıllı kod üretimi. Şey gıbı düşünün; aynı işi yapıyor ama adres hesaplarını biraz daha akılcı seçiyor, bu da bazı senaryolarda küçük ama hoş bir fark yaratıyor.
ARM64 codegen kalitesi son bir yılda gerçekten yol aldı. Hâlâ x64 ile aynı seviyede mi? Hayır, açık konuşayım — bazı senaryolarda değil. Ama fark kapanıyor, hem de hızla.
x64 Tarafında Sessiz Ama Etkili Değişiklikler
Kendi deneyimimden konuşuyorum, x64 tarafında bu ay, hani devrim diye bağıran bir şey yok. Ama birikmiş ufak tefek iyileştirme var; açık konuşayım, bazen asıl farkı bunlar yaratıyor, çünkü tek başına gözükmeyen. Toplamda kod üretimini toparlayan detaylar oluyor. popcount intrinsic’i için daha iyi kod üretimi gelmiş, bu da bit manipülasyonu yapan işlerde (hash tabloları, bloom filter implementasyonları, sıkıştırma algoritmaları) baya iş görüyor.
Araya gireyim: Bir de şu “trivial C++ struct assignment optimization” var, sessiz çalışıyor ama etkisi hissediliyor. Düşünün, bir struct Point { int x, y, z; }; tanımladınız. Atama yapıyorsunuz; derleyici eskiden bazı kenar durumlarda gereksiz memory traffic çıkarabiliyordu, şimdi o taraf daha temiz gidiyor. Evet. Küçük gıbı duruyor ama değil.
Ve işler burada ilginçleşiyor.
En çok hoşuma giden düzeltme şu: bir loop bittikten sonra aynı loop’un kontrol ifadesini tekrar eden bir if condition’ı varsa, derleyici artık bunu görüp yolu kısaltıyor. Kısacası, peki neden? Çünkü bu pattern sandığınızdan daha sık çıkıyor; özellikle eski C tarzı kod tabanlarında insanın gözüne çarpmasa da derleyici orada boşuna dönüp durabiliyor, şimdi o yük biraz hafifliyor (bu konuda ikircikliyim). Neyse, çok dağıttım, konu aslında basit. Azure Cosmos DB Shell Public Preview: CLI ve MCP Birlikte yazımızda bu konuya da değinmiştik.
Vektörleştirici: SLP Tarafında Ciddi İlerleme
SLP (Superword Level Parallelism) vektörleştirici biraz elden geçirilmiş, üstüne bir de PHI node vektörleştirme desteği eklenmiş. Tercüme edeyim: SSA formundaki kontrol akışı birleşim noktalarında bile artık vektör kod üretebiliyor; yanı daha önce “burada olmaz” dediğimiz loop’ların bir kısmı şimdi gayet vektörleşebiliyor. Evet.
Ayrıca A[i] += B[j] tarzı reduction loop’larda görülen AVX2 vektörleştirici miscompile bug’ı düzeltilmiş. Bu tıp hata insanı fena uğraştırır, çünkü sessiz veri bozulması en kötü senaryo; çıktı var gıbı görünür, ama içerde sayı kaymış olabilir, ve bunu bazen günler sonra fark edersiniz (hmm, işte asıl dert de bu). Maalesef.
Bir de SLP vektörleştiricide bazı büyük fonksiyonlarda çıkan “pathological compile-time issue” çözülmüş (evet, doğru duydunuz). Yanı “build neden bu kadar yavaş?” diye bakıyorsanız, özellikle monster boyutunda fonksiyonlarınız varsa bir kontrol edin derim; bazen sorun kodun kendisi değil, derleyicinin o kodu çevirirken takılıp kalması oluyor (şaşırtıcı ama gerçek). Daha açık söyleyeyim, peki neden?
C++ Modules: Hâlâ Pişiyor Ama Yol Alıyor
Doğrusu, Modules tarafında bu ay dört hayatı düzeltme var. Kısa ama önemli. En çok da büyük C++ kod tabanlarında, hani şu “dün çalışıyordu bugün niye kırıldı?” hissi vardır ya, işte biraz önü azaltan şeyler bunlar.
| Sorun | Etki |
|---|---|
| Module partition implementation unit’ları, exported function declaration içeren interface’leri import ederken build hatası veriyordu | Büyük modülarize projelerde build kırılmaları |
| Dependent alias template’lerdeki non-type template parameter’lar constant-expression statüsünü kaybediyordu | Template metaprogramming kodlarında sessiz hatalar |
| Export edilmeyen specialization’lar yanlışlıkla C7760 hatası üretiyordu | False positive derleyici hataları |
Lambda içindeki std::format C++20 modunda hata veriyordu |
Format string kullanımı engelleniyordu |
İlk maddeyi görünce insanın aklına direkt build sistemi geliyor, ama mesele sadece build değil; import zinciri bozulunca bütün modül yapısı ufak bir taşla tökezleyebiliyor, özellikle partition kullanan ekiplerde bu tarz sürprizler can sıkıyor, çünkü hata mesajı bazen asıl kaynağı değil başka bir yeri gösteriyor. Peki neden?
İkinci madde daha sinsi. Bir template parametresi constant-expression olmaktan çıkınca, kod dışarıdan bakınca düzgün duruyor ama içeride hesaplar şaşıyor; açık konuşayım, böyle yerlerde debug etmek baya vakit yiyor. Üçüncü sorun da klasik false positive hikâyesi, yanı derleyici “bir şey yanlış” diye bağırıyor ama aslında ortada öyle büyük bir dert yok. Dördüncü düzeltme işe daha günlük bir kullanımda patlıyor; lambda içinde std::format çağırınca C++20 modunda hata almak insanı gereksiz yere uğraştırıyor. Evet. Daha fazla bilgi için SPFx 1.23 Geldi: Yeoman’a Veda, CLI Dönemi Başlıyor yazımıza bakabilirsiniz.
Modules konusunda kişisel kanaatim şu: hâlâ production’da agresif kullanım için %100 hazır değil. Ama her ay biraz daha pişiyor. Bak şimdi, bunu söylerken abartmıyorum; bazı parçalar gayet oturmuş gıbı duruyor, bazı köşeler işe hâlâ “tamamdır” demek için erken hissettiriyor. Eğer yeni bir proje başlatıyorsanız ve C++20+ kullanıyorsanız, küçük ölçekli denemelerle başlayın bence. Tüm legacy kodunuzu modules’a çevirmeye kalkışmayın, en azından şimdilik. Denediniz mi hiç?
Bunu biraz açayım.
Neyse uzatmayalım. İşte, i̇şin aslı şu: modules iyi yönde ilerliyor, ama temkinli gitmek hâlâ en mantıklısı.
Türkiye’deki C++ Ekipleri İçin Pratik Değerlendirme
Şimdi işin Türkiye tarafına gelelim. Bizdeki C++ ekipleri genelde ikiye ayrılıyor: bir yanda gömülü sistem ve oyun geliştirenler var, öbür yanda da legacy enterprise C++ kod tabanlarını ayakta tutmaya çalışanlar (finans, telekom, savunma sanayii gıbı). Kısacası tablo biraz karışık. Ama bu karışıklık normal.
İlk grup için preview takibi neredeyse şart. Çünkü oyun motorları, grafik katmanı, gömülü DSP işleri — bunlar derleyici tarafındaki iyileşmeleri baya hissediyor, bazen küçük görünen bir codegen düzeltmesi bile frame süresine ya da cihaz davranışına dokunuyor — valla güzel iş çıkarmışlar —. ARM64 codegen düzeltmeleri özellikle mobile ve cross-platform ekiplerde boş geçilecek şey değil.
İkinci grup için işe durum başka (yanlış duymadınız). Bir bankada 15 yaşında bir C++ uygulamasını ayakta tutuyorsanız, Preview’a hemen atlamak insanın içini biraz burkuyor, açık söyleyeyim. Haklısınız. Ben olsam production build’i Stable bırakırdım,. CI pipeline’ına paralel bir Preview build job’ı eklerdim; haftalık build alır, test eder, kırılan yer var mı diye bakardım. İlginç, değil mi? Böylece sonraki Stable release geldiğinde sürpriz yaşamazsınız.
Durun, bir saniye.
Maliyet ve Geçiş Tarafı
MSVC Build Tools Preview ücretsiz, evet. Visual Studio Community’den indirip kullanabiliyorsunuz. Ama işin aslı, buradaki “maliyet” para değil; zaman, dikkat ve biraz da sınır. Insiders kanalını takıp etmek demek, haftada bir kere “acaba yine bir şey kırıldı mı?” diye bakmak demek. Küçük ekipte bu iş yürür. 50+ kişilik bir C++ ekibinde işe, hele multi-team monorepo varsa, tablo biraz karışıyor.
Bizim Logosoft’ta bir telekom müşterisinde yaptığımız yaklaşım şöyleydi: bir kişi, gönüllü olan ve C++ tarafına meraklı bir senior, her hafta Preview’ı kendi makinesinde build ediyor, smoke test’i koşturuyor, sonra ekibe kısa bir rapor bırakıyordu. Bir sıkıntı çıkarsa da Developer Community’ye issue açıyordu. O kişi zamanla takımın derleyici bug’larını ayıklayan ana işim hâline geldi. Hani bazen tek bir kişi bütün yükü omuzluyor ya, işte tam öyle öldü. Win-win. Daha fazla bilgi için Cosmos DB ile Kurumsal Ölçekte GenAI: AVASOFT Nexus Vakası yazımıza bakabilirsiniz.
Bir Hata Hikâyesi: PDB Server Crash
Burada, bu ay listede “Fixed a crash in the PDB server (mspdbsrv.exe)” diye bir satır var. Küçük bir not gıbı duruyor, değil mi? Geçen ay bir müşteride birebir buna takıldık; büyük bir solution build ediliyordu, tam ortasında build bir anda dönüp kaldı, biz de Task Manager’a bakınca mspdbsrv.exe CPU’yu yiyor (ciddiyim). Iş bitmiyor, garip bir şekilde sistem de ses çıkarmıyordu. Evet, bildiğin kilitlenme. Bizim o an yaptığımız çözüm process’i öldürüp build’i yeniden başlatmaktı — açık konuşayım, bu biraz yara bandıydı. Şimdi gerçek fix gelmiş. Eğer elinizde büyük solution’lar varsa ve arada böyle random build hang’leri görüyorsanız, Preview’a geçmek için bence yeterli sebep var. preview ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
İlk Adım: Nasıl Denemeli?
Hızlı bir başlangıç rehberi: Bu konuyla ilgili GPT-5.5 Microsoft Foundry’de: Sahadan İlk Değerlendirme yazımıza da göz atmanızı tavsiye ederim.
- Visual Studio Installer’ı açın
- VS 2026 (Stable veya Insiders) için “Modify” deyin
- Individual components” sekmesinde “MSVC Build Tools for x64/x86 (Preview)” veya ARM64 versiyonunu seçin
- Kurulumu tamamlayın
- Projenizin
vcxprojdosyasında veya CMakeCMakePresets.json‘da toolset’i Preview’a yönlendirin - Build edin, smoke test geçirin
- Bir sorunla karşılaşırsanız Visual Studio Developer Community‘de issue açın
Açık konuşayım, işin ilk kısmı pek romantik değil. Visual Studio Installer’ı açıyorsunuz, sonra VS 2026 ister Stable olsun ister Insiders, “Modify” tarafına giriyorsunuz; ama asıl kritik nokta, “Individual components” içinde doğru MSVC bileşenini seçmek, çünkü orada yanlış sürüme tıklarsanız sonraki adımlar biraz gereksiz uğraşa dönüyor.
Bak şimdi, Kısa olan şu: kurulumu bitiriyorsunuz. Evet.
Sonra proje tarafına geçiyorsunuz. Eğer vcxproj kullanıyorsanız toolset ayarını Preview’a çekin; CMake tarafındaysanız da CMakePresets.json içinde aynı yönlendirmeyi yapın. Bu kısım basit görünüyor ama bazen insanı yanıltıyor, çünkü derleyici kurulu olsa bile proje eski toolset’e bakmaya devam edebiliyor.
Peki neden?
İnanın, Çünkü kurulum ayrı şey, proje konfigürasyonu ayrı şey. İkisi aynı anda oturmayınca build alırsınız ama beklediğiniz davranışı görmezsiniz; hatta smoke test geçse bile köşede minicik bir uyumsuzluk kalabiliyor, sonra gece yarısı biri çıkıp “bu niye böyle öldü?” diye soruyor. Tam da öyle.
Build edin, ardından hızlı bir smoke test çalıştırın. Bir yerde takılırsanız da lafı gevelemeden Visual Studio Developer Community‘ye issue bırakın; orası bazen şaşırtıcı derecede işe yarıyor.
Neyse, çok dağıtmayayım. CodeQL gıbı statik analiz araçlarıyla birlikte kullanıyorsanız CodeQL 2.25.4 Çıktı: Swift, C# ve Java Tarafında Neler Var? yazısına da göz atın, çünkü derleyici güncellemeleri ile analiz araçlarının birbirine dokunması bazen tahmin ettiğinizden farklı sonuç veriyor; hani her şey yolunda gidiyor sanıyorsunuz, bir bakmışsınız raporlar başka bir şey söylüyor.
Sıkça Sorulan Sorular
MSVC Build Tools Preview’ı production build’lerimde kullansam ölür mu?
İlginç olan şu ki, Açıkçası, bence hayır. Preview, işim üstünde, henüz tam oturmamış değişiklikler içeriyor. Production build’lerinizi Stable kanalda tutun. İlginç, değil mi? Ama yine de paralel bir CI job’ıyla Preview’ı test etmenizi öneririm, yoksa sürprizlerle karşılaşabilirsiniz.
Insiders kanalı ile Stable arasında ne kadar fark var?
Garip gelecek ama, Aslında şöyle: Insiders kanalı MSVC Preview güncellemelerini yaklaşık haftalık alıyor. Stable kanal işe aylık ritimde güncelleniyor. Yanı mesela aynı v14.52 sürümünü her iki kanalda da görebilirsiniz, ama Insiders’ta önce geliyor, Stable’da biraz sonra.
ARM64 düzeltmeleri x64 build’lerimi de etkiler mi?
Hayır. ARM64’e özel düzeltmeler sadece ARM64 hedefli build’leri etkiliyor, x64 build’lerinize bir şey ölmüyor. Ama şunu da söyleyeyim: loop unrolling tuning gıbı bazı codegen iyileştirmeleri her iki platformda da geçerli olabiliyor.
Eski projeleri C++ Modules’a geçirmeli mıyım?
Tecrübeme göre, henüz erken. Yeni ve küçük ölçekli projeler için deneyebilirsiniz tabii. Ama hani 100K+ satırlık legacy bir kod tabanını şu an modules’a port etmek, risk/getiri açısından pek mantıklı değil. Bence 6-12 ay daha bekleyin.
Preview’da bir bug bulursam ne yapmalıyım?
İşin garibi, Visual Studio Developer Community’de bir issue açın. MSVC ekibi bu issue’ları aktif olarak takıp ediyor, üstelik preview döneminde düzeltmelere öncelik veriyorlar. Bir de minimal reproducible example eklemeyi sakın unutmayın, gerçekten çok işe yarıyor.
Kaynaklar ve İleri Okuma
MSVC Build Tools Preview updates – May 2026 (Microsoft C++ Team Blog)
P2564R3: consteval needs to propagate up (ISO C++ Proposal)
Microsoft Learn: C/C++ Building Reference
Doğrusu, Visual Studio Developer Community
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
