Compartilhar via


/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:

  • 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.

Consulte também

Referência

/CLR (common Language Runtime Compilation)