Pedro sobre Software

Servidor e usuário COM na mesma "solution"

2012-02-09T15:40:00.002-02:00

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 construção principal é um Windows Server 2008 x86-64, onde o usuário que constrói não é membro do grupo Administradores.

Evitando debater essa opinião, caminhamos para uma alternativa. Apesar de #import ser a maneira mais fácil de usar o componente, a maneira básica de referenciar componentes (e interfaces) COM é através da IDL que os definem.

Desse modo, o desenvolvedor incluiria os arquivos IDL que definem o componente (e suas interfaces) no projeto do programa. Construir arquivos IDL é gerar arquivos .h e .c, que devem compor o programa como de costume.

Mas como lidar com um componente ainda em desenvolvimento, cujas definições em IDL estão ainda incompletas ou não são definitivas? É, no mínimo, um saco copiar os arquivos IDL para todos os programas usuários (que, no meu caso, são vários) a cada vez que esses arquivos são modificados. Por princípio, desejamos definir as coisas em um único lugar, e referenciar este lugar em todos os outros lugares onde as coisas são necessárias.

Como reusar arquivos IDL dessa maneira? Infelizmente, não é possível usar #import com arquivos IDL; além disso, não faz sentido usar #include. Arquivos IDL devem ser compilados junto com o programa, não incluídos diretamente em unidades de tradução C++.

A base da minha solução, com o Visual Studio, é incluir os arquivos IDL presentes no projeto do componente em todos os projetos usuários usando o comando Add Existing Item do menu Project. Este comando insere uma referência aos arquivos selecionados no lote de construção do projeto-alvo sem copiar estes arquivos.

Essa técnica não funciona para componentes definidos em múltiplos arquivos IDL que fazem referência uns aos outros através da diretiva import. (Não confundir!) O midl.exe provavelmente não será capaz de ajustar os caminhos de import para o novo contexto -- o local de construção do programa é diferente do local de construção do componente. O arquivo A.idl referencia "B.idl" mas este arquivo não existe no local dos fontes do programa, mas sim no local dos fontes do componente.

A solução para essa situação é ajustar a configuração Additional Include Directories na aba MIDL das Configuration Properties do projeto.

Com essa configuração ajustada, os arquivos .h e .c correspondentes às IDL serão criados no local dos fontes do programa, como desejado. Estes arquivos devem ser incluídos da forma costumeira na construção do programa. Novamente, a técnica não funcionará para componentes definidos em múltiplos arquivos IDL, devido a um desacordo entre o midl.exe e o Visual Studio. A configuração padrão produzirá, para Foo.idl, arquivos Foo_h.h; porém, no texto gerado pelo midl.exe, ocorrerá #include "Foo.h".

A solução para essa situação é ajustar a configuração Header File na aba Output, na aba MIDL das Configuration Properties para o valor $(Filename).h.

Com essa configuração ajustada, os arquivos gerados terão texto e nome corretos, e será possível compilar o programa. Aqui, um último problema pode surgir, caso o projeto do programa use PCH. Muito provavelmente, o arquivo PCH terá sido compilado como unidade de tradução C++. Porém, o midl.exe gera arquivos C e não arquivos C++. Não é permitido incluir PCHs C++ em unidades de tradução C. É preciso desabilitar PCH para todo o projeto, ou especificamente para os arquivos C gerados. Como fazer isso fica como exercício para o leitor.

Atenção: esta técnica permitirá ao programa incluir as declarações necessárias ao uso do componente; porém, as declarações disponíveis serão muito mais simples que o tipicamente injetado pelo #import. Sugiro o uso de ATL::CComPtr ou, se não for possível usar ATL, o uso de _COM_SMARTPTR_TYPEDEF.

Visual Studio 6: debugger vs. Unicode string

2011-03-25T13:32:00.000-03:00

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ê!?

Análise Sintática Incremental

2010-09-09T11:32:00.000-03:00

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.

Por que goto é considerado prejudicial?

2010-08-30T15:37:00.000-03:00

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 treinado nos últimos vinte anos aprendeu a programar com if e while. Essas são as estruturas básicas de programas e aparecem rapidamente nos manuais e nos cursos de programação. Toda linguagem de programação moderna tem if e while, e variantes como switch, for etc.

Essas coisas são chamadas estruturas de controle porque fazem exatamente isso: controlam a execução do programa, às vezes indo para uma sequência de sentenças, às vezes indo para outra, de acordo com testes explícitos. Arranjar um programa com sequências de sentenças, if e while é fazer programação estruturada.

Agora, a não ser que algum curso maravilhoso e desconhecido por mim tenha história da programação no seu currículo, este programador provavelmente não percebe que if e while nem sempre existiram e que a programação estruturada foi inventada mais ou menos na década de 70.

Durante a discussão no grupo de desenvolvimento do Linux, Scott Robert Ladd disse o seguinte:

Your attitude against "goto" is perhaps based upon an excellent but dated article, "Goto Considered Harmful", written by Edsger W. Dijkstra, and published by the ACM in 1968. (A recent reprint can be found at http://www.acm.org/classics/oct95/.) As you can tell from the date, this article predates modern programming languages and idioms; it comes from a time when Fortran ruled, and before Fortran 77 provided significant tools for avoiding spaghetti code.

e mais o seguinte:

Used over short distances with well-documented labels, a "goto" can be more effective, faster, and cleaner than a series of complex flags or other constructs. The "goto" may also be safer and more intuitive than the alternative. A "break" is a goto; a "continue" is a "goto" -- these are statements that move the point of execution explicitly.

Dijkstra, e outros, iniciaram a pequena revolta estruturada e assim ocorreu que diversas linguagens de programação introduziram novidades como if e while. Mas como é possível programar sem if e while?

Considere este fragmento:

char * i = input;
while (*i != '\0')
if (*i == SPECIAL) goto exit;
else ++i;
:exit
return i;

Este fragmento _não_ é o objeto da objeção ao uso de goto. Este fragmento exibe honrada programação estruturada. goto está ali como bem poderia estar break. Tanto faz.

Agora, observe este fragmento:

char * i = input;
:loop
if (*i == '\0') goto exit;
if (*i == SPECIAL) goto exit;
++i;
goto loop;
:exit
return i;

Isto é o que você deve evitar.

O objetivo do combate ao goto era combater a programação não-estruturada, e esse combate foi vencido com a introdução das linguagens estruturadas. Tais linguagens levam o programador naturalmente ao caminho certo e proíbem os maiores absurdos.

Existem linguagens em que o último fragmento acima era _a única alternativa_. (Ou coisa pior.)

Em retrospectiva, sabemos que a programação não-estruturada dominante na época causava um modo de pensar não-estruturado sobre os programas, de modo que o "spagetthi code" clássico era um único fluxo de instruções com gotos arbitrários para cima e para baixo, algo muito pior que o último fragmento acima, o tipo de código que eu não saberia construir artificialmente.

Se você conhece e pratica a programação de acordo com os bons princípios da programação estruturada, não precisa temer o goto. Existem diversas situações excepcionais às quais as estruturas de controle do C não se adequam perfeitamente; aquela que me ocorre com mais frequência são switches dentro de for quando é preciso terminar o for dentro de um case.

for (char * i = input; *i != '\0'; ++i)
switch (state)
{
case FOO:
/* many things */
break;
case BAR:
if (*i == SPECIAL) goto exit;
/* many things */
break;
}
exit:

Sempre existe uma maneira de remover o goto; nem sempre essa maneira é desejável. O goto acima, cujo label está exatamente na saída do laço, me parece uma parte bastante adequada da estrutura de controle. Java, que não possui goto, permite dizer "break exit", com exatamente o mesmo significado.

Durante a discussão no grupo de desenvolvimento do Linux, Robert Love disse o seguinte sobre a substituição do goto por outras estruturas:

As a final argument, it does not let us cleanly do the usual stack-esque wind and unwind, i.e.

do A
if (error) goto out_a;
do B
if (error) goto out_b;
do C
if (error) goto out_c;
goto out;
out_c:
undo C
out_b:
undo B:
out_a:
undo A
out:
return ret;

Now stop this.

Test Driven em C++ cross-compiled é possível

2010-07-06T23:07:00.000-03:00

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 refatorar o código o suficiente para conseguir testar uma unidade isolada realmente. A dificuldade percebida pela equipe desde o início era devido ao acoplamento entre as diversas unidades teóricas do sistema, e a quantidade de código de inicialização de coisas irrelevantes ao teste. Eventualmente tropecei na idéia de dependency injection. Apesar de ser algo que ocorre em super frameworks de componentes empresariais, o conceito é simples e se mostrou aplicável mesmo em um sistema ligado estaticamente, desde que as unidades fossem desacopladas o suficiente uma da outra. No nosso caso, isso se dá na forma de um Factory central para todo o sistema, pré-existente ao meu esforço.

Claro que esse desacoplamento "suficiente" é um graal e nunca ocorre, especialmente em um ambiente tão confortável quanto o da ligação estática -- onde tudo se junta no final numa grande sopa de elementos. Ocorreu que algumas funções que eram parte da unidade mas não eram exercitadas faziam referência a algum nome que acabava indefinido no programa final -- função ou variável extern. Eventualmente realizei que isso simplesmente não tem solução prática e aceitei a seguinte possibilidade: se uma unidade não compila sem uma função de outra unidade, e a função é irrelevante para o teste, vamos enfiar um stub na jogada e ponto final. De certa forma, isso pode ser considerado um Mock do mundo pré-componentização.

Acaba que, por fim, se não lindamente xUnit, meu objeto de manutenção agora possui uma suite de testes de unidade. Entre os vinte e trinta testes bem básicos que eu bolei pra começar, já descobri umas cinco funções implementadas diferente do que o meu projeto previa. O cmake suporta bem a lista de testes e gera um relatoriozinho bem legal.

C++0x vai mudar sua vida: listas de inicialização

2010-05-15T20:27:00.000-03:00

Com a nova sintaxe para listas de inicialização, é como se agora houvesse uma notação para o valor literal de praticamente qualquer estrutura de dados.

Observe meu teste de unidade construindo um "attribute template" PKCS #11 com std::vector direto na inicialização:

std::vector attributes
{
  CK_ATTRIBUTE { CKA_CLASS, &object_class, sizeof(object_class) },
  CK_ATTRIBUTE { CKA_TOKEN, &on_token, sizeof(on_token) },
  CK_ATTRIBUTE { CKA_LABEL, &label, sizeof(label) },
  CK_ATTRIBUTE { CKA_APPLICATION, &application, sizeof(application) },
  CK_ATTRIBUTE { CKA_VALUE, &data, sizeof(data) }
};

O segredo da notação está nessa pseudo-gramática:

type-name identifier { initializer-list };

que é análoga em significado a:

type-name identifier ( argument-list );

ou:

type-name identifier = type-name ( argument-list );