Tumulto

Java vs. C#, uma perspectiva estranha

2009-11-03T19:55:00.002-02:00

Você pode achar o que quiser na disputa entre Java e C#, mas onde na documentação da Microsoft você vai encontrar uma afirmação tão direta, sincera e esclarecedora?

"Prior to Java 2 Standard Edition, JDK 1.4, the AWT focus subsystem was inadequate."

http://java.sun.com/javase/6/docs/api/java/awt/doc-files/FocusSpec.html

bug bizarro no RVCT 2.2

2009-10-29T15:13:00.002-02:00

Descobrimos um bug bizarro no RVCT 2.2 onde a compilação de uma chamada a um operador de conversão do std::auto_ptr gera as seguintes instruções:

1. push into stack from register
2. unconditionally jump to (1)

Alguém já viu isso?

C++ e puramente funcional

2009-09-18T17:27:00.002-03:00

Usando GCC 4.5, Dehydra e um script maroto, seria possível implementar uma verificação estática de que uma função é puramente funcional?

__attribute__((user("functionally_pure")) int foo_free_of_side_effects (int x, int y);

byte, address e dispositivos

2009-09-02T22:44:00.004-03:00

Suponha que você tem uma variante de C++0x onde existem apenas os tipos: byte, address e size. byte é uma sequência de oito bits, address é uma posição na memória e size é a distância entre duas posições na memória.

Com bytes você pode fazer bit shifting e outras operações próprias de sequências de bits; com address você pode navegar pela memória, obtendo sucessores e predecessores; com size você pode navegar pela memória a passos largos.

Suponha, além disso, que o programa tem à disposição um allocator que obtém pedaços de memória com tamanho fixo, e acesso a dispositivos por uma API razoável.

Que tipos de programa você poderia escrever?

Você poderia copiar dados de um dispositivo para outro:


void copy (device& in, device& out)
{
  const size length = allocator.page_size();
  address buffer = allocator.allocate_page();

  size n;
  while ((n = in.read(buffer, length)) > 0) out.write(buffer, n);
}

Você poderia copiar dados, criptografando com XOR:


void copy_and_encrypt (device& in, device& out, byte key)
{
  const size length = allocator.page_size();
  address buffer = allocator.allocate_page();

  size n;
  while ((n = in.read(buffer, length)) > 0)
  {
    for (address i = buffer; i != buffer + length; ++i) *i ^= key;
    out.write(buffer, n);
  }
}

Acredito que você poderia realizar praticamente todo tipo de criptografia apenas com operações binárias.

De onde um programa obteria a chave? De outro dispositivo de entrada, talvez.

Meu ponto é que nada disso está relacionado com aritmética em domínios numéricos; mesmo com a existência de size no programa, que é claramente uma "quantidade". Ainda é possível escrever programas interessantes mesmo sem a possibilidade de realizar aritmética com valores do tipo size.

Dualidade memória/dispositivo

2009-08-31T21:21:00.004-03:00

Ainda pensando sobre linguagem de programação e sistema, e na possibilidade de se projetar uma API de dispositivos apenas com byte e address<>, me ocorreram os seguintes pensamentos sobre a relação entre os dispositivos e a memória.

A memória é uma sequência onde ocorrem símbolos, na máquina binária contemporânea esses símbolos são bits e a unidade de armazenagem prática aos programas é o byte.

Além disso, na máquina de von Neumann, toda a operação do programa ocorre sobre a memória, inclusive operação sobre dispositivos, que ocorrem ao programa na forma de intervalos especialmente posicionados na memória.

Programas no sistema Unix, por outro lado, vêem dispositivos na forma de arquivos, com o qual trocam dados; o dispositivo é uma origem de dados e um destino de dados. A API fundamental de dispositivos é read e write. A realização básica de um arquivo é o próprio arquivo de dados, ocorrendo em um sistema de arquivamento.

É claro que o Unix, aplicando sua filosofia de simplicidade, exibe tudo como arquivo, inclusive todos os dispositivos; programas podem trocar dados com qualquer dispositivo representável em /dev. De fato, existe /dev/mem que reflete como um dispositivo a própria memória.

Por fim, borrando a distinção entre o que o processo de usuário vê e o que o sistema vê, existem os mecanismo de mapeamento em memória, que representam dispositivos (entre outras coisas) como intervalos de memória ao processo.

É fácil observar que a memória, fisicamente, e o dispositivo, abstratamente, são elementos e conceitos que se substituem e se sobrepõe. A noção de character device no Unix parece nascer exatamente daqueles dispositivos cuja natureza é a de um intervalo de átomos, um conceito cuja necessidade surge após a decisão de representar tudo como arquivos.

A união de memória virtual e o aspecto memória de um dispositivo ocorre no mecanismo de mapeamento em memória; no projeto de uma API de I/O assíncrono, a necessidade de expor páginas da memória de um processo ao driver do dispositivo para DMA também ocorre.

Programas sintonizados à API de arquivos frequentemente desejam comunicar a subprogramas dados em memória, e então a necessidade de um pseudo-dispositivo cuja representação é memória surge.

Tudo isso implica que o projeto de uma API de dispositivos é o projeto de uma API de memória, e todo projeto de um abstract data type dispositivo implica o projeto de um abstract data type intervalo-de-memória.

Que um aspecto ofereça melhor desempenho a um programa é função das necessidades desse programa. Programas que lêem arquivos frequentemente mapeiam este arquivo na memória e o lêem como um intervalo de memória. Programas que computam na memória o digest SHA-1 de uma informação frequentemente operam um pseudo-dispositivo onde escrevem blocos fixos de dados iterativamente.

Fundamentalmente, eis a questão: um dispositivo deve ser convertível para um intervalo-de-memória e vice-versa. O desafio é projetar tal API segundo todos os critérios de boas práticas realisticamente em um sistema.

Mudando de assunto, eis o projeto 9.1 do Elements of Programming:

"Modern computing systems include highly optimized library procedures for copying memory; for example, memmove and memcpy, which use optimization techniques not discussed in this book. Study the procedures provided on your platform, determine the techniques they use (for example, loop unrolling and software pipelining), and design abstract procedures expressing as many of these techniques as possible. What type requirements and preconditions are necessary for each technique? What language extensions would allow a compiler full flexibility to carry out these optimizations?"

Máquina de Turing

2009-08-25T21:30:00.002-03:00

Acho que atingi uma compreensão de como uma máquina de computação contemporânea cumpre os requisitos restritos da máquina universal de computação.

A máquina universal de computação é uma máquina que opera sobre símbolos ocorrendo um espaço unidimensional infinito. A máquina transforma seu estado de acordo com o símbolo atual; ela pode, por exemplo, avançar ou retroceder no espaço de símbolos, reescrever o símbolo em uma determinada posição, ou qualquer outra coisa.

A máquina se torna útil com a especificação do conjunto de símbolos representáveis e do significado de todos esses símbolos. Assim, um símbolo pode significar "avance três posições" e outro símbolo pode significa "substitua o próximo símbolo com o símbolo seguinte a esse, e vice-versa.

É claro que nenhuma máquina concreta terá acesso a um espaço infinito para símbolos; portanto, podemos falar sobre uma máquina universal restrita com espaço finito para símbolos.

Uma máquina universal binária é uma máquina cujos símbolos são 0 e 1. Uma tal máquina não pode significar muita coisa com apenas um símbolo, mas nada impede que significados especiais sejam atribuídos a sequências específicas de símbolos.

Assim, podemos falar sobre símbolos complexos, compostos por uma sequência de símbolos, que na máquina binária será uma sequência de 0s e 1s. A máquina binária possui portanto uma regra implícita: enquanto um símbolo complexo não for compreendido, ela avança para o próximo símbolo.

Quando um símbolo completo é compreendido, a máquina realiza a transformação especificada para aquele símbolo complexo.

É claro que, em uma máquina concreta, o número de símbolos complexos especificáveis é finito, já que os próprios símbolos complexos devem ser sequências finitas de símbolos fundamentais, e portanto existe uma combinação finita de tais símbolos complexos.

Mas um conjunto suficientemente grande pode representar todas as operações possíveis sobre uma memória sequencial de símbolos fundamentais, como: se o valor lógico do próximo símbolo complexo for verdade avance para a posição determinada pelo símbolo complexo seguinte a este, senão pelo símbolo complexo duas posições depois.

Isso é verdade porque, se podemos computar matemática fundamental, podemos computar qualquer coisa.

Tipos de dados primitivos 2

2009-08-21T14:10:00.003-03:00

Em C++, existe uma certa ambiguidade no significado dos tipos primitivos.

Tome char, por exemplo. char pode ser apenas char, pode ser signed char ou pode ser unsigned char. Mas char deve ser caractere, certo? Qual é o significado de um caractere ser signed ou unsigned? Nenhuma.

Existe, é claro, uma razão porque é possível especificar unsigned ou signed char; porque char é um valor inteiro de tamanho 1. De certa forma, char é o menor de todos os int, e foi projetado para ser usado como tal. Em uma máquina convencional, char é um inteiro de 8 bits. C99 na prática exige que char ocupe 8 bits.

Em C original, o ponteiro para char possuía a propriedade adicional de representar qualquer endereço válido de memória. Portanto, uma função que lê dados de um dispositivo qualquer para a memória aceitaria um parâmetro do tipo ponteiro para char significando o endereço de memória de um buffer.

É claro que isso provoca uma confusão com outro sigficado de ponteiro para char, a string de bytes terminada por NULL, ou NTBS. Por esse motivo, alguns programas e bibliotecas usam ponteiro para unsigned char para representar segmentos opacos de memória, como buffers de I/O.

Em C99, qualquer ponteiro é conversível para um ponteiro para algum char. Em C++ isso não é permitido. Em ambas as linguagens, qualquer ponteiro é conversível para um ponteiro para void.

Aritmética de ponteiro não é permitia para um ponteiro para void, infelizmente; programas que desejam atravessar a memória por qualquer razão devem usar ponteiros para char. Isso exige o uso de conversões por reinterpretação, como a notação de cast com parênteses, ou reinterpret_cast.

Existem aqui diversas necessidades diferentes. Uma delas é endereçar memória opaca, sem interpretação, e endereçá-la completamente. Outra é representar o menor valor inteiro possível na plataforma. Outra é representar um caractere. Outra é representar um segmento de texto.

Representar um caractere como o menor inteiro da plataforma é, hoje sabemos, uma ingenuidade, e existem diversas representações de caracteres que usam um número variado dessas unidades para caracteres, ou usam um número fixo de duas ou mais dessas unidades.

Assim, quando ocorre em um programa um caractere literalmente, como f, qual é a quantidade de armazenagem que o valor correspondente ocupa na memória? Depende da representação de caracteres usada no sistema alvo -- e naturalmente na unidade de memória da arquitetura alvo.

Eu não gosto dessa notação de signed e unsigned. Parece ter havido um problema original em que os ints tiveram de ser subitamente diferenciados entre inteiros e inteiros positivos. Não entendo como isso pode ter sido súbito, mas ainda não conheço bem a história da computação para saber como eram as máquinas quando C foi projetada. Me parece apenas que é um sistema de tipos obsoleto. As máquinas conhecem os naturais, ou inteiros positivos, representados em base 2 e conhece os inteiros representados em base 2 com complemento de dois.

Caracteres são um outro tipo de informação, distinto de números, apesar de logicamente relacionáveis -- a representação de um caractere é um índice em uma tabela.

Declarações, nomes e objetos

2009-08-18T11:06:00.002-03:00

Uma linguagem como C++ é chamada declarativa porque o elemento central de sua sintaxe é a declaração.

Uma declaração é uma construção sintática que associa um nome a um sujeito -- ou um identificador e um objeto. O caso simples é a declaração de uma variável.

Creio que um objeto é um ente totalmente abstrato do discurso, ao contrário do que a literatura sugere. Certamente podemos falar sobre o objeto e descrever suas propriedades; mas na máquina concreta, o significado de um objeto transita entre seus três aspectos fundamentais: seu valor, sua armazenagem e sua localização.

O tipo de um objeto, por princípio, corresponde ao domínio de seus valores. Assim, podemos considerar os dois tipos primitivos fundamentais que sugeri anteriormente, byte e address. byte é um pseudo-tipo para "o que quer que seja, armazenável na memória". address é o tipo do valor "localização na memória de um valor do tipo T". address é o tipo do valor "localização na memória do que quer que seja".

Em C++, a função de "o que quer que seja" é cumprida por char; char é a unidade de memória na máquina abstrata C++. A função de "localização na memória do que quer que seja" é cumprida em parte por void*, para o qual podemos converter qualquer T*, e em parte por char*, que garantidamente pode endereçar qualquer localização válida na memória.

Valores do tipo byte são apenas copiáveis; é possível, no mínimo, reproduzir o padrão de bits de uma armazenagem para a outra.
Valores do tipo address são copiáveis; além disso, o domínio de address é equivalente ao domínio dos naturais, e suporta a mesma aritmética; por fim, existe a operação de-referência, que transforma um valor address em um valor T.

Com esses dois tipos podemos fazer muito pouco, mas podemos fazer algo; é possível escrever um programa capaz de copiar dados de um dispositivo para o outro apenas com byte e address. Seria também possível escrever programas capazes de rearranjos e outras operações similares.

Esses programas não poderiam ser muito sofisticados porque os únicos julgamentos possíveis seriam sobre localizações de objetos, e não seus valores. Seria possível, por exemplo, escrever um programa que inverte uma sequência de bytes, etc.

Tipos de dados primitivos

2009-08-17T14:12:00.003-03:00

Após uma longa considerção sobre o assunto, e bastante tempo livre durante as férias, cheguei a uma opinião sobre que conjunto de tipos de dados primitivos eu gostaria de ver em Pedro C++.

A idéia de que há signed e unsigned como qualificadores distintos do tipo de dados não me parece muito coerente; um signed integer e um unsigned integer são valores em domínios completamente distintos. De fato, um unsigned integer é um natural, e foi essa intuição que me levou eventualmente a compilar a seguinte lista:

byte
address
natural
integer
rational
real
complex

Com os tipos primitivos byte a address seria possível escrever um sistema capaz de transportar dados entre dispositivos. Um tal sistema, ou sub-sistema, não tem interesse na representação de um dado; isso percebe-se claramente nas APIs de I/O do Unix, cujo tipo de dado é void*. Este tipo, em Pedro C++, seria um address.

Para a computação matemática pura temos a seleção completa de domínios algébricos. natural, integer e real são verdadeiramente primitivos, enquanto rational e complex são derivados destes. Em uma máquina convencional, natural é representado diretamente em base 2, integer é representado em base 2 por complemento de dois, e real é representado na forma dada em IEEE 754. Uma linguagem rica permitira que esses tipos sejam genéricos no tamanho; natural<16> é um natural ocupando dois bytes, integer<64> é um inteiro ocupando 8 bytes.

Deve ser possível, com base em natural, implementar qualquer domínio homomórfico com os naturais, como por exemplo caracteres em um mapa de caracteres.

É claro que nada disso é remotamente suficiente para uma linguagem na prática; é preciso ainda falar sobre muitas coisas muito simples, como a representação e o tipo de valores representados literalmente no programa etc.

NOTA: não tenho certeza se "homomórfico" foi a palavra certa ali em cima.

2009-08-11T10:58:00.003-03:00

Por que eu desejo escrever explicitamente sobre o ambiente de programação C++?
Por que existem documentos com frases assim:

To compile your programs, link with the C++CSP2 library. On GCC this can be achieved by using the "-lcppcsp2" option on the command-line.

Se eu tentar compilar o programa de exemplo deste documento seguindo essas instruções à risca ocorerrá o seguinte:

/usr/bin/ld: cannot find -lcppcsp2
collect2: ld returned 1 exit status

Por quê? Por que você não pode ingenuamente dizer quais bibliotecas você quer; o ambiente de ligação de programas com bibliotecas envolve a localização da biblioteca. Onde ela está?

Novo projeto: monografia sobre o ambiente de programação C++

2009-08-08T13:55:00.003-03:00

Como algumas pessoas sabem, um dos meus objetivos de mais longo prazo é projetar um sistema operacional em C++ e aplicar nesse projeto os métodos da orientação ao objetos, da programação genérica e da programação funcional.

Seria, é claro, ingênuo simplesmente acreditar que essa atividade é como programar uma variante do Unix convencional, meramente usando o compilador C++. A linguagem impõe requisitos muito mais interessantes sobre a ABI do sistema que C, uma linguagem simplória nesse sentido.

Assim sendo, comecei a estudar a questão da ABI do sistema e como C++ lida com ela, bem como o suporte ao mecanismo central da programação genérica em C++, os templates.

Tudo isso me sugeriu este novo projeto: escrever uma monografia sobre o ambiente completo de programação em C++, evidenciando detalhes ocultos ao programador, como a atuação do linker, do assembler, do compilador, do loader e mesmo de drivers de compilação como o make.

Quem sabe esse não será meu primeiro livro publicado?

Sigyn: componentes genéricos para networking

2009-08-01T00:47:00.001-03:00

Gostaria de anunciar o lançamento da biblioteca Sigyn.

A Sigyn contém diversos componentes genéricos para o desenvolvimento
de servidores de rede concorrentes. Ela também contém exemplos para
protocolos básicos como chargen e discard.

O código-fonte da biblioreca está disponível neste repositório
Subversion:

http://ccppbrasil.googlecode.com/svn/users/pedro.lamarao/sigyn

Documentação sobre a biblioteca está disponível aqui:

http://code.google.com/p/ccppbrasil/wiki/Sigyn

Pesquisando Sistemas Operacionais

2009-07-28T13:01:00.002-03:00

O iniciante em qualquer nova área de conhecimento sofre muito, na minha experiência, com as exigências transversais ao puro conhecimento que se impõe a ele.

O programador iniciante, por exemplo, sofre com a ferramenta de compilação, com o ambiente de compilação, com as peculiaridades do linker e do loader no sistema que ele está usando.

Da mesma forma, quem deseja iniciar uma pesquisa em sistemas operacionais deve lidar com problemas transversais aos algortimos de escalonamento e gerência de memória, como a singela atividade de bootar o kernel.

Reencontrei hoje uma ferramenta que me auxiliou muito nas minhas primeiras tentativas: o GRUB. Essa ferramenta não só facilita o processo de boot, resolvendo os problemas iniciais, como oferece ao kernel um protocolo de início muito similar ao protocolo de início da própria linguagem de programação, com uma função main.

O projeto GRUB vai além e oferece código-fonte em assembler e C para um kernel capaz de imprimir "Hello World!" de modo que qualquer programador minimamente determinado poderá iniciar seus estudos.

POSIX/C++

2009-02-28T16:38:00.003-03:00

No final de 2007, o IEEE aprovou a criação do projeto "POSIX-C++ Binding", com o propósito de aumentar a portabilidade de programas C++ que façam uso das interfaces de sistema especificadas em POSIX.

Este grupo de trabalho foi "fretado" inicialmente para entregar seu produto em Dezembro de 2011.

Discussões ocorrem em uma lista de discussão pública.

Os trabalhos iniciais envolveram a adequação da nova biblioteca de threads, componente da biblioteca padrão do C++0x, e especificar sua implementação sobre as interfaces de sistema especificadas em POSIX.

Dois outros projetos estão atualmente em discussão: bindings C++ para as interfaces de sockets, e bindings C++ para as interfaces do ligador dinâmico.

Eu estou trabalhando no projeto de bindings C++ para as interfaces de sockets; mais informações podem ser obtidas aqui. Meu trabalho está acontecendo sob a bandeira do Grupo de Usuários de C e C++ do Brasil.

Na próxima reunião do grupo de trabalho, dia 07 de Março, esses dois projetos serão tema da pauta de discussão. Infelizmente eu ainda não obtive um visto para participar dessa reunião; com sorte isso será possível.

O objetivo da binding para as interfaces de socket é basicamente produzir uma classe que aplique as técnicas de gerência de recurso em C++ no projeto de uma classe que represente um socket. Outros objetivos são melhorar a utilização das estruturas de dados representativas de endereços de socket, o uso de atributos de socket e das interfaces de tradução de nomes.

Ao longo deste processo se tornou claro que seria útil acrescentar às estruturas de dados simples especificadas em POSIX elementos como construtores e sobrecargas de operadores, para tornar mais simples e mais eficiente a inicialização de objetos destes tipos e sua operação.

Estou prestes a publicar agora meus primeiros trabalhos nesse sentido, na forma de uma modificação da GNU libc, usável com o GCC 4.4. Informações estão na mesma página mencionada acima.

Projeto Orientado a Componentes, parte IV

2008-05-08T14:57:00.006-03:00

Uma ligeira digressão, para aproveitar a oportunidade que se apresenta; apresentei esta semana um brevíssimo seminário sobre interoperabilidade entre C++ e Java (com ênfase na ferramenta SWIG).

O problema a resolver, quando a necessidade de interoperabilidade entre C++ e a Java surge, é exatamente um problema de projeto de componente, por uma via indireta: se não é tão necessária a garantia de substituição de componentes, é inescapável a completa separação entre a implementação do "componente C++" e do "componente Java" devido ao completo isolamento entre seus espaços de memória.

Esta mesma situação ocorre em um sistema convencional de componentes em que cada componente se localiza em processos distintos, ou mesmo em sistemas distintos, se comunicando através de algum mecanismo inter-processos. O próximo passo na escala evolutiva do projeto de sistemas, o projeto orientado a serviços, lida explicitamente com esta situação, já que se assume como normal que serviços se localizam em sistemas (portanto processos) distintos.

Esse contexto, e as restrições que ele impõe, transforma a natureza da troca de informação; a memória de um processo não é mais um recurso compartilhado entre rotinas.

Considere a seguinte função em C, parte de uma interface de componente IFoo. (O componente concreto Foo implementa a interface IFoo.)


  Foo*
  foo_retrieve_from_persistence (char* foo_name);

Esta função recebe uma NTBS identificando unicamente um objeto Foo na persistência e retorna o endereço do objeto Foo na memória, trazendo o objeto para a memória uma primeira vez se necessário.

Suponha que seja desejável, através de um programa Java, usar objetos Foo obtidos através desta função.

Do componente Bar, uma operação obtém uma referência a uma implementação de IFoo e decide chamar a operação foo_retrieve_from_persistence, passando como argumento uma NTBS. Observe que uma NTBS é uma referência a um espaço contíguo de memória; simplesmente entregar esse endereço para o componente Foo causará um desastre quando este componente resolver acessar esse endereço em seu próprio espaço de memória, cujo significado é incerto. Do mesmo problema sofre o valor de retorno da função; este é o endereço de um objeto na memória do componente Foo, cujo significado no espaço da memória de Bar é incerto.

Essa situação exibe a impossibilidade de tratar a semântica de referência, na travessia do limiar entre componentes, da mesma maneira como é tratada em projetos mais simples. Como já dissemos, não é possível assumir a memória como recurso compartilhado entre operações em um projeto orientado a componentes. [1]

A solução canônica é copiar esses valores. Esta tarefa deve ser realizado por aquele elemento do sistema que existe no umbral entre componentes e é responsável por transportar informação de um lado para o outro. Este elemento deverá, então, copiar todo o segmento de memória endereçado por foo_name da memória do componente Bar para a memória do componente Foo. Esta atividade se denomina "data marshalling" em um certo vocabulário e regras particulares de "data marshalling" são chamadas "type maps" em um certo outro vocabulário.

Este é um exemplo simples de "type map" que transporta um objeto String do Java para um argumento de tipo const std::string& do C++.


  // na prática, estes objetos são argumentos de uma função JNI.
  extern JNIEnv* jenv;
  extern jstring jargN;

  // type map
  const char *argN_pstr = (const char *)jenv->GetStringUTFChars(jargN, 0);
  if (!argN_pstr) return 0;
  std::string argN_str(argN_pstr);

A função GetStringUTFChars realiza a tarefa concreta de copiar os segmentos de memória do espaço de memória Java para o espaço de memória C++. Assim, a operação da interface de componente Java/JNI terá a seguinte forma:


  public static native jlong foo_retrieve_from_persistence (String foo_name);

Essa solução, infelizmente, não resolverá o problema do valor de retorno da função. Foo não é um tipo primitivo da linguagem; não existe uma função na JNI para copiar objetos Foo. Mesmo que existisse, Foo é um objeto; o que nós queremos fazer com ele é chamar suas operações. De certa forma, nossa vontade se divide em duas: expor ao programa Java as operações da classe Foo e expor ao programa Java objetos Foo sobre o qual operar. Essas duas necessidades serão resolvidas com mecanismos diferentes.

Digamos que esta seja a classe Foo.


class Foo {
public:

    Foo (char* name);

    char*
    ask_question (char* question);

    char*
    get_name () const;

};

A primeira vontade é realizável produzindo, para cada operação de Foo, uma operação na interface do componente IFoo.


    Foo*
    Foo_new (char* name);

    void
    Foo_delete (Foo* foo);

    char*
    Foo_ask_question (Foo* foo, char* question);

    char*
    Foo_get_name (const Foo* foo);

A segunda é entregando ao programa Java o endereço do objeto Foo necessário. Chegamos, aparentemente, a um impasse; já que nosso problema original era justamente como transportar o valor de retorno da função foo_retrieve_from_persistence, que é do tipo Foo*! Porém, tendo caminhado até aqui, o problema se torna ligeiramente diferente, e uma solução é possível. Agora que nós temos todas as operações de Foo que desejamos exportadas pela interface de componente IFoo, tudo o que resta é entregar ao componente cliente uma referência opaca a um objeto Foo. O componente cliente da interface nunca necessitará resolver (ou de-referenciar) esta referência; ele apenas mantém este valor para usá-lo como argumento de chamada a uma operação da interface IFoo. [2]

Endereços de memória do C++ podem ser guardados apropriadamente na memória do Java como um valor do tipo Long. Assim, o valor de retorno da operação Foo_create é resolvido pelo seguinte "type map":


  // este é o objeto retornado pela chamada JNI
  jlong jresult = 0;
  // este é o objeto retornado pela função C++
  Foo* result = NULL;

  // type map
  result = new Foo(arg1_str); // vide type map anterior
  *(Foo **)&jresult = result;

  // por fim...
  return jresult;

e a operação na interface de componente Java/JNI terá a seguinte forma:


  public static native jlong Foo_create (String name);

Assim, o programa Java chamador de Foo_create através desta interface receberá um valor Long que contém o endereço, na memória do C++, do objeto Foo recém-criado. A operação Foo_get_name através desta interface terá a seguinte forma:


  public static native String Foo_get_name (jlong foo);

sendo que o valor de retorno da operação Foo_get_name do componente IFoo será "marshalled" pelo "type map" como já vimos anteriormente.

Havendo resolvido o problema da possibilidade de referenciar, de maneira opaca, um objeto Foo da memória do C++ na memória do Java, e o problema de chamar operações da classe Foo em C++, podemos então criar uma classe Foo em Java cujo único propósito é imitar a classe Foo em C++ por conveniência.


class Foo {

  private Long cPtr;

  // @Override
  public void finalize () {
    delete();
  }

  public void delete () {
    IFooJNI.Foo_delete(cPtr);
  }

  public Foo (String name) {
    cPtr = IFooJNI.Foo_new(name);
  }

  public String ask_question (String question) {
    return IFooJNI.Foo_ask_question(cPtr, question);
  }

  public String get_name () {
    return IFooJNI.Foo_get_name(cPtr);
  }

};

Desta forma concretizamos uma forma ideal de interoperabilidade entre Java e C++ onde, para cara classe C++, há uma classe Java equivalente, responsável por esconder as chamadas à interface de componente JNI que, por sua vez, é responsável por realizar o transporte de informação através do umbral dos componentes.

Nestes exemplos ocultamos o fato de que, para a JNI, é necessário não somente um componente Java/JNI mas também um componente C++/JNI além do próprio componente que implementa a interface IFoo; também não lidamos com os casos em que registramos "objetos callback" criados no Java em sistemas C++; não lidamos com a vontade de transportar exceções disparadas em C++ de volta para o chamador Java; entre outras coisas de que não falamos.

[1] É claro que um projeto pode se utilizar da noção de componentes de uma forma restrita, para obter um conjunto restrito de benefícios, abandonando esta restrição; é possível, por exemplo, obter os benefícios de recompilação veloz e carga de código por demanda abandonando a possibilidade de distribuir os componentes de modo a mantê-los sempre no mesmo espaço de memória e permitir o uso convencional de ponteiros.

[2] Em projetos de sistemas com componentes é comum que esta idéia do "endereço opaco" seja generalizada para qualquer tipo de informação "opaca" que seja capaz de identificar univocamente um objeto de Foo no domínio do componente Foo; por exemplo, um "nome", ou um GUID, ou outra coisa qualquer.

Projeto Orientado a Componentes, parte III

2008-04-29T22:57:00.006-03:00

Agora, uma pausa para reflexão. Esta dicotomia interface versus implementação é difícil de definir. Por baixo dos panos nós temos memória de onde nós lemos e para onde nós escrevemos. O que caracteriza uma interface e o que a distingue de uma implementação?

Essa pergunta só pode ser respondida em um determinado contexto. Um bom sistema escrito em assembler talvez tenha interfaces mais bem definidas que um mau sistema escrito em Java. Porém, está claro para a indústria que certos mecanismos de linguagem favorecem o estabelecimento de boas interfaces no sistema implementado.

Além disso, a noção de interface surge diante de um problema de substituição. É interface aquilo que, mantendo-se estável, permite a substituição daquilo que é implementação. Porém, o que é este permite? Este permite, quando caracterizado, por conseguinte caracteriza o que é interface.

Suponha um sistema escrito em C++ por uma equipe que considera irrisório o tempo de recompilação do código-fonte. Neste contexto, podemos seguramente aceitar que a seguinte substituição mantém estável uma interface.

antes


class Foo {
public:

Foo ();

void
mutate_stuff ();

int
observe_stuff () const;

private:
Bar* m_bar;
};

depois


class Foo {
public:

Foo ();

void
mutate_stuff ();

int
observe_stuff () const;

private:
int m_cache;
shared_ptr<bar> m_bar;
};

Após a alteração acima e uma recompilação o sistema continua a funcionar normalmente. [1] Dizendo de forma mais extensa: neste contexto, a substituição realizada não altera propriedades observáveis externamente da classe, de modo que do ponto de vista de um observador, a classe mantém estável sua interface. (Apenas membros privados foram alterados.)

Agora vamos alterar as nossas premissas. O tempo de recompilação desse sistema é enorme e o ciclo de testes não pode esperar, de modo que a estrutura de classes do sistema foi particionada e esta classe mora dentro de um objeto compartilhado, uma biblioteca dinâmica.

A equipe realiza a substituição, recompila o objeto compartilhado e o entrega a uma equipe de testes.
E os testes falham miseravelmente.

Isto acontece porque, neste novo contexto, há mais propriedades observáveis a considerar, que devem se manter estáveis -- que fazem parte da interface da classe.
Neste caso, o layout de um objeto da classe Foo é uma propriedade observável; um programa compilado criando objetos da definição antes criará objetos com um layout diferente daquele esperado pelo objeto compartilhado que espera objetos dada a definição depois.
A definição depois tem um int no offset onde a definição antes tinha um ponteiro, ela ocupa mais memória etc.

Podemos dizer que o primeiro caso é o caso de um projeto orientado a objetos, onde a alteração de elementos privados da classe não altera a interface; e podemos dizer que o segundo caso é o caso de um projeto orientado a componentes, onde a alteração do layout na memória de uma classe altera sua interface.

Como no segundo caso nós estamos violando a interface do componente, nós não podemos substituir o componente de antes pelo componente de depois impunemente. Dito de trás para a frente, pelo fato de não podermos substituir o componente de antes pelo componente de depois, por definição estamos violando sua interface.

Imagine então o que acontece em um sistema spaghetti, onde todas as classes mantém referência a todas as outras classes; uma violação de interface em um "componente" perturbará implacavelmente todos os outros "componentes".

Quando projetamos um sistema pensando em componentes, ou quando desejamos aplicar a idéia forte de interface para melhorar o nosso projeto diminuindo o acoplamento entre as coisas que são distintas, é útil usar das ferramentas à disposição para dar forma ao que é uma interface.

Linguagens que se propõe a facilitar o desenvolvimento de componentes, como Java e C#, possuem como parte integrante do seu vocabulário e mecanismo nativo uma interface em contraste com as classes. Normalmente algo do tipo:


interface IFoo {

void
mutate_stuff ();

int
observe_stuff () const;

};

Em C++ não existe uma construção análoga mas é possível emulá-la integralmente usando classes, da seguinte maneira:


class IFoo {

virtual
void
mutate_stuff () = 0;

virtual
int
observe_stuff () const = 0;

};

(O leitor astuto observará que esta construção-interface não possui atributos.)

O propósito de usar construções como estas é evidenciar a natureza destes elementos como interfaces -- aquilo que se deseja manter estável -- e diminuir a chance disto que é interface ser inadvertidamente alterado -- causando o desastre. A construção-interface é a melhor amiga do projetista de componentes, permitindo a representação de um conceito de projeto diretamente na linguagem do código-fonte, restringindo as possibilidades de violação durante o processo de implementação, ou ao menos tornando a (necessidade de) violação claramente evidente.

Infelizmente para nós nem tudo que existe na fronteira de um componente pode ser uma interface, já que é preciso comunicar coisas de um componente para outro. E quem pode viver comunicando apenas doubles e bools? Nós queremos comunicar objetos.

Além disso, as construções-interface não são garantia de estabilidade de interfaces, já que há mais sobre o que é publicamente observável em um objeto que sua estrutura: há o seu comportamento.

[1] Estamos, naturalmente, assumindo que o programador não é louco e que a alteração tem algum sentido, exatamente como aparenta ter.

Projeto Orientado a Componentes, parte II

2008-04-28T22:36:00.005-03:00

Quando dizemos que componentes são por definição intercambiáveis estamos continuando uma longa tradição de bons projetistas de bons sistemas, cujo conjunto de características sempre integrará, por mais sofisticada a metodologia e/ou a nomenclatura, a aplicação da separação entre interface e implementação. [1]

Se a interface continua a mesma, podemos substituir a implementação sem perturbar o comportamento do sistema. Obviamente que o comportamento do sistema deve mudar de alguma forma, senão trocar a porcaria do componente não teria propósito. Esperamos, portanto, que erros sejam corrigidos (de modo que o sistema de fato funcione como deveria), ou que o desempenho aumente (de modo que o sistema funcione antes que eu caia no sono) ou sei lá.

Aplicávamos esta distinção já na era do projeto estruturado; e no projeto essencial; e no projeto orientado a objetos; e agora no projeto orientado a componentes e aplicaremos no projeto orientado a serviços quando finalmente este troço alcançar a plebe.

Em um sistema orientado a objetos, nós temos tipicamente dois elementos em evidência como detalhe de implementação: a estrutura de um objeto, e as instruções levadas a cabo por seus métodos. Nós queremos liberdade para alterar a estrutura de um objeto e queremos liberdade para alterar a instruções executadas por seus métodos. (Há mais por debaixo do pano, como sempre.)

Em um sistema orientado a componentes, um terceiro elemento surge ofuscando, como se fosse, os outros dois; o componente propriamente dito. Entendemos que um componente possui uma interface e uma implementação; sendo a implementação de um componente composta por inúmeras classes. Além disso, um componente é um artefato componente (heh) de um sistema implantado; é parte da definição de componente que este seja intercambiável por um outro, que implemente a mesma interface, em um sistema implantado -- em contraste com um tipo de substituição que exige recompilação.

Esta última restrição, quando posta no contexto dos sistemas operacionais reais, com seus linkers e loaders reais, nos trás à crux do problema de projeto orientado a componentes: a implementação de uma classe integrante de um componente absolutamente não pode depender de um detalhe de implementação de uma classe integrante de outro componente.

Observe que esta restrição não é exatamente uma novidade, já que bons sistemas isolarão módulos através de interfaces para aumentar a coesão e diminuir o acoplamento; porém, quando componentes entram na jogada, a metodologia exige uma restrição mais forte.

(De fato, esta restrição metodológica se torna uma impossibilidade tecnológica assim que os componentes são levados ao próximo estágio, passam a não mais morar no mesmo espaço de memória virtual, e começam a ser chamados "distribuídos" ou "serviços".) [2]

É por esta razão que os líderes do Projeto Spaghetti falharão em "componentizar" seu sistema; mesmo que, à primeira vista, seja possível seccionar sua estrutura de classes em artefatos binários distintos.

[1] Nós, filhos da cultura européia, nem escrevendo programas nos livramos da dicotomia corpo versus espírito. Nem imagino o que seria uma metodologia de desenvolvimento de sistemas desenvolvida por monges taoístas chineses.

[2] E portanto, domar a restrição metodológica significa poder conviver com a impossibilidade tecnológica e eventualmente programar os sistemas do futuro.

Projeto Orientado a Componentes, parte I

2008-04-28T21:34:00.002-03:00

Ano passado fiz um curso de extensão em Projeto Orientado a Componentes com UML; na época, eu estava progredindo na minha capacidade de construir modelos mentais de projetos de software orientados a objeto e já havia lido bastante sobre web services e arquiteturas orientada a serviços.

O mais interessante sobre os Componentes é a maneira como eles dão um nó na sofisticação aparente dos sistemas e obrigam o projetista a voltar aos básicos. Digo isso porque estes sistemas são aparentemente sofisticados; na prática, eles apresentam baixa coesão e alto acoplamento, significando que elementos deste sistema se relacionam diretamente com praticamente todos os outros de maneira ad hoc, fenômeno que, em sua forma mais concreta, denomina-se código spaghetti.

É possível construir um sistema orientado a objetos onde todos os objetos conhecem ponteiros para todos os outros, ou praticamente todos os outros, usando truques safados como embrulhar todo mundo em shared_ptr e tornando todas as classes enable_shared_from_this e olerê olará. Isto, é claro, se você tem um mínimo de conhecimento sobre C++ contemporâneo -- e se você está de fato escrevendo seu sistema em C++! -- e se você se importa com a memória. O sistema acima é "orientado a objetos". Muitos deles, embolados entre si.

Quando você se propõe a fazer sistemas orientados a componentes, porém, o buraco se alarga e se torna mais profundo. Os componentes existem com o propósito de serem intercambiáveis. Você não tem componentes se você não pode tirar um deles e colocar outro no lugar impunemente.

Frequentemente, os responsáveis por sistemas spaghetti ou aberrações similares, diante dos problemas insuportáveis causados inevitavelmente pela baixa coesão e pelo alto acoplamento, tentam "componentizar" seus sistemas com o intuito de obter os benefícios maravilhosos oferecidos pelos livros.

Vamos, então, pegar pedaços do sistema e enfiar dentro de DLLs!

Certamente isto não funciona.

Projeto: Eclipse + CppUnit

2008-04-06T19:24:00.003-03:00

Estou prestes a apresentar para o ccppbrasil.org um projeto de integração da CppUnit com o Eclipse TPTP.

Será uma oportunidade interessante de aprender a desenvolver sobre a plataforma OSGi e uma maneira de estimular a comunidade a aplicar as técnicas de testes de unidade.

A arquitetura do TPTP Test é assim: para um determinado "tipo de teste" registra-se um adaptador de implantação, um adaptador de ambiente e um adaptador de execução, bem como um runner para este "tipo de teste" no agente remoto.

A tarefa será implementar esses adaptadores para programas executáveis nativos e bibliotecas compartilhadas, resolvendo LD_LIBRARY_PATH e assuntos relacionados, depois implementar uma biblioteca de suporte em C para que programas joguem na saída padrão o histórico de execução da forma correta e por fim implementar com um wrapper Java um runner para suites de teste CppUnit na forma de plug-in.

Na verdade as tarefas ainda estão se abrindo porque não consegui dominar o problema de projeto completamente, o que me aborreceu um pouco, já que vou passar a semana ocupado com outros assuntos.

Encontro de Nerds em São Paulo

2008-04-02T23:29:00.003-03:00

Ora, aqui estamos nós!
O Encontro foi muito bom, evoluindo o formato do anterior.
Os nerds são inteligentes e conhecedoras das coisas, e bebem bastante cerveja e são engraçados demais.
Nosso trabalho continua no site ccppbrasil.org.

Quarto Encontro CCPP Brasil

2008-03-29T06:18:00.003-03:00

Cheguei há pouco na rodoviária de São Paulo.

Entrei em uma lan house pra anotar os endereços de que eu precisava. ¬¬

Cheguei cedo demais aqui; o ônibus fez a viagem em cinco horas e meia.
A turma só vai acordar depois das 07h, provavelmente às 08h.

Vou passar o tempo comendo e fumando.

Desta vez vou ficar hospedado no Formule One Jardins.
A estação de metrô da vez é Trianon-Masp.
Pra facilitar a minha vida comecei este mapa com marcadores para as estações do metrô.

OpenMP

2008-03-24T11:17:00.003-03:00

Reavaliar as hipóteses vigentes é sempre interessante quando você já possui alguma experiência; um retorno à "infância" do aprendizado, talvez, a uma época em que a sua sensação de segurança era mínima.

Acrescentar uma anotação tão singela quanto:

#pragma omp parallel

causou um desastre tremendo em um loop pequenininho dentro de pixman-mmx.c nesse fim de semana, experimentando com o André um novo caminho de otimização.

Se o seu compilador implementa OpenMP a diretiva acima transforma o bloco do loop seguinte de modo a despachar iterações individuais a um time de threads de trabalho.

Quando a hipótese de que uma iteração será seguida de outra some dependências entre acessos a dados surgem: enquanto uma iteração lê um endereço outra iteração escreve nesse enredeço, boom. Experimentamos muitos SIGSEGV com este loop. Eventualmente a implementação foi transformada de modo a eliminar essas dependências.

É interessante que se você não tem em mente essa questão não se dará ao trabalho e seus loops não terão iterações independentes. Porém, mesmo sem OpenMP, o GCC 4.3 produziu uma melhoria impressionante na execução deste código; certamente porque seus otimizadores aproveitaram novas oportunidades oferecidas por iterações livres de side effects observáveis.

ccppbrasil.org

2008-03-15T13:06:00.001-03:00

yo! _o/

Palestra em Sampa

2008-01-13T06:44:00.000-02:00

Próximo sábado, dia 19, darei uma palestra em Sampa com o seguinte título:

"C++0x - Novas características de suporte a projetos de bibliotecas genéricas"

Estou um pouco excitado e um pouco nervoso com essa oportunidade.

Participarei do terceiro encontro do Grupo de Usuários C/C++.
A programação do evento está aqui.

Fedora 7 nasceu

2007-05-31T11:41:00.000-03:00

Fedora é o sistema operacional livre que eu uso em casa.
Eu recomendo a todos e normalmente estou disposto a dar suporte voluntário (caveat emptor) para resolver problemas.

O ambiente de trabalho do Fedora é o GNOME e ele é muito bonito.

A versão 7 do sistema foi lançada hoje.
Vou instalar nesse fim de semana e dar o meu parecer.