Programando Pedro

 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...

Gente, depois de uma eternidade de sofrimento para interpretar (TCHAR *) no debugger do Visual Studio 6, eu acabei de descobrir, nesse minuto!, que existe uma opção chamada "Display Unicode String" e que esta opção não está marcada na configuração padrão . Em Options, Debug. Você clica nela e o debugger mostra strings de wchar_t. Por quê!?

Este não é um deles. m_pSocket->Read(); // Leitura do dado pela classe

A palestra que dei no Sétimo Encontro do Grupo de Usuários de C e C++ do Brasil apresentou meu resultado atual na pesquisa de um framework baseado em uma forma de orientação a aspectos em C++ descrita no "Modern C++ Design" do Alexandrescu. Minha palestra não apresentou, porém, o que é exatamente o problema a resolver, assumindo que fosse razoavelmente conhecido. Seu foco foi apresentar todos os mecanismos disponíveis para se resolver o problema no Linux 2.6, suas peculiaridades e seus aspectos comuns. Uma certa razão me motivou, após esta apresentação, a rebobinar meu raciocínio e considerar o problema original. [1] O que há exatamente de tão problemático na gestão de I/O em um programa? A imagem inicial é a de um programa cujo objetivo é interagir com um dos dispositivos ligados ao computador. A forma básica dessa interação é a cópia de dados do dispositivo para a memória e da memória para o dispositivo, sendo que trabalho útil por parte do programa ocorre enquanto os...