Estou desenvolvendo executáveis de interface de linha de comando para osx e linux usando c / c ++. O projeto será vinculado ao opencv. Devo usar libc ++ ou libstdc ++?
Eu usaria a biblioteca nativa para cada sistema operacional, ou seja, libstdc ++ no GNU / Linux e libc ++ no Mac OS X.
libc ++ não é 100% completo no GNU / Linux, e não há nenhuma vantagem real em usá-lo quando o libstdc ++ é mais completo. Além disso, se você deseja vincular a quaisquer outras bibliotecas escritas em C ++, é quase certo que elas tenham sido construídas com libstdc ++, portanto, você também precisará vincular a ela para usá-las.
Mais informações aqui sobre a integridade da libc ++ em várias plataformas.
Você poderia elaborar / fornecer links sobre o status de integridade de libc ++ no Linux? Não entendo muito bem por que isso seria específico da plataforma, já que libc ++ é apenas um monte de cabeçalhos de biblioteca padrão. Ou você quer dizer que é necessário construir o Clang wrt para bibliotecas de tempo de execução LLVM que não são bem suportadas no Linux?
TemplateRex
1
@TemplateRex, não sei o status atual, você pode procurar em libcxx.llvm.org . Eu não sigo a libc ++, então você está perguntando à pessoa errada, mas está sugerindo que "um monte de cabeçalhos da Biblioteca Padrão" nunca terá nenhum código específico de plataforma?
Jonathan Wakely
Bem, uma vez que você pode instalar o Linux praticamente no mesmo hardware da Apple que está executando o Mac OS X, eu me pergunto de onde viria a dependência de plataforma nos cabeçalhos C ++? Talvez alguns wrappers em torno de intrínsecos de CPU embutidos ou IO e coisas de tratamento de exceções sejam dependentes do sistema, mas meu entendimento é que essas coisas são tratadas no tipo librcxxrt de camadas binárias. Os cabeçalhos da Biblioteca Padrão não deveriam ser mais ou menos plugáveis?
TemplateRex
4
Não estou falando de hardware. Novamente, eu não tenho ideia sobre libc ++, mas a maioria das bibliotecas padrão C ++ são implementadas sobre a biblioteca C do sistema operacional e, por exemplo, o mapeamento de std::ctype_base::maskvalores para <ctype.h>constantes é totalmente dependente da plataforma. (Os intrínsecos da CPU são fornecidos pelo compilador, o tratamento de exceções é feito por uma camada ABI de baixo nível, mas o IO normalmente é feito inteiramente nas bibliotecas C ++ e C, não em coisas de baixo nível).
Jonathan Wakely
1
@abergmeier, esse é um argumento falso, porque (quando usado com o GCC ou outros processos de compilação elegíveis) libstdc ++ não impõe nenhuma restrição ao código que o usa, seja vinculado dinamicamente ou estaticamente. Não é o LGPL. Por favor, não espalhe FUD. gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.license.what
Jonathan Wakely
30
As principais distribuições do Linux não fornecem LLVM libc ++ porque:
Ao contrário da Apple e do FreeBSD, a GPL + 3 não é um problema, portanto, não há necessidade de implementar outra pilha aqui.
Os componentes do Linux foram desenvolvidos em torno do GNU libstd ++ por muito tempo. Alguns deles não se baseiam em mais nada.
Embora libc ++ seja forte em novos recursos, tem alguns problemas com o código legado.
Se eventualmente libc ++ se tornar parte das distribuições, será como um componente opcional. vincular a ele provavelmente exigirá opções extras.
Como Jonathan disse, você deve usar qualquer ferramenta incluída por padrão. O Clang é seguro para uso no Linux, pois está configurado como um substituto do GCC, portanto, nesse aspecto, você não precisa se preocupar com 2 compiladores. Além disso, como seu objetivo é duas plataformas, você deve dar uma olhada no cmake.
O Clang não é um substituto do GCC ... Apenas outro compilador.
Isaac Pascual
4
@IsaacPascual O que Mario quis dizer com clang oficialmente tem em seus objetivos de design ser um substituto para o compilador proeminente na plataforma em que você o executa (por exemplo, gcc quando executado no Linux). O mesmo vale para o afaik do compilador da Intel. É a sua maneira de obter uma adoção mais ampla.
Johan Boulé
-3
diz-se que a libc ++ tem mais mensagens de erro legíveis por humanos em erros de modelo.
Tem certeza de que não está confundindo alegações de melhores diagnósticos com clang do que gcc? O que nem sempre é verdade hoje em dia e é completamente separado da implementação da biblioteca padrão que está sendo usada. Se você tiver algum exemplo em que as mensagens são melhores do que boatos, relate os bugs em gcc.gnu.org/bugs
Respostas:
Eu usaria a biblioteca nativa para cada sistema operacional, ou seja, libstdc ++ no GNU / Linux e libc ++ no Mac OS X.
libc ++ não é 100% completo no GNU / Linux, e não há nenhuma vantagem real em usá-lo quando o libstdc ++ é mais completo. Além disso, se você deseja vincular a quaisquer outras bibliotecas escritas em C ++, é quase certo que elas tenham sido construídas com libstdc ++, portanto, você também precisará vincular a ela para usá-las.
Mais informações aqui sobre a integridade da libc ++ em várias plataformas.
fonte
std::ctype_base::maskvalores para<ctype.h>constantes é totalmente dependente da plataforma. (Os intrínsecos da CPU são fornecidos pelo compilador, o tratamento de exceções é feito por uma camada ABI de baixo nível, mas o IO normalmente é feito inteiramente nas bibliotecas C ++ e C, não em coisas de baixo nível).As principais distribuições do Linux não fornecem LLVM libc ++ porque:
Se eventualmente libc ++ se tornar parte das distribuições, será como um componente opcional. vincular a ele provavelmente exigirá opções extras.
Como Jonathan disse, você deve usar qualquer ferramenta incluída por padrão. O Clang é seguro para uso no Linux, pois está configurado como um substituto do GCC, portanto, nesse aspecto, você não precisa se preocupar com 2 compiladores. Além disso, como seu objetivo é duas plataformas, você deve dar uma olhada no cmake.
fonte
diz-se que a libc ++ tem mais mensagens de erro legíveis por humanos em erros de modelo.
fonte