logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog

Add to Google

Talvez você ache interessante ver a lista com todos os posts ou minha lista com os melhores posts.

Sobre minha nomeação como Microsoft MVP em Visual C++

Como alguns de vocês devem saber, esse ano eu fui nomeado Microsoft Most Valuable Professional em Visual C++. Aos que estão fora do mundo Microsoft, MVP é um "título" que a Microsoft concede aos profissionais que colaboram com a "comunidade" difundindo conhecimento sobre um dos produtos deles. É basicamente o que eu faço na lista de discussão do grupo C & C++ Brasil, com os eventos sobre C++ que eu ajudo a organizar e com os posts sobre Visual C++ aqui no blog. Mais detalhes sobre o programa MVP no site da Microsoft.

O único MVP de Visual C++ no Brasil era o Fabio Galuppo, que é também membro do grupo C & C++ Brasil.

Seja lá o que for, eu recebi isso por causa do grupo C & C++ Brasil, afinal, não costumo participar dos eventos da própria Microsoft e não respondo perguntas nos newsgroups da Microsoft faz anos. Até onde sei isso não é comum, e acho bem legal ter esse reconhecimento devido à uma comunidade não-Microsoft. Na minha primeira mensagem para lista-vip-clube-de-campo dos MVPs eu falei sobre o grupo C & C++ Brasil, a lista, e a variedade de tecnologias que usamos. Afinal, o último evento do grupo teve C++11 (com Visual C++), Android+Bada+iOS, ARM e até um framework usado pelo CERN. Mas sempre falamos de Visual C++ também.

Meu agradecimento pela nomeação (não é um prêmio) vai para os membros do grupo C & C++ Brasil, mas se extende à todos os programadores C & C++ do Brasil. Nós já vimos muitas modinhas irem e virem, mas continuamos aqui. E continuamos multiparadigma, multilinguagem e na maioria das vezes muitissistemaoperacional. (essas regras novas de gramática ainda me confundem...).

Em 15/01/2012 22:28 - Comentários (1)

C++11: auto

A palavra chave auto já existe no C++ desde os tempos mais primórdios. Ela sempre era (sim, era) um modificador de storage de variáveis. Você podia escolher o modificador auto para variáveis de armazenamento automático e register para armazenar a variável em um registrador. Esse modificador hoje em dia é implícito: se não especificado o armazenamento o compilador decide onde armazenar. De forma automática. O modificador register, até onde sei, é grande conhecido do pessoal de embarcados, que muitas vezes trabalham com recursos limitados e precisam gerenciá-los a ponto de dizer ao compilador onde a variável x será armazenada.

Interessante lembrar que a palavra chave register gera alguns efeitos colaterais, como a impossibilidade de pegar o endereço da variável com o operador &. E tem ainda o fato de que muitos compiladores modernos simplesmente não respeitam o register.

  1. //
  2. // Eu dizendo ao compilador que quero a variável a
  3. // *preferencialmente* armazenada em um registrador.
  4. //
  5. register int a = 10;
  6.  
  7. //
  8. // Eu dizendo para o compilador "eis minha variável b, enfie
  9. // onde bem entender"
  10. //
  11. auto int b = 42;
  12.  
  13. //
  14. // Quando não especifico nada, o "enfie onde quiser"
  15. // está subentendido
  16. //
  17. int c = 42;

Com o padrão C++11 o significado dessa palavra chave foi modificada. Agora ela é usada para tipar uma variável de acordo com a expressão a ela atribuída. Na linha "int a = "2 + 2", o compilador sabe que a expressão "2 + 2" retorna um tipo inteiro - na realidade o compilador sempre sabe o tipo de uma expressão em uma linguagem tipada - e pode muito bem acertar a declaração de acordo.

Esse recurso não é lá muito útil para expressões simples e pode até prejudicar a legibilidade do código, já que o leitor terá que efetuar de cabeça a mesma avaliação de expressão que o compilador fez. Ele realmente se torna útil para tipos e subtipos de classes templates, onde só o tamanho da declaração do tipo da variável pode tomar mais da metade da tela. Exemplo:

  1. //
  2. // Variável a será do tipo int
  3. //
  4. auto a = 10;
  5.  
  6. //
  7. // Variável f será do tipo double, devido à regra de promoção de tipos
  8. //
  9. auto f = 10 * 2.0;
  10.  
  11.  
  12. std::map<std::string, std::string> um_mapa;
  13.  
  14. //
  15. // Variável i será do tipo informado
  16. //
  17. std::map<std::string, std::string>::iterator i = um_mapa.begin();
  18.  
  19. //
  20. // Variável biggie_smalls terá o mesmo tipo da variável i,
  21. // mas economizando bastante espaço
  22. //
  23. auto biggie_smalls = um_mapa.begin();
  24.  
  25. //
  26. // Só pra mostrar que essa coisa toda funciona
  27. //
  28. assert(i == biggie_smalls);
  29. i = biggie_smalls;
  30.  
  31. //
  32. // ISSO NÃO FUNCIONA. É preciso haver uma atribuição para
  33. // que o compilador saiba qual o tipo
  34. //
  35. auto x; // <- error 12345: you really don't know how to use auto, do you?

Para quem programa em coisas tipo Haskell isso pode parecer óbvio. Mas já vi trocentas pessoas achando que isso é uma tentativa de transformar C++ em uma linguagem dinâmica. Então, só pra garantir:

A "nova" palavra chave auto NÃO TORNA O C++ UMA LINGUAGEM DINÂMICA. O tipo ainda é estático, você só não precisa informá-lo quando o compilador consegue deduzir isso sozinho.

Ah, isso é equivalente ao var do C# e igual ao funcionamento de declaração de variáveis da linguagem Go. E *não* é igual à declaração de variável em Python, Ruby ou Perl.

Mais um exemplo, e caso específico onde o auto é mais usado:

  1. using std::string;
  2. using std::map;
  3. using std::vector;
  4.  
  5. map<string, vector<string>> connections;
  6.  
  7. //
  8. // Como é hoje
  9. //
  10. for(map<string, vector<string>>::iterator i = connections.begin() ; i != connections.end() ; ++i)
  11. {
  12.  
  13. }
  14.  
  15. //
  16. // Muito mais fácil de ler.
  17. //
  18. for(auto i = connections.begin() ; i != connections.end() ; ++i)
  19. {
  20.  
  21. }

Em 28/11/2011 08:39 - Comentários (4)

Agora eu visto a camisa da empresa

Um post que gerou bastante polêmica foi o "Eu não visto a camisa da empresa". Em um emprego meu gerente contou que, quando um diretor resolveu me contratar sem consultá-lo ele imprimiu esse artigo, levou pra mesa dele e falou: "É esse cara aqui que você vai contratar?". O que eu acho ótimo. É mais fácil quando sabem das minhas opiniões antes de eu chegar. Economiza alguma discussões.

Durante muito tempo como programador peão de obra eu vi muitos gerentes cometendo erros crassos. Na realidade, como todo programador já sabe, a cada emprego que você passa você aprende sobre várias coisas que não deve fazer para ter sucesso em um projeto. Aprende-se muito mais o que não fazer. Conheci gerentes muito bons e projetos bem administrados, mas são, infelizmente, a minoria.

Depois de ver tanta besteira sendo feita comecei a me perguntar: será que é assim mesmo que as coisas funcionam e nada pode ser feito? Cheguei a cogitar que produção de software no Brasil é isso, uma grande bagunça onde a maioria dos gerentes e diretores são maus programadores que foram promovidos e não fazem a menor ideia do que estão fazendo.

Um belo dia, depois de anos recusando, resolvi aceitar um cargo de gerente de desenvolvimento, para ver se era realmente impossível fazer as coisas de uma maneira correta. Descobri: não é impossível. Não é fácil, mas tendo disciplina, método, e principalmente interesse, é possível. O que eu descobri é que as pessoas geralmente não se importam com isso. Elas se interessam pelo cargo, não pelo trabalho. Para virar programador eu li dezenas de livros. Quantos gerentes você conhece que leram ao menos um livro sobre o assunto? Além disso, os pseudo programadores recém promovidos costumam esquecer rápido que fazer a coisa certa envolve, no final das contas, dar condições para que os programadores programem, deixando-os distantes de políticas de empresa, não enchendo o saco por causa de horário e coisas estúpidas que todos sabemos que são estúpidas. Já escrevi sobre isso bastante (aqui, aqui, aqui), não vou repetir.

(Fim da sessão reclamação. Voltando ao assunto)

Depois de mais de 3 anos programando nas horas vagas, eu finalmente consegui juntar forças com um sócio não-programador e abrir um empresa de desenvolvimento de software para o mercado financeiro, a Intelitrader. Nosso foco é fazer software de alto desempenho e alta disponibilidade, basicamente o que eu tenho feito nos últimos anos. Mas dessa vez eu não preciso preciso explicar porque estou usando C++11, Python e até Assembly quando necessário. :-)

Abrir uma empresa de software é meu projeto de vida desde que tenho 15 anos (esses dias achei o adventure que eu fiz em 1995, com o "copyright" de STRAUSSoft). Aqui na Intelitrader eu tenho silêncio para programar em paz, e mesmo que eu tenha várias tarefas de dono de empresa, sou bem mais produtivo do eu era nos empregos por onde passei. E não é porque o lucro da empresa virá para o meu bolso. É porque meu foco é fazer software bom e com alta disponibilidade.

Como eu fiz quando virei gerente de desenvolvimento, vou tentar fazer aqui. Ver se, na prática, tudo que eu sempre preguei é possível. Sem horários (e com home office), sem regras de vestimenta (estou de bermuda no escritório nesse exato momento), sem frescura. Um lugar onde os escovadores de bits podem fazer o que mais gostam. E onde o importante é fazer software bom, rápido e fácil de usar. Se eu tiver disciplina e organização suficiente (tempo todo mundo tem), vou escrevendo minhas experiências aqui.

Pois é, agora eu visto a camisa da empresa. Por vários motivos. E o motivo principal é o fato de eu poder programar em paz por 4 horas seguidas quase todo dia. Isso não tem preço...

Em 16/11/2011 08:23 - Comentários (13)

C++11: Introdução

C++11 é a nova versão da linguagem C++, definida pelo padrão ISO/IEC 14882:2011. O fato de ser um padrão ISO traz a vantagem de nenhum fabricante ser "dono" da linguagem. Mas isso também cria um problema comum em qualquer coisa que é decidida por comitê: é necessário um consenso entre os membros para que algo seja adicionado ou modificado, e isso torna o processo sempre mais lento. O último padrão C++, por exemplo, foi de 2003. 8 anos depois, finalmente temos uma nova versão.

(Isso me lembra de quando fui a um Coding Dojo no Google Brasil. No final, todo mundo deve escrever as opiniões sobre o Dojo em papeizinhos, um para vantagens, outro para desvantagens. Foram inúmeras as reações de inconformismo quando leram o papel que eu escrevi com uma desvantagem: "Democracia demais".)

Mas a espera valeu. Todos os novos recursos foram bem, digamos, "azeitados", e o padrão já nasceu com vários compiladores implementando uma parte considerável dele (isso demorou bem mais no C++03). Além da vantagem de quem vem por último: você aprende com os erros e acertos dos outros (como Java, C# && Python).

Os principais objetivos do novo padrão, segundo quem participou das discussões de definição da linguagem e segundo eu mesmo são:

  • Facilidades de linguagens modernas: O melhor exemplo é a implementação de lambda, que, antes tarde do que nunca, chegou ao C++. Mas, por tardar e consequentemente aprender com os acertos e erros dos outros, temos em C++ a melhor implementação entre as linguagens mainstream.
  • Facilidade para ensino: Essa veio do Stroustrup (o criador da linguagem), que de uns anos pra cá voltou a dar aulas de programação para iniciantes. No último encontro de C++ me perguntaram qual seria a vantagem do C++11 para iniciantes. Não consegui dar uma resposta objetiva, além de citar o fato de que uma linguagem melhor acaba virando uma linguagem mais fácil.
  • Melhorias na biblioteca padrão: A STL já estava mesmo precisando de uma atualizada, e resolveu-se unir o útil ao agradável: com o tempo, as bibliotecas mais estáveis e bem aceitas do Boost estão sendo incorporadas à biblioteca padrão. O C++11 tem std::threads, std::shared_ptr, std::function, e inúmeras melhorias que vou detalhar em posts futuros.
  • Acabar com “gambiarras” do Boost: Não sei se esse era realmente um dos objetivos iniciais, mas eu gostei disso ter acontecido. Acho metaprogramação em C++ um negócio muito legal, mas exotérico demais. Boost Bind é algo extremamente necessário para programação assíncrona, mas 100+ erros de compilação por esquecer uma vírgula ou um _1 é de matar. E o Boost Lambda, convenhamos, é uma gambiarra que cresceu demais e aprendeu a falar. Com o recurso de lambda da linguagem se tornam desnecessários o Boost.Bind e o Boost.Lambda. Foi bom enquanto durou, mas não sentirei saudades.

Em breve, posts detalhando cada ponto. Enquanto isso, você pode como sempre, ler a extensiva lista de novidades na Wikipedia.

Em 03/11/2011 08:23 - Comentários (0)

Slides da palestra sobre C++11 no Oitavo Encontro de Programadores C & C++

Apesar do material já ter sido enviado para a nossa lista, outros programadores podem achar útil, então, lá vai:

Original PPTX

Em 26/10/2011 08:23 - Comentários (0)


Posts anteriores >>
rebarba rebarba
  ::::