15

Ho cercato molto sul Web e StackOverflow, ma non riesco a trovare una risposta definitiva alle mie domande seguenti.Porting di librerie C++ multipiattaforma alla piattaforma Windows Phone 8

Contesto:

Sto cercando di porto un gruppo di C++ librerie di supporto per l'utilizzo con il Phone 8 piattaforma Windows (WP8). Storicamente, queste librerie sono costruite come librerie statiche (piuttosto che come DLL).

Ho scritto con successo il codice specifico per WP8, in modo che le librerie siano compatibili e costruite contro ARM, utilizzando le API disponibili per WP8 (utilizzando il documento QuickStart dell'API WP come punto di riferimento). Solo una delle librerie (ad es. Lib1) richiede il consumo delle estensioni WinRT (il flag/ZW), a causa della necessità di sostituire le classiche chiamate Thread di Win32 con ThreadPool di WinRT.

Durante la creazione di Lib1, viene visualizzato il seguente avviso: Avviso 1 avviso LNK4264: file di archiviazione file compilato con/ZW in una libreria statica; si noti che quando si creano i tipi di Windows Runtime non è consigliabile collegarsi con una libreria statica che contiene metadati di Windows Runtime.

- alla ricerca di questo avvertimento, ho trovato this article, affermando: "Se si consuma una libreria statica che crea classi pubbliche ref, classi di interfaccia pubbliche, o classi valore pubblico, il linker genera questo avviso È possibile ignorare il. avviso se la libreria statica non produce componenti di Runtime di Windows che vengono utilizzati al di fuori della libreria stessa.I componenti pubblici in una libreria statica verranno compilati ma non verranno attivati ​​in fase di esecuzione.Tutti i componenti di Windows Runtime destinati al consumo da altri componenti o app devono essere implementato in una libreria a collegamento dinamico (DLL). "

In Lib1, ClassA contiene le funzioni che utilizzano chiamate WinRT ThreadPool. Le funzioni ClassA sono chiamate da ClassB e restituiscono semplicemente HANDLE e DWORD regolari a ClassB.

esempio di codice:

// ClassA.cpp 
HANDLE WINAPI ClassA::CreateThread(/* Params that are usually passed to Win32 CreateThread */) 
{ 
    // Do WinRTThreadPool stuff to create WorkItem 
    auto workItem = ref new Windows::System::Threading::WorkItemHandler([=](Windows::Foundation::IAsyncAction^) 
    // More code that eventually results in a Win32 Handle 

    return handle; 
} 

// ClassB.cpp 
Handle handle = ClassA::CreateThread(/* Params that are usually passed to Win32 CreateThread */); 

funzioni di ClassA potrà mai essere chiamati solo da ClassB, dall'interno Lib1, e ClassB possono quindi essere utilizzati dall'applicazione che collega Lib1.

Infine, alle mie domande:

  1. Può il C++ librerie che facciamo non consumano estensioni WinRT (/ ZW), quando costruito come librerie statiche, essere utilizzato da Windows Phone 8 applicazioni ?

  2. Può la libreria C++ (Lib1) che fa consumare estensioni WinRT (/ ZW), quando costruito come un lib statica, essere utilizzato da Phone 8 applicazioni Windows, nonostante l'avvertimento?

  3. Se la risposta è no a entrambe le domande, dovrò creare WinRT involucri componenti per tutte le classi nella rispettiva biblioteca, come this article dimostra con l'algoritmo di Mandelbrot? O c'è qualcos'altro che mi manca?

Grazie in anticipo per qualsiasi input è possibile fornire.

risposta

5

Domanda 1 Sì, a patto che non si sta usando qualsiasi API che non sono consentiti al telefono, ad esempio Win32, MFC, ecc Alcune delle caratteristiche standard c avere alcuni vincoli che li circonda; ad esempio, puoi chiamare fopen solo sui file che si trovano nell'area locale delle tue applicazioni. Naturalmente, puoi accedere alla funzionalità solo nella tua lib statica dal codice C++. Questo scenario è quello che mi piace definire lo scenario "Plain Old C++". Funziona bene.

Domanda 2 Sì, a patto che tutte le classi ref che si definiscono nel lib statiche sono destinati solo per essere utilizzato all'interno di quella lib statica. Quindi nel tuo esempio, finché la Classe A è una normale classe C++, starai bene. In sostanza, non è possibile avere classi di riferimento pubbliche nello stesso senso delle public class in un assembly .NET, poiché ciò richiede alcune funzioni COM-on-steroidi e queste vengono solo compilate in Componenti di Windows Runtime. Se hai un semplice codice C++ che avvolge le tue chiamate a qualsiasi codice di classe ref, e il codice che consuma la tua memoria statica lo consuma in un modo C++ semplice, allora stai bene. La logica suggerisce che non sarete in grado di passare i tipi WinRT dalla lib statica, anche se non ho ancora provato questa ipotesi.

Domanda 3 Credo che l'articolo che si fa riferimento al fatto che manca il codice in un lib statica può accedere alle classi ref ecc, quindi non preoccupatevi, non c'è bisogno di scrivere wrapper di Windows Runtime Component intorno al vostro librerie statiche. Lo vuoi fare solo se vuoi che il codice della tua libreria statica sia disponibile tramite "Public Classes" (nel senso dell'assembly .NET).

La cosa da ricordare è che si sta ancora costruendo una libreria statica "per l'archivio di Windows". È un codice nativo, ma può ancora fare tutto ciò che è C++/CX, semplicemente non include le cose di attivazione COM per consentire ai tipi definiti all'interno di esso di essere accessibili al di fuori dello scenario C++ collegato staticamente.