Programando Pedro

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

Em 2008, perguntei na ccppbrasil.org sobre uma boa maneira de produzir parsers incrementais. Dois anos depois, pude parar e estudar o manual do Bison o suficiente para descobrir ali o meu objetivo: push parsers . Este exemplo do manual é precisamente o que eu quero: int status; yypstate *ps = yypstate_new (); do { status = yypush_parse (ps, yylex (), NULL); } while (status == YYPUSH_MORE); yypstate_delete (ps); Meu objetivo é aplicar esta técnica para produzir o decodificador de mensagens de protocolo de aplicação em um servidor baseado em readiness-notification e non-blocking I/O.

Recentemente, o Fabiano Vasconcelos abriu uma discussão no Grupo de Usuários de C e C++: De cara eu vi algo aqui um pouco estranho, se que o amigo Márcio me permite comentar: que muitos programadores, inclusive eu (se que posso ser rotulado como programador) foram instruídos com o princípio de NUNCA usar o goto, por ser considerado um mau estilo de programação. Durante a discussão, o Eduardo Vieira puxou um artigo da KernelTrap sobre uma discussão similar ocorrida no grupo de desenvolvimento do Linux, onde Robert Wilken disse o seguinte: In general, if you can structure your code properly, you should never need a goto, and if you don't need a goto you shouldn't use it. It's just "common sense" as I've always been taught. Unless you're intentionally trying to write code that's harder for others to read. É preciso colocar a máxima "goto considered harmful" na perspectiva histórica adequada. Acredito que praticamente todo programador trein...

afe! Enquanto não rola um estudo retrospectivo maneiro, aqui vão minhas primeiras impressões. por mais que pareça andar de ré, tenha um porting para o sistema do desenvolvedor, onde a compilação não é cruzada; não exija frameworks xUnit e faça bilhões de programecos se necessário; guarde no coração que não é preciso reflection nem mesmo shared objects para aplicar dependency injection; não despreze a tediosa tarefa de testar parte a parte, pequena parte a pequena parte; não tenha escrúpulos para satisfazer dependências aleatórias com stubs. A maior revelação para mim nesse processo foram os pontos 2, 3 e 5 acima. Após um longo tempo digerindo o problema, e após diversas discussões sobre que framework de testes usar, por fim completei a tarefa da forma mais tosca possível: cada teste é um programa executável individual.  O projeto usa cmake para configurar a construção, e o ctest funciona legal com essa lista de programas de teste. O maior esforço nesse processo foi refat...