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++/WinRT'nin iç bileşenlerinin, C++ derleyicisinin derleme süresi ek yükünü ortadan kaldırmasına nasıl yardımcı olabileceğini ve C++ derleyicisinin C++/WinRT kütüphanesini işlemek için nasıl iyileştirilebileceğini belirlemek amacıyla derleyici analitiklerini derinlemesine inceledik. C++/WinRT derleyici için iyileştirilmiştir; ve derleyici C++/WinRT için iyileştirilmiştir.

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

Sürüm PCH boyutu (bayt) Saat (s)
Temmuz ayından itibaren Visual C++ 16.3 ile C++/WinRT 3,004,104,632 31
C++/WinRT sürüm 2.0.200316.3, Visual C++ 16.5 2,393,515,336 yirmi dört

Boyutta 20% azalma ve derleme süresinde 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ı fabrika önbelleğe alma

Fabrika önbelleğinin satır içi önbellekleme mekanizmasını, sık kullanılan yolları daha iyi optimize edebilmek için geliştirdik ve bu da daha hızlı bir yürütmeye yol açıyor.

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ğini 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

yalnızca IInspectableuygulamak için bir (Windows-Runtimeolmayan) COM arabirimi uygulamanız gerekiyorsa, bunu artık C++/WinRT ile yapabilirsiniz. IInspectable'i uygulayan COM arabirimlerini görün.

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 olmayan hata bilgileri desteği

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

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.

Daha verimli coroutine devam ettirme

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

Yeni when_all ve when_any asenkron 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ı, belirtilen beklenebilir öğelerden herhangi biri tamamlandığında tamamlanan bir IAsyncAction oluşturur.

Bkz. when_any eşzamansız yardımcıyı ekle ve when_all eşzamansız yardımcıyı ekle.

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), Microsoft.Windows.CppWinRT NuGet paketive aracı hakkında daha fazla bilgi için bkz. C++/WinRT, XAML, VSIX uzantısı ve NuGet paketiiç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'u desteklemektedir ve Visual Studio 2017'yi desteklemeye de devam etmektedir.
  • Çok sayıda hata düzeltmesi yapılmıştır.

Sürüm 2.0 için Microsoft.Windows.CppWinRT NuGet paketinde yapılan değişiklikler

  • Araç cppwinrt.exe artık Microsoft.Windows.CppWinRT NuGet paketine dahil edilir ve araç isteğe bağlı olarak her proje için platfom projeksiyon üst bilgileri 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 her platforma/yapılandırmaya özgü ara klasörün ($IntDir) altında paralel derlemeleri mümkün kılmak için projeksiyon üst bilgilerini oluşturuyor.
  • 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 paketine bakın readme'yi.
  • Ç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

cppwinrt.exe aracı bir Windows Çalışma Zamanı meta verileri (.winmd) dosyasını alır ve bu meta verilere dayanarak açıklanan API'leri projelendiren üst bilgi dosyası tabanlı standart bir C++ kütüphanesi oluşturur. Bu şekilde, C++/WinRT kodunuzdan bu API'leri kullanabilirsiniz.

Bu araç artık GitHub'da kullanılabilen tamamen açık kaynak bir projedir. microsoft/cppwinrtadresini ziyaret edin.

xlang kitaplıkları

Tamamen taşınabilir, sadece üstbilgiye sahip bir kütüphane (Windows Çalışma Zamanı tarafından kullanılan ECMA-335 meta veri biçimini ayrıştırmak için), ileride tüm Windows Çalışma Zamanı ve xlang araçlarının temelini oluşturmaktadır. Dikkate değer şekilde, cppwinrt.exe aracını xlang kitaplıklarını kullanarak baştan sona 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 çok daha esnek olmasını ve daha fazla senaryoda kullanılabilir olmasını sağlar. Özellikle, artık RoMetadata.dll'a bağlı değil.   Bunlar 2.0 için cppwinrt.exe bağımlılıklardır.  

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

Bu DLL'lerin tümü yalnızca Windows 10'da değil, Windows 7'ye ve hatta Windows Vista'ya kadar her yerde kullanılabilir. Eğer istiyorsanız, Windows 7 çalıştıran eski derleme sunucunuz artık projeniz için C++ üst bilgileri oluşturmak amacıyla cppwinrt.exe çalıştırabilir. Biraz çalışmayla, ilginizi çekerse Windows 7'de C++/WinRT çalıştırabilirsiniz.

Yukarıdaki listeyi, 1.0 cppwinrt.exe 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 Runtime, [noexcept]'daki yöntemlerinizi ve özelliklerinizi süslemek için kullanabileceğiniz yeni bir özniteliğe sahiptir. ö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 kabaca 4% azalmayla karşılaşır. 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 tüm bu catch bloklarını birleştirir ve yalnızca benzersiz olanları depolar. Sonuç, bu desene büyük ölçüde dayanan ikili dosyalar için kod boyutunun daha fazla ve genel olarak 18% azaltılmasıdı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 el ile yazılmak yerine meta verilerden üretilmektedir. Sonuç olarak, winrt/base.h boyutu yarıya indirilmiş ve iyileştirmeler doğrudan koda eklenmiştir (bu, elle yazılmış bir yaklaşımla yapmak zordu).

Önemli

Verilen örnek gibi arabirimler artık winrt/base.h yerine, ilgili ad alanı üst bilgilerinde 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 uyumluluk açısından önemli değişiklikler olduğundan (desteklemek için küçük değişiklikler yapmanız gerekebilir), bunları manuel olarak etkinleştirmeniz gerekir. Visual Studio'da, proje özelliği Ortak ÖzelliklerC++/WinRTİyileştirilmiş, Evetolarak ayarlayın. Bu, proje dosyanıza <CppWinRTOptimized>true</CppWinRTOptimized> eklemenin etkisine sahiptir. En azından komut satırından -opt[imize] çağrılırken cppwinrt.exe anahtarı eklemekle aynı etkiye sahiptir.

Yeni bir proje (proje şablonundan) varsayılan olarak -opt kullanı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_selfve get_self kullanmanız gerekmez. Çağrılarınız, doğrudan uygulamanın içine yapılan çağrılar olarak derlenecek ve bunlar tamamen satır içi hale gelebilir.

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_nowve winrt_get_activation_factoryadlı iki ek birleştirilebilir yardımcı içerir. 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 DllCanUnloadNowfonksiyonlarını manuel olarak birleştirmeniz gerekiyor. Bu yardımcılar, sahte kaynak hatalarından kaçınarak bunu yapmanızı çok daha kolay hale getirir. Aracın cppwinrt.exe bayrağı, her bir lib'e kendi başlangıç bölümünü vermek (tek bir -lib yerine), her lib'in işlevlerinin ayrı ayrı adlandırılabilmesi ve böylece açık bir şekilde birleştirilmesi için de kullanılabilir.

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ı zaman uyumsuz arabirimleri, artık el ile yazılmak yerine oluşturulduğundan, şimdi winrt/Windows.Foundation.hiçinde yer alır. Daha sürdürülebilir ve desteklenebilir olmasının yanı sıra, resume_foreground gibi eş yordam yardımcılarının artık belirli bir ad alanı üst bilgisinin sonuna eklenmesine gerek kalmadığı 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, artık belirli bir Windows::System::D ispatcherQueuebelirli bir devam etme işlemini 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ılabilirliklerini geliştirebilirler. co_await onları çalışması için yapmayı unutmanız ya da yapmanız gerektiğini fark etmemeniz durumunda, [[nodiscard]]nedeniyle bu tür hatalar şimdi derleyici uyarısı üretmektedir.

Doğrudan (yığın) ayırmalara tanı koymaya yardım

Yansıtılan ve uygulama sınıf adları (varsayılan olarak) aynı olduğundan ve sadece ad alanındaki farklılıktan dolayı, birini diğeriyle karıştırmak ve yanlışlıkla yığında bir nesne oluşturmak yerine, make ailesindekileri kullanmak mümkündür. Bazı durumlarda bu tanılama zor olabilir, çünkü mevcut başvurular halen var iken nesne yok edilebilir. Hata ayıklama derlemeleri için bir doğrulama şimdi bunu yakalar. Doğrulama, bir coroutine içindeki yığın ayırmayı algılamasa da, bu tür hataların çoğunu yakalamada yine de yararlıdır.

Daha fazla bilgi için bkz. doğrudan ayırmaları teşhis etme.

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 Runtime birlikte çalışma API'leri bir yansıtılan tür döndürdüğünde zaman zaman ortaya çıkar.

Bu güncelleştirme, variadic (Windows Runtime dışında) bir temsilci oluştururken, get_strong ve get_weak için destek ekler.

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

Çalışma zamanı sınıf nesnesinin yıkıcısında, başvuru sayısını geçici olarak artıran bir yöntemi çağırmak sık karşılaşılan bir durumdur. Başvuru sayısı sıfıra döndüğünde, nesne ikinci kez yok edilir. XAML uygulamasında, hiyerarşide yukarı veya aşağı doğru bazı temizlik işlemlerini çağırmak için bir destructor içinde QueryInterface (QI) gerçekleştirmeniz gerekebilir. Ancak nesnenin başvuru sayısı zaten sıfıra ulaşmıştır, böylece QI de bir başvuru sayısı sıçraması oluşturur.

Bu güncelleştirme, başvuru sayısını azaltma desteği ekleyerek sıfıra ulaştığında asla yeniden canlandırılamayacağından emin olur; ancak imha işlemi sırasında ihtiyaç duyabileceğiniz herhangi bir geçici nesne için sorgulama yapmanıza 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. nesne için kalan son işaretçi, std::unique_ptrbiçiminde sizin final_release'e iletilir. Daha sonra bu işaretçinin sahipliğini başka bir bağlama taşımayı tercih edebilirsiniz. İşaretçiyi çift yok etme tetiklemeden QI yapmak sizin için güvenlidir. Ancak referans sayısındaki net değişiklik, nesneyi yok ettiğiniz noktada sıfır olmalıdır.

final_release dönüş değeri void, IAsyncActiongibi zaman uyumsuz bir işlem nesnesi veya winrt::fire_and_forgetolabilir.

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ş saniye bekler (iş parçacığı havuzunda) ve sayfanın Dispatcher (QI/AddRef/Release'ın çalışması için gereklidir) kullanılarak devam eder. Ardından kullanıcı arabirimi iş parçacığında bir kaynağı temizler. Son olarak unique_ptrtemizler ve bu da MainPage yıkıcısının gerçekten çağrılmasına neden olur. Bu yıkıcıda bile, IFrameworkElementiçin QI gerektiren DataContext çağrılır.

final_release'i bir korotin olarak uygulamanız gerekmez. Ancak bu gerçekten işe yarıyor ve yıkım işlemini farklı bir iş parçacığına taşımayı çok basit hale getiriyor, ki bu örnekte olan şey 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 stili tek arabirim devralma için geliştirilmiş destek

C++/WinRT, Windows Çalışma Zamanı programlamasını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.

Parametrelerin doğru işlenmesi out

Parametrelerle, özellikle de Windows Çalışma Zamanı dizileriyle out çalışmak zor olabilir. Bu güncelleştirme ile 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 sona ermeden önce yok ediliyor.

Geleneksel bir eş yordam türü uygulama yöntemi, coroutine dönüş/tamamlanma sonra (son süspansiyondan önce değil) coroutine içindeki yerel değişkenlerin 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'da (Windows 10, sürüm 1809) haberler ve değişiklikler

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

Yeni veya değiştirilmiş özellik Daha fazla bilgi
Uyum bozan değişiklik. Derlemek için C++/WinRT, Windows SDK'sının üst bilgilerine bağımlı değildir. Windows SDK üst bilgi dosyalarından, aşağıdaki ,bölümündeki yalıtıma bakın.
Visual Studio proje sistemi biçimi değişti. Aşağıda, C++/WinRT projenizi Windows SDK'nin daha sonraki bir sürümüne nasıl yeniden hedefleyeceğinizi anlatan venumaralı bölümlere bakın.
Windows Çalışma Zamanı işlevine koleksiyon nesnesi 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++/WinRTile 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 coroutine'i iptal etme desteği, bir 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ı.
Üye işlevine işaret eden bir temsilci oluştururken, işleyicinin kaydedildiği noktada geçerli nesneye (ham bu işaretçisi yerine) güçlü veya zayıf bir başvuru oluşturabilirsiniz. Daha fazla bilgi ve kod örnekleri için, Bir üye işlevini temsilci olarak kullanıyorsanız alt bölümüne bakın Bu işaretçisine olay işleme temsilcisiyle güvenli bir şekilde erişme.
Visual Studio'nun C++ standardına iyileştirilmiş uyumluluğu nedeniyle ortaya çıkan hatalar düzeltildi. 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.

  • Uyum bozan 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 HSTRINGile birlikte çalışma.
  • Uyum bozan değişiklik. winrt::put_abi(winrt::hstring&) artık void**yerine HSTRING* döndürür. HSTRING* almak için reinterpret_cast<HSTRING*>(put_abi(my_hstring)); kullanabilirsiniz. Bkz. ABI'nin HSTRINGile birlikte çalışma.
  • Uyum bozan 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. Aksi takdirde, 'yi eklediğiniz sürece, C++/WinRT üst bilgilerini eklemeden önce unknwn.h, HRESULT'a dönüştürülür.
  • Uyum bozan 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 kullanmanız gerekir. Aksi takdirde, herhangi bir C++/WinRT üst bilgilerini eklemeden önce 'yi dahil ettiğiniz sürece unknwn.h, GUID'ye dönüştürülür. ABI'nin GUID yapısıyla etkileşim için Bkz. .
  • Uyum bozan 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.
  • Uyum bozan değişiklik. WINRT_CanUnloadNow ve WINRT_GetActivationFactory imzaları değişti. Bu işlevleri hiç bildirmemelisiniz. Bunun yerine, bu işlevlerin bildirimlerini eklemek için winrt/base.h (herhangi bir C++/WinRT Windows ad alanı üst bilgi dosyası eklerseniz otomatik olarak eklenir) ekleyin.
  • winrt::clock yapısıiçin from_FILETIME/to_FILETIMEfrom_file_time/to_file_timelehine kullanım dışı bırakılmıştır.
  • Basitleştirilmiş API'ler, IBuffer parametrelerini bekler. Ç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ı bir klasörden bahsettiğinde, belirli bir .winmd'e değil, cppwinrt.exe aracı artık .winmd dosyaları için özyinelemeli arama yapmaz. 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.
  • Güçlendirilmiş 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 bir şekilde işleyemediği bir sorunu ortaya çıkarmada yardımcı oldu; bu sorun winrt::com_ptr yapı şablonu'den kaynaklanıyordu. winrt::com_ptr düzeltildi ve olay iptal edenlerin atama sırasında iptal edebilmeleri için taşıma semantiğini doğru şekilde işleyecek şekilde düzeltildi.

Önemli

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

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

Bu, kodunuz için potansiyel olarak uyumsuzluk yaratabilecek bir değişikliktir.

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.

Projenize Windows başlık dosyalarını ekleme işini daha önce C++/WinRT'ye bıraktıysanız, şimdi bunları kendiniz eklemeniz gerekecek. Her durumda, bağlı olduğunuz başlık dosyalarını açıkça dahil etmek ve bunları sizin için eklemek üzere başka bir kütüphaneye bırakmamak her zaman en iyi yöntemdir.

Şu anda Windows SDK üst bilgi dosyası yalıtımının tek özel durumları iç öğeler 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ışma özelliğini yeniden etkinleştirebilirsiniz. Örneğin, bir COM arabirimi uygulamak isteyebilirsiniz (IUnknown). 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ızın Visual Studio’da dosya ekleme zahmetinden kurtaracak şekilde kopyalayabileceğiniz bölümleri olacaktır.

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

  • GenelWindows SDK Sürümiçin proje özelliğine gidin ve Tüm Yapılandırmalar'ı ve Tüm Platformlar'i seçin. Windows SDK Sürümünü hedeflemek istediğiniz sürüme ayarlayın.
  • Çözüm Gezgini'nde 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ını verirse, #include <unknwn.h>'yi pch.h dosyanızın en üstüne (C++/WinRT üst bilgilerini eklemeden önce) ekleyin."

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

C++ bağlayıcısı "hata LNK2019: çözümlenmemiş dış simge _WINRT_CanUnloadNow@0'ın _VSDesignerCanUnloadNow@0 işlevinde başvurulması" hatasını üretiyorsa, bunu #define _VSDESIGNER_DONT_LOAD_AS_DLL dosyanıza pch.h ekleyerek çözebilirsiniz.

  • Last updated on