/CLR restrições
Observe as seguintes restrições no uso de /clr:
Em um manipulador de exceção estruturada, há restrições sobre o uso de _alloca durante a compilaçã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 Erro de tempo de execução verifica.
Quando /clr é usado para compilar um programa que usa somente a sintaxe do C++ padrão, as diretrizes a seguir se aplicam ao uso de assembly embutido:
Código de assembly embutido que pressupõe o conhecimento do layout pilha nativa, convenções fora da função atual ou outras informações sobre o computador de baixo nível de chamada pode falhar se conhecimento aplicado ao quadro de pilha para uma função gerenciada.Funções que contém o código de assembly embutido são geradas como funções não gerenciadas, como se eles foram colocados em um módulo separado que foi compilado sem /clr.
Não há suporte para o código de assembly embutido em funções que passar parâmetros de função construída de cópia.
O funções de vprintf não pode ser chamado a partir de um programa compilado com /clr.
O nua__declspec modificador é ignorado em /clr.
A função do conversor definido por _ set_se_translator afetará apenas detectando em código não gerenciado.Consulte Tratamento de Exceção (Extensões de Componentes C++) para obter mais informações.
A comparação dos ponteiros de função não é permitida em /clr.
O uso de funções que não são totalmente com protótipo não é permitido em /clr.
As opções do compilador não são compatíveis com /clr:
/EHscand /EHs (/clr implies /EHa (see /EH (modelo de manipulação de exceção))
/fp:strictand /fp:except (see /FP (Especifica o comportamento de ponto flutuante))
/ZI
A combinação entre a _STATIC_CPPLIB definição de pré-processador (/D_STATIC_CPPLIB) e o /clr ou /clr:pure não há suporte para a opção de compilador.Isso acontece porque a definição faria com que seu aplicativo vincular com estático multithread biblioteca C++ padrão, que não é suportada.Para obter mais informações, consulte o tópico / MD, /MT, /LD (biblioteca de tempo de execução de uso).
/J não é compatível com /clr:safe ou /clr:pure.
Não há suporte para as bibliotecas do ATL e MFC compilação de modo puro (/clr:pure).Você pode usar /clr:pure com a biblioteca C++ padrão e a CRT, se você compilar também com /MD ou /MDd.
Ao usar o /Zi com /clr, há implicações de desempenho.Para obter mais informações, consulte /Zi.
Passando um caractere largo para um.NET Framework a rotina de saída sem especificar /Zc:wchar_t ou sem o caractere para a projeção __wchar_t fará com que a saída apareça como um unsigned short int.Por exemplo:
Console::WriteLine(L' ') // Will output 32. Console::WriteLine((__wchar_t)L' ') // Will output a space./GS é ignorada durante a compilação com /clr, a menos que uma função está em #pragma não gerenciado ou se a função deve ser compilada para o nativo, caso em que o compilador gerará aviso C4793, o que está desativado por padrão.
Consulte /ENTRY para requisitos de assinatura de função de um aplicativo gerenciado.
Aplicativos compilados com /openmp e /clr só pode ser executado em um processo único de appdomain.Consulte /OpenMP (Habilitar OpenMP 2.0 suporte) para obter mais informações.
Funções que levam a um número variável de argumentos (varargs) serão geradas como funções nativas.Quaisquer tipos de dados gerenciado na posição de argumento variável serão empacotados para tipos nativos.Observe que System.String tipos estão realmente-seqüências de caracteres, mas eles são empacotados para seqüências de caracteres de byte único.Portanto, se um especificador de printf é %s (wchar_t *), ele controlará a uma seqüência de %s em vez disso.
Ao usar a macro va_arg, você pode obter resultados inesperados durante a compilação com /clr:pure.Para obter mais informações, consulte va_arg, va_end, va_start.
Se seu aplicativo passa um argumento do tipo va_list para uma função declarada para tirar uma número variável de argumentos, e seu aplicativo é compilado com /clr:pure, o CLR lança NotSupportedException.Se /clr é usado em vez disso, as funções afetadas são compiladas para código nativo e executado adequadamente.Se /clr:safe é usado, um erro de diagnóstico é emitido.
Você não deve chamar, do código gerenciado, todas as funções que movimentar a pilha para obter informações de parâmetros (argumentos de função); a camada de P/Invoke faz com que essas informações a serem mais para baixo na pilha.Por exemplo, não compilar proxy/stub com /clr.
Funções serão compiladas para código gerenciado sempre que possível, mas nem todas as construções de C++ podem ser traduzidas para código gerenciado.Essa determinação é feita em uma base por função-função.Se qualquer parte de uma função não pode ser convertido em código gerenciado, a função inteira será convertida em vez disso, para código nativo.Casos a seguir impedem que o compilador gera código gerenciado.
Thunks gerado pelo compilador ou funções auxiliares.Thunks nativas são geradas para qualquer chamada de função através de um ponteiro de função, incluindo as chamadas de função virtual.
Funções chamada setjmp ou longjmp.
Funções que usam determinadas rotinas intrínsecas para manipular diretamente os recursos da máquina.Por exemplo, o uso de __enable e __disable, _ReturnAddress e _AddressOfReturnAddress, ou intrínsecos multimídia serão todos os resultados em código nativo.
Funções que se sigam o #pragma unmanaged diretiva.(Observe que o inverso, #pragma managed, também é suportado.)
Uma função que contém referências a alinhados tipos, ou seja, tipos declarados usando __declspec(align(...)).
Não é possível usar o Compilador COM suporte classes com /clr:pure ou /clr:safe.