Por que ' t mais aplicativos de desktop escritos com Qt? [fechado]

Não pretendo que seja uma resposta contundente, mas essas são as razões pelas quais faço não uso pessoalmente Qt. Há muitas coisas boas a dizer sobre isso – a saber, que a API funciona na maior parte do tempo e faz a ponte entre plataformas perfeitamente. Mas eu não uso Qt porque:

1. Em alguns casos, simplesmente não se parece com a aparência de programas nativos. Projetar uma única IU para todas as plataformas inerentemente não vai parecer certo quando movido de máquina para máquina, por vários motivos de estilo visual. Por exemplo, em máquinas Mac, as barras de divisão são geralmente relativamente grossas e os botões são pequenos e arredondados com ícones. Em máquinas Windows, as barras de divisão são geralmente estreitas e os botões são mais textuais, com designs mais quadrados. Só porque você pode escrever uma IU para cada plataforma, não significa que deva fazer isso para a maioria dos aplicativos.
2. Qt não é apenas um conjunto de bibliotecas C ++ habilitado para link. O sistema de construção que está sendo usado requer a tradução de certos arquivos em arquivos de origem extras, o que torna o processo de construção muito mais complicado quando comparado com a maioria das outras bibliotecas.
3. Como resultado de (2), IDEs e ferramentas C ++ pode sinalizar expressões Qt como erros, porque eles não entendem as especificações do Qt “. Isso quase força o uso do QtCreator ou de um editor apenas textual como o vim.
4. Qt é uma grande quantidade de código-fonte, que deve estar presente e pré-instalado em qualquer máquina que você usar antes de compilar. Isso pode tornar a configuração de um ambiente de construção muito mais tediosa.
5. As peças são principalmente licenciadas sob a LGPL, o que torna é difícil usar a implantação de binário único quando é necessário lançar sob uma licença mais restritiva ou menos restritiva.
6. Ele produz binários compilados extremamente grandes quando comparados com " plain ol “aplicativos nativos " (exceto, é claro, os aplicativos escritos dez para KDE).

Comentários

• @Dehumanizer: há ' s o Licença LGPL e ' a licença comercial. A licença comercial custa milhares de dólares por parte do licenciado e não permite a redistribuição, etc. Para projetos de código aberto sob licenças liberais como BSD, MIT ou Boost, onde os autores não ' t ganhando muito dinheiro e eles desejam liberar seu código sob uma licença liberal, a dependência da LGPL não é razoável, mas os desenvolvedores em questão geralmente não podem pagar pelo licenciamento comercial.
• # 6 é o maior razão pela qual eu evito. Quer dizer, eu não ' não quero um programa grande e desajeitado e não ' não gosto de estar vinculado a uma licença específica, mas é ' é realmente a falta de uma boa aparência e comportamento nativo que ' é um obstáculo para mim.Versões recentes do OSX e do Windows, especificamente, fizeram um trabalho fantástico em tornar suas interfaces nativas bonitas, rápidas e funcionais, e eu ' prefiro aproveitar todo o trabalho que ' já feito para mim; Acho que muitos programas sem uma aparência nativa parecem baratos e hacky para mim (nem sempre, mas me deixa um pouco estranho).
• Seu número 6 deveria ser o número 1. Este é por agora o maior problema com o Qt. Em muitos casos, ele simplesmente não usa as APIs nativas. Gosto que meu software pareça nativo. Os usuários também gostam disso. Eu ' nunca vi um aplicativo Mac criado com Qt que se parecesse com um aplicativo Mac. Nenhum outro usuário de Mac também tem, e eles ' são exigentes com esse tipo de coisa. Você perde todos os benefícios de ser " plataforma cruzada " se ' re usando-o apenas para criar aplicativos Linux, que é praticamente o único lugar em que parece nativo porque realmente não há nada nativo.
• exceto o problema do ' nativo ' a aparência não está mais lá. A velha consistência dos aplicativos do Windows agora é uma bastardização de quaisquer blobs, brilhos e animações que o WPF e o silverlight permitem que você tenha. Dê uma olhada no ' s Painel de controle do Office ou Windows 7 apenas para ver como até mesmo o principal produto da MS tem GUI inconsistente hoje em dia. Usuários de Mac – bem, você tem um ponto muito válido.
• @TrevorBoydSmith: Desculpe, mas você ' está errado. Qt é o único framework que usa pré-processamento. Período. Verifique GNOME, FLTK, WX e amigos e me mostre uma etapa de pré-processamento. Você não ' não encontrará um. Algumas outras bibliotecas vêm com diferentes sistemas de construção, mas no final do dia, são bibliotecas C ++ que podem ser construídas por qualquer compilador C ++. Quanto a " Win32 bruto não presente em minhas razões ", está presente em minhas razões como nº 5 e nº 6.

Como as pessoas dizem, cada ferramenta se ajusta a cada problema e situação …

Mas se você for um programador C ++, Qt é o seu framework. Sem rival.

Nós desenvolvemos um aplicativo comercial complexo de imagens médicas, e o Qt se mantém.

Eu não digo isso os “contras” que as pessoas dizem sobre ele são falsos, mas tenho a sensação de que eles não tentam o Qt há muito tempo (está melhorando continuamente a cada nova versão …) E, principalmente, todos os problemas que eles comentam não são um problema se você tomar cuidado.

Inconsistência da plataforma da IU: somente se você usar os widgets da IU “como eles são”, sem personalização ou arte personalizada.

Sobrecarga do pré-processador Qt : Somente se você abusar do mecanismo de slot de sinal, ou herança de QObject, quando não houver realmente necessidade.

A propósito, ainda escrevemos aplicativos em C # .NET e temos fazendo isso por um longo tempo. Portanto, acho que tenho uma perspectiva melhor.

Como eu disse, cada ferramenta para cada situação,

mas o Qt é, sem dúvida, um framework consistente e útil.

Comentários

• +1 Thaks! Eu só queria escrever o mesmo. O mais absurdo é " código não aberto / argumento comercial ". É surpreendente como muitas pessoas entendem erroneamente o termo código aberto. Qt era open-source desde que eu o uso (1.4). E costumava ter a licença mais justa: ganhe dinheiro com Qt – > pagamento.
• Ah, e eu realmente não ' t PREOCUPE-SE em adicionar DLLs de 10 MB a aplicativos contendo 50 MB de arte e mais 200 MBs de tutoriais em vídeo e dados 🙂
• O espaço necessário para o Qt é barato atualmente.
• Isso corresponde à minha experiência com Qt (a estrutura de widgets, eu não ' usei QML / QtQuick para nada sério até agora). É adequado para escrever grandes aplicativos com requisitos complexos de IU. Depois de aprender isso, você pode ser muito produtivo. Os contras mencionados (etapa de compilação separada para mocagem, arquivos ui, etc) não são um problema se o sistema de compilação estiver configurado corretamente. Eu posso recomendar o qmake ou o cmake.
• do Qt 5.8 depois, há um projeto chamado Qt Lite que minimiza extremamente o Qt para suas necessidades específicas. este é um recurso comercial;)

De todas as coisas que eu não gosto no Qt, o fato de ele não funcionar bem com os modelos me incomoda mais. Você não pode fazer isso:

template < typename T > struct templated_widget : QWidget { Q_OBJECT; public signals: void something_happened(T); }; 

Também não funciona bem com o pré-processador. Você não pode “fazer isso:

#define CREATE_WIDGET(name,type) \ struct name ## _widget : QWidget \ { \ Q_OBJECT; \ \ public signals: \ void something_happened(type); \ } 

Isso, combinado com o fato de que tudo que responde a um sinal tem que ser um Q_OBJECT, torna o Qt difícil de funcionar para um programador C ++. As pessoas acostumadas com a programação no estilo Java ou Python provavelmente são bem melhores.

Na verdade, gastei muito tempo e esforço pesquisando e desenvolvendo uma maneira de obter segurança de tipo de volta e conectar um sinal Qt a qualquer objeto functor: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html

O tipo de coisa que eu quero fazer lá é o desenvolvimento C ++ básico e diário tornado quase impossível pelo Qt moc … que em si é totalmente desnecessário hoje em dia, se é que realmente foi.

Francamente, porém, estou preso a ele porque se você quiser fazer testes automatizados de interface do usuário, Qt é praticamente o único jogo na cidade com falta de MFC. ..que é tão 1980 (é uma merda trabalhar nessa merda muito difícil). Alguns podem dizer WX, mas tem problemas ainda mais sérios. GTKmm teria sido minha primeira escolha, mas uma vez que é todo desenhado pelo proprietário e não oferece acessibilidade … não pode ser conduzido por software de teste padrão da indústria. Qt é difícil o suficiente nesse aspecto ( apenas funciona quando você modifica o plug-in de acessibilidade).

Comentários

• Sem interesse, quais são os principais problemas do WX?
• @Tom – documentação pobre, especialmente para as coisas novas. Os componentes AUI quase não são documentados com grandes seções faltando, tornando-se difícil de usar em um ambiente de produção. A documentação para o processo de evento está fundamentalmente errada em relação ao caminho que é seguido, pelo menos no win32. Gastou muito tempo gritando no computador, " Isso deve estar funcionando !!! " antes de entrar no código de processamento profundo para descobrir que o que o WX faz não ' t seguir os documentos e o que eu estava fazendo NUNCA funcionaria.
• eu era também perturbado pela aceitação da biblioteca de grade de propriedade na linha principal. Usei essa biblioteca e ela mostrou inúmeras falhas de design fundamentais, além da falta real de conhecimento por parte do programador que a escreveu (chamadas de funções virtuais em construtores, por exemplo). Ele e o mau estado do AUI mostraram uma tendência para padrões mais pobres. Eu ' também não sou um grande fã de tabelas de eventos estáticos, embora pelo menos haja ' s outra maneira de responder aos eventos … ao contrário do MFC, que WX é muito parecido para ser emocionante de qualquer maneira.
• Obrigado. Eu ' usei apenas um pouco, e por meio da API wxPython, onde parecia muito bom. Eu posso entender que isso esconderia um pouco do mal, mas também que eu simplesmente não ' me envolvi profundamente o suficiente para ter me deparado com problemas mais sérios. Algo para eu estar ciente.
• tudo que responde a um sinal tem que ser um Q_OBJECT, Não hoje em dia … Agora, funções estáticas, funções e até funções lambda podem responder a um sinal (você pode usar ponteiros de função como slots). As classes No-QObject também podem ter slots de membro se você se conectar a elas usando std :: bind para converter o membro da instância em um ponteiro de função.

Um motivo para não usar Qt é que se você escrever apenas para uma arquitetura, como Windows, pode querer usar C # /. NET (ou Cocoa no Mac) porque eles invariavelmente ser capaz de tirar proveito das últimas novidades do sistema operacional.

Se você está escrevendo aplicativos de plataforma cruzada, então você já deve estar investido em outra tecnologia, como Java (ou seja, você trabalha em uma “Loja de Java”). Sua escolha de tecnologia pode ser ditada pelo ecossistema no qual você está desenvolvendo, como APIs de linguagem específica. Nesses tipos de casos, minimizar o número de tecnologias pode ser benéfico.

Uma terceira razão que posso pensar é que o Qt é baseado em C ++, e C ++ é uma linguagem comparativamente difícil / perigosa de programar Acho que é uma linguagem para profissionais. Se você precisa ter um desempenho superior e é capaz de ser meticuloso, C ++ provavelmente ainda é o melhor jogo da cidade. Na verdade, o Qt ameniza muitos dos problemas de gerenciamento de memória se você configurar as coisas para sair do escopo. Além disso, o próprio Qt faz um bom trabalho isolando o usuário de muitos dos problemas desagradáveis do C ++. Cada linguagem e estrutura tem seus prós e contras. É uma questão muito, muito complicada que geralmente pode ser resumida pelo adágio frequentemente visto em lanchonetes: velocidade, qualidade e preço (mas você só pode escolher dois).

Embora as regras digam que devo manter focado em responder a pergunta, eu quero refutar algumas das questões levantadas por Billy ONeal, que eu acho que faz um bom trabalho resumindo as razões comumente citadas para não usar Qt:

1. Qt é de fato uma biblioteca / estrutura / arquivos de cabeçalho C ++. É aumentado por um processador de macro (moc) que habilita sinais e slots, entre muitas outras coisas. Ele transforma comandos de macro adicionais (como Q_OBJECT) para que as classes tenham introspecção e todos os tipos de outras coisas que você pode imaginar como adição de funcionalidade Objective-C ao C ++. Se você souber o suficiente sobre C ++ para se ofender com essa falta de pureza, ou seja,você é um profissional, então 1) não use Q_OBJECT e seus semelhantes ou 2) seja grato por ele fazer isso e programe nos casos mais limitados em que isso causa um problema. Para pessoas que dizem “Use Boost para sinais e slots! “, então eu retrucaria que você está trocando um” problema “por outro. Boost é enorme e tem seus próprios problemas comumente citados, como documentação deficiente, API horrível e horrores de plataforma cruzada (pense em compiladores antigos como o gcc 3.3 e compiladores big iron como AIX).

2. Para suporte do editor, isso também segue de 1, eu concordo. Na verdade, Qt Creator é IMHO o melhor editor gráfico C ++, ponto , mesmo se você não usar as coisas do Qt. Muitos programadores profissionais usam emacs e vim. Além disso, acho que o Eclipse lida com a sintaxe adicional. Assim, sem problemas com as macros Qt (Q_OBJECT) ou adições de sinais / slots. Você provavelmente não encontrará essas macros no Visual Studio, porque (admito) elas são adições ao C ++. Mas, de modo geral, o pessoal do C # /. NET não vai usar o Qt de qualquer maneira, devido ao fato de que eles têm muitas das funcionalidades cobertas por suas próprias técnicas proprietárias.

3. Quanto ao tamanho do código-fonte do Qt, contanto que ele compile durante a noite, quem se importa? Compilei o Qt 4 no meu Macbook dual core em “menos do que durante a noite”. Certamente espero que não seja isso o que está levando sua decisão usar ou não usar uma tecnologia específica. Se este for realmente um problema, você pode baixar os SDKs pré-compilados para Mac, Linux e Windows no site do Qt.

4. O licenciamento é disponível em três opções: 1) Licença proprietária no caso de você desejar modificar o Qt SI MESMO e não compartilhar, ou ocultar o fato de que está usando o Qt e não quer dar atribuição (pode ser muito importante para a marca e imagem!) 2) GPL e 3) LGPL. Sim, existem problemas com links estáticos (rolando todo o Qt para o binário) – mas acho que é mais porque não se pode dar uma espiada e perceber que você está você cantar Qt (atribuição!). Tentei comprar uma licença proprietária da Digia e eles me disseram “pelo que você está fazendo, você realmente não precisa”. Uau. De uma empresa que está no ramo de venda de licenças. li>

5. O tamanho do binário / pacote deve-se ao fato de você ter que distribuir as coisas do Qt para as pessoas que não as têm: o Windows já tem? as coisas do Visual Studio ou você tem que instalar o tempo de execução. O Mac já vem com o enorme Cocoa e pode ser vinculado dinamicamente. Embora eu não faça muita distribuição, nunca encontrei muitos problemas com a distribuição do arquivo estático de ~ 50 megabytes (que posso tornar ainda menor com alguns dos utilitários de compactação / stripper binário como UPX). Eu simplesmente não me importo o suficiente para fazer isso, mas se a largura de banda fosse um problema, eu adicionaria uma etapa UPX ao meu script de construção.

6. O que define “aparência e comportamento nativos?” Acho que a “maioria” concordaria que o Mac é o que mais se aproxima da aparência e sensação unificadas. Mas aqui estou eu, olhando para Safari, iTunes, Aperture, Final Cut Pro, Pages, etc. e eles não se parecem em nada, apesar de serem feitos pelo fornecedor do sistema operacional. Acho que o aspecto “sentir” é mais relevante: estilo do widget, capacidade de resposta etc. Se você se preocupa com a capacidade de resposta, então aqui está um bom motivo para usar C ++ em vez de Java ou alguma outra linguagem altamente dinâmica. (Objective C também arrasa, mas estou tentando dissipar mitos sobre Qt)

Em resumo, é uma questão complicada. Mas eu gostaria de salientar que acho que há menos razões para “não usar Qt” do que se poderia pensar com base em mitos e informações desatualizadas em décadas.

Comentários

• O que eu não ' entendo é por que essas bibliotecas de plataforma cruzada não são ' simplesmente funções de empacotamento , ou ainda melhor; se defs em torno de funções Cocoa, Win32, KDE / Gnome, garantindo a interface do usuário mais bonita, com todos os recursos ' s.
• @MarcusJ Escrevendo um wrapper um kit de ferramentas é claramente não trivial, quanto mais 4 ou mais – mas se você acha que ' é tão fácil, você ' é bem-vindo tentar. Quanto à ideia de que isso poderia ser alcançado usando apenas pré-processamento condicional … você deve estar brincando, certo?
• @MarcusJ libui é exatamente isso (embora sem suporte para KDE).
• Quero acrescentar que agora você pode usar Qt / QML com .NET. Você não ' não precisa tocar em C ++. github.com/qmlnet/qmlnet PS: Eu ' sou o autor.

Parte disso é licenciamento. Consulte https://en.wikipedia.org/wiki/Qt_(software) #Licenciamento para um pouco do histórico de licenciamento. Até 2000, as pessoas que se preocupavam muito com o código aberto não usavam o Qt. Período. (Esta foi, de fato, a motivação original para o desenvolvimento do Gnome.) Até 2005, as pessoas que queriam lançar software livre para Windows não usavam Qt.Mesmo depois dessa data, as pessoas que queriam software livre sob algo diferente da GPL, simplesmente não tinham a opção de usar o Qt. Portanto, qualquer projeto de software livre anterior a essas datas não poderia usar o Qt. E, é claro, as pessoas que escreviam código proprietário tinham que pagar pelo privilégio.

Além disso, não é como se houvesse um falta de outras opções. Por exemplo WxWidgets , GTK + e Tk são todos de código aberto, kits de ferramentas de plataforma cruzada.

Além disso, por muito tempo o Windows foi tão dominante na área de trabalho que muitos softwares se contentavam em rodar apenas no Windows. Se você instalar o conjunto de ferramentas da Microsoft, é mais fácil apenas usar as coisas proprietárias da Microsoft do que se preocupar com qualquer outra coisa, e muitos programadores fizeram exatamente isso.

Comentários

• @btilly: GTK + é uma plataforma cruzada. Por exemplo, o cliente Pidgin IM é escrito em GTK +.
• Ok, no entanto, é possível ' de alguma forma ' para executar no Windows 🙂
• Basta instalar o GIMP no Windows e dar uma olhada.
• Sim, e o GIMP funciona bem no Windows, mas certamente não ' não se ajusta à interface do usuário do Windows 7 & sensação.
• O Pidgin é provavelmente um exemplo melhor de GTK no Windows. Não ' não faz nada extravagante, mas se encaixa e tem sido por cerca de 10 anos ou mais?

Eu concordo com quase todas as razões discutidas acima, porém muitas pessoas aqui disseram que não usariam o Qt por causa da sobrecarga extra que ele traz consigo. Eu discordo com isso porque todas as linguagens mais comuns hoje (Java, C # e Python) carregam um pouco de sobrecarga.

Em segundo lugar, o Qt torna a programação com C ++ tão fácil e direta que compensa o recursos extras que usa. Eu encontrei alguns aplicativos de console escritos em Qt em vez de C ++ padrão, devido à facilidade com que podem ser escritos.

Eu diria que a produtividade do Qt é maior do que a de C / C ++, mas menor do que linguagens como Python.

Comentários

• Acho que ' é tudo relativo à experiência ' individual, porque posso codificar OK em C ++ 14, mas toda vez que eu olho para algum código Qt, tenho que apertar os olhos para reconhecê-lo como a mesma linguagem … então eu certamente não ' não acho ' é o impulsionador de produtividade unânime que você ' está sugerindo aqui.
• @underscore_d obviamente se você conhece C ++ muito bem e não ' t Qt, você não será mais produtivo com o último. Mas quando você conhece C ++ e Qt, o framework está realmente tornando muitas coisas mais fáceis e rápidas de implementar (C ++ 11, 14 etc. estão preenchendo a lacuna, mas ainda não totalmente).

Isso realmente não é uma tentativa de iniciar um conflito armado, eu só queria abordar alguns dos pontos.

Provavelmente, a verdadeira razão pela qual Qt não é mais amplamente usado é que é C ++ e menos pessoas usam c ++ para aplicativos de desktop.

Qt não é uma biblioteca C ++. Requer uma etapa de compilação separada, o que torna o processo de construção muito mais complicado quando comparado com a maioria das outras bibliotecas.

O vs-addin para visual studio faz isso automaticamente, assim como o próprio processo de criação de linha de comando do Qt. O compilador de recursos usado para construir as caixas de diálogo para MFC também é uma etapa separada, mas ainda é c ++.

Qt é uma grande quantidade de fonte, que deve estar presente e pré-instalado em qualquer máquina que você usar antes de compilar. Isso pode tornar a configuração de um ambiente de compilação muito mais tediosa.

Há um download binário para cada versão do Visual Studio e a construção a partir do código-fonte é um único comando. Não vejo que o tamanho do código-fonte do SDK seja tão importante atualmente. O Visual Studio agora instala todas as bibliotecas C ++ em vez de permitir que você escolha e escolha; como resultado, o tamanho da instalação do compilador é> 1 Gb.

It ” s disponíveis apenas sob LGPL, o que torna difícil o uso de implantação binária única quando é necessário liberar sob uma licença mais restritiva ou menos restritiva.

A LGPL só se aplica à lib, não afeta seu código. Sim, significa que você precisa enviar DLLs em vez de um único binário (a menos que você pague), mas em um mundo onde você precisa baixar um Java runtime ou uma atualização .Net para um pequeno utilitário, isso não é grande coisa. “também é menos problemático em plataformas com uma única ABI para que outros aplicativos Qt possam compartilhar as bibliotecas.

Em alguns casos, simplesmente não” t parecem programas nativos.Projetar uma única interface do usuário para todas as plataformas inerentemente não vai parecer certo quando movido de máquina para máquina, por vários motivos de estilo visual.

É suposto para usar widgets e temas nativos. Devo admitir que faço principalmente aplicativos técnicos, então meus usuários não se preocupam muito com o estilo. Especialmente no Windows, a nova moda de ter tudo estilizado como um widget de smartphone significa que há cada vez menos um padrão de qualquer maneira.

Comentários

• Muitas grandes empresas de software criam aplicativos comerciais em C ++, mas eu ' não tenho conhecimento de muitas que usam QT. Portanto, embora eu entenda que desenvolvedores não C ++ podem evitar QT, há outras razões para evitar QT, mesmo quando você está escrevendo um aplicativo C ++, ao que parece. Na verdade, realmente não existe ' qualquer linguagem de plataforma cruzada e kit de ferramentas de interface gráfica do usuário que eu possa ' encontrar falhas. Parece que o desenvolvimento de plataforma cruzada é APENAS PRATICAMENTE DIFÍCIL e que fazê-lo bem nunca é fácil ou grátis, e que a promessa feita pelo QT (Escreva sua GUI uma vez e reutilize essa GUI em todos os lugares) não '
• A maioria dos softwares C ++ de desktop está no MFC porque começou há 20 anos ou usa um kit de ferramentas interno iniciado há 20 anos para evitar o MFC (por exemplo, MS-Office ou Autocad). Duvido muito que esteja sendo escrito em C ++ / CLR com WPF. Mas mesmo sem considerações de plataforma cruzada eu acho o Qt o melhor (ou pelo menos o pior!) Kit de ferramentas para desktop. Como a maioria das pessoas, estamos avançando em direção a um front-end webby (possivelmente em QtQuick / QML) e um servidor backend C ++ – que provavelmente usará sinais / slots Qt, mas sem interface de usuário
• Concordo. Pelo menos pior. E mesmo em aplicativos somente para Windows, ' prefiro depurar problemas de QT do que problemas de MFC.
• @WarrenP – sim, não ' não deixe de pesquisar no codeproject todas as coisas que faltam no MFC. Mas com o novo amor da MSFT ' pelo código nativo – eles não ' fizeram muito para tornar a escrita de um gui mais fácil.

A razão é simples: não possui bons vínculos para todas as linguagens dominantes e não é por mágica sempre apropriado para o trabalho em questão.

Use a ferramenta certa para o trabalho. Se estou escrevendo um aplicativo de linha de comando simples, por que aumentaria isso com o Qt só por causa disso?

Como uma resposta mais geral (que posso dar porque sou relevante aqui ), alguns programadores simplesmente nunca deram uma chance e decidiram usá-lo. Em alguns casos, não há nenhuma razão específica além do programador nunca ter encontrado uma necessidade para isso e investigado.

Comentários

• Mas o Qt fornece capacidade de escrever apenas aplicativos de console. Não é ' é?
• @Dehumanizer: Não faço ideia. Mas por que eu o usaria para uma pequena ferramenta utilitária? Que benefício isso me traria se eu pudesse escrever trivialmente o aplicativo apenas em C ++ padrão? Parece que você ' está procurando uma razão para usar uma biblioteca , que é uma maneira reversa de programar.
• @Dehumanizer: Como Eu disse que ' é uma abordagem para trás. Quando você precisar de uma biblioteca, ' saberá, e então poderá experimentar algumas e ver o que se adapta melhor às suas necessidades. Tentar reunir opiniões sobre uma biblioteca quando você não ' não tem um caso de uso é uma tolice ' s recado.
• " Se eu ' estou escrevendo um aplicativo de linha de comando simples, por que iria sobrecarregá-lo com Qt apenas por causa disso " há pelo menos uma ferramenta não-gui muito famosa escrita em Qt – Doxygen 🙂
• @Dehumanizer por exemplo quando você tem que lidar com arquivos, xml, unicode, json, regexp, simultaneidade, bancos de dados, etc, etc, muito rápido e não ' não deseja baixar, adotar, manter dezenas de terceiros bibliotecas de terceiros.

Frameworks como o Qt são apropriados quando você está mais preocupado com a aparência de seu produto o mesmo em todas as plataformas do que com seu produto parecendo certo em todas as plataformas. Hoje em dia, cada vez com mais frequência, esses tipos de aplicativos estão migrando para tecnologias baseadas na web.

na minha opinião, aprender programação C ++ é mais simples do que cair em outras linguagens que escondem sua complexidade, e o programador não sabe o que realmente acontece em segundo plano. O Qt, por outro lado, adiciona alguns benefícios sobre o C ++, para torná-lo um nível superior ao do C ++ nativo. Portanto, Qt C ++ é um ótimo framework para quem deseja desenvolver tarefas de baixo nível, ou de alto nível, da mesma maneira. C ++ é (por algumas práticas) uma linguagem complexa e simples. Complexo para quem não quer desafiar, simples para quem gosta.Não deixe por causa da complexidade!

Concordo que Qt é um bom framework para trabalhar. Mesmo assim, tenho vários problemas com ele:

1. É escrito em C ++, que é uma linguagem de baixo nível. O simples fato de ser C ++ tornará cada programador Qt significativamente menos produtivo em comparação com Frameworks escritos em outras linguagens. Minha principal dificuldade com o C ++ como linguagem de desenvolvimento de GUI é que ele quase não tem noção de gerenciamento automático de memória, o que torna o processo de desenvolvimento muito mais sujeito a erros. Não é introspectivo, o que torna a depuração muito mais difícil. A maioria dos outros kits de ferramentas GUI principais tem alguma noção de gerenciamento automático de memória e introspecção.
2. Todo kit de ferramentas de plataforma cruzada sofre do problema de que só pode implementar o mínimo denominador comum de todas as plataformas suportadas. Isso, e as diferentes diretrizes da interface do usuário em diferentes plataformas questionam a conveniência de interfaces de usuário multiplataforma como um todo.
3. O Qt é muito centrado na codificação de toda a sua interface do usuário. Mesmo que você possa usar o QtDesigner para construir algumas partes de sua IU, ele está seriamente deficiente em comparação com, digamos, o Construtor de Interface (Cocoa / Obj-C) ou as ferramentas .Net.
4. Mesmo que o Qt inclua muitas funcionalidades de aplicativos de baixo nível, ele não pode ser comparado a ter um framework feito à mão para uma determinada plataforma. As bibliotecas nativas do sistema operacional para Windows e OSX são significativamente mais poderosas do que as implementações do Qt. (Pense em estruturas de áudio, acesso ao sistema de arquivos de baixo nível, etc.)

Dito isso, eu adoro usar PyQt para prototipagem rápida de aplicativos ou aplicativos internos. Usar Python para fazer toda a codificação alivia as preocupações com C ++ e realmente torna o Qt um lugar muito agradável.

Edite, em resposta a alguns comentários:

Quando eu escrevi sobre o Qt sendo escrito em C ++, não estava reclamando muito do próprio Qt , mas mais sobre o ambiente em que vive. É verdade que o Qt gerencia seus próprios recursos muito bem, mas todo o código relacionado à GUI, mas não ao Qt, deve ser escrito em C ++ também. Mesmo assim, o Qt fornece muitos boas ferramentas, mas no final das contas, você tem que lidar com C ++ nesse nível. Qt torna C ++ suportável, mas ainda é C ++.

Quanto à introspecção, o que quero dizer é o seguinte: Os casos mais difíceis de depurar são quando você tem um ponteiro para algum objeto que não se comporta da maneira que você acha que deveria. Com C ++, seu depurador pode ser capaz de olhar dentro desse objeto um pouco (se acontecer de ele ter informações de tipo nesse ponto), mas mesmo isso nem sempre funciona. Veja, por outro lado, o Cacau na mesma situação. No Cocoa / Obj-C, você seria capaz de enviar mensagens (“funções de chamada”) para um objeto diretamente no depurador. Você pode alterar o estado dos objetos, pode consultá-los sobre seus atributos, pode pedir seus tipos e nomes de funções … Isso pode tornar a depuração muito mais conveniente. Qt / C ++ não tem nada nem perto disso.

Comentários

• 1. Qt cuida do gerenciamento de memória por conta própria, você não precisa chamar ' delete ' após cada ' novo '. 1a. C ++ NÃO é uma linguagem de baixo nível, é uma linguagem de alto nível com ' habilidades ' de baixo nível. 3. Eu concordo, mas o Qt fornece para fazer uma IU com QtDesigner e com ' código simples ' ao mesmo tempo. 4. Concordo novamente, mas o Qt também fornece o uso de APIs nativas.
• para o seu ponto nr 1. Eu acho que c ++ tem um tipo de gerenciamento de memória semiautomático: se você usar ponteiros inteligentes como std :: auto_ptr ou boost :: shared_ptr etc. você geralmente não precisa se preocupar em liberar memória. Esses tipos de contêineres também podem ser feitos para outros recursos (arquivos, recursos do sistema que precisam ser liberados). O uso do padrão RAII ajuda muito com o gerenciamento de memória e conforme ele cresce em você, você realmente não precisa se preocupar com a memória.
• " Só o fato de que é C ++ tornará cada programador Qt significativamente menos produtivo em comparação com Frameworks escritos em outras linguagens. " [carece de fontes]
• @ SK-logic: Embora eu pense Eu entendo todas as palavras da sua terceira frase, não tenho ideia do que você está dizendo. O que é um " nível de limite de abstração "? Por falar nisso, sua primeira frase é falsa, dada a definição da Wikipedia de " linguagem de baixo nível ".
• @ SK-logic: a metaprogramação de template é Turing-completa, e existem pessoas inteligentes e com conhecimento suficiente para tirar vantagem disso. RAII não é ' t ótima coleta de lixo, mas o fato de que funciona para todos os tipos de recursos mais ou menos compensa isso.Agora, especificamente, que tipo de abstração funciona em Java, mas não em C ++?

O mais importante, mas coisa não mencionada. Em grandes projetos, uma coisa causa tantos problemas e código desnecessário. Os mecanismos de slot de sinal do Qt são ineficientes. Os widgets do Qt não fornecem os sinais necessários para widgets simples de evento. Por exemplo, você não pode definir sinais para onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus e etc. Mesmo o widget mais complexo, como QTreeWidget fornece um ou dois sinais inúteis ultra simples.

Sim, você pode usar eventos, MAS !!! você criou uma nova classe para cada widget com evento personalizado. Isso é uma grande perda de eficiência;

• Você reescreveu cada evento de objeto widget personalizado, há pequenas mudanças.
• Você perde todas as coisas do Qt Designer. Você deve promover cada widget com eventos personalizados.
• O projeto se tornou maior e difícil de manter.
• Você começou a não gostar de qt por causa disso. E começando a falar sobre como .net fornece delegados, como é muito, muito melhor do que slot de sinal, como .net componentes (widgets) geralmente fornecem todos os eventos que você pode imaginar. E etc.

Um de minha faculdade escreveu uma nova classe de caixa de combinação para cada widget de caixa de combinação porque ele teve que usar algum evento sem sinal. História verdadeira …

No entanto, Qt é a melhor estrutura de interface do usuário C ++ até agora, com altos e baixos.

Comentários

• Com relação a eventos e criação de novas classes: você pode usar filtros de eventos em classes que precisam reagir a eles.
• " Sim, você pode usar eventos MAS !! ! você criou uma nova classe para cada widget com evento personalizado. Isso é uma enorme perda de eficiência; " – NÃO EXATAMENTE. Acabei com o bool eventFilter que lida com vários widgets e, em seguida, installEventFilter (this) em todos os widgets filhos. E isso não ' está perdendo eficiência e desempenho de programação! Na verdade, eu nunca uso " Widgets promovidos " … Eu deixo cair apenas um widget vazio, instalo-o como eventFilter nele e reimplemento a maior parte meus eventos dentro da minha classe cpp principal. Experimente, não ' dói 🙂 Você pode personalizar quase TUDO no Qt sem criar novas classes sempre

Eu realmente gosto de Qt, mas é um pouco pesado para muitos aplicativos. Às vezes, você simplesmente não precisa desse nível de complexidade. Às vezes você só precisa de algo simples sem todo o overhead do Qt. Nem todo aplicativo precisa ser orientado a eventos e o C ++ fornece um conjunto razoável de modelos. Boost fornece outro conjunto muito bom e inclui muitas das funcionalidades de baixo nível (arquivo, soquete, ponteiros gerenciados, etc) que o QT oferece.

Outros aplicativos têm requisitos de licenciamento que não funcionam bem com GPL , Licença comercial LGPL ou Qt. A GPL é inadequada para software comercial. A LGPL é inadequada para software vinculado estaticamente e a licença comercial custa dinheiro – algo que muitos não estão dispostos a pagar.

Alguns têm considerações de segurança ou estabilidade que não permitem bibliotecas complexas como o Qt.

Você precisa executar o moc para pré-processar seus fontes. Isso não é um grande problema, mas pode ser assustador para o novo usuário. Muitos programadores pensam que você precisa de usar qmake com Qt, mas esse é um nome impróprio. É possível conectar o Qt em outros sistemas de construção com bastante facilidade.

Alguns alvos são muito memória ou CPU restrita.

Há algumas pegadinhas específicas da plataforma. A maioria dessas pegadinhas não está documentada. Construa um aplicativo suficientemente grande e você irá topar com eles e se perguntar o que está acontecendo (isenção de responsabilidade, o a última vez que usei o Qt com raiva foi há mais de 18 meses, então pode ter melhorado).

É apenas C ++. Existem outras ligações de linguagem, mas elas tendem a ocultar ou expor mal muitos dos funcionalidade que você deseja que o Qt tenha.

Existem várias razões para não usar o Qt, é por isso que existem alternativas. Se você só tem um martelo, todos os problemas se parecem com um prego.

Comentários

• " A LGPL é inadequada para software vinculado estaticamente [código fechado] " – isso parece ser impreciso, já que LGPL e links estáticos são legalmente possíveis ( veja ).
• Sua posição parece correta. Veja gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic Mas é ' é trabalho extra e coisas extras enviar. Você pode fugir com isso? sim. Você quer despender o esforço? Possivelmente não.

O motivo real não é técnico.

Pessoas acontecem ser diferente. Então, são suas escolhas. A uniformidade não é uma característica humana.

Comentários

• É por isso que todas as pessoas andam sobre as pernas? Bem, quem tem pernas pelo menos …