Chamar código não gerenciado de processo gerenciado ou desova

votos
0

Eu tenho um exe não gerenciado C ++ que eu poderia chamar de dentro de meu código C # diretamente (tem o código C ++ que eu poderia fazer uma lib) ou via disparando um processo e agarrando os dados do OutputStream. Quais são as vantagens / desvantagens das opções?

Publicado 19/05/2009 em 21:12
fonte usuário
Em outras línguas...                            


5 respostas

votos
1

Desde que você tem o código-fonte da biblioteca C ++, você pode usar C ++ / CLI para compilá-lo em uma DLL de modo misto por isso é fácil de ser utilizado pela aplicação C #.

O benefício desta será mais flexível sobre o fluxo de dados (de entrada ou de saída para que o módulo C ++).

Durante a execução do código C ++ fora do processo tem um benefício. Se o seu código C ++ não é muito robusto, isso pode fazer a sua principal processo C # estável de modo a não ser caiu pelo código C ++.

Respondeu 24/05/2009 em 15:45
fonte usuário

votos
0

A principal desvantagem de estar em processo seria certificando-se de lidar com as interações nativas gerenciados / corretamente.

1)

O código c ++ provavelmente vai depender de destruição determinista para limpeza / recurso liberando etc. Digo provavelmente porque isso é comum e boas práticas no c ++.

No código gerenciado isso significa que você tem que ter cuidado se desfazer do seu c ++ cli código invólucro corretamente. Se o seu código é utilizado uma vez, a usar cláusula no c # vai fazer isso por você. Se o objeto precisa para viver um tempo como um membro, você verá que o descarte deverá ser encadeado todo o caminho através de sua aplicação.

2)

Outra questão depende de como a memória com fome sua aplicação é. O coletor de lixo gerenciado pode ser preguiçoso. É garantido para chutar, se uma alocação conseguiu precisa de mais espaço do que está disponível. No entanto, o alocador não gerenciado não está ligado de qualquer maneira. Portanto, você precisa informar manaully o alocador gerenciado que você estará fazendo alocações não gerenciados e que deve manter esse espaço disponível. Isso é feito usando o método AddMemoryPressure.

As principais desvantagens de estar fora do processo são:

1) Velocidade.

2) sobrecarga código para gerenciar a comunicação.

3) sobrecarga Código de prestar atenção para um ou outro moribundo processo quando ele não é esperado para.

Respondeu 09/09/2009 em 14:43
fonte usuário

votos
0

Você é muito melhor tomar um subconjunto das funções do C ++ executável e construí-lo em uma biblioteca. Você vai manter a segurança de tipos e você vai ser capaz de melhor manuseio alavancagem Exception (para não mencionar o controle de grão mais fino de como você gerencia as chamadas para as funções na biblioteca).

Se você vai com agarrando os dados do OutputStream do executável, você vai ter nenhuma visibilidade sobre os processos do executável, nenhum tratamento de exceção real, e você vai perder qualquer informação de tipo que possa ter tido.

Respondeu 19/05/2009 em 21:24
fonte usuário

votos
0

Outra desvantagem de um processo de desova é que em janelas spwaning um processo é uma operação muito cara (lenta). Se você pretende chamar o código C ++ muitas vezes isso vale a pena considerar. Uma vantagem pode ser que você está automaticamente mais isolada a falhas no programa c ++. Queda na substituição do executável c ++ pode ser uma vantagem também. Além disso escrevendo código de interoperabilidade pode ser grande confusão no c #. Se é um interace complicado e você decidir fazer interoperabilidade, ter um olhar para c ++ / CLI para a camada de interoperabilidade.

Respondeu 19/05/2009 em 21:24
fonte usuário

votos
0

A grande desvantagem para raspar o OutputStream é a falta de digitação de dados. Eu prefiro fazer o trabalho de exportação de algumas funções e reutilização de uma biblioteca existente; mas, isso é realmente apenas uma preferência.

Respondeu 19/05/2009 em 21:20
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more