/clr Restrizioni

  • Articolo

Si notino le restrizioni seguenti sull'uso di /clr:

  • In un gestore di eccezioni strutturato esistono restrizioni sull'uso _alloca durante la compilazione con /clr. Per ulteriori informazioni, vedere _alloca.

  • L'uso dei controlli degli errori di runtime non è valido con /clr. Per altre informazioni, vedere Procedura: Usare controlli di runtime nativi.

  • Quando /clr viene usato per compilare un programma che usa solo la sintassi C++ standard, le linee guida seguenti si applicano all'uso di assembly inline:

    • L'esecuzione del codice assembly inline che presuppone la conoscenza del layout pila nativo, delle convenzioni di chiamata all'esterno della funzione corrente o di altre informazioni di basso livello sul computer potrebbe non riuscire se tale codice viene applicato allo stack frame di una funzione gestita. Le funzioni contenenti codice assembly inline vengono generate come funzioni non gestite, come se fossero inserite in un modulo separato compilato senza /clr.

    • Il codice dell'assembly inline nelle funzioni che passano i parametri della funzione costruita dalla copia non è supportato.

  • Le vprintf funzioni non possono essere chiamate da un programma compilato con /clr.

  • Il naked__declspec modificatore viene ignorato in /clr.

  • La funzione traduttore impostata da _set_se_translator influirà solo sui catch nel codice non gestito. Per altre informazioni, vedere Gestione delle eccezioni.

  • Il confronto dei puntatori a funzione non è consentito in /clr.

  • L'uso di funzioni non completamente prototipo non è consentito in /clr.

  • Le opzioni del compilatore seguenti non sono supportate con /clr:

  • La combinazione della definizione del _STATIC_CPPLIB preprocessore (/D_STATIC_CPPLIB) e dell'opzione del /clr compilatore non è supportata. Poiché la definizione causerebbe il collegamento dell'applicazione alla libreria standard C++ statica e multithreading, che non è supportata. Per altre informazioni, vedere /MD, /MT/LD (Usare la libreria di runtime).

  • Quando si usa /Zi con /clr, esistono implicazioni per le prestazioni. Per ulteriori informazioni, vedere /Zi.

  • Il passaggio di un carattere wide a una routine di output di .NET Framework senza specificare /Zc:wchar_t o senza eseguire il cast del carattere in _wchar_t causerà la visualizzazione dell'output come unsigned short int. Ad esempio:

    Console::WriteLine(L' ')              // Will output 32.
Console::WriteLine((__wchar_t)L' ')   // Will output a space.

  • /GS viene ignorato durante la compilazione con /clr, a meno che una funzione non sia sotto #pragma unmanaged o se la funzione deve essere compilata come codice nativo, nel qual caso il compilatore genererà l'avviso C4793, che è disattivato per impostazione predefinita.

  • Vedere /ENTRY per i requisiti di firma delle funzioni di un'applicazione gestita.

  • Le applicazioni compilate con /openmp e /clr possono essere eseguite solo in un singolo processo di appdomain. Per altre informazioni, vedere /openmp (Abilitare il supporto openMP 2.0).

  • Le funzioni che accettano un numero variabile di argomenti (varargs) verranno generate come funzioni native. Se nella posizione dell'argomento variabile sono presenti tipi di dati gestiti, ne verrà eseguito il marshalling a tipi nativi. Tutti i System.String tipi sono in realtà stringhe di caratteri wide, ma vengono sottoposto a marshalling in stringhe di caratteri a byte singolo. Pertanto, se un printf identificatore è %S (wchar_t*), eseguirà il marshalling in una %s stringa.

  • Quando si usa la macro, è possibile ottenere risultati imprevisti durante la va_arg compilazione con /clr:pure. Per altre informazioni, vedere va_arg, va_copy, va_end, va_start. Le opzioni del /clr:pure compilatore e /clr:safe sono deprecate in Visual Studio 2015 e non supportate in Visual Studio 2017 e versioni successive. Il codice che deve essere "puro" o "sicuro" deve essere trasferito in C#.

  • Non è consigliabile chiamare funzioni che illustrano lo stack per ottenere informazioni sui parametri (argomenti della funzione) dal codice gestito. Il livello P/Invoke fa sì che le informazioni siano più in basso nello stack. Ad esempio, non compilare proxy/stub con /clr.

  • Le funzioni vengono compilate in codice gestito dove possibile, ma non tutti i costrutti C++ possono essere convertiti in codice gestito. Questa possibilità viene determinata da funzione a funzione. Se una parte di una funzione non può essere convertita in codice gestito, l'intera funzione verrà invece convertita in codice nativo. Il compilatore non è in grado di generare codice gestito nei casi seguenti.

    • Funzioni helper o thunk generati dal compilatore. I thunk nativi vengono generati per qualsiasi chiamata di funzione tramite un puntatore a funzione, incluse le chiamate di funzioni virtuali.

    • Funzioni che chiamano setjmp o longjmp.

    • Funzioni che usano alcune routine intrinseche per modificare direttamente le risorse del computer. Ad esempio, l'uso di __enable e __disable, _ReturnAddress e _AddressOfReturnAddress o di intrinseci multimediali produrrà in tutti i casi codice nativo.

    • Funzioni che seguono la direttiva #pragma unmanaged. L'inverso, #pragma managed, è supportato anche.

    • Una funzione che contiene riferimenti a tipi allineati, ossia tipi dichiarati tramite __declspec(align(...)).

Vedi anche