C++/WinRT'deki yenilikler

C++/WinRT'nin sonraki sürümleri yayımlandıkçe, bu konu başlığında yenilikler ve değişenler açıklanmaktadır.

Mart 2020 itibarıyla yapılan son iyileştirme/eklemelerin toplamı

%23’e kadar daha kısa derleme süreleri

C++/WinRT ve C++ derleyici ekipleri, derleme sürelerini kısaltmak için mümkün olan her şeyi yapmak için işbirliği yaptı. C++ derleyicisinin derleme süresi ek yükünü ortadan kaldırmasına yardımcı olmak için C++/WinRT’nin iç yapısının nasıl yeniden düzenlenebileceğini ve C++ derleyicisinin C++/WinRT kitaplığını işleyebilmesi için nasıl iyileştirilebileceğini belirlemek üzere derleyici analizlerini ayrıntılı biçimde inceledik. C++/WinRT derleyici için iyileştirilmiştir; ve derleyici C++/WinRT için iyileştirilmiştir.

Örneğin, tek tek tüm C++/WinRT projeksiyon ad alanı üst bilgilerini içeren önceden derlenmiş bir üst bilgi (PCH) oluşturma gibi en kötü durum senaryosunu ele alalım.

Sürüm PCH boyutu (bayt) Saat (s)
Visual C++ 16.3 ile Temmuz'dan itibaren C++/WinRT 3,004,104,632 31
C++/WinRT sürüm 2.0.200316.3, Visual C++ 16.5 2,393,515,336 24

Boyutta %20, derleme süresinde ise %23 azalma.

Geliştirilmiş MSBuild desteği

Çok çeşitli senaryolar için MSBuild desteğini geliştirmek için çok fazla çalışma yaptık.

Daha da hızlı önbellekleme

Daha iyi satır içi sık erişim yolları sağlamak ve bu da daha hızlı yürütmeye yol açmak için fabrika önbelleğinin satır içi olarak eklenmesini geliştirdik.

Bu geliştirme kod boyutunu etkilemez; aşağıda İyileştirilmiş EH kod-gen bölümünde açıklandığı gibi, uygulamanız C++ özel durum işlemeyi yoğun olarak kullanıyorsa, Visual Studio 2019 16.3 ve sonraki sürümlerle oluşturulan yeni projelerde varsayılan olarak açık olan seçeneği kullanarak /d2FH4 ikili dosyanızı daraltabilirsiniz.

Daha verimli boks

Bir XAML uygulamasında kullanıldığında winrt::box_value artık daha verimlidir (bkz . Kutulama ve kutu açma). Çok fazla kutulama işlemi gerçekleştiren uygulamalar da kod boyutunun küçüldüğünü fark eder.

IInspectable uygulayan COM arabirimlerini uygulama desteği

IInspectable da uygulayan bir (Windows Runtime olmayan) COM arabirimini uygulamanız gerekiyorsa, artık bunu C++/WinRT ile yapabilirsiniz. Bkz. IInspectable uygulayan COM arabirimleri.

Modül kilitleme geliştirmeleri

Modül kilitleme üzerinde denetim artık hem özel barındırma senaryolarına hem de modül düzeyinde kilitlemenin tamamen ortadan kaldırılmasına olanak tanır. Bkz . Modül kilitleme geliştirmeleri.

Windows-Runtime dışı hata bilgileri için destek

Bazı API'ler (hatta bazı Windows Çalışma Zamanı API'ler) Windows Çalışma Zamanı hata kaynağı API'leri kullanmadan hataları bildirir. Böyle durumlarda C++/WinRT artık COM hata bilgilerini kullanmaya geri döner. WinRT dışı hata bilgileri için bkz. C++/WinRT desteği.

C++ modül desteğini etkinleştirme

C++ modülü desteği geri döndü, ancak yalnızca deneysel bir biçimde. Özellik henüz C++ derleyicisinde tamamlanmamıştır.

Coroutine'lerin daha verimli sürdürülmesi

C++/WinRT yordamları zaten iyi performans gösteriyor, ancak bunu geliştirmenin yollarını aramaya devam ediyoruz. Bkz. Coroutine resumption'ın ölçeklenebilirliğini geliştirme.

Yeni when_all ve when_any eşzamansız yardımcıları

when_all yardımcı işlevi, sağlanan tüm beklenebilir öğeler tamamlandığında tamamlanan bir IAsyncAction nesnesi oluşturur. when_any yardımcı, sağlanan beklenebilir öğelerden herhangi biri tamamlandığında tamamlanan bir IAsyncAction oluşturur.

Bkz. when_any eşzamansız yardımcısını ekleyin ve when_all eşzamansız yardımcısını ekleyin.

Diğer iyileştirmeler ve eklemeler

Ayrıca, hata ayıklamayı basitleştirmeye ve iç ve varsayılan uygulamaları iyileştirmeye yönelik çeşitli iyileştirmeler de dahil olmak üzere birçok hata düzeltmesi ve küçük iyileştirmeler ve eklemeler kullanıma sunulmuştur. Kapsamlı bir liste için şu bağlantıyı izleyin: https://github.com/microsoft/xlang/pulls?q=is%3Apr+is%3Aclosed.

C++/WinRT 2.0'da haberler ve değişiklikler

C++/WinRT Visual Studio Uzantısı (VSIX) hakkında daha fazla bilgi için Microsoft.Windows. CppWinRT NuGet paketi ve cppwinrt.exe bunların nasıl alınıp yükleneceği de dahil olmak üzere araç için bkz. C++/WinRT, XAML, VSIX uzantısı ve NuGet paketi için Visual Studio desteği.

Sürüm 2.0 için C++/WinRT Visual Studio Uzantısında (VSIX) yapılan değişiklikler

  • Hata ayıklama görselleştiricisi artık Visual Studio 2019'un yanı sıra Visual Studio 2017'yi desteklemeye devam ediyor.
  • Çok sayıda hata düzeltmesi yapılmıştır.

Microsoft.Windows.CppWinRT NuGet paketindeki 2.0 sürümü değişiklikleri

  • cppwinrt.exe aracı artık Microsoft.Windows.CppWinRT NuGet paketine dahildir ve araç, her proje için isteğe bağlı olarak platform projeksiyon başlıkları oluşturur. Sonuç olarak, cppwinrt.exe araç artık Windows SDK'sine bağımlı değildir (ancak araç uyumluluk nedeniyle sdk ile birlikte gönderilir).
  • cppwinrt.exe artık paralel derlemeleri etkinleştirmek için her platforma ve yapılandırmaya özgü ara klasöründe ($IntDir) projeksiyon başlık dosyaları oluşturur.
  • Proje dosyalarınızı el ile özelleştirmek istemeniz durumunda C++/WinRT derleme desteği (props/targets) artık tamamen belgelenmiştir. Microsoft.Windows.CppWinRT NuGet paketinin README dosyasına bakın.
  • Çok sayıda hata düzeltmesi yapılmıştır.

Sürüm 2.0 için C++/WinRT'de yapılan değişiklikler

Açık kaynak

Araç cppwinrt.exe bir Windows Çalışma Zamanı meta veri (.winmd) dosyası alır ve meta verilerde açıklanan API'leri projeleyen üst bilgi dosyası tabanlı standart bir C++ kitaplığı oluşturur. Bu şekilde, C++/WinRT kodunuzdan bu API'leri kullanabilirsiniz.

Bu araç artık GitHub üzerinde kullanılabilen tamamen açık kaynak bir projedir. Microsoft/cppwinrt adresini ziyaret edin.

xlang kitaplıkları

Tamamen taşınabilir, yalnızca üst bilgi dosyalarından oluşan bir kitaplık (Windows Çalışma Zamanı tarafından kullanılan ECMA-335 meta veri biçimini ayrıştıran), bundan böyle tüm Windows Çalışma Zamanı ve xlang araçlarının temelini oluşturur. Özellikle, cppwinrt.exe aracını xlang kitaplıklarını kullanarak sıfırdan yeniden yazdık. Bu, C++/WinRT dil projeksiyonuyla ilgili uzun süredir devam eden birkaç sorunu çözerek çok daha doğru meta veri sorguları sağlar.

Daha az bağımlılık

xlang meta veri okuyucusu nedeniyle aracın cppwinrt.exe kendisi daha az bağımlılık içerir. Bu, özellikle kısıtlanmış derleme ortamlarında daha fazla senaryoda kullanılabilir olmasının yanı sıra çok daha esnek olmasını sağlar. Özellikle, artık RoMetadata.dll’a dayanmıyor.   Bunlar 2.0 için cppwinrt.exe bağımlılıklardır.  

  • ADVAPI32.dll
  • KERNEL32.dll
  • SHLWAPI.dll
  • XmlLite.dll

Tüm bu DLL'ler yalnızca Windows 10'da değil, Windows 7'de ve hatta Windows Vista'da da mevcuttur. İsterseniz, Windows 7 çalıştıran eski derleme sunucunuz artık projeniz için C++ üst bilgileri oluşturmak üzere çalıştırılabilircppwinrt.exe. Biraz çalışmayla, ilginizi çeken bir Windows 7 üzerinde C++/WinRT bile çalıştırabilirsiniz.

Yukarıdaki listeyi, cppwinrt.exe 1.0 sürümünün sahip olduğu bu bağımlılıklarla karşılaştırın.

  • ADVAPI32.dll
  • SHELL32.dll
  • api-ms-win-core-file-l1-1-0.dll
  • XmlLite.dll
  • api-ms-win-core-libraryloader-l1-2-0.dll
  • api-ms-win-core-processenvironment-l1-1-0.dll
  • RoMetadata.dll
  • SHLWAPI.dll
  • KERNEL32.dll
  • api-ms-win-core-rtlsupport-l1-1-0.dll
  • api-ms-win-core-heap-l1-1-0.dll
  • api-ms-win-core-timezone-l1-1-0.dll
  • api-ms-win-core-console-l1-1-0.dll
  • api-ms-win-core-localization-l1-2-0.dll
  • OLEAUT32.dll
  • api-ms-win-core-winrt-error-l1-1-0.dll
  • api-ms-win-core-winrt-error-l1-1-1.dll
  • api-ms-win-core-winrt-l1-1-0.dll
  • api-ms-win-core-winrt-string-l1-1-0.dll
  • api-ms-win-core-synch-l1-1-0.dll
  • api-ms-win-core-threadpool-l1-2-0.dll
  • api-ms-win-core-com-l1-1-0.dll
  • api-ms-win-core-com-l1-1-1.dll
  • api-ms-win-core-synch-l1-2-0.dll

Windows Çalışma Zamanı noexcept özniteliği

Windows Çalışma Zamanı, [noexcept] yöntemlerinizi ve özelliklerinizi süslemek için kullanabileceğiniz yeni bir özniteliği vardır. özniteliğinin varlığı, uygulamanızın özel durum oluşturmadığını (veya başarısız bir HRESULT döndürmediğini) destekleyen araçlara işaret eder. Bu, dil projeksiyonlarının başarısız olabilecek uygulama ikili arabirimi (ABI) çağrılarını desteklemek için gereken özel durum işleme ek yükünü önleyerek kod oluşturmayı iyileştirmesine olanak tanır.

C++/WinRT, hem tüketen hem de yazan kodun C++ noexcept uygulamalarını üreterek bundan yararlanır. Hatasız API yöntemleriniz veya özellikleriniz varsa ve kod boyutuyla ilgileniyorsanız, bu özniteliği araştırabilirsiniz.

İyileştirilmiş kod oluşturma

C++/WinRT artık C++ derleyicisinin mümkün olan en küçük ve en verimli ikili kodu üretebilmesi için daha da verimli C++ kaynak kodu (arka planda) oluşturur. Geliştirmelerin çoğu gereksiz geri alma bilgilerinden kaçınarak özel durum işleme maliyetini azaltmaya yöneliktir. Büyük miktarda C++/WinRT kodu kullanan ikili dosyalar, kod boyutunda yaklaşık %4'lük bir azalma görecektir. Daha az yönerge sayısı nedeniyle kod daha verimlidir (daha hızlı çalışır).

Bu geliştirmeler, sizin için de kullanılabilen yeni bir birlikte çalışma özelliğine dayanır. Kaynak sahibi olan tüm C++/WinRT türleri artık önceki iki adımlı yaklaşımdan kaçınarak doğrudan sahiplik almak için bir oluşturucu içeriyor.

ABI::Windows::Foundation::IStringable* raw = ...

IStringable projected(raw, take_ownership_from_abi);

printf("%ls\n", projected.ToString().c_str());

İyileştirilmiş özel durum işleme (EH) kod oluşturma

Bu değişiklik, özel durum işleme maliyetini azaltmak için Microsoft C++ iyileştirici takımı tarafından yapılan çalışmayı tamamlar. Kodunuzda yoğun olarak uygulama ikili arabirimleri (ABI' ler) (COM gibi) kullanıyorsanız, bu deseni izleyen çok sayıda kod gözlemlersiniz.

int32_t Function() noexcept
{
    try
    {
        // code here constitutes unique value.
    }
    catch (...)
    {
        // code here is always duplicated.
    }
}

C++/WinRT, uygulanan her API için bu düzeni oluşturur. Binlerce API işleviyle buradaki iyileştirmeler önemli olabilir. Geçmişte iyileştirici, bu yakalama bloklarının tümünün aynı olduğunu algılamıyordu, bu nedenle her ABI'nin etrafında çok fazla kod çoğaltıyordu (bu da sistem kodunda özel durum kullanmanın büyük ikili dosyalar ürettiği inancına katkıda bulundu). Ancak Visual Studio 2019’dan itibaren C++ derleyicisi bu catch funclet’lerinin tümünü birleştirir ve yalnızca benzersiz olanları depolar. Sonuç olarak, bu desene büyük ölçüde dayanan ikili dosyalar için kod boyutunda toplamda ek %18’lik bir azalma sağlanır. EH kodu artık iade kodlarını kullanmaktan daha verimli olmakla kalmaz, aynı zamanda daha büyük ikili dosyalar hakkındaki endişe artık geçmişte kaldı.

Artımlı derleme geliştirmeleri

Araç cppwinrt.exe artık oluşturulan üst bilgi/kaynak dosyasının çıkışını diskteki mevcut herhangi bir dosyanın içeriğiyle karşılaştırır ve yalnızca dosya aslında değişmişse dosyayı yazar. Bu, disk G/Ç ile önemli ölçüde zaman kazandırır ve dosyaların C++ derleyicisi tarafından "kirli" olarak kabul edilmemesini sağlar. Sonuç olarak, yeniden derleme önlenir veya çoğu durumda azaltılır.

Genel arabirimlerin tümü artık oluşturulur

Xlang meta veri okuyucusu nedeniyle C++/WinRT artık meta verilerden tüm parametreli veya genel arabirimleri oluşturur. Windows::Foundation::Collections::IVector<T> gibi arabirimler artık winrt/base.h içinde elle yazılmak yerine meta verilerden oluşturulmaktadır. Bunun sonucu olarak, winrt/base.h boyutu yarıya indi ve optimizasyonlar doğrudan kodun içine yerleştirildi (bunu elle geliştirilen yaklaşımla yapmak zordu).

Önemli

Verilen örnekteki gibi arabirimler artık winrt/base.h yerine ilgili ad alanı başlıklarında görünür. Bu nedenle, henüz yapmadıysanız arabirimi kullanmak için uygun ad alanı üst bilgisini eklemeniz gerekir.

Bileşen iyileştirmeleri

Bu güncelleştirme, aşağıdaki bölümlerde açıklanan C++/WinRT için çeşitli ek kabul iyileştirmeleri için destek ekler. Bu iyileştirmeler geriye dönük uyumluluğu bozan değişiklikler olduğundan (bunları desteklemek için küçük değişiklikler yapmanız gerekebilir), bunları açıkça etkinleştirmeniz gerekir. Visual Studio'da,C++/WinRT>için İyileştirilmiş> proje özelliğini Evet olarak ayarlayın. Bu, proje dosyanıza <CppWinRTOptimized>true</CppWinRTOptimized> eklenmesine neden olur. Ve bu, -opt[imize] komut satırından çağrılırken cppwinrt.exe anahtarını eklemekle aynı etkiye sahiptir.

Yeni bir proje (bir proje şablonundan oluşturulan) varsayılan olarak -opt kullanacaktır.

Tekdüzen oluşturma ve doğrudan uygulama erişimi

Bu iki iyileştirme, yalnızca öngörülen türleri kullanırken bile bileşeninizin kendi uygulama türlerine doğrudan erişmesine olanak sağlar. Yalnızca genel API yüzeyini kullanmak istiyorsanız make, make_self veya get_self kullanmanız gerekmez. Çağrılarınız, gerçeklemeye yapılan doğrudan çağrılara derlenir ve bunlar hatta tamamen satır içi hâle bile getirilebilir.

Daha fazla bilgi ve kod örnekleri için bkz. Tekdüzen oluşturma ve doğrudan uygulama erişimini kabul etme.

Tür silme fabrikaları

Bu iyileştirme, içindeki #include bağımlılıklarını önler, böylece tek bir uygulama sınıfı her değiştiğinde module.g.cpp yeniden derlenmemesi gerekir. Sonuç, geliştirilmiş derleme performansıdır.

Birden çok lib içeren büyük projeler için daha akıllı ve daha verimli module.g.cpp

module.g.cpp dosyası artık winrt_can_unload_now ve winrt_get_activation_factory adlı iki ek birleştirilebilir yardımcı da içeriyor. Bunlar, DLL'nin her biri kendi çalışma zamanı sınıflarına sahip bir dizi lib'in yer aldığı daha büyük projeler için tasarlanmıştır. Bu durumda DLL'nin DllGetActivationFactory ve DllCanUnloadNow dosyalarını el ile birleştirmeniz gerekir. Bu yardımcılar, sahte kaynak hatalarından kaçınarak bunu yapmanızı çok daha kolay hale getirir. cppwinrt.exe aracının -lib bayrağı, her bir lib’e kendi ön ekini vermek için de kullanılabilir ( winrt_xxx yerine ); böylece her lib’in işlevleri ayrı ayrı adlandırılabilir ve dolayısıyla belirsizliğe yol açmadan birleştirilebilir.

Coroutine desteği

Coroutine desteği otomatik olarak eklenir. Daha önce, destek birden çok yerde bulunuyordu ve bu çok sınırlayıcı olduğunu hissettik. Ardından v2.0 için geçici olarak bir winrt/coroutine.h üst bilgi dosyası gerekliydi, ancak bu artık gerekli değildir. Windows Çalışma Zamanı eşzamansız arabirimleri artık elle yazılmak yerine oluşturulduğundan, artık winrt/Windows.Foundation.h içinde yer alıyorlar. Bakımı ve desteklenmesi daha kolay olmasının yanı sıra, bu, resume_foreground gibi eş yordam yardımcılarının artık belirli bir ad alanı başlık dosyasının sonuna eklenmek zorunda olmadığı anlamına gelir. Bunun yerine bağımlılıklarını daha doğal bir şekilde içerebilirler. Bu, resume_foreground yalnızca belirli bir Windows::UI::Core::CoreDispatcher üzerinde devam etme desteği sağlamakla kalmaz, aynı zamanda artık belirli bir Windows::System::D ispatcherQueue'da devam edilmesini de destekleyebilir. Daha önce yalnızca bir tane desteklenebilirdi; ancak her ikisini birden değil, çünkü tanım yalnızca bir ad alanında yer alabilir.

DispatcherQueue desteğinin bir örneği aşağıda verilmiştir.

...
#include <winrt/Windows.System.h>
using namespace Windows::System;
...
fire_and_forget Async(DispatcherQueueController controller)
{
    bool queued = co_await resume_foreground(controller.DispatcherQueue());
    assert(queued);

    // This is just to simulate queue failure...
    co_await controller.ShutdownQueueAsync();

    queued = co_await resume_foreground(controller.DispatcherQueue());
    assert(!queued);
}

Coroutine yardımcıları artık [[nodiscard]] ile de dekore edilmiştir; böylece kullanılabilirlikleri iyileştirilmiştir. Bunların çalışması için üzerlerinde co_await yapmayı unutursanız (ya da bunu yapmanız gerektiğini fark etmezseniz), [[nodiscard]] nedeniyle bu tür hatalar artık bir derleyici uyarısına neden olur.

Doğrudan (yığın) ayırmaları tanılama konusunda yardım

Yansıtılan ve uygulama sınıfı adları (varsayılan olarak) aynı olduğundan ve yalnızca ad alanları farklı olduğundan, birini diğeriyle karıştırmak ve make yardımcıları ailesini kullanmak yerine yanlışlıkla yığında bir uygulama oluşturmak mümkündür. Bazı durumlarda bunu teşhis etmek zor olabilir, çünkü henüz tamamlanmamış referanslar hâlâ işlenirken nesne yok edilebilir. Bir assert artık bunu hata ayıklama derlemelerinde yakalar. Assert ifadesi, bir coroutine içinde stack üzerinde bellek ayırmayı algılamasa da, bu tür hataların çoğunu yakalamaya yine de yardımcı olur.

Daha fazla bilgi için bkz. Doğrudan ayırmaları tanılama.

Geliştirilmiş yakalama yardımcıları ve variadic temsilciler

Bu güncelleştirme, öngörülen türleri de destekleyerek yakalama yardımcılarıyla ilgili sınırlamayı düzeltir. Bu durum, Windows Çalışma Zamanı birlikte çalışabilirlik API'leri yansıtılmış bir tür döndürdüğünde zaman zaman ortaya çıkar.

Bu güncelleştirme ayrıca variadic (Windows Çalışma Zamanı olmayan) bir temsilci oluştururken get_strong ve get_weak desteği ekler.

Imha sırasında ertelenmiş imha ve güvenli QI desteği

Çalışma zamanı sınıfı nesnesinin yıkıcısında, referans sayısını geçici olarak artıran bir yöntemin çağrılması alışılmadık bir durum değildir. Başvuru sayacı sıfıra indiğinde, nesne ikinci kez imha edilir. Bir XAML uygulamasında, hiyerarşinin üst veya alt kısmındaki bazı temizleme uygulamalarını çağırmak için destructor içinde QueryInterface (QI) gerçekleştirmeniz gerekebilir. Ancak nesnenin referans sayısı zaten sıfıra düşmüş olduğundan, bu QI de bir referans sayısı sıçraması sayılır.

Bu güncelleştirme, başvuru sayısını kaldırma desteği ekleyerek sıfıra ulaştığında asla yeniden oluşturulamayacağından emin olur; ancak imha sırasında ihtiyacınız olan geçici bir süre için QI'ye izin verir. Bu yordam belirli XAML uygulamalarında/denetimlerinde kaçınılmazdır ve C++/WinRT artık buna dayanıklıdır.

Uygulama türünüzde statik bir final_release işlevi sağlayarak yok etme işlemini erteleyebilirsiniz. Nesneye kalan son işaretçi, std::unique_ptr olarak, final_release yönteminize iletilir. Daha sonra bu işaretçinin sahipliğini başka bir bağlama taşımayı tercih edebilirsiniz. Çifte imhayı tetiklemeden işaretçi üzerinde güvenle QI yapabilirsiniz. Ancak başvuru sayacındaki net değişiklik, nesneyi yok ettiğiniz anda sıfır olmalıdır.

final_release dönüş değeri, void, IAsyncAction gibi bir asenkron işlem nesnesi veya winrt::fire_and_forget olabilir.

struct Sample : implements<Sample, IStringable>
{
    hstring ToString()
    {
        return L"Sample";
    }

    ~Sample()
    {
        // Called when the unique_ptr below is reset.
    }

    static void final_release(std::unique_ptr<Sample> self) noexcept
    {
        // Move 'self' as needed to delay destruction.
    }
};

Aşağıdaki örnekte MainPage yayımlandıktan sonra (son kez) final_release çağrılır. Bu işlev, beş saniyeyi iş parçacığı havuzunda bekleyerek geçirir ve ardından sayfanın Dispatcher'ını kullanarak devam eder (bu da çalışmak için QI/AddRef/Release gerektirir). Ardından o UI iş parçacığında bir kaynağı temizler. Ve son olarak unique_ptr'ı temizler; bu da MainPage yıkıcısının gerçekten çağrılmasına neden olur. Bu yıkıcıda bile, DataContext çağrılır; bu da IFrameworkElement için bir QI gerektirir.

final_release'i bir eş yordam olarak uygulamak zorunda değilsiniz. Ama bu işe yarıyor ve imha işlemini farklı bir iş parçacığına taşımayı çok kolaylaştırıyor; bu örnekte olan da tam olarak budur.

struct MainPage : PageT<MainPage>
{
    MainPage()
    {
    }

    ~MainPage()
    {
        DataContext(nullptr);
    }

    static IAsyncAction final_release(std::unique_ptr<MainPage> self)
    {
        co_await 5s;

        co_await resume_foreground(self->Dispatcher());
        co_await self->resource.CloseAsync();

        // The object is destructed normally at the end of final_release,
        // when the std::unique_ptr<MyClass> destructs. If you want to destruct
        // the object earlier than that, then you can set *self* to `nullptr`.
        self = nullptr;
    }
};

Daha fazla bilgi için bkz. Ertelenen yok etme.

COM tarzı tek arabirimli kalıtım için geliştirilmiş destek

C++/WinRT, Windows Çalışma Zamanı programlamanın yanı sıra yalnızca COM API'lerini yazmak ve kullanmak için de kullanılır. Bu güncelleştirme, arabirim hiyerarşisi bulunan bir COM sunucusu uygulamayı mümkün kılar. Bu, Windows Çalışma Zamanı için gerekli değildir, ancak bazı COM uygulamaları için gereklidir.

out parametrelerinin doğru işlenmesi

out parametrelerle uğraşmak; özellikle de Windows Çalışma Zamanı dizileriyle, zor olabilir. Bu güncelleştirmeyle C++/WinRT, parametreler ve diziler söz konusu out olduğunda, bu parametrelerin bir dil projeksiyonu aracılığıyla mı yoksa ham ABI kullanan bir COM geliştiricisinden mi geldiği ve değişkenleri tutarlı bir şekilde başlatmama hatası yapan bir COM geliştiricisinden gelen hatalara karşı oldukça daha sağlam ve dayanıklıdır. Her iki durumda da, C++/WinRT artık yansıtılan türleri ABI'ye teslim etme (kaynakları serbest bırakmaya dikkat ederek) ve ABI üzerinden gelen parametrelerin sıfırlanması veya temizlenmesi söz konusu olduğunda doğru şeyi yapar.

Olaylar artık geçersiz belirteçleri güvenilir bir şekilde işleyecek

winrt::event uygulaması artık kaldırma yönteminin geçersiz bir belirteç değeriyle (dizide bulunmayan bir değer) çağrıldığı durumu düzgün bir şekilde işler.

Coroutine yerel değişkenleri artık coroutine geri dönmeden önce yok edilir

Geleneksel bir eş yordam türünü uygulama yöntemi, eş yordam içindeki yerel değişkenlerin, nihai askıya almadan önce değil, eş yordam döndükten/tamamlandıktan sonra yok edilmesine izin verebilir. Bu sorundan kaçınmak ve diğer avantajları tahakkuk etmek için artık herhangi bir garsonun yeniden başlatılması son askıya alınmaya kadar ertelenmiş durumdadır.

Windows SDK sürüm 10.0.17763.0 (Windows 10, sürüm 1809) ile ilgili haberler ve değişiklikler

Aşağıdaki tabloda, Windows SDK sürüm 10.0.17763.0 (Windows 10, sürüm 1809) içinde C++/WinRT ile ilgili haberler ve değişiklikler yer almaktadır.

Yeni veya değiştirilmiş özellik Daha fazla bilgi
Uyumsuzluğa neden olan değişiklik. Derlemek için C++/WinRT, Windows SDK'sının üst bilgilerine bağımlı değildir. Aşağıdaki Windows SDK üst bilgi dosyalarından yalıtım bölümüne bakın.
Visual Studio proje sistemi biçimi değişti. Aşağıdaki C++/WinRT projenizi Windows SDK'sının sonraki bir sürümüne yeniden hedefleme bölümüne bakın.
Bir koleksiyon nesnesini bir Windows Çalışma Zamanı işlevine geçirmenize veya kendi koleksiyon özelliklerinizi ve koleksiyon türlerinizi uygulamanıza yardımcı olacak yeni işlevler ve temel sınıflar vardır. Bkz. C++/WinRT ile Koleksiyonlar.
C++/WinRT çalışma zamanı sınıflarınızla {Binding} işaretleme uzantısını kullanabilirsiniz. Daha fazla bilgi ve kod örnekleri için bkz. Veri bağlamaya genel bakış.
Bir eş yordam iptal etme desteği, iptal geri çağırmasını kaydetmenize olanak tanır. Daha fazla bilgi ve kod örnekleri için bkz. Zaman uyumsuz işlemi iptal etme ve iptal geri çağırmaları.
Bir üye işleve işaret eden temsilci oluştururken, işleyicinin kaydedildiği noktada geçerli nesneye (ham bir this işaretçisi yerine) güçlü ya da zayıf bir başvuru oluşturabilirsiniz. Daha fazla bilgi ve kod örnekleri için, Olay işleme temsilcisiyle bu işaretçiye güvenli bir şekilde erişme bölümündeki Temsilci olarak üye işlevi kullanıyorsanız alt bölümüne bakın.
Visual Studio'nun C++ standardıyla daha iyi uyumlu hale gelmesiyle ortaya çıkan hatalar giderildi. LLVM ve Clang araç zinciri, C++/WinRT standartlarının uyumluluğunun doğrulanması için daha iyi bir şekilde kullanılabilir. Artık yeni projem neden derlenemiyor? başlığı altında açıklanan sorunla karşılaşmazsınız. Visual Studio 2017 (sürüm 15.8.0 veya üzeri) ve SDK sürüm 17134 kullanıyorum

Diğer değişiklikler.

  • Uyumsuzluğa neden olan değişiklik. winrt::get_abi(winrt::hstring const&) artık void* yerine HSTRING döndürür. HSTRING almak için static_cast<HSTRING>(get_abi(my_hstring)); kullanabilirsiniz. Bkz. ABI'nin HSTRING'i ile birlikte çalışma.
  • Uyumsuzluğa neden olan değişiklik. winrt::put_abi(winrt::hstring&) artık void** yerine HSTRING* döndürür. reinterpret_cast<HSTRING*>(put_abi(my_hstring));, bir HSTRING* elde etmek için kullanılabilir. Bkz. ABI'nin HSTRING'i ile birlikte çalışma.
  • Uyumsuzluğa neden olan değişiklik. HRESULT artık winrt::hresult olarak yansıtılır. HRESULT 'a ihtiyacınız varsa (tür denetimi yapmak veya tür özelliklerini desteklemek için), static_cast yapabilirsiniz. Aksi takdirde, herhangi bir C++/WinRT başlığını dahil etmeden önce dosyasını dahil ettiğiniz sürece unknwn.h, HRESULT'a dönüştürülür.
  • Uyumsuzluğa neden olan değişiklik. GUID artık winrt::guid olarak yansıtılır. Uyguladığınız API'ler için GUID parametreleri için winrt::guid kullanmalısınız. Aksi takdirde, herhangi bir C++/WinRT üst bilgisini eklemeden önce eklerseniz, unknwn.h GUID’e dönüşür. Bkz. ABI'nin GUID yapısıyla birlikte çalışma.
  • Uyumsuzluğa neden olan değişiklik. winrt::handle_type oluşturucu açık hale getirilerek sağlamlaştırılmıştır (artık yanlış kod yazmak daha zordur). Ham tanıtıcı değeri atamanız gerekiyorsa bunun yerine handle_type::attach işlevini çağırın.
  • Uyumsuzluğa neden olan değişiklik. WINRT_CanUnloadNow ve WINRT_GetActivationFactory imzaları değişti. Bu işlevleri hiç bildirmemelisiniz. Bunun yerine, bu işlevlerin bildirimlerini dahil etmek için winrt/base.h ekleyin (herhangi bir C++/WinRT Windows ad alanı başlık dosyasını eklerseniz bu dosya otomatik olarak eklenir).
  • winrt::clock yapısı için from_FILETIME/to_FILETIME, from_file_time/to_file_time tercih edilerek kullanım dışı bırakılmıştır.
  • IBuffer parametreleri bekleyen basitleştirilmiş API'ler. Çoğu API koleksiyonları veya dizileri tercih eder. Ancak IBuffer'a dayanan API'leri çağırmayı daha kolay hale getirmemiz gerektiğini düşündük. Bu güncelleştirme, bir IBuffer uygulamasının arkasındaki verilere doğrudan erişim sağlar. C++ Standart Kitaplık kapsayıcıları tarafından kullanılanla aynı veri adlandırma kuralını kullanır. Bu kural, geleneksel olarak büyük harfle başlayan meta veri adlarıyla çakışmaları da önler.
  • Geliştirilmiş kod oluşturma: Kod boyutunu küçültmeye, inlining'i geliştirmeye ve fabrika önbelleğini iyileştirmeye yönelik çeşitli geliştirmeler.
  • Gereksiz özyineleme kaldırıldı. Komut satırı, belirli bir .winmd yerine bir klasöre işaret ettiğinde, cppwinrt.exe aracı artık .winmd dosyalarını özyinelemeli olarak aramaz. Araç cppwinrt.exe artık yinelenenleri daha akıllı bir şekilde işleyip kullanıcı hatasına ve kötü biçimlendirilmiş .winmd dosyalara daha dayanıklı hale getiriyor.
  • Sağlamlaştırılmış akıllı işaretçiler. Daha önce, taşımaya yeni bir değer atandığında olay iptal edenlerin iptali başarısız oldu. Bu, akıllı işaretçi sınıflarının kendi kendine atamayı güvenilir şekilde işleyemediği ve kökeni winrt::com_ptr yapı şablonunda yatan bir sorunun ortaya çıkarılmasına yardımcı oldu. winrt::com_ptr düzeltildi; ayrıca olay geri alma nesneleri de, atama sırasında geri alma işlemini gerçekleştirecek şekilde taşıma semantiğini doğru biçimde işleyecek şekilde düzeltildi.

Önemli

C++/WinRT Visual Studio Uzantısı'nda (VSIX) hem sürüm 1.0.181002.2 hem de sonraki sürüm 1.0.190128.4'te önemli değişiklikler yapıldı. Bu değişikliklerin ayrıntıları ve bunların mevcut projelerinizi nasıl etkilediği hakkında bilgi için C++/WinRT için Visual Studio desteği ve VSIX uzantısının önceki sürümlerine bkz.

Windows SDK başlık dosyalarından yalıtım

Bu, kodunuz için uyumluluğu bozabilecek bir değişiklik olabilir.

Derlemek için C++/WinRT artık Windows SDK'sından üst bilgi dosyalarına bağımlı değildir. C çalışma zamanı kitaplığındaki (CRT) ve C++ Standart Şablon Kitaplığı'ndaki (STL) üst bilgi dosyaları da Windows SDK üst bilgileri içermez. Bu da standartlara uyumluluğu geliştirir, yanlışlıkla bağımlılıkları önler ve korumanız gereken makro sayısını büyük ölçüde azaltır.

Bu bağımsızlık, C++/WinRT'nin artık daha taşınabilir ve standartlara uygun olduğu anlamına gelir ve derleyiciler arası ve platformlar arası bir kitaplık olma olasılığını daha da ilerletir. Ayrıca, C++/WinRT üst bilgilerinin makrolardan olumsuz etkilenmemesi anlamına gelir.

Daha önce projenize Windows üst bilgileri eklemek için C++/WinRT'ye bıraktıysanız, bunları artık kendiniz eklemeniz gerekir. Her durumda, bağlı olduğunuz üst bilgileri açıkça dahil etmek ve bunları sizin için eklemek üzere başka bir kitaplığa bırakmamak her zaman en iyi yöntemdir.

Şu anda Windows SDK üst bilgi dosyası yalıtımına yönelik tek özel durumlar iç bilgiler ve sayısal öğelerdir. Bu son kalan bağımlılıklarla ilgili bilinen bir sorun yoktur.

Projenizde, gerekirse Windows SDK başlık dosyalarıyla birlikte çalışabilirliği yeniden etkinleştirebilirsiniz. Örneğin, bir COM arabirimi uygulamak isteyebilirsiniz (kök olarak IUnknown kullanılır). Bu örnekte, C++/WinRT üst bilgilerini eklemeden önce ekleyin unknwn.h . Bunun yapılması, C++/WinRT temel kitaplığının klasik COM arabirimlerini desteklemek için çeşitli kancaları etkinleştirmesine neden olur. Kod örneği için bkz. C++/WinRT ile COM bileşenleri yazma. Benzer şekilde, çağırmak istediğiniz türleri ve/veya işlevleri bildiren diğer Windows SDK üst bilgilerini açıkça ekleyin.

C++/WinRT projenizi Windows SDK'nın daha sonraki bir sürümüne yeniden hedefleme

En az derleyici ve bağlayıcı sorununa neden olabilecek projenizi yeniden hedefleme yöntemi de en yoğun emek gerektiren yöntemdir. Bu yöntem, yeni bir proje oluşturmayı (seçtiğiniz Windows SDK sürümünü hedeflemeyi) ve ardından dosyaları eski projenizden yeni projenize kopyalamayı içerir. Eski .vcxproj ve .vcxproj.filters dosyalarınızda, Visual Studio’da dosya eklemek zorunda kalmamak için doğrudan kopyalayabileceğiniz bazı bölümler olacaktır.

Ancak, projenizi Visual Studio'da yeniden hedeflemenin iki yolu daha vardır.

  • Genel>Windows SDK Sürümü proje özelliğine gidin ve Tüm Yapılandırmalar ve Tüm Platformlar'ı seçin. Windows SDK Sürümünü hedeflemek istediğiniz sürüme ayarlayın.
  • Çözüm Gezgini proje düğümüne sağ tıklayın, Projeleri Yeniden Hedefle'ye tıklayın, hedeflemek istediğiniz sürümleri seçin ve ardından Tamam'a tıklayın.

Bu iki yöntemden birini kullandıktan sonra derleyici veya bağlayıcı hatalarıyla karşılaşırsanız, yeniden derlemeyi denemeden önce çözümü temizlemeyi deneyebilirsiniz (Temiz Çözüm> ve/veya tüm geçici klasörleri ve dosyaları el ile silin).

C++ derleyicisi "hata C2039: 'IUnknown': ''global namespace'' üyesi değil" hatası üretirse, dosyanızın #include <unknwn.h> en üstüne ekleyin pch.h (C++/WinRT üst bilgilerini eklemeden önce).

Bundan sonra da eklemeniz #include <hstring.h> gerekebilir.

C++ bağlayıcısı "error LNK2019: unresolved external symbol _WINRT_CanUnloadNow@0 referenced in function _VSDesignerCanUnloadNow@0" hatasını verirse, #define _VSDESIGNER_DONT_LOAD_AS_DLL öğesini pch.h dosyanıza ekleyerek bu sorunu çözebilirsiniz.

  • Last updated on