Devaneando

Sobrecarga de função às avessas

1 year ago

by Wanderley Caloni in Devaneando

Navegando pelo Archive.org, que possibilita viajar no tempo e encontrar coisas enterradas que seria melhor deixar por lá, consegui encontrar um post que se perdeu na dobra espaço-temporal entre o old-fashioned Caloni.com.br (com direito à velha joaninha psicodélica, desenho do meu amigo t@z) e o finado CThings. No final, consegui matar a marmota, chegar a 80 milhas por hora e voltar para o presente. Enjoy it!

Alguém já se perguntou se é possível usar sobrecarga de função quando a diferença não está nos parâmetros recebidos, mas no tipo de retorno? Melhor dizendo, imagine que eu tenha o seguinte código:

GUID guid;
wstring guidS;
 
CreateNewGUID(guidS); // chama void CreateNewGUID(wstring&)
CreateNewGUID(guid); // chama void CreateNewGUID(GUID&) (o compilador sabe disso)

É um uso sensato de sobrecarga. Mas vamos supor que eu queira uma sintaxe mais intuitiva, com o retorno sendo atribuído à variável:

GUID guid;
wstring guidS;
 
guidS = CreateNewGUID(); // chama wstring CreateNewGUID()
guid = CreateNewGUID(); // chama GUID CreateNewGUID() (o compilador sabe disso?)

Voltando às teorias de C++, veremos que o código acima NÃO funciona. Ou, pelo menos, não deveria. Só pelo fato das duas funções serem definidas o compilador já reclama:

error C2556: 'GUID CreateNewGUID(void)' :
overloaded function differs only by return type from 'std::wstring CreateNewGUID(void)'

Correto. O tipo de retorno não é uma propriedade da função que exclua a ambigüidade. Apenas a assinatura pode fazer isso (que são os tipos dos parâmetros recebidos pela função).

Pois bem. Não podemos fazer isso utilizando funções ordinárias. Então o jeito é criar nosso próprio "tipo de função" que dê conta do recado:

struct CreateNewGUID
{
   // o que vai aqui?
};

Pronto. Agora podemos "chamar" a nossa função criando uma nova instância e atribuindo o "retorno" a wstring ou à nossa GUID struct:

guidS = CreateNewGUID(); // instancia um CreateNewGUID
guid = CreateNewGUID(); // instancia um CreateNewGUID. A diferença está no "retorno"

Uma vez que criamos um novo tipo, e considerando que este tipo é, portanto, diferente dos tipos wstring e GUID já existentes, devemos simplesmente converter nosso novo tipo para cada um dos tipos de retorno desejados:

struct CreateNewGUID
{
   operator wstring () { ... } // a conversão é a "chamada da função".
 
   operator GUID () { ... } // E como existem duas conversões... sobrecarga!
};

E isso conclui a solução meio esquizofrênica de nossa sobrecarga às avessas:

// instancia um CreateNewGUID e chama CreateNewGUID::operator wstring()
guidS = CreateNewGUID();
 
// instancia um CreateNewGUID e chama CreateNewGUID::operator GUID()
guid = CreateNewGUID();

Eis o fonte completo:

#include <windows.h>
#include <objbase.h>
 
#include <iostream>
#include <string>
 
using namespace std;
 
 
struct CreateNewGUID
{
   operator wstring ()
   {
      GUID guid = operator GUID();
      OLECHAR buf[40] = { };
      ::StringFromGUID2(guid, buf, sizeof(buf));
      return wstring(buf);
   }
 
   operator GUID ()
   {
      GUID guid = { };
      ::CoCreateGuid(&guid);
      return guid;
   }
};
 
 
 
int _tmain(int argc, _TCHAR* argv[])
{
   wstring guidS;
   GUID guid;
 
   // instancia um CreateNewGUID e chama CreateNewGUID::operator wstring()
   guidS = CreateNewGUID();
 
   // instancia um CreateNewGUID e chama CreateNewGUID::operator GUID()
   guid = CreateNewGUID();
 
   wcout << L"Pra nao dizer que esse exemplo nao imprime nada:\n"
         << guidS << L'\n';
 
   return 0;
}

Voltando à pergunta original: penso que, com criatividade e C++, nada é impossível =)

Vida e Software

1 year ago

by Wanderley Caloni in Devaneando

Fonte: semichaotic.spreadshirt.com

Desenvolver software está bem longe de ser uma ciência exata e muito próxima de ser uma ciência humana. Eu, pessoalmente, considero um ramo esotérico, onde vale muito mais ter a atitude de reconhecer que não temos muito controle sobre como as coisas funcionam do que querer ter as rédeas de algo desgovernado.

Não sei bem o motivo. Talvez por existirem muitas camadas o software não consegue ser normalizado como as propriedades físicas dos blocos que montam um prédio ou um transatlântico. Ou simplesmente existem variáveis demais na própria camada da aplicação que impedem a compreensão total do problema (como sabemos se estamos dentro da Matrix? Como o software sabe se está em um ambiente virtualizado?).

Para os piores casos, o software sempre vai ter que confiar em seu ambiente e as regras, aparentemente imutáveis, que o regem. Ele precisar confiar não o exime de controlar seus próprio limites, e é aí que recai a atitude do programador, atitude essa que reflete diretamente nossa visão sobre a vida.

Já vi muitos programadores (eu me incluo) deixando o código pronto para o melhor dos mundos e dando a tarefa por concluída. Otimismo demais? Desleixo? Ou arrogância? Qualquer que seja o motivo, ele está incrustado na própria visão de vida do programador e de como ele se vê no mundo. Eu, particularmente, fico horrorizado com código assim. Não com todos, mas com os que são visivelmente importantes e que necessitam de um carinho especial. São os alicerces para outros códigos, de repente.

Outra atitude igualmente deformada é achar que o mundo vai acabar se não existirem todos os sanity checks (até os mais bizarros) em qualquer meia-dúzia de linhas. É o paranóico, que pode se dar bem no tipo de código importante já citado, mas que nunca vai conseguir entregar um projeto trivial se for baseado em libs escritas pelos outros e cujo código nunca deu uma "lida rápida". Aliás, essa mesma atitude "deu uma lida" demonstra que o pessimista pode ser ainda mais arrogante, pois acredita conseguir capturar toda a complexidade do sistema apenas lendo seu código en passant.

De uma forma ou de outra, como toda atividade humana, escrever código nos define não apenas como bons programadores, mas como bons humanos, com seu conjunto de crenças e valores. O que, de certa forma, é um bom sinal, pois melhorando como seres humanos, melhoramos como programadores. E vice-versa.

Para devanear mais

Para quê filosofia? – Marilena Chauí

Reorganizando meus feeds (de novo)

2 years ago

by Wanderley Caloni in Devaneando

Depois da minha opinião dada ao Efetividade na matéria sobre ferramentas para gerenciar as leituras tenho que atualizar que não utilizo mais o esquema das estrelinhas, porque acabei me dando conta que nunca lia o que marcava para ler "depois".

Porém, ainda utilizo o Google Reader por uma série de motivos:

Integrado com as ferramentas Google, que eu venero;
Tem atalhos no teclado, que eu venero
Consigo anotar o que quiser em qualquer página que navegar;
Posso organizar os feeds por categorias.

Minha organização de feeds, até semana passada, usava categorias específicas (programação, cinema, economia) e tinha duas categorias no topo que organizava por frequência (diário, semanal), seguindo uma dica de um leitor do Efetividade. Porém, meu maior problema sempre fora os feeds que cospem milhares de entradas por dia, e que sempre ficava para ler no meu fim-de-semana, consumindo às vezes o dia inteiro!

Por isso, para evitar ser abarrotado de notícias, mantenho a seguinte organização de categorias:

Notícias: todos os feeds que cospem milhares de entradas. Organizo por "mágica" e leio apenas os que ficarem no topo. Ao final, clico no famigerado "Mark all as read" e fim de história.
Diário: leituras imediatas, que não requerem mais que cinco minutos, como a tirinha do Dilbert e minhas pesquisas cadastradas no Google.
Semanal: leitura um pouco mais demorada, para quando tiver mais que 10 minutos sobrando.
Amigos: todos os feeds das pessoas que eu conheço e acompanho.
Pessoal: meus próprios feeds, para reler o que eu escrevi e capturar "o outro lado da comunicação" (você, leitor).
Fóruns: mensagens do grupo de programação C++, por exemplo. Está no final da lista porque posso dedicar um pouco do fim-de-semana para ler a evolução dos tópicos, ou até colaborar quando tiver algum conhecimento a acrescentar.

Além disso, os Shared Itens estão configurados como Start page, sendo que tudo que eu anotar durante minha navegação deve ser lida quando eu abro o Reader (incluindo minhas anotações).

Basicamente é isso. Espero não ter que mudar novamente a estrutura. Se tiver, que seja pra melhor.

Idéias?

dia-a-dia leituras

Base64

2 years ago

by Wanderley Caloni in Devaneando, Programação

No meio dos meus artigos pendentes, encontrei esse, de Luiz Rocha, que fala sobre a dificuldade de entender o que seria Base64:

"Salve Caloni,

Já leio o seu site a algum tempo. Realmente acho complicado, alguns eu nem entendo =D. Mais eh o seguinte, eu estou montando um projeto, mas eu não entendo nada de trabalhar com binários. Então pesquisei na internet, e achei um algoritmo que pode me ajudar, na lógica. É o base64 mas eu não entendi como ele converte e desconverte em binário. Será que vc pode me ajudar, obrigado!!"

Não é a primeira pessoa que pede informações sobre algo específico demais para explicar (para isso existe a Wikipedia e o Google, não?). No meio da minha escrita, percebi que já havia escrito sobre os fundamentos do conhecimento por trás da criação do Base64, conhecimento esse, acredito eu, todo programador que quer sair do lugar com os próprios pés deve ter.

Básico do básico: assembly
Básico do básico: binário <-- Luiz, você está procurando por esse!
Básico do básico: tipos
Básico do básico: ponteiros

Bônus:

REALMENTE para iniciantes:

Acredito que tudo que um programador precisa saber é o básico. O problema é que esse básico cresce a cada ano, mas, de qualquer forma, continua sendo necessário voltar às raízes de vez em quando, e se existe algo que ele nunca deve esquecer, é isso.

Até porque na programação, 90% não se cria, se copia.

Imaginemos o cenário para a criação do Base64:

Alguns meios de comunicação, notadamente envio de e-mails e a navegação web, por incrível que pareça, trabalham em um protocolo totalmente em modo texto. É até fácil de entender, pois quando essas tecnologias nasceram as limitações de velocidade e estabilidade das conexões permitiam apenas o envio de texto puro de uma ponta a outra.

Isso quer dizer que, na prática, os anexos de um e-mail e as imagens de uma página trafegam, pelo protocolo definido, em modo texto.

Como isso é possível?

A solução não é tão obscura quanto possa parecer. Se um programador médio tivesse esse problema e nenhuma solução existisse ainda, ele faria o que sempre fez para resolver problemas desse tipo: codificar a mensagem na forma permitida. Isso já é feito com o próprio texto, que é apenas uma interpretação de tabelas de caracteres.

Tudo que é necessário fazer é o contrário, mas usando a mesma lógica: montar uma tabela de caracteres válidos e traduzir para um conteúdo binário, sendo que todas as combinações possíveis devem caber nessa tabela.

A forma mais básica binária de comunicação é um byte, constituído por 8 bits, que combinados darão 2^8 entradas em nossa tabela, que precisaria de 256 caracteres diferentes. Como isso ultrapassa o limite dos protocolos que estamos lidando, que em sua maioria utilizam a tabela ascii básica, que possui 128 posições, sendo que algumas posições não possuem caracteres imprimíveis, decidiu-se usar o múltiplo anterior: 64 posições, o que nos dá a chance de codificar 6 bits de cada vez (2^6).

Esse padrão de codificação se chama Base64. Se quiser mais detalhes, basta ler a RFC, que é pequena e muito simples de se ler.

Agora, como codificar essa solução? Só entendendo o básico, é claro.

Mudança

2 years ago

by Wanderley Caloni in Devaneando

Fecha uma porta...

Desde que comecei a programar profissionalmente, lá por volta de 2001, sempre estive envolvido com uma ou duas empresas de Segurança da Informação, na época uma promissora carreira, com direito a hacking, engenharia reversa e outras diversões. Até programar por programar valia!

O tempo passou, completei uma década na área, e agora está realmente na hora de tentar programar coisa nova. Dessa forma, acompanhando minha própria tendência de investidor pessoa física na bolsa de valores, resolvi dar um novo salto em minhas aspirações nesse campo igualmente fascinante e apostar meu tempo de programação também no setor financeiro, onde C/C++ também corre na veia.

Aprendi muito nesse tempo todo com alguns amigos entusiastas (até demais) e programei muito código que gostaria que não tivesse meu nome nos comentários. Mas a vida (e o código) é assim: melhora com os erros.

... e abre outra!

A empresa que estou deixando agora está à caça de uma pessoa para se tornar minha versão 2.0. Dessa vez não é uma busca por talentos inexperientes, de forma que estaremos aceitando apenas pessoas que já se f... com larga experiência em programação Windows.

Segue a descrição da vaga, feita por mim mesmo, sozinho. Interessados: sem timidez, please.

Analista Programador C++

Conhecimentos avançados em Windows: serviços, DLLs, (drivers desejável).
Programação: libc, Win32 API, (STL/Boost e Assembly 8086 desejáveis).
Ferramentas: Visual Studio 2003, Bazaar, VMWare, (WinDbg desejável).
Funções: codificação, análise, reunião técnica, refatoração, (UML desejável).
Perfil: vontade de aprender, pró-atividade, comunicação.

Devaneando

Para devanear mais

Fecha uma porta...

... e abre outra!

Analista Programador C++

Categorias

Tags

Blogroll

Meta