/CLR restrições
Observe as seguintes restrições no uso de /clr:
Em um manipulador de exceção estruturada, não existem 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 de 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 um assembly de in-line:
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ído 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 será ignorado em /clr.
A função do conversor definido por _ set_se_translator afetará apenas detectando em código não gerenciado. Consulte Exception Handling under /clr 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 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 da _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 causaria o seu aplicativo vincular com estático multithread biblioteca C++ padrão, que não é suportada. Para obter mais informações, consulte o tópico /LD /MD, /MT, (biblioteca Run-Time uso).
/J não é compatível com /clr:safe ou /clr:pure.
Não há suporte para as ATL e MFC bibliotecas de compilação de modo puro (/clr:pure). Você pode usar /clr:pure com a biblioteca C++ padrão e CRT, se você compilar também com /MD ou /MDd.
Ao usar /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 também /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, 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 appdomain. Consulte /OpenMP (Ativar 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 sã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á para uma seqüência de caracteres %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 um 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. Esta determinação é feita de acordo com uma função por 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 impede 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 no 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 Compiler COM Support classes com /clr:pure ou /clr:safe.
Consulte também
Referência
/CLR (common Language Runtime Compilation)
Histórico de alterações
Date |
History |
Motivo |
|---|---|---|
|
Maio de 2010 |
Código compilado com /clr: puro não pode passar um argumento va_list para um parâmetro de número variável de argumentos. |
Comentários do cliente. |