C++ mais produtivo
Thiago Adams
Como tornar o desenvolvimento usando C++ mais produtivo?
Thiago Adams
-x-
- Tempo de compilação
- ..?
Rodrigo Kumpera
Uma estação xeon 8 cores sai por menos de 10mil. Isso se paga provavelmente em 6 meses.
Ah, para isso o build da tua aplicação tem que ser paralelizavel.
Cesar Mello
Marcos Ludwig
Felipe Magno de Almeida
> Invista dinheiro em uma boa workstation.
> Uma estação xeon 8 cores sai por menos de 10mil. Isso se paga provavelmente
> em 6 meses.
Eu uso um Core 2 Quad 2.4GHz com 8GB de RAM como workstation.
Compilo minhas dependencias do boost + meus projetos em menos de meia hora.
Obviamente que quase sempre isto nao é necessário.
> Ah, para isso o build da tua aplicação tem que ser paralelizavel.
O que seria de mim sem build paralelizado. :P
--
Felipe Magno de Almeida
Pedro Lamarão
de uma API ao máximo.
Quando sua APi retorna às vezes uma referência, às vezes um ponteiro,
às vezes um shared_ptr, às vezes uma referência para shared_ptr, às
vezes uma classe proxy, o programador terá problemas para manter um
modelo mental desta API em mente, e passará boa parte do dia olhando
pro monitor com cara de bobo.
--
P.
Rodrigo Kumpera
Felipe Magno de Almeida
> Meia hora?!?!?! Afe! E eu reclamando dos 4 minutos que leva pra reconstruir
> meu atual projeto em C inteiro.
C é mole de compilar :P
Rodrigo Kumpera
2008/5/9 Rodrigo Kumpera <kum...@gmail.com>:
> Meia hora?!?!?! Afe! E eu reclamando dos 4 minutos que leva pra reconstruirC é mole de compilar :P
> meu atual projeto em C inteiro.
--
Eu sempre me esqueço da bomba que trabalhar é com C++, ainda mais quando se usa templates e acaba por mexer nos headers com muita freqüência. Depender de um ciclo de compilação de mais de 10 minutos me deixaria maluco.
Felipe Magno de Almeida
>
>
[snip]
> Eu sempre me esqueço da bomba que trabalhar é com C++, ainda mais quando se
> usa templates e acaba por mexer nos headers com muita freqüência. Depender
> de um ciclo de compilação de mais de 10 minutos me deixaria maluco.
Pra quase qualquer modificação meu projeto leva menos de 2 minutos pra compilar.
Sendo que uns 30 segundos é pro build carregar.
É preciso saber diminuir as dependencias no projeto pra manter o build
gerenciavel.
Mas um build do zero leva uma meia hora. Mas aí é hora de tomar um
café e tal né ;).
Mas mesmo 2 minutos atrapalha sim a produtividade.
thiagodp
> Pra quase qualquer modificação meu projeto leva menos de 2 minutos pra compilar.
cabeçalhos. Mesmo colocando as diretivas de compilação para proteger a
declaração dos headers (os #ifndef ... #define ... #endif da vida)
isso toma algum tempo do compilador. Dá pra fazer algumas otimizações
acertando os pragmas do compilador para ele criar os cabeçalhos pré-
compilados em cache e depois usar onde preciso sem ter que recompilá-
los. Em muitos casos é necessário acertar manualmente um determinado
conjunto de bibliotecas que serão colocadas num conjunto, usando
#pragma hdrstop (dependend do compilador), pra o compilador gerar o
cache do grupo de bibliotecas e utilizar esse cache quando houver a
reincidência do grupo em outra biblioteca.
> Sendo que uns 30 segundos é pro build carregar.
prioridade mais alta, para acelerar o processo. No windows, por
exemplo dá pra chamar pelo comando start colocando a prioridade em
ABOVENORMAL ou HIGH. Não recomendo colocar em REALTIME porque senão
você não faz mais nada... :p
> É preciso saber diminuir as dependencias no projeto pra manter o build
> gerenciavel.
similaridade de uso", por assim dizer, eram agrupadas em um só arquivo
na tentativa de diminuir o tempo de compilação. Em alguns casos havia
uma certa melhora. Mas, claro, há um preço a pagar, tanto pela
organização quanto pelas dependências criadas.
> Mas um build do zero leva uma meia hora. Mas aí é hora de tomar um
> café e tal né ;).
> Mas mesmo 2 minutos atrapalha sim a produtividade.
>
> --
> Felipe Magno de Almeida
perde mais tempo compilando de que programando certa funcionalidade.
Em casos onde não há o que fazer em termos de otimização de
compilação, o jeito é dar uma boa revisada no código pra já pegar
algumas coisas que possam ter passado desapercebidas.
..:: Thiago ::..
Cesar Mello
>
> Diminuir o número de elementos individuais necessários ao entendimento
> de uma API ao máximo.
>
> Quando sua APi retorna às vezes uma referência, às vezes um ponteiro,
> às vezes um shared_ptr, às vezes uma referência para shared_ptr, às
> vezes uma classe proxy, o programador terá problemas para manter um
> modelo mental desta API em mente, e passará boa parte do dia olhando
> pro monitor com cara de bobo.
>
Concordo plenamente. Sem uma padronização mínima no estilo das APIs fica
muito mais difícil escrever código correto de primeira ou
"naturalmente". E fica ainda mais difícil revisar o código. Um pouco de
padronização por outro lado ajuda a fazer a coisa certa "por default".
Isso que o Lamarão citou é um ótimo exemplo de boa prática. Não é apenas
a questão da padronização em si, mas principalmente evitar dúvidas e
RISCOS desnecessários. O C++ é uma linguagem cheia de riscos, mas que
podem ser evitados com treinamento extenso (como o Marcos Ludwig citou),
e com a adoção de práticas saudáveis. Não é à toa que cada ano de
experiência dá tanto poder a um programador C++. Aproveito pra reforçar
mais uma vez a sugestão do "C++ Coding Standards". Cada página desse
livro vale MESES ou ANOS de experiência.
PS: Eu juro que não ganho nem um centavo com vendas desse livro, nem do
TC++PL. :-) Recomendar esses livros é simplesmente o conselho mais
rápido e com melhor resultado que posso dar.
Outra práticas óbvias recomendadas no livro é ter controle de versão,
builds automáticos limpos (sem warnings), revisão de código, testes
automáticos... Vale a pena lembrar o quanto cada bug que passa pela
revisão de código custa em tempo de desenvolvimento. Evitar bugs é a
melhor forma de aumentar a produtividade com C++.
Vai mais uma vez aí:
[]
Mello
Márcio Gil
Alex Sandro Garzao
Na minha opinião eu colocaria 3 pontos:
1) A sintaxe complexa em alguns casos (o que dificulta a memorização)
e extensa (o que faz com que tenhamos que digitar muito sem comparado
com C#, D, ...)
2) Os necessários (mas chatos) ".h.".
Eu sei que pela definição da linguagem o .h é indispensável, mas é um
saco para quem trabalha com um ambiente que não tem um editor para
automatizar essas tarefas ou uma ferramenta para geração das classes
como Umbrello, Together, ....
Eu geralmente crio o .h, populo com classes, métodos, corpo dos
métodos, e quando acho que tá "aceitável" eu crio um .cpp dele e
retiro o corpo dos métodos do .h.
Eu também acho um saco ter que sincronizar a definição de um método no
.h com o equivalente no .cpp, isso sem contar que a definição dos
métodos nem sempre é igual nos dois (default de parâmetros não é
especificado no .cpp), ou seja, nem sempre é só copy&paste "burro".
Difícil é claro que não é, mas acho que isso tudo ajuda a diminuir a
produtividade.
Claro que um ambiente bom para desenvolvimento ajuda (e muito) a questão do .h.
Eu lembro até que na época que eu programa em C (1992, TC 2.0) eu
criava o .cpp e rodava o compilador (ou alguma ferramenta do pacote,
não me lembro bem agora) que buscava todas as funções e gerava um ".h"
com o protótipo das funções. Não era a melhor coisa do mundo, mas
ajudava bastante...
3) Bibliotecas. Eu, sempre que possível, desenvolvo meus projetos em
C++, mas vejo que uma linguagem com um conjunto robusto e
diversificado de bibliotecas tende a ser mais produtiva (claro, após o
aprendizado do uso dessas bibliotecas).
Abraços !!!!
2008/5/10 Márcio Gil <marci...@bol.com.br>:
--
[]'s
Alex Sandro Garzão
Otávio Basso Gomes
Bah, os .h são chatos, mas para quem usa o Emacs (alguem?...) existe
este macro:
http://www.emacswiki.org/cgi-bin/wiki/switch-file.el
Ele faz o switch entre o .h e o .cpp. Ex. se estiver editando o arquivo foo.h
ele vai para o foo.cpp. se estiver editando o bar.cpp ele vai para o bar.h
Eu coloco como o atalho C-o:
(global-set-key "\C-o" 'switch-cc-to-h)
Vinicius Jarina
/* Alberto Fabiano */
Acho que pra tornar o C++ mais produtivo uma ferramenta que ajuda (e muito) é o Visual Assist X, ele praticamente advinha o que você vai escrever XD. E tem outras features como essa de alternar entre .cpp e .h e menus extras com refactoring ..e etc...muito bom!
Sem aprofundar-se nas entranhas da linguagem, com certeza conhecer e ter boas ferramentas é fundamental! O que o Pedro comentou é muito válido, conheço na pele o que ele tentou expressar e como agora irei lidar com mais 2 colegas Jrs acho que mais uma vez na pele sentirei isto! :-/
Há muito o que dizer neste tópico, porém muitos fatores (como o de ferramentas adequadas) são genéricos a várias linguagens, como por exemplo os gotchas.
Eduardo Nakamatu
Eduardo Nakamatu
--
Eduardo Nakamatu
Consultor de Negócios, Desenvolvedor & Instrutor ADVPL Microsiga
ADVPL Consultoria, Treinamentos e Fabrica de Software.
edu...@advpl.com.br
www.advpl.com.br
thiagodp
tornar o desenvolvimento usando C++ mais produtivo?". Me ajudem
anexando suas idéias:
1- Conhecimento homogêneo da linguagem pela equipe de desenvolvimento
(truques, regras, etc.);
2- Conhecimento homogêneo de bibliotecas utilizadas pelos projetos
(STL, Boost, Crypto++, etc.);
3- Padronização do código (estilo, documentação, etc.);
4- Boas ferramentas de desenvolvimento (IDEs e outros);
5- Configuração otimizada de dependência de arquivos, do compilador,
paralelismo e de outras ferramentas;
6- Boa configuração de hardware;
..:: Thiago ::..
Rodrigo Strauss
* Estudar todos os recursos da linguagem, talvez lendo o livro do
Stroustrup ou outra referência completa
* Aprender a usar um bom editor ou IDE é quase tão importante quanto
saber C++. A melhor combinação que eu conheço ainda é
Windows+VisuaStudio+VisualAssist. Também uso
Linux+vim+ctags+OmniCppComplete. Vim assusta mas não morde, é um ótimo
investimento de tempo. O mesmo vale para Emacs.
* Uma máquina rápida ajuda. Um HD rápido é importante do que um
processador com trocentos cores.
Rodrigo Strauss
On Fri, May 9, 2008 at 11:54 AM, Thiago Adams <thiago...@gmail.com> wrote:
>
>
Rodrigo Kumpera
Rodrigo Strauss
STL e Boost e coisas assim pra lá?
Rodrigo Strauss
2008/5/13 Rodrigo Kumpera <kum...@gmail.com>:
Rodrigo Kumpera
Igor Mol
--
[]'s
Igor Mol
- http://www.yrado.net
Felipe Magno de Almeida
> Você ainda compila teu projeto no disco? Instala mais memoria ai e faça isso
> de um tmpfs. Funciona que é uma maravilha.
Nunca tive problema com o HD.
Meu projeto (sozinho, sem as dependencias) gera em torno de 1GB de arquivos
intermediários por variante. Sendo a de depuração um pouco maior.
E mesmo assim meu disco (Um SATA 2 7200rpm 320GB) dá conta
tranquilo de manter 4 CPUs em utilização máxima.
Um tmpfs (existe algo parecido pra windows?) me ajudaria a economizar
espaço em disco porém, ao custo de ter q recompilar algumas vezes mais, de vez
em qdo. Como programo para x64 e win32, e compilo
debug, release e profile de tempos em tempos, isso dá 6GB de arquivos
intermediários.
[snip]
[]'s