Devido ao número enorme de spam tive que fazer com que somente comentários de usuários registrados sejam aceitos.
Estranho não ter uma opção para verificar se o usuário é real como uma verificação de imagens.(wordpress)
Em qualquer biblioteca gráfica 2D, jogo, framework de interfaces
gráficas, navegador internet entre outras coisas é necessário uma
forma de desenhar na tela.
Embora muito usada e nos mais diversos sistemas operacionais e tipos
de dispositivos não existe nenhuma biblioteca c++ padrão para suprir
esta necessidade de “como desenhar na tela” de maneira
multiplataforma.
Já na web com o HTML5 existe um elemento padrão chamado canvas.
Este canvas naturamente será seguido pelos diversos dispositivos afim
de possibilitar que navegadores web padrão sejam criados.
Desta forma o Canvas se torna um candidato perfeito para ser seguido como padrão
para uma biblioteca gráfica. Além disso, a documentação e exemplos
serão fartos.
Criei um projeto open source que cria uma classe de abstração de desenho
que segue a mesma interface do canvas definido no html5.
http://code.google.com/p/canvasplusplus/
Este projeto consiste em criar uma adaptação de interface para o objeto
nativo que implementa o desenho de forma que fique como o canvas.
Por exemplo, no Windows está sendo usada GDI. Poderá mais tarde ser usada GDI+ e Direct2D
em conjunto ou cada separada de forma que se possa trocar a implementação.
C é uma linguagem minimalista muito bonita que abstrai
o acesso ao hardware.
Ela é praticamente o assembly universal e tem grande mérito
por ter se firmado como tal.
Dito isto, não conheço nenhum programa de computador que
não exija abstrações além daquelas que existam no hardware.
Por exemplo, por muito tempo, não existiu o conceito de bool no C.
Claro, não existe um “bool” na memória então não era necessário.
Isso não significava que milhões de linhas de código em C não
estivessem artificialmente criando o conceito de BOOL TRUE/FALSE
com macros.
Isso só mostra como qualquer programa de computador faz este
mapeamento entre conceitos e comandos que o computador entenda.
Neste ponto entra o C++ com o propósito de fornecer uma linguagem
com suporte a vários estilos de programação e permitir o programador
uma abstração maior. Mas tudo isso com fortes restrições de eficiencia
e memória.
Neste aspecto, o C++ também se firmou como a única linguagem capaz de
proporcionar tal grau de abstração aliada com o nível de eficiência.
Enquanto o hardware seguir este modelo atual, qualquer tentativa de
criar
o assembly universal converge para o C, e qualquer tentativa de
adicionar
maiores abstrações sem perda de desempenho converge para o C++.
A genialidade da criação do C está em entender como conversar com os
diversos tipos de hardware. A genialidade do C++ está em como abstrair
conceitos que possam ser mapeados eficientemente para os mais variados
hardwares.
O C++ não é perfeito como linguagem, mas diria que é a melhor solução
dado os requisitos. É fácil criar uma linguagem melhor, mais simples,
que não tenha eficiência como restrição, porém é muito difícil criar
uma linguagem tão boa com as mesmas restrições.
A “briga” entre C e C++ é muito saudável para o C++, pois permite ao
C++ ter um parâmetro de eficiencia para uma solução “feita na mão” em
C.
No fim, tudo vai se resumir a comandos para o computador.
Objetos compartilhados com referencias ponteiros smart pointers..
http://www.thradams.com/codeblog/dullptrs.htm
Teste de performance comparando a passagem de parametros usando shared_ptr versus normal pointer
Existem vários casos importantes como casts e conversão para const aonde a performance cai bastante usando shared-ptrs.
Uma das causas mais comuns de erros e dificuldade de manutenção de código está relacionada com a falta de documentação e especificação dos efeitos nos operandos das funções. Isso ocorre especialmente em funções membro aonde o operando, além dos argumentos, é toda estrutura "this". O "output", ou seja, o efeito da função pode passar despercebido principalmente se não documentados. Por exemplo:
void X::DoSomething()
{
g();
f();
}
O resultado da modificação de estado da instancia de X depende de g e f. Não basta olhar para DoSomething. A falta de documentação obriga a inspeção de todas as chamadas de g e f. Além disso, na revisão, fica difícil saber qual é a verdadeira intenção do programador e confirmar se o código está de acordo com a especificação (que não foi dita).
Uma das maneiras de tornar o código mais claro é usar funções aonde o output seja explicito através de argumentos out e retorno da função. Então por exemplo, se g modifica o estado de uma variável m_var1 e f usa m_var1 e modifica m_var2, seria muito mais claro escrever:
void X::DoSomething() { int var1 = g(); int var2 = f(var1); m_var1 = var1; m_var2 = var2; }
Em resumo:
Deixe explicito e documentado qual é o objetivo de uma função e qual é a alteração que ela produz nos operandos.
Recentemente escrevi no twitter o seguinte:
Programming is like the movie Back to the Future. If you change old code, you can break the future. Even worst, new code also can break the past.
E agora com com mais espaço, quero escrever mais sobre isso:
Quando começamos uma nova classe ela nasce sem erros:
class x{};
O código compila, está perfeito e não tem erros.
Se um bug existir na classe X quer dizer que em algum momento durante o desenvolvimento ele foi introduzido.
Também quer dizer que é um momento em que a classe estava compilando, afinal para ver o bug quer dizer que o programa estava rodando.
Então por que não cuidar cada alteração compilável de forma que cada passo seja feito de forma segura?
A resposta é que isso é díficil, a complexidade vai aumentando como tamanho da classe. As dependências de estado internas e externas também aumentam.
Também existem momentos de instabilidade natural. Por exemplo, um TODO que está aguardando uma parte que não está pronta. Quando a parte A depende da B e a B depende de A, não é possível criar A e B simultaneamente. Pode ser preciso fazer A antes e testar as partes que não dependam de B. Ou deixar o comportamento um pouco diferente até que B esteja pronta.
O que ocorre então, é que não é fácil garantir que todos os incrementos anteriores na classe estejam seguros. Talvez uma modificação no futuro, quebre o comportamento de uma função que já foi testada.
Não é possível apenas criar pequenos incrementos, no desenvolvimento da classe é preciso revisar todos os estados e o código já criado que estava funcionando.
Então, por exemplo, para fazer a alteração de estado número 10 teriam que ser revisados as outras 9 modificações.
Essa influência do código novo sobre o código feito no passado é uma fonte comum de bugs.
Para melhorar a situação, é importante que as pré e pós condições estejam documentadas em cada função e que sejam usados ASSERTs para garantir isso.
Mesmo as pré-condições óbvias agora podem não ser no futuro.
Outra forma de melhorar este quadro, são os unit tests. Eles ajudam a testar se o comportamento anterior continua correto a cada incremento.
A todo o momento aparece uma nova linguagem de computador. Será que existe alguma evolução ou é apenas uma sintaxe diferente para se fazer a mesma coisa?
Se nós olharmos para o passado, é possível ver que não é a primeira vez que conceitos iguais são expressos de maneira diferente.
Para os números, por exemplo, existe o formato Romano e o Arábico que nós conhecemos bem, e além destes existem muitos outros inclusive com diferentes bases.
O mais usado sem dúvida é o Arábico, que apesar do nome, começou na Índia depois foi adotado pelos Persas e Árabes até chegar à Europa (daí o nome arábico) e depois foi espalhado para o resto do mundo com o colonialismo.
O sucesso desta representação se devia a sua simplicidade de uso e com certeza foi difundido pelas questões práticas do comércio.
Outras notações na matemática já sofreram modificações. O cálculo, por exemplo, foi inventado por Newton e Leibniz separadamente. Cada um tinha sua própria notação e nomenclatura. A notação de Leibniz que não é muito prática, mas tem uma doze de intuição é usada ainda hoje (dy/dx) a de Newton (y com ponto em cima) nem tanto. Lagrange também usou a notação f’(x) para se referir a derivada de f(x).
Muitos conceitos idênticos são representados de maneiras diferentes. Com o tempo uma das representações pode se tornar mais usada e muitas vezes as representações podem coexistir.
A ciência hoje em dia é feita por um número muito maior de pessoas comparada com a época de Newton e a facilidade para se criar e difundir uma linguagem de computador é enorme. Praticamente basta um compilador e internet.
Eu espero que estas linguagens de computador convirjam sua sintaxe para um número pequeno e comum de regras que já se mostraram eficientes, e que os conceitos comuns possam ser entendidos e compartilhados pelo maior número possível de programadores.
Acho que a computação carece de um padrão de comunicação mais exato, porém um padrão exato pode precisar de muitos detalhes e símbolos. Acho que vamos ter que criar sintaxes baseadas em contextos para evitar um número excessivo de símbolos.
Outra dificuldade comparada com a matemática é o fato das linguagens serem em formato ASCII. Então novos símbolos (desenhos e caracteres) não podem ser criados além do que tudo tem que entrar num formato linha e coluna.
Se o C++ não existisse, como poderia ser implementado o polimorphismo em C?
Código completo:
http://www.thradams.com/codeblog/cpoly.htm
Este código vai ter uma certa semelhança com um código gerado pelo compilador C++.
Uma das diferenças é que em C os tipos são opacos. São publicados apenas os handles.
Vendo esta implementação é facil perceber porque seria preciso um “C com classes”. Afinal é muita coisa gerada na mão e pouca checagem de conversões e tipos.
Para isso existe o C++.
Porém fica um sentimento de algo meio termo… e se eu tivesse o controle sobre o o typeinfo? Adicionar reflection?
E se o C++ fosse com tipos opacos?
Twiki é um wiki off-line que eu fiz e uso para manter minha página na web. (Veja post anterior)