Assinaturas padrão dos operadores de stream

Sempre esqueço da assinatura padrão dos operadores de inserção e remoção do C++. Então resolvi anotar aqui:

std::ostream& operator<<(std::ostream& s, const MyData& data);

std::istream& operator>>(std::istream& s, MyData& data);

Um exemplo de implementação do >>:


istream& operator>>(istream& s, MyDataEnum& data)
{
    int v;
    s >> v;
    
    if (s) //Conversion OK.
        data = MyDataEnum(v);

    return s;
}

Orientação a objetos

Prezados.

O preceito mais básico da Orientação a Objetos é ter dados e operações dentro da mesma unidade lógica (no caso, a classe). Isto também se diz da seguinte forma: Os objetos devem ser responsáveis por si próprios; eles é que devem realizar as operações sobre seus dados internos.

Outro preceito importante é o de encapsulamento de dados ou information hiding. É até anterior à OO, importante também em outros paradigmas de programação. Trata-se de não expor detalhes de como uma entidade é implementada; expor apenas a interface da entidade. Em OO, isto significa, ter poucos (idealmente, nenhum) dados públicos (no sentido semântico de públicos). Um excelente livro sobre programação que eu li, e agora me escapa qual, dizia a este respeito que devemos seguir o conselho ouvido na infância: "Don't show your private parts."

Perco as contas de quantas vezes vejo isto tudo ser deixado de lado. Por exemplo quando fazem algo assim:

class Horario

{

  unsigned hora;

  unsigned minuto;

public:

  unsigned getHora();

  unsigned getMinuto();

  void setHora(unsigned hora);

  void setMinuto(unsigned minuto);

};

main()

{

  Horario t0, t1, t2, t3;

  t0.setHora = 10;

  t0.setMinuto = 10;

  // um pouco mais de código, inicializando tn e fazendo sabe-se mais o que....

  // então imprime alguns t:

  cout << t2.getHora() << ':' << t2.getMinuto() << endl;

  cout << t3.getHora() << ':' << t3.getMinuto() << endl;

}

estão jogando no lixo os preceitos mencionados acima.

O information hiding foi pro vinagre, pois embora os membros não sejam declarados como públicos, semanticamente eles são totalmente públicos: usuários da classe podem fazer o que bem entenderem com eles... Os getXXX e setXXX geram o problema.

Além disso, o preceito básico da OO foi pro espaço também. Notem que as operações (inicialização e "impressão") sobre os objetos estão sendo feitas FORA do objeto (fora da classe).

Melhor seria algo como:


class Horario
{
  unsigned hora;
  unsigned minuto;
public:
  Horario(unsigned h, unsigned m): hora(h), minuto(m) {};
  string paraString()
   {/*converte para string no formato hh:mm, possivelmente usando ostringstream*/};
  //Eventualmente outras operações com Horarios, mas nada de getXXX ou setXXX
 };

main()
{
  Horario t0(10,10);
  Horario t2(5,11);
  Horario t3(23,55);

  // um pouco mais de código, inicializando tn e fazendo sabe-se mais o que....
  // então imprime alguns t:
  cout << t2.paraString() << endl;
  cout << t3.paraString() << endl;
}
Ou, para este caso de "impressão", usando um operador de inserção em stream:
 
class Horario
{
  friend ostream& operator<<(ostream& s, const Horario& h);
  unsigned hora;
  unsigned minuto;
public: 
  Horario(unsigned h, unsigned m): hora(h), minuto(m) {};
  //Eventualmente outras operações com Horarios, mas nada de getXXX ou setXXX
 };

ostream& operator<<(ostream& s, const Horario& h)
{
  s <<  h.hora << ':' << h.minuto;
  return s;
}

main()
{
  Horario t0(10,10);
  Horario t2(5,11);
  Horario t3(23,55);

  // um pouco mais de código, inicializando tn e fazendo sabe-se mais o que....

  // então imprime alguns t:
  cout << t2 << endl;
  cout << t3 << endl;
}

IMPORTANTE!!!!!! Nesta implementação acima, a classe e o operator<< devem estar no mesmo módulo. Ou seja, as declarações de ambas no mesmo .h (horario.h, por exemplo) e as implementações de ambas no mesmo .cpp (horario.cpp, por exemplo). Notem que quebramos um pouco do information hiding nesta implementação, já que o operator<< precisa acessar os dados privados da classe. Quer dizer, a classe não mostra as suas "partes privadas" para todo mundo, mas mostra para os "amiguinhos". Não é o ideal e não me agrada, mas até pode ser aceitável em algumas situações, desde que classe e operador tenham uma "união estável" bem forte e a classe tenha poucos "amiguinhos" (entidades friend).


Eu prefiro uma implementação que inclui o encapsulamento da paraString() e a conveniência do operador<<: Implemento o operator<< chamando o paraString(). Neste caso, a declaração de friend fica desnecessária.

As "Regras de Ouro" do desenvolvimento de software

1. Não se repita.
2. Não separe o que deve estar junto.
3. Não junte o que deve estar separado ou coisas que não estão relacionadas.
4. Guarde as coisas perto de onde elas são usadas.
5. Teste tudo que você faz. (O que você testa, funciona de primeira; o que você não testa, dá pau.)

Para quem se escreve o código-fonte?

Bom, todo (ou quase todo) software que escrevemos possui código-fonte. Mas quando estamos escrevendo este código quem devem ser os "leitores" a quem o dirigimos? Costumo dizer que a resposta dada por um programador para esta pergunta (e o quanto ele aplica a resposta na prática) definem o nível de habilidade deste programador.

Os programadores mais iniciantes ou tacanhos pensam que se deve escrever para que o computador entenda e isto basta. Programadores avançados sabem que se precisa escrever para outros programadores lerem. O que passa desapercebido é que devemos ser claros na nossa escrita e, para isso, devemos ter um vocabulário rico.

Em programação, muitas vezes se pode escrever operações ou expressões diferentes que levam a um mesmo resultado. Usar estas diferenças para expressar melhor o que o programa faz e como o programador pensou na solução é o que eu chamo de ter um vocabulário rico. Aumentamos o nosso vocabulário de programação do mesmo jeito que o de português: estudando, lendo bons textos (no caso, lendo programas), escrevendo com cuidado e pedindo para pessoas experientes revisarem nossos "textos".

Em programação, muitas vezes se usa o termo "idioma" para se referir às peças de vocabulário. Em outros artigos, vou dar alguns exemplos de idiomas em C++, procurando mostrar diferentes idiomas cujos resultados são idênticos para o computador, mas que dizem coisas diferentes para quem lê o código.

Isto me lembra de uma discussão recorrente que tenho com programadores: Eu dizendo "Isto está errado." e o programador respondendo "Mas funciona, logo está certo". Nem tudo que funciona está certo, justamente porque o código pode estar fazendo a coisa certa, mas dizendo a coisa errada. Ou seja, está escrito para o computador, mas não para os leitores humanos.

Vamos a alguns exemplos:

int some16BitVal;

sint_16 some16BitVal;

Mesmo que sint_16 seja um define ou typedef para int, a linha de cima está errada. Quando se escreve int, se está dizendo: preciso de um inteiro que seja o mais eficiente possível nesta arquitetura, mas não me importa o seu tamanho. Se precisamos de tamanho definido, o correto é expressar isto com um tipo.

Outra bem comum: Aproveitar uma constante para dois usos só por que, coincidentemente elas têm o mesmo valor. Se você usa uma mesma constante (e.g. const int mySize=33;) em vários pontos do código, você está dizendo que obrigatoriamente e irrevogavelmente todos aqueles pontos estão ligados e que mudando num todos tem de ser mudados juntos, mantendo todos sempre o mesmo valor.

Backup de blog

O comando

wget -e robots=off -E -H -k -K -p -r -l 1 http://lg-fotos.blogspot.com

parece fazer um backup completo de um blog.

"The miserable programmer paradox"

O artigo hoje não é meu. Este post é para apontar para um post de outrem.

Me enviaram o endereço the-miserable-programmer-paradox há alguns dias e no fim de semana consegui ler. Nada mais verdadeiro do que o que ele diz.

E uma grande verdade que todos os envolvidos com desenvolvimento de software deveriam aprender está escrita lá no meio: "A train of thought is a fragile thing". Programação e interrupções ao programador simplesmente não combinam. ;-)

Abraços e até o próximo.

Publicar postagem

Identificadores de versão

O assunto de hoje é identificadores de versão. Os famosos v1.0, v1.2.5.9, etc.

Todo mudo já viu estes números em software e a maioria acha que entende bem como funcionam e para que servem. Nem todos... Muitos tem uma vaga idéia; alguns tem uma idéia melhor, mas não sabem como incrementar cada campo e poucos realmente sabem qual a real utilidade destes números e quais são os mecanismos lógicos de avançar os números de versão de um software.

Vamos aos detalhes.

Primeiro, por que se tem números de versão? A resposta é simples: Para termos rastreabilidade do software em campo. E o que é isto? É se poder identificar de forma inequívoca qual versão de um programa um usuário estava rodando (por exemplo, para poder auxiliar o usuário ou reportar/corrigir um bug). Sabendo-se o identificador de versão (VID), deve-se ser também capaz de recuperar os arquivos fonte exatos que geraram aquela versão do software (provavelmente usando tags ou baselines de seu sistema de versionamento de fontes). Isto mostra que temos que garantir que nosso software nunca repetirá um VID, ou seja, se mudamos qualquer coisa no software, temos de mudar o VID.

Há várias estratégias e formatos de VID possíveis que garantem a rastreabilidade e alguns ainda dão indicações de compatibilidade entre versões do software. Eu vou explicar o mecanismo de 4 dígitos comumente usado, pois ele é simples de entender e amplamente difundido. Neste mecanismo, os VIDs têm a forma M.n.r.b ou M.n.r-b, onde M, n, r e b são números naturais (0, 1, 2, 3...). M é chamado de Major, n é o minor, r é o release (também chamado de patch level e abreviado como p) e b é o build.

Como queremos que qualquer mudança no software cause mudanças no VID, vamos incrementar o build number cada vez que buildarmos o software (ou seja, gerou os deliverables -- instaladores, executáveis, etc -- do software, incrementa o build number). Notem que o build number será incrementado SEM TER HAVIDO ALTERAÇÕES NOS FONTES! Alguns vão perguntar: Ué, mas sem alterações nos fontes, então nada mudou e não precisa mudar o VID... Errado! O tempo passou, a máquina em que o build foi realizado envelheceu (pode ter sofrido atualizações de software...), eventualmente até estamos buildando em uma máquina diferente. Ou seja, muita coisa pode ter mudado. Por isso, incrementa-se o build number e assim se tem certeza que não teremos duas cópias com mesmo VID e comportamento diferente. Notem que o processo de incrementar o build number pode e deve ser automatizado. O próprio conjunto de scripts de build ou ferramentas de build deve se encarregar de incrementar o build number, evitando esquecimentos. Detalhe importante: Mesmo que se mude de máquina, o build number tem de ir sempre crescendo, quer dizer, temos de bolar um jeito de que os scripts guardem qual o último build number usado em algum lugar compartilhado e o incrementem. A solução clássica é guardar o buil number (e o resto todo do VID) no repositório de fontes (sistema de versionamento de fontes).

E quando mudamos algo nos fontes? Bom, aí precisamos de um incremento em alguma parte além do build number. Se a alteração foi apenas uma correção de bug ou alteração interna, sem mudança nas funcionalidades do software, se incrementa apenas o release number. Ao incrementar o release number, se volta o build number para zero. Isto faz com que a seqüência de VIDs fique do tipo M.n.0.0, M.n.0.1, M.n.0.2, M.n.1.0, ...

Se houve alteração ou adição de funcionalidades, devemos incrementar o minor ou o major, dependendo do tipo de alteração. O minor é incrementado se podemos garantir que não houve quebra de compatibilidade na nova versão. Isto normalmente ocorre se só houve adições ao software e tudo que se podia fazer antes continua valendo (por exemplo, ler na nova versão os arquivos gerados com a versão anterior, executar as mesmas operações que eram possíveis anteriormente, etc).

Se ocorre quebra de compatibilidade, devemos incrementar o major number. Muitos recomendam também incrementar o major number quando houve muitas alterações no software, mas há que se olhar esta recomendação com certo cuidado, pois é difícil definir o que são "muitas"...

Resumindo a conversa:

• Os números de versão existem para permitir rastreabilidade. 
• Há muitos procedimentos (especificações) de como atualizar números de versão que funcionam, garantindo a rastreabilidade (e existem também alguns escritos por aí que não funcionam, portanto, caveat...). 
• Um mecanismo lógico possível de ser usado estabelece um identificador de versão de 4 números (major, minor, release e build) incrementados da seguinte forma:
• No mínimo o build number é incrementado sempre que se reconstroi o software.
• No mínimo o release number é incrementado se houve alterações nos fontes.
• No mínimo o minor number é incrementado se houve alterações de funcionalidade no software.
• O major number é incrementado se houve alterações no software com quebra de compatibilidade.

PS.: Se fala em "compatibilidade para trás" (backward compatibility). Para explicar este conceito, o melhor jeito é usando um exemplo. Imagine que você usa a versão 1.1 de um editor de textos para criar alguns arquivos. Logo a seguir, você instala a versão 1.2 deste editor e cria novos arquivos com ela. Se diz que há backward compatibility se a versão 1.2 do editor conseguir abrir sem problemas os arquivos da 1.1. O  contrário, ou seja, abrir os arquivos da 1.2 usando a 1.1 pode não ser possível, e, por isso, se fala em "para trás". No esquema de versionamento descrito neste artigo, alterações no minor number indicam que há compatibilidade para trás.

PS2: No caso das duas versões do software abrirem arquivos uma da outra, independentemente de qual é mais nova, têm-se compatibilidade total. No esquema de versionamento descrito neste artigo, alterações no release number indicam compatibilidade total.

PS3: O exemplo de abrir arquivos de outras versões é APENAS UM EXEMPLO DIDÁTICO para explicar o conceito de compatibilidade. Na realidade, todas as funcionalidades do software devem ser levadas em conta e cada tipo de software tem coisas diferentes a serem avaliadas. Exemplos: Uma biblioteca com backward compatibility significa que programas linkados com uma versão mais antiga vão funcionar com a mais nova; no caso de servidores, os clientes que sejam feitos para a versão mais antiga do servidor devem continuar funcionando com a versão mais nova; e por aí vai.

Abraços e até o próximo artigo.
LGM