MSVC Build Tools Haziran 2026 Önizleme: Sessiz Ama Derin İyileştirmeler
Açık konuşayım: MSVC tarafındaki preview güncellemeleri çoğu zaman benim de “bir bakıp geçeyim” dediğim listenin başında dürüyor. Çünkü release notları öyle teknik, öyle madde madde akıyor ki, normal bir geliştiricinin gözü bir süre sonra kayıyor (ilk duyduğumda inanamadım). Ama bu sefer 14.52 preview’ünü biraz daha dikkatli okudum — ve içinde gerçekten konuşmaya değer şeyler buldum. Yanı sadece “şu bug fix edildi” listesinin biraz üstü var burada.
Bence, Eric Brumer’ın yazdığı orijinal güncelleme notunda C++ Modules, ARM64 kod üretimi, x64/x86 düzeltmeleri, optimizer iyileştirmeleri ve linker tarafı için epey madde var. Ben size buradan hem teknik bir özet vereceğim hem de — daha önemlisi — bunların Türkiye’deki yazılım ekiplerinin gündemine nasıl oturduğunu konuşacağım. İlginç, değil mi? Çünkü bizim taraftaki C++ kullanımı, Batı’dakinden baya farklı akıyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
MSVC v14.52 Preview, dışarıdan bakınca “küçük” düzeltmelerle dolu gibi dürüyor ama altında iki büyük mesaj var: C++ Modules artık üretim ortamına gerçekten yaklaşıyor, ARM64 desteği de oyuncak olmaktan çıkıp ciddi bir hedef platforma dönüyor.
Önce kısa bir hatırlatma: MSVC Build Tools Preview ne ki?
MSVC Build Tools Preview, Visual Studio 2026’nın yanında ayrıca kurulabilen, derleyici ekibinin sık sık güncellediği bir paket. Stable kanaldan VS 2026 kuranlar bunu aylık alabiliyor; Insiders kanalındaysa aşağı yukarı haftada bir güncelleme geliyor.
Açık konuşayım, Installer’da iki bileşen var, bilenler bilir:
- MSVC Build Tools for x64/x86 (Preview)
- MSVC Build Tools for ARM64/ARM64EC (Preview)
Kurduktan sonra cl.exe ve link.exe‘nın versiyon numarası en az 19.52.36418 / 14.52.36418 olmalı. Komut satırınızı ya da IDE’nızı preview kullanacak şekilde ayarlamak için aka.ms/msvc/preview sayfasındaki adımları izlemek gerekiyor — burada en sık yapılan hata şu: kullanıcı kurduğunu sanıyor ama hâlâ eski cl çalışıyor. Çünkü PATH ya da VsDevCmd ayarı yapılmadıysa sistem yine stable’ı çağırıyor.
Peki neden preview kullanasınız ki?
Şöyle ki, Sahada şunu çok görüyorum: ekipler ya hiç preview kullanmıyor, ya da CI/CD içinde preview’ü production build için kullanıyor. İkisi de ayrı problem. Doğru yaklaşım, ayrı bir “experimental” pipeline tutmak ve büyük güncellemeler gelmeden önce kendi kod tabanınızla bunu test etmek. En çok da sız de C++20/23 modules’a geçiş düşünüyorsanız, bu test ortamı altın değerinde.
C++ Modules: Artık “şaka” olmaktan çıkıyor
Bence bu güncellemenin en can alıcı kısmı burası. C++20 modules uzun süredir “kağıt üstünde iyi, pratikte can sıkan” tarafta duruyordu (şaşırtıcı ama gerçek). Her preview’de biraz toparlanıyordu ama her seferinde başka bir gariplik çıkıyordu. Hani ne farkı var diyorsunuz, değil mi? 14.52 ile birlikte düzelenler şunlar:
- Modül içinde
if constexprverequiresifadelerini birlikte kullanan variadic template sınıflarda derleyici çökmesi düzeltildi. - C++23 modülleriyle ilgili bir internal compiler error (IÇE) giderildi.
- Modüllerden export edilen
operator==kullanırken yaşanan IÇE çözüldü. (bence en önemlisi) import stdkullanımının derlenememesi sorunu düzeldi.- Header unit’lerden import edilen
__VA_OPT__makrolarında iç içe parantez sorunu giderildi.
Bunlar tek tek bakınca “tamam, bir bug daha kapandı” gibi dürüyor. Ama bütüne bakınca başka bir resim çıkıyor: Microsoft modules tarafını gerçekten production-ready yapmaya çalışıyor, sessiz sedasız ilerleyen bir sprint var ortada. Bilhassa import std‘nın düzgün çalışmaya başlaması küçük olay değil — standart kütüphaneyi modül olarak import etmenin önündeki son ciddi engellerden biri buydu.
Bunu biraz açayım.
Türkiye’de modules ne durumda?
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de C++ modules kullanımı neredeyse yok denecek kadar az. Hâlâ ekiplerin büyük bölümü C++17’de, hatta bazıları C++14’te kalmış durumda (bizzat test ettim). Sebep? İki tane: Birincisi mevcut kod tabanları precompiled header (PCH). Include hiyerarşileri üzerine kurulmuş oluyor, refactor maliyeti yüksek geliyor. İkincisi de takım liderlerinin “modules’a geçince ne kazanacağız?” sorusuna net cevap bulamaması.
Bak şimdi, Bence net cevap şu: build süreleri. Büyük projelerde modules ciddi anlamda build time düşürüyor — bazı senaryolarda %30-50 arası fark görebiliyorsunuz (ciddiyim). Ama bu kazancı almak için bağımlılık zincirinizin önemli kısmının modules’a uygun olması lazım; yanı iş biraz kütüphane ekosistemine dayanıyor. vcpkg Mayıs 2026 Güncellemesi: Sessiz Güç, Büyük Etki yazımda da değinmiştim, vcpkg tarafı bu konuda sessiz sedasız ilerliyor. Bu konuyla ilgili sessiz ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Durun, bir saniye.
ARM64: Artık “deneme” değil, hedef platform
Şimdi gelelim benim için en ilginç kısma. ARM64 tarafındaki güncellemeler aslında şunu söylüyor: Microsoft, ARM64’ü Windows on ARM kapsamında ciddi bir geliştirici hedefi olarak görüyor (ki bu çoğu kişinin gözünden kaçıyor). Snapdragon X cihazların Copilot+ PC adıyla piyasaya yayılması da bu işin arkasındaki ana itici güç olmuş durumda — bence çok yerinde bir karar —
14.52’deki ARM64 iyileştirmeleri: Visual Studio’dan Çıkmadan Pull Request İncelemek: Artık Daha Rahat yazımızda bu konuya da değinmiştik.
- Vektör inşasında duplicate instruction’lardan sonra gereksiz insert operasyonları elenerek vector construction iyileştirildi.
- SSA Optimizer artık SVE (Scalable Vector Extension) tiplerini destekliyor.
- Bitfield instruction’larında (
BFI,BFXIL,UBFIZ,UBFX,SBFIZ,SBFX) immediate operand’ların genişliği daraltılarak daha kompakt kod üretiliyor. - Vector memory intrinsic’leri standart load/store operasyonlarına dönüştürülerek hedef benchmark’larda %2-3 iyileştirme sağlandı.
Küçük bir detay: %2-3 kulağa küçük gelebilir. Ama derleyici dünyasında bu rakamlar hiç fena değil (ki bu çoğu kişinin gözünden kaçıyor). Hele binary size küçülmesiyle birlikte gelirse — embedded. Mobile tarafında cache hit oranlarını bile etkileyen bir kazanıma dönüşebiliyor bu iş. CodeQL 2.25.6 ile Sessiz Ama Güçlü Güvenlik Sıçraması yazımızda bu konuya da değinmiştik.
SVE desteği neden önemli?
SVE, ARM’ın değişken uzunluklu vektör mimarisi. Yanı sabit 128-bit ya da 256-bit vektör yerine, donanım hangi genişliği destekliyorsa ona göre çalışan kod yazabiliyorsunuz; güzel tarafı da bu zaten. SSA Optimizer’ın bunu artık doğru şekilde optimize edebilmesi, ARM64 üzerinde HPC ve sinyal işleme uygulamaları yazanların ilgisini çekecek türden bir gelişme. Neden önemli bu? Bizim coğrafyada bu tip iş yapan ekip az ama gelecekte özellikle savunma sanayii ve telekom tarafında ARM64’e ciddi yatırım göreceğiz gibi dürüyor, ona göre.
x64/x86 tarafında düzeltmeler — Bazıları gerçekten önemli
x64/x86 tarafında daha çok bug fix ağırlıklı bir liste var ama içlerinden biri baya kritik: Daha fazla bilgi için Bot PR’lere de CI yolu açıldı: Güvenlikte ince ayar zamanı yazımıza bakabilirsiniz. Bu konuyla ilgili Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor yazımıza da göz atmanızı tavsiye ederim.
- Multi-byte copy propagation’da miscompile: Destination address capture edildiğinde yanlış kod üretiliyordu. Bu tehlikeli bir bug — sessiz sessiz yanlış sonuç üreten kod demek bu, compiler bug’larının en sevimsiz türü.
- Multiply’ları shift’e indirgerken overflow flag’lerin korunmaması sorunu giderildi.
- x86’da non-register destination’lı LEA kullanımında IÇE düzeltildi.
- Amd64’te SIMD C dosyaları derlerken IÇE düzeltildi.
- x86 için SSA Optimizer copy propagation tune edildi.
- x86’da 16-bit overflow intrinsic’lerinde codegen bug’ı giderildi.
Daha ilk maddeyi özellikle vurgulamak istiyorum. Eğer üretimde uzun süredir çalışan bir servisiniz varsa. “arada sırada garip davranıyor ama yeniden üretemiyoruz” diyorsanız, compiler bug ihtimalini de kenara atmayın derim açıkçası. Geliştiriciler genelde “bizim kodda hata vardır” diye düşünür — ki çoğu zaman öyledir —. Derleyicinin de yanılabildiğini unutmamak gerekiyor.
Optimizer iyileştirmeleri: Inliner akıllanıyor mu?
Şöyle söyleyeyim, Bence bu bölümün en dikkat çekici maddesi şu: inliner heuristics’e return value cost analysis eklendi. Yanı derleyici artık bir fonksiyonu inline etmeden önce dönüş değerinin maliyetini de hesaba katıyor; küçük görünüyor. Tam da böyle ayrıntılar performansı oynatıyor. Bakın, en çok da template ağırlıklı kodlarda bunun etkisini hissedebiliyorsunuz.
Daha ilginç olan başka bir nokta var: inliner’ın memory model’i, function pointer devirtualization mümkün olacak şekilde geliştirildi. Yanı bazı durumlarda virtual function call’ları statik olarak çözmek daha kolay hâle geliyor. C++ tarafında devirtualization yıllardır LLVM’in (Clang’ın) güçlü olduğu, MSVC’nın biraz geriden geldiği alanlardan biri sayılıyordu; bu adım o farkı biraz kapatmaya çalışıyor gibi dürüyor (ben de ilk duyduğumda şaşırmıştım)
Neyse uzatmayalım; diğer optimizer notları da şöyle:
| Iyileştirme | Etkisi |
|---|---|
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| COROUTINE inlining assertion düzeltildi | |
| >Coroutine inline assert fixi | |
| >Constant type conversion folding (/fp:fast olmadan) | |
| Loop unswitching + vectorization birleşim hatası düzeltildi |
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.
Yorum gönder