Quais são minhas opções para usar uma biblioteca C ++ 11 em um aplicativo C # WPF? [fechadas]

5

Estou escrevendo um aplicativo de área de trabalho de plataforma cruzada (OS X e Windows) no C ++ 11. Eu pretendo usar o mesmo núcleo C ++ 11 em ambas as plataformas, utilizando estruturas nativas para a interface do usuário (Cocoa e Objective-C no OS X e WPF e C # no Windows), pois acredito que a melhor experiência de UX é nativa. / p>

Atualmente, o aplicativo é executado como um aplicativo de console em ambas as plataformas. O aplicativo executa algum trabalho intensivo da CPU e fornece retornos de chamada para o relatório de andamento e, quando concluído, instancia uma coleção de Itens ( std::vector<std::unique_ptr<Item>> ) representando os resultados do processamento.

Meu objetivo é que a biblioteca C ++ 11 atue como um modelo para a interface do usuário de uma maneira compatível com os padrões MVC e MVVM.

A interface do usuário deve:

  • Permitir que o usuário escolha um arquivo para processar (abra uma caixa de diálogo de arquivo e envie o caminho do arquivo para a biblioteca C ++)
  • Exibir progresso (manipular retornos de chamada da biblioteca C ++ para atualizar uma barra de progresso)
  • Exibir os resultados em um formulário do WPF (acessar a classe Item e exibir as informações fornecidas)

Eu olhei para o WinRT e parece que não há muitas informações disponíveis para uso em aplicativos de desktop. Eu também não gosto da idéia de criar a própria UI em C ++. Meu objetivo é obter dados dentro e fora do aplicativo C ++ e usar o C # para lidar com a interface do usuário, pois acredito que seja uma maneira mais eficiente de trabalhar com o WPF.

Estou ciente do P / Invoke, mas, no meu entender, ele só funciona com uma interface C. Criar tal interface em torno do C ++ 11 parece complicado.

Também estou ciente do C ++ / CLI, mas não tenho certeza se isso atenderá às minhas necessidades ou se é compatível com o C ++ 11.

Eu dei uma olhada no CppSharp mas parece ser um trabalho em andamento e duvido que eu saiba para contornar quaisquer problemas que possam surgir.

Eu tenho muita experiência com C ++ e um pouco com C #, mas não tenho certeza se estou perdendo melhores opções ou qual das opções acima é uma boa abordagem.

    
por Rotsiser Mho 16.02.2014 / 19:44
fonte

3 respostas

2

SWIG pode gerar C # wrappers para código C ++. Eu não tenho experiência em usá-lo para isso, então não sei o quão bem funciona.

Acredito que o lançamento atual do SWIG (versão 2.x) tenha pelo menos algum suporte ao C ++ 11, mas você pode precisar usar o versão de desenvolvimento para suporte completo.

    
por 17.02.2014 / 14:34
fonte
1

Parte de uma resposta ...

Na maioria das vezes, na solução para este problema, você terminará com 3 camadas.

  1. Uma camada C / C ++ nativa, que pode chamar a API do Windows ou as bibliotecas COM ou C ++
  2. Uma camada C / C ++ gerenciada, que pode acessar o modelo de objeto e a estrutura do C #
  3. Uma camada C #, porque é mais fácil usar o .NET Framework e o WPF em C #.

P / Invoke refere-se às chamadas entre código nativo e gerenciado, mas nesse tipo de estrutura elas acontecem dentro da camada (2). Camada (2) costumava ser gerenciado C ++, mas agora é substituído por C ++ / CLI. Cada uma das camadas pode falar facilmente com a próxima, mas (1) não fala facilmente com (3) ou vice-versa.

Você pode encontrar um produto que faça exatamente o que você quer, mas eu não conheço um. É mais provável que você tenha que escrever o que precisa com esse tipo de estrutura em camadas.

Eu fiz isso mais de 3 vezes com mais de 3 gerações diferentes de Managed C / C ++ e temos um produto comercial criado dessa forma (legacy C / C ++ < = > ASP.NET / remoting). Cada geração da camada gerenciada é diferente, mas a estrutura geral permanece a mesma. [editar]

Sugiro: escreva algum código, mas planeje jogá-lo fora. A experimentação está em ordem.

    
por 17.02.2014 / 15:03
fonte
0

O que é uma interface do usuário nativa no Windows mais? O WPF não parece 'padrão', winforms e MFC estão mortos, como o Silverlight. Pode-se dizer que o mais nativo dos aplicativos agora é HTML, especialmente se você estiver gravando blocos do Windows 8.

Então minha sugestão seria usar wxWidgets que usa controles nativos para renderizar. Sua interface do usuário será parecida com um programa tradicional do Windows, em vez de um programa "moderno", mas é isso que você queria depois, não é?

Se você ainda precisar usar o WPF para a GUI, poderá gravar um wrapper de interface C ++ / CLI que chama seu C ++ dll ou poderá expor sua dll como um serviço e deixar o WPF fazer o soquete (ou outro RPC) chama para isso. Se for muito falador, esta não seria a melhor solução, mas se fizer poucas chamadas de longa duração, então é o ideal. Um serviço também seria a melhor solução para vincular um front-end da Web à sua dll também, embora eu exponha o serviço como uma WWS web service neste caso.

    
por 18.02.2014 / 09:49
fonte