Pure Virtual C++ 2026: Hızlı Build, Hızlı Çalışan Kod Zamanı
İnanın, Şunu en başta söyleyeyim: C++ ile uğraşan herkesin ortak can sıkıntısı build süreleri. İşin tuhaf tarafı, bu dert 20 yıl önce de vardı, bugün de var. Fark şu ki elimizde daha çok araç var ama ekiplerin bir kısmı hâlâ 2005’ten kalma reflekslerle kod derliyor. Sonra da progress bar’a bakıp zaman harcıyoruz, hani pek keyifli olmuyor.
Neyse, konuya gireyim. Microsoft, Pure Virtual C++ 2026 etkinliğinin konuşmacılarını duyurmaya başladı. 21 Temmuz 2026’da, tek gün sürecek, ücretsiz ve tamamen online bir konferans olacak. Yayın YouTube (Microsoft Reactor) ve Twitch üzerinden yapılacak. İlk tanıtım turunun teması da tam yukarıdaki mesele: daha hızlı build, daha hızlı çalışan kod.
Ve işler burada ilginçleşiyor.
Bu yazıda iki oturuma bakacağım — biri C++20 modüllerinin gerçek dünyadaki etkisi, diğeri de GitHub Copilot’ın build iyileştirmeuna nasıl karıştığı. Ama sadece etkinlik haberi vermeyeceğim (ki bu çoğu kişinin gözünden kaçıyor). Kendi gördüklerimi, Türkiye’deki ekiplerin bu teknolojilere nasıl yaklaştığını ve nerede tökezlediğini de anlatacağım (evet, doğru duydunuz). Şey, biraz sohbet gibi olsun istiyorum.
Neden bu tema? Yavaş build’in kimseye faydası yok
Küçük bir detay: Sahada şunu çok görüyorum: bir ekip 40 dakikalık full build süresine “eh alıştık” diyor. Alıştık dedikleri şey aslında günde 2-3 saat kayıp mesai. Bir developer 8 saatlik gününde 3 kere clean build yapıyorsa, hafta sonunda 6-9 saati progress bar izleyerek geçirmiş oluyor. Hesap baya ortada.
Durun, bir saniye.
Bi saniye — Bir de şu var: build süresi uzadıkça developer davranışı bozuluyor. Küçük değişikliği “toplu yapayım” diye biriktiriyor, küçük commit kültürü dağılıyor, test döngüsü uzuyor, CI pipeline şişiyor; yanı domino taşı gibi gidiyor işte (inanın bana). Azıcık yavaşlıkla başlıyor, sonra süreç komple ağırlaşıyor.
“Build süreleri sadece bir mühendislik meselesi değil, aslında bir moral ve kültür meselesi. Ekibin motivasyonunu içten içe kemiren şey çoğu zaman görünmüyor bile.”
Konferansın bu ilk bölümünde iki farklı yaklaşım var. Biri klasik yol: derleme modelini modernize et (C++20 modules). Diğeri işe yeni nesil yol: AI ajanını sal, gerçek darboğazı o bulsun (ben de ilk duyduğumda şaşırmıştım). İkisi de aynı yere çıkıyor gibi dürüyor ama yöntemleri epey farklı.
Bir dakika — bununla bitmedi.
Ryan Shepherd: C++/WinRT ve C++20 modules
Ryan Shepherd Windows tarafında Senior Software Engineer olarak çalışıyor. WinRT, C++/WinRT, SDK’lar, CRT derken altyapının tam göbeğinde yer alıyor. Ha bu arada boş vakitlerinde trombon çalıyormuş, fotoğraf çekiyormuş, ekmek pişiriyormuş. Niye yazdım bilmiyorum ama insana bir şey söylüyor: bu adam sadece code monkey değil.
Oturumun özü
C++/WinRT yakın zamanda C++20 modules desteği aldı. Ve sonuç kağıt üstünde kalmadı; sahada belli öldü: Windows Terminal ekibi bu desteği benimsedi, build süresini yaklaşık %15 düşürdü. Build sırasında kullanılan disk alanından onlarca gigabyte tasarruf etti.
İşin garibi, Onlarca gigabyte deyince iş değişiyor tabiî. Bu artık “biraz iyileşme” değil; CI runner’ların disk maliyeti, geliştirici makinelerinin SSD ömrü ve cache verimliliği doğrudan etkileniyor. Kısacası küçük görünen şeyin faturası büyük çıkabiliyor.
Modules aslında ne çözüyor?
Klasik header-based derleme modelini düşünün. Bir .cpp dosyası <windows.h> dahil ediyor; preprocessor bu header’ı olduğu gibi kopyalıyor; sonra o header başka header’ları çağırıyor; onlar da başkalarını… Sonuçta tek bir translation unit için compiler bazen 100.000+ satır kod okuyor ve bunu her .cpp dosyası için yeniden yapıyor.
Modules bu çılgınlığı kırıyor. Bir modül bir kere derleniyor, sonra .ifc (interface) dosyası olarak saklanıyor; diğer dosyalar da bu binary interface’i kullanıyor (ben de ilk duyduğumda şaşırmıştım). Tekrar tekrar parse etmek yok, tekrar tekrar template instantiation yok. Açık konuşayım, işin aslı burada baya pratik bir kazanç var.
// Klasik yaklaşım
#include <winrt/Windows.Foundation.h> // Binlerce satır tekrar parse
// Modules yaklaşımı
import winrt.Windows.Foundation; //.ifc dosyasından direkt okuNe gerekiyor başlamak için?
- C++/WinRT 3.0 veya üstü (bu kritik)
- MSVC Build Tools 14.50 veya üstü
- Ve tabi biraz sabır — çünkü mevcut kod tabanınızı bir gecede dönüştüremezsiniz (bence en önemlisi)
Türkiye’deki ekipler için gerçekçi bir değerlendirme
Bence, Açık konuşayım: Türkiye’de C++/WinRT kullanan ekip sayısı bir elin parmaklarını geçmez gibi geliyor bana. Ama modules konusu sadece WinRT için değil, genel bir C++ konusu. Burada ufak bir gözlemim var — Türkiye’deki C++ ekipleri modernizasyona genelde temkinli yaklaşıyor. C++17’ye bile geç gelen çok kod tabanı gördüm; o yüzden C++20 modules denince ilk tepki “istikrarlı mı?” oluyor. Pek haksız da sayılmazlar.
Şimdi gelelim işin can alıcı noktasına.
Bence gerçekçi tavsiye şu: greenfield bir projeye başlıyorsanız modules’i düşünün ama mevcut milyonlarca satırlık legacy kod tabanına dokunacaksanız önce header units ile başlayın. Daha az riskli ara adım bu. Windows Terminal gibi görece modern bir kod tabanı bile geçişte epey uğraştıysa, 15 yıllık kurumsal bir C++ monolitine dokunurken iki kere düşünmek lazım.
Yanı, Evet.
David Li: Build expert olmadan build sürelerini kısaltmak
Bakın, İkinci konuşmacı David Li — Visual Studio’nun Game Developer Product Manager’ı. Sektörde 14 yılı var ve developer productivity tarafına ciddi merakı olduğu belli oluyor. Off-hours’ta bebeği ve köpeğiyle vakit geçiriyormuş, bir de Europa Universalis V’te dünyayı fethetmeye çalışıyormuş; ben EU IV’ün ötesine geçemedim ama neyse konumuz o değil (en azından benim deneyimim böyle)
Oturumun özü
Bak şimdi, David’in oturumu farklı bir açıdan geliyor: GitHub Copilot build performance agent. Yanı AI ajanı sizin build’i analiz ediyor, darboğazları buluyor ve öneriler getiriyor; amaç da build expert olmadan build sürelerini kısaltmak.
Bunu ilk duyduğumda ben de biraz şüpheciydim çünkü build optimize etmeu çoğu zaman bağlama çok bağlıdır; “include what you use”, template instantiation cost’u, link-time optimization ayarları, PDB dosyalarının şişmesi… Bunların her biri ayrı uzmanlık istiyor. Bir AI bunları gerçekten çözebilir mi? Peki neden olmasın diyorsunuz ama insan yine de temkinli kalıyor.
Beklentimi düşürerek yaklaşıyorum
Neyse, bi saniye — Ama şöyle düşününce mantıklı geliyor: build sistemleri artık o kadar çok telemetri üretiyor ki tek tek insan gözüyle bakmak zorlaşıyor. MSBuild logları, /Bt+ çıktıları, /d1reportTime raporları, header — en azından ben öyle düşünüyorum — dependency grafikleri… Bir LLM için böyle yapılandırılmış veriyi tarayıp pattern çıkarmak fena fikir değil aslında; kaynak kod da elinde olduğuna göre “şu header’ı şu 47 dosya include ediyor ama sadece 3’ünde gerçekten kullanılıyor” gibi tespitler yapabilir.
Yanı şöyle ayırabiliriz:
| Klasik yaklaşım | AI ajanı yaklaşımı |
|---|---|
| Manuel profiling, /Bt+ output okuma | Otomatik telemetri analizi |
| Deneimli mühendis gerekli | Junior dev de kullanabilir |
| Optimizasyonlar tek seferlik | Sürekli izleme mümkün |
| Genel best practices | Müşteriye/projeye özgü öneriler |
Küçük ekip ile enterprise aynı değil
Küçük bir ekipseniz muhtemelen build optimize etmeuna ayıracak dedicated kişiniz yoktur. Bu tip bir AI aracı size baya iş görür; Copilot ne diyorsa uygulayın, sonuçlarını ölçün ve ilerleyin demek yeterli olabilir.
Şahsen, Ama enterprise ölçekte tablo değişiyor biraz. 500+ developer’ın olduğu kod tabanında AI’ın önerdiği değişikliğin domino etkisini kim değerlendirecek? Header ordering değişirse ABI etkilenebilir; precompiled header stratejisi bozulursa geçici olarak build yavaşlayabilir; yanı öneri iyi olabilir ama otomatik uygulama değil tartışma başlatıcı olarak görülmeli büyük ekiplerde.
İkinciyi de yan yana koyunca ne çıkıyor?
Araya gireyim: Peki bu iki oturum birlikte bize ne söylüyor? Bana göre mesaj net: C++ build performansı artık “gurunun bileceği iş” olmaktan çıkıyor. Bir tarafta dil seviyesinde modernizasyon var (modules), diğer tarafta araç seviyesinde otomasyon (Copilot ajanları). İki yol da aynı yere çıkıyor ama biri daha yapısal, diğeri daha pratik geliyor kulağa.
Kendi ekibinize dönerseniz benim sıraya koyacağım adımlar şöyle olur:
- Ölç: Şu an nerede olduğunuzu bilmeden ilerleyemezsiniz. MSVC’de
/Bt+ve/d1reportTimeflag’leriyle başlayın; hangi dosyalar en çok zaman alıyor bakın. (bu kritik) - Düşük asılı meyveleri topla: Include-what-you-use, forward declarations ve pImpl idiom… Bunlar bilinen çözümler ama çoğu ekip uygulamayı erteliyor.
- PCH’yi gözden geçir: Çoğu ekip precompiled headers’ı beş yıl önce kurmuş ve sonra unutmuş oluyor; içinde artık kullanılmayan header’lar dolanmış olabilir. — bunu es geçmeyin
- Header units’e geç: Modules’in eğitim tekerlekli hali gibi düşünün; risk daha düşük ama kazanım hiç fena değil.
- Yeni kodda modules kullan:. — ciddi fark yaratıyor
]
}
Maliyet tarafına da bakalım mı?
Böyle konferans duyurularında genelde atlanan şeylerden biri build optimize etmeunun para karşılığıdır.? Bir CI runner’ın saatlik maliyetini düşünün.? Azure Pipelines’ta paralel job başına aylık ücret? GitHub Actions’ta dakika bazlı fiyatlandırma… Bir ekip günde 200 build çalıştırıyorsa. Bunu 10 dakikadan 8.5 dakikaya bir düşüneyim… indirebiliyorsa? aylık runner faturasında ciddi düşüş oluyor.? Ufak görünmüyor yanı. “””
Sıkça Sorulan Sorular
Pure Virtual C++ 2026’ya kayıt olmam gerekiyor mu? Ücretli mi?
Konferans tamamen ücretsiz, hiç merak etme. YouTube (Microsoft Reactor) ve Twitch üzerinden canlı izleyebilirsin. Kayıt olmak şart değil ama hatırlatma ve güncelleme almak istiyorsan bence kayıt olmakta fayda var. Kaçırırsan da sorun yok — Visual Studio YouTube kanalında sonradan on-demand olarak yayınlanıyor zaten.
C++20 modules’e geçmek için mevcut kod tabanımı tamamen değiştirmek zorunda mıyım?
Hayır, kesinlikle değil. Modules aslında kademeli geçişe çok uygun bir teknoloji. Önce header units ile başlayabilirsin —. Mevcut header dosyalarını module olarak import edebiliyorsun, kodda büyük bir şey değiştirmene gerek kalmıyor. Sonra yeni yazdığın bileşenleri gerçek modules olarak yazarsın. Mesela Windows Terminal ekibi de bu tür kademeli bir yaklaşımla ilerlemiş, tecrübeme göre bu yol çok daha az stresli.
MSVC dışında bir compiler kullanıyorsam modules çalışır mı?
Çalışıyor ama olgunluk seviyeleri birbirinden farklı. MSVC en olgun modules desteğine sahip olan. Clang epey yol kat etti, GCC de aktif geliştirme aşamasında. Cross-platform bir proje yürütüyorsan, açıkçası üç compiler’ın da modules desteğini test edip ortak paydayı bulman gerekiyor. Peki bunu neden söylüyorum? Şu an için üretim ortamında MSVC en güvenli seçim bence.
GitHub Copilot build performance ajanı şu an kullanılabilir mi?
Detaylar konferans oturumunda açıklanacak. Copilot ekosistemindeki ajan tabanlı özellikler hızla genişliyor — hani bazıları. Public preview’da, bazıları henüz iç test aşamasında. Kesin olarak ne zaman kullanılabilir olacağını öğrenmek için oturumu takip etmeni ve GitHub Copilot’ın resmî dokümantasyonunu düzenli kontrol etmeni öneririm.
Küçük bir ekipsem, hangi iyileştirmedan başlamalıyım?
Ölçmekten. Yanı “şu an ne kadar sürüyor, neresi yavaş?” sorusuna cevabın yoksa yaptığın optimizasyon aslında şansa dayanıyor. MSVC’nın /Bt+ ve /d1reportTime flag’leri ücretsiz ve etkili — bence buradan başlamak mantıklı. Sonrasında include-what-you-use gibi klasik teknikler, PCH gözden geçirme. Mümkünse yeni kod için modules — bu sırayla ilerle.
Kaynaklar ve İleri Okuma
Pure Virtual C++ 2026 — Meet the Speakers, Part 1 (Microsoft C++ Blog)
Overview of modules in C++ — Microsoft Learn
Compare header units, modules, and precompiled headers — Microsoft Learn
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.
2 comments