Programando Pedro

E se a interface do sistema de arquivos focasse primeiro nos arquivos e depois nos nomes, e não o contrário? Ao invés de criar um arquivo com nome tal, os programas primeiro criam arquivos, da mesma forma como alocam memória, e posteriormente criam ligações desse arquivo para locais na árvore de nomes. Um programa que criasse um arquivo mas nunca criasse ligações teria um arquivo temporário fatalmente destruído após o término do programa. Uma referência válida para o arquivo em um programa adquire o arquivo e portanto ele não pode ser destruído; transmitir essa referência a outro programa por interprocess communication  se torna uma forma de object remoting  paralela a shared memory . Isto evidenciaria melhor a distinção no sistema de arquivos entre os arquivos propriamente ditos e os nomes; no Unix, entre os inodes  e os paths . A interface de arquivos e a interfaces de nós na árvore seria logicamente associada porém claramente distinta. Esta distinção é útil a...

Cometi pela milionésima vez o mesmo erro e deixo este artículo na tentativa de impedir a próxima: não, não interessa se a operação overlapped diz que completou imediatamente, haverá uma completion packet esperando na completion port . Apenas ignore.

Chegou, então, a hora de ressuscitar um programa desenvolvido pelo fundador da empresa em um inominável sistema UNIX rodando em i386 no passado remoto. O programa, cujo sistema de construção permitia a configuração para inúmeras variantes do UNIX de então, permaneceu compilável com mínimas modificações até o Fedora 17. Impressionante. Infelizmente, ao executar o programa, segmentation fault a torto e a direito. Com a ajuda de um debugger , alcançamos a seguinte iteração, simplificada para este artigo: for (int i = 0; i < name_list_size; ++i) {   p = (char *) getenv(name_list[i]);   if (p != NULL)     if (*p != NULL)       strcpy(value_list[i], name_list[i]); } Simples, certo? O programa levantava SIGSEGV ao avaliar a expressão *p . Como é possível? Certamente getenv retorna um endereço válido ou NULL . Certamente p não é NULL quando avalia-se *p . Qual é o tipo de p ? char * p . Por acaso o programa está s...

 Um dos objetivos da próxima iteração no meu projeto atual é quebrar o sistema em mais pedaços, e levantar os pedaços um nível de abstração até componentes COM. Uma das consequências é substituir diversas ligações mais estáticas e torná-las ligações mais dinâmicas através do COM. Tipicamente, um programa usuário de um componente COM, escrito para o Visual Studio, usará a diretiva #import para incluir na unidade de tradução C++ as declarações necessárias. Isso implica que o componente deve estar instalado na máquina que constrói o programa. O que fazer quando o componente em questão está no mesmo lote de construção que o programa usuário? A solução inicial é criar uma dependência de construção tal que o componente seja sempre construído primeiro, e usar um post-build event ao projeto do componente para registrá-lo no sistema. Desse modo, na construção do programa, o ambiente estará correto. Eu considero este arranjo prejudicial. Minha melhor razão é esta: o servidor de const...

Investigando oportunidades para otimizar um componente, experimentei definir métodos que não solicitam dados (em arrays etc.) como argumentos mas sim instâncias de IStream , e me deparei com um problema interessante: interoperabilidade com .NET. Usar componentes COM em programas .NET não é particularmente difícil; no Visual Studio, é possível adicionar componentes COM como referências no projeto. Se o componente for capaz de Automation, é possível usar a ferramenta tlbimp.exe para gerar manualmente um callable wrapper para o componente, que, se eu entendi as coisas corretamente, não precisa ser distribuído com a aplicação. Porém, todos os métodos que eu aprendi tem essa peculiaridade: eles parecem assumir que um componente não usa interfaces definidas por outros componentes -- como, por exemplo, declarando parâmetros com tipo IStream , uma interface definida pelo sistema. Pelo método do callable wrapper , a ferramenta assume que as interfaces mencionadas integram o componente...

Infelizmente, eu caí na asneira de experimentar o Visual Studio 11 Developer Preview no meu sistema principal de desenvolvimento. O Developer Preview é razoável, e a presença dos testes de unidade para C++ me fizeram muito satisfeito. Porém, o Visual Studio 10 não funciona direito quando misturado com o Visual Studio 11 Developer Preview. O instalador do Developer Preview sobrescrever alguma configuração no sistema que é compartilhada com o 10. O primeiro efeito colateral que eu percebi foi nos projetos .NET, o que me levou a supor a natureza do problema. Projetos .NET começaram a indicar problemas nas referências a outros projetos -- com um ícone de exclamação em vermelho na tela de referências. A Internet me informa que isto é sinal de que os projetos ligados como referência são incompatíveis -- o referido indica uma versão do .NET mais recente que o referente. Minha hipótese é a de que o instalador do Developer Preview define, em algum lugar central, que o .NET 4.5 beta é a ...

Conversando com várias pessoas novatas ao longo dos anos, percebi que é muito difícil obter uma compreensão clara do que é a programação estruturada por falta de contexto. O material didático e os cursos afirmam a maravilha da programação estruturada ao organizar programas, enumerando problemas que ninguém mais tem, porque todas as linguagens de programação atuais são estruturadas. Como é possível comunicar a dificuldade de programar de uma forma que é, atualmente, impossível programar? Uma solução seria ensinar BASIC e então mostrar como é problemático escrever programas longos em BASIC, em comparação com Pascal. Porém, BASIC e Pascal são escrotas por sí só, sem qualquer relação com a presença ou ausência de estruturas. Ensinar programação não-estruturada com o intuito de redescobrir a programação estruturada não pode implicar mais dores que esta: manifestar o fluxo de controle apenas com goto. Me ocorreu, então, que esta é exatamente a solução: tomar uma linguagem de programa...