Técnicas para garantir a compatibilidade entre plataformas (C ++)?

Eu estava terminando um dos meus primeiros projetos em C ++, que é (de acordo com a estrutura) supostamente multiplataforma. Desenvolvi o projeto totalmente no Windows e no Visual Studio, pensando que, como as bibliotecas são todas multiplataforma, fazer a compilação do OSX "mais tarde" seria trivial. Isso acabou não sendo o caso, mas o "código do Windows" não funciona corretamente e teve alguns erros de compilação a serem corrigidos.

Quais técnicas existem para garantir antecipadamente que o código seja compatível com todas as plataformas? Desenvolvendo todas as plataformas simultaneamente, testando o código em todas as plataformas ao mesmo tempo, quando novos recursos são adicionados, em vez de desenvolver as diferentes versões da plataforma uma após a outra? (*)

Procurando aconselhar especificamente que não depende das ferramentas, mas "processos de desenvolvimento" que ajudam na compatibilidade entre plataformas, independentemente de quais ferramentas são usadas. Como o (*) acima.

Especificamente, estou desenvolvendo um plug-in VST com WDL-OL ( https://github.com/olilarkin/wdl-ol ) e algumas bibliotecas DSP de plataforma cruzada. Os projetos WDL-OL têm os projetos VS e Xcode configurados, mas acho que os problemas vêm das bibliotecas e depois das diferenças nos compiladores.

Criar código portátil pode ser muito desafiador.

Primeiro, alguns conselhos óbvios relacionados à linguagem:

• use C ++ padrão e evite cuidadosamente qualquer comportamento indefinido
• confie principalmente na biblioteca padrão (e em bibliotecas portáteis, como boost )
• sempre inclua todos os cabeçalhos esperados. Não presuma que você não precisa de um cabeçalho, pois ele está incluído em outro ( por exemplo, em uma implementação específica !): Isso pode causar erros de compilação
• evitar construções suportadas pelo compilador, mas não garantidas pelo padrão C ++ (por exemplo, estrutura anônima ou matriz de comprimento variável ): pode causar erros de compilação.
• use opções do compilador para ajudá-lo a impor a conformidade (desabilitando extensões específicas do compilador, maximizar o nível de mensagens de aviso retornadas)
• lembre-se de que não é suficiente que o código funcione: existem muitas armadilhas de portabilidade dependentes da implementação: tamanho de tipos de dados (mesmo elementares), caracteres que podem ser assinados ou não assinados por padrão , suposições sobre endianidade , ordem de avaliação nas expressões quando estas use efeitos colaterais , etc.

Em seguida, algumas recomendações de design:

• Prefira a alternativa da biblioteca padrão à funcionalidade equivalente do sistema operacional
• Isole o uso das dependências do sistema operacional o máximo possível (por exemplo, em uma função de wrapper controlada com compilação condicional)

Finalmente os pontos delicados:

• codificação de caracteres: em muitos sistemas, você pode confiar no utf8 . Mas para o Windows é mais delicado, pois o sistema espera ansi ou utf-16. Obviamente, você pode confiar em um typedef (como TCHAR), mas isso pode ser desafiador em combinação com a biblioteca padrão (por exemplo, coutvs wcouta ser usado dependendo se estiver usando charou wchar_t)
• Se, para GUI / gráficos / E / S avançadas, você não consegue encontrar uma biblioteca portátil que atenda às suas expectativas / requisitos, projete a arquitetura geral para isolar componentes específicos do SO. Os invólucros podem não ser suficientes aqui, devido às diversas interações e conceitos envolvidos.
• Tire proveito de alguns padrões de design interessantes, como por exemplo, a fábrica abstrata (ideal para projetar famílias de objetos relacionados, como na interface do usuário específica do SO) ou o mediador (ideal para implementar a colaboração entre famílias de objetos relacionados) e use-os em conjunto com a compilação condicional .

Mas estes são apenas conselhos. Nesta área, você não pode obter certeza.

Não há nada que possa garantir que o código seja compatível com outra plataforma além de construí-lo, executá-lo e testá-lo lá. Portanto, a abordagem de todas as pessoas sãs é criar, executar e testar seus aplicativos em todas as plataformas que eles projetam, que precisam ser construídas, executadas e testadas.

A Integração Contínua (IC) pode aliviar um pouco esse fardo para projetos menores, pois você pode obter agentes de compilação baratos ou gratuitos para algumas plataformas (principalmente Linux), fazer seu desenvolvimento no Windows e simplesmente retornar ao Linux quando houver um problema.

O OSX CI é bastante complicado.

Se você está solicitando "processos de desenvolvimento" e sua plataforma de desenvolvimento principal é o Windows com Visual Studio, sugiro que tente criar seu projeto sem o "windows.h" incluído. Você receberá muitos erros de compilação que apontarão para muitos lugares onde você precisará refatorar seu código. Por exemplo, 'DWORD' não será # definido e será necessário substituí-lo por uint32_ttodos os lugares (google for stdint.he você encontrará informações úteis sobre tipos inteiros e suas definições entre plataformas). Em seguida, você precisará substituir todas as chamadas à API do Win32, como,Sleep()com o equivalente em várias plataformas (novamente, o Google é seu melhor amigo, que mostrará perguntas e respostas relevantes nos sites stack * .com). Provavelmente, você não conseguirá encontrar todas as substituições relevantes de plataforma cruzada para seu código e precisará retornar sua include "windows."diretiva, mas colocá-la em baixo #ifdef _WIN32- mais detalhes aqui

Continue fazendo perguntas mais concretas e obtendo respostas - essa é uma sugestão geral para "o que deve ser o processo de desenvolvimento"

EDIT 1 Outra sugestão é usar gcc e / ou clang na sua máquina de desenvolvimento do Windows (junto com o Visual Studio)

Depende dos "alguns erros de compilação" mencionados. Sem saber o que eram, é impossível ser específico.

Eu tenho código de plataforma cruzada para Windows / Linux / iOS / Android / Mac. Cada nova plataforma trouxe alguns erros e avisos extras quando foi adicionada pela primeira vez. Você aprenderá rapidamente quais construções trazem problemas. Evite-os ou abstraia as diferenças em um cabeçalho com #ifdefs. Tente nunca #ifdefentre plataformas dentro do seu próprio código.

Um exemplo:

void myfunction(MyClass &);
myfunction(MyClass());

cria uma instância temporária da MyClassqual é excluída após o myfunctionretorno. Com alguns dos meus compiladores C ++, essa instância é de leitura / gravação (e o fato de ser temporário e em breve ser destruído não preocupa o compilador). Com outros, myfunctiondeve ser redefinido para obter um const MyClass &, ou o compilador reclama. Não importa o que o padrão C ++ diz, ou qual compilador está certo e qual está errado. Depois de encontrar o erro de um par de vezes Sei de (a) quer declarar uma variável temporária do tipo MyClasse passar que a myfunctionou (b) declarar a referência constem myfunctione usar mutableaqui e ali para deconstify.

Conclusão: acumule experiência e desenvolva seus próprios padrões de codificação.

Uma maneira possível de ajudar a portabilidade seria confiar apenas nas declarações e recursos fornecidos pelo padrão C ++ 11 e usando bibliotecas e estruturas de plataforma cruzada como POCO e Qt .

Mas mesmo isso não é à prova de falhas. Lembre-se do aforismo

não existe um programa portátil, existem apenas programas que foram portados com sucesso (para alguma plataforma específica)

Com prática, disciplina e muita experiência, transferir um programa para outra plataforma geralmente pode ser feito rapidamente. Mas a experiência e o know-how são muito importantes.