/clr Restrições

  • Artigo
  • 4 minutos para o fim da leitura

Observe as seguintes restrições sobre o uso de /clr :

  • Em um manipulador de exceção estruturado, há restrições no uso _alloca do ao compilar 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 como: usar verificações nativas em tempo de execução.

  • Quando /clr é usado para compilar um programa que usa apenas a sintaxe C++ padrão, as diretrizes a seguir se aplicam ao uso de assembly embutido:

    • O código de assembly embutido que pressupõe conhecimento sobre o layout empilhado nativo, as convenções de chamada fora da função atual ou outras informações de nível inferior sobre o computador poderá falhar se esse conhecimento for aplicado ao registro de ativação de uma função gerenciada. Funções que contêm código de assembly embutido são geradas como funções não gerenciadas, como se elas fossem colocadas 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 passam parâmetros de função de cópia criada.

  • As vprintf funções não podem ser chamadas de um programa compilado com /clr .

  • O naked__declspec modificador é ignorado em /clr .

  • A função tradutor definida pelo _set_se_translator afetará apenas as capturas no código não gerenciado. Para obter mais informações, consulte tratamento de exceção.

  • A comparação de ponteiros de função não é permitida em /clr .

  • O uso de funções que não são totalmente modeladas não é permitido em /clr .

  • As seguintes opções de compilador não têm suporte com /clr :

  • Não há suporte para a combinação da definição de _STATIC_CPPLIB pré-processador ( /D_STATIC_CPPLIB ) e da opção de /clr compilador. É porque a definição faria com que seu aplicativo fosse vinculado com a biblioteca padrão de C++ multithread estática, que não tem suporte. Para obter mais informações, consulte /MD , /LD/MT (use Run-Time Library).

  • Quando você usa /Zi o com o, há implicações de /clr desempenho. Para obter mais informações, consulte /Zi.

  • passar um caractere largo para uma rotina de .NET Framework saída sem especificar /Zc:wchar_t ou sem converter o caractere para _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 é ignorado durante a compilação com /clr , a menos que uma função esteja sob #pragma unmanaged ou se a função precisar ser compilada como código nativo; nesse caso, o compilador irá gerar o Aviso C4793, que está desativado por padrão.

  • Consulte /ENTRY para obter os requisitos de assinatura de função de um aplicativo gerenciado.

  • Aplicativos compilados com /openmp e /clr só podem ser executados em um único processo AppDomain. Para obter mais informações, consulte /openmp (habilitar suporte a OpenMP 2,0).

  • As funções que usam um número variável de argumentos (varargs) serão geradas como funções nativas. Será realizado o marshaling dos tipos de dados gerenciados na posição de argumento variável para tipos nativos. Todos os System.String tipos são, na verdade, cadeias de caracteres largos, mas são empacotados para cadeias de caracteres de byte único. Portanto, se um printf especificador for %S ( wchar_t* ), ele realizará marshaling em uma %s cadeia de caracteres em vez disso.

  • Ao usar a va_arg macro, você pode obter resultados inesperados ao compilar com /clr:pure . Para obter mais informações, consulte va_arg , va_endva_copy ,, va_start. as opções de /clr:pure compilador e /clr:safe são preteridas no Visual Studio 2015 e sem suporte no Visual Studio 2017 e posterior. O código que precisa ser "puro" ou "seguro" deve ser portado para o C#.

  • Você não deve chamar nenhuma função que Oriente a pilha para obter informações de parâmetro (argumentos de função) do código gerenciado. A camada P/Invoke faz com que essas informações estejam mais abaixo da pilha. Por exemplo, não compile proxy/stub com /clr .

  • As funções serão compiladas em código gerenciado sempre que possível, mas nem todos os constructos C++ podem ser convertidos em código gerenciado. Essa determinação é feita por função. Se qualquer parte de uma função não puder ser convertida em código gerenciado, a função inteira será convertida em código nativo. Os casos a seguir impedem o compilador de gerar um código gerenciado.

    • Conversões geradas pelo compilador ou funções auxiliares. Conversões nativas são geradas para qualquer chamada de função por meio de um ponteiro de função, incluindo chamadas de função virtual.

    • Funções que chamam setjmp ou longjmp.

    • Funções que usam algumas rotinas intrínsecas para manipular diretamente os recursos do computador. Por exemplo, o uso de __enable e __disable, _ReturnAddress e _AddressOfReturnAddress ou todos os intrínsecos de multimídia resultarão em código nativo.

    • Funções que seguem a diretiva #pragma unmanaged. (O inverso, #pragma managed , também tem suporte.)

    • Uma função que contém referências a tipos alinhados, ou seja, tipos declarados usando __declspec(align(...)).

Consulte também