/clr Restrições
Observe as seguintes limitações no uso de /clr:
Em um manipulador estruturado de exceção, há limitações no uso _alloca durante a criação com /clr. Para obter mais informações, consulte _alloca.
O uso de verificações de erro em tempo de execução não é válido com /clr. Para obter mais informações, consulte Verificações de erro em tempo de execução.
Quando /clr é usado para criar um programa que usa somente a sintaxe padrão do C++, as diretrizes a seguir se aplicam ao uso do assembly embutida:
O código em linha do assembly que assume o conhecimento de layout nativo da pilha, chamando convenções da função atual, ou outras informações de baixo nível sobre o computador pode falhar se esse conhecimento é aplicado ao quadro de pilhas para uma função gerenciada. As funções que contêm código embutida do assembly são geradas como funções não gerenciado, como se foram colocadas em um módulo separado que é compilado sem /clr.
Embutido código do assembly em funções que os parâmetros cópia de passagem da função não têm suporte.
funções de vprintf não pode ser chamado de um programa compilado com /clr.
O modificador de despido__declspec é ignorado em /clr.
O conjunto da função de tradutor por _set_se_translator afetará apenas captura em código não gerenciado. Consulte Em /clr de manipulação de exceção para maiores informações.
A comparação de ponteiros da função não é permitida em /clr.
O uso de funções que não são completamente protótipos não é permitido em /clr.
As seguintes opções do compilador não têm suporte em /clr:
/EHsc e /EHs (/clr implica /EHa (consulte /EH (modelo de tratamento de exceções))
/fp:strict e /fp:except (consulte /fp (especificar comportamento de ponto flutuante))
/ZI
A combinação da definição de pré-processador de _STATIC_CPPLIB (/D_STATIC_CPPLIB) e a opção do compilador de /clr ou de /clr:pure não tem suporte. Isso é bem como a definição faz com que o aplicativo vincular com a biblioteca multi-threaded estático padrão do C++, que não tem suporte. Para obter mais informações, consulte o tópico /MD, /MT, /LD (usar biblioteca em tempo de execução).
/J não tem suporte com /clr:safe ou /clr:pure.
As bibliotecas de ATL e de MFC não são suportadas pela compilação pura de modo**/clr:pure**(). Você pode usar /clr:pure com a biblioteca padrão do C++ e o CRT se você também cria com /MD ou /MDd.
Ao usar /Zi com /clr, as implicações de desempenho. Para obter mais informações, consulte /Zi.
Passe um caractere largo para uma rotina de saída do .NET Framework sem especificação /Zc: wchar_t ou sem converter a cadeia de caracteres a __wchar_t fará com que a saída aparecem como unsigned short int. Por exemplo:
Console::WriteLine(L' ') // Will output 32. Console::WriteLine((__wchar_t)L' ') // Will output a space./GS será ignorado durante a criação com /clr, a menos que uma função está em #pragma não gerenciado ou se a função deverá ser criada ao nativo, caso o compilador gerará C4793 de aviso, que é desativada por padrão.
Consulte para /ENTRY requisitos de assinatura da função de um aplicativo gerenciado.
Os aplicativos criados com /openmp e /clr só podem ser executados em um único processo de appdomain. Consulte /openmp (habilitar suporte a OpenMP 2.0) para maiores informações.
As funções que usam um número variável de argumentos (varargs) serão geradas como funções nativos. Todos os dados gerenciados na posição variável de marshaling argumento para tipos nativos. Observe que os tipos de String são realmente cadeias de caracteres de ampla marshaling de caracteres, mas em cadeias de caracteres de um byte. Isso se um especificador de printf é wchar_t* (%S), marshaling para uma cadeia de caracteres de %s em vez disso.
Ao usar a macro de va_arg, você pode obter resultados inesperados ao criar com /clr:pure. Para obter mais informações, consulte va_arg, va_copy, va_end, va_start.
Se seu aplicativo passa um argumento de tipo va_list a uma função declarada para fazer número variável de argumentos, e seu aplicativo for compilado com /clr:pureCLR, gerencie NotSupportedException. Se /clr é usado por outro lado, as funções afetadas são criadas em código nativo e sejam executadas corretamente. Se /clr:safe for usado, o diagnóstico de erro é emitido.
Você não deve chamar, o código gerenciado, qualquer função que mostram a pilha para obter informações de parâmetro (argumentos de função); as causas da camada de P/Invoke essas informações ser listados mais adicional a pilha. Por exemplo, não crie o proxy/stub com /clr.
As funções serão criadas ao código gerenciado construções sempre que possível, mas não todas as C++ podem ser traduzidas para código gerenciado. A determinação é feita em uma base de função-por- função. Se qualquer parte de uma função não pode ser convertida no código gerenciado, a função inteira será convertida em código nativo em vez disso. Os seguintes casos impedir que o compilador gerencia o código gerenciado.
Thunks completo gerados ou funções auxiliares. Os thunks nativos são gerados para qualquer chamada de função por meio de um ponteiro de função, incluindo chamadas de função virtuais.
Funções que chamam setjmp ou longjmp.
Funções que usam determinadas rotinas intrínsecas para manipular diretamente recursos do computador. Por exemplo, o uso de __enable e __disable, _ReturnAddress e _AddressOfReturnAddress, ou intrinsics de multimédios qualquer resultado em código nativo.
Funções que seguem a política de #pragma unmanaged . (Observe que o inverso, #pragma managed, também há suporte.)
Uma função que contém referências aos tipos alinhados, ou seja, digite declarado usando __declspec(align(...)).
Você não pode usar as classes de Suporte COM do compilador com /clr:pure ou /clr:safe.