VidaGeek.net

Linux, Open-source, Programação e Produtividade

Archive for August, 2007

YACP - Definindo seus próprios tipos

C possui suporte a definição de novos tipos, o que torna o código muitas vezes mais legível e conciso. É possível criar esses novos tipos com typedef, struct, enum e union.

Typedef

Typedef serve para você mudar o nome de um tipo. Parece meio inútil mas na verdade ajuda muito com a semântica do código. Por exemplo, você decide que precisa de um tipo para guardar dinheiro. Float não serve, porque pode dar erros de precisão (faça o teste com R$0.30 . É uma dízima periódica em binário e pode gerar resultados estranhos). Então você percebe que se guardar o dinheiro contando os centavos (1 real = 100 centavos) você não vai ter problemas de precisão, pois você sabe que os postos de gasolina não podem colocar aquele terceiro digito depois da vírgula, pois não existe milésimo de real.

Então você vai lá e declara dinheiro como int. Pronto. Seu sistema funciona e você fica feliz, mas chamar seu dinheiro de int é meio feio e não faz muito sentido semanticamente. Como resolver isso? Você cria um novo tipo chamado dinheiro com o typedef:

Agora você armazena seu dinheiro em um tipo dinheiro. Muito mais legível, certo?

Struct

Struct é uma forma de você agrupar diversos tipos dentro de um único, e acessá-los de forma individual. Na minha opinião é o recurso mais poderoso para definição de novos tipos. É muito bom para juntar informações relevantes e colocá-las em um único lugar de facil manipulação.


Para acessar qualquer tipo que esteja dentro da struct, use o operador “.”:


E você usa como uma variável qualquer. Simples, não? Nem tanto. A sintaxe de declaração de uma variavel do tipo struct é meio chata. Você precisa dizer que aquilo é uma struct:


É aqui que entra a verdadeira mágica do typedef. Bem agora que você estava quase acreditando que a melhor utilidade do typedef é mudar o nome de um tipo primitivo.

Se você criar um tipo para representar “struct nome_struct”, fica bem mais fácil de declarar:


Geralmente isso já é feito quando declaramos a struct:


O resto é igual, mas você usa o nome real pra declarar.

Enum

Enum cria um tipo que pode apenas receber valores específicados durante a sua criação. Por exemplo:


Mas como isso funciona? Cada posição recebe um valor (a partir de 0 e incrementando para cada posição) e se você colocar um valor que seja diferente desses o compilador gera um erro (ou talvez um warning). O problema é que esse nosso tipo não tem nome e sempre que você for usar você precisa colocar toda essa linha de código para declarar uma variavel:


Novamente somos salvos pelo typedef:

A parte mais legal é que aumenta a legibilidade do código, pois é muito mais elegante você verificar se o mês é janeiro do que verificar se ele é 0.

Também é possível mudar o valor inicial do enum, atribuindo para o primeiro elemento um valor inteiro:

Union

Union é uma forma de você colocar diversos tipos em uma única variável. Um conceito interessante, mas que eu não vejo ser usado com muita frequência (Usei apenas uma vez e poderia ter feito de uma forma que evitasse isso). A sintaxe de declaração é bem semelhante à struct:

Já declarei com o typedef, mas se não tivesse feito isso, teria que escrever union antes da declaração, como acontece com struct.

Para utilizar, é basicamente como o struct. Possui apenas uma diferença (fundamental). Ela guarda apenas um dos valores por vez. Portanto, se você armazenar algo em m.i e depois em m.f, o valor de m.i será sobrescrito.


E cuidado com a leitura dos valores. Se você gravar em m.f e ler com m.i, você receberá um valor que não apresenta sentido, pois o union não faz conversão entre os tipos que você coloca nele.


A única vez que usei essa estrutura foi quando estava fazendo um leitor de arquivos .ini . Convencionei que poderiam existir apenas 3 tipos dentro do ini (string, inteiro e float) e criei um union para representar isso. Mesmo assim ainda precisava de 2 bits pra armazenar qual tipo eu tinha lido, porque o union não mantém essa informação.

Posts Relacionados:

  • YACP - Variáveis e Tipos Primitivos
  • Linguagens de programação - C++
  • YACP (Yet Another C Primer)
  • YACP - Condições Booleanas
  • Linguagens de programação - Smalltalk
  • Guia Latex - Parte II: O Básico
  • SNL - A Arte da Guerra
  • Assine nosso RSS feed!

    SNL - As Brumas de Avalon

    Acho que todo mundo já ouviu, leu ou assistiu alguma histório relacionada ao Rei Artur e os Cavaleiros da Távola Redonda. Você deve ter notado que o ponto de vista é sempre masculino. As mulheres, embora presentes, aparentam não ser responsáveis pelos acontecimentos no decorrer da história. Esse livro é diferente exatamente nesse ponto.

    “As Brumas de Avalon” (escrito por Marion Zimmer Bradley em 1979) conta as mesmas histórias sob o ponto de vista feminino, passando os homens para um papel secundário. Com isso, toda a estrutura da história é modificada, sem perder nada desse mundo fantástico.

    O primeiro dos quatro volumes é o melhor na minha opinião. Senti que a autora perde um pouco do rítmo no decorrer dos outros volumes, mas mesmo assim ainda é um dos livros que mais gostei de ler.

    Era um livro para o qual eu não dava muito valor, mas que surpreendeu-me muito. Para os que gostam desse tipo de história (Tradições Celtas) é realmente uma leitura imperdível. Para os que não gostam ou não tiveram muito contato, é um ótimo de jeito de conhecer melhor.

    Posts Relacionados:

  • SNL - SEO Book
  • SNL - O Diabo e outras histórias
  • SNL - A Arte da Guerra
  • SNL - Memórias, Sonhos e Reflexões
  • SNL - Ensaio sobre a cegueira
  • SNL - Guerra e Paz
  • Assine nosso RSS feed!

  • 3 Comments
  • Filed under: Dicas, Livros, Opiniao
  • Simpósio Brasileiro de Computação Musical

    Nos dias 1 a 4 de setembro, o IME/USP será sede do 11º Simpósio Brasileiro de Computação Musical.

    O evento será composto de palestras, apresentações de papers, workshops e eventos culturais, todas as noites, em locais variados da cidade de São Paulo, e os temas variam de Como o computador ajuda no ensino da música a um Processador que reconhece contextos harmônicos.

    Haverá, também, um workshop e uma palestra sobre Nyquist, uma linguagem de programação de som. Seu projeto pode ser visto no SourceForge.

    As inscrições vão até o dia do evento, mas o prazo para comprar com preço reduzido acabou em julho - antes da ampla divulgação do Simpósio. Os preços variam de R$120 a R$220, de acordo com a categoria. Para conferir os preços e fazer sua inscrição, saber mais sobre a programação, visite o site do evento:

    http://gsd.ime.usp.br/sbcm/2007/portugues/index.html.

    Posts Relacionados:

  • Antispam brazuca aberto
  • FISL 8.0: Wireless Meshing with OLPC
  • Um dia na vida de um programador azarado
  • ACM ICPC - Brasil na maratona de programação 2008
  • FISL 8.0 - Privacidade na Internet: um debate em aberto (Thiago Tavares Nunes de Oliveira e Demi Getschko)
  • SNL - A Arte da Guerra
  • FISL 8.0: Entrevista com Guilherme Silveira, um dos ganhadores da Arena
  • Assine nosso RSS feed!

  • 0 Comments
  • Filed under: Eventos
  • Ultimamente tenho ouvido falar muito sobre desenvolvimento orientado a testes (Test Driven Development). Uma grande vantagem dessa forma de produzir código é que você consegue garantir a consistência do seu sistema. Quando possuímos bons casos de teste, caso um bug seja inserido durante o desenvolvimento, identificamos o problema assim que rodarmos os casos de teste. Ou seja, trocamos dezenas de horas de debug por alguns segundos (ou talvez minutos) de testes rodando. Assim você acaba produzindo software em um tempo muito menor e provavelmente a qualidade do seu sistema será melhor também.

    Infelizmente não encontrei nenhum framework que facilite este tipo de desenvolvimento em C, mas é simples produzir um script (em bash, perl, ruby, etc) que rode seus casos de teste sempre que você quiser. O grande segredo é deixar tudo automatizado (rodar os testes, checar as respostas e avisar onde um possível erro está ocorrendo), assim você não fica cansado de ficar compilando seus testes manualmente para ver se o sistema funciona.

    Algumas dicas para quem pretende desenvolver utilizando testes:

    • Escreva seus casos de teste antes de escrever suas funções. Isso força você a pensar melhor em casos que podem quebrar o código que você ainda vai escrever, além de diminuir o número de testes viesados (que contém os mesmos erros que seu código, por exemplo).
    • Idealmente, teste todas as suas funções. Na prática isso dificilmente acontece, mas é o ideal.
    • Teste como suas funções se integram com as outras.
    • Teste como seus módulos se integram com os outros.
    • Para cada bug (que inevitavelmente ocorrem), crie um caso de teste para evitar que esse bug seja reinserido em modificações futuras.
    • Testes são seus amigos. Não modifique-os apenas para ver todos os testes passando. Só modifique-os quando for realmente necessário.

    Mais informações: Wikipedia

    Com isso encerro a série Dia C. Espero que tenham gostado.

    Posts Relacionados:

  • Testes unitários em C++
  • Os criadores do Skype atacam novamente…
  • Séries
  • Game Developers Conference
  • Digam adeus ao mouse
  • TDD para Ruby - Fibonacci
  • Desenvolvimento de jogos com o Morphic
  • Assine nosso RSS feed!

    Publicidade